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
(SVN is running slow for me today, which is unusual. I hope it's just my local ISP.)
As my next task, I think I'll add a data transfer from Proparse so that we can fetch its internal data about node types and keywords.
re: do ?
To be honest, I think that we should do what Progress do. Once a new product is released, the old product is supported, but all new features go into the new product. Keep the "old" proparse and proline available (for V9 people) and use the new stuff for v10+
queries and parserNodeStateHead ...
I think I am starting to understand the structure of this. Parts, anyway.
The structure "org.prorefactor.core.JPNode" (or should I say class, instead structure) defines offsets to integers and offsets to offsets, like offsets to related nodes. Related nodes like firstChild, Parent, nextSibling are easy to find, probably in just two hits on the memptr.
Am I correct in thinking that functions like parserNodeStateHead() and the parserQuery family of functions will require quite some ABL statements? I mean, am I correct that these bits of code are effectively removed from Proparse and moved into ABL?
Not that that's a bad thing, I just ask so I understand where this is going. I am a little bit concerned about turbolint.dll where the ABL code needs to be imitated in Delphi, that's all.
Re: queries and parserNodeStateHead
You are correct - most of those old DLL API functions need to be replaced with new functions (the new API) that fetch data from the blob.
One of the benefits of the blob is that I recently was asked if the data from the parsers (proparse+prorefactor) could be used from C# for scripting and large analysis projects. Now the answer is 'yes'.
I have two thoughts about turbolint. One is that in terms of performance, it should no longer be necessary. The other is that if you want to work with Delphi, you will probably find that it's very fast to generate Delphi Objects for *all* of the records from the blob. I certainly found that was the case in Java, where I was creating new Java objects for ever node and hidden token from the DLL. It's much nicer to work with than trying to keep track of node handles for proparse.dll.
Re: queries and parserNodeStateHead
True, navigating through the blob can be faster, lots faster than calling DLL functions in a tight loop. So if we're lucky then turblolint won't be necessary anymore. We'll see. And porting an API for ABL to Delphi won't be too difficult so it does not really matter.
'inline' functions??
Interesting, I just noticed this header-comment in xferblob.i (available in the in codeparse Subversion repository):
Do you mean that these functions are inline included by the ABL compiler, more or less how a C compiler would, e.g. more or less like preprocessor expansion? I did not know that ABL could do that, I figured the compiler would just compile functions and then compile calls to those functions, with stacks and such.
Re: 'inline' functions??
Bad choice of words, sorry. No, I put these into an include file rather than a .p, so that they are local function calls (same compile unit) rather than calls to functions in some other persistent procedure.
That reminds me: I did a brief search on PEG for the numbers that people were posting in terms of the amount of time it took for different call types (RUN local, RUN in persistent, ditto for functions, calls to methods). I couldn't find them though. Did anybody hang onto that?
re: new blob api early example
Wow that client.p certainly runs very fast!
But to see things in perspective, would you upload the example sourcefile that was parsed (I think the name was, surprisingly, c-win.w) - just for a quick compare of the sourcecode with the blob contents.
c-win.w
OK, I added c-win.w to svn. (Why is the name surprising? Julian sent it to me, and I really don't know where the name came from.)
Oh man I envy how you're not
Oh man I envy how you're not privy to that whole Apbuilder thing!
c-win.w is the default name, choose "New window" from the File menu and a c-win.w is what you get, just like when you add your first button it's always named "button-1". The c-win.w you got from Julian was close, very close to the template, but not quite identical.
re: Oh man I envy how you're not
Heh. It was our very first sample file. We are starting simple, and working our way up. The initial goal is to reproduce the UI in .net equivalents. Once we achieve this goal, we will start to work on more and more complex UI programs.