Your Help is needed - New Release 3 of SPFLite

Hi George !
Invoking a Macro with parm gets error msg
Operand: parm, exceeds the maximum allowed text operands .
Thanks

George,

I see you have now released SPFLite3. I don't approve of this, and I want you to understand why.

You know, there was a time when a change of this magnitude was something you'd talk over with me in great detail. We'd work out every nook and cranny of the design, so once it saw the light of day, there was a good chance (a) it was documented accurately, and (b) it worked as advertised. It would seem those days are over, since you are no longer interested in my opinion. But, what you have done forces me to give my opinion here, even though personally, I'd rather not. I hate arguing, but this is not an argument, because I am not asking you to change your ways. I know you won't.

I want you to think carefully about how in past times I proposed wild ideas for some damn thing or another. At first you went along with them, but over time and after having been burned enough, you tended to come up with a standard answer. Ready for it? The standard answer goes like this:

"I am trying to back away from major changes. I am XX years old and I can't do this forever. Besides, no one will even know the fix is in there. No one will use it. Putting this in is make-work. It doesn't buy me anything."

And you would summarily shut me down. The standard answer shuts down a lot these days. NOW, suppose some years ago that I had proposed to YOU to make the very change that YOU made to SPFLite3. Wouldn't YOU have given ME the standard answer? "It doesn't buy me anything. Why do it?"

So, George, what does SPFLite3 "buy me"?

1. You removed some perfectly good, working features, because you wanted to wrap up SPFLite3 development prematurely and were too lazy to keep those features in place in your rewrite. And, you were too lazy to properly reach out to the user community, a step that would have delayed the release. (BTW, what is your hurry, anyway?) And even if you did THAT, it overlooks a vital current-events fact: The SPFLite community has been AWOL for the last months at least, with days when NO ONE has even logged on, and when they did, it was just 2 or 3 people, sometimes only you, and sometimes literally no one. Not exactly the right circumstances to be conducting surveys, is it?

2. You completely changed the architecture of the "parser" (oh yeah, you never mentioned WHICH parser; I assume you mean the primary command one, which is not the only one, is it?) when no one that I know of has made a single complaint about the parser failing in years, that I can recall. Tell me again, what does this buy me? I know I didn't ask for this.

3. You have destroyed confidence in the editor. Your changes are so complex that even you, as the author, admit that you yourself are incapable of testing it - despite the fact that you have complete and total knowledge of what was done. So, instead of the only person in the world that even knows WHAT was changed going ahead and doing that necessary, time-consuming grunt work, you have handed off that testing to hundreds of your users, who don't know what the hell they are even looking for to test. And why? You're too bored to do it yourself. So, now every time the editor fails or a macro fails, we ALL are going to have to painstakingly run our own ad-hoc tests to try to figure out what the hell went wrong. Thanks for that.

Now, you can't judge by me, because my use of SPFLite is not at all typical. I am not trying to design software or run a business. But there are users out there who ARE trying to do those things. Maybe some of that activity is critical to a business, and if SPFLite3 is subtly broken, it could cause real harm to them. But, IS SPFLite3 subtly broken? I have absolutely no idea, nor do you, NOR do any of your users.

I can tell you right now, if I depended on SPFLite as part of a business process, there is no way I would use SPFLite3, unless some other braver and more-willing users had the time and energy to test it for me first. I would stay with SPFLite2 for at least a year, because I simply couldn't justify the risk of an unproven, untested editor breaking critical data or editing processes.

For my own use case, I have some quite large macros that I have used for years because they work, and now, I don't remember the details of all the hundreds of lines of macro code I wrote. With SPFLite3, I will have to go through all of them, line by line, to make sure the syntax of every one will still work in version 3, that I don't use any of the features you unceremoniously removed, etc. etc. And, at my stage of life, I am doing good just get up in the morning. Do I have the strength and resolve to exhaustively go through that make work to survive whatever you've done with SPFLite3?

NO.

As I see it, it's unforeseeable that I will use SPFLite3 any time soon, if at all.

I tried to tell you that you needed automated methods to test your changes. You dismissed that, because (again) it was your famed "make work" and you couldn't be bothered. Instead, you are 'bothering' your users to test a new editor that (I am sorry to say) sets back the editor's reliability by 15 years. And I will repeat, USERS are not qualified to properly test everything you've done, because you haven't told us what you changed - not EXACTLY. And even if you did, that presupposes that all of your users have the TIME to do that. Maybe they are very busy running a company, and just wanted their editor to work? Just a thought.

Now, if you at least had a DESIGN DOCUMENT, we could read it for ourselves and use it as a testing guideline. But you never design things first, do you? You haven't worked that way for 15 years, so why start now? Code first, design later, document last, right? We have no way to know if you've even revised everything in the Help to reflect the new circumstances. Documentation is such make work, isn't it?

Remember the bad old days when every other day, some bug was found where commands didn't work right or didn't support ISPF syntax? I remember. But constantly working on those problems as they arose served to address the issues, one at time. Yet now, you have thrown away years of all the hard work that made the old parser - such as it is - quite reliable. Perfect? No, but it was perfect enough. How could you do that to us - to pull the rug out from under us like that?

George, I am sorry to be so critical and throw cold water on your hard work. Perhaps I am too cynical and suspicious. Maybe 99% of the changes work right. Sorry for the poor guy who gets hit with the 1% bad part and ends up destroying their data, but oh well. Achieving perfection is such make work.

In my opinion, you have done your users a great disservice. If you had asked me beforehand (you know, like the "good old days" when you listened to me) I could have given you some advice, and I would have tried to find some way to help you automate your testing so that you might have had some grounds for confidence. I actually know something about this stuff. I worked on object oriented systems where they included testing stubs as part of the object design, and all you do is compile in "test-generator mode" and poof, your design gets tested. Yes, that is pie in the sky design, and SPFLite is not really an actual object-designed program. Still, I actually have testing insights that you don't have. Only thing is, you're not interested in my options and won't listen any more. We're two peas. Two geezers. Listening is just so time consuming, isn't it?

Maybe I'm wrong - and if I am, good for you and good for the users. You may be willing to foist an unproven, untested and untestable alpha program on your users and burden them with finding all the bugs in real time - bugs you yourself are unwilling to find. I just can't do it.

I could advise you on how to get out of this conundrum, but again, you won't listen, and I don't have the heart to argue. What's the use? It won't buy me anything.

Sorry.

Robert: You're probably right on lots of your points, but I do object mostly to being called lazy. I've been working on this almost full time for nearly 4 months. Why? Because I was tired of the state of the code. And I'm tired of being the only person in the world who has any inclination to actually work on SPFLite.

BTW The Doc. in this release has been updated, even your latest request.

I've spent weeks testing this release, it may still have bugs, but it is NOT untested. Saying I'm foisting an untested program on the users is a bit much.

As to removing unused stuff. Do I expect anyone to bemoan the loss of Numbering support? Fold? Command chaining? Get real. I didn't drop them from laziness, individual commands of their nature were trivial to do. It just galled me because they were basically useless. And Command Chaining" - well with 8 pages of dense text in the Help file to describe it, nobody would ever put the effort in to learn how to use it. Sort of like your format change support that we yanked. 

You are back at harping to me on stuff like a Design Document, reviewing it with users, yourself etc.; setting up testing plans and automation. Just how big a development team do you think works on this?

Yes, your suggestions and involvement are certainly less than in the past. Why? Because every positive suggestion is wrapped in negative comments about my work style. I don't need to be told that year after year. If you wanted to have things done to your high standards, you should have continued on the QSPF path and then you could sit back and snigger at SPFLite.

I know I've been talking shutting this down for a long time, but I love doing this, it's really hard to just stop. But this time it really has to end. This will be the last significant change. I want to leave the source in as clean a state as I can manage.  My peripheral neuropathy has basically killed my legs and has now jumped to my hands; I can no longer do up buttons; I can't tie my own shoes; and typing is more Bksp than forward.

Until somebody steps up to take over SPFLite, and fix everything you say is wrong with it, everyone is stuck with this 'unproven, untested and untestable alpha program' that I've turned out.

George

 

Jo: No problem reporting it here at all. During my V3 testing I ran into many bugs of course, and surprisingly, many existed in the production version so were not part of the V3 changes.

So is that last file simply not visible because it's on the next page? Or was it Excluded or Forgotten?

George

MUEH: Ack! Of course! Dumb stuff like this is my downfall, the brain ain't what it used to be.

George

P.S. I posted a 24101A version with the fix. The model definition was corrected, it wasn't a coding error, but still a bug.

George

MUEH: This is showing that converting the 'rules' for every command into definitions for the new parse code is much harder than I thought. Kwds that are not defined, by default, become literal operands. Hard to believe (well maybe it isn't) that stuff like this escaped my testing.

BTW, just a comment, about Robert's comments that this is an untested, maybe unreliable release.

Yes, it is not fully tested, nothing with SPFLite's complexity and interaction of various options could ever be. Even with some automated testing tool for which he has been pushing. (And which I doubt could ever be created)

But I have been using this new release for editing the SPFLite source code itself, and have never said "d*mn" it messed up.

I think the fix for this latest bug will have to wait till tomorrow. I'll have to do a full review of the parsing rules to see if I've messed up some other definitions.

George

OK - 24102 is available.

MUEH: Thanks for all the testing, it's invaluable.

First - the 2nd bug. I think this is actually a bug in the production version, which the new version has plugged.

SHOW syntax is describes as:


SHOW      [ search-string ]
               [ start-column [ end-column ] ]
               [ FIRST | LAST | NEXT | PREV | ALL ]
               [ C ] [ Q ] [ T ]
               [ PREFIX | SUFFIX | WORD | CHAR ]
               [ line-control-range ]
               [ U | NU ]
               [ color-selection-criteria ]       <============
               [ TOP ]

Which says 'color-selection-criteria' and that means only LIME, not +LIME. i.e. search only, not change.

I think here you want the FIND command, which would allow the +LIME operand.

I know, it used to work, but the revisions in this case are just enforcing what the doc. describes. The previous versions actually had a bug.

George