Tag Archives: External Link

Entries containing a hyperlink that leads away from this blog.

And Now For A Bit Of Fun. (Redux.)

(Title is a line from _Monty Python’s Flying Circus_.)

Frigid northern Idaho winters be the times what try gender-nonexclusive souls:
A nifty Python script & some data recovery have been my only accomplishments
as naughty pictures of Amaterasu hastened the thawing of my heart. Boi~ng!

Today’s the day I will write of myself in the third person.
But first, I will link you to my work and some auxiliaries.
This will take some time.

I must warn you: My portfolio is now sexually explicit, because I have recently
assembled portions of a dossier documenting my life to date.
If you’re too young, why not go play Narbacular Drop instead?

So, the PARENTAL DISCRETION caution is no longer entirely sufficient. Instead
you are advised that the work is ADULTS ONLY: don’t even touch it if a child.
The “Adults Only” category applies to ALL of these links, which are external to
WordPress, and the content hosted there is not necessarily endorsed by either
WordPress or the external host. Which is good for them, because it’s naughty.

I have at last retitled the archives with less confusing file names, and I have
rearranged the directory structure to be more sensible and easier to handle with
the unzip (manual section 1, by Info-ZIP) decompression utility: because each
archive contains similar directory structure, extracting them all into the CWD
will produce a less confusing output. Warning: Windows 10 will fail to extract
some of the files due to long filenames. 7zip (incl.) and unzip don’t do this.

If you download all the archives, you’ll need several hundred MB to decompress.
I’ve done what I could to ensure that all the megabytes are permissible by law,
but censorship laws in my country (USA) are restrictive and becoming more so…
exercise discretion.
If you wish to maintain a strictly lawful archive, then delete the banned books.
Actually, you might like to just delete everything, on the off chance that your
local apparatschik might declare you mentally ill due to unapproved thoughts.

A standalone version of MLPTK (0.7 MB / 0.2 MB), in case you have no time for the larger archives:

My complete portfolio is, owing to recent (and, I hope, conclusory) additions from auld lang syne, 22.8 megabytes. Compressed, it is 12 MB:
(New: duplicate file culler in Python, MLPTK’s “roman” module, & naughty chats.)

Syntax-highlighted illustrations in candy-colored HTML format are available (23.8 MB uncompressed / 3.3 MB compressed):

My book, “Yawnie’s Whole” fills about 1,100 A4 pages (13.3 MB / 7.1 MB), and I have corrected the typesetter malfunction that caused images not to appear in their respective chapters:
(These are the Ice Capades.)

Another 5,000 pp document my past (27.2 MB / 14.9 MB), and I have corrected the typesetter malfunction that caused images not to appear in their respective chapters:
(These are the Buttscapades.)

The companion curriculum (“Relevant Works By Others”), now its own archive (64.5 MB / 31.1 MB), contains the indispensable Berkeley Utilities and a diverse assortment of other excellent resources for programmers and Windows users:

Recently I’ve been exploring elderly volumes.
Here are some other curios I won’t be distributing after this time:

34.4 megabytes of finely crafted TrueType fonts (9.4 megs zipped):

A Windows compilation of the SWFTools suite version 0.7.0. (32.5 MB / 5 MB):

A selection of episodes of the out-of-print children’s television series, Sonic the Hedgehog (SatAM, not AoSTH; 100.8 MB / 98 MB):

A miscellany, including other out-of-print works (58.3 MB / 35.4 MB):

The combined size of all the downloads is about two hundred Megabytes.

Think not that those ten archives contain the Owl of Thebes; for, gentles all,
the foregoing hyperlinks were created with the courteous assistance of MediaFire
— a file host serving via Hypertext Transport Protocol. You may have observed
their advertisements on the interstitial page: I haven’t yet clicked one, but I
guess they might be OK — if not, then wouldn’t BBB complaints have been filed?

And here is a faux press release I’ve been working on since January…

  _Toys for Tots_ not as enthusiastic about introducing children to Falstaff.

Archivist Thor King once again spins a dreidel squarely into the Public Domain
with his much trumpeted posting today of MLPTK's officially final edition.

The composition, titled "MLPTK", contains his portfolio: a simple command line
tool written in JavaScript for use with Web browsers, as well as assorted other
"sideshows" sufficing quotidian archival tasks. In these latter, work continues.

Full to brimming with thousands of lines of invective artfully hidden among tens
of thousands of lines of source code, Thor's publication -- not as much textbook
as periodical, considering his publication schedule -- is both an indispensable
companion to the casual programmer and an ominous reminder of what Wyrd sets in
store for unlucky engineers: namely, the affection of rodents.

A cursory bibliography is included.

Included also: assorted trinkets & curios collected during the Worldwide Web's
toddling days -- late 1990s through about 2010, when Internet access in the USA
had grown ubiquitous but before the only use we ever put to it was gift shopping
-- and items from his unique body of knowledge, the swashbucklers' lore.

Like asking a grown man why he carries his midday meal in a child's lunchbox,
inquiring of Thor why he does not restrict his archive to only those items of
immediate utility (or indeed, even to his own exclusively) is just Not Done(TM).

As a bovine might deposit a patty of brown gold in a happy orchard as it grazes
its way past, the portfolio (as it is typeset for PDF format) also includes the
autobiography of a vagabond, replete with rhapsodical reprisal of recollection:
a fantastic story of intrigue is belied by the writer's apparently (& actually)
mundane personal wont of tedious exactitude in mediocrity, although the tale is
hindered by its cumbersome and banal scrivening.

His reasoning regardless, we note that his book ("Yawnie's Whole: the complete
Yawnie, for Yawnie enthusiasts"), as set for A4 area, numbers aproximadamente
one thousand pages, of which perhaps half is in English and the rest in code.
One way or the other, "Yawnie's Whole" is a gaping chasm of analytical logic fit
to tie Gordian knots around the necks of capitalist pigs: cut them as you will.
The PDF file was created with the technical assistance of LaTeX via TeX Live, &
DocBook via DBLatex, with appearances by an all-star cast of GNU core utilities.

For those not yet initiated into the candy-striper's bespec{k,tac}led part-time
wonderland, and in addition to the PDF, Thor's portfolio is supplemented by yet
another archive containing colorfully syntax-highlighted HTML documents. With
these, Thor's intends to illustrate the so-called "look & feel" (ambience) of
his day-to-day working environment: which is, to paraphrase a line from the film
"Night Flyer" by Stephen King, redder than the Devil's eye on one side, blacker
than a woodchuck's ass on the other. (And it is not known to drink.)

Although Thor once cautioned children to speak to their parents about reading
his portfolio, due to force of law he now advises them to avoid it entirely: his
recent inclusion of several explicit portions renders him uncouth. Because, as
we all know, a child once warned is forever guarded, Thor discharges his further
obligation to the youngsters of the Internets and returns to his lab equipment.

The author lives in scenic Idaho, where he spends his days asleep and his nights
shipping furry slash fiction in thirty two languages.

Thor, 30, has written for two decades, pausing occasionally to pick his nose.

In his copious spare time, he keys source code using only his left pinky toe.

Unless a massive government conspiracy hangs like a thunderhead over your entire
way of life, you may be able to reach him at these additional locations:

         │ Thor King                               │
         │ 1433 Flannigan Creek Road               │
         │ Viola, ID 83872                         │
         │ United States of America                │
         │                                         │
         │ colonel32.dll@gmail.com                 │
         │ https://plus.google.com/+ThorYawnieKing │
         │ https://www.facebook.com/thor.king.524  │
         │ https://www.twitter.com/NotAYawnoceros  │

Automaton Empyreum: the Key to Pygnition. (Trivial File Transfer Protocol edition.)

(I have implemented the Trivial File Transfer Protocol, revision 2, in this milestone snapshot. If you have dealt with reprogramming your home router, you may have encountered TFTP. Although other clients presently exist on Linux and elsewhere, I have implemented the protocol with a pair of Python scripts. You’ll need a Python interpreter, and possibly Administrator privileges (if the server requires them to open port 69), to run them. They can transfer files of size up to 32 Megabytes between any two computers communicating via UDP/IP. Warning: you may need to pull out your metaphorical monkey wrench and tweak the network timeout, or other parameters, in both the client and server before they work to your specification. You can also use TFTP to copy files on your local machine, if for whatever reason you need some replacement for the cp command. Links, courtesy of MediaFire, follow:

Executable source code (the programs themselves, ready to run on your computer): http://www.mediafire.com/file/rh5fmfq8xcmb54r/mlptk-2017-01-07.zip

Candy-colored source code (the pretty colors help me read, maybe they’ll help you too?): http://www.mediafire.com/file/llfacv6t61z67iz/mlptk-src-hilite-2017-01-07.zip

My life in a book (this is what YOUR book can look like, if you learn to use my automatic typesetter and tweak it to make it your own!): http://www.mediafire.com/file/ju972na22uljbtw/mlptk-book-2017-01-07.zip


Title is a tediously long pun on "Pan-Seared Programming" from the last lecture.
Key: mechanism to operate an electric circuit, as in a keyboard.
Emporium: ein handelsplatz; or, perhaps, the brain.
Empyreuma: the smell/taste of organic matter burnt in a close vessel (as, pans).
Lignite: intermediate between peat & bituminous coal. Empyreumatic odor.
Pignite: Pokémon from Black/White. Related to Emboar & Tepig (ember & tepid).
Pygmalion (Greek myth): a king; sculptor of Galatea, who Aphrodite animated.

A few more ideas that pop up often in the study of computer programming: which,
by the way, is not computer science. (Science isn't as much artifice as record-
keeping, and the records themselves are the artifact.)

As Eric Steven Raymond of Thyrsus Enterprises writes in "The Art of Unix
Programming," "keep it simple, stupid." If you can take your programs apart, and
then put them back together like Lego(TM) blocks, you can craft reusable parts.

A kind of object with methods (functions) attached. These are an idiom that lets
you lump together all your program's logic with all of its data: then you can
take the class out of the program it's in, to put it in another one. _However,_
I have been writing occasionally for nearly twenty years (since I was thirteen)
and here's my advice: don't bother with classes unless you're preparing somewhat
for a team effort (in which case you're a "class" actor: the other programmers
are working on other classes, or methods you aren't), think your code would gain
from the encapsulation (perhaps you find it easier to read?), or figure there's
a burning need for a standardized interface to whatever you've written (unlikely
because you've probably written something to suit one of your immediate needs:
standards rarely evolve on their own from individual effort; they're written to
the specifications of consortia because one alone doesn't see what others need).
Just write your code however works, and save the labels and diagrams for some
time when you have time to doodle pictures in the margins of your notebook, or
when you _absolutely cannot_ comprehend the whole at once.

This is a kind of data structure in C. I bet you're thinking "oh, those fuddy-
duddy old C dinosaurs, they don't know what progress is really about!" Ah, but
you'll see this ancient relic time and again. Even if your language doesn't let
you handle the bytes themselves, you've got some sort of interface to them, and
even if you don't need to convert between an integer and four ASCII characters
with zero processing time, you'll still need to convert various data of course.
Classes then arise which simulate the behavior of unions, storing the same datum
in multiple different formats or converting back and forth between them.
(Cue the scene from _Jurassic Park,_ the film based on Michael Crichton's book,
 where the velociraptor peeks its head through the curtains at a half-scaffolded
 tourist resort. Those damn dinosaurs just don't know when to quit!)

The most amusing use of void*s I've imagined is to implement the type definition
for parser tokens in a LALR parser. Suppose the parser is from a BNF grammar:
then the productions are functions receiving tokens as arguments and returning a
token. Of course nothing's stopping you from knowing their return types already,
but what if you want to (slow the algorithm down) add a layer of indirection to
wrap the subroutines, perhaps by routing everything via a vector table, and now
for whatever reason you actually _can't_ know the return types ahead of time?
Then of course you cast the return value of the function as whatever type fits.

Washing brights vs darks, convenience, convenience, & convenience, respectively.
Don't forget: convenience helps you later, _when_ you review your code.

These are a treelike structure, or should I say a grasslike structure.
I covered binary trees at some length in my fourth post, titled "On Loggin'."

The reason why you need recursion is to execute depth-first searches, basically.
You want to get partway through the breadth of whatever you're doing at this
level of recursion, then set that stuff aside until you've dealt with something
immensely more important that you encountered partway through the breadth. Don't
confuse this with realtime operating systems (different than realtime priority)
or with interrupt handling, because depth-first searching is far different than
those other three topics (which each deserve lectures I don't plan to write).

Jet airplanes, video games versus file indexing, & how not to save your sanity.

A paradigm appearing in such pleasant languages as Python and Icon.
Generators are functions that yield, instead of return: they act "pause-able,"
and that is plausible because sometimes you really don't want to copy-and-paste
a block of code to compute intermediate values without losing execution context.
Generators are the breadth-first search to recursion's depth-first search, but
of course search algorithms aren't all these idioms are good for.
Suppose you wanted to iterate an N-ary counter over its permutations. (This is
similar to how you configure anagrams of a word, although those are combinations
-- for which, see itertools.combinations in the Python documentation, or any of
the texts on discrete mathematics that deal with combinatorics.) Now, an N-ary
counter looks a lot like this, but you probably don't want a bunch of these...
    var items = new Array(A, B, C, D, ...);       // ... tedious ...
    var L = items.length;                         // ... lines ...
    var nary = new Array(L);                      // ... of code ...
    for (var i = 0; i < L; nary[i++] = 0) ;       // ... cluttering ...
    for (var i = L - 1; i >= 0 && ++nary[i] == L; // ... all ...
        nary[i--] = ((i < 0) ? undefined : 0)     // ... your other ...
    ) ; // end for (incrementation)               // ... computations ...
... in the middle of some other code that's doing somewhat tangentially related.
So, you write a generator: it takes the N-ary counter by reference, then runs an
incrementation loop to update it as desired. The counter is incremented, where-
upon control returns to whatever you were doing in the first place. Voila!
(This might not seem important, but it is when your screen size is 80 by 24.)

(Boodle (v.t.): swindle, con, deceive. Boodle (n.): gimmick, device, strategy.)
Because this lecture consumed only about a half of the available ten thousand
characters permissible in a WordPress article, here's a PowerPoint-like summary
that I was doodling in the margins because I couldn't concentrate on real work.
Modularity: perhaps w/ especial ref to The Art of Unix Programming. "K.I.S.S."
Why modularity is important: take programs apart, put them together like legos.
Data structures: unions, classes.
Why structures are important: atomicity, op overloading, typedefs, wrappers.
linked lists: single, double, circular. Trees. Binary trees covered in wp04??
recursion: tree traversal, data aggregation, regular expressions -- "bookmarks"
Generators. Perhaps illustrate by reference to an N-ary counter?

Suppose someone is in a coma and their standing directive requests you to play
some music for them at a certain time of day. How can you be sure the music is
not what is keeping them in a coma, or that they even like it at all? Having
experienced death firsthand, when I cut myself & bled with comical inefficiency,
I can tell you that only the dying was worth it. The pain was not, and I assure
you that my entire sensorium was painful for a while there -- even though I had
only a few small lacerations. Death was less unpleasant with less sensory input.
I even got sick of the lightbulb -- imagine that! I dragged myself out of the
lukewarm bathtub to switch the thing off, and then realized that I was probably
not going to die of exsanguination any time soon and went for a snack instead.

"You need help! You are insane!"
My 1,000 pages of analytical logic versus your plaintive bleat.

Pan Fried Programming

(Here's the update -- nothing much is new:
MLPTK: http://www.mediafire.com/file/m3u25i445lqkztb/mlptk-2016-12-16.zip
Source Highlight: http://www.mediafire.com/file/ygxb14ie94cwcuy/mlptk-src-hilite-2016-12-16.zip
Book: http://www.mediafire.com/file/vg439qruq3do90q/mlptk-book-2016-12-16.zip

Remedial (adj.): intended to rectify, amend, heal.
Panacea (n., myth): goddess of healing, daughter of Aesculapius.
Pansear (n.): Chili's Pokémon.

This remedial lecture will tersely cover a semester's curriculum,
similar to what you have learnt in your high school algebra class,
comprising the fundamentals of programming with synthetic languages
(those that are above machine code).

If you don't know what computer programming is, I would recommend that you study
some tutorials & encyclopedia articles. Much is available on the WWW (Worldwide
Web). The Web is a part of the Internet, and it is the Web you access from your
Web browser when you navigate to a Web page. You could also try one'a them there
"<name of programming language> For Dummies" textbooks: the "For Dummies" books
are excellent "Cliff's Notes"-style crash courses, and each aims to be similar
to a "101" course in the topic advertised.

To make a beginning with any programming language, all you must know is that a
computer computes: your instructions, issued in the program you write, tell the
machine how to progress from its input or initial state to a resultant output or
final state. These instructions look different in different languages -- some
languages require more or fewer -- but every computer program is an algorithm,
or "recipe for computation."

Computers and computer programs can be characterized as finite state automata.
They're like assembly-line robots who know where to weld each sheet of metal.
Also like assembly-line robots, they are "blind" in the sense that they'll kill
you with the soldering iron should you step between it and the sheet.
Computing machines do what they're told, even when it is particularly stupid:
that's why computer viruses, worms, and computer espionage exist.

In simplest terms, the computer's processing units receive some numbers and an
instruction that says what mathematical operation to execute, then operates:
like a calculator. High-level programming languages are more synthetic, like a
human language is, and comprise such ideas as objects (amalgamations of data) &
functions (modular sub-routines). Compilers or interpreters read these languages
and translate them into machine instructions, simplifying the lengthy series of
instructions necessary to make the calculator execute these difficult tasks.

In a high-level language, there are few technical concerns.
You can begin immediately with the abstract concepts.
Here are some:

As in algebra, a variable is a name that represents a value.
As in solving a system of equations, values are typically assigned to some vars
and the value of the other variables is computed using the values given.
For example, in Javascript:
    var a = 2;
    var b = a + 2;
The variable <b> is now equal to 2 + 2. Similar operations function similarly.
In Javascript and other very-high-level languages, variables aren't only scalars
and can point at any object. They're like placeholders for procedure.
Although "variable" implies a value stored in memory, and "identifier" only its
mnemonic, the words "variable" & "identifier" used loosely mean about the same.
    "Just don't try that with the Captain."
        -- Geordi LaForge, to Data, _Star Trek: the Next Generation._

These are important ideas that are abstracted away in VHLLs. A pointer stores an
address in memory, for a later indirect read/write or similar operation. In HLLs
a pointer/reference accesses an object directly instead of copying its value.
You'll rarely have to make the distinction in Javascript; but, for example:
    var a = new Array(1, 2, 3); // a[0] == 1, a[1] == 2, a[2] == 3
    var b = a; // Incidentally, b === a, and that is why in the next line...
    b[0] = 555; // ... b[0] == 555, and now a[0] also == 555!
As opposed to:
    var c = new Array(3); // c is a new array of length 3
    c[0] = b[0]; c[1] = b[1]; c[2] = b[2]; // copy scalar values one-by-one
    c[0] = 0; // c[0] == 0, but b[0] remains == a[0], which remains == 555.
    var d = 2;
    var e = d;
    e = 4; // e == 4, but d is still == 2.
As you can see, operating on an object (such as via array subscript operation)
changes the object, even if the object is pointed by multiple variables.
Likewise, objects passed as the argument of a function are passed by reference:
they aren't simply copied, and operating on the argument within the function is
equivalent to changing the object, whose scope is above that of the function.
Some high-level languages, like C, permit you to explicitly specify what is a
pointer or reference, which eliminates some of this confusion but requires more
exacting attention to detail in your design specification.

The state of a program is the value of all its variables, the current location
within the instruction set, and the environment of the operating system (or the
interpreter). In Javascript, within Web browsers, the browser typically provides
access to some of its state via the Document Object Model.

Heuristics, or "guesswork," could not exist if there were no way to execute some
different code depending on the state of the program. Furthermore there are some
mathematics you can't write as exactly one set of instructions that produces one
semantic value: for instance, a function defined only on an interval, or an even
root of a positive number. In this circumstance, you are writing branches:
    if (5 > 10) { /* of course, the code in this block never happens. */ }
    else if (2 < 0) { /* neither does this, b/c cond'n is also false. */ }
    else { /* but all of this code happens, because the others didn't. */ }
... One of the branches executes, and the others don't.
The part in parentheses is the "conditional statement:" it's evaluated as either
"true" or "false," like in Boolean logic. 

Identifiers are only valid within the block (curly brackets, or { ... }) where
they were declared. Well, they're supposed to, anyway. Therefore, if you declare
a variable inside a function, you can't use it outside of the function or within
another function. Why would you want to, anyway? The next time you invoked the
function, the value of the variables you were using in there would change again.

Computers are great at repetition. Loops repeat a set of instructions: they are
typically written as a prefix, conditional, postfix, and body. For example:
    for (var T = 10; T > 0; T--) { alert("T minus " + T); }
... which counts down from ten to one with annoying alert popups.
While or do-while loops have only conditions & bodies.
A loop is an example of an "iterative algorithm." Each time the loop's body is
executed, it's called an "iteration." In computing fractal geometric patterns,
"iteration" means more like "recursion:" which, see below.

A function is a modular segment of your program: a sequence of computation that
is repeated a few times, or can be reused as part of another computation.
Functions are "invoked," or called by name, with values supplied as arguments,
and return a value, similarly to how functions behave in algebra. When declaring
a function, you'd typically write the name of the function followed by its args
in parentheses and then the function body. For example, again in Javascript:
    function intp (N) { return (N % 1) == 0; } // integer predicate
... which returns true if N is probably an integer, or whole number:
    if (intp(5)) { alert("Yes. 5 is probably an integer."); }
    if (intp(5.55)) { alert("This box never appears..."); }
    else { alert("... but this one does, because 5.55 is a floater."); }
(Floating-point numbers are inaccurate, in Javascript as likewise elsewhere.)

A function that invokes itself is a recursive function. Any function invoking an
other function, which subsequently causes the original function to be invoked
again, causes a recursion-like situation that I think is called "re-entrancy."
It is essential to note that _any_ and _every_ recursive function you can write
for a computer to execute can be rewritten as an iterative algorithm. The proof
of this is complex: it follows from Alan Turing's model of finite state automata
and the read-execute model of arithmetic and logic units (CPUs), and basically
asserts that you'd never be able to execute recursion if you couldn't do it by
reading one instruction at a time. In other words, each time your function calls
itself again, it's simply storing its state in memory temporarily while the
machine executes a fresh copy: after the copy is done, the former state is re-
loaded, and execution proceeds from there. This is achieved with stacks: data
structures that grow in size as more is "pushed" onto them, and shrink when some
is "popped" off of the top.

An object is a collection of data that comprises a several datum. That is, when
data are related to one another, they can be envisioned as a "shape" or "motion"
that is the sum of its parts. For example, a vector has direction and magnitude;
an individual has a first and last name; a parser has an input stream, a stack,
and a procedure. In Javascript, you'd write something like this:
    function Blah (newz) { if (newz) { this.z = newz; } return this; }
    Blah.prototype = new Object();
    Blah.prototype.z = 555;
    Blah.prototype.tell_me_z = function () { return this.z; }
    var a = new Blah(222), b = new Blah(); // a.z == 222; b.z = 555.
... syntax varies among languages. Essentially an object is a data structure
containing some members ("variables" attached to the object, like Blah::z above)
and, if the object is a class, some methods (functions, like ::tell_me_z).


(Here be an update, as of November 8th, 2016. Me old war wound be actin’ up too much, and I think these’ll be the last for some time.





Ahoy, mateys. Today be the nineteenth of September — ye’d be better knowin’ it as International Talk Like A Pirate Day — and I’ll wager that upon this fine occasion ye’d be askin’ yerselves: “where’s me booty? ”

Well, and I’d make a poor excuse for a captain if I couldn’t deliver ye at least that! (But avast: ye might be findin’ it somewhat unholy, and parental discretion be even more advisable than in previous revisions.) I have prepared for ye a fine trove o’ source code, the likes of which are fit for Kings. Although me mother be the only one likely to find it interestin’, I’ve also put the finishin’ touches on me preliminary sketch of a typesetter for me book: “Yawnie’s Whole: the Complete Yawnie, for the Yawnie Enthusiast.” These be available in three chests, or what ye might be callin’ “Zip Arr-chives,” which I be uploadin’ to Mediafire as per usual.

Me latest revision of MLPTK be here…
… and be comprisin’ not much different from the last MLPTK, again as usual, except that I were fixin’ bugs. I report with most contrition that Polyfac be a failure: I be tryin’ to return me attention to the other tasks I failed to complete this year.

If ye prefer to be tastin’ th’ rainbow, a set of syntax-highlighted HTML documents illustratin’ the source code be here…
… they scry as nearly as possible alike to me own development environment.

Would ye like me book? I be certain to update and revise it as time be passin’, but who knows if me accounts shan’t be commandeered in the interstice? If ye be at all interested, don’t hesitate: supplies be unlimited, but tempus fugit…
… and, someday, me literature be gone forever, as literature inevitably shall.

And there be little more to say about this revision, as I’ve prepared no new lectures since April.

In the meantime, have ye noticed how beautiful life can be sometimes? Quite apart from th’ hardship and pain, there be especial bounty of resources. If ye be readin’ this, then ye would be privileged to Internet access, which are a rare treasure: there be all sorts o’ literature & art to be found, plenty of amusin’ diversions, and certainly no shortage of comely wenches to descry.

Me meaning be: ye could probably spend yer whole lives havin’ not a thing but a netbook computer, occasional access to electrical power, and some sort o’ shelter to protect ye from the elements. A “sex tent,” if ye will: just be addin’ some wenches. Why, I can imagine that no few individuals upon this blasted globe could be livin’ their lives contented with a shelter and a wench — wenches of the world bein’ blessed not to be needin’ anywench else.

Childhood be another of those times. As I grew, I were witness to what some would be describin’ as the “Wild West” of the World Wide Web. Nearly every outlet of popular culture were findin’ its way into troves and hoardes shared worldwide by generous scoundrels (and belligerent litigious bilge rats) to an audience of hundreds of millions. The vast serpent of DHTML and jQuery had only just been sighted far afore, and the stars fated to portend swashbucklin’ adventure at every second of the compass.

There was, too, a massive population of reputable sailors upon the vast waters of cyberspace. I remember some of the finest: OverClocked ReMix, VGMusic. Angelfire, Tripod, and Geocities. Neopets. The Merchant Guild. 4chan. So many more motes be floatin’ in the eye of history that I cannot even recount. Ah, the world were bigger then, and me eyes wide in childlike wonder.

Well, and it were the best of times, but me swashbucklin’ days be sadly behind me. (Arr, insofar as I cannot swash without me bucks! Besides that, me galleon be in disrepair, and overhaul be veritably a tribulation. However, as usual, be sendin’ me no money, for I cannot guarantee that it shall ever arrive; nor could I be certain it would help if it did.) As it happened, although I were studyin’ me life’s work throughout me life, me attention were turnin’ too late to serious programmin’ (peradventure, alas!), and circumstances be such that I envision failure to accomplish writing the parts of me portfolio I’d intended to finish this year.

(Happily I were not askin’ for research grants, considerin’ me doldrums.)

I be in pain; and, in light of this, tried to pass along what few ideas I were able to sustain the concentration to write before I be entirely unable to do so. They be in me ephemerides, toward page 950.

The spring be another of those times when life be less painful than it’s usually. I tell ye there be nothing like the sensation of warm sunlight on yer skin for the first time in months. Which are even assumin’ ye survived th’ winter — in the frigid North, for example, ye might be a popsicle if ye aren’t careful.

And let’s be not forgettin’ lemons…

Ah, but me ramblin’ be more piteous than a scurvy dog.

Enjoy me work.



Here be a ninja update fer th’ new year, 2017.

Ever wanted t’ shred data? Here be a tip:

dd -if /dev/random -of /dev/sda

will shred your ENTIRE HARD DISK /dev/sda irreversibly.

The file system be destroyed the instant you hit enter. There be no confirmation.

Shred it all night long, then when ye wake in the mornin’ do this before work:

dd -if /dev/urandom -of /dev/sda

to drop a load on yer disk that be heavier’n fifteen spars on a dead man’s chest.

Seriously. This be how to erase yer disks so thoroughly even the C.I.A. shall never espy yer dirty secrets.

Sleep tight, mateys.

A Midsummer Report.

Here are some updates on my progress:

https://www.mediafire.com/?zcc0pq81u001k4w (or http://www.mediafire.com/download/zcc0pq81u001k4w/mlptk-2016aug12.zip )

^- This one contains a snapshot of my MLPTK directory as of last night shortly before I endured my nightly battle with pain that keeps me awake. It’s a couple’a megs (zipped) or about three megabytes (inflated). Download this if you only want the MLPTK software and reference materials.


https://www.mediafire.com/?3lxoqrocmmm5byc ( or http://www.mediafire.com/download/3lxoqrocmmm5byc/mlptk-report-2016-08-12.zip )

^- This one contains a tasty treat! I have rewritten my automatic typesetter for today’s report, and there are now available some syntax highlighted HTML documents that make the code very much easier to read. There are some cute PDFs, too, for printing. DocBook was a very convenient format to get started with, but I hope with future revisions I will graduate from the training wheels and learn to use LaTeX / PostScript. The report is about thirty megabytes (zipped) or fifty megabytes (inflated). Download this if you would like to preserve my work in “Dead Tree” format. (Yes, I’m pretty sure that all the PDFs with my name on them are actually my own work, thus the “Author” bit in the typesetter. I deleted all the PDFs that I identified as not being my own work. Yes, it will require over four hundred pages if you print it. No, I’m not done writing.)


I have been working on MLPTK, and other projects, but have nothing of any value to report. Sadly, I stalled-out on QL and everything, and I don’t think I can publish anything complete in 2016 as I had hoped.

However, I _have_ made a good run at finishing every part of QL that I set out to write last Christmas. Also, I have run a quick test on the Firefox bundled with a recent version of Lubuntu: ironically, the _horrendous QL speed bug_ has no perceptible effect on execution time in that version! (I’m still going to try and fix it, though, because my development machine is still on the elder version.)

Apart from crashing and burning with QL, I have begun a new C++ project called Sparkster (after the name of the titular protagonist of Rocket Knight Adventures) which will be a simple exercise in simulating kinetics; I still haven’t started YawniePong 2 because I need to begin a three dimensional rendering library for Javascript if I want to make it into Return to Thunderdome; and I have written a new module for MLPTK, based on Polynom, called Polyfac — although it is practically useless.

Since the last revision I have also written a few other modules, and fixed sundry bugs. See the history log for more details.


P.S. The header image easter-egg has also changed. Again.

Palling around.

Pall (n.): pawl.

I couldn't write last week, and my upgrade to QL has progressed no further.
For reference, I stalled before comparing the efficiency of nested Objects to
that of nested Arrays, which I must test before experimenting further with the
prototype compiler or even refining the design. I intend to do that this month.
In the meantime, here's a snapshot of MLPTK with new experiments included.


And a correction to my brief about the grammar ("Saddlebread"): actually, the
InchoateConjugation sequence does not cause differentiation, because the OP_CAT
prevents the original from reducing. Other parts may be inaccurate. I'll revise
the grammar brief and post a new one as soon as I have fixed the QL speed bug.

I took some time out from writing Quadrare Lexema to write some code I've been
meaning to write for a very long time: pal9000, the dissociated companion.
This software design is remarkably similar to the venerable "Eggdrop," whose C
source code is available for download at various locations on the Internets.
Obviously, my code is free and within the Public Domain (as open as open source
can be); you can find pal9000 bundled with today's edition of MLPTK, beneath the
/reference/ directory.

The chatbot is a hardy perennial computer program.
People sometimes say chatbots are artificial intelligence; although they aren't,
exactly, or at least this one isn't, because it doesn't know where it is or what
it's doing (actually it makes some assumptions about itself that are perfectly
wrong) and it doesn't apply the compiler-like technique of categorical learning
because I half-baked the project. Soon, though, I hope...

Nevertheless, mathematics allows us to simulate natural language.
Even a simplistic algorithm like Dissociated Press (see "Internet Jargon File,"
maintained somewhere on the World Wide Web, possibly at Thyrsus Enterprises by
Eric Steven Raymond) can produce humanoid phrases that are like real writing.
Where DisPress fails, naturally, is paragraphs and coherence: as you'll see when
you've researched, it loses track of what it was saying after a few words.

Of course, that can be alleviated with any number of clever tricks; such as:
	1. Use a compiler.
	2. Use a compiler.
	3. Use a compiler.
I haven't done that with p9k, yet, but you can if you want.

Of meaningful significance to chat robots is the Markov chain.
That is a mathematical model, used to describe some physical processes (such as
diffusion), describing a state machine in which the probability of any given
state occurring is dependent only on the next or previous state of the system,
without regard to how that state was encountered.
Natural language, especially that language which occurs during a dream state or
drugged rhapsody (frequently and too often with malicious intent, these are
misinterpreted as the ravings of madmen), can also be modeled with something
like a Markov chain because of the diffusive nature of tangential thought.

The Markov-chain chat robot applies the principle that the state of a finite
automaton can be described in terms of a set of states foregoing the present;
that is, the state of the machine is a sliding window, in which is recorded some
number of states that were encountered before the state existent at the moment.
Each such state is a word (or phrase / sentence / paragraph if you fancy a more
precise approach to artificial intelligence), and the words are strung together
one after another with respect to the few words that fit in the sliding window.
So, it's sort of like a compression algorithm in reverse, and similar to the way
we memorize concepts by relating them to other concepts. "It's a brain. Sorta."

One problem with Markov robots, and another reason why compilers are of import
in the scientific examination of artificial intelligence, is that of bananas.
The Banana Problem describes the fact that, when a Markov chain is traversed, it
"forgets" what state it occupied before the sliding window moved.
Therefore, for any window of width W < 6, the input B A N A N A first produces
state B, then states A and N sequentially forever.
Obviously, the Banana Problem can be solved by widening the window; however, if
you do that, the automaton's memory consumption increases proportionately.

Additionally, very long inputs tend to throw a Markov-'bot for a loop.
You can sorta fix this by increasing the width of the sliding window signifying
which state the automaton presently occupies, but then you run into problems
when the sliding window is too big and it can't think of any suitable phrase
because no known windows (phrases corresponding to the decision tree's depth)
fit the trailing portion of the input.
It's a sticky problem, which is why I mentioned compilers; they're of import to
artificial intelligence, which is news to absolutely no one, because compilers
(and grammar, generally) describe everything we know about the learning process
of everyone on Earth: namely, that intelligent beings construct semantic meaning
by observing their environments and deducing progressively more abstract ideas
via synthesis of observations with abstractions already deduced.
Nevertheless, you'd be hard-pressed to find even a simple random-walk chatbot
that isn't at least amusing.
(See the "dp" module in MLPTK, which implements the vanilla DisPress algorithm.)

My chatbot, pal9000, is inspired by the Dissociated Press & Eggdrop algorithms;
the copy rights of which are held by their authors, who aren't me.
Although p9k was crafted with regard only to the mathematics and not the code,
if my work is an infringement, I'd be happy to expunge it if you want.

Dissociated Press works like this:
	1. Print the first N words (letters? phonemes?) of a body of text.
	2. Then, search for a random occurrence of a word in the corpus
	   which follows the most recently printed N words, and print it.
	3. Ad potentially infinitum, where "last N words" are round-robin.
It is random: therefore, humorously disjointed.

And Eggdrop works like this (AFAICR):
	1. For a given coherence factor, N:
	2. Build a decision tree of depth N from a body of text.
	3. Then, for a given input text:
	4. Feed the input to the decision tree (mmm, roots), and then
	5. Print the least likely response to follow the last N words
	   by applying the Dissociated Press algorithm non-randomly.
	6. Terminate response after its length exceeds some threshold;
	   the exact computation of which I can't recall at the moment.
It is not random: therefore, eerily humanoid. (Cue theremin riff, thundercrash.)

A compiler, such as I imagined above, could probably employ sliding windows (of
width N) to isolate recurring phrases or sentences. Thereby it may automatically
learn how to construct meaningful language without human interaction.
Although I think you'll agree that the simplistic method is pretty effective on
its own; notwithstanding, I'll experiment with a learning design once I've done
QL's code generation method sufficiently that it can translate itself to Python.

Or possibly I'll nick one of the Python compiler compilers that already exists.
(Although that would take all the fun out of it.)

I'll parsimoniously describe how pal9000 blends the two:

First of all, it doesn't (not exactly), but it's close.
Pal9000 learns the exact words you input, then generates a response within some
extinction threshold, with a sliding window whose width is variable and bounded.
Its response is bounded by a maximum length (to solve the Banana Problem).
Because it must by some means know when a response ends "properly," it also
counts the newline character as a word.
These former are departures from Eggdrop.
It also learns from itself (to avoid saying something twice), as does Eggdrop.

In addition, p9k's response isn't necessarily random.
If you use the database I included, or choose the experimental "generator"
response method, p9k produces a response that is simply the most surprising word
it encountered subsequent to the preceding state chain.
This produces responses more often, and they are closer to something you said
before, but of course this is far less surprising and therefore less amusing.
The classical Eggdrop method takes a bit longer to generate any reply; but, when
it does, it drinks Dos Equis.
... Uh, I mean... when it does, the reply is more likely to be worth reading.
After I have experimented to my satisfaction, I'll switch the response method
back to the classic Eggdrop algorithm. Until then, if you'd prefer the Eggdrop
experience, you must delete the included database and regenerate it with the
default values and input a screenplay or something. I think Eggdrop's Web site
has the script for Alien, if you want to use that. Game over, man; game over!

In case you're curious, the algorithmic time complexity of PAL 9000 is somewhere
in the ballpark of O(((1 + MAX_COHERENCE - MIN_COHERENCE) * N) ^ X) per reply,
where N is every unique word ever learnt and X is the extinction threshold.
"It's _SLOW._" It asymptotically approaches O(1) in the best case.

For additional detail, consult /mlptk/reference/PAL9000/readme.txt.

Pal9000 is a prototypical design that implements some strange ideas about how,
exactly, a Markov-'bot should work. As such, some parts are nonfunctional (or,
indeed, malfunction actually) and vestigial. "Oops... I broke the algorithm."
While designing, I altered multiple good ideas that Eggdrop and DisPress did
right the first time, and actually made the whole thing worse on the whole. For
a more classical computer science dish, try downloading & compiling Eggdrop.

I will gladly pay you Tuesday for a Hnakkerbröd today.

Beware: when speaking to Trolls, listen carefully. It could save your ice hole.
        (Trolls are known for their skill in wintertime fishing.)

My software, courtesy of MediaFire:

https://www.mediafire.com/?ebbyj47e35mmytg (http://www.mediafire.com/download/ebbyj47e35mmytg/mlptk-qlupgradecomplete-awaitingspeedfix-27mar2016.zip)

This update (unlike the foregoing, which fixed the Opera bug) regards only QL.
Again: Quadrare Lexema is similar to GNU Bison. If an infringement, I'll delete
it as soon as I hear or see from you. BTW, Bison is time-tested; QL isn't.

Oh, and a correction to "First Rate?": Bison can indeed unshift multiple tokens
back onto its input stream, even though productions can't be multiple symbols in
length, by unshifting directly onto its input during reduction (which is how QL
does it too, during deferment, which amounts to the same exact thing because no
reason exists to compute anything during deferment -- otherwise, there'd be more
race conditions than the Kentucky Derby, which is very silly).

QL is now "kinda-sorta" debugged and functioning to my specification AFAICT. Now
the API has changed considerably from how it was last month (the argument vector
to reduction deferment class constructors has been modified, some new faculties
now exist, and some were removed); this necessitated additional instantiations
of "new Array()," and interolably reduces efficiency when operating on very long
inputs, but I wanted to hurry-up this design iteration. (That was one sentence.)

The token agglutination mechanism of the parser logic is the same as before.
Code to determine precedence & blocking has been abridged; toddling steps toward
a method to generate the parser as in-line code. (As you see, that isn't yet.)

I'm tempted to redo the infrastructure to reduce the number of new Array()s that
are instantiated during the parse phase, but I'm pretty sure I can do that by
rewriting the underlying code without changing the API. The interface between
the parser's stack extremum and its input stream is passed to reductions as an
Array(), but that doesn't mean it always has to be allocated anew.

Remember: the old Command Line Interpretation Translator scaffold isn't decided;
I left ::toTheLimit() where it was, pending a ::hatten() that shall suit you; if
you'd like to use the horrifying monstrosity that is my software architecture,
you can see Mr. Skeleton awaiting you in clit.js -- asking where is his flesh, &
rapidly becoming impatient with my poking and prodding him all day. Soon, Mr.
Skeleton; soon shall be the day when the hat is yours at last, & your calcareous
projection from within my library becomes a fully fledged automaton unto itself.

For the meantime I'm satisfied with the half-measure. I think the API is okay to
start building upon, so I'll start building. Overhaul of the back-end late this
year or early in the next, & it's looking good for me to furnish the CLIT before
the third quarter. Therefore I'd say: expect full CLIT functionality in 2016.

Before I apprise you of my progress so far, let's take a moment for a thoroughly
detailed technical analysis of Mr. Skeleton's bony protrusion.

Phoneme    <=    (EscapeSequence | AnyCharacter | Number | String)
                 (EscapeSequence | AnyCharacter | Number | String | Phoneme | )
	Concatenate a "word" that is one argument in an argument vector.

ISLDQ    <=    '\"'
	Open a <String>.

InchoateString    <=    (ISLDQ | InchoateString)
                        (OP_CAT | OP_CONJ | EscapeSequence | AnyCharacter
                         | Number | Space)
	Make strings out of any symbol following an open string.
	(As you can see, this rule must be rewritten...)

String    <=    InchoateString '\"'
	Close a <String>.

Argument    <=    Phoneme (Space | ) | Argument Argument
	Concatenate the argument vector comprising an executable MLPTK command.
	That bit with "(Space | )" should probably be just "Space".

Catenation    <=    (Argument | Group | Conjugation) OP_CAT
	Concatenate the output of commands.

MalformedGroupCohesion    <=    (Argument | Group | Conjugation) OP_CLPAR
	Automatically correct the user's malformed syntax where the last
	command in a parenthetical sub-grouping was not followed by a ";".

ExecutableInchoateConjugation    <=    Argument OP_CONJ | Blargument
	Signify that a command can be executed as part of a <Conjugation>.

InchoateConjugation    <=    Group OP_CONJ | Conjugation
	Convert a conjugated <Group>, or the output of a <Conjugation>,
	to an <InchoateConjugation> token that can form the left-hand
	part of a further <Conjugation>.
	This reduction causes parser stack differentiation, because it
	conflicts with "Catenation <= Conjugation OP_CAT".
	In that circumstance, the sequence "<Conjugation> <OP_CAT> ..."
	is both a "<Catenation> ..." and a "<InchoateConjugation> <OP_CAT> ...".
	Observe that the latter always produces a syntax error.
	I'm pretty sure I could rewrite the grammar of the <Conjugation> rule to
	fix this; IDK why I didn't. (Maybe a bug elsewhere makes it impossible.)

Conjugation    <=    (ExecutableInchoateConjugation | InchoateConjugation)
	Execute the command in the <ExecutableInchoateConjugation> at right,
	supplying on its standard input the standard output of that at left.

InchoateGroup    <=    (OP_OPPAR | InchoateGroup) Catenation
	Concatenate the contents of a parenthesized command sub-grouping.

Group    <=    InchoateGroup (OP_CLPAR | MalformedGroupCohesion)
	Close an <InchoateGroup>. Concatenate the contents of a
	<MalformedGroupCohesion> if it trailed.

CommandLine    <=    (CommandLine | ) Catenation
	Concatenate the output of <Catenation>s into one Array.
	This one actually doesn't differentiate. Either a <CommandLine> waits at
	left to consume a Catenation when it reduces, or something else does, &
	<Catenations> in mid-parse never reduce to <CommandLine>s except when
	fatal syntax errors occur, in which case the parser belches brimstone.
Blargument    <=    Argument (OP_CAT | OP_CLPAR)
    Duplicate the trailing concatenation operator or close parenthesis following
    an <Argument>, so that a <Conjugation> doesn't conflict with a <Catenation>
    or an <InchoateGroupCohesion>. I think this can be specified formally in a
    proper grammar, without the multiple-symbol unshift, but IDK how just yet --
    because (without lookahead) the parser can't know when the argument vector
    ends without seeing a trailing operator, so execution of the last command in
    the conjugation sequence <InchoateConjugation> <Argument> <OP_CAT> would
    occur when <Argument> <OP_CAT> reduces & executes, disregarding its standard
    input (the contents of the foregoing <InchoateConjugation>.
    "Blargument <= Argument" can never happen and "ExecutableInchoateConjugation
    <= Argument" would grab the <Argument> before it could concatenate with the
    next <Argument>, so I'm at a loss for how I should accomplish this formally.
    BTW, <Blargument> is the <WalkingBassline>, with trivial alterations.
    The <Blargument> reduction causes parser stack differentiation, because it
    conflicts with both <Catenation> and <MalformedGroupCohesion>. In either
    case, the <Blargument> branch encounters a syntax error & disappears
    when <Blargument> didn't immediately follow an inchoate conjugation; the
    other branch disappears in the inverse circumstance.

Token identifier   Operator precedence  Associativity
"Space", - - - - - 2, - - - - - - - - - "wrong",
"OP_CAT",  - - - - 0, - - - - - - - - - "wrong",
"EscapeSequence",  0, - - - - - - - - - "right",
"AnyCharacter",  - 0, - - - - - - - - - "right", (the sequence to the right of
"Number",  - - - - 0, - - - - - - - - - "right",  a right-associative token is
"String",  - - - - 0, - - - - - - - - - "right",  reduced first, except...)
"OP_OPPAR",  - - - 0, - - - - - - - - - "left",
"OP_CLPAR",  - - - 0, - - - - - - - - - "wrong", (... when wrong-associativity
"OP_CONJ", - - - - 0, - - - - - - - - - "wrong",  forces QL to reduce the right-
"QL_FINALIZE", - - 0, - - - - - - - - - "wrong"   associative sequence.)

The avid reader shall observe that my "wrong-associativity" specifier, when used
to define runs of right-associative tokens that stick to one another, is similar
to the lexical comparison & matching algorithm of a lexical analyzer (scanner).
In fact, as written, it _is_ a scanner. For an amusing diversion, try excerpting
the portions of the semantical analyzer (parser) that can be made into lexical
analyzer rules, then put them into the scanner; or wait a few months and I will.

But that's enough bony baloney.
If you preferred Mr. Skeleton as he was, see mlptk/old/clit.js.21mar2016.

As of probably a few days before I posted this brief, my upgrade to QL is now
sufficient to function vice its predecessor. I spruced-up Mr. Skeleton, so that
the test scaffold in clit.js now functions with ::hattenArDin() in QL, and now
everything looks all ready to go for shell arithmetic & such frills as that.

Ironically, it seems that I've made it slower by attempting to make it faster. I
 should have known better. I'll try to fix the speed problem soon; however,
until then, I've abandoned work on the Translator due to intolerable slowness.
I'm sorry for the inconvenience. If it's any help, I think the problem is due to
 too many new Array() invocations or too many nested Arrays, one of the two.
Either way, I intend to fix it this year by rewriting the whole parser (again)
as a static code generator.

I was also thinking of writing a windowing operating system for EmotoSys, but I
am uncertain how or whether to put clickable windows in the text console. I mean
-- it'd be simple now that QL's rolling, but maybe a more Spartan design? I will
post some flowcharts here when I've exhausted my ministrations to the CLIT.