Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Memorymanager &8000
16 views
Skip to first unread message
Ron
Mar 31, 2012, 10:25:12 PM3/31/12
to
I am using approx 1K of Memory at &8000 from an Obey file, like this:
Echo <0><0> { >> <TarControl$Dir>.Files.OK }
Load <TarControl$Dir>.Files.OK &8000
Obey -m &8045
And the selected lines are Obeyed, all looks fine.
This avoids using Basic or the tail utility to set some variables,
and the main useage of the Obey files is filer related so it is
not a bad place to be operating from.
The short question, is it safe?
The longer question, What decides the separation of any particular
task/application use of any one logical &8000 allocation?
Using
*Save Ram:whats_at8000 &8000 &8214
If I issue this from a new Task window, it doesn't change, so there
must be a cache to clear possibly?
Something from the heyrick site alludes to it.
"Upon a context switch (ie, making an application 'active') you need
to remap it's memory to begin at &8000 and flush the cache."
I'll have a browse of the PRM's Memory management in the meantime.
Thanks, Ron M.
Echo <0><0> { >> <TarControl$Dir>.Files.OK }
Load <TarControl$Dir>.Files.OK &8000
Obey -m &8045
And the selected lines are Obeyed, all looks fine.
This avoids using Basic or the tail utility to set some variables,
and the main useage of the Obey files is filer related so it is
not a bad place to be operating from.
The short question, is it safe?
The longer question, What decides the separation of any particular
task/application use of any one logical &8000 allocation?
Using
*Save Ram:whats_at8000 &8000 &8214
If I issue this from a new Task window, it doesn't change, so there
must be a cache to clear possibly?
Something from the heyrick site alludes to it.
"Upon a context switch (ie, making an application 'active') you need
to remap it's memory to begin at &8000 and flush the cache."
I'll have a browse of the PRM's Memory management in the meantime.
Thanks, Ron M.
Gerph
Apr 1, 2012, 7:41:00 AM4/1/12
to
On Apr 1, 3:25 am, Ron <b...@woosh.co.nz> wrote:
> I am using approx 1K of Memory at &8000 from an Obey file, like this:
>
> Echo <0><0> { >> <TarControl$Dir>.Files.OK }
> Load <TarControl$Dir>.Files.OK &8000
> Obey -m &8045
Who thought it was a good idea to allow execution of obey files from
> I am using approx 1K of Memory at &8000 from an Obey file, like this:
>
> Echo <0><0> { >> <TarControl$Dir>.Files.OK }
> Load <TarControl$Dir>.Files.OK &8000
> Obey -m &8045
memory? Shoot them now.
No, this is just a bad idea and you should abandon it right now. The
Obey module manages its own files and the environment in which it is
executing, and cannot protect you if you're going to use arbitrary
sections of memory for its data area.
For all of its faults, PipeFS is a far more sensible mechanism to do
what you are
trying to do, and you should use it rather than attempting to
construct files in memory for use with Obey. If you avoid TaskWindows
you will have no problems with doing that. Using <Wimp$ScrapDir> -
which is intended for transient content - is better than trying to
execute random seconds of application space, and will address any of
the issues you might encounter with TaskWindow/PipeFS interaction.
> And the selected lines are Obeyed, all looks fine.
> This avoids using Basic or the tail utility to set some variables,
> and the main useage of the Obey files is filer related so it is
> not a bad place to be operating from.
problem. You don't say /what/ your problem is, but just present an
somewhat bizarre command sequence without any indication of what you
are trying to achieve by it.
> The short question, is it safe?
--
Justin Fletcher
Jonathan Graham Harston
Apr 1, 2012, 7:53:04 PM4/1/12
to
be...@woosh.co.nz wrote:
> I am using approx 1K of Memory at &8000 from an Obey file, like this:
> Echo <0><0> { >> <TarControl$Dir>.Files.OK }
> Load <TarControl$Dir>.Files.OK &8000
I'm surprised that doesn't give an error. Filing commands take
> I am using approx 1K of Memory at &8000 from an Obey file, like this:
> Echo <0><0> { >> <TarControl$Dir>.Files.OK }
> Load <TarControl$Dir>.Files.OK &8000
/hexadecimal/ addresses, to load to 8000 you specify 8000. I've just
tried *LOAD !Boot &8000 on my A5000 and no error occured, but I have
no idea what happened.
The Task Manager "Next" size specifies how much memory the next
task gets. This defaults to 640K or however much is remaining if
less than 640K.
If it is a single-tasking task (ie you never call Wimp_Init and
Wimp_Poll) then you can't relinquish any memory you don't need.
You should specify how much memory you want to use with *WimpTask
which errors if there is less memory in the current task slot than
you ask for, and increases "Next" if neccessary:
WimpSlot -min 1K -max 1K
Echo <0><0> { >> <TarControl$Dir>.Files.OK }
Load <TarControl$Dir>.Files.OK 8000
Obey -m 8045
WimpSlot uses a grain size of whatever your memory mapping hardware
uses, usually 32K.
I'm guessing 'Obey -m' obeys commands in memory. On my system it
gives "File '-m' not found". How does it know it has come to the
end of the commands to execute?
> Using
> *Save Ram:whats_at8000 8000 8214
You will get whatever crap happens to be in the memory that the
task manager choses to page in.
--
J.G.Harston - j...@mdfs.net - mdfs.net/jgh
Ron
Apr 2, 2012, 5:15:32 AM4/2/12
to
In message <120402...@arcade.demon.co.uk>
> The Task Manager "Next" size specifies how much memory the next
> task gets. This defaults to 640K or however much is remaining if
> less than 640K.
>
> If it is a single-tasking task (ie you never call Wimp_Init and
> Wimp_Poll) then you can't relinquish any memory you don't need.
>
> You should specify how much memory you want to use with *WimpTask
> which errors if there is less memory in the current task slot than
> you ask for, and increases "Next" if neccessary:
>
> WimpSlot -min 1K -max 1K
> Echo <0><0> { >> <TarControl$Dir>.Files.OK }
> Load <TarControl$Dir>.Files.OK 8000
> Obey -m 8045
>
> WimpSlot uses a grain size of whatever your memory mapping hardware
> uses, usually 32K.
The main obey file already sets a -min 274K -max 274K for the
Confix program.
I guess I can experiment with some sizes and check to see if the
memory is released after the main obey file completes.
I still have a bit to learn about wimpslots. Even though I have a
large enough next slot, When running the secondary obey files
with the actual tar command they ignored the next slot and each
obey file had to have Wimpslot set individually.
I haven't seen that before.
The other thing I have noticed, maybe it is only with some
unixlib ports, is that there is a grey area where the program
errors in a more obscure way than if it is way to low, when
it will plainly say that there is a memory (slot) shortfall.
>
> I'm guessing 'Obey -m' obeys commands in memory. On my system it
> gives "File '-m' not found". How does it know it has come to the
> end of the commands to execute?
>
Yes, it is not on my RiscPC 3.7 either but loading the RISC OS 5.18
Obey module and it works OK.
I dont know when it was introduced or wether RISC OS 4 has it or is
happy running the newer module, so this is a bit of a stickler.
Obey -m would keep trying to execute lines past the file, and that
is why I have to append an <0> to make it exit. (2 aren't necessary)
> > Using
> > *Save Ram:whats_at8000 8000 8214
>
> You will get whatever crap happens to be in the memory that the
> task manager choses to page in.
>
Yes that seems to be happening OK now.
The above is a typo, I have to use &8000 &8214
Thanks,
j...@arcade.demon.co.uk (Jonathan Graham Harston) wrote:
> be...@woosh.co.nz wrote:
> > I am using approx 1K of Memory at &8000 from an Obey file, like this:
> > Echo <0><0> { >> <TarControl$Dir>.Files.OK }
> > Load <TarControl$Dir>.Files.OK &8000
>
> I'm surprised that doesn't give an error. Filing commands take
> /hexadecimal/ addresses, to load to 8000 you specify 8000. I've just
> tried *LOAD !Boot &8000 on my A5000 and no error occured, but I have
> no idea what happened.
>
I get an operand error if I dont use the &.
> be...@woosh.co.nz wrote:
> > I am using approx 1K of Memory at &8000 from an Obey file, like this:
> > Echo <0><0> { >> <TarControl$Dir>.Files.OK }
> > Load <TarControl$Dir>.Files.OK &8000
>
> I'm surprised that doesn't give an error. Filing commands take
> /hexadecimal/ addresses, to load to 8000 you specify 8000. I've just
> tried *LOAD !Boot &8000 on my A5000 and no error occured, but I have
> no idea what happened.
>
> The Task Manager "Next" size specifies how much memory the next
> task gets. This defaults to 640K or however much is remaining if
> less than 640K.
>
> If it is a single-tasking task (ie you never call Wimp_Init and
> Wimp_Poll) then you can't relinquish any memory you don't need.
>
> You should specify how much memory you want to use with *WimpTask
> which errors if there is less memory in the current task slot than
> you ask for, and increases "Next" if neccessary:
>
> WimpSlot -min 1K -max 1K
> Echo <0><0> { >> <TarControl$Dir>.Files.OK }
> Load <TarControl$Dir>.Files.OK 8000
> Obey -m 8045
>
> WimpSlot uses a grain size of whatever your memory mapping hardware
> uses, usually 32K.
Confix program.
I guess I can experiment with some sizes and check to see if the
memory is released after the main obey file completes.
I still have a bit to learn about wimpslots. Even though I have a
large enough next slot, When running the secondary obey files
with the actual tar command they ignored the next slot and each
obey file had to have Wimpslot set individually.
I haven't seen that before.
The other thing I have noticed, maybe it is only with some
unixlib ports, is that there is a grey area where the program
errors in a more obscure way than if it is way to low, when
it will plainly say that there is a memory (slot) shortfall.
>
> I'm guessing 'Obey -m' obeys commands in memory. On my system it
> gives "File '-m' not found". How does it know it has come to the
> end of the commands to execute?
>
Obey module and it works OK.
I dont know when it was introduced or wether RISC OS 4 has it or is
happy running the newer module, so this is a bit of a stickler.
Obey -m would keep trying to execute lines past the file, and that
is why I have to append an <0> to make it exit. (2 aren't necessary)
> > Using
> > *Save Ram:whats_at8000 8000 8214
>
> You will get whatever crap happens to be in the memory that the
> task manager choses to page in.
>
The above is a typo, I have to use &8000 &8214
Thanks,
Ron
Apr 2, 2012, 5:31:40 PM4/2/12
to
In message <a472384e-8621-46f9...@er9g2000vbb.googlegroups.com>
<snipP
"This avoids using Basic or the tail utility to set some variables,
and the main useage of the Obey files is filer related so it is
not a bad place to be operating from."
Does PipeFs have the capability of reading off the last few lines
similar to tail?
The reading of selected lines from the file was the object of that
exercise.
The main focus of my program is for multipart tars, and the use
of ,xyz extensions for compatibility with Sunfish/Moonfish.
Otherwise, Spark is fine with Tar archives.
I think there are a few issues with running binaries from BASIC
regarding wimpslots also, and a lot of my program is to do with
Renaming Filenames for the multipart archiving, and changing the
CSD for the top tar directory.
I think the operation from the Obey files is smoother, though
programming it in BASIC is much more flexible of course, and
already compatible with all machines.
Thanks for your views,
Ron M.
<snipP
> Where is your problem with using some other mechanism to solve your
> problem. You don't say /what/ your problem is, but just present an
> somewhat bizarre command sequence without any indication of what you
> are trying to achieve by it.
>
> > The short question, is it safe?
>
> The short answer is 'no'.
From my original post,
> problem. You don't say /what/ your problem is, but just present an
> somewhat bizarre command sequence without any indication of what you
> are trying to achieve by it.
>
> > The short question, is it safe?
>
> The short answer is 'no'.
"This avoids using Basic or the tail utility to set some variables,
and the main useage of the Obey files is filer related so it is
not a bad place to be operating from."
similar to tail?
The reading of selected lines from the file was the object of that
exercise.
The main focus of my program is for multipart tars, and the use
of ,xyz extensions for compatibility with Sunfish/Moonfish.
Otherwise, Spark is fine with Tar archives.
I think there are a few issues with running binaries from BASIC
regarding wimpslots also, and a lot of my program is to do with
Renaming Filenames for the multipart archiving, and changing the
CSD for the top tar directory.
I think the operation from the Obey files is smoother, though
programming it in BASIC is much more flexible of course, and
already compatible with all machines.
Thanks for your views,
Ron M.
Ron
Apr 3, 2012, 8:58:18 AM4/3/12
to
In message <aa76087...@ron1954.woosh.co.nz>
My apologies, John, *Save does work with 8000 8214
It is only *Load that requires the &8000 (On my Iyonix, anyway)
With a few extra lines I can Obey the file from <Wimp$ScrapDir>
and it means it is both not executing in Memory, and will work
in all machines as is.
<0> no longer works as a terminator and I have to append the
Obey command to stop the Obey operation from continuing.
Which in turn means running it in a taskwindow so the main
Obey file doesn't quit too.
It runs that quick that no Taskwindow actually appears.
The whole !Run file is
Set TarCtrl$Dir <Obey$Dir>
WimpSlot -min 274K -max 274K
Run <Confix$Dir> -res <TarCtrl$Dir>.Files -default 0 -layout 1
-Task TarCtrl -profiles 0 -help 0 -pos center,center -ok OK
Echo Obey { >> <TarCtrl$Dir>.Files.OK }
Load <TarCtrl$Dir>.Files.OK &8000
Save <Wimp$ScrapDir>.tarctrl 8045 8200
Taskwindow "Obey <Wimp$ScrapDir>.tarctrl"
Delete <Wimp$ScrapDir>.tarctrl
Delete <TarCtrl$Dir>.Files.OK
If %Flow% = "=1" Then Taskwindow <TarCtrl$Dir>.Files.extract -wimp
slot 768K Else Taskwindow <TarCtrl$Dir>.Files.build -wimpslot 768K
Unset %Flow%
Unset %Multi%
Unset Verb
The Load and Save slice off the header section of Confix's setting
file (OK) as it cant be converted into something Obey compatible.
The tail part I can use for any number of variables.
I can add some for options for like multipart size, bzip gzip etc
but I think I can do some testing archiving a harddrive now.
Thanks, Ron M.
It is only *Load that requires the &8000 (On my Iyonix, anyway)
With a few extra lines I can Obey the file from <Wimp$ScrapDir>
and it means it is both not executing in Memory, and will work
in all machines as is.
<0> no longer works as a terminator and I have to append the
Obey command to stop the Obey operation from continuing.
Which in turn means running it in a taskwindow so the main
Obey file doesn't quit too.
It runs that quick that no Taskwindow actually appears.
The whole !Run file is
Set TarCtrl$Dir <Obey$Dir>
WimpSlot -min 274K -max 274K
Run <Confix$Dir> -res <TarCtrl$Dir>.Files -default 0 -layout 1
-Task TarCtrl -profiles 0 -help 0 -pos center,center -ok OK
Echo Obey { >> <TarCtrl$Dir>.Files.OK }
Load <TarCtrl$Dir>.Files.OK &8000
Save <Wimp$ScrapDir>.tarctrl 8045 8200
Taskwindow "Obey <Wimp$ScrapDir>.tarctrl"
Delete <Wimp$ScrapDir>.tarctrl
Delete <TarCtrl$Dir>.Files.OK
If %Flow% = "=1" Then Taskwindow <TarCtrl$Dir>.Files.extract -wimp
slot 768K Else Taskwindow <TarCtrl$Dir>.Files.build -wimpslot 768K
Unset %Flow%
Unset %Multi%
Unset Verb
The Load and Save slice off the header section of Confix's setting
file (OK) as it cant be converted into something Obey compatible.
The tail part I can use for any number of variables.
I can add some for options for like multipart size, bzip gzip etc
but I think I can do some testing archiving a harddrive now.
Thanks, Ron M.
Rick Murray
Apr 4, 2012, 12:22:35 AM4/4/12
to
On Sun, 1 Apr 2012 04:41:00 -0700 (PDT), Gerph <ge...@gerph.org>
wrote:
> Who thought it was a good idea to allow execution of obey files from
> memory? Shoot them now.
Thank you Gerph. I never knew that that option even existed. Given
the simplicity of assembling an obey file, say, in Scrap, I can't
imagine why there would be any possible reason to do it from memory.
That sounds... you know what, the idea is actually making my brain
hurt. I'm going to bed in like ten minutes and the thought there will
be obey files executed from memory. Aaaaaaaaaaargh!!! [I'm not even
certain we can exercise Rule 34 on *this* one]
Best wishes,
Rick.
wrote:
> Who thought it was a good idea to allow execution of obey files from
> memory? Shoot them now.
the simplicity of assembling an obey file, say, in Scrap, I can't
imagine why there would be any possible reason to do it from memory.
That sounds... you know what, the idea is actually making my brain
hurt. I'm going to bed in like ten minutes and the thought there will
be obey files executed from memory. Aaaaaaaaaaargh!!! [I'm not even
certain we can exercise Rule 34 on *this* one]
Best wishes,
Rick.
Ron
Apr 4, 2012, 9:41:32 PM4/4/12
to
In message <almarsoft.8636...@news.orange.fr>
I'm scared to ask what rule 34 is :-)
I have found a nicer way ,so that Obey takes no action on
the particular text.
Set Alias$[Title] <10>
Then Obey ignores it, instead of "File [Title] not found"
The alias should probably be unset after use.
Ron M.
I have found a nicer way ,so that Obey takes no action on
the particular text.
Set Alias$[Title] <10>
Then Obey ignores it, instead of "File [Title] not found"
The alias should probably be unset after use.
Ron M.
Ste (news)
Apr 5, 2012, 7:28:18 AM4/5/12
to
In article <8db1a07...@ron1954.woosh.co.nz>,
program. It sounds like an horrific collection of bodges which for some
reason I cannot understand are being used instead of writing a proper
utility to process the input file(s).
Ta,
Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Ron <be...@woosh.co.nz> wrote:
> The Load and Save slice off the header section of Confix's setting
> file (OK) as it cant be converted into something Obey compatible.
> The tail part I can use for any number of variables.
> I can add some for options for like multipart size, bzip gzip etc
> but I think I can do some testing archiving a harddrive now.
Please tell me this is for your own use and not for some to-be released
> The Load and Save slice off the header section of Confix's setting
> file (OK) as it cant be converted into something Obey compatible.
> The tail part I can use for any number of variables.
> I can add some for options for like multipart size, bzip gzip etc
> but I think I can do some testing archiving a harddrive now.
program. It sounds like an horrific collection of bodges which for some
reason I cannot understand are being used instead of writing a proper
utility to process the input file(s).
Ta,
Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Ron
Apr 5, 2012, 9:27:19 AM4/5/12
to
In message <527ba02...@revi11.plus.com>
It is an exercise in RISC OS CLI scripting which due to some
limitations does lead to bodges. I have improved on the
above situation and am not using &8000 at all now.
I am doing in three lines what BASIC is doing in a page,
not that that is neccessarily important either.
The nature of Tar, bzip, gzip and xz are such that they are
mainly involved with renaming, copying and deleting and
that also suits working from the script.
They are plain unixlib ports that are not optimised in any way
for RISC OS other than Filename compatibility.
The benefit is that they appear to be fully working and offer
some alternate compatibility, especially tar/bzip2 and tar/xz.
I haven't had any trouble with Spark and Tar/gz to date.
However, the prime reason was to have non-compressed 2GB
multipart tar archiving with ,xyz filetyping to give compatibility
with Linux as well.
It has been quite a long haul getting Tar and unixlib to work with
all the possible filenames. I started off knowing little about
!GCC and the Autobuilder, and it has been an ideal project.
Ron M.
limitations does lead to bodges. I have improved on the
above situation and am not using &8000 at all now.
I am doing in three lines what BASIC is doing in a page,
not that that is neccessarily important either.
The nature of Tar, bzip, gzip and xz are such that they are
mainly involved with renaming, copying and deleting and
that also suits working from the script.
They are plain unixlib ports that are not optimised in any way
for RISC OS other than Filename compatibility.
The benefit is that they appear to be fully working and offer
some alternate compatibility, especially tar/bzip2 and tar/xz.
I haven't had any trouble with Spark and Tar/gz to date.
However, the prime reason was to have non-compressed 2GB
multipart tar archiving with ,xyz filetyping to give compatibility
with Linux as well.
It has been quite a long haul getting Tar and unixlib to work with
all the possible filenames. I started off knowing little about
!GCC and the Autobuilder, and it has been an ideal project.
Ron M.
0 new messages