MkDocs plugins with additional features
New features can be added to MkDocs engine by installing additional plugins. These packages can modify the navigation behavior, or render new content types, or export the site to PDF documents. Plugins also can be modified easily as they are written in Python.
Last update: 2021-06-02 19:10:48
Table of Content
1. Awesome Pages⚓
MkDocs Awesome Pages plugin simplifies configuring page titles and their entries order.
Install the plugin:
pip install -U mkdocs-awesome-pages-plugin
Enable it in the config file:
plugins:
- search # built-in search must be always activated
- awesome-pages
It overrides the nav
sections in the site config file mkdocs.yml
, and provides some more extra configs:
-
Create a YAML file named
.pages
in a directory and use thenav
attribute to customize the navigation on that level. List the files and subdirectories in the order that they should appear in the navigation. -
A 3-dots
...
entry is used to specify where all remaining items should be inserted. It can filter the remaining items using glob patterns or regular expressions. For example:.pages
nav: - ... | introduction-*.md - ... - summary.md
The pattern is checked against the basename of remaining items - not their whole path, so it can be used to filter files in sub-folders.
-
Hide directory by setting the
hide
attribute totrue
. - Optionally set the directory title using the
title
attribute. -
Optionally specify a title for the navigation entry before its document path. For example:
.pages
title: New section nav: - First page: page1.md - Link Title: https://example.com
-
Collapse single nested pages by setting
collapse_single_pages
attribute totrue
.
2. Section index⚓
MkDocs Section Index is a plug that change the navigation sidebar to turn section name to a link that show the index page that section.
Install the plugin:
pip install -U mkdocs-section-index
Enable it in the config file:
plugins:
- search # built-in search must be always activated
- awesome-pages
- section-index # must be after awesome-pages
In MkDocs, each directory will become a section, and by default, section only contains its children. There is no page associated to a section. This plugin will merge the index.md
page in the directory to its section label. However, the merge section page show the section’s title from directory name, not the page’s title.
This result is different from using collapse_single_pages: true
option in the Awesome Pages plugin. If use single page collapsing, Awesome Pages plugin replace the section which has only one child by its child page. Therefore, a directory with index.md
and some sub-folders will not be processed to merge the index.md
to the section label of that directory.
Use both Awesome Pages collapse_single_pages
option and Section Index will make a better result because both page and title are merged to the section.
3. Revision date⚓
To keep tracking the last modified date of a post, git-revision-date plugin can be used. A better alternative plugin is git-revision-date-localized which provides more types of date format (even in time-ago format), and the creation date.
Install the plugin:
pip install -U mkdocs-git-revision-date-localized-plugin
Enable it in the config file:
plugins:
- search # built-in search must be always activated
- git-revision-date-localized:
enable_creation_date: true
type: iso_date
This plugin create new field in the post’s meta-data which content the creation and update date. This information is used to sort the posts by revision date to get recently updated items, as shown in the Blog page. Read more in the Customize theme.
4. Print to PDF⚓
To export the posts on this blog, there are plugins which can do it. However, most of them depend on Weasy Print which in turn depends on many other packages. There is one plugin that does printing in an easy and simple way: use browser to print page by sending print command (like press Ctrl + S
).
More detail of installation and configuration the MkDocs PDF with JS plugin for printing to PDF can be read in Print to PDF.
5. Macros⚓
This plugin is no longer used in this site!
MkDocs Macros is a plugin/framework that makes it easy to produce richer and more beautiful pages. It can do two things:
-
Transform the markdown pages into a Jinja2 templates that can use variables, macros and filters.
-
Replace MkDocs plugins for a wide range of tasks: e.g. manipulating the navigation, adding files after the html pages have already been generated etc.
Install the plugin:
pip install -U mkdocs-macros-plugin
Enable it in the config file:
plugins:
- search # built-in search must be always activated
- macros
Incomplete data in marco
The macro {{ navigation.pages }}
contains a list of all pages, but the data of each page maybe not complete, such as title or meta-data.
This issue happens when rendering a the content of the first page, but it needs to know the content of the second page which has not been parsed already as it is waiting for the first page getting done.
6. DrawIO Exporter⚓
This plugin is no longer used in this site!
DrawIO Exporter is a great plugin that exports the .drawio
diagrams to images at build time and insert them to the document. This plugin can replace the Mermaid plugin, and it is faster thanks to no javascript needed at runtime. It also helps to enable instant navigation mode of the Material theme.
Install the plugin:
pip install -U mkdocs-drawio-exporter
Enable it in the config file:
plugins:
- search # built-in search must be always activated
- drawio-exporter
To create end edit .drawio
diagram, download and install the diagrams.net application.
To import a diagram, just use the syntax for inserting an image:
![My alt text](my-diagram.drawio)
The plugin will generate an svg image to a cache folder (default in docs\drawio-exporter
), and then modify the image source attribute to the generated image.
If the diagram is a multi-page documents, append the index of the page as an anchor in the URL:
![Page 1](my-diagram.drawio#0)
A limitation
Using Draw.io Integration extension in Visual Studio Code, I can save a DrawIO diagram as a .drawio.svg
file, then use that file directly in the page as an usual image. However this method will not support multiple pages in the drawing:
![My alt text](my-diagram.drawio.svg) // work
![My alt text](my-diagram.drawio.svg#1) // does not work
7. Mermaid⚓
This plugin is no longer used in this site!
MkDocs Mermaid2 is a plugin to render textual graph description into Mermaid graphs (flow charts, sequence diagrams, pie charts, etc.).
Install the plugin:
pip install -U mkdocs-mermaid2-plugin
Enable it in the config file:
plugins:
- search # built-in search must be always activated
- mermaid2
And configure the codeblock parser for mermaid2 blocks:
markdown_extensions:
- pymdownx.superfences:
custom_fences:
- name: mermaid
class: mermaid
format: !!python/name:mermaid2.fence_mermaid
Example:
```mermaid
graph LR
A[Start] --> B{Error?};
B -->|Yes| C[Hmm...];
C --> D[Debug];
D --> B;
B ---->|No| E[Yay!];
```
will render as:


--- title: 'When is the golden age of rap music?' author: Xuxin Zhang date: '2020-10-10' slug: golden-age-of-rap categories: - R project tags: - data visualization - data analysis subtitle: '' summary: '' authors: [] lastmod: '2020-10-10T19:21:58+08:00' featured: no image: caption: '' focal_point: '' preview_only: no projects: [] ---
I have a rap-enthusiast friend whom I have known for a long time. We became friends when we were still in kindergarten. Now he’s operating his own vintage outfit store. Every single time I visit him, he will definitely play some old school rap music in his store. Under his influence, I have get myself familiar with the names of those OG rappers such as Biggie, Tupac, and NWA.
Gradually, I notice that he seldom plays the “new style” rap songs such as mumble-rap and trap. One time I asked him why so, and he said “I just love the old school rap. They are much realer if you know what I mean.” Well, to be honest, I don’t, and that’s exactly why I’m writing this post to analyze the rap musics of different time. Hopefully, I can find out the golden age of rap music.
library(tidyverse)
library(hrbrthemes)
library(gganimate)
library(plotly)
polls <- readr::read_csv('https://raw.githubusercontent.com/rfordatascience/tidytuesday/master/data/2020/2020-04-14/polls.csv')
rankings <- readr::read_csv('https://raw.githubusercontent.com/rfordatascience/tidytuesday/master/data/2020/2020-04-14/rankings.csv')
After importing the data, we first focus on the poll data since its sample size is larger. With the poll data, because the only variable that reflects the quality of these songs is rank
, we will calculate the average ranking of the nominated songs for each year to show how the quality varies across time.
Based on this graph and the help of the regression line, we see that the trend for the average numerical value of the ranking is actually increasing over time. That is to say, the quality, on the contrary, is decreasing. In particular, there are three years that have record high rankings of all time in the 80s. In this way, we can infer that the golden age of rap music could be the 80s.
polls%>%
group_by(year)%>%
summarise(av_rank = mean(rank))%>%
ggplot(aes(x = year, y = av_rank),group = 1)+
geom_point(color = ft_cols$yellow)+
geom_line(color = ft_cols$white)+
geom_smooth(color = ft_cols$white)+
labs(x = "Year",
y = "Average ranking",
title = "How the average ranking changes across time?",
subtitle = "The regression result shows that the average ranking is increasing,
which means the quality of the rap musics decreases over time."
)+
theme_ft_rc()
## `summarise()` ungrouping output (override with `.groups` argument)
## `geom_smooth()` using method = 'loess' and formula 'y ~ x'
Then we take a look at how the rating changes for both genders. First thing we notice is that there are more points for songs that are created by male rappers and female rappers, which means songs created by male rappers are more likely to get nominated. In addition, the numerical values of average ranking of songs created by male rappers are mostly lower than those of female rappers. These two phenomena convey the information that the rap music industry is dominated by male rappers and the systematic gender gap does exist.
polls%>%
filter(gender!="mixed")%>%
group_by(year,gender)%>%
summarise(av_rank = mean(rank))%>%
ggplot(aes(x = year, y = av_rank,color = gender))+
geom_point()+
geom_line()+
labs(x = "Year",
y = "Average ranking",
title = "How the average ranking changes for different genders?",
color = "",
subtitle = "From this graph, we see that the rap industry is predominatedly occupied by male rappers."
)+
geom_smooth()+
facet_wrap(~gender,scales = "free_x")+
scale_color_manual(values = c("yellow","white"))+
theme_ft_rc()+
theme(legend.position = "null")
## `summarise()` regrouping output by 'year' (override with `.groups` argument)
## `geom_smooth()` using method = 'loess' and formula 'y ~ x'
The gender gap could be further illustrated by the following graph. Here, we have picked out the top five artists of each gender with the highest number of nominations. Even though Missy Elliott takes the first place of female rappers with her songs nominated by 9 times, she is still way out-numbered by the fifth place male rapper OutKast with his songs nominated by 17 times. Not to memtion the fact that Salt-N-Pepa and Cardi B are both nominated only twice.
polls%>%
filter(gender!="mixed")%>%
group_by(gender)%>%
count(artist,sort=TRUE)%>%
top_n(5)%>%
ggplot(aes(x = n, y = reorder(artist,n), color = gender))+
geom_point(size = 4)+
geom_segment(aes(x = 0,xend = n, y = artist, yend = artist),size = 3, alpha = 0.5)+
geom_text(aes(label = n),hjust = 2)+
scale_color_manual(values = c("yellow","white"))+
labs(x = "Nomination number",
y = "Artists",
title = "The top 5 artists with\n most nomination for each gender")+
theme_ft_rc()
## Selecting by n
Next, by taking the average ranking of the songs nominated for each artist, we have the following rough list of the top 15 rap artists with best quality of works.
library(ggrepel)
top_artists_ranking<-polls%>%
add_count(artist)%>%filter(n>7)%>%
group_by(artist)%>%
summarise(av_ranking = mean(rank))%>%
ungroup()%>%
top_n(15,-av_ranking)
## `summarise()` ungrouping output (override with `.groups` argument)
polls%>%
inner_join(top_artists_ranking)%>%
add_count(title)%>%
mutate(title_for_graph = ifelse(n>=10,title,""))%>%
ggplot(aes(x = year, y = reorder(artist,-av_ranking)))+
geom_point(aes(size = n),color = ft_cols$yellow,alpha = 0.15)+
geom_text(aes(label = title_for_graph),
color = "white",
hjust = -0.1)+
labs(x = "Year", y = "",
title = "The greatest 15 rappers of all time")+
theme_ft_rc()+
theme(legend.position = "null")
## Joining, by = "artist"
The top three rap artists are Public Enemy, The Notorious B.I.G (with no doubt), and Eric B & Rakim. Since the other rappers on the list are also quite famous, I would assume this ranking is valid. In the graph, I have also annotate the names of songs that are nominated more than 10 times. Thus, based on the poll dataset, the greatest songs are “Fight The Power”, “Juicy”, “Shook Ones (Part II)”, “The Meessage”, “C.R.E.A.M.”, and “Nuthin’ But A ‘G’ Thang”.
There is another thing in the graph which is worthwhile to point out. Notice the points with large size are clustering in the 1980-1990 time period. This could be seen as another reference to the golden age of rap music.
rankings%>%
filter(ID!=70)%>%
ggplot(aes(x = year, y = points, color = gender))+
geom_point(alpha = 0.6)+
scale_y_log10()+geom_smooth(color = "white")+
labs(title = "How does quality of songs change through time?")+
scale_color_manual(values = c("indianred1","yellow","white"))+
theme_ft_rc()
## `geom_smooth()` using method = 'loess' and formula 'y ~ x'
rankings%>%
group_by(year)%>%
summarise(av_points = mean(points))%>%
ggplot(aes(x = year, y = av_points),group = 1)+
geom_point(color = ft_cols$yellow)+
geom_line(color = ft_cols$white)+
labs(x = "Year",
y = "Average ranking",
title = "How does the average points change?")+
theme_ft_rc()
## `summarise()` ungrouping output (override with `.groups` argument)
top_ranking_gender<-rankings%>%
distinct(ID,year,title, artist, gender, points)%>%
group_by(gender)%>%
top_n(10,points)%>%
ungroup()
top_ranking_gender%>%
ggplot(aes(x = year, y = points, color = gender))+
geom_point(aes(size = points*500))+
scale_color_manual(values = c("indianred1","yellow","white"))+
labs(title="Points distribution of top 10 songs \nperformed by artists of each gender ")+
theme_ft_rc()+
scale_y_log10()+
scale_size_continuous(guide = FALSE)
top_ranking_gender%>%
ggplot(aes(x = year, y = points, color = gender))+
scale_color_manual(values = c("indianred1","yellow","white"))+
geom_text_repel(aes(label = title), force = 20)+
labs(title="The top 10 songs performed by artists of each gender ")+
theme_ft_rc()+
scale_y_log10()
library(tidytext)
rankings%>%
distinct(title, year)%>%
unnest_tokens(word, title)%>%
anti_join(stop_words)%>%
inner_join(get_sentiments("afinn"))%>%
group_by(year)%>%
summarise(av_sent = mean(value, na.rm = TRUE))%>%
ggplot(aes(x = year, y = av_sent), group=1)+
geom_point(color = "yellow")+geom_line(color = "white")+
geom_smooth(se=FALSE, color = "white", alpha = 0.6)+
labs(y = "Average sentiment",
title = "How does the average sentiment for the titles change?")+
theme_ft_rc()
## Joining, by = "word"
## Joining, by = "word"
## `summarise()` ungrouping output (override with `.groups` argument)
## `geom_smooth()` using method = 'loess' and formula 'y ~ x'


These underground caves serve as a feeding ground for Greed imps. Seeing as these caves are dispersed underground. The Greed imps must aqurire a lot of wealth, to buy them for their raw minerals. These caves are not effected by the weather above ground.
The days are colder and there is less to harvest. The imps use the dead leaves, as fuel for their home's fires. As the trees begin to rest, the imps thank them for their gifts (leaves, wood, fruit, ect.) These days are known as the 'Wilting Season of Change'.
The ice that has blanketed the forest has melted away. This river is located between the Gluttonous and Lust imp territory. The green of the forest is an ideal place to find fresh herbs for medicine.
They harvest half of the fruits, levaing some back for the forset. Fruits are preserved in magical jars that can preserve fruits for 100+ years. This leaves the forest more and more abundent every year.
The woods during summer are hot and lush with trees, it is easy to get lost with all of the new greenery covering the dirt roads. Projects are created by the player to make permanent road that can be travered by imps and not obscured by the forest.
Now that the snow has fallen, the land is asleep (unable to produce crops). The imps can take a break to find wood to warm their house. The Lust imps who own cloth shops have a bomb in sales, selling clothes for travelling imps.
The imps of Pride live in a colorless, monochromal world. Their skys are covered in clouds, giving off shades of gray. The forest's trees resemble hands from the soil, due to the trees feeding from the imp's diety; the Pride imp's diety is the imp of the underworld. No Pride imp has ever seen the blue of the sky or the setting sun.


Performs model fitting and significance estimation for Localised Co-Dependency between pairs of features of a numeric dataset.
| Version: | 0.1 |
| Depends: | R (≥ 2.15.0) |
| Published: | 2013-09-30 |
| Author: | Ed Curry [aut, cre] |
| Maintainer: | Ed Curry <e.curry at imperial.ac.uk> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| URL: | http://www.r-project.org, http://www1.imperial.ac.uk/medicine/people/e.curry/ |
| NeedsCompilation: | no |
| CRAN checks: | LCA results |
| Reference manual: | LCA.pdf |
| Package source: | LCA_0.1.tar.gz |
| Windows binaries: | r-devel: LCA_0.1.zip, r-release: LCA_0.1.zip, r-oldrel: LCA_0.1.zip |
| OS X binaries: | r-release: LCA_0.1.tgz, r-oldrel: LCA_0.1.tgz |
| Reverse imports: | Wrapped |
Please use the canonical form https://CRAN.R-project.org/package=LCA to link to this page.


Description: Hide the matched elements by fading them to transparent.
duration: String,Number A string or number determining how long the animation will run.
callback: Callback A function to call once the animation is complete.
options: Options A map of additional options to pass to the method.
duration: String,Number A string or number determining how long the animation will run.
easing: String A string indicating which easing function to use for the transition.
callback: Callback A function to call once the animation is complete.
The .fadeOut()
method animates the opacity of the matched elements. Once the opacity reaches 0, the display
style property is set to none
, so the element no longer affects the layout of the page.
Durations are given in milliseconds; higher values indicate slower animations, not faster ones. The strings 'fast'
and 'slow'
can be supplied to indicate durations of 200
and 600
milliseconds, respectively. If any other string is supplied, or if the duration
parameter is omitted, the default duration of 400
milliseconds is used.
We can animate any element, such as a simple image:

Click here

With the element initially shown, we can hide it slowly:
$('#clickme').click(function() {
$('#book').fadeOut('slow', function() {
// Animation complete.
});
});
Note: To avoid unnecessary DOM manipulation,
.fadeOut()
will not hide an element that is already considered hidden. For information on which elements jQuery considers hidden, see :hidden Selector.
As of jQuery 1.4.3, an optional string naming an easing function may be used. Easing functions specify the speed at which the animation progresses at different points within the animation. The only easing implementations in the jQuery library are the default, called swing
, and one that progresses at a constant pace, called linear
. More easing functions are available with the use of plug-ins, most notably the jQuery UI suite.
If supplied, the callback is fired once the animation is complete. This can be useful for stringing different animations together in sequence. The callback is not sent any arguments, but this
is set to the DOM element being animated. If multiple elements are animated, it is important to note that the callback is executed once per matched element, not once for the animation as a whole.
As of jQuery 1.6, the .promise()
method can be used in conjunction with the deferred.done()
method to execute a single callback for the animation as a whole when all matching elements have completed their animations ( See the example for .promise() ).
.fadeOut()
, can be turned off globally by setting jQuery.fx.off = true
, which effectively sets the duration to 0. For more information, see jQuery.fx.off.
<!DOCTYPE html>

If you click on this paragraph
you'll see it just fade away.

<!DOCTYPE html>

Find the modifiers -

If you really want to go outside
in the cold then make sure to wear
your warm jacket given to you by
your favorite teacher.

<!DOCTYPE html>

<button id="btn1">fade out</button>
<button id="btn2">show</button>

linear

swing


Plan the course of your experience using our simple and effective trip outlining feature. Just looking for a tour guide? Use Guidr to browse through tour guides in your favorite locations!
Want to remember those little details? Keep a log during and after your adventure to share with the world.
Show the world your amazing discoveries and encounters by adding personal photos from your tour to your Guidr portfolio. Connect with other Guidr users and view their adventures too!
Stay organized and boost productivity with our calendar feature. Keep track of your future tours with our easy scheduling system.
Plan the course of your experience using our simple and effective trip outlining feature. Just looking for a tour guide? Use Guidr to browse through tour guides in your favorite locations!
Want to remember those little details? Keep a log during and after your adventure to share with the world.
Show the world your amazing discoveries and encounters by adding personal photos from your tour to your Guidr portfolio. Connect with other Guidr users and view their adventures too!
Stay organized and boost productivity with our calendar feature. Keep track of your future tours with our easy scheduling system.


MARVEL
Hero Hangman
Press This Button to Play!
START
Guess the Marvel Hero!


Preparation time
overnight
Cooking time
30 mins to 1 hour
Serves
Serves 4
A delicate starter of venison and cherries.
Place the venison in a large bowl and coat with 2 tablespoons oil, garlic, half the thyme, the juniper berries and peppercorns. Cover and refrigerate overnight.
When ready to cook, remove from the marinade and season with salt and pepper.
Sear in a very hot pan for 1 minute on each side, or until coloured all over. Remove from the pan, wrap in cling film and allow to rest in the fridge until ready to eat.
Preheat the oven to 180C/160C Fan/Gas 4.
Line a deep ovenproof dish with kitchen foil and place the beetroots inside. Bring the sides of the foil up around the beetroots, leaving a small gap. Pour the sherry vinegar and red wine vinegar into the foil, add ½ teaspoon salt, the sugar and remaining thyme, then seal the foil.
Pour 100–200ml/3½–7fl oz water around the foil into the tray (depending on saucepan size) and roast for 30–40 minutes, or until soft. Remove from the oven and allow to cool in the juices. Peel and roughly chop.
Place the celeriac in a saucepan with the milk and cream over a medium heat. Cook until soft, season with salt and pepper and blend using a hand blender. Set aside.
Meanwhile, in a bowl, mix the remaining 3 tablespoons oil with the white wine vinegar, mustard and a pinch of salt and pepper. Stir in the cherries.
Preheat a deep-fat fryer to 180C (CAUTION: hot oil can be dangerous. Do not leave unattended.). Deep-fry the kale in batches for 1 minute. Remove and drain on kitchen paper. Set aside.
Slice the venison into thin pieces and divide equally between four plates. Garnish with the beetroot, cherries, a few drops of celeriac purée and the kale.


SASL - Implementation of SASL mechanisms for Tcl
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and authorization to comunications protocols. The SASL framework is structured to permit negotiation among a number of authentication mechanisms. SASL may be used in SMTP, IMAP and HTTP authentication. It is also in use in XMPP, LDAP and BEEP. See MECHANISMS for the set of available SASL mechanisms provided with tcllib.
 All the mechanisms work the same way although the number of steps may vary. In this implementation a callback procedure must be provided from which the SASL framework will obtain users details. See CALLBACK PROCEDURE for details of this procedure.
Contruct a new SASL context. See OPTIONS for details of the possible options to this command. A context token is required for most of the SASL procedures.
Modify and inspect the SASL context option. See OPTIONS for further details.
This is the core procedure for using the SASL framework. The step procedure should be called until it returns 0. Each step takes a server challenge string and the response is calculated and stored in the context. Each mechanism may require one or more steps. For some steps there may be no server challenge required in which case an empty string should be provided for this parameter. All mechanisms should accept an initial empty challenge.
Returns the next response string that should be sent to the server.
Re-initialize the SASL context. Discards any internal state and permits the token to be reused.
Release all resources associated with the SASL context. The context token may not be used again after this procedure has been called.
Returns a list of all the available SASL mechanisms. The list is sorted by the mechanism preference value (see register) with the preferred mechanisms and the head of the list. Any mechanism with a preference value less than theminimum (which defaults to 0) is removed from the returned list. This permits a security threshold to be set. Mechanisms with a preference less that 25 transmit authentication are particularly susceptible to eavesdropping and should not be provided unless a secure channel is in use (eg: tls).
The type parameter may be one of client or server and defaults to client. Only mechanisms that have an implementation matching the type are returned (this permits servers to correctly declare support only for mechanisms that actually provide a server implementation).
New mechanisms can be added to the package by registering the mechanism name and the implementing procedures. The server procedure is optional. The preference value is an integer that is used to order the list returned by the mechanisms command.  If the mechanism is already registered then the recorded values are updated.
Specify a command to be evaluated when the SASL mechanism requires information about the user. The command is called with the current SASL context and a name specifying the information desired. See EXAMPLES.
Set the SASL mechanism to be used. See mechanisms for a list of supported authentication mechanisms.
Set the service type for this context. Some mechanisms may make use of this parameter (eg DIGEST-MD5, GSSAPI and Kerberos). If not set it defaults to an empty string. If the -type is set to 'server' then this option should be set to a valid service identity. Some examples of valid service names are smtp, ldap, beep and xmpp.
This option is used to set the server name used in SASL challenges when operating as a SASL server.
The context type may be one of 'client' or 'server'. The default is to operate as a client application and respond to server challenges. Mechanisms may be written to support server-side SASL and setting this option will cause each step to issue the next challenge. A new context must be created for each incoming client connection when in server mode.
When the SASL framework requires any user details it will call the procedure provided when the context was created with an argument that specfies the item of information required.
In all cases a single response string should be returned.
The callback procedure should return the users authorization identity. Return an empty string unless this is to be different to the authentication identity. Read [1] for a discussion about the specific meaning of authorization and authentication identities within SASL.
The callback procedure should return the users authentication identity. Read [1] for a discussion about the specific meaning of authorization and authentication identities within SASL.
The callback procedure should return the password that matches the authentication identity as used within the current realm.
For server mechanisms the password callback should always be called with the authentication identity and the realm as the first two parameters.
Some SASL mechanisms use realms to partition authentication identities. The realm string is protocol dependent and is often the current DNS domain or in the case of the NTLM mechanism it is the Windows NT domain name.
Returns the client host name - typically [info host].
As used in FTP this mechanism only passes an email address for authentication. The ANONYMOUS mechanism is specified in [2].
 The users authentication details are transmitted in plain text. This mechanism should not be provided unless an encrypted link is in use - typically after SSL or TLS has been negotiated.
The LOGIN [1] mechanism transmits the users details with base64 encoding. This is no more secure than PLAIN and likewise should not be used without a secure link.
This mechanism avoids sending the users password over the network in plain text by hashing the password with a server provided random value (known as a nonce). A disadvantage of this mechanism is that the server must maintain a database of plaintext passwords for comparison. CRAM-MD5 was defined in [4].
This mechanism improves upon the CRAM-MD5 mechanism by avoiding the need for the server to store plaintext passwords. With digest authentication the server needs to store the MD5 digest of the users password which helps to make the system more secure. As in CRAM-MD5 the password is hashed with a server nonce and other data before being transmitted across the network. Specified in [3].
OTP is the One-Time Password system described in RFC 2289 [6]. This mechanism is secure against replay attacks and also avoids storing password or password equivalents on the server. Only a digest of a seed and a passphrase is ever transmitted across the network. Requires the otp package from tcllib and one or more of the cryptographic digest packages (md5 or sha-1 are the most commonly used).
This is a proprietary protocol developed by Microsoft [5] and is in common use for authenticating users in a Windows network environment. NTLM uses DES encryption and MD4 digests of the users password to authenticate a connection. Certain weaknesses have been found in NTLM and thus there are a number of versions of the protocol. As this mechanism has additional dependencies it is made available as a separate sub-package. To enable this mechanism your application must load the SASL::NTLM package.
This is a proprietary protocol developed by Google and used for authenticating users for the Google Talk service. This mechanism makes a pair of HTTP requests over an SSL channel and so this mechanism depends upon the availability of the tls and http packages. To enable this mechanism your application must load the SASL::XGoogleToken package. In addition you are recommended to make use of the autoproxy package to handle HTTP proxies reasonably transparently.
This is a protocol specified in RFC 5802 [7]. To enable this mechanism your application must load the SASL::SCRAM package.
See the examples subdirectory for more complete samples using SASL with network protocols. The following should give an idea how the SASL commands are to be used. In reality this should be event driven. Each time the step command is called, the last server response should be provided as the command argument so that the SASL mechanism can take appropriate action.
proc ClientCallback {context command args} { switch -exact -- $command { login { return "" } username { return $::tcl_platform(user) } password { return "SecRet" } realm { return "" } hostname { return [info host] } default { return -code error unxpected } } } proc Demo {{mech PLAIN}} { set ctx [SASL::new -mechanism $mech -callback ClientCallback] set challenge "" while {1} { set more_steps [SASL::step $ctx challenge] puts "Send '[SASL::response $ctx]'" puts "Read server response into challenge var" if {!$more_steps} {break} } SASL::cleanup $ctx }
Myers, J. "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. (http://www.ietf.org/rfc/rfc2222.txt)
Newman, C. "Anonymous SASL Mechanism", RFC 2245, November 1997. (http://www.ietf.org/rfc/rfc2245.txt)
Leach, P., Newman, C. "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000, (http://www.ietf.org/rfc/rfc2831.txt)
Klensin, J., Catoe, R. and Krumviede, P., "IMAP/POP AUTHorize Extension for Simple Challenge/Response" RFC 2195, September 1997. (http://www.ietf.org/rfc/rfc2195.txt)
No official specification is available. However, http://davenport.sourceforge.net/ntlm.html provides a good description.
Haller, N. et al., "A One-Time Password System", RFC 2289, February 1998, (http://www.ieft.org/rfc/rfc2289.txt)
Newman, C. et al., "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010, (http://www.ieft.org/rfc/rfc5802.txt)
Pat Thoyts
This document, and the package it describes, will undoubtedly contain bugs and other problems. Please report such in the category sasl of the Tcllib Trackers. Please also report any ideas for enhancements you may have for either package and/or documentation.
When proposing code changes, please provide unified diffs, i.e the output of diff -u.
Note further that attachments are strongly preferred over inlined patches. Attachments can be made by going to the Edit form of the ticket immediately after its creation, and then using the left-most button in the secondary navigation bar.
Networking
Copyright © 2005-2006, Pat Thoyts <patthoyts@users.sourceforge.net>


Collector Yumi:
Interesting. Wendy and Atlanta's memories, taken together, form parts of a coherent picture. I think they fell asleep at the same time and were reawakened by Dr. Chaos.
Ask about Dr. Chaos.


ChainZilla provides the most efficient and flexible end-to-end blockchain solutions. These include project onboarding, tokenization, app development, ICO management, and blockchain migrations.
100 messages
Before 05-Dec-19 12:00 AM
GatewayBOT13-Oct-18 09:39 PM
[dscrd-cz] <PTYX> ok
[dscrd-cz] <PTYX> i've created #exchanges
GatewayBOT13-Oct-18 09:52 PM
[dscrd-cz] <Emmanuel> @jono it was his University ip
[dscrd-cz] <jono> @Emmanuel SMH
[dscrd-cz] <PTYX> Jeeez
[dscrd-cz] <PTYX> Lucky he didn't get swatted
[dscrd-cz] <PTYX> I'll be honest it was my first time ever watching twitch or whatever it's called
[dscrd-cz] <PTYX> Twitching
[dscrd-cz] <jono> Same here . Never used it before .
GatewayBOT13-Oct-18 10:06 PM
[dscrd-cz] <Emmanuel> you maybe remember justin.tv
What are the @Chainzillaio services offered and their benefits? Blockchain as a service solution. Services onboard, application development and ICO management for #Komodo, $NEM, $Qtum and #Etherum and other services!
See the video: https://t.co/SgJ7BySss1
@KomodoPlatform...
GatewayBOT14-Oct-18 11:15 AM
[dscrd-cz] <Instel7> @ollsanek @h6y34ui98 Hello there! Welcome to Chainzilla. Hope you have a nice stay in here, let me know if you need help
It's amazing to be surrounded by projects that work daily as a single team, sinergizing their efforts with one common goal!
Thanks to @KomodoRussia for supporting the ecosystem. Support them too with a follow! https://t.co/iqt9S03n42
[dscrd-cz] <Instel7> I want to say thanks to @ghøst and @Mixic for their great support to the whole ecosystem. Keep that soul mates!
[dscrd-cz] <Mixic> Thank you, Instel
[dscrd-cz] <ghøst> Thank you, Instel
[dscrd-cz] <Mixic> Ghost and I always happy to help you
[dscrd-cz] <PTYX> I am also working with them to add ChainZilla
[dscrd-cz] <Instel7> Only chrome?
[dscrd-cz] <Instel7> Not Firefox?
[dscrd-cz] <PTYX> right now it's availble on chrome.
GatewayBOT14-Oct-18 09:33 PM
[dscrd-cz] <javadth> is it safe ?
[dscrd-cz] <PTYX> Guarda has a good team
[dscrd-cz] <PTYX> have i had someone check the code, not yet
[dscrd-cz] <PTYX> would i trust it with more than 100 KMD, no. I wouldn't trust any online wallet with more than 100KMD.
[dscrd-cz] <PTYX> however, i do have less than 100KMD in various online wallets because you do have to spend it every now and then. it's convenient. With the chrome extension you generate a seed so I assume if your browser is not compromised you should be ok.
SHossain14-Oct-18 09:47 PM
@PTYX did you find out why their Android wallets been removed from Google Play Store?
GatewayBOT14-Oct-18 09:47 PM
[dscrd-cz] <PTYX> yes, it was related to another application they developed - a game. it got banned and they subsequently banned all their apps.
[dscrd-cz] <PTYX> from what i understand, they were planning on getting rid of the standalone apps anyway and were releasing a multiwallet
[dscrd-cz] <PTYX> which i guess is what they did now with the chrome extension and their new web wallet.
ChainZilla is now supported in @peer2group's Pungo App for Android. Thank you Peer2Group! Now users can store and spend your $ZILLA tokens using the Pungo Wallet. @KomodoPlatform @VerusCoin #komodoecosystem #blockchainasaservice #cryptocurrency
GatewayBOT15-Oct-18 05:48 PM
[dscrd-cz] <c2k> FIDELITY LAUNCHES NEW COMPANY, FIDELITY DIGITAL ASSETS
Fidelity offering Bitcoin trading to hedge funds now!
GatewayBOT15-Oct-18 06:24 PM
[dscrd-cz] <Instel7> Hey @JAKE#1168 Welcome to Chainzilla
[dscrd-cz] <Hungry_BullBear> In the roadmap there is a dICO - can you explain in few words how is that supposed to work and what advantages it has to "regular" ICO
[dscrd-cz] <MadamLobster> It is really cool! I like website!
[dscrd-cz] <figgy132> I like the site, so easy on the eyes! One thing I noticed is the message you get once you subscribe to the newsletter - 'Thank you for Subscribing our update.' - might be missing the word 'to' or the words 'our update' are surplus :)
[dscrd-cz] <PTYX> @Hungry_BullBear are you referring to the dICO app?
[dscrd-cz] <Hungry_BullBear> yes
[dscrd-cz] <Instel7> @twittler It's gonna be in January
[dscrd-cz] <Instel7> Thanks @figgy132 There are some changes that we'll be making in these next days
[dscrd-cz] <PTYX> The dICO app was used by Utrum to carry out an atomic-swap powered decentralized ICO
[dscrd-cz] <PTYX> however, the app needs some improvements along with marketmaker
[dscrd-cz] <PTYX> our plan was to develop an improved version of the dico app to offer an easy to use dICO app for our clients. Not only for KICs but for ETH assets, Nem assets, and any other coin you can trade on BarterDEX protocol(edited)
[dscrd-cz] <PTYX> The advantages of a dICO is that you are fulfilling the orders atomically. There is no trust involved which is gamechanging for ICOs. Contributors usually have to trust that the ICO issuer will pay the tokens.
[dscrd-cz] <Hungry_BullBear> sounds really useful
[dscrd-cz] <PTYX> definitely. The more tools we have out our disposal the more things we can offer our clients.
GatewayBOT15-Oct-18 09:08 PM
[dscrd-cz] <Mixic> Excellent! Congratulations!
[dscrd-cz] <NWhiskeyTango> The animations started getting delayed when i scrolled down, about when i got to "developers". Looks great though.
[dscrd-cz] <NWhiskeyTango> What are the tokens used for? Buying zilla products? I understand the use case, but confused about the purpose of the token it's self
[dscrd-cz] <PTYX> the token will server many purposes. one of them is spending them for our services at a discount
[dscrd-cz] <PTYX> however, we plan on activating cryptoconditions next year and we want to implement voting functions, airdrops, and other reward mechanisms
[dscrd-cz] <PTYX> when our apps are finished we might allow advertising through the apps which will pay the users in ZILLA.
[dscrd-cz] <PTYX> Projects that launch through ChainZilla might want to reward the Zilla community with direct airdrops. We will try to keep the zilla token as relevant as possible in terms of use-cases
[dscrd-cz] <pdtm> a lot of Work but well done so far
[dscrd-cz] <PTYX> definitely alot of work. most people don't know we have been also delivering a DIY project
[dscrd-cz] <PTYX> we finished the handover yesterday.
[dscrd-cz] <PTYX> so we are already a revenue generating company
Checkout our new #ICO website: https://t.co/VdeorKVABG In the coming weeks we will activate registrations through our ICO dashboard. Do you want to launch your own ICO or integrate blockchain into your business? Join us! Discord: https://t.co/43yTBISHq7 @KomodoPlatform
GatewayBOT16-Oct-18 02:17 AM
[dscrd-cz] <PTYX> Welcome @ABEE Help
GatewayBOT16-Oct-18 03:56 AM
[dscrd-cz] <miles> @PTYX - site looks slick and worked well on iPhone / safari - noticed a couple of minor typos on a scroll through - Boarrd Member and minimal investment amount, I would normally read that as minimum investment amount if specifying threshold of entry. Awesome effort as always and congrats on first project
[dscrd-cz] <miles> Will have a closer look through again when on a desktop
GatewayBOT16-Oct-18 03:08 PM
[dscrd-cz] <PTYX> @miles great feedback. We'll get those fixes ready
GatewayBOT16-Oct-18 05:47 PM
[dscrd-cz] <PTYX> @Dexter88 @John Heldnik and @kimmel (Peer2.group) welcome to our channel. Checkout our #tipbot channel and get rained on
[dscrd-cz] <PTYX> Is anyone interested in being one of our channel moderators?
[dscrd-cz] <kimmel (Peer2.group)> thanks for the warm welcome @PTYX always a pleasure
Blockchain service provider Chainzilla and cryptocurrency exchange operator NIX have partnered to provide a bridge communication between digital currency exchanges.


This is the API documentation for 'rack-cache-1.2 Documentation'.
[Validate]
Generated with the Darkfish Rdoc Generator 2.


v1.3.9
- Bugfixes:
- Ensure endpoints can’t be overwritten
- Pitch label in path selector displays as channel 224
- Updates:
- Allow endpoints to be dragged vertically
- Added “Always on Top” toggle option to menu (under Window)
- Added current version number to the bottom left side of Bezie
- Keyboard shortcuts added:
- command (mac) / ctrl (win) + t: Toggle Always on Top
v1.3.8
v1.3.7
- Introduced modes (clock & controller)
In clock mode (existing/default functionality), Bezie transmits automation against your DAW's MIDI clock. Controller mode allows you to trigger Bezie automation with either a hardware MIDI controller or your computer's keyboard (shortcuts below). In controller mode you can easily map from your hardware controller as well as select the tempo in which to send out the automation. These modes can be selected in MIDI preferences.
- Keyboard shortcuts added:
- shift + 1-8: Trigger envelope (active in controller mode only)
- up/down: Cycle through curve types on the selected point (default, bezier 1, bezier 2)
- backspace: Delete selected point
v1.3.6
- Settings icon added for MIDI preferences
- Full MIDI CC channel selection (channels 1-119) per envelope
- MIDI CC device presets (Save/Load Preset in MIDI preferences)
- Envelope display names (Name envelopes in MIDI preferences)
- Selected envelope's display name or channels name will now display below grid
- Keyboard shortcuts added:
- 1-8: Envelope switching
- command (mac) / ctrl (win) + c: Copy envelope
- command (mac) / ctrl (win) + v: Paste envelope
- command (mac) / ctrl (win) + 1: Decrease note interval
- command (mac) / ctrl (win) + 2: Increase note interval
- command (mac) / ctrl (win) + -: Zoom out
- command (mac) / ctrl (win) + =: Zoom in
- p: Power
- v: Vertical inversion
- h: Horizontal inversion
- b: Broadcast MIDI channel for mapping (equivalent to clicking the horn)
- t: Toggle triplet mode
- s: Toggle snap to grid mode
v1.3.5
- Added activation button to Bezie
v1.3.4
- Added MIDI
- Updated to 8 envelopes
- Disable map button while app is running


loyola hacks
for health
+
February 20th | 2016
The 404s --- Hongbin Sun | Morgan Rose | Aaron Bauer
The Null Pointers --- Christian Lanzer | Nieky Allen | Lucasz Borowczak | Aid Idrizović
Team TBD --- Safa Faheem | Ian Cassidy | Keegan Cimler
Trojan.exe --- Eddy Eastwood | Nathnael Alemu | Thomas Hafer
Charlies Angels --- Tara Raj | Mary Makarious | Kate Schoenberger
Zero Experience Necessary --- Allison Kane | Jonah Murray | Ben Lorentz


{% load static %}
The first international scientific conference entitled "Advanced Computer Communications and Informatics", which was held on Saturday and Sunday at the Faculty of Computers and Information, Suez Canal University, under the patronage of Dr. Mamdouh Ghorab, President of the University, recommended activating the role of information technology in developing the economic zone in the Suez Canal axis
The conference, over the course of two days, honored a number of research participants, experts and university professors, and the opening of the conference dealt with several speeches by the conference organizers, and Dr. Abdel Raouf Abdel-Rahman Mustafa, Dean of the Faculty of Computers and Information, stated that the college's first international scientific conference represents a unique move in the field of computers and information technology
Faculty of Computer and Informatics is working on graduating distinguished human cadres capable of competing in the labor market under a system of quality education and applied scientific research directed at community service while keeping pace with technological development within a framework of values and ethics.
| Organizers | Arbitrator | Time | Day | |
|---|---|---|---|---|
| i / Karim El Hawary i / Isra Khaled Mohamed |
Prof. Dr. Jamal Zaher | 18:00 | Sunday 1/31/2021 |
Poetry Competition |
| Dr. Ayoub Al-Otaibi Mr. Shahd Ayman Al-Sayed |
Dr. Ahmed Abdel Wahab | 18:00 | Sunday 1/31/2021 |
Playing Competition |
| i / Mohamed Ibrahim Mubarak | Dr. Basma Mahmoud Ibrahim | 18:00 | Sunday 1/31/2021 |
Singing competition |


Named Gem Sets
rvm gives you compartmentalized independent ruby setups. This means that ruby, gems, irb are all separate and self contained from system and from each other.
You may even have separate named gem sets.
Let's say, for example, that you are testing two versions of a gem with ruby 1.9.1. you can install one to the default 1.9.1 and you can create a named gem set for the other version and switch between them easily.
Example: testing gems
rvm 1.9.1%testing
will use a '1.9.1%testing' gems dir, whereas:
rvm 1.9.1
use the normal 1.9.1 gems dir :)
Example: Rails versions & upgrading apps
To illustrate the point let's talk about a common use case. Let us assume that we are testing out a rails application in order to upgrade it to the latest Rails from a previous version. rvm makes such testing very easy as it lets you quickly switch between multiple rails versions. First let us set up the environments.
rvm 1.9.1 gem install rails # 2.3.3 rvm 1.9.1%rails222 gem install rails -v 2.2.2 rvm 1.8.7%rails126 gem install rails -v 1.2.6 rvm 1.8.7 gem install rails -v 1.2.3
Note that above on each ruby installs you can have a completely separate versions! Now that our environments are setup switching between rails versions and ruby versions is quite simple:
∴ rvm 1.8.7%rails126 ; rails --version Rails 1.2.6 ∴ rvm 1.8.7 ; rails --version Rails 1.2.3 ∴ rvm 1.9.1%rails220 ; rails --version Rails 2.2.0 ∴ rvm 1.9.1 ; rails --version Rails 2.3.3
Warning!!!
* rvm gives you a separate gem directory for each and every ruby version and gem set.* What this means is that gems will have to explicitly installed for each revision and gem set.
Although I recommend against using it, if you are sure you can use 'rvm gemdup default' and 'rvm gemdup system' to clone user default gems and system gems respectively.
Gem Sets with passenger
Documented on the page
Managing gem sets
We can not only use completely separate gem sets per application/project/etc... we can also dump and load them easily.
To switch to a gem set
∴ rvm gems albinochipmunk
To obtain the name of the currently selected gem set
∴ rvm gems albinochipmunk ; rvm gems name albinochipmunk
To obtain the full path to the directory for the currently selected gem set:
∴ rvm gems albinochipmunk; rvm gems dir /Users/wayne/.rvm/gems/ruby/1.9.1%albinochipmunk
To dump a gem set easily, assuming a project called 'albinochipmunk' running on Ruby 1.9.1:
∴ rvm 1.9.1%albinochipmunk dump
will create an 'albinochipmunk.gemset' file.
Alternatively, if you already have a ruby selected
rvm gems dump
You can specify the gemset filename prefix also
rvm gems dump albinochipmunk.gems
A subtle difference with the above command is to leave off the '.gems' which will dump the gems for the gemset named 'mygemsetname'
rvm gems dump albinochipmunk
Loading a gem set
To load this gem set simply do:
∴ rvm 1.9.1%albinochipmunk load
Note that you can use any gem set name to load into.
Alternatively, if you already have a ruby selected:
rvm gems load
You can specify the gemset filename prefix also
rvm gems dump albinochipmunk
You can delete a gem set (the --force makes it not prompt you :) )
rvm gems albinochipmunk ; rvm --force gems delete albinochipmunk"
Loading without arguments first checks for a gemset file with the current gem set name prefix, then checks for 'default.gems' and finally looks for a 'system.gems'.
rvm gems albinochipmunk ; rvm gems load # will look for albinochipmunk.gems first, then default.gems and finally system.gems
To get a list of all named gem sets for the current ruby interpreter / version
rvm gems list
To use a named gem set with a rvm multi action, append it to the ruby selector string using a '%'
rvm 1.9.1%albinochipmunk,ree%albinochipmunk,jruby%albinochipmunk rake test
Alternatively and with less typing this should also work to use 'albinochipmunk' gem set for each interpreter
rvm gems albinochipmunk ; rvm 1.9.1,ree,jruby rake test


| configobj reference pages |
c=CONFIGOBJ() c=CONFIGOBJ(c) c=CONFIGOBJ(struct) c=CONFIGOBJ(filename)
c=CONFIGOBJ() default constructor
c=CONFIGOBJ(c) copy constructor
c=CONFIGOBJ(struct) create configobj from structure.
c=CONFIGOBJ(filename) read configobj from file.
A configobj can be used to create configuration files in a format similar to the windows ini-files. In contrast to ini-files a configobj supports infinitely nested sections and can store and retrieve some (simple) matlab constructs like cells and matrices. Multiple comments and one inline comment can be associated with a section or a variable.
An example configuration file: A = 1 #comment for B B = {'test'} #comment for section LEVEL1 [LEVEL1] #inline comment for LEVEL1 C = [1 2 3] [[LEVEL2]] #nested section D = {'one', 'two', 'three'} #cell array of strings
| config2struct | configobj | display |


@* * This template is called from the `index` template. This template * handles the rendering of the page header and body tags. It takes * two arguments, a `String` for the title of the page and an `Html` * object to insert into the body of the page. *@ @(title: String)(content: Html) @import template._
@* Here's where we render the page title `String`. *@


Image classification is a supervised learning problem: define a set of target classes (objects to identify in images), and train a model to recognize them using labeled example photos.
A video is really just a stack of images. Like image classification, this is also a supervised learning problem where examples can be detected and classified from a Video.


#include <GrPolygonBSPTree.h>
Public Types | |
| typedef std::vector < GrPolygonBSPArea * > | AreaVector |
Public Member Functions | |
| GrPolygonBSPTree () | |
| class header. | |
| GrPolygonBSPTree (const GrPolygonGroup &hullPolygons, const GrPolygonGroup &propPolygons, GrPolygonUberUVMapper &mapper, bool calcPVS=true, bool uberTexture=true, float uberTexelsPerMeter=1024) | |
| GrPolygonBSPTree (UReader &reader) | |
| ~GrPolygonBSPTree () | |
| unsigned int | GetLeafCount () const |
| gets all leaves in the tree. | |
| AreaVector & | GetLeaves () |
| const AreaVector & | GetLeaves () const |
| bool | GetIntersect (MVec3 &hitPos, const MRay &ray, float maxDist) |
| public methods. | |
| void | Build (const GrPolygonGroup &hullPolygons, const GrPolygonGroup &propPolygons, GrPolygonUberUVMapper &mapper, bool calcPVS, bool uberTexture, float uberTexelsPerMeter) |
| builds a new BSP tree from the polygons passed in. | |
| void | GetUberTexData (std::vector< GrPolygonUberPatchGroup * > &dataArray) const |
| packs ubertexture patches into an ubertexture. | |
| GrPolygonBSPSplit * | GetRoot () const |
| returns the root BSP node. | |
| void | Load (UReader &reader) |
| load/save. | |
| void | Save (UWriter &writer) |
Definition at line 31 of file GrPolygonBSPTree.h.
| typedef std::vector< GrPolygonBSPArea* > GrPolygonBSPTree::AreaVector |
Definition at line 34 of file GrPolygonBSPTree.h.
| GrPolygonBSPTree::GrPolygonBSPTree | ( | ) |
class header.
File: GrPolygonBSPTree.cpp Author: Kevin Bray Created: 09-30-06 Copyright © 2004 Bootstrap Studios. All rights reserved. project includes. class GrPolygonBSPTree ctor & dtor
Definition at line 29 of file GrPolygonBSPTree.cpp.
| GrPolygonBSPTree::GrPolygonBSPTree | ( | const GrPolygonGroup & | hullPolygons, | |
| const GrPolygonGroup & | propPolygons, | |||
| GrPolygonUberUVMapper & | mapper, | |||
| bool | calcPVS = true , |
|||
| bool | uberTexture = true , |
|||
| float | uberTexelsPerMeter = 1024 | |||
| ) |
Definition at line 39 of file GrPolygonBSPTree.cpp.
| GrPolygonBSPTree::GrPolygonBSPTree | ( | UReader & | reader | ) |
Definition at line 51 of file GrPolygonBSPTree.cpp.
| GrPolygonBSPTree::~GrPolygonBSPTree | ( | ) |
Definition at line 61 of file GrPolygonBSPTree.cpp.
| void GrPolygonBSPTree::Build | ( | const GrPolygonGroup & | hullPolygons, | |
| const GrPolygonGroup & | propPolygons, | |||
| GrPolygonUberUVMapper & | mapper, | |||
| bool | calcPVS, | |||
| bool | uberTexture, | |||
| float | uberTexelsPerMeter | |||
| ) |
builds a new BSP tree from the polygons passed in.
cleanup the current tree.
create the new BSP node tree.
fill our array of leaves.
tell all leaves to compress their visibility data.
Definition at line 80 of file GrPolygonBSPTree.cpp.
public methods.
finds the point where the given ray hits world geometry. Returns false if no hit was found.
Definition at line 73 of file GrPolygonBSPTree.cpp.
| unsigned int GrPolygonBSPTree::GetLeafCount | ( | ) | const [inline] |
| const AreaVector& GrPolygonBSPTree::GetLeaves | ( | ) | const [inline] |
Definition at line 46 of file GrPolygonBSPTree.h.
| AreaVector& GrPolygonBSPTree::GetLeaves | ( | ) | [inline] |
Definition at line 45 of file GrPolygonBSPTree.h.
| GrPolygonBSPSplit* GrPolygonBSPTree::GetRoot | ( | ) | const [inline] |
| void GrPolygonBSPTree::GetUberTexData | ( | std::vector< GrPolygonUberPatchGroup * > & | dataArray | ) | const |
| void GrPolygonBSPTree::Load | ( | UReader & | reader | ) |
load/save.
cleanup the current tree.
load the BSP node tree.
fill our array of leaves.
Definition at line 120 of file GrPolygonBSPTree.cpp.
| void GrPolygonBSPTree::Save | ( | UWriter & | writer | ) |
Definition at line 134 of file GrPolygonBSPTree.cpp.


Home
Zapdos
Riakou
Ampharos
Jason
9999
1
9999
9999
ABILITY
Code
Hello There! Welcome to the world of Pokemon! My name is Prof. Jason! People call me the pokémon Prof! This world is inhabited by creatures called pokémon!
YOUR NAME?
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
(
)
!
?


About LeadCap
Leadcap is a high-quality manufacturer of Aluminum Roll-On Pilfer-Proof (ROPP) bottle caps to clients in the pharmaceutical, veterinary and agricultural industries. Formerly Filcaps Aluminum Bottle Closures, we are a progressive firm with over twenty (20) years experience in the manufacturing industry. The company applies quality standards in understanding the customers’ needs and in providing packaging solutions.
The company prides itself on understanding its clients' needs, applying quality standards to provide secure and reliable packaging solutions while aiming to deliver products with consistent durability, accurate dimensions and seamless finish.
Our Guarantee
- Conformity with International Regulations
- Guaranteed Highest Quality
- No Deterioration / Evaporation / Pilferage
Leadcap's ROPP screw caps are guaranteed by strict quality control and are manufactured with raw materials that conform with major international regulations for materials in contact with food and drugs.
Our aluminium caps serve as sealing devices fitted on glass bottles that can be broken with a simple twist. The seal ensures that contents remain secure and do not deteriorate or evaporate quickly.
Purpose & Future
Leadcap believes in continuously developing and updating its products and services. It is currently undergoing ISO accreditation under Food Safety Management Systems (ISO 2200, 223 and 9001) as part of its vision to venture into exportation, as well as expand to other types of packaging.
Leadcap Corp. is set to be Philippines' premiere ROPP cap manufacturing company, leadning the industry by providing superior quality products at the highest standard.
To request more information about us, visit our contact page or email us at


I tried my first dose of Meth around August 1996, my life was starting to spiral down around me and things were getting pretty difficult to deal with. My wife (thankfully now ex-wife) was a hard core speed freak, and I the anti-drug. She got me to try it once, and that was all I needed.  It wasn't all that great, put me in a pretty good mood for a few hours, but still enough to get me wanting more.
When I got back home to California (this all started in Florida, as I was leaving the Navy) it really started in earnest, I learned how to purify it to try and minimize the effects of the cut. I went from 165 lbs when I started to a shade under 120 (damned thin for six feet tall!) and my trips lasted longer and longer. Once towards the end I stayed up an entire solid week, rewiring a friend's (also my supplier, seriously good stuff!) Volkswagen bus. By the end of that trip I was so tired and shaky that I was hallucinating more than any LSD ever made me. I didn't even know where I was, just that I was high and fixing something. I was always really laid back, not a care in the world, as long as I had the drug and something to tweak on I was happy.
Then in late December, after hitting rock bottom (and neither noticing nor caring), my girlfriend, one of our mutual friends, and I were in my VW bus in a parking lot (where we all lived at the time) getting very much spun when...bright lights...cops with guns...Miranda rights...oops! They found almost a full 1/8th ounce (8-ball, roughly 4.3 grams) in the van, and that was the end of that story. My GF was extradited out of state for a prior she had there, my friend gave 'em a fake name and was never heard from again, and I got 2 years of probation.
 The worst part is that it screws up the parts of your brain that produce Serotonin, the hormone that makes one happy. So now my brain is perpetually depressed. Up 4 months, down forever.
Best advice to anyone thinking of trying meth, don't. While it's not physically addictive, it's so much fun getting spun that you'll never want to stop, even as your life self destructs. To those currently using it, be careful and please try to quit. The long term effects simply aren't worth it.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


This example demonstrates coupling a quasi stationary circuit with a DC circuit. The QS voltage is rectified (using an ideal AC DC converter), loaded by a variable load conductor. The conversionFactor = DC voltage / AC rms voltage in this case is the root mean square of a rectified sine, i.e., 1. You may compare the quasi stationary results with that of a fully transient model (using a Graetz rectifier), plotting:
It can be seen that at the DC side the current is represented by its averaged value, at the AC side by its rms value.
The quasi stationary model needs a grounding at the QS side as well as the DC side, whereas the transient model may have only one ground since AC side and DC side are connected via the diodes.


|
Bug-reproducer Assistant Python kernel
1.0
Código Python de kernel del Bug-reproducer Assistant
|
Public Member Functions | |
| def | __init__ |
| def | getBackupFileName |
| def | processFile_ |
| def | countAnnotations_ |
| def | countPythonImportsUse_ |
| def | fileHasIncludes_ |
| def | getAllClassesAndFunctionsAnnotations |
| def | getAllClassesAndFunctions |
| def | annotateMainFile |
| def | unAnnotateMainFile |
| def | annotateCppFile |
| def | annotateCppFunctions |
| def | annotateCppClasses |
| def | annotateCppClassFunctions |
| def | annotatePythonObject |
| def | unAnnotateCppFile |
| def | unannotateCppFunctions |
| def | unannotateCppClasses |
| def | unannotateCppClassFunctions |
| def | unAnnotatePythonObject |
| def | addOrRemoveAnnotationsToMainFile_ |
| def | addOrRemoveFileAnnotations_ |
| def | addOrRemoveClassesAnnotations_ |
| def | addOrRemoveFunctionAnnotations_ |
| def | addOrRemoveAnnotations_ |
| def | processGlobalFunctions_ |
| def | processClasses_ |
| def | annotateIncludes_ |
| def | removeIncludes_ |
| def | removePythonImports_ |
Public Attributes | |
| language_ | |
| mainFilePath_ | |
| mainFunction_ | |
| backupFiles_ |
It parses a source code file (Python or C++), and performs actions like adding or removing annotations, or consulting annotations state for classes and functions.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::__init__ | ( | self, | |
| language, | |||
| mainFilePath, | |||
mainFunction = 'main' , |
|||
backupFiles = False |
|||
| ) |
| self | The SourceCodeParser instance to construct. |
| language | The program's programming language. |
| mainFilePath | The program's main file path. |
| mainFunction | The program's main function name. |
| backupFiles | If True, create a backup file before annotating. Constructor. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::addOrRemoveAnnotations_ | ( | self, | |
| doAdd, | |||
| originalFileName, | |||
| resultFileName, | |||
| headerToInclude, | |||
| classNames, | |||
| functionNames, | |||
| processCallback, | |||
| annotateIncludes | |||
| ) |
| self | The SourceCodeParser instance. |
| doAdd | If True, we're adding annotations, else we're removing them. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| classNames | Class names from the file. |
| functionNames | Function names from the file. |
| processCallback | Action to take with the file after annotating the includes. |
| annotateIncludes | If True, annotate the includes. Add or remove annotations to a source file, with a parameter callback to process. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::addOrRemoveAnnotationsToMainFile_ | ( | self, | |
| language, | |||
| doAdd, | |||
dumpFileName = "" |
|||
| ) |
| self | The SourceCodeParser instance. |
| language | The program's programming language. |
| doAdd | If True, we're adding annotations, else we're removing them. |
| dumpFileName | File where the call graph database will be dumped. Add or remove annotations to the program's main file. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::addOrRemoveClassesAnnotations_ | ( | self, | |
| doAdd, | |||
| originalFileName, | |||
| resultFileName, | |||
| headerToInclude, | |||
| classNames, | |||
functionNames = [] , |
|||
annotateIncludes = True |
|||
| ) |
| self | The SourceCodeParser instance. |
| doAdd | If True, we're adding annotations, else we're removing them. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| classNames | Class names from the file. |
| functionNames | Function names from the file. |
| annotateIncludes | If True, annotate the includes. Generic function to add or remove annotations to a source file classes. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::addOrRemoveFileAnnotations_ | ( | self, | |
| doAdd, | |||
| originalFileName, | |||
| resultFileName, | |||
headerToInclude = "" , |
|||
classNames = [] , |
|||
functionNames = [] , |
|||
annotateIncludes = True |
|||
| ) |
| self | The SourceCodeParser instance. |
| doAdd | If True, we're adding annotations, else we're removing them. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| classNames | Class names from the file. |
| functionNames | Function names from the file. |
| annotateIncludes | If True, annotate the includes. Generic function to add or remove annotations to a source file. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::addOrRemoveFunctionAnnotations_ | ( | self, | |
| doAdd, | |||
| originalFileName, | |||
| resultFileName, | |||
| headerToInclude, | |||
| functionNames, | |||
annotateIncludes = True |
|||
| ) |
| self | The SourceCodeParser instance. |
| doAdd | If True, we're adding annotations, else we're removing them. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| functionNames | Global functions to process. |
| annotateIncludes | If True, annotate the includes. Generic function to add or remove annotations to a source file global functions. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::annotateCppClasses | ( | self, | |
| originalFileName, | |||
| resultFileName, | |||
| headerToInclude, | |||
classNames = [] |
|||
| ) |
| self | The SourceCodeParser instance. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| classNames | Classes filter to process. Annotate a C++ source file classes. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::annotateCppClassFunctions | ( | self, | |
| originalFileName, | |||
| resultFileName, | |||
| headerToInclude, | |||
| className, | |||
functionNames = [] |
|||
| ) |
| self | The SourceCodeParser instance. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| className | Class filter to process. |
| functionNames | The classes' member functions to process. Annotate a C++ source file classes member functions. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::annotateCppFile | ( | self, | |
| originalFileName, | |||
| resultFileName, | |||
| headerToInclude | |||
| ) |
| self | The SourceCodeParser instance. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to add the modified lines. |
| headerToInclude | Header to include. Annotate a C++ source file. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::annotateCppFunctions | ( | self, | |
| originalFileName, | |||
| resultFileName, | |||
| headerToInclude, | |||
functionNames = [] |
|||
| ) |
| self | The SourceCodeParser instance. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| functionNames | Global functions filter to process. Annotate a C++ source file global functions. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::annotateIncludes_ | ( | self, | |
| language, | |||
| originalFileName, | |||
| resultFile | |||
| ) |
| self | The SourceCodeParser instance. |
| language | The program's programming language. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFile | Result file to add the modified lines. Add annotation includes to a file. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::annotateMainFile | ( | self, | |
| dumpFileName | |||
| ) |
Add annotations to main file.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::annotatePythonObject | ( | self, | |
| pythonObjectName, | |||
| itsAModule, | |||
functionName = None |
|||
| ) |
| self | The SourceCodeParser instance. |
| pythonObjectName | Name of a Python object to annotate. |
| itsAModule | If true, Python object is a module. |
| functionName | Function to process. Annotate a Python object. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::countAnnotations_ | ( | self, | |
| fileName | |||
| ) |
Count all the "Bug-reproducer Assistant" regions in the file.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::countPythonImportsUse_ | ( | self, | |
| pythonImport | |||
| ) |
Count all the ocurrences of a Python import in the main file.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::fileHasIncludes_ | ( | self, | |
| fileName | |||
| ) |
Return whether or not a file has at least one include.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::getAllClassesAndFunctions | ( | self, | |
| fileName, | |||
headerToInclude = None |
|||
| ) |
Get a file's classes and global functions.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::getAllClassesAndFunctionsAnnotations | ( | self, | |
| fileName, | |||
headerToInclude = None |
|||
| ) |
Get all annotations for a file's classes and global functions.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::getBackupFileName | ( | fileName | ) |
| fileName | File path. |
Return The backup file name path.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::processClasses_ | ( | self, | |
| doAdd, | |||
| myFunctionAnnotator, | |||
| originalFileName, | |||
| resultFile, | |||
| headerToInclude, | |||
| classNames, | |||
functionNames = [] |
|||
| ) |
| self | The SourceCodeParser instance. |
| doAdd | If True, we're adding annotations, else we're removing them. |
| myFunctionAnnotator | Action instance that actually annotates. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFile | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| classNames | Class names from the file. |
| functionNames | Function names from the file. Add or remove annotations to a source file classes. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::processFile_ | ( | self, | |
| fileName, | |||
| aLineProcessor | |||
| ) |
Generic function to process a file, applying a "Line Processor" to every line.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::processGlobalFunctions_ | ( | self, | |
| doAdd, | |||
| myFunctionAnnotator, | |||
| originalFileName, | |||
| resultFile, | |||
| headerToInclude, | |||
| _, | |||
| functionNames | |||
| ) |
| self | The SourceCodeParser instance. |
| doAdd | If True, we're adding annotations, else we're removing them. |
| myFunctionAnnotator | Action instance that actually annotates. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFile | Result file to add the modified lines. |
| headerToInclude | Header to include. |
| functionNames | Function names from the file. Add or remove annotations to a source file global functions. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::removeIncludes_ | ( | self, | |
| fileName | |||
| ) |
| self | The SourceCodeParser instance. |
| fileName | File where the includes will be removed. Remove #includes from a file. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::removePythonImports_ | ( | self, | |
| pythonImport | |||
| ) |
| self | The SourceCodeParser instance. |
| pythonImport | Python import to remove. Remove a Python from the main file. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::unannotateCppClasses | ( | self, | |
| originalFileName, | |||
| resultFileName, | |||
classNames = [] |
|||
| ) |
| self | The SourceCodeParser instance. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to remove the annotations to. |
| classNames | Class names to process. Remove annotations from a C++ source file, filtering the classes. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::unannotateCppClassFunctions | ( | self, | |
| originalFileName, | |||
| resultFileName, | |||
| className, | |||
functionNames = [] |
|||
| ) |
| self | The SourceCodeParser instance. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to remove the annotations to. |
| className | Class name to process. |
| functionNames | Member function names to process. Remove annotations from a C++ source file, filtering the classes and their member functions. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::unAnnotateCppFile | ( | self, | |
| originalFileName, | |||
| resultFileName | |||
| ) |
| self | The SourceCodeParser instance. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to remove the annotations to. Remove annotations from a C++ source file. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::unannotateCppFunctions | ( | self, | |
| originalFileName, | |||
| resultFileName, | |||
functionNames = [] |
|||
| ) |
| self | The SourceCodeParser instance. |
| originalFileName | File name of the original (unprocessed) file name. |
| resultFileName | Result file to remove the annotations to. |
| functionNames | Global functions to process. Remove annotations from a C++ source file, filtering the global functions. |
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::unAnnotateMainFile | ( | self | ) |
Remove annotations from main file.
| def bug_reproducer_assistant::source_code_parser::SourceCodeParser::unAnnotatePythonObject | ( | self, | |
| pythonObjectName, | |||
| itsAModule, | |||
functionName = None |
|||
| ) |
| pythonObjectName | Name of a Python object to unannotate. |
| itsAModule | If true, Python object is a module. |
| functionName | Function to process. Unannotate a Python object. |


Class ImportProductSetsResponse (v2.2.2)
Response message for the ImportProductSets
method.
This message is returned by the google.longrunning.Operations.GetOperation method in the returned google.longrunning.Operation.response field.
Generated from protobuf message google.cloud.vision.v1.ImportProductSetsResponse
Methods
__construct
Constructor.
| Name | Description |
| data |
array
Optional. Data for populating the Message object. |
| ↳ reference_images |
array<Google\Cloud\Vision\V1\ReferenceImage>
The list of reference_images that are imported successfully. |
| ↳ statuses |
array<Google\Rpc\Status>
The rpc status for each ImportProductSet request, including both successes and errors. The number of statuses here matches the number of lines in the csv file, and statuses[i] stores the success or failure status of processing the i-th line of the csv, starting from line 0. |
getReferenceImages
The list of reference_images that are imported successfully.
Generated from protobuf field repeated .google.cloud.vision.v1.ReferenceImage reference_images = 1;
| Type | Description |
| Google\Protobuf\Internal\RepeatedField |
setReferenceImages
The list of reference_images that are imported successfully.
Generated from protobuf field repeated .google.cloud.vision.v1.ReferenceImage reference_images = 1;
| Name | Description |
| var |
array<Google\Cloud\Vision\V1\ReferenceImage>
|
| Type | Description |
| $this |
getStatuses
The rpc status for each ImportProductSet request, including both successes and errors.
The number of statuses here matches the number of lines in the csv file, and statuses[i] stores the success or failure status of processing the i-th line of the csv, starting from line 0.
Generated from protobuf field repeated .google.rpc.Status statuses = 2;
| Type | Description |
| Google\Protobuf\Internal\RepeatedField |
setStatuses
The rpc status for each ImportProductSet request, including both successes and errors.
The number of statuses here matches the number of lines in the csv file, and statuses[i] stores the success or failure status of processing the i-th line of the csv, starting from line 0.
Generated from protobuf field repeated .google.rpc.Status statuses = 2;
| Name | Description |
| var |
array<Google\Rpc\Status>
|
| Type | Description |
| $this |


lzw and gif explained----steve blackstock
¡¡i hope this little document will help enlighten those of you out there who want to know more about the lempel-ziv welch compression algorithm, and, specifically, the implementation that gif uses. before we start, here's a little terminology, for the purposes of this document: "character": a fundamental data element. in normal text files, this is just a single byte. in raster images, which is what we're interested in, it's an index that specifies the color of a given pixel. i'll refer to an arbitray character as "k". "charstream": a stream of characters, as in a data file. "string": a number of continuous characters, anywhere from one to very many characters in length. i can specify an arbitrary string as "[...]k". "prefix": almost the same as a string, but with the implication that a prefix immediately precedes a character, and a prefix can have a length of zero. so, a prefix and a character make up a string. i will refer to an arbitrary prefix as "[...]". "root": a single-character string. for most purposes, this is a character, but we may occasionally make a distinction. it is [...]k, where [...] is empty. "code": a number, specified by a known number of bits, which maps to a string. "codestream": the output stream of codes, as in the "raster data" "entry": a code and its string. "string table": a list of entries; usually, but not necessarily, unique. that should be enough of that. lzw is a way of compressing data that takes advantage of repetition of strings in the data. since raster data usually contains a lot of this repetition, lzw is a good way of compressing and decompressing it. for the moment, lets consider normal lzw encoding and decoding. gif's variation on the concept is just an extension from there. lzw manipulates three objects in both compression and decompression: the charstream, the codestream, and the string table. in compression, the charstream is the input and the codestream is the output. in decompression, the codestream is the input and the charstream is the output. the string table is a product of both compression and decompression, but is never passed from one to the other. the first thing we do in lzw compression is initialize our string table. to do this, we need to choose a code size (how many bits) and know how many values our characters can possibly take. let's say our code size is 12 bits, meaning we can store 0->fff, or 4096 entries in our string table. lets also say that we have 32 possible different characters. (this corresponds to, say, a picture in which there are 32 different colors possible for each pixel.) to initialize the table, we set code#0 to character#0, code #1 to character#1, and so on, until code#31 to character#31. actually, we are specifying that each code from 0 to 31 maps to a root. there will be no more entries in the table that have this property. now we start compressing data. let's first define something called the "current prefix". it's just a prefix that we'll store things in and compare things to now and then. i will refer to it as "[.c.]". initially, the current prefix has nothing in it. let's also define a "current string", which will be the current prefix plus the next character in the charstream. i will refer to the current string as "[.c.]k", where k is some character. ok, look at the first character in the charstream. call it p. make [.c.]p the current string. (at this point, of course, it's just the root p.) now search through the string table to see if [.c.]p appears in it. of course, it does now, because our string table is initialized to have all roots. so we don't do anything. now make [.c.]p the current prefix. look at the next character in the charstream. call it q. add it to the current prefix to form [.c.]q, the current string. now search through the string table to see if [.c.]q appears in it. in this case, of course, it doesn't. aha! now we get to do something. add [.c.]q (which is pq in this case) to the string table for code#32, and output the code for [.c.] to the codestream. now start over again with the current prefix being just the root p. keep adding characters to [.c.] to form [.c.]k, until you can't find [.c.]k in the string table. then output the code for [.c.] and add [.c.]k to the string table. in pseudo-code, the algorithm goes something like this: [1] initialize string table; [2] [.c.] <- empty; [3] k <- next character in charstream; [4] is [.c.]k in string table? (yes: [.c.] <- [.c.]k; go to [3]; ) (no: add [.c.]k to the string table; output the code for [.c.] to the codestream; [.c.] <- k; go to [3]; ) it's as simple as that! of course, when you get to step [3] and there aren't any more characters left, you just output the code for [.c.] and throw the table away. you're done. wanna do an example? let's pretend we have a four-character alphabet: a,b,c,d. the charstream looks like abacaba. let's compress it. first, we initialize our string table to: #0=a, #1=b, #2=c, #3=d. the first character is a, which is in the string table, so [.c.] becomes a. next we get ab, which is not in the table, so we output code #0 (for [.c.]), and add ab to the string table as code #4. [.c.] becomes b. next we get [.c.]a = ba, which is not in the string table, so output code #1, and add ba to the string table as code #5. [.c.] becomes a. next we get ac, which is not in the string table. output code #0, and add ac to the string table as code #6. now [.c.] becomes c. next we get [.c.]a = ca, which is not in the table. output #2 for c, and add ca to table as code#7. now [.c.] becomes a. next we get ab, which is in the string table, so [.c.] gets ab, and we look at aba, which is not in the string table, so output the code for ab, which is #4, and add aba to the string table as code #8. [.c.] becomes a. we can't get any more characters, so we just output #0 for the code for a, and we're done. so, the codestream is #0#1#0#2#4#0. a few words (four) should be said here about efficiency: use a hashing strategy. the search through the string table can be computationally intensive, and some hashing is well worth the effort. also, note that "straight lzw" compression runs the risk of overflowing the string table - getting to a code which can't be represented in the number of bits you've set aside for codes. there are several ways of dealing with this problem, and gif implements a very clever one, but we'll get to that. an important thing to notice is that, at any point during the compression, if [...]k is in the string table, [...] is there also. this fact suggests an efficient method for storing strings in the table. rather than store the entire string of k's in the table, realize that any string can be expressed as a prefix plus a character: [...]k. if we're about to store [...]k in the table, we know that [...] is already there, so we can just store the code for [...] plus the final character k. ok, that takes care of compression. decompression is perhaps more difficult conceptually, but it is really easier to program. here's how it goes: we again have to start with an initialized string table. this table comes from what knowledge we have about the charstream that we will eventually get, like what possible values the characters can take. in gif files, this information is in the header as the number of possible pixel values. the beauty of lzw, though, is that this is all we need to know. we will build the rest of the string table as we decompress the codestream. the compression is done in such a way that we will never encounter a code in the codestream that we can't translate into a string. we need to define something called a "current code", which i will refer to as "<code>", and an "old-code", which i will refer to as "<old>". to start things off, look at the first code. this is now <code>. this code will be in the intialized string table as the code for a root. output the root to the charstream. make this code the old-code <old>. *now look at the next code, and make it <code>. it is possible that this code will not be in the string table, but let's assume for now that it is. output the string corresponding to <code> to the codestream. now find the first character in the string you just translated. call this k. add this to the prefix [...] generated by <old> to form a new string [...]k. add this string [...]k to the string table, and set the old-code <old> to the current code <code>. repeat from where i typed the asterisk, and you're all set. read this paragraph again if you just skimmed it!!! now let's consider the possibility that <code> is not in the string table. think back to compression, and try to understand what happens when you have a string like p[...]p[...]pq appear in the charstream. suppose p[...] is already in the string table, but p[...]p is not. the compressor will parse out p[...], and find that p[...]p is not in the string table. it will output the code for p[...], and add p[...]p to the string table. then it will get up to p[...]p for the next string, and find that p[...]p is in the table, as the code just added. so it will output the code for p[...]p if it finds that p[...]pq is not in the table. the decompressor is always "one step behind" the compressor. when the decompressor sees the code for p[...]p, it will not have added that code to it's string table yet because it needed the beginning character of p[...]p to add to the string for the last code, p[...], to form the code for p[...]p. however, when a decompressor finds a code that it doesn't know yet, it will always be the very next one to be added to the string table. so it can guess at what the string for the code should be, and, in fact, it will always be correct. if i am a decompressor, and i see code#124, and yet my string table has entries only up to code#123, i can figure out what code#124 must be, add it to my string table, and output the string. if code#123 generated the string, which i will refer to here as a prefix, [...], then code#124, in this special case, will be [...] plus the first character of [...]. so just add the first character of [...] to the end of itself. not too bad. as an example (and a very common one) of this special case, let's assume we have a raster image in which the first three pixels have the same color value. that is, my charstream looks like: qqq.... for the sake of argument, let's say we have 32 colors, and q is the color#12. the compressor will generate the code sequence 12,32,.... (if you don't know why, take a minute to understand it.) remember that #32 is not in the initial table, which goes from #0 to #31. the decompressor will see #12 and translate it just fine as color q. then it will see #32 and not yet know what that means. but if it thinks about it long enough, it can figure out that qq should be entry#32 in the table and qq should be the next string output. so the decompression pseudo-code goes something like: [1] initialize string table; [2] get first code: <code>; [3] output the string for <code> to the charstream; [4] <old> = <code>; [5] <code> <- next code in codestream; [6] does <code> exist in the string table? (yes: output the string for <code> to the charstream; [...] <- translation for <old>; k <- first character of translation for <code>; add [...]k to the string table; <old> <- <code>; ) (no: [...] <- translation for <old>; k <- first character of [...]; output [...]k to charstream and add it to string table; <old> <- <code> ) [7] go to [5]; again, when you get to step [5] and there are no more codes, you're finished. outputting of strings, and finding of initial characters in strings are efficiency problems all to themselves, but i'm not going to suggest ways to do them here. half the fun of programming is figuring these things out! --- now for the gif variations on the theme. in part of the header of a gif file, there is a field, in the raster data stream, called "code size". this is a very misleading name for the field, but we have to live with it. what it is really is the "root size". the actual size, in bits, of the compression codes actually changes during compression/decompression, and i will refer to that size here as the "compression size". the initial table is just the codes for all the roots, as usual, but two special codes are added on top of those. suppose you have a "code size", which is usually the number of bits per pixel in the image, of n. if the number of bits/pixel is one, then n must be 2: the roots take up slots #0 and #1 in the initial table, and the two special codes will take up slots #4 and #5. in any other case, n is the number of bits per pixel, and the roots take up slots #0 through #(2**n-1), and the special codes are (2**n) and (2**n + 1). the initial compression size will be n+1 bits per code. if you're encoding, you output the codes (n+1) bits at a time to start with, and if you're decoding, you grab (n+1) bits from the codestream at a time. as for the special codes: <cc> or the clear code, is (2**n), and <eoi>, or end-of-information, is (2**n + 1). <cc> tells the compressor to re- initialize the string table, and to reset the compression size to (n+1). <eoi> means there's no more in the codestream. if you're encoding or decoding, you should start adding things to the string table at <cc> + 2. if you're encoding, you should output <cc> as the very first code, and then whenever after that you reach code #4095 (hex fff), because gif does not allow compression sizes to be greater than 12 bits. if you're decoding, you should reinitialize your string table when you observe <cc>. the variable compression sizes are really no big deal. if you're encoding, you start with a compression size of (n+1) bits, and, whenever you output the code (2**(compression size)-1), you bump the compression size up one bit. so the next code you output will be one bit longer. remember that the largest compression size is 12 bits, corresponding to a code of 4095. if you get that far, you must output <cc> as the next code, and start over. if you're decoding, you must increase your compression size as soon as you write entry #(2**(compression size) - 1) to the string table. the next code you read will be one bit longer. don't make the mistake of waiting until you need to add the code (2**compression size) to the table. you'll have already missed a bit from the last code. the packaging of codes into a bitsream for the raster data is also a potential stumbling block for the novice encoder or decoder. the lowest order bit in the code should coincide with the lowest available bit in the first available byte in the codestream. for example, if you're starting with 5-bit compression codes, and your first three codes are, say, <abcde>, <fghij>, <klmno>, where e, j, and o are bit#0, then your codestream will start off like: byte#0: hijabcde byte#1: .klmnofg so the differences between straight lzw and gif lzw are: two additional special codes and variable compression sizes. if you understand lzw, and you understand those variations, you understand it all! just as sort of a p.s., you may have noticed that a compressor has a little bit of flexibility at compression time. i specified a "greedy" approach to the compression, grabbing as many characters as possible before outputting codes. this is, in fact, the standard lzw way of doing things, and it will yield the best compression ratio. but there's no rule saying you can't stop anywhere along the line and just output the code for the current prefix, whether it's already in the table or not, and add that string plus the next character to the string table. there are various reasons for wanting to do this, especially if the strings get extremely long and make hashing difficult. if you need to, do it. hope this helps out.----steve blackstock |


About Currency Converter
Convert one currency to another. It's that simple.
Currency Converter is a simple web app made for #7DaysofCodeChallenge — an initiative of the Google Africa Scholarship challenge course organized in conjuction with Andela Learning Community
About the challenge
7 Days of Code Challenge is an individual project/program completion task for the ALC learners. The goal is to:
- determine your overall progress in the ALC program, and identify the top 100 learners from this track
- To test the skills learned by learners and certify the top learners at the end of the program.
Freecurrencyconverterapi is an API that converts one currency to another and returns result in json format.
You are required to implement a front-end application that takes advantage of the functionalities Freecurrencyconverterapi provides. The application should be able convert one currency to another while offline or online.
Challenge requirements
- All Javascript MUST be written in >=ES6
- Use Github repository for version control.
- Host a working version of the application on Github-Pages.
- The application must make use of the following:
- Service Worker
- Cache API
- IndexedDB
- You are not to use any service worker library
Application Functions
At minimum users should be able to:
- Select currencies to be converted from and to
- Convert currencies while the application is online or offline
Solution to challenge
Requirements
Browser support: Latest versions of Chrome and Firefox
Built With
- Bulma framework - https://bulma.io
Getting Started
- Clone repo
git clone http://github.com/williamukoh/currency-converter
- Run
npm install
to install dependencies
Running solution
- Ensure you're in the root directory of project
- Run
npm start
and browse tohttp://localhost:3000
to view project - To deploy to Github pages, run
npm run deploy
and visithttp://<GITHUB-USERNAME>.github.com/currency-converter
License
Solution to challenge is licensed under the MIT License - see the LICENSE file for details.
Author
@williamukoh. Proudly 🇳🇬


{{/* FIXME This won't change for dark themes :-( */}}
{{ if .GolferInfo }}
{{ else }}
{{ end }}
{{/* TODO Kill JSExt, make codemirror a real module imported from hole.js */}}
{{ with .JSExt }}{{ end }}
{{/* type=module acts like defer, even on inline scripts */}}
Your account will be permanently deleted on the {{ .Delete.Value.Format "2 Jan 2006" }}.
If you wish to stop this, visit settings and cancel the deletion.
The {{ .Trophy.Emoji }} {{ .Trophy.Name }} trophy will {{ if .During }} stop being available in {{ time .End }}. {{ else }} be available in {{ time .Start }}. {{ end }}


Defining and filling METAL slots
metal:define-slot
Attribute syntax
metal:define-slot="SLOTNAME"
Remarks
Only valid when defined on a child element of an element decorated with
metal:define-macro
or when decorating a
child element of an element decorated fill-slot
, within an element decorated
metal:extend-macro
. Indicates that the
element and its children constitute a named extension point for the current macro. The slot uses the given name
(SLOTNAME).
metal:fill-slot
Attribute syntax
metal:fill-slot="SLOTNAME"
Remarks
Only valid when defined on a child element of an element decorated with
metal:use-macro
or
metal:extend-macro
. When the use-macro element is
replaced with the macro, the referenced macro is searched for a slot (indicated by define-slot
)
with a name matching SLOTNAME. If a matching slot is found then the define-slot element (and its
children) is replaced with the fill-slot element and its children.
Slot-filling example
The following example shows a macro which represents an

element. It provides a
standard markup structure, including an actions menu. The markup for the heading and content are supplied from
the location at which the macro is used, using slots.

Title goes here

Article content goes here

Upvote

Downvote

Share

Report

Filling slots

The slot filler content can include markup and
TAL statements.

Filling slots

The slot filler content can include markup and
TAL statements.

Upvote

Downvote

Share

Report