|
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: V3.0.24091CHANGES
- Upgrade the INCLUDE support of the SUBMIT command to handle UTF8 files with embedded BOM markers.
- Prevent the clearing of error messages from the screen if Macro Post_DO commands are still executing.
Download: For members: SPFLite2.3.0.24091.exe (511 KB) For non-members: SPFLite2.EXEFor 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
|
|
|
Post by George on Mar 1, 2024 11:21:56 GMT -5
Robert: Could be interesting. First I'll get things working to handle the existing syntax (which is mandatory).
I'm working through the commands now and each one seems to require some modification/correction to the parser. It shows just how many internal 'exceptions to the rule' have been introduced over the years. I've also found code supporting operands that aren't even documented. Those I have to watch for as some are 'internal only' and probably can't be just tossed out.
George
|
|
|
Post by George on Feb 29, 2024 16:19:59 GMT -5
The forum has been pretty quiet lately, but just as an FYI, I have been active in the background.
Because SPFLite has been poked and prodded for many, many years, some parts have become very convoluted and ugly to maintain.
So I've tackled re-writing the main command parser to clean up this area. So far so good, it's been an interesting exercise as I re-discover all the little 'wrinkles' that were introduced over the years.
While this will probably not affect the user experience, it is a long overdue maintenance item.
George
|
|
|
Post by George on Feb 25, 2024 16:45:44 GMT -5
Robert: Without checking, Post_Do should just stack the commands on a FIFO basis.
|
|
|
Post by George on Feb 25, 2024 16:07:35 GMT -5
Robert: Thanks. I've installed and tried it out. It seems to handle the exiting Doc. well.
George
|
|
|
Post by George on Feb 25, 2024 14:35:52 GMT -5
Jo: The macro seems to run fine here (assuming I understand its purpose properly)
What does it do differently for REX files, I'm not sure about that part.
George
|
|
|
Post by George on Feb 25, 2024 13:40:30 GMT -5
Jo: How about:
Send me the macro. Try assigning the new primitive (CmdLog) to a key and invoking it, before testing. and sending me the log it creates (whether it crashes or not). The log is in the SPFLite Home Data folder.
George
|
|