Skip to content
gpiancastelli edited this page Sep 14, 2010 · 12 revisions

During the process of porting tuProlog’s code from Java 1.4 to Java 5/6 I may decide to bring in some other modifications, dealing with duplication, reorganization, architecture, &c. This wiki contains a change log of those modifications in reverse chronological order. For changes coming from the Java language porting process, please see the Commits section of this site.

August 25, 2010

The command-line REPL class is now called Console, because it’s simpler.

August 19, 2010

Removed occurrences of another exception (this time an IllegalArgumentException, generated when looking in the database for clauses with a variable as head) during tests. The ISOAcceptanceSuite now runs without throwing exceptions.

August 15, 2010

Removed duplicated predicates. In BasicLibrary: constant/1 in favour of the ISO standard atomic/1; expression_equality/2, expression_greater_than/2, expression_less_or_equal_than/2, expression_less_than/2, expression_greater_or_equal_than/2, term_equality/2, term_greater_than/2 and term_less_than/2 in favour of their operator-based equivalents. In ISOLibrary: bound/1 because it’s just another name for ground/1 (from BasicLibrary).

August 5, 2010

Removed deprecated methods and classes.

The use of Override to annotate methods implementing an interface bumps requirements for running tuProlog up to Java 6.

August 4, 2010

As a consequence of refactoring the library mechanism to exploit annotations, Java methods which represent Prolog directives must now have a boolean return type. Also, predicates/functors/directives cannot have synonyms, i.e. you can’t give a directive two or more different names corresponding to the same method (as instead was the case with the old library mechanism, through Library.getSynonymMap) because the annotation supports just one String value; so, directive names consult/1 and solve/1 have been removed, in favor of their ISO standard equivalents include/1 and initialization/1.

July 30-31, 2010

Got rid of package alice.util. The Tools class was removed, after moving a couple of needed methods to proper places: loadText was moved to Agent; removeApices was transformed in Term.toStringWithoutApices, as it was always used on a term’s string representation (except a couple of places where it was used on a Struct name, but those Struct were atoms, so…). Unfortunately, the dreaded OneWayList is too deeply innervated into the engine’s internals (see StateBacktrack for the most problematic place) so it’s been impossible to discard without performing modifications of such entity that I was not willing to spend the necessary time into. So, OneWayList has just been moved to the alice.tuprolog package, highlighting the “core” role that it always had.

I also noted, en passant, that some of the methods in the API of OneWayList are never used: setHead, setTail, addLast, and get.

July 10, 2010

Fixed another annoying ClassCastException thrown by atom_length/2 when the first argument is not an atom.

July 8, 2010

After a long discussion on SourceForge with Matteo Collina, took inspiration from his patch to remove the renaming step in Term.unify which was causing unwanted unifications between instances of variables with the same original name that were created in different steps during the goal resolution. (See the link for more details.) The impact on debug information of this deletion is yet to be seen/understood, but I decided to include the patch anyway, since a correct behavior is more important.

May 28, 2010

Completely removed serialization. First of all, serializable classes generated warnings for an UID number missing — which I had no intention to provide. Second, the parts of the project that used serialization were already removed — extensions for sending Prolog terms and libraries on the wire through TCP or RMI, for example. Third, I recall that, when transitioning from tuProlog 1.x to tuProlog 2.0, serialization wasn’t really thought out throughly — I may be wrong, but this is just another reason why, for the purpose of this Java rewriting exercise, I think it was better to stay far away from serialization.

May 26, 2010

Fixed ClassCastException thrown by type testing predicates (integer/1, float/1) when the argument is not a number (i.e. an unbound variable, an atom, or a compound term). Those exceptions annoyed me because they were generated during unit/acceptance testing.

May 18, 2010

Started with tuProlog 2.1.1.

Transformed FIT tests into JUnit 4 tests, mostly with help by a little Python script which is too hacky and messy to be showed in public. Some tests have been ported by hand. (You will note which, because the automated transformation used meaningless method names.) The FIT-to-JUnit transition was needed because of how much flexibility and control is granted by JUnit over single test methods. (Also, I have a feeling that JUnit is faster.) In FIT, you know how many tests passed and how many failed; for documents where tables are not 100% green (like the ISO-compliance HTML documents included in tuProlog) however, there is no way to know exactly which test changed (from red to green, but more importantly, from green to red) on subsequent runs when you just see the numbers changing. JUnit allows you to turn an entire test suite green by supporting expected failures: just annotate a failing test with @Test(expected=AssertionFailure.class) and you will get a passing test. This is extremely important when all you want to do is to preserve the current functionalities rather than adding features or fixing bugs, which is exactly what I shall do in porting the code to Java 5. Whenever the introduction of a “new” language feature in the code base breaks tuProlog, the now-100%-green suite of tuProlog tests will catch the problem and let me know precisely what I broke. Unfortunately, FIT does not have a built-in support for expected failures, but it must be noted that JUnit is not perfect, either: for test methods containing more than one assertion, the failure may prevent some to be executed, while FIT was able to always execute each and every comparison between expected and actual results.

Removed/Reorganized some parts of build.xml, to account for the FIT-into-JUnit transformation.

Ditched stuff I’m not interested in: GUI and other extensions.

Moved the command-line REPL into the alice.tuprolog.ui package.

Clone this wiki locally