Messy occurence

So working on my set of complex BASIC programs, using StrongED. I was editing one of the many libraries, and adding some debugging code. I had unwittingly managed to extend one line too long.

I saved the library, then ran the calling program.

“Bad program called as function library at line…” The line was the LIBRARY statement. The message is from memory, so may be different.

Re-opened the library in StrongED. Nothing obvious, except the program was a little shorter.

Ran SideDiff against an earlier saved version. Sidediff popped up a message “Line longer than 254 characters, shortened”. Again from memory.

Back to StrongED. The last line now showing in the library is the one that was too long.

So it seems that during StrongED’s save of the program, which involves retokenising the text, the progrsam was truncated immediately AFTER the overlong line.

I’m not blaming anyone but me, but I now have to recreate a lot of editing I’ve done today. I have shortened the line in question, and patched the remaining part of the program from the backup, but it’s going to be difficult to re-do the edits from memory.

Yes, it’s a problem with StrongED Alan. I have seen it too in the past.

It doesn’t stop at 255 chanracters line length on the BASIC mode and when saving (and the retokenizing happens) the rest of the file gets completely corrupted. BTW it can even happens if a comment is too long and passes the 255 length, JFYI.

I have shortened the line in question, and patched the remaining part of the program from the backup, but it’s going to be difficult to re-do the edits from memory.

One suggestion I have, given that we now use Ghz clocked machines, there is no need anymore to stack up multiple instructions in a single line, it doesn’t buy much perfs (compared to other optimisation techniques), so maybe you may wish to consider using one instruction per line.

I know it’s not a fix, but at least you do not need to remember to be careful with the line size.

If, for whatever reason you still wish to stack up instructions, then you can always use a cruncher before releasing your code and write a Makefile that craches your BASIC or something like this.

Hope this helps,

Edit does not appear to fall into this hole, as rather briefly tested with over long comments. On save the file is tokenised with the “too long” lines intact. The ’too long" error occurs at runtime.

Edit, on tokenising a “too long” line cannot enter the full length in the single length byte. Hmm!

An editor that destroys work just because of a user syntax error is a bit harsh.

See !SrcStrED.sTxt.BasicText

     ;------ Find line length

     SUB     R14,R2,R8       ; line length = end - start
     ADD     R14,R14,#2      ; add in space taken up by line number
     CMP     R14,#&100       ; is line too long to fit?
     Bge     TTB_compress    ; if so, try to compress line by removing spaces
     STRB    R14,[R8]        ; write line length

Commenting out the compress helps, as tested once!!!

This is with StrongED 4.69f12.

Zap doesn’t suffer from this either. So that’s a StrongEd bug and Fred’ll be along in a moment to fix it I bet.

Commenting out the compress helps, as tested once!!!

That will only lead to the same line length problem as with Edit.

The cause was a missing Bvs in the SaveBasicWhole routine.

        MOV     R0,R1                           ; (FG) ptr -> start of source data
        MOV     R1,R2                           ; (FG) ptr -> end of source data

        MOV     R2,R3                           ; (FG) ptr -> start of buffer
        ADD     R3,R3,R6                        ; (FG) ptr -> end of buffer

        LDR     R4,[R12,#basic_first%]          ; (FG) first line number to use
        LDR     R5,[R12,#basic_step%]           ; (FG) line number increment
        BL      TextToBasic                     ; (FG) convert text to basic
        Bvs     SBW0                            ; (FG) if err, skip save

With the Bvs in place an error is reported that says which line is too long and the file won’t be saved.

BTW it would be helpful if errors were reported to me directly rather than me having to chance upon them in a public forum.

Edit: looks like you’ve won your bet nemo :-)

:-)

I originally wrote “in a minute” but thought it a bit too much pressure. What a fool I was.

BTW it would be helpful if errors were reported to me directly rather than me having to chance upon them in a public forum.

Sorry Fred. I wasn’t sure whether it was a problem caused by StrongED or within the BASIC interpreter, as the error didn’t appear until attempting to run the program.

In this case the error message was most unhelpful, possibly because it occurred in a library load rather than a run.

Is there a fixed version of StrongED available please?

(It turned out that the long line was only about 50 lines before the end of the program, so there wasn’t too much to recover.

there is no need anymore to stack up multiple instructions in a single line

I wasn’t doing that – it was a single instruction creating a line of text to output. The variable names are long, so although the resulting text was only about 100 lines long, the command was over 254 bytes.

I split it into multiple lines building up the text in a variable before outputting it.

The cause was a missing Bvs in the SaveBasicWhole routine.

Bvs SBW0 ; (FG) if err, skip save

But …

Processing:†RAM::RamDisc0.$.SE.!SrcStrED.sTxt.BasicText
Errors in :†RAM::RamDisc0.$.SE.!SrcStrED.sTxt.BasicText
  1009 S Unknown or missing variable in "<SrcStrED$Dir>.sTxt.BasicText"

I cannot find SBW0.

A bit later Tried Harder!

        LDR     R4,[R12,#basic_first%]          ; (FG) first line number to use
        LDR     R5,[R12,#basic_step%]           ; (FG) line number increment
        BL      TextToBasic                     ; (FG) convert text to basic
        Bvs     SBW0                         ; (FG) iff err, skip save

        MOV     R5,R2                           ; (FG)
        MOV     R4,R8                           ; (FG)
        MOV     R3,#0                           ; (FG)
        MOV     R2,R7                           ; (FG)
        MOV     R1,R9                           ; (FG)
        MOV     R0,#10                          ; (FG)
FN_Debug2(pass%,"OS_File from,to",4,5)
        SWI     "XOS_File"                      ; (FG)
.SBW0
        STRvs   R0,[R13,#0]                     ; (FG)
        LDMFD   R13!,{R0-R12,PC}

Any good?

Is there a fixed version of StrongED available please?

StrongED is an easy build, and it is in BASIC assembler.

@Alan

Sorry Fred. I wasn’t sure whether it was a problem caused by StrongED or within the BASIC interpreter, as the error didn’t appear until attempting to run the program.

That’s okay, but next time please send a message anyway as I’ll be able to assess if it’s down to StrongED or not.

Is there a fixed version of StrongED available please?

No and yes. There is no fixed version of 4.69f12 at the moment but there is 4.70a15 which doesn’t have this problem.

Another option is to do as David has done and build a fixed version of 4.69f12. Good thing that I, finally, put the sources to 4.69f12 on the website last week.

(It turned out that the long line was only about 50 lines before the end of the program, so there wasn’t too much to recover.

Sorry that you lost work because of me, glad to hear it wasn’t too bad.

@David

Any good?

Yes, that the correct spot for SBW0. I figured you might like that little puzzle. ;-)

Now to fix RAM_Fetch in 4.70a16 that has a similar problem.

Zap doesn’t suffer from this

(Src)Edit and StrongEd work with BASIC by asking the interpreter to detokenise the file for display, and to retokenise it afterwards.
Zap, however, deals directly with tokenised BASIC, there is no conversion to text happening.
Both methods have their strengths and weaknesses.

That being said, in this day and age one probably shouldn’t have lines running to the length limit for the source code. Crunch the code (if necessary) on the way to making release versions.

Another option is to do as David has done and build a fixed version of 4.69f12.

Now done. Thanks all.

@ Fred

BTW it would be helpful if errors were reported to me directly rather than me having to chance upon them in a public forum.

Common problem we all have, me to I wish people to report issues using GitHub, but just mentioning it can get some folks have very bad reactions.

So, for next time, what would it be you favorite way to report problems? I have one ready to ship for the Lua module :)

Thanks,

some folks have very bad reactions.

Git is probably good if you use Git, are used to Git, and have Git as part of your workflow.

However, if you don’t Git (either because you just don’t or are a newb at it) than it is somewhere between difficult and incomprehensible.

That being said, there’s a definite benefit to having an open and available bug tracker (there’s one here) in order that bugs can be noted both by people running into the same problem, and by those who are in a position to fix those bugs. Certainly it’s useful to look to see “oh, my favourite pet bug has already been reported so I don’t need to do so”.

I wish people to report issues using GitHub

Just know that for people who don’t use GitHub, it requires them to make an account there in order to report an issue.

(plus, whinging on a forum has that “immediate satisfaction” value ;) )

Git is probably good if you use Git, are used to Git, and have Git as part of your workflow.

Worth remembering that Git is not GitHub (or GitLab). The issue trackers on the sites have nothing to do with Git, either – they’re just additional services offered alongside the source control, because they’re useful.

That being said, there’s a definite benefit to having an open and available bug tracker

Which is basically what GitHub offer…

So, for next time, what would it be you favorite way to report problems?

Putting details on here so others can join in is fine but do send me a PM so I don’t miss it. Most of the time I read this forum regularly but not always.

I have one ready to ship for the Lua module :)

Let me take a wild guess here. You want to be able to run a Lua file without have to save it first. Just like you can in BASIC mode. Am I close?

@ Steve Fryatt

Thanks, I hope one day the community will start to use GitHub to open tickets. Obviously when people will give it a try they will find not only that is much better, but that on the RO Community we offer nice web forms which requires no knowledge of anything to report an issue….

@ Rick

(plus, whinging on a forum has that “immediate satisfaction” value ;) )

I knew it! That is what it’s trully stopping you! XD

@ Fred

Putting details on here so others can join in is fine but do send me a PM so I don’t miss it. Most of the time I read this forum regularly but not always.

Ok, will do. Thx

Let me take a wild guess here. You want to be able to run a Lua file without have to save it first. Just like you can in BASIC mode. Am I close?

Almost! :D there is a bit more:

1) When I use the Lua mode, it gives me an error on latest stable, (it’s been like this for quite a while now, I mean over releases), I think the mode file isn’t complete OR Lua may have some delimiter that causes troubles in the Mode file. The result is no syntax highlight at all.

2) Yes you’re right, I wish to have the Run button for Lua as well, in the end I presented it (on the videos on youtube) like a nice feature for BBC BASIC and Python, so could we please have it for Lua too? :)

3) Could we have a “return” action from when we jump to a function using the “steps” button please (to basically return to where we where before jumping to the function). Right now I have to open multiple Function list windows to be able to quickly “return” (or more appropriately to jump back) to the function where I was before the first jump. No idea if my English is making any sense here, but I hope you’ll figure out what I am asking for, that would really speed up a lot my code editing and code checking

Thanks :)
Oh and yes, beers are on me next time I’ll see you after all the fixes above eheh :D

You want to be able to run a Lua file without have to save it first. Just like you can in BASIC mode.

The current modefile uses SaveRun. Change the section starting ‘Key F10’ to have

 Select SetTmp() Process(text,“Lua <StrongED$ScrapDir>.out”,,NoReplace)

 Adjust SetTmp() Process(text,“Taskwindow \”Lua <StrongED$ScrapDir>.out\" -quit",,NoReplace)

1) When I use the Lua mode, it gives me an error on latest stable, (it’s been like this for quite a while now, I mean over releases),

What’s the error message?

Is it Lua mode with syntax highlighting off or has StrongED reverted to BaseMode? The latter will happen when parsing of a ModeFile fails.

2) Yes you’re right, I wish to have the Run button for Lua as well, in the end I presented it (on the videos on youtube) like a nice feature for BBC BASIC and Python, so could we please have it for Lua too? :)

When I watched the video, and coded along, I missed this too so I’ve already added it to Lua mode.

The default Python(3) mode doesn’t have this either, did you add it yourself?

3) Could we have a “return” action from when we jump to a function using the “steps” button please (to basically return to where we where before jumping to the function).

An Adjust click on the “steps” icon will take you back. I see that the interactive help for the button is incorrect, need to fix that.

Ctrl-G also moves to a definition and another Ctrl-G (or Ctrl-Y) takes you back.

The return stack goes 9 levels deep, the number on the right of the 4 rectangles on the Infobar shows the current level. Ctrl-Shift-Y clears the return stack.

What’s the error message?

StrongED: Error while parsing FIle
File: Lua.ModeFile
Line: Line 25
Error: Missing "

As everything else it should be fixable (IIRC I fixed it in the past), but it’s best to fix it at the source obviously.

Is it Lua mode with syntax highlighting off or has StrongED reverted to BaseMode? The latter will happen when parsing of a ModeFile fails.

StrongEd obviously reverts back to BaseMode and the Lua Mode can’t be used (even when selected manually).

The default Python(3) mode doesn’t have this either, did you add it yourself?

That is entirely possible, I also did my own C++ Mode file for modern C++ syntax (not needed with DDE C++) and started (and never finished) the GNU ASM one. But I don’t remember tbh, so I’ll double check and, if needed, I’ll send the one for Python.

Also please note: When fixing the error above, the “Run” button works well for Lua, I think Gavin already added that and also the “Build” button, so I think the whole thing would get fixed for all users as soon as the error above is fixed.

An Adjust click on the “steps” icon will take you back. I see that the interactive help for the button is incorrect, need to fix that.

Haaa thx! Then the help didn’t help I guess XD

[edit]
I added some more info after checking one of my machines where in the past I fixed the error for the Lua Mode
[/edit]

Also (at risk to start another git war), would it be ok if we create a shared repo of at least the modes for StrongED?

With the video making I am sure more things will come up and it would be nice if we could have a repo easy to share and to use to quickly fix problems.

Just proposing an idea to help on getting StrongED even better and faster, if that is ok.

would it be ok if we create a shared repo of at least the modes for StrongED?

I second that. I have always taken advantage of the flexibility that StrongED offers for personalization, much increased over the years by Fred. In fact I even personalize the base mode, cutting out the stuff I do not need or do not want. However I do recognize the utility of standardization, and I sometimes forget, when posting a screen capture, for example, that other people may not be accustomed to what I have shown them.

A propos the Lua mode, I am pretty sure that originally I used StrongED’s Process command. But, somewhere along the line, RunSave entered the fray without my noticing. I guess everybody can have a different preference for which behaviour they want, especially if the proposed shared repository is properly documented. Years ago debugging StrongED modes could be tricky. Again, hats off to Fred for making it a lot easier.

StrongED: Error while parsing FIle
File: Lua.ModeFile
Line: Line 25
Error: Missing "

Yes, I remember that one. In one of the search expressions there is a space missing. The Lua mode that comes with 4.69f12 has that fixed so you must have an older copy in UserPrefs.

and started (and never finished) the GNU ASM one.

Could you send me a copy please. After seeing the videos I started a GnuAsm mode myself, at the moment it’s just a copy of ObjAsm mode with directives replaced by gas directives.

the “Run” button works well for Lua,

It does, and with the following definitions tied to the ‘Run’ icon you can choose whether the file should be saved before being run.

s-Select SetTmp() SaveRun("Lua <StrongED$Tmp_FileName>")

s-Adjust SetTmp() SaveRun("Taskwindow \"Lua <StrongED$Tmp_FileName>\" -quit")

Select SetTmp() Process(text,"Lua <StrongED$ScrapDir>.out",,NoReplace)

Adjust SetTmp() Process(text,"Taskwindow \"Lua <StrongED$ScrapDir>.out\" -quit",,NoReplace)

Could you send me a copy please. After seeing the videos I started a GnuAsm mode myself, at the moment it’s just a copy of ObjAsm mode with directives replaced by gas directives.

Sure, and I did exactly the same ahahah :D

Give me some days please, it’s a bit of a busy time at work at the moment, but sure, will do.

It does, and with the following definitions tied to the ‘Run’ icon you can choose whether the file should be saved before being run.

Boom! +1000 points to both Gavin and Fred! :)

Thanks!