I need to be able to read the value of an OS variable and transfer it to a BASIC string. I seem to remember a SWI something like "OS_ReadVarVal" or something like that, but this was a long long time ago.
Gazza <use...@garethlock.com> wrote: > I need to be able to read the value of an OS variable and transfer it > to a BASIC string. I seem to remember a SWI something like > "OS_ReadVarVal" or something like that, but this was a long long time > ago.
> Can anyone confirm this??
StrongHelp with the freely-downloadable PRM manuals is your friend. Drobe used to have an HTML interface to them; don't know if they still do.
On Oct 6, 12:24 am, Rob Kendrick <n...@rjek.com> wrote:
> On Mon, 5 Oct 2009 15:09:46 -0700 (PDT)
> Gazza <use...@garethlock.com> wrote: > > I need to be able to read the value of an OS variable and transfer it > > to a BASIC string. I seem to remember a SWI something like > > "OS_ReadVarVal" or something like that, but this was a long long time > > ago.
> > Can anyone confirm this??
> StrongHelp with the freely-downloadable PRM manuals is your friend. > Drobe used to have an HTML interface to them; don't know if they still > do.
> On Oct 6, 12:24 am, Rob Kendrick <n...@rjek.com> wrote: >> On Mon, 5 Oct 2009 15:09:46 -0700 (PDT)
>> Gazza <use...@garethlock.com> wrote: >>> I need to be able to read the value of an OS variable and transfer it >>> to a BASIC string. I seem to remember a SWI something like >>> "OS_ReadVarVal" or something like that, but this was a long long time >>> ago.
>>> Can anyone confirm this??
>> StrongHelp with the freely-downloadable PRM manuals is your friend. >> Drobe used to have an HTML interface to them; don't know if they still >> do.
Alan Adams <a...@adamshome.org.uk> wrote: > LOCAL name% , val% > DIM name% LEN(varname$)+1, val% LEN(varname$)+1
Don't have LOCAL DIMs, because they're memory leaks. BASIC allocates the memory, and at the end of the function loses the pointer to it. But the memory is still allocated, and if you do this regularly you'll run out. There's no way to free memory in plain BASIC.
I think Basalt might provide a fix to this. The nastier way to do it is to just use a static block defined to be 'large enough' on initialisation.
In message <o+B*PB...@news.chiark.greenend.org.uk> Theo Markettos <theom+n...@chiark.greenend.org.uk> wrote:
> Alan Adams <a...@adamshome.org.uk> wrote: >> LOCAL name% , val% >> DIM name% LEN(varname$)+1, val% LEN(varname$)+1 > Don't have LOCAL DIMs, because they're memory leaks. BASIC allocates the > memory, and at the end of the function loses the pointer to it. But the > memory is still allocated, and if you do this regularly you'll run out. > There's no way to free memory in plain BASIC. > I think Basalt might provide a fix to this. The nastier way to do it is to > just use a static block defined to be 'large enough' on initialisation.
An earlier version did just that. I revised it to this because it's in a library of general purpose routines, and I wanted to avoid a separate initialisation routine. I didn't realise it was a memory leak though. Fortunately I call this very rarely.
In article <o+B*PB...@news.chiark.greenend.org.uk>, Theo Markettos <theom+n...@chiark.greenend.org.uk> wrote:
> Alan Adams <a...@adamshome.org.uk> wrote: > > LOCAL name% , val% > > DIM name% LEN(varname$)+1, val% LEN(varname$)+1
> Don't have LOCAL DIMs, because they're memory leaks. BASIC allocates the > memory, and at the end of the function loses the pointer to it. But the > memory is still allocated, and if you do this regularly you'll run out. > There's no way to free memory in plain BASIC.
Or, use DIM LOCAL which is in the version of BASIC that you can freely download from the RISC OS Open site...
DIM name% LOCAL size%
Just pop BASIC and BASICTrans into !Boot.Choices.Boot.PreDesk to load them during boot (I don't think BASIC will be RMRun from PreDesk - it should be RMLoaded - if it's RMRun, your boot sequence will drop into BASIC!).
Gazza wrote: > I need to be able to read the value of an OS variable and transfer it > to a BASIC string. I seem to remember a SWI something like > "OS_ReadVarVal" or something like that, but this was a long long time > ago.
> Can anyone confirm this??
I'm probably flogging a dead horse, but:
string$=SYS(sys_var_name$)
There are SYS statements to set and unset system variables, too. ;-)
-- ; ,', * Basalt * - gives RO 3.10+ versions of BASIC V new and alternative ;,' keywords, dynamic memory for arrays and blocks, new variable types. ;', Legal, fast and simple to use. Freeware - version 0.98ß - 19 Aug 03 ,; ',, Steve Drain, Kappa : http://www.kappa.me.uk/basalt.htm
"Ste (news)" <st...@revi11.plus.com> wrote: > In article <o+B*PB...@news.chiark.greenend.org.uk>, > Theo Markettos <theom+n...@chiark.greenend.org.uk> wrote: > > Alan Adams <a...@adamshome.org.uk> wrote: > > > LOCAL name% , val% DIM name% LEN(varname$)+1, val% LEN(varname$)+1
> > Don't have LOCAL DIMs, because they're memory leaks. BASIC allocates > > the memory, and at the end of the function loses the pointer to it. But > > the memory is still allocated, and if you do this regularly you'll run > > out. There's no way to free memory in plain BASIC.
> Or, use DIM LOCAL which is in the version of BASIC that you can freely > download from the RISC OS Open site...
> DIM name% LOCAL size%
> Just pop BASIC and BASICTrans into !Boot.Choices.Boot.PreDesk to load them > during boot (I don't think BASIC will be RMRun from PreDesk - it should be > RMLoaded - if it's RMRun, your boot sequence will drop into BASIC!).
Well that is one way of destroying VRPC/Mac. With the two modules in PreDesk the Boot disappeared into a morass of errors. VRPC had to be stopped from the Mac desktop, the modules removed and the all then /DS_Store files that the Mac filer installs had to be removed.
Take 2 then, rmloading the modules from the desktop. This appeared to work, a test prog using the DIM LOCAL syntax ran without error. The snag was that !Locate's !Boot threw a wobbler, an abort on data transfer from this innocent looking line :-
theme_path$=theme_dir$+"."+theme$
Take 2a, trying the same on a real RiscPC/OS6.06 produces a similar data abort.
> (IMO: everyone should be running the latest BASIC so that people who write > BASIC programs can use the newer features.)
Wouldn't that be nice, but why just BASIC, if we all ran the latest OS we could all use all the latest features. Anyway in this instance there does seem to be an impediment.
Obviously this tip is only applicable to the Iyonix but those two modules in the Iyonix's !Boot causes a similar error rash to that on VRPC, and it also trips up !Locate's !Run.
One last point, has not OS5's BASIC always had the DIM LOCAL option.
Steve Drain <st...@kappa.me.uk> wrote: > Gazza wrote: > > I need to be able to read the value of an OS variable and transfer it to > > a BASIC string. I seem to remember a SWI something like "OS_ReadVarVal" > > or something like that, but this was a long long time ago.
> > Can anyone confirm this??
> I'm probably flogging a dead horse, but:
> string$=SYS(sys_var_name$)
> There are SYS statements to set and unset system variables, too. ;-)
Basalt also supports DIM LOCAL, useful for OSes other than the Iyonix's.
> In article <o+B*PB...@news.chiark.greenend.org.uk>, > Theo Markettos <theom+n...@chiark.greenend.org.uk> wrote: > > Alan Adams <a...@adamshome.org.uk> wrote: > > > LOCAL name% , val% > > > DIM name% LEN(varname$)+1, val% LEN(varname$)+1
> > Don't have LOCAL DIMs, because they're memory leaks. BASIC allocates the > > memory, and at the end of the function loses the pointer to it. But the > > memory is still allocated, and if you do this regularly you'll run out. > > There's no way to free memory in plain BASIC.
> Or, use DIM LOCAL which is in the version of BASIC that you can freely > download from the RISC OS Open site...
> DIM name% LOCAL size%
> Just pop BASIC and BASICTrans into !Boot.Choices.Boot.PreDesk to load them > during boot (I don't think BASIC will be RMRun from PreDesk - it should be > RMLoaded - if it's RMRun, your boot sequence will drop into BASIC!).
> (IMO: everyone should be running the latest BASIC so that people who write > BASIC programs can use the newer features.)
Does this module work on 26-bit systems as well?
Also, is there a version history recorded anywhere?
-- __<^>__ / _ _ \ I don't have a problem with God; it's his fan club I can't stand. ( ( |_| ) ) \_> <_/ ======================= Martin Bazley ==========================
> > On Oct 6, 12:24 am, Rob Kendrick <n...@rjek.com> wrote: > >> On Mon, 5 Oct 2009 15:09:46 -0700 (PDT)
> >> Gazza <use...@garethlock.com> wrote: > >>> I need to be able to read the value of an OS variable and transfer it > >>> to a BASIC string. I seem to remember a SWI something like > >>> "OS_ReadVarVal" or something like that, but this was a long long time > >>> ago.
> >>> Can anyone confirm this??
> >> StrongHelp with the freely-downloadable PRM manuals is your friend. > >> Drobe used to have an HTML interface to them; don't know if they still > >> do.
There's no need whatsoever for the explicit DIMming and 0-termination. On SYS calls, BASIC already takes care of that for you (if there's a string parameter, its 0-terminated value is copied to the BASIC stack, and discarded after the SYS call).
(varval$ will be "" if the variable is undefined, the STRING$ reserves a temporary buffer for the return value on the BASIC stack, which is discarded after the SYS call)
> Thanks... Those two should do what I want them to do... As far as the > LOCAL DIM issue is concerned, I'll just make the whole lot dependant > on LibASH. (http://www.garethlock.com/acorn/invaders/libash.zip)
I know this is probably a lost cause, because you've been asked many times before. Please don't quote the entire message, and especially please don't signatures. Looks like you're cutting and pasting in Google Groups. I know it has bad habits, but I don't think even it is that broken.
Ste (news) wrote: > Theo Markettos wrote: > > Alan Adams wrote: > > > LOCAL name% , val% > > > DIM name% LEN(varname$)+1, val% LEN(varname$)+1 > > Don't have LOCAL DIMs, because they're memory leaks. BASIC allocates the > > memory, and at the end of the function loses the pointer to it. But the > > memory is still allocated, and if you do this regularly you'll run out. > > There's no way to free memory in plain BASIC. > Or, use DIM LOCAL which is in the version of BASIC that you can freely > download from the RISC OS Open site...
> DIM name% LOCAL size%
Or DIM LOCAL name% size%
which you can add to /any/ version of BASIC. ;-)
> Just pop BASIC and BASICTrans into !Boot.Choices.Boot.PreDesk to load them > during boot (I don't think BASIC will be RMRun from PreDesk - it should be > RMLoaded - if it's RMRun, your boot sequence will drop into BASIC!).
I love that "Just pop"; poking around in !Boot can be dodgy, but perhaps you could provide an installation app, that could be included with new software requiring new versions of BASIC. We once did that with the SharedCLib etc.
> (IMO: everyone should be running the latest BASIC so that people who write > BASIC programs can use the newer features.)
We have been over this ground before, and the likelihood of even a majority of remaining users keeping up with the latest version of BASIC seems very remote. And we do know that you cannot replace BASIC dynamically.
-- ; ,', * Basalt * - gives RO 3.10+ versions of BASIC V new and alternative ;,' keywords, dynamic memory for arrays and blocks, new variable types. ;', Legal, fast and simple to use. Freeware - version 0.98ß - 19 Aug 03 ,; ',, Steve Drain, Kappa : http://www.kappa.me.uk/basalt.htm
Theo Markettos wrote: > Alan Adams wrote: > > LOCAL name% , val% > > DIM name% LEN(varname$)+1, val% LEN(varname$)+1 > Don't have LOCAL DIMs, because they're memory leaks. BASIC allocates the > memory, and at the end of the function loses the pointer to it. But the > memory is still allocated, and if you do this regularly you'll run out. > There's no way to free memory in plain BASIC.
Look far enough back in c.s.a.p and you will find half a dozen or more ways to grab a temporary block suggested, some more dodgy or awkward than others. Here is a variant on one where BASIC actually frees the heap memory itself:
DEFPROClocal_dim LOCAL a%,a$,b%,b$ a%=END:a$=STRING$(255," ") b%=END:b$=a$ REM use as if DIM a% LOCAL 255, b% LOCAL 255 (or DIM a% LOCAL 511) ENDPROC
You must be very careful not to create any more objects on the heap. There are other pitfalls, too, so of course I suggest using Basalt if you do not have the ROOL version of BASIC. They both use code very similar to creating local arrays.
> I think Basalt might provide a fix to this. The nastier way to do it is to > just use a static block defined to be 'large enough' on initialisation.
-- ; ,', * Basalt * - gives RO 3.10+ versions of BASIC V new and alternative ;,' keywords, dynamic memory for arrays and blocks, new variable types. ;', Legal, fast and simple to use. Freeware - version 0.98ß - 19 Aug 03 ,; ',, Steve Drain, Kappa : http://www.kappa.me.uk/basalt.htm
>> (IMO: everyone should be running the latest BASIC so that people who write >> BASIC programs can use the newer features.)
> We have been over this ground before, and the likelihood of even a > majority of remaining users keeping up with the latest version of BASIC > seems very remote. And we do know that you cannot replace BASIC > dynamically.
I'm afraid I don't recall the previous discussions, but I disagree. ROOL are keen to start deploying stuff as RiscPkg packages - this requires as yet uncommitted manpower/volunteers, but this is exactly the kind of thing that might be a dependency or an update.
Whilst the rollout of the 32-bit SCL was heroic, it was still a PITA and required manual steps. That's definitely something you want to avoid as much as possible.
In article <ant0715471cbv...@kappa.zetnet.co.uk>, Steve Drain <st...@kappa.me.uk> wrote:
> Ste (news) wrote: > > Just pop BASIC and BASICTrans into !Boot.Choices.Boot.PreDesk to load > > them during boot (I don't think BASIC will be RMRun from PreDesk - it > > should be RMLoaded - if it's RMRun, your boot sequence will drop into > > BASIC!).
> I love that "Just pop"; poking around in !Boot can be dodgy, but perhaps > you could provide an installation app, that could be included with new > software requiring new versions of BASIC. We once did that with the > SharedCLib etc.
This _is_ csap, with "programmer" being the operative word! I'm assuming that the readers here are quite capable of putting a subdir in PreDesk with a !Run obey file that RMEnsures and RMLoads the two modules as required!
If you don't know what you are doing, DON'T DO IT!!
Ta,
Steve
-- Steve Revill @ Home Note: All opinions expressed herein are my own.
> >> (IMO: everyone should be running the latest BASIC so that people who > >> write BASIC programs can use the newer features.)
> > We have been over this ground before, and the likelihood of even a > > majority of remaining users keeping up with the latest version of BASIC > > seems very remote. And we do know that you cannot replace BASIC > > dynamically.
> I'm afraid I don't recall the previous discussions, but I disagree. ROOL > are keen to start deploying stuff as RiscPkg packages - this requires as > yet uncommitted manpower/volunteers, but this is exactly the kind of thing > that might be a dependency or an update.
> Whilst the rollout of the 32-bit SCL was heroic, it was still a PITA and > required manual steps. That's definitely something you want to avoid as > much as possible.
I agree completely. With a decent package manager installed across RISC OS systems, issues such as keeping people up to date with modules such as BASIC would be pretty simple to manage.
Of course, the RISC OS world is a bit odd, I bet a lot of users are still using > 10 year old machines and have at best dial-up, but at some point we're going to have to start pushing the platform (and the laggards) forwards or the overheads imposed upon developers will just be too great.
A package manager installed in a new Universal disc image, along with RISC OS 5 available to all for free would be one possible way to harmonise things. Let the flame war begin...
Thanks,
Steve
-- Steve Revill @ Home Note: All opinions expressed herein are my own.
"Ste (news)" <st...@revi11.plus.com> wrote: > In article <ant0715471cbv...@kappa.zetnet.co.uk>, > Steve Drain <st...@kappa.me.uk> wrote: > > Ste (news) wrote: > > > Just pop BASIC and BASICTrans into !Boot.Choices.Boot.PreDesk to load > > > them during boot (I don't think BASIC will be RMRun from PreDesk - it > > > should be RMLoaded - if it's RMRun, your boot sequence will drop into > > > BASIC!).
> > I love that "Just pop"; poking around in !Boot can be dodgy, but perhaps > > you could provide an installation app, that could be included with new > > software requiring new versions of BASIC. We once did that with the > > SharedCLib etc.
> This _is_ csap, with "programmer" being the operative word! I'm assuming > that the readers here are quite capable of putting a subdir in PreDesk > with a !Run obey file that RMEnsures and RMLoads the two modules as > required!
In article <mpro.kr5ymn00001h2013h.n...@pittdj.co.uk>, David Pitt <n...@pittdj.co.uk> wrote:
> And you know this works?
This is what I had in my boot sequence for years before softloading the latest RISC OS.
> As I have already said, this does not work here.
That is quite possible - I've not tried softloading BASIC for a while so it may be that someone has broken it. The only way we at ROOL find this stuff out is if and when people report problems to us.
I'll look into it...
Steve
-- Steve Revill @ Home Note: All opinions expressed herein are my own.
"Ste (news)" <st...@revi11.plus.com> wrote: > In article <mpro.kr5ymn00001h2013h.n...@pittdj.co.uk>, > David Pitt <n...@pittdj.co.uk> wrote: > > And you know this works?
> This is what I had in my boot sequence for years before softloading the > latest RISC OS.
> > As I have already said, this does not work here.
> That is quite possible - I've not tried softloading BASIC for a while so > it may be that someone has broken it. The only way we at ROOL find this > stuff out is if and when people report problems to us.
This is what SysLog found as the Iyonix, OS5.14, booted.
08 Oct 07:50:26 000 80000002: Error from (unknown): Internal error: abort on data transfer at &202E3C10 08 Oct 07:50:27 000 80000002: Error from (unknown): Internal error: abort on data transfer at &202E3C10 08 Oct 07:50:28 000 80000002: Error from (unknown): Internal error: abort on data transfer at &202E3C10 08 Oct 07:50:29 000 00000000: Error from (unknown): !Alarm RunImage cannot be found 08 Oct 07:50:46 000 000000FF: Error from ResFind: Internal error: abort on data transfer at &202E3B70 at 25 08 Oct 07:50:47 000 000000F8: Error from (unknown): Filing system or path StrongEDRes: not present
*where 202e3c10 Address 202E3C10 is at offset 00004A5C in module BASIC *where Address 202E3B70 is at offset 000049BC in module BASIC *
Peter Naulls wrote: > Steve Drain wrote: > > We have been over this ground before, and the likelihood of even a > > majority of remaining users keeping up with the latest version of BASIC > > seems very remote. And we do know that you cannot replace BASIC > > dynamically.
> I'm afraid I don't recall the previous discussions, but I disagree. > ROOL are keen to start deploying stuff as RiscPkg packages - this > requires as yet uncommitted manpower/volunteers, but this is > exactly the kind of thing that might be a dependency or an update.
I entirely agree that this would be a prime candidate for RiskPkg.
> Whilst the rollout of the 32-bit SCL was heroic, it was still a PITA and > required manual steps. That's definitely something you want to avoid as > much as possible.
I was thinking of the original soft-loaded SCL. Before the universal !Boot its replacement usually involved no more than dragging a dummy !System over the main one. Ah! Simple times. ;-)
-- ; ,', * Basalt * - gives RO 3.10+ versions of BASIC V new and alternative ;,' keywords, dynamic memory for arrays and blocks, new variable types. ;', Legal, fast and simple to use. Freeware - version 0.98ß - 19 Aug 03 ,; ',, Steve Drain, Kappa : http://www.kappa.me.uk/basalt.htm
Ste (news) wrote: > Steve Drain wrote: > > Ste (news) wrote: > > I love that "Just pop"; poking around in !Boot can be dodgy, but perhaps > > you could provide an installation app, that could be included with new > > software requiring new versions of BASIC. We once did that with the > > SharedCLib etc.
> This _is_ csap, with "programmer" being the operative word! I'm assuming > that the readers here are quite capable of putting a subdir in PreDesk with > a !Run obey file that RMEnsures and RMLoads the two modules as required!
> If you don't know what you are doing, DON'T DO IT!!
Programmers - fine. But what do you do with the programs you write? You cannot ignore the users' attitudes.
-- ; ,', * Basalt * - gives RO 3.10+ versions of BASIC V new and alternative ;,' keywords, dynamic memory for arrays and blocks, new variable types. ;', Legal, fast and simple to use. Freeware - version 0.98ß - 19 Aug 03 ,; ',, Steve Drain, Kappa : http://www.kappa.me.uk/basalt.htm
|
