Proparse Group



Why do we need an index for fixed-length records

If a record is fixed length, then surely the record offset is easily calculated ?

If the node record is 32 bytes long, and the node data set starts at 1000 bytes, then record n is at position 1000 + 32 * (n - 1). Why do we need an index of node records pointing to a node record ?


Strings

Whilst I understand and appreciate the rationale behind "fixed length" records, and the need to store an offset to a string in a field position, I feel that it may be overcomplicated.

Why couldn't proparse.jar return 3 blobs: Header, Record and Strings.

The strings blob is simply a collection of null-terminated strings (no sizes etc)

FOO\0
BAR\0

Each record field that is a string could simply contain a pointer to the starting position of the string. The progress GET-STRING() will read a string until it hits a NULL, so we don't need to record the size of the string.


Schema and speed

One thing that I am thinking of that is costing us in speed terms is the schema of each record. For each node, there is a pointer to the node record. Once we have that record, we then need the schema pointers to get us to the value of each field. This is done because we need to have the capability of changing the schema around if required.

This means that

a) we need to include the schema in each blob
b) we need to read the schema to create the record and field offsets
c) each field's position has to be calculated, and stored in a variable


Changing the tree for refactoring?

I'm answering an offline question here, because I think it's of reasonably general interest for people using the parser.


What is the definition for invalid nodes

If the child node is unknown, or not valid, what is the definition ? Is it null, -1 , 0 etc ? I seem to get some strange numbers (434 if NumNodes is 431 for example).

Could it possible to set all "invalid" nodes to -1 ?

NextSibling, PrevSibling, Parent, FirstChild etc.


Proparse server config, 'prorefactor' directory

Jurjen, I'm working on the proparse.jar server configuration stuff.
I'm going to set it up so that the client can request the server to load a project's settings. This way, the client (like Prolint) can dump the project configuration automatically at start up time, and get the server to read that.
The server process will always require its './prorefactor' directory for reading and writing various configuration and other files.

PUB binary files directory


New blob api early example

I created a new repository called 'codeparse', added a directory called 'wip' for shared efforts that are work-in-process or experimental, and added a subdirectory called 'proparseclient'.

svn://oehive.org/codeparse/wip/proparseclient

For those interested in building and using the API, you should be able to run client.p in that directory, which reads the two binary files 'header.bin' and 'blob.bin'. The program 'tree2text.p' is small and reasonably easy to understand as a starting point. If you don't know which API we're talking about, see http://www.oehive.org/node/1247


New proparse.jar BLOB Internals

Most developers working with Proparse would use an existing API, and these notes would not be of interest. These notes are only for developers working directly with the bytes from the blob, for example, when developing a new API.

The layout for the blob had one over-riding design consideration: It had to be indexed for fast random access of the records and fields within it. Loading all of the records into ABL objects would take too long for an interactive tool like Prolint.

As a result, the blob ended up looking somewhat like a miniature read-only database.


New proparse.jar API

Proparse is ported to Java and can be launched as a little server which listens on a TCP port. It receives a program name, finds and parses the program's source code, and then returns a BLOB containing records of all the objects in the syntax tree and symbol tables.

The blobs will be read by ABL routines to generate ABL objects (temp-tables, data sets, Objects) as needed.

This new Proparse API will be used by another project right away. In the coming days you can look for “GUI BOM” here on the hive.

There isn't any timetable for a new version of Prolint using this new API.


Using Proparse

Download

You can find Proparse pre-built libraries on Joanju's Proparse page at
joanju.com/proparse/.

Configuration for Project Settings

See Project Config. Dump for a description of how to generate the configuration files needed by Proparse.


3.1C02

Version 3.1C02 is now available (minor bug fix release). Binaries available for windows and linux at www.joanju.com/proparse/ .


Proparse directions

I imagine that the first priority is to add support for 10.1C syntax. I don't know if any Proparse users are adding 10.1C syntax to their applications anytime soon... this would be a good place for discussion.

Beyond that, there are a number of changes that I would like to make in terms of making Proparse easier to use, adding more features, and making it easier to maintain.


3.1b01

I posted 3.1b01 (Windows and Linux builds available from joanju.com/proparse/). This fixes an obscure bug created in the previous release, which could cause a crash at a parse error in a function definition.


Compiling the C++ DLL

If you have everything all set up perfectly, then Proparse can be compiled with a simple Gnu make command. Getting everything set up can take a lot of effort though, so if you are adventurous and want to try compiling it yourself, be prepared for some challenges. The source requires Gnu C++, Gnu Make, perl, and probably other things I've forgotten. For performance reasons I usually compile the Windows DLL with MSVC++, but I found that by installing the right packages with Cygwin, I'm able to compile with that. Doing a build on Linux isn't too hard.


Proparse Book

This book is for the Proparse open source ABL parser.


#
Syndicate content