function_missing # lost in complexity

Introduction Here’s a new series of short articles that concentrate on one powerful tool within Prolog Pr ogramming,   “Definite Clause Grammars”. These are covered in a number of tutorials on the web (refer to the information in the appendix).  However I found a step by step approach, "distilled" with tests, to be the most appropriate learning path, as the topic might otherwise be a bit daunting for newcomers to comprehend. The context where I personally used the technology is for parsing application server logs and parsing programming languages such as Java. A number of probl ems arise when parsing text, such as: the ability to reuse generic structures such as lists and options to structure grammars the ease of capturing the elements recognized by the parser, and maintaining state across several rules (productions) the handling of ambiguous contexts when looking up text tokens (“lookahead”) the handling of rules with left recursion The effectiveness of ...

The previous article presented 2 alternatives for calculating the diff predicates, such as   diff(on(//'NEST', @type), from(//bird, @name)).   using a common strategy for matching objects, and a different strategy for matching sub-nodes of these objects, in the tree_d2_map and tree_d2_lcs implementations respectively.   This approach led however to some code duplication, and thus to the increase of the number of predicates which one might have to write to produce a diff.   The present article now introduces a generic diff implementation that works as a “swiss-army knife”, enabling on-the-spot combinations of node set matching strategies.   Resources for this article Prolog source code and XML examples are available on  [github] , and are linked to this article. To help enhance the readability of the predicates’ output, some Xml elements below are sometimes “ellipsed” with a “…” . A new code structure for decoupling th...

Introduction Building on the previous article I wrote on using the SWI Prolog Xpath predicate for analyzing Xml Node Set relationships, I now describe a way to produce a tree oriented diff based on similar techniques. The goal of such a diff is to identify objects of 2 Xml trees which differ by a given sub-node. In a sense is that diff not a fully general diff, as it focuses on 2 or 3 levels: object sub-or-descendant node resp. property when required, property of the sub-or-descendant node specified by the user, within the Xml tree structure. Another important goal of this diff is to be able to accommodate a different ordering of these objects in the Xml structure, which is normally a constraint which most editors or developer tools can’t cope with. In the following sections I will again use a similar fictitious tree example as in the precedent article. Resources for this article Prolog source code and XML examples are available on  [github] ...

Introduction SWI Prolog provides a Prolog-friendly version of Xpath which consists of defining Xpath expressions as Prolog  terms . The actual API is documented  here . There are a few hurdles which one has to face, coming from using standard Xpath expressions (e.g. with XSLT) and having to transpose them into the Prolog flavor. Having integrated this difference with the standard, one can quickly measure the immense flexibility offered by these Prolog xpath predicates for performing some complex Xml Analysis. Key to this is the possibility to use unification involving some Xml intermediate Node objects, using them as current (local) context nodes, which in Xpath is referred to as the “Axis”. Another concept of Xpath, the NodeSet, can also be covered elegantly by unification. I would like now to showcase this on a small example, using a fictitious tree description, and some imaginary information one would like to extract from it. Resources for ...

I have end of last year (2016) started working part of my time as release manager with the  regular duty of building software artifacts out of legacy Java EE Components (web  applications, web services, batches). There are a number of tools which we use to: build and release software, namely Maven, Jenkins and Nexus define clusters and their properties for our applications to be deployed on check or adapt the apps configuration, then deploy the software artifacts monitor the deployed applications Each of these functions implies working with a different toolset, which implies a lot of user  navigation in complex directory structures, file systems or web hierarchies, with either an IDE such as Intellij, a directory/web browser, or by using tools like Git or BitBucket. Facing this complexity of information can at times be challenging, given that: our build system and toolset undergo regular changes the effort of navigating the information cannot be easily au...

Synopsis Given the complexity of the stack described in my previous post, things did not quite go into linear fashion. However as far as GODI itself is concerned, I just had to overcome a single hurdle for its installation on my system. The rest of the process was surprisingly smooth. Getting the GODI distribution From the GODI homepage I downloaded godi-rocketboost-20080630.tar.gz (which is the version including Ocaml 3.10.2) and unpacked it under my 'Ocamel' directory. As this software is not installed via 'wizard', one needs to read the README file first. In the section 'Requirements', it is clearly explained that the installation requires the GNU gcc compiler (which is best provided by the Xcode package engineered by Apple) and also other UNIX tools such as GNU make (which on my Mac is provided by Fink ). As I had already Fink installed on my Mac, the only additional step before starting the Ocaml installation was to install a Tiger-compatible version of...

Although OCaml is available as binary packages for Mac OS X, the problem is that this kind of distribution cannot easily be complemented by various packages available from the Caml Hump (an Ocaml equivalent of CPAN for Perl). This is fine as long as one only wants to experiment with the language. Beyond this, any work involving some pragmatic issues such as database persistence or internationalization, needs to be based one way or another on the functionality offered by the standard packages provided by the Ocaml community. An example of this is the Camomile library, which is the de-facto standard to handle Unicode characters in Ocaml, yet is not included in the standard Ocaml distribution. As opposed to Java, there is no simple way to drop a library (such as a jar file) in some agreed directory. The current Ocaml ecosystem relies on a source based package being built, compiled, tested, and installed into the Ocaml environment, in a fashion similar to Perl 5. Depending on the specifi...