Re: Bug in crm114 parser? Or is it me again?

On Thu, May 22, 2008 at 10:59 PM, Paolo <[email protected]> wrote:
> On Thu, May 22, 2008 at 04:02:24PM -0400, Bill Yerazunis wrote:
>>
>> Something is seriously wrong; I get:
>
> indeed ...

Not so in the GerH builds.  :-P

>>   match [:spam:] (:: :spamdir: :spamwildcard:) /^(.*[\/\\])([^\/\\]*)/
>>
>> which _should_ be identical in behavior, but they aren't, because
>
> ... problem is likely that we look for next '\' but we don't count how
> many we've seen. Note that if you try from that as an in-line from cmd line
> you get crazy before getting it right. A workaround is to use [\o134\o057].

Yeah.

Added trouble inside crm114 is that the parameters were scanned (sorta
like parsed) in several places in the code, each of course just ever
so slightly different.

The GerH script compiler parses the complete apb block (argument
parameter block) immediately at start/compile time and caches it. So
there's very little JIT left there. This helps me both to ensure I can
check/validate the parameter counts, etc. at compile time and warn the
script programmer and ensure the script program space is scanned fewer
times.
Besides doing it this way has shown to make no difference in timing -
the data was scanned several times before anyhow and the parsing is
not cpu intensive, so the bigger gain of the two is getting rid of
just one more scan, while right now I have essentially 'compiled'
code: no need to test all the possible branches just to find one made
a programming error by specifying the wrong number of args or other
arg related screwups - which happen often to me as I write crm scripts
intermittently and the language is just enough off from the main of
what I use usually.

The only thing (sounds easy, right?) I still need to get rid off is
the separate preproc and compile phases: these can be rolled into one
to further reduce time spent: no need for twice the lex/scan code and
the run-time cost of dual scan pass like it is today. I know how to do
it, but I'm in no mood to do it right now. Nevertheless, I should do
it better earlier than later.

And, yeah, I know working on the compiler like that does not make
crm114 mindbogglingly faster - that was never the intent, but NOT
making it slower would be nice, as it would preclude any argument of
not going this way, I think. I made this major move to ensure I would
arrive at a script compiler which would allow me to have my scripts
checked *completely* for typing and other obvious coding mistakes as
early as possible; I *hate* script languages which allow me to make
stupid coding mistakes (like forgetting an argument list closure) and
only barf at run-time when that particular branch of code is hit. ASP
comes to mind. <shudder> Vade Retro, Satana!

> Note that last MATCH is wrong, if I got its purpose right:
>
> - match [:spamdir:] /\/dir1\/dir2\/dir3\/*/
> + match [:spamdir:] /\/dir1\/dir2\/dir3\/\*/

Well spotted, that one. Yep, one \-escape too few. Thanks!
Fixed in the test script.


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/