|
Post by George on Jul 8, 2024 12:22:41 GMT -5
OK, a new Beta today (24190) I think this corrects outstanding errors and capabilities that were missing. Also improved the response messages to be clearer about what had happened.
George
|
|
|
Post by Robert on Jul 8, 2024 14:04:15 GMT -5
George, just tried 24.190.
I had data like this:
000001 AAA 000002 XXX 000003 AAA I issue these commands:
FIND XXX LABEL .BB .ZFIND + 1 I expected label .BB to be put on line 3. Actually got msg: Bottom of data reached
|
|
|
Post by George on Jul 8, 2024 14:33:14 GMT -5
Robert: Try +1, not + 1. It's supposed to catch lonely + or - entries. Please don't ask for + 1 type syntax to be acceptable.
I'll check this.
George
|
|
|
Post by mueh on Jul 8, 2024 14:42:43 GMT -5
Hi George ! User macro MI -1 or even find -1 is not longer possible . Msg "Operand: -1 exceeds the maximum allowed +/- Adjustments" Thanks for 24190 .
|
|
|
Post by Robert on Jul 8, 2024 14:46:14 GMT -5
This is a surprising syntax limitation. Be sure to explain this in the Help for LABEL. Just tried your suggestion. Using +1 with no space after the + worked.
R
|
|
|
Post by Robert on Jul 8, 2024 14:58:49 GMT -5
Mueh, George:
Evidently, the parser is treating -1 as if it's a "magic" lexical token, and it is not actually parsing - 1 as a signed number. It's almost as if -1 is treated like a keyword. I checked the last production version 23.069 and FIND -1 is treated like FIND "-1". Personally, I think syntax like that is dubious usage, but clearly some users are depending on being able to use syntax like that. I seem to recall arguing against allowing such things; it just looks so "ugly" to me. But I guess it's just a matter of taste. This is why commercial software developers rarely do their own parsing logic. Hand-crafted parser are usually not robust and can contain lurking bugs hidden in all the ad hoc code.
I am sorry; after writing the above it must sound very critical and I don't want to go add to our discord. But imagine if PB or thin Basic treated -1 and - 1 as different tokens. Wouldn't you be surprised? No, I won't ask you to change it, I am sure that even attempting it would be difficult.
|
|
|
Post by Stefan on Jul 9, 2024 1:41:55 GMT -5
Hmm, when a user enters a command like FIND ABC +RED they don't split the colour argument/token by placing a space between the plus and RED.
I'd expect the same logic to apply to a command including a token like .ZFIND-1 Hence I would argue that there should never be a space within such tokens.
|
|
|
Post by George on Jul 9, 2024 9:26:38 GMT -5
I think sometimes we forget just how flexible the SPFLite parser has to be.
OK, why can't xxx + 1 work?
First, let's not forget this is an ISPF clone. Whose syntax has always been space delimited, position independent 'words'. I don't care if other parsers handle ((A + 3) * 3) / B without a hiccup, SPFLite doesn't and never will.
I don't know beans about other parsers, but how many would treat these as identical?
CHANGE FRED BILL PREFIX 20 30 .AA .BB BLUE +STD
CHANGE .AA +STD PREFIX FRED 20 .BB BILL BLUE 30
Yes, we've had to utilize positional operands in a couple places (look at SORT and LOCATE). I see no reason to create any more exceptions.
Basically xxx + 1 trips up on the number. LABEL .AA FRED + 1 (Remember this could be entered as LABEL FRED 1 + .AA)
What is 1? Do we look for FRED in column 1, or is 1 the adjustment? I do not want to get into a discussion of possibilities for distinguishing what was intended. Like what if two numbers are present. Is it a Start/end column? Or is it a Start Col and adjustment?
So Robert, Yes, it is a new 'type' of operand. Giving us now: KWDs, numeric, strings(13 formats), line references (.xxx), line pointers(!nnn), Tags(:xxx) and now Adjustments(+|-nnn)
I'm sorry it has an impact; literals like -1 or +4 must now be quoted. And the new adjustments must have no space between the +/- and the number. I think that still ranks as minimal.
MUEH: MI -1 will now work, I forgot to allow Macros to have Adjustment Type operands.
George
|
|
|
Post by Robert on Jul 9, 2024 12:45:47 GMT -5
You are totally right George, I am sorry I brought this up. I was going to jump in here early and delete my post, but I didn't wake up until 12 noon and the brain is a little foggy. Sorry.
Its sometimes hard to divorce my parsing background from thing I say. A thing like a YACC parser always knows the context of how it go some token, because it constitutes a parse tree and if you wanted to know what command had a "number" token you can just traverse the parse tree. I realize you don't do things like that. My apologies. I never should have brought it up.
|
|
|
Post by George on Jul 9, 2024 13:34:32 GMT -5
Robert: It's fine. I guess I just get 'testy' at times. A lot is just because I'm having more trouble keeping all the balls in the air. I make lots more errors than in the past; I forget things easily, and sometimes my reaction becomes "Sheesh! NOW what are they whining about?".
I'd just like to get this release out, the Beta notes are getting enormous.
|
|
|
Post by Robert on Jul 9, 2024 13:52:22 GMT -5
Yeah, I saw how you first said beta 3 "just" had some "minor bugfixes" and then the list of bug fixes kept getting longer and longer. don't feel bad. I never write code any more. the most I do it edit macros and hardly any of that. I have forgotten so much I used to do.
|
|
|
Post by George on Jul 9, 2024 14:06:57 GMT -5
Well, a lot of those entries are moot. It's a Beta. It has a bug. It's fixed. It can be removed from the list now. Maybe next Beta I'll 'prune' it down to what's different from the 24069 production release.
George
|
|
|
Post by Robert on Jul 9, 2024 14:28:11 GMT -5
You'll have to put out a "production beta" or something ![:))](//storage.proboards.com/forum/images/smiley/cheesy.png) R
|
|
|
Post by George on Jul 9, 2024 15:18:11 GMT -5
Smart *ss!
|
|
|
Post by Robert on Jul 9, 2024 16:07:09 GMT -5
unfortunately, most days I have been feeling like a dumb *ss.
|
|