SideDiff & 17/01/21 ROM

Well that went well :-/

A better fix for this issue could be to alias

Alias$@RunType_FD1 : @RunType_FFB %*0
Alias$@LoadType_FD1 : @LoadType_FFB %*0

as is done in the SideDiff !Boot.

Yes, if FD1 is to be handled that way. I’ve always just stamped text BASIC files with FFB.

Sorry about that. What happens when you try to actually fix things, eh? All those programs waiting to fail when they get a command line longer than BASIC’s string limit…

And hopefully this should fix the ancient OS_EvaluateExpression bug.

And hopefully this should fix the ancient OS_EvaluateExpression bug.

So a golden-oldie dies (yay!)
The reason I chipped in with those specific lines in the Boot file was that I’d been playing with something similar in the Festive season and produced the same ‘Unknown operand’ error. Memory rather than diagnostic talent

All those programs waiting to fail when they get a command line longer than BASIC’s string limit…

Ah, you mean like the method of causing Transient/TrapDelete to crash?
Just create a file with a name that matches the longest allowed, and then delete it with TrapDelete active.

Sorry Fred – discovered that this weekend and forgot to mail a bug report.

Just create a file with a name that matches the longest allowed,

Trying to access a file with a path over ~230 characters crashes the filer.

That’s why my software assumes filenames/paths won’t be more than 255 characters in length – it’s more than the Wimp can handle, so more than you’d get via a Wimp Message.

Trying to access a file with a path over ~230 characters crashes the filer.

It does. But a command line could legitimately be

BASIC -quit The.First.Really.Long.File -input The.Second.Really.Long.File -output The.Third.Really.Long.File

where each of those is ~230 characters long. I believe that’s supported in modern RISC OS versions. However, whilst

SYS "OS_GetEnv" TO env$
PROCprocess_env(env$)

will promptly fall over,

SYS "OS_GetEnv" TO env%
SYS "OS_ReadArgs", ",load=quit/K,input,output", env%, buffer%, buffer_size%

(FSVO buffer% and buffer_size%) will happily extract all of the bits. Which I think was Stuart’s point.

You can then get them by

SYS "XOS_GenerateError", buffer%!8 TO input$
SYS "XOS_GenerateError", buffer%!12 TO output$

and nothing exceeds the 255 characters allowed by BASIC.

Trying to access a file with a path over ~230 characters crashes the filer.

Actually the Filer stayed operational – presumably Transient did a life-saving intervention. Its selfless sacrifice is noted.

Sorry Fred – discovered that this weekend and forgot to mail a bug report.

That’s okay Steve, this should be easy to replicate. To save me some experimentation, how long was that filename?

Exactly that Steve F.

That’s okay Steve, this should be easy to replicate. To save me some experimentation, how long was that filename?

Ah, now you’re asking…

It was something I created when playing around with the longest filenames Word will produce, copied it to RPCEmu and checked what RO would make of it. I think it was about 213 – 236 characters – with spaces of course because Word is brain-dead and breaks titles at punctuation rather than whitespace.

236 is the Word maximum, I think you need to bring that string down to about 213-ish to make RO display it in the filer.

I, currently can’t replicate – I think the current beta ROM may be affecting some functions in Transient. Due to start work in 8 minutes.

Allow me a little reminiscence. In the early days I would decode a command line using the search for " or the offset methods. I saw OS_ReadArgs, but put it to one side as too complex to bother with. When I was writing Basalt a couple of decades ago I thought it would be a good idea to incorporate its facility into BASIC, so I learned how to use it in detail. This resulted in:

ARGS syntax$ TO <list of variables>

where syntax$ is the trailing part after the usual ",quit". Whether with Basalt or not, I have always used OS_ReadArgs since then and I would definitely recommend it, but for a casual programmer it might still look daunting.

(FSVO buffer% and buffer_size%) will happily extract all of the bits.

There’s the rub. If you have several filenames of indeterminant length, how do you know what size of buffer to create, especially as it is only temporary? I always use the 16K ‘scratch space’ at &4000. ;-)

If you have several filenames of indeterminant length, how do you know what size of buffer to create,

That question is perhaps best answered by asking how you receive the filenames. For me, a buffer of ~256 will suffice because you can’t get more sent via a Wimp Message (DataLoad). ;-)

For me, a buffer of ~256 will suffice …

It was pointed out in the parallel topic that a command line can contain many filenames. ;-)

RISC OS uses fixed length buffers for everything. I guess it seemed simplest at the time, but even in those days plenty was known about more sophisticated datatypes. Perhaps the constraint was the price of memory rather than the complexity of garbage collection? If one was starting afresh the design of an OS, surely one of its components would be a memory manager that would enable not only programming languages but also command shells to rid themselves entirely of having to make guesses about the sizes of files or the lengths of commands? For real-time programming I can see that this might present a problem; the OS would also need a policy to protect itself from rogue tasks with inordinate demands. But that should not be made the concern of everyday user-tasks. I have spent so much time with RiscLua, and away from BASIC, that questions about the lengths of strings seem as old-fashioned as theological disputations.

too complex to bother with.

That’s probably what many felt for simple single-parameter extraction. For more complicated stuff, yes, it makes sense.

Have you taken a look at ChangeFSI? I wonder if ReadArgs could cope with that?

I always use the 16K ‘scratch space’ at &4000. ;-)

I’m surprised ReadArgs doesn’t.

It was pointed out in the parallel topic that a command line can contain many filenames. ;-)

Read what I wrote carefully, especially the part mentioning the DataLoad message. ;-)

To be honest, I wonder how likely we are to actually encounter files with names/paths adding up to more than ~236 bytes, given the inherent limitations in the Desktop? I can imagine such files pretty much being pathological cases intended to not work as expected (if at all) outside of the command line.

Likewise, one shouldn’t really be making use of a command line of more than 256 characters unless they know they’re on a system that is capable. The…. I’ve forgotten the name, thing that comes with the DDE to give long command lines… is an alternative that works on all current systems, but it’s a little bit fiddlier.

but also command shells to rid themselves entirely of having to make guesses about the sizes of files or the lengths of commands?

It would be nice, but you’re always going to run into programmers doing stuff like

char filename[11]; // 10 plus terminator

;-)

I have spent so much time with RiscLua, and away from BASIC, that questions about the lengths of strings

The problem with this is that making strings ‘smart’ is a slippery slope to hell. I don’t know Lua, but I know what you mean about strings because php works a bit like that. But it tries too hard. Let me ask you, is “1” the same as 1? The answer is “maybe”. If you add “1” and “1”, is the result “11” or “2”?

You can run into some interesting buglets upon discovering that your “simple string assignment” was interpreted by php in a way that defies logic.

BTW, it’s not just BASIC with string lengths. C does it too. And to a degree I prefer it like that. I’m old school, I like to know that I should allocate ‘x’ bytes for something that is ‘x’ bytes in length.

The problem is, the RISC OS API hasn’t kept up with the underlying changes. Filenames can now be ‘x’ bytes in length. The ROOL guys don’t want to pin down any specific length out of fear that people might start hardcoding such limits, though Jeffrey hinted that the limits weren’t really limits likely to be hit, so Steve’s using 16K of scratch space “just in case” might have some merit. Plus, we can’t blindly allocate sixteen thousand bits for all filenames – if we did that we’d end up with memory consumption to rival Android apps.
What the API ought to do for us now is have a call like OS_GBPB, 12 where if the buffer length is zero then instead of returning the number of objects read in R3, it would return the size of the buffer required to hold “this entry”. That way, one could determine the necessary buffer sizes for things prior to attempting to read them in.

That way, one could determine the necessary buffer sizes for things prior to attempting to read them in.

Agreed. Wimp_LoadTemplate is a good example.

Let me ask you, is “1” the same as 1?

In the current RiscLua, no. In the early days of Lua, there were all sorts of coercions, string <-> number, integers <-> floats, in the belief that this made things easier for users. Slowly the attitude has swung the other way; coercions are being understood to be a source of error. They are turned off by default in RiscLua. You should use explicit tostring, tonumber functions. You can always use metamethods to do clever tricks with a personalized syntax, if you want to. For example if you want to have mail-merge strings containing string-variables:

letter = [[
Dear $donor
   Thanks for your splendid $gift. 
   Happy Xmas from Johnny]]

letter % { donor = "Aunt Agatha"; gift = "bottle of whisky"; }

has the intended value, then you simply precede your code with the statement

(getmetatable "").__mod = \ (s, t) => s:gsub ("%$([%w_]+)", t) end

I wonder how likely we are to actually encounter files with names/paths adding up to more than ~236 bytes, given the inherent limitations in the Desktop? […] Likewise, one shouldn’t really be making use of a command line of more than 256 characters unless they know they’re on a system that is capable.

We’re not talking about single filenames, though, are we?

When you need to know the command line in a BASIC program, you call OS_GetEnv, which returns the command which launched the program. The reason that we’re doing this parsing stuff at all is that it isn’t just the arguments that you’ll get back. First you’ve got

BASIC

which launched BASIC to run the program. Then you’ve got the parameter which told BASIC where your program itself was

-quit "ADFS::HardDisc4.$.Potentially.A.Long.Path.To.The.Program.Itself"

It’s only after that lot is out of the way that we get to the parameters that the user actually entered. So if the command was

Itself -input "ADFS::HardDisc4.$.My.Data.Files.Input" -output "ADFS::HardDisc4.$.My.Data.Files.Output"

the actual command line returned by OS_GetEnv is

BASIC -quit "ADFS::HardDisc4.$.Potentially.A.Long.Path.To.The.Program.Itself" -input "ADFS::HardDisc4.$.My.Data.Files.Input" -output "ADFS::HardDisc4.$.My.Data.Files.Output"

It makes far more sense to accept that the OS will allow what it allows in terms of command line length, and the let OS_ReadArgs worry about breaking that lot up into

LET Input$ = "ADFS::HardDisc4.$.My.Data.Files.Input"
LET Output$ = "ADFS::HardDisc4.$.My.Data.Files.Output"

than to arbitrarily truncate the whole lot at 255 characters whatever the system can handle. Sure, older systems won’t cope with long names, but newer ones will, and will therefore enable any of the filenames to be up to the system maximum of ~230 characters.

Have you taken a look at ChangeFSI? I wonder if ReadArgs could cope with that?

Use syntax$=",quit,wimp" to get possible file in F$ then set task%=LENF$.

We’re not talking about single filenames, though, are we?

It is important to grasp this. My Crunchie might have 6 filenames and many switches. ;-)

Likewise, one shouldn’t really be making use of a command line of more than 256 characters unless they know they’re on a system that is capable.

I recently needed to issue a lot of *copy path1/* path2/* commands from BASIC. As both paths were rather long, I couldn’t fit this into a string for OSCLI. I solved it by defining two system variables first, one containing path1, the other path2. The OSCLI was then *copy <syspath1>/* <syspath2>/* .

More on-topic, I’ve just done a quick check of my set of programs, and so far found just one looking for a quote character in the result of OS_Env. It does this to find the start of the path to the program in order to locate other things.

One effect of this is that that particular program doesn’t work if run from StrongED (using the run button in the window). The environment string in that case is strange.

Nice, but *commands aren’t always the answer – may I refer you to https://www.riscosopen.org/wiki/documentation/show/OS_FSControl%2026

It does this to find the start of the path to the program in order to locate other things.

This can also be obtained using OS_ReadArgs. Programs run using the filetype alias will always be -quit and for me that is what I expect. So I use the -quit as a keyword for the program name, which is then the string at buffer!4

The environment string in that case is strange.

It is run from memory using addresses, I think. I have changed my mode file to always save and then run from disc.

So I tried OS-ReadArgs. I don’t understand the error message:

DEF FNreadargs(input$,key$)
LOCAL A$
  IF DEBUG%AND1 THEN
    *report \V input$ key$
  ENDIF
  SYS "OS_ReadArgs",key$,input$,wlib_block%,256
  REM A$=$(buf%!4)
=A$

input$="BASIC -quit "SCSI::disc256.$.Data.CanoeClub.Slalom.!Slalom21.Programs.LAUNCHER" " key$="quit"
14:49:15.71 ** Error **
  Error  : &000001EB
  Message: Argument repeated

Argument repeated

That’s because you’re asking for a single parameter named “quit” but input$ contains 3 parameters, one of which it will recognise as a switch (-quit).
Presumably you’re after the filename, in which case you need key$ = “,quit/K/S,” (note the commas) and then you’ll be able to read the filename from wlib_block%!8.

Oh, and the string will be terminated with a zero so $(wlib_block%!8) wont work, so use SYS “XOS_GenerateError”,wlib_block!8 TO A$