In a message dated 16/01/05 11:04:53 GMT Standard Time,
[EMAIL PROTECTED] writes:
Yes, I agree that these would be fine for our purposes IF IT WERE NOT FOR
ONE PROBLEM.
PROG_USE and DATA_USE are system wide settings and cannot vary between
programs. If you launch one program it could
ONE PROBLEM.
PROG_USE and DATA_USE are system wide settings and cannot vary
between programs. If you launch one program it could read the
current PROG_USE and DATA_USE settings at the time that it is
started, but again, you have to presume that the user is going to
alter these every time
I mean things like .. and \ (root directory) of DOS.
Yes!!
Ok, so at least one likes my idea :-)
Two, I hope?
Three now, I like the idea of having '..' etc too!
Shouldn't we just decide on a suggested value now instead of
making
it dynamic (things like configuration options can't be dynamic
In a message dated 14/01/05 20:09:29 GMT Standard Time,
[EMAIL PROTECTED] writes:
stack (a7)
channel count
channels
command string
magic (.w) - (a6,a5) (as at present)
program's name length (.w)
HD's length (.w)
program's name bytes
padding of above to 42
Wolfgang Lenerz wrote:
Moreover, Joachim said on this list that there is a mechanism in the heap
allocation/release whereby a call would be made to some user specified code
when the mem is released. I can't find this facility anywhere, thgough. All
that exists, AFAIK, is an address that will
P Witte wrote:
Even though it is my idea this probably needs more thinking. The
device I proposed is probably not the way to go, instead perhaps the
OPEN routine would need to be changed to automatically make use of the
current directory, otherwise it's probably somewhat pointless. BUT
if
Wolfgang Lenerz writes:
But why? Its enough to know it can be done without knowing how ;)
OK, so this whole discussion makes no sense, I should just have gone
ahead...
That does not follow. The point of the discussion is not to fall into fixed
ideas before all the issues have been explored.
On 15 Jan 2005 at 13:50, P Witte wrote:
(...)
Im trying to understand the present state of play, so how do you see the
question of Qdos compatibility and any consequences? Should a Current
Directory [CD] be included with the HD or is this a different project? How
do filename/path limits
Wolfgang Lenerz schrieb:
What we want is
a home directory. That is the dir the prog was executed from
a home filename if I may call it that, i.e. the total name of the file that
was executed (if possible, re: executable things).
both of these are notaionally immutable.
a current directory.
P Witte wrote:
DATA_USE 'win1_prg'
DDOWN 'ext'
PRINT DATAD$
would print win1_prg_ext_ on your screen.
I should add: Whether it exists or not, ie it appears to be a simple string
operation.
Per
___
QL-Users Mailing List
Marcel Kilgus writes:
I mean things like .. and \ (root directory) of DOS.
Yes!!
Ok, so at least one likes my idea :-)
Two, I hope?
Shouldn't we just decide on a suggested value now instead of making
it dynamic (things like configuration options can't be dynamic
anyway)? Windows
George writes:
stack (a7)
channel count
channels
command string
magic (.w) - (a6,a5) (as at present)
program's name length (.w)
HD's length (.w)
program's name bytes
padding of above to 42 bytes
Since there is nothing on the stack after the
Wolfgang Lenerz writes:
set a default filename for a job with a certain name
No. I dont see the point. They can just use PROGD$ as now.
No, I thought about hot_rext'd progs.
What are they?. I dont have a hot_rext (or similar) command. If this is
contained in some toolkit, then that
Marcel Kilgus writes:
Also something one should probably think about: should functions like
OPEN automatically use the current directory if no drive name is
given? Currently most commands default to DATAD$.
Or, speaking completely into the blue, what about a meta device like
DEV_ that uses
On 14 Jan 2005 at 11:54, P Witte wrote:
(...)
What are they?. I dont have a hot_rext (or similar) command. If this is
contained in some toolkit, then that toolkit should be altered, not the
system.
yes, you do :-)
eg ert hot_rext(' f ',' win1_progs_fifi ').
Sets FiFi up as a hotkey (in fact
On 14 Jan 2005 at 15:03, Wolfgang Lenerz wrote:
yes, you do :-)
No you don't.
I meant hot_res, of course.
Woflgang
www.scp-paulet-lenerz.com
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Wolfgang Lenerz wrote:
You will notice that (contrary to the long file names topic) I
didn't ask a question, but made a suggestion. This implies that I'm
quite willing to do that stuff...
Very well :-) I'm willing to contribute, perhaps in adapting the
clients.
I'm not promising anything
In a message dated 14/01/05 00:12:56 GMT Standard Time, [EMAIL PROTECTED]
writes:
the complete filename
the dir whence it came from (home dir)
the current dir which will initially be the home dir
This is just a semi-thought. If a file is called win1_d1_twaddle and there
is no directory
On 14 Jan 2005 at 16:38, Marcel Kilgus wrote:
(...)
Very well :-) I'm willing to contribute, perhaps in adapting the
clients.
yes QPAC2.
Does anybody have a valid email address for Thierry Godefroy. It would be
nice to adapt FileInfo II, too.
(...)
Even though it is my idea this
On 14 Jan 2005 at 11:22, [EMAIL PROTECTED] wrote:
(...)
This is just a semi-thought. If a file is called win1_d1_twaddle and
there
is no directory called win1_d1_ then the home directory is win1_. Now,
while the program is in operation someone types MAKE_DIR win1_d1 and
presses
ENTER.
Marcel Kilgus writes:
Even though it is my idea this probably needs more thinking. The
device I proposed is probably not the way to go, instead perhaps the
OPEN routine would need to be changed to automatically make use of the
current directory, otherwise it's probably somewhat pointless.
Wolfgang Lenerz writes:
What are they?. I dont have a hot_rext (or similar) command. If this is
contained in some toolkit, then that toolkit should be altered, not the
system.
yes, you do :-)
eg ert hot_rext(' f ',' win1_progs_fifi ').
Sets FiFi up as a hotkey (in fact an executable
Wolfgang Lenerz writes:
It will be set up as a thing (since I don't think we have found any
other satisfactory solution for compiled Basic).
We havent really tried, but ok
Go ahead!!!
But why? Its enough to know it can be done without knowing how ;)
Actually I can think of one
On 14 Jan 2005 at 20:08, P Witte wrote:
(...)
But why? Its enough to know it can be done without knowing how ;)
OK, so this whole discussion makes no sense, I should just have gone ahead...
More seriously, I don't pretend to know it all and if you have a better idea,
I (generally) don't
On Thu, 13 Jan 2005 08:14:30 +0100, Wolfgang Lenerz
[EMAIL PROTECTED] wrote:
It will be set up as a thing (since I don't think we have found any
other
satisfactory solution for compiled Basic).
For each job, the thing should contain:
the complete filename
the dir whence it came from (home
In a message dated 12/01/05 12:45:10 GMT Standard Time,
[EMAIL PROTECTED] writes:
(...)
Only problem here is that if an existing program is called with the home
dir on the stack - the program will not tidy up the stack correctly since
it does not know to remove the extra bytes (I
Wolfgang Lenerz writes:
[Save Name]
Right, I wasn't even aware of that possibility!
I've had a quick look, this seem to be an Sbasic specific feature, it
doesn't exist in Superbasic (nor, I think in TK II, but could somebody
check?)..
Yes, its strictly SMSQE only. Nice little job for some
Wolfgang Lenerz writes:
Your idea sounds excellent. Instead of my bicycle you and Wolfgang
have produced a Mercedes. I am in favour (as long as I dont have to
produce it ;)
Damn, that was my precondition, too! ;-) But it does start to sound
like a worthwhile job.
You will notice
Wolfgang Lenerz writes:
Sorry but A6,A5 does indeed point to the *end* of the command string at
least when the job is invoked by EX it doesn't point to any data area
Yes, the documentation is a bit misleading here.
Apart form that, I think we agree on the Ex mechanism.
(...)
QLib
Marcel Kilgus writes:
However, this is a much more ambitious project than a mere home
directory affair.
Actually I think it doesn't amount to much more work.
Perhaps it is a separate piece of work altogether? Afterall, why not have as
many current directories as you like, from 0..n? This
Wolfgang Lenerz writes:
Other thought: make the job use the thing, which in turn reserves the
memory. On removal the thing will be informed and can deal with that.
Just a thought, I am NO expert on things.
But this is entirely correct - it would just mean that the thing would
have to be
Wolfgang Lenerz writes:
Sorry if I misunderstood.
(or I did!)
It is easier to misunderstand that otherwise. Weve all been doing a lot of
that during this and other discussions. Very frustrating, but it cant be
helped. As long as we get some results AND stay positive very little else
matters
Can we more or less agree on the following:
---
It will be set up as a thing (since I don't think we have found any other
satisfactory solution for compiled Basic).
For each job, the thing should contain:
the complete filename
the dir whence it came from (home dir)
the
On 13 Jan 2005 at 15:52, [EMAIL PROTECTED] wrote:
It sounds as if you are moving (or hoping to move) towards the end of
discussion and on to some programming.
May I wish you all the best for this project.
Thanks -I'll need it.
Wolfgang
On 13 Jan 2005 at 11:59, P Witte wrote:
(...)
I'm not promising anything quick, though.
(Wasnt that what I said two years ago? ;)
I *won't* take that long, though!
(...)
It will be set up as a thing (since I don't think we have found any
other satisfactory solution for compiled
On 13 Jan 2005 at 12:03, P Witte wrote:
(...)
This means that the thing will, indeed, have to have some kind of
default facility, as envisaged earlier.
No, no:
ERT HOT_RES('x', 'win1_psion_XChange', 'X')
The file name is there! Thats the one to store somewhere and propagate to
On 13 Jan 2005 at 12:01, P Witte wrote:
Could you agree to it?
The only power a volunteer has in cases such as these is to give or to
withhold his work, so of course I agree ;)
No, if you have a better idea, I'm always listening.
But do you agree that the concept of stacking information
On 13 Jan 2005 at 11:56, P Witte wrote:
(...)
(...)
No, extending the CDB was a hack, and not a pretty one either, but quite
servicable. My proposal is an extension of an existing facility, namely
stacking an additional parameter above the command line, where only
cognizant programs will
On 13 Jan 2005 at 12:04, P Witte wrote:
Is there any reason why the job cant be born as a confirmed Thing user, ie
it doesnt have to take any specific action to use the Thing when it starts
up. Let the setup routine (currently EX) sort it all out before handing over
to the job?
No reason at
In message [EMAIL PROTECTED], Wolfgang Lenerz
[EMAIL PROTECTED] writes
clip
Can we more or less agree on the following:
---
It will be set up as a thing (since I don't think we have found any other
satisfactory solution for compiled Basic).
For each job, the thing should contain:
the
they start up the program.
All problems to my miond are solved then.
- Original Message -
From: Wolfgang Lenerz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 13, 2005 7:14 AM
Subject: Re: [ql-users] I'm home, dear.
On 12 Jan 2005 at 23:46, Marcel Kilgus wrote:
Your
On Wed, 12 Jan 2005 07:03:39 +0100, Wolfgang Lenerz
[EMAIL PROTECTED] wrote:
On 11 Jan 2005 at 22:19, Rich Mellor wrote:
(...)
1) Older programs which would expect (a6,a5) to point to the command
string at the top of the data area. If we were to adopt this scheme,
then
a lot of existing
Wolfgang Lenerz wrote:
How do you find this string? Have you tried finding the command
string from a QLibbed prog other than with the QLib internal CMD$
command? The problem is that once you get to the stage where your
keyword will be invoked, A5 will point to who knows what (in fact,
the
Dilwyn Jones wrote:
I look forward to it, and I don't really care how it's written as
long as my little new programs can do something like:
Careful, Dilwyn - that's the sort of attitude that made Windows what
it is today!
One of the advantages of SMS* being under the control of one person
was
Wolfgang Lenerz writes:
1) Older programs which would expect (a6,a5) to point to the command
string at the top of the data area. If we were to adopt this scheme,
then
a lot of existing programs would immediately not be able to get at any
parameters passed to them. We do not have the
Wolfgang Lenerz writes:
Whatever the low-down implementation, ideally the workings of the HD/CD
should be as consistent as possible accross m/c programs, interpreted
Sbasic
or compiled Sbasic.
Anything that wouldn't be available to compiled Sbasic wouldn't make
much sense!
True ;) I
Wolfgang Lenerz writes:
Or a completely different proposal:
(putting the home dir after the command string)
As long as you dont mean that this has to be done on the EX command line, I
agree with the above description.
Having said that, it /would/ perhpas be nice to add something like this
Wolfgang Lenerz writes:
Wolfgang Lenerz wrote:
Default could also be DATAD$ or whatever.
that would defeat the wholme exercice.
Why that? It's just a fallback solution if otherwise no other
directory can be provided (none set).
Well, it already exists...
Wouldn't it be better if
I look forward to it, and I don't really care how it's written as
long as my little new programs can do something like:
Careful, Dilwyn - that's the sort of attitude that made Windows what
it is today!
Aarrgghhh. Forget I ever said that
Dilwyn Jones
On 12 Jan 2005 at 13:20, P Witte wrote:
(...)
That is why Im suggesting to use the Save Name as
the Homedir in the interpreter. The difficult bits have already been
implemented, only we dont currently have access to the Save Name except
indirectly through (Q)SAVEing and (Q)LOADing the current
On 12 Jan 2005 at 13:25, P Witte wrote:
(...)
As long as you dont mean that this has to be done on the EX command line, I
agree with the above description.
No, that wouldn't make much sense.
Having said that, it /would/ perhpas be nice to add something like this as
an option to
overwrite
On 12 Jan 2005 at 13:26, P Witte wrote:
(...)
Doesnt this defeat the object? We already can do this with a simple Config
block. The point of a Homedir is that you can always know the name and path
of the current job from wherever it is executed.
I think we were talking about jobs executed
P Witte wrote:
Theres no stack hack involved; simply a new convention.
Well, the more I think about it, the less I like it. A thing could be
a much cleaner, better maintainable and extendable solution.
I suspect you may have the path depth/filename length issue at the
back of your mind.
No,
Dilwyn Jones wrote:
Aarrgghhh. Forget I ever said that
Said what? :-)
John
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
On 12 Jan 2005 at 14:31, John Hall wrote:
(...)
True. (And, of course, your Thing could potentially be extended to
store any number of per-job data items.)
Yes, Marcel has seen the potential of it immediately.
It's just that, for some reason, what we're trying to achieve doesn't
seem to
In a message dated 11/01/05 16:54:46 GMT Standard Time,
[EMAIL PROTECTED] writes:
On 11 Jan 2005 at 17:44, Marcel Kilgus wrote:
(...)
Without having any personal view on the issue yet, isn't it basically
the same issue as with CMD$? Does CMD$ work in compiled basic?
Yes and no. (That's a
Wolfgang Lenerz writes:
That is why Im suggesting to use the Save Name as
the Homedir in the interpreter. The difficult bits have already been
implemented, only we dont currently have access to the Save Name except
indirectly through (Q)SAVEing and (Q)LOADing the current program.
Oops,
Wolfgang Lenerz writes:
Doesnt this defeat the object? We already can do this with a simple
Config block. The point of a Homedir is that you can always know
the name and path of the current job from wherever it is executed.
I think we were talking about jobs executed from things which
Marcel Kilgus writes:
No, I have for example a current directory in mind, which should be
changeable (on request of the application) after the application
started to run. I also have a device in mind that automatically
accesses the current directory. None of which is cleanly doable with
the
Wolfgang Lenerz writes:
Having said that, it /would/ perhpas be nice to add something like this
as an option to
overwrite the default home directory, although is does complicate an
already overloaded parameter list:
EX filename ; command string ! different homedir
Before
P Witte wrote:
I never knew that I wanted a current directroy,
I didn't know that you want one either, but I know that *I* would like
one ;-)
However, this is a much more ambitious project than a mere home
directory affair.
Actually I think it doesn't amount to much more work.
You have to
On 12 Jan 2005 at 23:46, Marcel Kilgus wrote:
Your idea sounds excellent. Instead of my bicycle you and Wolfgang have
produced a Mercedes. I am in favour (as long as I dont have to produce it ;)
Damn, that was my precondition, too! ;-) But it does start to sound
like a worthwhile job.
On 12 Jan 2005 at 21:22, P Witte wrote:
LOAD win1_prg_fred_bas: REMark Load a program
SAVE: REMark Save the same program
win1_prg_fred_bas is the Save Name as far as Im concerned as I dont know
what else to call it. The Save Path (or directory) here is win1_prg.
Right, I wasn't
Wolfgang Lenerz wrote:
There has been some talk on this list about some form of
currrent directory or home directory for programs that
are being executed.
As far as I understand it, the purpose of such a directory is to
give the program the name of the directory from which the file was
On 11 Jan 2005 at 10:53, John Hall wrote:
(...)
Conceptually, I'm not keen on this centralised approach - it seems
rather too Windows-like!
Since it's an item of job-specific data, couldn't it be associated
with a job-specific data area or structure (e.g. put on the stack
prior to
Wolfgang Lenerz wrote:
Apart from anything else, this would maintain the self-cleaning
property of the operating system...
True.
However, how do you get at that from basic, espacially compiled basic?
Without having any personal view on the issue yet, isn't it basically
the same issue as with
On 11 Jan 2005 at 17:44, Marcel Kilgus wrote:
(...)
Without having any personal view on the issue yet, isn't it basically
the same issue as with CMD$? Does CMD$ work in compiled basic?
Yes and no. (That's a true lawyes's anwer for you)
No problem for Sbasic itself, of course.
However, while
Wolfgang Lenerz wrote:
Yes and no. (That's a true lawyes's anwer for you)
No problem for Sbasic itself, of course.
However, while CMD$ works in Qlib, this is only because Qlib has it's own
CMD$ command. There is no way to have a similar home$ command in Qlib.
Ah, very well. Anyway, if one now
Wolfgang Lenerz wrote:
--- Finally, progs executed from memory (executable things) would
probably not have a home directory, unless a facility is set up
whereby a default home dir is set up for programs with a certain
name.
Default could also be DATAD$ or whatever.
- Via QPAC2. This would
On 11 Jan 2005 at 18:19, Marcel Kilgus wrote:
Default could also be DATAD$ or whatever.
that would defeat the wholme exercice. Why not have the user set the default?
(...)
Hm, the meaning of a Trap #3 depends on a specific device you've
opened, not a good choice IMO. But if you do use a
Or a completely different proposal:
Lets take the standard job as the starting point. Dealing with QLiberated or
Turboed jobs need some special treatment.
When a job is first started it has a code area and a data area. If there are
open channels or a command line the Basic keywords EX (and
On Tue, 11 Jan 2005 22:00:37 -, P Witte [EMAIL PROTECTED]
wrote:
Or a completely different proposal:
Lets take the standard job as the starting point. Dealing with
QLiberated or
Turboed jobs need some special treatment.
When a job is first started it has a code area and a data area. If
Rich Mellor wrote:
I prefer this type of approach as it would ensure that the home
directory (or whatever) would be removed together with the job.
If the job uses the thing, the thing is informed when the job dies.
Even if not, one could allocate the necessary memory on behalf of the
job and
Wolfgang Lenerz wrote:
Default could also be DATAD$ or whatever.
that would defeat the wholme exercice.
Why that? It's just a fallback solution if otherwise no other
directory can be provided (none set).
Hm, the meaning of a Trap #3 depends on a specific device you've
opened, not a good
2) The bigger problem and one which is harder to address...
How do you decide what is the home directory of a file called
win1_basic_exts_turbo_config_exe
I guess the code which sets up the job would have to look at each of
the levels before the underscore to see if they were set up as a
Rich Mellor writes:
It would not be difficult to stack the home directory on top
of that again thus:
Home directory
Command string
Channel ID
Channel ID
number of channel IDs
Data area
At present (a6,a5) point to the top of the data area. This could now be
the
Marcel Kilgus writes:
If the job uses the thing, the thing is informed when the job dies.
Even if not, one could allocate the necessary memory on behalf of the
job and therefore it would get freed along with the job.
So far I think I'd prefer that over any stack hack, but I haven't
On 11 Jan 2005 at 22:19, Rich Mellor wrote:
(...)
1) Older programs which would expect (a6,a5) to point to the command
string at the top of the data area. If we were to adopt this scheme, then
a lot of existing programs would immediately not be able to get at any
parameters passed to
78 matches
Mail list logo
