Reading the contents of an OS variable from a BASIC program.
Gazza
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??
Rob Kendrick
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.
B.
matthew....@gmail.com
The manuals are still there.
The index for the manuals is at http://www.drobe.co.uk/show_manual.php?manual=/sh-cgi
.
The relevant page for OS_ReadVarVal seems to be
http://www.drobe.co.uk/show_manual.php?manual=/sh-cgi?manual=OS%26page=OS_ReadVarVal
.
--
Matthew
Alan Adams
ups.com>
"matthew....@gmail.com" <matthew....@gmail.com>
wrote:
> --
> Matthew
DEF PROCsetsysvar(varname$,varval$)
LOCAL vallen%
LOCAL name% , val%
DIM name% LEN(varname$)+1, val% LEN(varname$)+1
$name%=varname$+CHR$(0)
$val%=varval$+CHR$(0)
vallen%=LEN(varval$)
SYS "OS_SetVarVal",name%,val%,vallen%,0,0
ENDPROC
:
DEF FNgetsysvar(varname$)
LOCAL name% ,val% ,vallen%
DIM name% LEN(varname$)+1,val% 200
$name%=varname$+CHR$(0)
SYS "XOS_ReadVarVal",name%,,-1 TO ,,vallen%
IF vallen%<0 THEN
SYS "OS_ReadVarVal",name%,val%,200,0,3 TO ,,vallen%
val%?vallen%=13
ELSE
?val%=13
ENDIF
=$val%
--
Alan Adams, from Northamptonshire
al...@adamshome.org.uk
http://www.nckc.org.uk/
Theo Markettos
> 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.
Theo
Alan Adams
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
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.
Ste (news)
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> Alan Adams <al...@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!).
http://www.riscosopen.org/content/downloads/module-zipfiles
(IMO: everyone should be running the latest BASIC so that people who write
BASIC programs can use the newer features.)
Ta,
Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Steve Drain
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
David Pitt
> In article <o+B*PB...@news.chiark.greenend.org.uk>,
> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> > Alan Adams <al...@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!).
>
> http://www.riscosopen.org/content/downloads/module-zipfiles
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.
--
David Pitt
Snow Leopard - MessengerPro
David Pitt
> 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.
Martin Bazley
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 ==========================
Gazza
> In message <a636d4f7-dc0c-4850-b788-82f3f6d08...@l34g2000vba.googlegro
> ups.com>
> "matthew.wight...@gmail.com" <matthew.wight...@gmail.com>
>
> - Show quoted text -
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)
John Kortink
On Tue, 06 Oct 2009 17:17:52 +0100, Alan Adams <al...@adamshome.org.uk>
wrote:
>[...]
>
>DEF PROCsetsysvar(varname$,varval$)
>LOCAL vallen%
>LOCAL name% , val%
>DIM name% LEN(varname$)+1, val% LEN(varname$)+1
>$name%=varname$+CHR$(0)
>$val%=varval$+CHR$(0)
>vallen%=LEN(varval$)
>SYS "OS_SetVarVal",name%,val%,vallen%,0,0
>ENDPROC
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).
I.e. simply replace the whole PROC with :
SYS "OS_SetVarVal", varname$, varval$, LEN(varval$), 0, 0
>DEF FNgetsysvar(varname$)
>LOCAL name% ,val% ,vallen%
>DIM name% LEN(varname$)+1,val% 200
>$name%=varname$+CHR$(0)
>SYS "XOS_ReadVarVal",name%,,-1 TO ,,vallen%
>IF vallen%<0 THEN
>SYS "OS_ReadVarVal",name%,val%,200,0,3 TO ,,vallen%
>val%?vallen%=13
>ELSE
>?val%=13
>ENDIF
>=$val%
Same thing, also for the return value.
I.e. :
varval$ = ""
SYS "OS_ReadVarVal", varname$, STRING$(255, CHR$0), 255, 0,
3 TO , varval$
(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)
John Kortink
--
Email : kor...@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink
There's something to be said, for getting out of bed
Ste (news)
It should do.
> Also, is there a version history recorded anywhere?
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Programmer/BASIC/VersionNum
Peter Naulls
[snip huge amount of quoting]
>> Alan Adams, from Northamptonshire
>> a...@adamshome.org.ukhttp://www.nckc.org.uk/- Hide quoted text -
>>
>> - Show quoted text -
>
> 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.
Thanks.
Steve Drain
> 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!).
>
> http://www.riscosopen.org/content/downloads/module-zipfiles
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.
Steve Drain
> 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.
--
Peter Naulls
> Ste (news) wrote:
ib 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.
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.
Ste (news)
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!).
> >
> > http://www.riscosopen.org/content/downloads/module-zipfiles
>
> 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!!
Ste (news)
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,
David Pitt
> In article <ant07154...@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!).
> > >
> > > http://www.riscosopen.org/content/downloads/module-zipfiles
> >
> > 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!
And you know this works?
As I have already said, this does not work here.
Ste (news)
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...
David Pitt
> In article <mpro.kr5ymn00...@pittdj.co.uk>,
> David Pitt <ne...@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
*
> I'll look into it...
I hope the above helps.
Many thanks.
Steve Drain
> 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. ;-)
Steve Drain
> Steve Drain wrote:
> > Ste (news) wrote:
> > 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.
Ste (news)
Steve Drain <st...@kappa.me.uk> wrote:
> Programmers - fine. But what do you do with the programs you write? You
> cannot ignore the users' attitudes.
Run that past me again - what are you asking? Are you asking how I cope with
this situation in my software? If so, there are two answers:
1. I don't use any of the newer BASIC features that were added for RISC OS 5
and beyond
2. I provide my MoreDesk application with an installer that you double-click
and it does all of the other magic
Having things like the BASIC modules managed with a package manager would
make things better in that I could have the BASIC package as a dependency
(solves 1) and have my own application within a package (solves 2,
provinding the package manager is any good).
Steve Drain
> Steve Drain wrote:
I have added back these quotes:
>>Ste (news) wrote:
>>> Steve Drain 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.
>
> Run that past me again - what are you asking? Are you asking how I cope with
> this situation in my software? If so, there are two answers:
>
> 1. I don't use any of the newer BASIC features that were added for RISC OS 5
> and beyond
>
> 2. I provide my MoreDesk application with an installer that you double-click
> and it does all of the other magic
>
> Having things like the BASIC modules managed with a package manager would
> make things better in that I could have the BASIC package as a dependency
> (solves 1) and have my own application within a package (solves 2,
> provinding the package manager is any good).
I do not think there is any difference between us - note my mention of
an installation app above, and also of packages in another post.
Perhaps I should have used "one" rather than "you" in that last post -
I was not asking what you, personally do, but what would have to be
normal practice if we are to rely on every user having the latest BASIC
installed.
BTW does MoreDesk rely on the latest BASIC from ROOL?
Ste (news)
Steve Drain <st...@kappa.me.uk> wrote:
> Perhaps I should have used "one" rather than "you" in that last post -
> I was not asking what you, personally do, but what would have to be
> normal practice if we are to rely on every user having the latest BASIC
> installed.
Ah, I see. Sorry for the confusion.
> BTW does MoreDesk rely on the latest BASIC from ROOL?
Nope, for the very reasons we've been discussing. It does depend upon the 32
bit SharedCLibrary so the installer has to worry about ensuring a new enough
version of that is present.
It's a shame I couldn't rely on the newer BASIC because things like DIM
LOCAL and VDU as a function are pretty useful.
Steve Drain
> Steve Drain wrote:
>
>
> It's a shame I couldn't rely on the newer BASIC because things like DIM
> LOCAL and VDU as a function are pretty useful.
Hmm! Spots soft target - resists the temptation. ;-)
Gazza
> In article <haiemt$v3...@news.eternal-september.org>,
>
> - Show quoted text -
Although I have an A7000+, I'm all for pushing forward RISC OS and
would happilly use a ROOL softload over the 4.39 ROM, but I have yet
to see the IOMD port of the ROOL code working. AFAIK it is still a
WIP. Please update me if the situation has changed.
druck
> 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.
Alternatively don't use a language which isn't up to the job, pick one
which has sensible memory allocation and runs on all versions of the OS.
---druck