|
Post by George on Mar 28, 2024 7:54:04 GMT -5
Robert: Looks like a misc update to fix bugs and add minor features. It didn't even have to migrate existing files, which some updates have to do.
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 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 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 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 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 9, 2024 10:37:20 GMT -5
Hi, A small release has been posted. Just a few bug fixes that have been in Beta release for a while.
The next release may be some time as it has some major internal code revisions, so this 24069 release is just a 'catch up' so that I don't have multiple active versions underway at the same time.
George
|
|
|
Post by George on Mar 9, 2024 10:33:23 GMT -5
This thread will contain the latest Beta release following the V3.0.24069 production release.
This unique Beta notice is based on the Production version so that thread postings from a previous Beta version are not lost nor confused with comments on THIS release.
By Beta, I mean one that is, in my opinion, at least good enough to let other users try it out.
If you download and use one of these Betas, you should take precautions to be able to back off should it prove unstable.
I will try to provide, with every version, any information that may affect switching to the Beta release. When a new Beta completely replaces previous versions, the download link for the previous beta versions will be removed.
If you are running the latest production release, this Beta can simply be swapped in place of the production EXE.
Beta version: No current Beta release
CHANGES
Download:
For members:
For non-members:
For non-Members, comments should be emailed to : support@SPFLite.com
RE: Beta 3.0.23230 -- or whatever the version is --
Or better yet, become a member, as it says in the news, it costs nothing, you get to post on the forum, and you will not be bothered by any emails from us.
|
|
|
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 8, 2024 16:55:03 GMT -5
DinoRick: Sorry about this, but be assured it is a false positive. There is no way I can do any change to the programs that would eliminate this problem. Best option is to white list the install folder.
AV programs and lightly used software programs simply don't get along. They don't 'see' the programs often enough to flag them as 'ok'.
George
|
|
|
Post by George on Mar 8, 2024 12:53:35 GMT -5
Robert: No, the problem is not just proving the parser is 'doing its job'. This change is NOT just affecting the parser.
When we're talking about the original or the new parser, there is simple NO one single defined interface between the code in the actual command and the data created by the parser. You can't just swap in a new parser and expect the command code to accept it as a 100% perfect substitute. So I can't revise/replace the parser without going into each and every command and 'walking the code' to see what has to be adapted.
We have commands ranging from END with no operands, to others with just a simple ON/OFF and those like CHANGE with every possible search option under the sun and similar modify options, and of course LOCATE with it's myriad options and custom parser.
So yes, we have to test that SPFLite (the whole thing) is working. It's true that masses of underlying support routines remain unchanged, but the command code sits between those routines and the parser, and with either the new or old parser, a lot of the command code still has a lot of unique operand validation to perform that no generalized parser could incorporate.
All I can do is plug along. Attempting some kind of automated validation is a total diversion.
George
|
|
|
Post by George on Mar 7, 2024 15:39:22 GMT -5
Robert: Yeah. Sure. I looked at that once. It's an enormous undertaking. Just look at the LOCATE command that we were talking about. Figure out what the test data would have to look like to encompass all the search types, all the different line types required (not all of which could be saved in STATE) and then the scripts with all the LOCATE commands issued one at a time. I'm not even sure how the script would be able to check if the command was successful or not.
Now multiply that by the 100+ commands and all THEIR variations, a lot of which would require unique test data files.
I should live so long. Sadly, this is just a dream.
George
|
|
|
Post by George on Mar 7, 2024 14:29:48 GMT -5
Robert: The parser seems fine, the problem is commands (like LOCATE) which 'break the rules of "position independent" operands' which was always a hallmark of ISPF syntax.
But as to why tackle this? Winter cabin fever? Boredom? Who knows? The parsing has never been great, and as I go through the commands one by one migrating them to the 'new way', many of them have been simplified greatly. Simplification has to be better.
The problem is testing. There is simply no way I can ever test out each command and all it's variations of operands. This will need a lot of assistance from our forum testers.
George
|
|
|
Post by George on Mar 7, 2024 9:19:06 GMT -5
Robert: I have the basic parser re-written, and the underlying manipulators (Search, Change, Join etc.), but each Primary command needs tweaking to accept the new method. In most cases it's fairly trivial, but some commands are quite a struggle. I'm working through them A-Z and am tackling LOCATE right now. It's gotta be the worst one so far, over 50 keyword type parameters mixed in with some having trailing numeric operands. It's a nightmare.
I'd like to respecify and re-write it, but we're stuck with what we've created.
Interesting during all this, I've found several places where the Doc is incomplete, or has conflicting information, so these are corrected as I go.
Fun, fun, fun!
George
|
|
|
Post by George on Mar 1, 2024 14:47:41 GMT -5
Robert: That's why I have to check carefully. Some commands are issued internally with secret Kwds, for various reasons. It's not a big problem, just something to watch for. These internal Kwds will NEVER be documented in HELP.
George
|
|