The SWI-Prolog website (http:www.swi-prolog.org) is written in Prolog and integrates PlDoc to provide a comprehensive searchable http://www.swi-prolog.org/pldoc/index.htmlonline manual .
Version 2 of PlDoc extends the syntax with http://en.wikipedia.org/wiki/MarkdownMarkdown markup as specified by http://www.stack.nl/ dimitri/doxygen/Docygen. Based on experience with version 1, PlDoc 2 both tightens some rules to avoid misinterpretations and relaxes others that were considered too conservative.
When developing Prolog source that has to be maintained for a longer period or is developed by a ---possibly distributed--- team some basic quality mechanisms need to be adopted. A shared and well designed codingstyle Covington et al., 2012 is one of them. In addition, documentation of source-files and their primary interfaces as well as a testing framework must be established.
In our view, hitherto existing documentation and testing frameworks fell short realising the basic needs in a lightweight and easy to adopt system. To encourage consistent style, well commented code and test-assisted development, we make sure that
First, we describe the documentation system we developed for SWI-Prolog. In section 11 we motivate our main choices.
Like JavaDoc, the PlDoc infrastructure is based on structured
comments. Using comments, no changes have to be made to Prolog to
load the documented source. If the library(pldoc)
library
is loaded, Prolog will not only load the source, but also parse all
structured comments. It processes the mode-declarations inside the
comments and stores these as annotations in the Prolog database to
support the test framework and other runtime and compiletime analysis
tools that may be developed in the future.
Documentation for all or some of the loaded files can be written to file in either HTML+CSS or LaTeX (see section 10.5) format. Each source file is documented in a single file. In addition, the documentation generator will generate an index file that can be used as an index for a browser or input file for LaTeX for producing nicely typeset document.
To support the developer, the documentation system can be asked to start a web-server that can be used to browse the documentation.
Structured comments come in two flavours, the line-comment (%) based
one, seen mostly in the Prolog community and the block-comment (/*
...*/
)
based one, commonly seen in the Java and C domains. As we cannot
determine the argument names, type and modes from following (predicate)
source itself, we must supply this in the comment.1See section
11. The overall structure of the comment therefore is:
@
keyword value, see section
6)
The /*
...*/
style comment starts with
/**
<white>. The type and mode declarations start at
the first non-blank line and are ended by a blank line.
The %
-style line comments start with %!
<white>
or, for compatibility reasons, with %%
<white>.2The %%
leader was considered to give too many false positives on arbitrary
source code. It is still accepted, but invalid comments are silently
ignored, while invalid comments that start with %!
result
in a warning. The type and mode declaration is ended by the
first line that starts with a single %. E.g., the following two
fragments are identical wrt. PlDoc. Skipping blank-lines in /**
comments allows to start the comment on the second line.
%! predicate(-Arg:type) is nondet % Predicate ...
/** * predicate(-Arg:type) is nondet * * Predicate ... */
The JavaDoc style keyword list starts at the first line starting with @<word>.
An important aspect is documentation of the file or module as a whole, explaining its design, purpose and relation to other modules. In JavaDoc this is the comment that preceeds the class definition. The Prolog equivalent would be to put the module comment in front of the module declaration. The module declaration itself however is an important index to the content of the file and is therefore best kept first.
The general comment-structure for module comments is to use a type
identifier between angled brackets, followed by the title of the
section. Currently the only type provided is module
. Other
types may be added later.
/** <module> Prolog documentation processor This module processes structured comments and generates both formal mode declarations from them as well as documentation in the form of HTML or LaTeX. @author Jan Wielemaker @license GPL */
Many predicates can sensibly be called in different ways, e.g. with a specific argument as input or as output. The header of the documentation of a predicate consists of one or more templates, each representing a specific way of calling the predicate.
A template can contain information about types, argument instantiation patterns, determinism and more. The syntax is informally described below:
| <template> | ::= | ['//'] 'is' <determinism> |
| | | ['//'] | |
| <determinism> | ::= | 'det' |
| | | 'semidet' | |
| | | 'failure' | |
| | | 'nondet' | |
| | | 'multi' | |
|  | ::= | <functor>'('<argspec> ',' <argspec>')' |
| | | <functor> | |
| <argspec> | ::= | [<instantiation>]<argname>[':'<type>] |
| <instantiation> | ::= | '++' | '+' | '-' | '--' | '?' | ':' | '@' | '!' |
| <type> | ::= | <term> |
The determinism values originate from Mercury. Their meaning
is explained in the table below. Informally, det
is used
for deterministic transformations (e.g. arithmetic), semidet
for tests, nondet
and multi
for generators.
The
failure
indicator is rarely used. It mostly appears in
hooks or the recovery goal of catch/3.
| Determinism | Predicate behaviour |
det | Succeeds exactly once without a choice point |
semidet | Fails or Succeeds exactly once without a choice-point |
failure | Always fails |
nondet | No constraints on the number of times the predicate succeeds and whether or not it leaves choice-points on the last success. |
multi | As nondet ,
but succeeds at least one time. |
The meanings of the instantiation patterns for individual arguments are:
Users should be aware that calling a predicate with arguments instantiated in a way other than specified by one of the templates may result in errors or unexpected behavior.
Developers should ensure that predicates are steadfast with respect to output arguments (marked - in the template). This means that instantiation of output arguments at call-time does not change the semantics of the goal (it may be used for optimization, though). If this steadfast behavior cannot be guaranteed, -- should be used instead.
In the current version, argument types are represented by an arbitrary term without formal semantics. In future versions we may adopt a formal type system that allows for runtime verification and static type analysis Hermenegildo, 2000, Mycroft & O'Keefe, 1984, Jeffery et al., 2000
%! length(+List:list, -Length:int) is det. %! length(?List:list, -Length:int) is nondet. %! length(?List:list, +Length:int) is det. % % True if List is a list of length Length. % % @compat iso
@
see,
etc.Optionally, the description may be followed by one or more tags. Our tag convention is strongly based on the conventions used by javaDoc. It is adviced to place tags in the order they are described below.
@
arg Name Description@arg
tag. The first word is the name of the argument. The remainder of the
tag is the description. Arguments declarations normally appear in order
used by the predicate.@
param Name Description@arg
, using the JavaDoc tag name.@
throws Term Description@
error Error Description@
throws, but the exception is embedded in error(Error,
Context)
.@
author Name@
version Version@
see Text@
deprecated Alternative@
compat Standards and systems@
copyright Copyright holder@
license License conditions@
bug Bug description@
tbd Work to be doneStructured comments that provide part of the documentation are written in Wiki notation, based on http://www.twiki.orgTWiki, with some Prolog specific additions.
blockquote
element and in LaTeX using the
quote
environment. Finally, if the initial indentation is
16 or more, the paragraph is centered.ul
), numbered lists (HTML ol
) and
description lists (HTML dl
). Each list environment
is headed by an empty line and each list-item has a special symbol at
the start, followed by a space. Each subsequent item must be indented at
exactly the same column. Lists may be nested by starting a new list at a
higher level of indentation. The list prefixes are:
* | Bulleted list item |
1. | Numbered list item. Any number from 1..9 is allowed, which allows for proper numbering in the source. Actual numbers in the HTML or LaTeX however are re-generated, starting at 1. |
$ Title : Item | Description list item. |
' . '
to the
text and reads it using the operator definitions also used to read the
mode terms. See section 5. Variable
names encountered in the Term are used for indentifying
variables in the following
Description. At least one Description must be
non-empty to avoid confusion with a simple item list.
* Term1 Description * Term2 Description
The following predicates are considered Prolog's prime list processing primitives: * [[member/2]] * [[append/3]]
|
sign and the cells are
separated by the same character. The last cell must be ended with |
.
Multiple lines that parse into a table-row together form a table.
Example:
| Algorithm | Time (sec) | | Depth first | 1.0 | | Breath first | 0.7 | | A* | 0.3 |
---+ Section level 1 ---++ Section level 2 ---+++ Section level 3 ---++++ Section level 4
In addition, PlDoc recognises the markdown syntax, including
named sections as defined by doxygen. A section is named
(labeled) using an optional sequence {\#
name}
.
The three code sections below provide examples. Note that #
section headers should be positioned at the left margin and the
#
must be followed by blank space. If the header is
underlined, the underline is a line that only contains
or
=
characters. There must be a minimum of three4Markdown
demands two, but this results in ambiguities with the -
fence for code blocks. of such characters.
==
Section level 1 =============== Section level 2 ---------------
# Section level 1 ## Section level 2 ### Section level 3 #### Section level 4
Section level 1 {#label} =============== # Section level 1 {#label}
==
. Doxygen fence
lines are also accepted. They contain at least three tilde (~
)
characters, where the opening fence line may be followed by a file
extension between curly brackets. In all cases, the code is indented
relative to the indentation of the fence line. Below are two examples,
the first being the traditional PlDoc style. The second is the Doxygen
style, showing a code block that is indented (because it is a body
fragment) and that is flagged as Prolog source. Note that the
{.pl}
is optional.
== small(X) :- X < 2. ==
~~~{.pl} ..., format('Hello ~w~n', [World]), ..., ~~~
The second form of code blocks are indented blocks. Such a
block must be indented between 4 and 8 characters, relative to the
indentation of the last preceeding non-blank line. The block is opened
with a blank line and closed by a blank line or a line that is indented
less than the indentation of the initial line. It is allowed to have a
single blank line in the middle of a code block, provided that the next
line is again indented at least as much as the initial line. The initial
line as well as a line that follows a blank line may not be a valid list
opening line or a table row, i.e., it may not start with one of
*-
followed by a space or |
.
_
) or asterisk (*
). Below are
three examples, the last two of which are valid markdown.
-- *** - - -

or

.5The
markdown conventions are (original) two spaces at the of the physical
line and (GitHub) a physical line break. Neither fit well with source
code. Doxygen supports restricted HTML and allows for

.
Text emphasis is a combination of old plaintext conventions in Usenet and E-mail and the doxygen version of markdown. Table 1 shows the font-changing constructions. The phrase limited context means that
*
or _
must be
preceeded by white space or a character from the set <{([,:;
and must be followed by an alphanumerical character.
*
or _
may not be
followed by an alphanumerical character and may not be preceeded by
white space or a character from the set ({[<=+-\@
.
Note that =
<identifier>=
is limited
to a an
identifier, such as a file name, XML name, etc. Identifiers
must start and end with an alphanumerical character, while characters
from the set .-/:
may appear internally. Note that this set
explicitly does not allow for white space in code spans delimited by a
single
. This markup is specifically meant to
deal with code that is either not Prolog code or invalid Prolog code.
Valid Prolog code should use the backtick as described in section
7.2.2.
=
*bold* | Typeset text in bold for limited content (see running text). |
*|bold|* | Typeset text in bold. Content can be long. |
_emphasize_ | Typeset text as emphasize for limited content (see running text). |
_|emphasize|_ | Typeset text as emphasize. Content can be long. |
=code= | Typeset text fixed
font for identifiers (see running text). |
=|code|= | Typeset text fixed
font. Content can be long. |
Word | Capitalised words that appear as argument-name are written in Italic |
Inline code can be realised using the =
switch described
in
section 7.2.1 or the markdown
backtick. In addition, it can use the mardown/Doxygen backtick
(`
) convention: a string that is delimited by backticks is
considered code, provided:
Currently, `Var` is typeset as a variable (italics) and other terms are typeset using a fixed-width code font.
In addition, compound terms in canonical notation (i.e.,
functor(
,...args...)
that can be
parsed are first verified as a file-specification for
absolute_file_name/3
and otherwise rendered as code.
Table 2 shows the constructs for creating links.
Images can be included in the documentation by referencing an image
file using one of the extensions .gif
, .png
,
.jpeg
, .jpg
or .svg
.6SVG
images are included using the object
element. This is
supported by many modern browsers. When using IE, one needs at least
IE9. By default this creates a link to the image file that
must be visited to see the image. Inline images can be created by
enclosing the filename in double square brackets. For example
The [[open.png]] icon is used open an existing file.
The markdown alternative for images is also supported, and looks as below. The current implementation only deals with image files, not external resources.
![Caption](File)
A directory index consists of the contents of the file README
(or README.TXT
), followed by a table holding all currently
loaded source-files that appear below the given directory (i.e. traversal
is
recursive) and for each file a list of public predicates and
their descriptive summary. Finally, if a file TODO
or TODO.TXT
exists, its content is added at the end of the directory index.
Sometimes it is desirable to document aspects of a package outside
the source-files. For this reason the system creates a link to files
using the extension .txt
. The referenced file is processed
as Wiki source. The two fragments below illustrate the relation between
an
.pl
file and a .txt
file.
%! read_setup(+File, -Setup) is det. % % Read application setup information from File. The details % on setup are described in setup.txt.
---+ Application setup data If a file =|.myapprc|= exists in the user's home directory the application will process this data using setup.pl. ...
To support the developer with an up-to-date version of the
documentation of both the application under development and the system
libraries the developer can start an HTTP documentation server using the
command
doc_server(?Port)
. A good way to deploy PlDoc for program
development is to write a file called e.g., debug.pl
that
sets up the preferred development environment and loads your program.
below is an example debug.pl
that starts PlDoc and prints
strings as text before loading the remainder of your program.
:- doc_server(4000). % Start PlDoc at port 4000 :- portray_text(true). % Enable portray of strings :- [load]. % load your program
doc_server(Port, [allow(localhost), workers(1)])
. This
predicate must be called before loading the program for which
you consult the documentation. It calls doc_collect/1
to start collecting documentation while (re-)loading your program./
. Path
must be an absolute URL location, starting with /
and ending in /
. Intented for public services
behind a reverse proxy. See documentation of the HTTP package for
details on using reverse proxies.false
, do not allow editing, even if the connection
comes from localhost. Intended together with the root
option to make pldoc available from behind a reverse proxy. See the HTTP
package for configuring a Prolog server behind an
http://httpd.apache.org/docs/1.3/mod/mod_proxy.htmlApache reverse proxy
.allow('.uva.nl')
grants access to all machines in this domain. IP addresses are specified
using the library(socket) ip/4
term. I.e. to allow access from the 10.0.0.X domain, specify
allow(ip(10,0,0,_))
.allow
option.
Access is granted iff
The library library(pldoc/doc_library)
defines doc_load_library/0
to load the entire library.
:- doc_server(4000, [ allow('.my.org') ]). :- use_module(library(pldoc/doc_library)). :- doc_load_library.
Example code can be found in $PLBASE/doc/packages/examples/pldoc
.
The documentation system is normally accessed from a web-browser after starting the server using doc_server/1. This section briefly explains the user-interface provided from the browser.
The top-right of the screen provides a search-form. The search string
typed is searched as a substring and case-insensitive. Multiple strings
seperated by spaces search for the intersection. Searching for objects
that do not contain a string is written as
<string>.
A search for adjacent strings is specified as -
"
<string>"
.
Here are some examples:
load file | Searches for all
objects with the strings
load and file . |
load -file | Searches for
objects with load , but
without file . |
"load file" | Searches for the
string load file . |
The two radio-buttons below the search box can be used to limit the search. All searches both the application and manuals. Searching for Summary also implies Name.
The web-browser supports several views, which we briefly summarise here:
README
and TODO
files is
given.
/** <module ... */
comment and the public
predicates with their full documentation. Using the zoom button
the user can select to view both public and documentated private
predicates. Using the source button, the system shows the source
with syntax highlighting as in PceEmacs and formatted structured
comments.7This mode is still
incomplete. It would be nice to add line-numbers and links to
documentation and definitions in the sources.
If the browser is accessed from localhost
, each object
that is related to a known source-location has an edit icon at the right
side. Clicking this calls edit/1
on the object, calling the user's default editor in the file. To use the
built-in PceEmacs editor, either set the Prolog flag editor
to pce_emacs
or run ?- emacs.
before clicking
an edit button.
Prolog source-files have a reload button attached. Clicking this reloads the source file if it was modified and refreshes the page. This supports a comfortable edit-view loop to maintain the source-code documentation.
Create stand-alone documentation from a bundle of source-files. Typical use of the PlDoc package is to run it as a web-server from the project in progress, providing search and guaranteed consistency with the loaded version. Creating stand-alone files as provided by this file can be useful for printing or distribution.
file(s)
. Options
include
html
.
doc
.
http://www.swi-prolog.org/pldoc/
index
.
loaded
(default) only
documents files loaded into the Prolog image. true
documents all files.
true
, recurse into subdirectories.
copy
, copy the CSS file to created directories. Using inline
,
include the CSS file into the created files. Currently, only the default copy
is supported.
The typical use-case is to document the Prolog files that belong to a
project in the current directory. To do this load the Prolog files and
run the goal below. This creates a sub-directory doc
with
an index file index.html
. It replicates the directory
structure of the source directory, creating an HTML file for each Prolog
file and an index file for each sub-directory. A copy of the required
CSS and image resources is copied to the doc
directory.
?- doc_save(., [recursive(true)]).
doc
inside the
pack. The index page consists of the content of readme
or
readme.txt
in the main directory of the pack and an index
of all files and their public predicates.
The LaTeX backend aims at producing quality paper documentation as
well as integration of predicate description and Wiki files in LaTeX
documents such as articles and technical reports. It is realised by the
library doc_latex.pl
.
The best practice for using the LaTeX backend is yet to be
established. For now we anticipate processing a Wiki document saved in a
.txt file using doc_latex/3 to
produce either a simple complete LaTeX document or a partial document
that is included into the the main document using the LaTeX \input
command. Typically, this is best established by writing a Prolog
Script that generates the required LaTeX document and call this from
a Makefile. We give a simple example from PlDoc, creating this
section from the wiki-file latex.txt
below.
:- use_module(library(doc_latex)). :- [my_program].
We generate latex.tex from latex.txt
using this Makefile
fragment:
.SUFFIXES: .txt .tex .txt.tex: swipl -f script.pl \ -g "doc_latex('$*.txt','$*.tex',[stand_alone(false)]),halt" \ -t "halt(1)"
High-level access is provided by doc_latex/3,
while more low level access is provided by the remaining predicates.
Generated LaTeX depends on the style file pldoc.sty
, which
is a plain copy of pl.sty
from the SWI-Prolog manual
sources. The installation installs
pldoc.sty
in the pldoc
subdirectory of the
Prolog manual.
/
Arity//
ArityTypically Spec is either a list of filenames or a list of predicate indicators. Defined options are:
true
(default), create a document that can be run
through LaTeX. If false
, produce a document to be included
in another LaTeX document.
true
(default), only emit documentation for exported
predicates.
section
.
stand_alone
, public_only
and section_level
. See doc_latex/3
for a description of the options.stand_alone
, public_only
and
section_level
. See doc_latex/3
for a description of the options.\
begin{description}...\
end{description}
environment, just a plain list of \
predicate, etc.
statements. The current implementation ignores Options.
Literal programming is an established field. The TeX source is one of the first and best known examples of this approach, where input files are a mixture of TeX and PASCAL source. External tools are used to untangle the common source and process one branch to produce the documentation, while the other is compiled to produce the program.
A program and its documentation consists of various different parts:
Comments can be added through Prolog directives, a route taken by Ciao Prolog with lpdoc Hermenegildo, 2000 and Logtalk Moura, 2003. We feel structured comments are a better alternative for the following reasons:
We are aware that the above problems can be dealt with using syntax-aware editors. Only a few editors are sufficiently powerful to support this correctly though and we do not expect the required advanced modes to be widely available. Using comments we do not need to force users into using a particular editor.
JavaDoc uses HTML as markup inside the structured comments. Although HTML is more widely known than ---for example--- LaTeX or TeXinfo, we think the Wiki approach is sufficiently widely known today. Using text with minimal layout conventions taken largely from plaintext newsnet and E-mail, Wiki input is much easier to read in the source-file than HTML without syntax support from an editor.
Types and modes are not a formal part of the Prolog language. Nevertheless, their role goes beyond pure documentation. The test-system can use information about non-determinism to validate that deterministic calls are indeed deterministic. Type information can be used to analyse coverage from the test-suite, to generate runtime type verification or to perform static type-analysis. We have chosen to use a structured comment with formal syntax for the following reasons:
SWI-Prolog aims at platform independency. We want tools to rely as much as possible on Prolog itself. Therefore, the entire infrastructure is written in Prolog. Output as HTML is suitable for browsing and not very high quality printing on virtually all platforms. Output to LaTeX requires more infrastructure for processing and allows for producing high-quality PDF documents.
Initially, the PlDoc wiki language was based on http://www.twiki.orgTwiki. Currently, http://en.wikipedia.org/wiki/Markdownmarkdown is a wiki syntax that is widely accepted and not tight to a single system. In PlDoc 2, we have adopted markdown, including many of the limitations and extensions introduced by http://www.stack.nl/ dimitri/doxygen/Docygen. Limitations are needed to avoid ambiguities due to the common use of symbol charaters in programming languages. Extensions are desirable to make use of already existing conventions and support requirements of program documentation.
Some of the changes in PlDoc 2 are to achieve compatibility with the http://prolog-commons.org/Prolog Commons project. The library documentation conventions of this project will be based on PlDoc and the Ciao lpdoc standards. It is likely that there will be more changes to the PlDoc format to synchronise with Commons. We do not anticipate significant impact on existing documentation.


Speech
The Education Secretary speaks about the importance of collaboration and partnerships between schools.
Thank you, Maxine [Adams, Chair - Leicestershire Academies Group].
It’s a real pleasure to be here today at the Leicestershire Academies Spring Conference and let me wish you a happy anniversary on a year of collaboration!
It’s great to be here as a member of the government - as Secretary of State for Education. And as MP for Loughborough too.
But actually I’m also just a local resident - a local mum, the wife of a school governor, and I feel privileged to be addressing you this morning.
This government has been very clear about its priorities for education in this Parliament, building on the work of the coalition government in the last. Putting it simply, we want to see excellence in education everywhere.
Our reforms have sought to unleash the potential in our schools and give them the freedom to operate in the best interests of their students and their communities.
The academies programme has been at the forefront of that work and under this government we expect to see it grow and expand until all schools become academies. And that isn’t because of some ideological slavishness to the idea of the academies programme.
As you all know - academies really work. We now have 5,500 academies with 65% of all secondary schools as academies and 18% of primaries.
We know that unfortunately too close to home there are authorities and unions who oppose conversion to academy status - the city council tried hard to block the conversion of Rushey Mead, meaning pupils stayed in an underperforming school for over 2 years.
They were prepared to put children’s education to the background by calling strike action at Uplands School and orchestrating the mass resignation of staff.
I think it is wholly wrong to play politics with children’s education.
It shows the importance of our Education and Adoption Bill , which will allow us to intervene swiftly where schools are failing, to bring in new sponsors and I’ll be saying more about the bill in a few moments.
If we are to be a truly world-class education system then we need to make sure that academies performing well are able to share their knowledge and collaborate with each other.
I’m talking about schools like Humberstone Juniors. An academy converter in 2013 that has seen standards rise year on year with pupil attainment moving from 77% of pupils achieving level 4+ at key stage 2 in English and maths in 2012 to 95% achieving it last year.
That’s a massive increase and something to be celebrated but what’s even more impressive is that Humberstone Juniors is taking its approach to driving up standards and now helping other schools to do the same.
If academies are driving excellence in our schools then partnerships are the way to make sure it spreads.
I want to see all our young people - no matter where they are or what their background - accessing high-quality education which helps set them up for their futures.
I think the best way to improve the education system is through school-to-school support and it has become increasingly clear that the best way to do that, the most sustainable, the most accountable, the most efficient way to do that is through multi-academy trusts.
MATs have so many benefits. These range from sharing best teaching practice to the economies of scale. Then of course there are staffing arrangements which can be more flexible, allowing MATs to develop and retain the best teachers who have well defined careers paths which lead them to school leadership roles much sooner.
These benefits are already being seen here in Leicestershire.
I mentioned Humberstone Junior School a few moments ago and I am pleased to say that the Humberstone Multi-Academy Trust was approved as a sponsor last year and Humberstone Infant School is planned to join the trust this year.
New MATs are forming all the time.
Another example in Leicestershire is Wigston Academies Trust, formed less than a year ago when Abington Academy merged with Bushloe High School and took on sponsorship of Guthlaxton College. It had been judged as ‘requires improvement’ by Ofsted in 2014 with 2014 attainment results below expected standards. Wigston Academies Trust was able to implement an improvement plan which included staffing, leadership and the curriculum. Now called Wigston College, it is already showing impressive signs of improvement and what an exciting time it must be for the school.
That is the power MATs can have and we are offering various incentives to join them including the primary academy chain grants and the sponsor capacity fund which gave out over £11 million to 155 sponsors in the last year.
What is required is the vision for a grouping of schools collaborating in the pursuit of high performance and the leadership to make that vision a reality.
Leadership is so important in our schools and in our schools system. It is something DfE is very focused on. It is the impetus that keeps our schools on the path to success. We know that brilliant leadership teams can turn schools around at pace.
That’s why we are investing in the Future Leaders MAT CEO Course; in governors for schools; and Inspiring the future - an active programme to recruit more governors.
School governors are so important because of the skill, expertise and wisdom they bring to running schools.
We believe that the best run schools are those with highly skilled governors who can hold schools to account; play an active role in the path the school takes; and support heads and system leaders to create and sustain excellent educational outcomes.
We want those governors to have access to specific training too, so we have invested, through the National College of Teaching and Leadership, in governor training to help them understand key areas - like data.
If interpreted correctly it can have a huge impact on the success of a school or MAT .
We have local examples of fantastic leadership like the chief executive and head of Kibworth Church of England Primary, Paul Stone - a national leader of education.
Kibworth is a national support school and the lead school in the Affinity Teaching School Alliance. The alliance of 69 schools directly employs 6 national leaders of education, 8 local leaders of education and 40 specialist leaders of education.
Kibworth is part of the Discovery Schools Academy Trust - a strategic partner with the Flying High Trust and Candleby Lane Teaching School Alliance in Nottinghamshire.
Together they have formed, Inspiring Leaders, a not-for-profit partnership company which holds a licence to deliver National College of Leadership programmes, including the national professional qualifications for middle and senior leadership and for headship.
There’s no denying the wealth of talent that is being so widely shared and how amazing to think it is in our county.
Our Education and Adoption Bill, currently making its final passage through Parliament, seeks to create new powers to tackle failing and coasting schools - be they maintained schools or academies.
And that’s because our young people shouldn’t have to accept an education which doesn’t give them access to the kind of future they really want.
Should we stand by and allow any school to fail young people? Absolutely not.
The Education and Adoption Bill puts a duty on me, and my successor secretary of states, to make an academy order for all inadequate maintained schools, ensuring that swift action will always be taken where a maintained school has failed.
Crucially, the Education and Adoption Bill removes the requirement for consultation on whether a school should become an academy - to prevent the unnecessary, prolonged debates that have often prevented a school from being transformed quickly.
We have sought, however, to place a duty on sponsors to communicate with parents about their plans to improve the school, ensuring that - in all cases - parents are given the opportunity to understand just how a sponsor plans to transform their child’s school.
The Education and Adoption Bill, if passed by Parliament, will create a clearer path for all failing schools to be brought under new leadership and ensure that coasting schools are challenged to improve.
It is simply unacceptable that any young person should be held back from fulfilling their potential because their school was unable to provide them with the tools they needed to succeed.
We fully expect the Education and Adoption Bill to become law this year and we are excited about how it will feed into our priorities for the education system. We envisage a school-led system where schools voluntarily convert to become academies, form or join MATs , learn from teaching schools through teaching alliances and - where possible - join collaborative groups like yours.
We are all working towards the same goal and I believe government’s role is to support you in building that collaboration and capacity - because we know how difficult this is.
But where performance is unacceptably low we will use new powers to intervene to change leadership in schools.
We owe it to our young people - whose futures depend on it.
It really has been a pleasure to be here today. Conferences like this are in the spirit of collaboration we see as the future of our education system.
The Leicestershire Academies Group and others like it are crucial to realising that by sharing ideas and bringing together best practice on what really works for young people.
Published: 4 February 2016


'RJDBC' based 'DBI' driver to Amazon Athena, which is an interactive query service to analyze data in Amazon 'S3' using standard 'SQL'.
| Version: | 1.1.0-1 |
| Imports: | methods, RJDBC, rJava |
| Published: | 2017-11-19 |
| Author: | Neal Fultz, Gergely Daróczi |
| Maintainer: | Neal Fultz <nfultz at gmail.com> |
| License: | AGPL-3 |
| NeedsCompilation: | no |
| Materials: | README |
| CRAN checks: | AWR.Athena results |
| Reference manual: | AWR.Athena.pdf |
| Package source: | AWR.Athena_1.1.0-1.tar.gz |
| Windows binaries: | r-devel: AWR.Athena_1.1.0-1.zip, r-release: AWR.Athena_1.1.0-1.zip, r-oldrel: AWR.Athena_1.1.0-1.zip |
| OS X binaries: | r-release: AWR.Athena_1.1.0-1.tgz, r-oldrel: AWR.Athena_1.1.0-1.tgz |
| Old sources: | AWR.Athena archive |
Please use the canonical form https://CRAN.R-project.org/package=AWR.Athena to link to this page.


This is what underlies the random and sequential loop types in Builder, they work using the method of constants. The trialHandler presents a predetermined list of conditions in either a sequential or random (without replacement) order.
see TrialHandler
for more details.
This generates the next trial using an adaptive staircase. The conditions are not predetermined and are generated based on the participant’s responses.
Staircases are predominately used in psychophysics to measure the discrimination and detection thresholds. However they can be used in any experiment which varies a numeric value as a result of a 2 alternative forced choice (2AFC) response.
The StairHandler systematically generates numbers based on staircase parameters. These can then be used to define a stimulus parameter e.g. spatial frequency, stimulus presentation duration. If the participant gives the incorrect response the number generated will get larger and if the participant gives the correct response the number will get smaller.
see StairHandler
for more details


SARS-CoV- {border-style px;} #ffffff;} viral COVID- throat specimens day virus clinical gargling symptom collected px; respiratory sputum {font-family RT-PCR coronavirus font-size load shedding specimen Elsevier ahead case days double; swab symptoms antibody border-color border-width patients solid; wash {font-style {font-weight Antibody However, bold centre courier; detection determined disease em; fever novel onset. present print] prolonged pt;} remained resource results specific using


2 Chronicles 22:2
Forty and two years old was Ahaziah when he began to reign, and he reigned one year in Jerusalem. His mother's name also was Athaliah the daughter of Omri.


Mig/Impl/Prod Tools Run Post Migration Checks. Check where is your project. Check mig, impl and Prod server and customer. Search for Institution Code/Name: Search for a Project Go to: Migration Sanity Checks Choose a project from possible candidates .


Why learn web development?
used frequently in work
develpoing to interest myself
followed by others
How to learn web development?
HTML:learn tags
words format tags
this is bold
this is emphasis
this
is mixed
body!
HTML link like:
Duke Learn Programs Doc of Tags
Add Image:
CSS
JavaScript
here is div1
here is div2


You need to enable JavaScript to run this app.
Student Mentorship System
Logout
Student Mentorship System
My Profile
Chats
Chats
Logout
Mentor
Start New Chat


Mubarak Wakaso fourth in list of most tackles won in La Liga after 13 matches
Deportivo Alaves midfielder Mubarak Wakaso is one of the hardest working midfielders after 13 games in La Liga this season.
The Ghana international comes fourth in the most tackles won in the Spanish league after an impressive start to the season.
The 29-year old has won 21 tackles this season placing him the fourth in the list of hard working midfielders in Spain.
Real Madrid defensive midfielder Casimero leads the pack with 28 duels won, followed closely by Celta Vigo's Hugo Malo.
Wakaso comes fourth just one behind Vincente Iborra of Villareal.
The other players on the list are Victor Sanchez of RCD Espanyol and Marc Cucurella of Getafe.
Mubarak Wakaso missed Ghana's AFCON 2021 qualifiers against South Africa and Sao Tome because of a fractured arm but he is set to return for the weekend's La Liga showdown against Eibar.
The ex-Espanyol midfielder has played 11 La Liga games this season.
See list below:


UX design notes part 2
More notes from my Udemy course in UX design.
Design process
The instructor reiterated that this is about coming up with the process that works best for you and not to copy another designer’s style. Make changes however you see fit.
There are four main steps in most processes: research (empathize), analyze (your reserach), ideate (generate ideas), test.
Mistakes people make/things people don’t realize:
- there is a design process; need to do research, come up with ideas, etc. One can’t just come up with an idea on the spot, work needs to go into it, and that takes the form of your design process.
- need to have an excess of research before you analyze, and need excess of ideas before you test them; it’s imporant to be aware of as many problems that you are facing as possible, so you can proritize the most imporant ones. Solving some problems can also cause problems in other areas.
- each of these design phases require different types of thinking; divergence and convergence
Research and ideation are divergent, quantity over quantity, need to gather lots of data Analysis and testing are convergent, need to focus on most important details, lots of time to think
Critical thinking/design thinking
Scandinavian cooperative design: Scandinavian designers actually worked with the people they were building software for. The workers essentially helped to design the software they were going to use.
- this type of process is more about perception, rather than a “scientific” or rational thinking kind of process
- often re-packaged as “design thinking”, boiled down to process steps; these short courses don’t usually help you to become a better designer
Innovation theatre: the appearance of being innovative without actually having interest in a better user experience; more for show, for stakeholders, etc
Design is about thinking
- it’s important to improve your preception, creativity skills, and listen more
- decisions come from emotions rather than rational thinking
- book recommendation was Six Thinking Hats - to learn about different ways of thinking
Experience
We can get people to buy products by saving them:
- time
- money
- space
If the cost of any of these is too high it is no longer worth it.
These days, improving the experience of a product is more important.
It’s important to look at the emotional responses that people have to various tasks in their lives
- e.g. Tinder - online dating full of rejection and emotional pain, Tinder takes the rejection out of it by having “matches” and includes the experience of “swiping” people out of your life or into your life
- good experience, however not in the long term
Focusing on making something a good experience does not make it inherently good. A cheeseburger is a good experience, but is not good for you.
Center for Humane Technology: organization that wants to make things that are good for people, rather than focusing on a good experience
People like to talk about things that are easy to articulate. But sometimes it’s more important to address the things that are difficult to talk about.
Perception is important. If someone says it took too long to do something on your site, it’s likely they just don’t like your site. It doesn’t matter how long it actually took them - if they perceived it to take too long it is a problem. People’s experiences are not rooted in reality. These things can be difficult to articulate to your coworkers; talking about things like the number of clicks to a particular part of a site is easy.
People like to feel in control. They like to know how long it will be until the Uber or train arrives, and will more happily wait when they know what to expect. If your site responds when you click a button, or you let the user know that something is loading, they will be more patient with your site
Software design isn’t all about usability - creativity is important too.
- e.g. TV remote - if you take away some buttons from your TV remote, you should replace them with something unique and interesting. If you just take buttons away, people will think it’s less valuable.
Creativity
TL;DR - creative people come up with lots and lots of ideas
We value novel experiences, even if the things we have are fine as they are.
Creativity: ability to generate novel solutions to a problem
- how many ideas you can come up with in a defined amount of time
- judgement free, whatever comes to you; don’t try to overthink and figure out why something won’t work
- you can’t be creative and rationalize at the same time
- this is important to practice - the more you do it the better you get
- your first idea is probably bad, and don’t want to get attached to an idea too early
Exercise: every day pick a problem and see how many solutions you can come up with in one minute
Exercise: think of 100 uses for a potato, see how quickly you can do it
- can do this for other things like a pin
Charles Darwin: sometimes unique traits help an animal survive, more than fitness
- so don’t make your designs forgettable - you need some uniqueness for people to remember it
The things we love are imperfect and unique. Humans’ highest perception of value is creativity.
It is important to write down or draw out your ideas. It gets them out of your working memory, freeing it up for the more interesting ideas underneath. Use paper and get away from the computer.
“Good ideas are hidden under bad ideas”
Important parts of your brain for creativity:
- Central Executive Network - for focusing on a task
- Default Mode Network - where you daydream and let your brain make new connections
The most creative people use both of these parts of the brain at once or can switch between them quickly. Taking breaks is good, because that’s when you’re in default mode. A lot of ideas can come when you’re not in focused mode.
Boundaries/limits make people more creative - Van Gogh used only a few colors in his paintings.


Loading PDF file from Firebase Storage in Flutter App (Android, iOS & Web)
Posted on February 03, 2020 in Flutter
Target Audience: Beginner
Recipe: Loading PDF file from Firebase Storage in Flutter Native & WebApp.
Goal: In this code recipe, we'll do following:
- Review Firebase Project and configuration setup.
- Checkout availability of PDF file in FirebaseStorage using Firebase Console.
- Fetching PDF from Firebase Storage.
- Checkout code for loading pdf in native and web app environments.
Note: Please review this article about Firebase Login, if you run into permissions issues accessing PDF. Android platform expects user to be logged in.
Flutter Cookbook:
Android:
iOS:
Flutter Web:
Checkout the Youtube video:
Introduction
This code recipe would demonstrate loading PDF file from Firebase Storage in Flutter Native and Web Apps. I'm using my Flutter talks's slides as PDF file. I've this PDF available in Firebase Storage already.
Firebase Project review
Project Setup:
Make sure that your Firebase project is configured for all three platforms.
- Android: Checkout this link to configure Firebase project for Android app.
- iOS: Checkout this link to configure Firebase project for iOS app.
- Web: Checkout this link to configure Firebase project for Flutter Web app.
Images in Firebase Storage Console:
I've uploaded Flutter presentation's slides as PDF in Firebase Storage as shown in screenshot below.
Don't forget to tune Firebase Storage files 'Rules' depending on your usage. For demonstration purposes for this code recipe, I want to let user read images regardless of their authentication status. So, I'm making pdf bucket readable to all as shown in screenshot below:
pubspec.yaml
dependencies
Flutter plugins for accessing files from FirebaseStorage for Native apps are similar to previous article about Loading images from Firebase Storage
dependencies:
#http to download PDF
http: ^0.12.0+4
#Open PDF in a viewer
flutter_full_pdf_viewer: ^1.0.6
#Firebase related
firebase_storage: ^3.0.8
firebase_core: ^0.4.0+9
firebase_analytics: ^5.0.6
Flutter plugin for accessing files in Firebase Storage for Web apps:
dependencies:
firebase: ^5.0.4
Code Structure for loading PDF
I want to fetch PDF from firebase as the first thing. For this purpose I'll be fetching it in initState()
method. file
variable holds the path of the pdf file in FirebaseStorage. fileName
variable is used to display the name for the PDF in app bar.
First, LaunchFile.loadFromFirebase(context, file)
method fetches the PDF file from FirebaseStorage, and then it is passed to LaunchFile.createFileFromPdfUrl(url)
to take appropriate action on the targeted platform. For Native platform, remote pdf is downloaded on the disk and named as flutterSlides.pdf
. On Web platform, PDF file's url is opened in another tab.
String file = "pdfs/slides.pdf";
String fileName = "Flutter Slides";
class LoadFirbaseStoragePdf extends StatefulWidget {
@override
_LoadFirbaseStoragePdfState createState() => _LoadFirbaseStoragePdfState();
}
class _LoadFirbaseStoragePdfState extends State<LoadFirbaseStoragePdf> {
static String pathPDF = "";
static String pdfUrl = "";
@override
void initState() {
super.initState();
//Fetch file from FirebaseStorage first
LaunchFile.loadFromFirebase(context, file)
//Creating PDF file at disk for ios and android & assigning pdfUrl for web
.then((url) => LaunchFile.createFileFromPdfUrl(url).then(
(f) => setState(
() {
if (f is File) {
pathPDF = f.path;
} else if (url is Uri) {
//Open PDF in tab (Web)
pdfUrl = url.toString();
}
},
),
));
}
...
}
Once the app has information about the PDF file, 'Open PDF' button will open it another screen:
FlatButton(
onPressed: () {
setState(() {
LaunchFile.launchPDF(
context, "Flutter Slides", pathPDF, pdfUrl);
});
},
child: Text(
"Open PDF",
style: TextStyle(fontSize: 20),
),
)
File launch_pdf.dart
uses dart.library
to decide on redirecting calls to native vs web implementation for LaunchFile
.
export 'unsupported_pdf.dart'
if (dart.library.html) 'web_pdf.dart'
if (dart.library.io) 'mobile_pdf.dart';
web_pdf.dart
has web related implementations while mobile_pdf.dart
file addresses native platforms (Android & iOS). Anything else goes to unsupported_pdf.dart
.
Let's checkout each of these files below:
unsupported_pdf.dart
For every platform that's not supported by our application will throw appropriate exceptions.
import 'package:flutter/material.dart';
class LaunchFile {
static void launchPDF(
BuildContext context, String title, String pdfPath, String pdfUrl) {
throw ("Platform not found");
}
static Future<dynamic> loadFromFirebase(BuildContext context, String url) {
throw ("Platform not found");
}
static Future<dynamic> createFileFromPdfUrl(dynamic url) async {
throw ("Platform not found");
}
}
Loading Image in Flutter Web App (web_pdf.dart
)
Web platform uses following implementation for the LaunchFile
class:
import 'package:flutter/material.dart';
import 'package:flutter_widgets/plugins/firetop/storage/fire_storage_service.dart';
import 'package:flutter_widgets/plugins/url_launcher/url_launcher.dart';
class LaunchFile {
static void launchPDF(
BuildContext context, String title, String pdfPath, String pdfUrl) async {
UrlUtils.open(pdfUrl);
}
static Future<dynamic> loadFromFirebase(
BuildContext context, String url) async {
return FireStorageService.loadFromStorage(context, url);
}
static Future<dynamic> createFileFromPdfUrl(dynamic url) async {
return url;
}
}
-
launchPDF(...)
:url_launcher
plugin will open the PDF in browser tab for Flutter Web. It usespdfUrl
parameter. -
loadFromFirebase(...)
: Checkoutfiretop
plugin directory to familiarize yourself with the platform specific call re-direction for accessing FirebaseStorage. -
createFileFromPdfUrl(...)
: This method simply return the url for the PDF to help open the file in browser's tab.
Loading PDF file in Flutter Native App (mobile_pdf.dart
)
import 'dart:io';
import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:flutter_widgets/pdf/load_pdf.dart';
import 'package:flutter_widgets/pdf/pdf_screen.dart';
import 'package:path_provider/path_provider.dart';
import 'package:flutter_widgets/plugins/firetop/storage/fire_storage_service.dart';
class LaunchFile {
static void launchPDF(
BuildContext context, String title, String pdfPath, String pdfUrl) {
Navigator.push(
context,
MaterialPageRoute(
builder: (context) => PDFScreen(title, pdfPath, pdfUrl),
),
);
}
static Future<dynamic> loadFromFirebase(
BuildContext context, String url) async {
return FireStorageService.loadFromStorage(context, file);
}
static Future<dynamic> createFileFromPdfUrl(dynamic url) async {
final filename =
'flutterSlides.pdf'; //I did it on purpose to avoid strange naming conflicts
print(filename);
var request = await HttpClient().getUrl(Uri.parse(url));
var response = await request.close();
var bytes = await consolidateHttpClientResponseBytes(response);
String dir = (await getApplicationDocumentsDirectory()).path;
File file = new File('$dir/$filename');
await file.writeAsBytes(bytes);
return file;
}
}
launchPDF(...)
: On native platform, this method opens the PDF file in a Flutter screen as below:
import 'package:flutter/material.dart';
import 'package:flutter_full_pdf_viewer/flutter_full_pdf_viewer.dart';
import 'package:flutter_full_pdf_viewer/full_pdf_viewer_scaffold.dart';
class PDFScreen extends StatelessWidget {
String title = "";
String pdfPath;
String pdfUrl;
PDFScreen(this.title, this.pdfPath, this.pdfUrl);
@override
Widget build(BuildContext context) {
return PDFViewerScaffold(
appBar: AppBar(
backgroundColor: Colors.blue,
title: Text(title),
actions: <Widget>[
IconButton(
icon: Icon(Icons.share),
onPressed: () {},
),
],
),
path: pdfPath);
}
}
-
loadFromFirebase(...)
: Checkoutfiretop
plugin directory to familiarize yourself with the platform specific call re-direction for accessing FirebaseStorage. -
createFileFromPdfUrl(...)
: This method downloads the pdf file from FirebaseStorage to a local file at disk. This local pdf file is later opened inPDFScreen
later.
That's all you need to load a PDF file from FirebaseStorage into your Flutter application.
Note: Checkout my previous article about plugins directory structure in details, and supporting web and native app's from single source code.
Source code repo
References:
- Related article about loading image from FirebaseStorage about supporting web and native app's from single source code.
- Configure Firebase project for Flutter Native Android app.
- Configure Firebase project for Flutter Native iOS app.
- Configuring Firebase project for Flutter Web app.
Happy cooking with Flutter :)
Liked the article ? Couldn't find a topic of your interest ? Please leave comments or email me about topics you would like me to write ! BTW I love cupcakes and coffee both :)
Follow me at twitter


?NEW
YORK
BOTANICAL
GARDEN
PLANTS
OF
BAHAMA
ISLANDS
Mastichodendron
foetidissimum
(Jacq.)
H.J.Lam«
Great
Abaco:
in
coppice
along
Whitesounc
road
from
Hopetown,
Elbow
Cay.
01443439
'"’"NEW
YOf^>
B°tANICAL
S>N?4RdEN
FLORA
NEOTROPICA
Sideroxylon
ioetidi
ssi
mum
Jacquin
subsp.
foetidi
ssi
mum
Pree
5
m.
tall.
July
k,
197b
D.
S.
Correli
&
John
Popenoa
b25b2
T.D.PENNINGTON
Herbarium
FAIRCHILD
TROPICAL
GARDEN
01443439
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


|
| enum | BackoffPolicy { LINEAR,
EXPONENTIAL
} |
| |
|
using | TimeUnit = std::chrono::milliseconds |
| |
|
|
static const TimeUnit | DEFAULT_INITIAL_BACKOFF {100} |
| |
|
static const TimeUnit | DEFAULT_BACKOFF_STEP {50} |
| |
|
static const TimeUnit | DEFAULT_MAXIMUM_BACKOFF {1000} |
| |
|
static const size_t | DEFAULT_MAXIMUM_RETRIES {numeric_limits<size_t>::max()} |
| |
◆ BackoffPolicy
The backoff policy to use
◆ BackoffPerformer()
| cppkafka::BackoffPerformer::BackoffPerformer |
( |
| ) |
|
Constructs an instance of backoff performer
By default, the linear backoff policy is used
◆ perform()
template<typename Functor >
| void cppkafka::BackoffPerformer::perform |
( |
const Functor & |
callback | ) |
|
|
inline |
Executes an action and backs off if it fails.
This will call the functor and will retry in case it returns false
- Parameters
-
| callback | The action to be executed |
◆ set_backoff_policy()
| void cppkafka::BackoffPerformer::set_backoff_policy |
( |
BackoffPolicy |
policy | ) |
|
Sets the backoff policy.
- Parameters
-
| policy | The backoff policy to be used |
◆ set_backoff_step()
| void cppkafka::BackoffPerformer::set_backoff_step |
( |
TimeUnit |
value | ) |
|
Sets the backoff step.
When using the linear backoff policy, this will be the delay between sending a request that fails and re-trying it
- Parameters
-
| value | The value to be used |
◆ set_initial_backoff()
| void cppkafka::BackoffPerformer::set_initial_backoff |
( |
TimeUnit |
value | ) |
|
Sets the initial backoff.
The first time a commit fails, this will be the delay between the request is sent and we re-try doing so
- Parameters
-
| value | The value to be used |
◆ set_maximum_backoff()
| void cppkafka::BackoffPerformer::set_maximum_backoff |
( |
TimeUnit |
value | ) |
|
Sets the maximum backoff.
The backoff used will never be larger than this number
- Parameters
-
| value | The value to be used |
◆ set_maximum_retries()
| void cppkafka::BackoffPerformer::set_maximum_retries |
( |
size_t |
value | ) |
|
Sets the maximum number of retries for the commit operation.
- Parameters
-
| value | The number of retries before giving up |
The documentation for this class was generated from the following files:


Inline Corporations Limited.
Home
About
Shop
Blog
Contact Us
Why Don't You Leave Us A Message?
Please feel to contact via this form.
Contact Us:
Full Name:
Business Name:
Registration Number:
Email Address:
Phone number:
Message:
Date of Birth


Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
IITM is a leading platform for the travel industry to showcase existing products and introduce new ones to audiences across the country.


I’ve run my first session of Creative Coding workshop with 2nd year Design students at Goldsmiths today. I wanted to give the group a good intro to web technologies, because apart from them being useful for making cool things with I am convinced most people will need them at one point or another.
The short course will cover HTML, CSS and JavaScript (let’s be honest, with a huge dollop of jQuery), in the last couple of days focusing on using APIs to get interesting things from other places and then doing something with thise things.
I’ve built a quick site for collecting all the notes, materials and additional resources in one place, you can find it here. It’s CC licensed, so feel free to use it, adapt it, or contribute to making it better.
Today we’ve focussed on HTML, and I’ve started by showing the group Mozilla’s X-Ray Goggles, which always inevitably turns into defacing the BBC website:
Fun times.


{% extends "base.html" %} {% set page_title = "Join the SRCF" %} {% block body %}
Hello, and welcome to the SRCF! Before you can use our services, you'll need to sign up for a personal account. To apply for SRCF membership, please fill in the form below.
Note that to assist your application, we have attempted to guess values based on information available to anyone on the CUDN. These are not stored until you complete the application form and give us explicit permission to do so.
{% endblock %}


Welcome to FitLife Fitness and Training Center!
Make fitness your favourite habit!
Home
About
Classes
Services
Memberships
Cardio
Strength
Other


In the Winter of 2006, I was visiting a few friends of mine in Ohio. I had moved to Tennessee 8 months ago, and visit them as often as possible. We're always up for new ideas, and always experimenting. The first few days I was in town, we really wanted to score some grass. Where I used to live it's relatively easy to score, and always fairly priced. We didn't score until a later date though, due to people being out of town and it being a major Holiday week.
So, in the end, we got some beers. Then I drove us all down to the local college to buy cigarettes. Once we arrived at our destination, an attic apartment of a friend who was out of town, we got busy. We first found his beer bong, and decide because of how little beer we had (Roughly 4 each), we should down them quickly. Right beside the beer bong, however, was a water bong. This is where things started to get interesting.
After we all beer bonged one beer each, we all packed a huge bowl of tobacco into the water bong. We'd pass this bowl until dry, then bong a single beer each again. Then we repeated the pattern. Around the third pass of the water bong, we all realised we were a bit out of it. High if you will. After a toke of 15-20 seconds, I'd get a huge buzz that lasted up to five minutes. When the night was over though, these highs seemed to last up to 25 minutes!!! Note: The water bong was home made, and was never used before. Due to this factor alone we are positive we smoked nothing but tobacco that night.
We had no clue what was going on, but went with it anyway. We put a picture of a sunset over mountains on top of a ping-pong table, and sat at the couch near the end of it. We then played Immortal Technique's 'Dance With the Devil.' I closed my eyes and visualized the entire song in a dreamlike form. This may be due to the fact my name is William (Main characters name in the song). My two friends saw people climbing the mountains in the paintings. We weren't high anymore. We were tripping very mildly, or at least using our artistic views on the song and painting to their extremes.
 We tried the experiment with three different kinds of cigs and all worked. We may never find out what happened, as erowid mentions nothing of these effects. Whatever it may be though, we may all remember it for quite some time.
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.


| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
wchar_t
mess The ISO C and POSIX standard creators made an attempt to fix the first problem mentioned in the section ‘char *’ strings. They introduced
<wctype.h>
that were meant to supplant the
ones in <ctype.h>
.
Unfortunately, this API and its implementation has numerous problems:
wchar_t
is a 16-bit type. This
means that it can never accommodate an entire Unicode character. Either
the wchar_t *
strings are limited to characters in UCS-2 (the
“Basic Multilingual Plane” of Unicode), or — if wchar_t *
strings are encoded in UTF-16 — a wchar_t
represents only half
of a character in the worst case, making the <wctype.h>
functions
pointless.
wchar_t
encoding is locale dependent
and undocumented. This means, if you want to know any property of a
wchar_t
character, other than the properties defined by
<wctype.h>
— such as whether it's a dash, currency symbol,
paragraph separator, or similar —, you have to convert it to
char *
encoding first, by use of the function wctomb
.
fgetwc
and fgetws
, and when the input stream/file is
not in the expected encoding, you have no way to determine the invalid
byte sequence and do some corrective action. If you use these
functions, your program becomes “garbage in - more garbage out” or
“garbage in - abort”.
As a consequence, it is better to use multibyte strings, as explained in
the section ‘char *’ strings. Such multibyte strings can bypass
limitations of the wchar_t
type, if you use functions defined in gnulib
and libunistring for text processing. They can also faithfully transport
malformed characters that were present in the input, without requiring
the program to produce garbage or abort.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Bruno Haible on January, 2 2022 using texi2html 1.78a.


|
Allegro Animations
1.0
Simple animations made using Allegro graphics library
|
| C_line | Straight line from the Point object _start to the Point object _end with a certain slope |
| CDisplay | Class to initialize allegro and open the main window |
| CDrawable | Interface for drawable objects |
| CmySimulator | Lists of Drawable objects and Updateable objects and calls draw and update for their derived objects respectively |
| CPoint | Position on the display (grid) |
| CSimulator | Simulator object. Sets up Allegro library, and runs the main simulation loop |
| CTriangle | Triangle that falls from the top of the display to the bottom |
| CTrunk | Elogating line from Point start to Point end in total_time |
| CUpdateable | Interface for updateable objects |
| CVector | Change in position of x and y |


Test for [popup]::backdrop presence and stacking order. The test passes if there are 3 stacked boxes, with the brightest green on top.


Cel is a pure Lua library. It is desigend to be embedded into a host application. The host application must provide Cel with input from the user and access to system resources, and also provide rendering for Cel.
Before Cel is usable we need to install a driver for it, the driver is responsible for provding device input, fonts, clipboard access and other miscellaneous functions that are platform specific. This section is meant to serve as an example on how to create the driver and use it to drive Cel.
We will create a module for our driver, that will allow any love application to use Cel by requiring this module. See not yet defined source listing for the comlete source for this module.
To embed Cel. First require the cel module.
local cel = require 'cel'
We add new table in the global love table, to allow the love application to interface with the Cel driver. (We will use the love.cel table later to define cels that are dependent on the love platform.) We are also making love.cel a proxy for cel.
love.cel = setmetatable({}, {__index = cel})
Before we install the driver Cel requires a table that maps the platform key codes and states to the names that Cel will use (for the mouse and keyboard). This mapping has a big advantage, all events from Cel will use the plaform codes. What that means is that this the application developer can use the love codes for callbacks like this:
local example = cel.new(100, 100) --create a cel with specified width and height
function example:onkeydown(key)
if key == 'escape' then
love.event.push('q') -- quit the game
end
end
Using the platforms keycodes is great unless you write a new cel that you want to use on multiple platforms, in that case you would use the cel to access the keycodes by name, like this:
local example = cel.new(100, 100) --create a cel with specified width and height
function example:onkeydown(key)
if key == cel.keyboard.keys.escape then
--do something that is platform agnostic
end
end
Cel will acess the buttons table with keys 'left', 'right', 'middle', to get the code for mouse buttons. Love uses the 'l', 'r', 'm' as the codes for left, right, and middle mouse buttons.
local mouse = {
buttons = {
left = 'l',
right = 'r',
middle = 'm',
},
--love has no codes for the mouse state, so we will use the names cel uses.
states = {
unknown = 'unknown',
normal = 'normal',
pressed = 'pressed',
},
wheeldirection = {
up = 'wu',
down = 'wd',
},
}
As of now Cel uses the exact key codes that love uses becuause it is fairly complete and there is no universal standard. The keyboard should define this mapping in the keys table.
local keyboard = {
--we don't actually have to define this for love, since they are the same
--the keys will match the values
keys = setmetatable({}, {__index = function(t, k, v) return k end}),
--love has no codes for the key states, so we will use the names cel uses.
--The 'repeat' state indicates the key is being held down
states = {
unknown = 'unknown',
normal = 'normal',
pressed = 'pressed',
['repeat'] = 'repeat',
}
}
With the mouse and keyboard mappings defined we can install the driver. A proxytable is returned which will be a bidirectional interface.
local driver = cel.installdriver(mouse, keyboard)
The driver module should define these functions in the driver table retured by cel.installdriver. They will be called by cel if they are provided.
To provide mousemove input to Cel, we have to poll the mouse position from love. We will use a strategy that defines a function in the love.cel table to be called by the love app from the love callback of the same name. As a convenience we define the callbacks if they are not already defined by the app at this point.
do --driver.timer, driver.mousemove
if not love.update then
function love.update(dt)
love.cel.update(dt)
end
end
--on each update we call mousemove and timer on the driver
function love.cel.update(dt)
function love.cel.update(dt)
driver.mousemove(love.mouse.getX(), love.mouse.getY())
driver.timer(love.timer.getTime()*1000);
end
--On the first update resize the root
driver.root:resize(love.graphics.getWidth(), love.graphics.getHeight())
love.cel.update(dt)
end
end
do --driver.mousewheel, driver.mousedown
if not love.mousepressed then
function love.mousepressed(...)
return love.cel.mousepressed(...)
end
end
function love.cel.mousepressed(x, y, button)
--love treats the mousewheel like a button press
if 'wu' == button then
driver.mousewheel(x, y, 'wu', 1)
elseif 'wd' == button then
driver.mousewheel(x, y, 'wd', 1)
else
driver.mousedown(x, y, button)
end
end
end
do
if not love.mousereleased then
function love.mousereleased(...)
return love.cel.mousereleased(...)
end
end
function love.cel.mousereleased(x, y, button)
--we have to filter wheel buttons here, cel has no concept of the wheel as a button
if 'wu' ~= button and 'wd' ~= button then
driver.mouseup(x, y, button)
end
end
end
do --driver.keydown, driver.keypress, driver.char, driver.command
if not love.keypressed then
function love.keypressed(...)
return love.cel.keypressed(...)
end
end
function love.cel.keypressed(key, unicode)
--love does not distinguish a keypress and keydown event, so check cel keyboard to see
--if the key is already down, if so send the keypress instead of keydown
if cel.keyboard:isdown(key) then
driver.keydown(key)
else
driver.keypress(key)
end
local isDown = love.keyboard.isDown
--send copy/cut/paste commands, using standard windows keys, love does not abstract
--this so we have to interpret.
if isDown('lctrl') or isDown('rctrl') then
if key == 'c' then
driver.command('copy')
return
elseif key == 'x' then
driver.command('cut')
return
elseif key == 'v' then
driver.command('paste')
return
end
end
--get the char for the unicode and pass to driver.char
--restricting the codeset used becuase love font does not
--handle others well
if unicode <= 255 and unicode >= 32 then
driver.char(string.char(unicode))
end
end
end
do --driver.keyup
if not love.keyreleased then
function love.keyreleased(...)
return love.cel.keyreleased(...)
end
end
function love.cel.keyreleased(key)
driver.keyup(key)
end
end
Call from love.draw. Cel does not draw itself, and has no concept of drawing primitives such as images, polygons, lines, etc. The host app must render, and is free to do so however seems best. Cel provides a description of a cel, which includes all the information necessary to draw a cel. See the rendering section.
do --draw
if not love.draw then
function love.draw()
love.cel.draw()
end
end
--cel.describe will returns a table containing a description of what the visible
--cels, and true if this table is not identical to the last table returned.
function love.cel.draw()
local t, refresh = cel.describe()
t.drawtimestamp = cel.timer() --TODO don't put timestamp in here
t.description.face:draw(t.description)
end
end
This is where embedding gets the most difficult if you don't already have decent font rendering/metrics. Cel does not provide this, but expcets some basic font metrics, they may seem complex, and it is, but doesn't even scratch the surface of the real complexity involved with proper glyph rendering.
love.graphics.setFont(12) --TODO don't do this, don't remeber exactly why i had to do it initally, but
--this is not a nice thing to do
The driver is required to implement the loadfont function. cel.loadfont() will call driver.loadfont to create a new font. When a font is loaded through cel.loadfont() it caches the result, so it is unecesasry to do this in the driver implementation. Then name of the font passed to loadfont is unrestricted, the cel demos use 4 names, so implementing these names is a good idea if you want to run the demos:
A font returned from load font will be included in the description of a cel that uses the font. For that reason you should also include any additional information in the font that will be needed for your renderer. For love, we store a reference to the love font retruned by love.graphics.newFont().
Love does not give us the font metrics we need to work with, but it gives us some and we can fudge the others. The result of this fudging will be imperfect alignment of the glyphs when cel makes measurements. It is not unusual to have minimal font metrics, and cel is designed with this is mind, as you will see later.
do --driver.loadfont
--map demo font names to location of fonts in love directory
local namemap = {
code = 'fonts/cour.ttf',
monospace = 'fonts/cour.ttf',
serif = 'fonts/Anonymous Pro.ttf',
sansserif = 'fonts/VeraMono.ttf',
}
--name is an unrestricted value
--weight will be either 'normal' or 'bold'
--slant will be either 'normal' or 'italic' or 'oblique'
--size is the fonts size in pixels (size of what exactly is up to the driver to decide
--a sensible choice is the size of the em square)
function driver.loadfont(name, weight, slant, size)
name = namemap[name]
local font = {}
--create a love font and store it as font.nativefont to be used by our renderer
if name then
font.nativefont = love.graphics.newFont(name, size)
else
font.nativefont = love.graphics.newFont(size)
end
local nativeheight = font.nativefont:getHeight()
do --calculate font bbox, love does not provide most of the metrics that cel requires,
--but we can still make it work by guessing picking reasonable values based on the
--font metrics is does provide. The most important metric for cel is the advance,
--love does supply that metric. These can be tweaked based on the font through trial
--and error, or you can use outside means, such as freetype to store the metrics in
--a file.
font.bbox = {
xmin = 0,
xmax = 0,
ymin = -(nativeheight - math.floor(nativeheight * .8)), --fudge it
ymax = math.floor(nativeheight * .8), --fudge it
}
end
font.lineheight = font.nativefont:getHeight()
font.ascent = font.bbox.ymax
font.descent = -font.bbox.ymin
local function newglyph(fontmetrics, glyph)
local char = string.char(glyph)
--no glyph metrics from love, we can get the horizontal advance at least
local xmin, xmax, ymin, ymax = 0, font.nativefont:getWidth(char), font.bbox.ymin, font.bbox.ymax
fontmetrics[glyph] = {
glyph = glyph,
char = char,
advance = font.nativefont:getWidth(char),
xmin = xmin,
xmax = xmax,
ymin = ymin,
ymax = ymax,
}
return fontmetrics[glyph]
end
--Don't calculate the glyph metrics until it is asked for.
font.metrics = setmetatable({}, {__index = newglyph})
return font
end
end
We set the key repeat, by default it is off in love. Not very nice of our driver.
love.keyboard.setKeyRepeat(450, 35)
Our driver will return a cel to be used as the root cel for the love app. We don't return the real root cel because we want our driver to have sole control of it. You don't have to understand this right now, you will after going through the tutorials on linking.
return driver.root:newroot():link(driver.root, 'edges')
This module will define how we render a cel. The approach taken here is just one way to do it, how you choose to render will depend on the rendering capabilitis you have available.
local cel = require 'cel'
Lets take a look at the information provided in a cel description. The description is obtained by calling cel.describe().
In the description of the white cel mousefocus would be 1. For the red, blue and green cels it would be true.
This is an example description that of Fig 1.
 A single face can be shared by multiple cels or a cel can have its own unique face. In most cases though you would have a face that is used for buttons, another for listboxes, another for labels and so on.
The renderer is a good place to define faces, but doesn't have to be the only place. This is how you create a face:
local face = cel.face {
metacel = 'cel'
}
We just defined a face that can be used by any cel ('cel' is the name of the default metacel, all other cels 'inherit' from the 'cel' metacel). The metacel entry indicates what metacel this face is for.
Lets add something to the face that we can use to render the cel, like a color
local face = cel.face {
metacel = 'cel',
color = 'red',
}
Now when we see a face in the description our renderer can get the color out of the face and use that when rendering the cel. An important point is that Cel does not care what the color is, nor does it understand the meaning of the color entry in the face, this definition is something that your renderer and app understand. There are some entries that cel does understand, and defines the meaning of. These entries are reserved by Cel:
I will go into a deeper explanation of font, layout and flow later. Any properties in the 'cel' metacel face are also properties of other faces (via __index metamethod).
This defines a face for a button. The metacel = 'button'
entry is what makes it a button face.
local buttonface = cel.face {
metacel = 'button',
bordercolor = 'blue',
}
A 'button' metacel inherits from the 'cel' metacel (as do all cels). The face defined for a metacel will inherit properties of the face defined for the metacel it inherits from. In this case buttonface.color == 'red'
This define a face for a textbutton. The textbutton metacel inherits from the button metacel.
local textbuttonface = cel.face {
metacel = 'textbutton',
color = 'green',
}
textbuttonface inherits bordercolor from buttonface but overrides the color. If there was no entry for color in the textbuttonface then it would use the value from the 'cel' face.
It is many times necessary to define multiple faces for the same metacel, for instance if we want buttons to be different colors. To do that you have to give the face a name like this:
local purplebuttonface = cel.face {
metacel = 'button',
name = 'purplebutton'
color = 'purple',
}
Notice that buttonface
was not given a name, what a face does not have a name it becomes the face for the metacel and any other face for that metacel will inherit properties from it. So in this case purplebuttonface.bordercolor == 'blue'
If a button is created like this:
local button = cel.button.new(100, 100)
then it will use the unnamed face for the button metacel. To create a button with an alternate face, you can pass it in as the last parameter like this:local button = cel.button.new(100, 100, 'purplebutton')
. When the button is created it will lookup a face with the name purplebutton. You can also pass a reference to the face directly like this:local button = cel.button.new(100, 100, purplebuttonface)
. In addition the name of a face is not restricted to a string, which is useful for creating private faces.
TODO explain when face inheritance happens, not when it is created but wehn the metacel is created.
This example renderer will use the painters algorithm to render each cel, we start by drawing the root cel and then any will go through the cel descriptions from bottom to top(from n to 1) drawing each one.
We will start by defining the face for the 'cel' metacel, any properties we put in here will be available to all other faces.
By defining a font in the 'cel' face we are settting the font for every label, textbutton, text, edtibox, etc. that will be created. The font entry is one of the entries reserved by Cel. When a cel is created that needs a font, it will look for and expect to find the font in its face. By calling cel.loadfont() with no arguments we are asking for the default font provided by the driver.
local face = cel.face {
--metacel = 'cel', this is the default metacel, we don't have to specify it
font = cel.loadfont(),
textcolor = cel.color.rgb(255, 255, 255),
fillcolor = cel.color.rgb(200, 200, 200),
linecolor = cel.color.rgb(200, 200, 200),
}
The 3 ****color entries are ignored by Cel, but the we want to run the demo and the demo apps will use these names to specify colors for some cels. When you create your own faces for your app, you may decide to not use this approach. The next step is to draw a cel based on its description when using this face.
The printstring function sets the font and prints the specified text, x, y is the pen location, i, j
is the portion of the text to render.
Love prints from the upperleft corner of the the font.bbox (font.bbox becuase our
driver defines font.bbox in terms of font.nativefont:getHeight())
We don't need to adjust for penx only becuase our font metrics are bad and we
know font.bbox.xmin is always 0.
i, j are the substring of the text we want to render. Ideally love.graphics.print
would allow us to pass these in without haveing to create the substring. Hopefully
a future version will expose that type of api. An ideal api(for rendering Cel) would expose a print function
that allows specifying the pen origin along with a the substring of the text to render.
--this function sets the current color, the color argument is a 4 byte string with each byte representing red, green, blue, alpha respectively. Take note of when we return true or false.
local function setcolor(color)
if not color then return false end
local r, g, b, a = cel.color.decode(color)
if a == 0 then return false end
love.graphics.setColor(r, g, b, a)
return true
end
--this function clips our drawing to the the retangle defined by t,
--t is expected to be in the format of the clip table from a cel description.
local function clip(t)
love.graphics.setScissor(t.l, t.t, t.r-t.l, t.b-t.t)
end
--draws a rectangle outline in the current color.
--The r parameter represent corner radius for rounded rectangles, we will ignore it for now.
local function strokerect(x, y, w, h, r)
love.graphics.rectangle('line', x+.5, y+.5, w, h)
end
--draws a filled rectangle in the current color.
--The r parameter represent corner radius for rounded rectangles, we will ignore it for now.
local function fillrect(x, y, w, h, r)
love.graphics.rectangle('fill', x, y, w, h)
end
The drawlinks function is the implementation of the painters algorithm,
the argument t is a cel description, for each linked cel in the description
we call the draw function of its face, with its description. This means we
need to make sure each face has a draw function, so we will create one in the
root face. TODO explain that root face is not the face of the the root cel, but
the 'cel' metacel face that all other faces inherit from.
local function printstring(font, x, y, text, i, j)
love.graphics.setFont(font.nativefont)
if i then text = text:sub(i, j) end
return love.graphics.print(text, x, y - font.bbox.ymax)
end
local function drawlinks(t)
for i = #t,1,-1 do
local t = t[i]
t.face:draw(t)
end
end
This is the draw function that all faces will use (unless they redefine it). Notice
that it will draw colors if they are set. When the face is done drawing it calls drawlinks.
function face:draw(t)
if self.color then
if setcolor(self.color) then
clip(t.clip)
fillrect(t.x, t.y, t.w, t.h)
else
if setcolor(self.fillcolor) then
clip(t.clip)
fillrect(t.x, t.y, t.w, t.h)
end
if setcolor(self.linecolor) then
clip(t.clip)
strokerect(t.x, t.y, t.w, t.h)
end
end
else
end
return drawlinks(t)
end


Lorem
aka Ipsum
I build HTML and CSS.
Home
example.com
Discord
example#0001
Github
@example
Steam
/id/example
Reddit
/u/example


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev Letter
Next Letter
Frames
No Frames
All Classes
A
B
C
D
E
F
G
H
I
K
L
M
N
O
P
R
S
T
U
V
W
M
Main
- Class in
com.main
Main class
Main()
- Constructor for class com.main.
Main
main(String[])
- Static method in class com.main.
Main
main method to run the game
MainPage
- Class in
com.view.gui
MainPage(Window, GameBoard)
- Constructor for class com.view.gui.
MainPage
makeCompactGrid(Container, int, int, int, int, int, int)
- Static method in class com.view.gui.lib.
SpringUtilities
Aligns the first
rows
*
cols
components of
parent
in a grid.
makeGrid(Container, int, int, int, int, int, int)
- Static method in class com.view.gui.lib.
SpringUtilities
Aligns the first
rows
*
cols
components of
parent
in a grid.
map
- Variable in class com.view.gui.panel.
InputPanel
MAX_PLAYER
- Static variable in class com.controller.
OXGame
maximum(Dimension, Dimension)
- Static method in class com.view.gui.lib.
DimensionUtilities
return the minimum width and height in a and b
example: a = (200, 400), b = (500, 100)
the result will be (500, 200)
A
B
C
D
E
F
G
H
I
K
L
M
N
O
P
R
S
T
U
V
W
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev Letter
Next Letter
Frames
No Frames
All Classes