Author Archives: Paulo Moura

Zipper lists in Prolog

I’m currently looking into zipper data structures. Searching the web for zippering lists for prolog, the third hit is this old blog post by Daniel Lyons (hi Daniel!):

But I don’t liked the calls to reverse/2 and append/3 and their implied performance hits. So, I just rewrote the code to eliminate the calls (and start list index at 1; this is not C! :-)

% zipper(+Position, +List, -Zip, -Element)
% where Zip = zip(Before, Element, After)
% index starts at 1

zipper(Position, List, Zip, Element) :-
    zipper(Position, List, [], Zip, Element).

zipper(1, [Head|Tail], Acc, zip(Acc,Head,Tail), Head).
zipper(N, [Head|Tail], Acc, zip(Before,Element,After), Element) :-
    N > 1,
    M is N - 1,
    zipper(M, Tail, [Head|Acc], zip(Before,Element,After), Element).

next(zip(Before,Element,[Head|Tail]), zip([Element|Before],Head,Tail)).

previous(X, Y) :-
    next(Y, X).

Some sample queries:

?- [zipper].
% zipper compiled 0,00 sec, 5 clauses

?- zipper(3, [1,2,3,4,5], Zip, X), next(Zip, Next).
Zip = zip([2, 1], 3, [4, 5]),
X = 3,
Next = zip([3, 2, 1], 4, [5]) .

?- zipper(3, [1,2,3,4,5], Zip, X), next(Zip, Next), previous(Next, Zip).
Zip = zip([2, 1], 3, [4, 5]),
X = 3,
Next = zip([3, 2, 1], 4, [5]) .

?- zipper(3, [1,2,3,4,5], Zip, X), previous(Zip, Previous).
Zip = zip([2, 1], 3, [4, 5]),
X = 3,
Previous = zip([1], 2, [3, 4, 5]) .

?- zipper(3, [1,2,3,4,5], Three, X),
   next(Three, Four), next(Four, Five), previous(Five, Four),
   previous(Four, Three), previous(Three, Two), previous(Two, One).
Three = zip([2, 1], 3, [4, 5]),
X = 3,
Four = zip([3, 2, 1], 4, [5]),
Five = zip([4, 3, 2, 1], 5, []),
Two = zip([1], 2, [3, 4, 5]),
One = zip([], 1, [2, 3, 4, 5]) .

I wonder how many curious Prolog programmers wrote a similar solution in the past. A cut can be added to the first clause of zipper/5 to eliminate a choice point. The zipper constructed is not the same (minus the index start) as in Daniel’s solution, however, as we can no longer simply concatenate Before+Element+After to get the original list. On the other hand, my solution follows the list example on the Wikipedia page:

Pros and cons of both solutions from an usage perspective? Still learning but this is fun programming :-) Eventually, I hope to add support for zipper data structures to the Logtalk library.

Structured Message Printing

Logtalk 3.x adds a structured message printing mechanism. This feature gives the programmer full control of message printing, allowing it to filter, rewrite, or redirect any message. The origins of the mechanism for message printing that inspired the Logtalk implementation go back to Quintus Prolog, where it was implemented, apparently, by Dave Bowen (thanks to Richard O’Keefe for the historical bits). This mechanism can also be found currently on e.g. SICStus Prolog, SWI-Prolog, and YAP.

Why a mechanism for printing messages? Consider the different components in a Logtalk application development and execution. At the bottom level, you have the Logtalk compiler and runtime. The Logtalk compiler writes messages related to e.g. compiling and loading files, compiling entities, compilation warnings and errors. The Logtalk runtime writes banner messages and handles execution errors that may result in printing human-level messages. The development environment can be console-based or you may be using a GUI tool such as PDT. In the latter case, PDT needs to intercept the Logtalk compiler and runtime messages to do its magic and present the relevant information using its GUI. Then you have all the other components in a typical application. For example, your own libraries and third-party libraries. The libraries may want to print messages on its own, e.g banners, debugging information, or logging information. As you assemble all your application components, you want to have the final word on which messages are printed, where, an in what conditions.

The Logtalk message printing mechanism provides you with a set of predicates, defined in the logtalk built-in object, and some hook predicates. Two of the most important predicates are logtalk::print_message(Kind, Component, Term), which is used for printing a message, and logtalk::message_hook(Term, Kind, Component, Tokens), a user-defined hook predicate used for intercepting messages. The Kind argument is used to represent the nature of the message being printed. It can be e.g. a logging message, a warning message or an error message, In Logtalk this argument can be either an atom, e.g. error, or a compound term, e.g. information(requested). Using a compound term allows easy partitioning of messages of the same kind in different groups. Messages are represented by atoms or compound terms, handy for machine-processing, and converted into a list of tokens, for human consumption. This conversion is performed using the non-terminal logtalk::message_tokens(Term, Component). A simple example is:

:- multifile(logtalk::message_tokens//2).
:- dynamic(logtalk::message_tokens//2).

logtalk::message_tokens(loaded_settings_file(Path), core) -->
    ['Loaded settings file found on directory ~w'-[Path], nl, nl].

The Component argument is new in the Logtalk implementation and is useful to filter messages belonging to a specific component (e.g. the Logtalk compiler and runtime is identified by the atom core) and also to avoid conflicts when two different components define the same message term (e.g. banner seems to be popular).

There are also predicates for printing a list of tokens, logtalk::print_message_tokens(Stream, Prefix, Tokens), for printing an individual token, logtalk::print_message_token(Stream, Token), and for setting default output stream and message prefixes, logtalk::message_prefix_stream(Kind, Component, Prefix, Stream). For example, the SWI-Prolog adapter file uses the print_message_token/2 hook predicate to enable coloring of messages printed on a console.

Using the message printing mechanism in your applications and libraries is easy. Simply chose a component name for your application, call logtalk::print_message/3 for every message that you may want to print, and define default translations for your message terms using the multifile non-terminal logtalk::message_tokens/2. For a full example, see e.g. the lgtunit tool. Happy coding!

Logtalk 3

After five months of private development, the first public development release of the third generation of Logtalk is available from the GitHub Logtalk account. The release notes of the first alpha version detail the work done so far. It’s marked as an alpha release mainly because is not feature-complete; most libraries, examples, and bundled contributions work flawlessly. However, existing Logtalk 2 applications will likely require a few changes, essentially due to removed or renamed compiler options. Using Logtalk conditional compilation directives should easily allow you to keep compatibility with Logtalk 2 while, at the same time, allow testing with Logtalk 3.

There are major changes and features on Logtalk 3 and some of them will be discussed here in detail on forthcoming posts. The current plan is to release the first stable version of Logtalk 3 on February 9, 2013. This will mark the 14th anniversary of the first stable release of Logtalk 2.

I’m now working full time on Logtalk development and consulting. I’m resigning from the permanent position at my university. But I’m keeping my researcher position at CRACS – INESC TEC, Portugal. Logtalk was born from my research on programming languages and I expect some of the future enhancements to result from continuing research in collaboration with the logic programming community.

You’re invited to provide early feedback in Logtalk 3 development. As a programming language, Logtalk 3 is expected to keep a high-degree of backward compatibility with Logtalk 2. But the new features of Logtalk 3 will make it easier to develop large applications and will give you more mature development tools. The list of Logtalk 3 compatible back-end Prolog compilers is not yet final, however. In a major policy change from Logtalk 2, Logtalk 3 development will no longer be hold back by the slow progress of Prolog compilers towards official and de facto standards.

WG17 changes course

This just in: WG17 changes course

Tired of being cursed by all for standardization problems and mishaps, the next ISO Prolog Core standard revision will mandate:

– Forward-chaining inference mechanism. Stated reason: you cannot move Prolog forward doing backward reasoning.

– Replacement of stream-based input/output with revamped, time-proved, Edinburgh-style input/output. Highlights: see_what/1 and told_you_so/0 built-in predicates for DWIM user-friendly semantics.

– New character escape 0'\q unexpectedly quits Prolog for those embarrassing programming moments.

– Due to all controversy regarding char_conversion/2, from now on all standards will be published in Esperanto.

– Attempting printing of cyclic terms will endlessly print the lyrics of “99 bottles of beer on the wall”.

– New operator class yfy for decomposing operands.

– Singleton variable report by read_term/3 is deprecated as it’s not politically correct to complain about a variable choice of life-style. In addition, for privacy reasons, the variable_names/1 option is also deprecated.

– New value for the unknown flag, true, provides a sharp decrease on the number of “no“s reported by Prolog interpreters. Specially relevant in educational environments, it will hopefully contribute to make the language more attractive to students.

– Database built-in predicates are enhanced with an optional argument for cloud computing. Handy for hiding your dirty programming tricks.

– The de facto standard freeze/2 predicate is added to the standard but with an extra argument that allows the user to specify a time-out value, freeing the goal to fulfill its destiny.

– Further details are still being worked out but stay tuned.

Hoping that no one here is humor-impaired, Happy April Fools’ Day :-)

A more sane implementation of the term-expansion mechanism

One of the oldest and more useful feature found in most Prolog compilers is the term-expansion mechanism. Acting as a souped-up pre-processor, defining term- and goal expansion clauses allows us to rewrite terms and goals as their are read from a source file and apply all kinds of transformations. This made term-expansion the preferred mechanism for implementing all sorts of extensions to Prolog.

You may be wondering if the Logtalk compiler is also implemented using the term-expansion mechanism. The answer is no. One of the main reasons is that the term-expansion mechanism is not implemented by all Prolog compilers. Among those that do implement term-expansion, there are also some minor (and not so minor) syntax and semantics differences. The real trouble with term-expansion results, however, from its usual implementation and usage patterns, combined with module features, not from those portability issues.

The usual pattern when implementing some Prolog extension using the term-expansion mechanism is to define a module, relying on term- and goal-expansion clauses to compile to standard Prolog code the syntactic elements defined by the extension. As the recommended way of using modules is to simply use a use_module/1 directive to make the module resources available in your current context (how convenient and easy is to shoot yourself in the foot… but I digress), the term_expansion/2 and goal_expansion/2 predicates are declared as multifile predicates, with the clauses ending up either on the user module or on a special system module. Either way is fine until you try to use more than one module that defines term_expansion/2 clauses. The Prolog compiler will try term_expansion/2 clauses until it finds one that succeeds for the term being expanded or until there are no more clauses left to try (the goal_expansion/2 predicate, however, is called recursively until no more goal-expansion clauses apply). Assuming that no two Prolog modules want to expand the same term (one can always hope), there should no problem. Sure, there might be a performance issue due to trying and failing term_expansion/2 clauses until the correct one is selected. But what happens if two modules compete for expanding the same term? Say, the end_of_file term. Well, if the module developers are not aware of the problem, one of them will likely lose. Each one? That will depend on the modules loading order. The usual workaround is to define term_expansion/2 clauses that perform their magic using side-effects to record the results and fail when done. The failure leads to backtracking, giving other term_expansion/2 clauses a chance to be applied. Ugliness of using side-effects apart, there is a more sane way of implementing and using the term-expansion mechanism.

One of the advantages of not being first (to design and try a new mechanism) is that you can learn from both the successes and mistakes of others before you. You also have a significant advantage by not having to care about breaking backward compatibility. The implementation of term-expansion in Logtalk differs from the implementation found on most Prolog compilers in two crucial aspects.

First, Logtalk doesn’t support using the term- and goal expansion clauses defined in an object (or source file) to expand the object (or source file) itself. It’s already bad enough that some predicate directives must precede the compilation of calls to those predicates. But having the result of the compilation of an object (or source file) depend on the order of the predicate definitions in the same object (or source file) feels plain wrong. Specially as it’s an exception to the way both Logtalk and Prolog compilers work. Just imagine being forced to define all predicates called by a predicate before it could be defined. It will be painful. It would also be impossible in some cases. Yet, well know Prolog extensions do just that, throwing portability down the drain (not all Prolog compilers make predicate definitions visible and usable, as soon as they are compiled, without waiting for the rest of the source file to be compiled…).

Second, term- and goal-expansion clauses are defined local to the object where they are defined. It’s possible to add those clauses to the pseudo-object user (Logtalk supports multifile object predicates). But that is neither necessary or advised. Do we really want to put all our eggs… err… term-expansion hooks in the same basket?

So, what’s the magic incantation to use term-expansion in Logtalk? Easy. Objects containing clauses for the term- and goal expansion predicates are known as hook objects. When compiling a source file, you use a compiler option to state which hook object should be used to term-expand the source file. For example, assuming a hook object named my_expansion we could write:

| ?- logtalk_load(source_file, [hook(my_expansion)]).

This compiler option also provides a nice solution for combining different hook objects in order to expand the same source file. You simply define another hook object that calls the term- and goal-expansion predicates defined in the base hook objects. This allows fine control on how the different expansions will work together. For example, we can define a pipeline of goal-expansions. Or apply all term-expansions in parallel and combine the resulting terms. For some sample code, check the expanding example in the current Logtalk distribution. Or browse the example source code on-line:

Even when a source file is to be expanded using a single hook object, we can be ensured that the compilation time will not be adversely affected by other hook objects that might be loaded at the time of the compilation. The code also becomes easier to debug as only the relevant term-expansion clauses will be in focus.

P.S. It’s worth noting that the Logtalk term-expansion implementation and recommended usage patterns can be easily adopted by Prolog module systems. In that regard, it’s also worth noting that some Prolog compilers, e.g. SICStus Prolog and Ciao Prolog, already include improved implementations of term-expansion mechanisms.

Coding guidelines and the spaces-versus-tabs holy war

Logtalk, like most programming languages, defines a set of coding guidelines that aim to improve the quality and readability of source code:

These coding guidelines are also mandatory for contributions to the Logtalk distribution. Most guidelines in the above document are pretty consensual but one of them, source code layout and indentation, always stirs a lot of discussion:

Format your source file using tabs, not spaces.

Search the web and you can easily find passionate texts defending the use of either tabs or spaces for source code layout and indentation. Recently, I was commenting on a paper on Prolog coding guidelines that stated:

2.1 Indent with spaces instead of tabs.

You cannot normally predict how tabs will be set in the editors and browsers others will use on your code. Moreover, mixing tabs and spaces makes searches and substitutions more problematic. All in all, it is better not to use tabs altogether: almost any editor can be set to substitute spaces for tabs automatically when saving your file.

Take the first sentence. It completely misses the point of using tabs instead of spaces. Try this. Open any of the many examples distributed with Logtalk in your favorite text editor. The example source code is formatted using tabs. Next go to your text editor preferences and adjust the tab size to your liking. I prefer a tab size equivalent to 4 spaces. You may prefer a tab size equivalent to 2 spaces. Or 3 spaces. Or 6 spaces. No matter your choice, the code will remain perfectly indented. That means that I’m not imposing on you my indentation preferences. If someone gives you a file indented using spaces, say, where an indentation level is 2 spaces, and you prefer to use 4 spaces, your preference will be ignored. You will need to edit the file, i.e. change it, even if only for you to feel comfortable reading/studying the source code.

If you think that my argument is only meaningful for text editors but not for browsers, well, think again. I have written (and tested!) support for syntax highlight of Logtalk source code for Pygments, GeSHi, Highlight, Source-highlight, and SyntaxHighlighter. If you’re publishing source code on a web page, a blog, or a wiki, chances are that you will be using one of these syntax highlighters. As you already guessed, they allow you to set your tab preferences. Never found a problem due to the use of tabs instead of spaces.

I have also written (and tested!) Logtalk syntax highlight support for several text editors, including TextMate, SubEthaEdit, Emacs, Vim, Kate, Gedit (i.e. GtkSourceView), NEdit, and jEdit. Again, never found a problem due to the use of tabs instead of spaces. This, I concede, may not have always been true in the past but, nowadays, using spaces for indentation is just a big waste of space. And obnoxious to all people you may share your code with that don’t necessarily share with you the same preferences for the size of an indentation level.

As this post is about a holy war, it’s mandatory and good netiquette that I finnish it with a suitable insult or inflammatory remark to the other side. So, death to the tab infidels! May your spacebar burn in hell!

Writing unit tests in Logtalk

Logtalk provides simple but portable support for writing unit tests. This support is provided by a library object, lgtunit, inspired on the works of Joachim Schimpf (ECLiPSe library test_util) and Jan Wielemaker (SWI-Prolog plunit package). You can load it using the goal:

| ?- logtalk_load(library(lgtunit)).

The interface of the lgtunit object is quite simple and can be found e.g here:

Most of the examples found on the current Logtalk distribution include a set of unit tests, together with a handy loader file named tester.lgt. Typically, this loader file loads the code you want to test, the unit test framework, the unit tests themselves, and send a run/0 message to the unit test objects. Check, for instance, the example:

In order for you to write your own unit tests, start by defining objects extending the lgtunit object. These objects must be compiled using the option hook(lgtunit). For example:

| ?- logtalk_load(my_tests, [hook(lgtunit)]).

After successful compilation and loading of your unit test objects, you can run them by typing:

| ?- my_tests::run.

Logtalk unit tests can be written using any of three different dialects. The most simple dialect is:

test(Test) :- Goal.

This dialect allows the specification of tests that are expected to succeed. Tests that are expected to fail can be written by using the \+/1 built-in predicate. However, tests that are expected to throw an error cannot be specified. A second dialect overcomes this restriction:

succeeds(Test) :- Goal.
fails(Test) :- Goal.
throws(Test, Error) :- Goal.

This is a straightforward dialect. For succeeds/1 tests, Goal is expected to succeed. For fails/1 tests, Goal is expected to fail. For throws/2 tests, Goal is expected to throw Error. A third supported dialect is:

test(Test, Outcome) :- Goal.

In this case, Outcome can be the atom true, the atom fail, or the exception term that the test is expected to throw. In all cases, Test is an atom, uniquely identifying a test. Simply use the dialect that is the best fit for your application.

That’s all. Happy testing!

Note: when using the <</2 control construct to access and test an object internal predicates, make sure that the objects are compiled with the context_switching_calls flag set to allow.

Prolog modules madness II

Try the following experiment in a Prolog compiler with a module system. Define a simple module containing a simple meta-predicate that tests its meta-argument, writing an error message if it’s uninstantiated:

:- module(m, [mp/1]).
:- meta_predicate(mp(0)).
mp(Goal) :-
    (    var(Goal) ->
    ;    write(passed)

Compile and load the code above and we’re ready for a quick test. This is the result you get with current versions of SICStus Prolog, SWI-Prolog, and YAP:

| ?- m:mp(_).

You get this result no matter how you load the module file. You also get this result if you import the module meta-predicate in order to call it without using explicit qualification:

| ?- mp(_).

Before looking closely for an explanation why we don’t get an error message instead of a passed message, allow me to show the result you get in Logtalk with the same meta-predicate definition:

:- object(obj).
    :- public(mp/1).
    :- meta_predicate(mp(0)).
    mp(Goal) :-
        (    var(Goal) ->
        ;    write(passed)
:- end_object.

After compiling an loading this object, we get:

| ?- obj::mp(_).

Back to the module example. Is the standard var/1 built-in predicate broken? Or maybe var/1 isn’t module-aware? Should we blame the meta_predicate/1 directive? But we want it in order to be able to call the meta-predicate without qualifying both the call and the meta-arguments(!) when importing the module. At this point, Prolog module pundits are likely loosing their patience and screaming that the solution is to “correct” the meta-predicate definition to:

mp(_:Goal) :-
    (    var(Goal) ->
    ;    write(passed)

With this “corrected” definition you now get:

| ?- m:mp(_).

Some will go as far as arguing that, because a simple workaround is available, everything is fine. But one of the main goals of the meta_predicate/1 directive is to avoid using explicit qualification (as we are now doing in the meta-predicate clause head) in the first place. Wouldn’t it be more elegant to make var/1 (and other built-in predicates!) module-aware? That would fit nicely with the common argument that modules are a natural solution for encapsulation Prolog code. And would avoid the trouble of adding not only a meta_predicate/1 directive but also modifying the meta-predicate definition when moving a meta-predicate to another module. Not to mention that the original, broken module meta-predicate definition is more elegant, straightforward, easier to explain and understand by novice programmers when compared with the “corrected” definition, which requires understanding the lower-level details of Prolog modules compilation.

Update: You may wonder what results you get with other Prolog compilers with modules systems. The problem doesn’t exist in ECLiPSe as this compiler uses an alternative solution for declaring and defining meta-predicates. The problem also doesn’t exist in the beta versions of Ciao 1.13 where our first attempt at defining the meta-predicate is also the correct one, working similar to Logtalk in this respect.

How To Misappropriate and Misrepresent Other People’s Hard Work in 12 Easy Steps

Step 1. Work using an alias. Why expose your identity?

Step 2. Spend years asking the Logtalk open-source developer to implement everything except the proverbial kitchen sink, while at the same time politely declining to make any significant code contribution to all those features you find critical. After all, you’re a commercial user, with serious business to attend to. No time to fool around. In our example, the wish list includes:

  • an IDE
  • a type-checker
  • a cross-referencer
  • automatic dependency generation
  • a bootstrapped implementation
  • a code coverage tool
  • a web server
  • a sockets interface
  • unit test support (ignoring the existing one)
  • new documenting tools (as the existing ones don’t fit your commercial development requirements)
  • a revamped debugger

Step 3. Score hundreds of hours of free support, including on-line and in-situ, from the Logtalk developer. Besides saving you precious development time, you’re also learning the fine details of the Logtalk implementation, which will be quite handy in later steps.

Step 4. Plan your moves carefully. For example, make a peanuts donation to the Logtalk hosting expenses. It’s one less burger and cola, which in itself is not a bad idea. Who knows? It might become handy in the future to claim that you had gone as far as contributing financially to the original project.

Step 5. Try to dictate the Logtalk roadmap in a public Logtalk wiki. Users write wish lists; developers write roadmaps. But who cares about these fine distinctions? The important bit is that you may now argue that your “collaboration” attempts got shut down by the ungrateful Logtalk developer.

Step 6. Fork Logtalk. Forks can be a fantastic tool for collaborative development. So much that Logtalk is available not only from an open-access Subversion server but also from a git repository in a convenient public place. Of course, a fork starts as being an exact copy of the existing software.

Step 7. Take a page from Microsoft and name your fork OpenLogtalk. This will make it easier for new users to peek the most open alternative. Is dead simple: just choose the one with “open” in its name. Duh!

Step 8. Present your work as an upcoming professional alternative to the original academic and amateur one. Sprinkle the description of your fork with concepts from Software Engineering 101. Talk how you’re going to provide “high reliability” and “comprehensive documentation”. Talk is cheap; you can afford it.

Step 9. Present your work as a new implementation, while kindly acknowledging the first and original implementation. For example, write:

OpenLogtalk is an implementation of the “Logtalk language”.

The first implementation of Logtalk was by Paulo Moura.

The article “an” is a good choice as it nicely suggests “another” and “alternative”. Don’t let the little fact that the first implementation is also the only existing one, that you forked, spoil your message. Deception, after all, is an art that requires practice.

Step 10. Make cosmetic changes to your fork. Change tabs into spaces, put a tab before comment text, split files in smaller files (nothing rhymes more with “modular” than a lot of small files, even if you just end up loading all of them), remove a prefix from internal names, never mind that is there for sound technical reasons as already explained to you.

These changes are very important as they (1) make the code in your fork look different in a quick glance; (2) make the code fit your programming style (coding guidelines of the original developer be damned; it’s your fork!); (3) make it next to impossible for the original developer to pull and include your changes without lots of rewriting work; (4) reinforce the reality distortion field that you jump-started in the previous steps. As a bonus, you may get to claim later on the road the the original developer is not playing nice as he is not picking up your “contributions”.

Step 11. Innocently ask the original developer for help in understanding the source code. Put his mail replies in new files in your fork. It helps in product differentiation.

Step 12. There is no step 12. You’re already using a fork, not for collaborating, but to split. The best thing that can happen to a young programming community. Just let it roll.

P.S. If you care about Logtalk, help to spread this post and expose the troll.

Logtalk is the result of more than 12 years of hard work. Logtalk is, always have been, and always will be open for collaborations. Is not open, however, for abuse from disgruntled commercial users.

Logtalk source code history visualization movies

Recently I came across two open-source tools for visualization of the commit history of source code: codeswarm and gource. Both tools support Subversion, the version control software currently used for Logtalk. Before that I used CVS. Unfortunately, the Logtalk Subversion repository only covers development from October 29, 2001 onwards (Logtalk 2.x development started on January, 1998). Even so, using the above tools provide interesting insight into the history of Logtalk for the past eight and a half years. The resulting videos are encoding using the MPEG-4 H264 video codec. I tried to upload the videos to YouTube but the apparently mandatory reconversion produced awful results.

The first video shows the Logtalk code swarm between October 29, 2001 and May 4, 2010 (the date of the latest Logtalk stable release, version 2.39.2):

You will notice that the red color, representing commits related to the Prolog config files, often dominates. This is consequence of the lack of strong Prolog standards, which result in spending an inordinate amount of time working around portability issues.

The second video was produced by gource and covers the same time period:

This video excels at illustrating all aspects of Logtalk development work other than the Logtalk compiler/runtime itself. The “flashes” where the little green guy seems to touch most files happen when a new Logtalk version is released and I increment the version number in order to begin working on the next release.

A special thanks to the developers of the codeswarm and gource tools.