|
Post by George on Mar 8, 2024 17:02:14 GMT -5
Robert: Yes, I understand all that, and I am determined to do as extensive a testing regime as I can manage before releasing this into the Beta world.
It's unfortunate, but with SPFLite's development history, all that 'nicety' of parsers, lexers, etc. just doesn't apply. You simply can't go back and somehow re-impose a lovely parse/lexer environment on something that has grown like topsy for almost 20 years.
We're stuck with what we've got.
A release now is a good idea though.
George
|
|
|
Post by George on Mar 11, 2024 13:07:12 GMT -5
Just an update. I'm really being surprised by how many inconsistencies I'm uncovering.
From stuff in the code that's not in the Doc. and visa versa, code not doing what the Doc says. Add in many redundancies mixed in with just plain stupid code, and it's quite an eye-opener. Too many years of too many overly expedient additions.
Should be interesting when I can actually start removing the old parse code, right now both old and new are present.
George
|
|
|
Post by George on Mar 13, 2024 10:58:44 GMT -5
Here's an example. It appears the search for negative colors (e.g. FIND XXX -BLUE) has not been working for a long time. I didn't waste time going back to see when it last worked.
PITA since you waste time looking for the error in the changes you've just made, assuming it was working previously.
I really wonder how many other 'bells and whistles' type features are lying there unused (even if they DO work)
George
|
|
|
Post by George on Mar 17, 2024 14:07:47 GMT -5
Robert: I've been cursing you for the last few days (just so you know). Your ideas for RLOCFIND were fine, since we allow so many commands to use the full search engine. But my new parse routine and this feature (especially the REVERSE Kwd addition) have been driving me nuts.
i.e. How do you parse a command like RLOCFIND, which can have no parameters, a single REVERSE/REV parameter, or any of the full command sets from FIND, CHANGE, DELETE, JOIN and SPLIT? We created a monster!
I think today I finally have it working properly with FIND only, hopefully the rest will fall in place a bit easier. It's been a real brain-buster.
George
|
|
|
Post by Robert on Mar 17, 2024 20:33:56 GMT -5
George,
1. I've operating under the assumption that I'm no longer in your good graces, so the idea that you're cursing me doesn't come as a big surprise.
2. How would I parse a command like RLOCFIND as you've described it? I do my serious parsing with YACC. In YACC it's quite straightforward:
parse_cmd : RLOCFIND | RLOCFIND reverse_arg | RLOCFILE find_class_syntax ;
reverse_arg :: REVERSE | REV ;
find_class_syntax /* the generic syntax for find/change/delete/join/split would be here */ ;
3. If your new parser cannot handle this, it suggests your parser design needs some work. Designing parsers is hard; that's why most commercial users of parsers never hand-craft their own, but use parser generators like YACC instead.
R
|
|
|
Post by George on Mar 18, 2024 8:38:22 GMT -5
Robert: "Not in your good graces"? That's news to me. I curse you the same way I curse myself for many decisions I've made over the years.
I've looked at YACC, but it's beyond me. It seems to take a specification and create it's own code (in C) which you insert into your own. The specification itself is baffling (I don't need a learning curve experience), let alone trying to figure out how to integrate it into existing code. Please, enough with pushing YACC/LEX at me. If we were starting over it might be a different story.
I have to do this so the rest of the program only needs tweaking, not major surgery, and the various bolt-on additions and kludges we've done over the years are the problem.
It's a shame that over the years you've never actually had to make the changes to the full code base, you've been isolated from them by writing nicely defined, separate functions, at which point you hand them off and can wash your hands of it and let me worry about integrating it into the main code. If you had, maybe your experience might tone down the "if you'd only do it THIS way ..." suggestions.
SPFLite is not easy to work with. Fault? Yes, it's mine; so I really shouldn't be complaining
George
|
|
|
Post by George on Mar 24, 2024 12:55:42 GMT -5
Latest status: I think the changes to swap in the new command parser are done. Lots more testing etc. to do before anyone else sees this. Not really looking forward to that part, SPFLite just has soooooo many commands and options.
One thing I have spotted during this is that there were a bunch of commands which simply had errors and did NOT do what the Doc. described. Also there were commands that had undocumented operands, or operands that really did nothing, etc. -- that was a surprise.
It's been an interesting exercise. Not that it buys anything, well not much, except that all primary commands will now react to a ? operand to open Help.
|
|
|
Post by George on Apr 7, 2024 13:22:26 GMT -5
Robert: I'm close to finally putting out a Beta (No -- an Alpha). I'm going to make it a whole major jump to SPFLite3 and a separate install folder, so two versions can co-exist. This has been a really interesting exercise. Amazing how many unreported bugs I've uncovered.
To prevent any possible corruption of the CFG file, the new version will (for a while) make a timestamped backup of the CFG file at each invocation.
Also, your suggestion for the AA.Macname / BB.Macname is included. Any prefix will override the normal Profile MACLIB setting.
George
|
|