On 12 Jan 2005 at 23:46, Marcel Kilgus wrote:

> 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 alter the device driver to cater for it too.
> 
> Hm, which? I don't propose that every device driver should know about
> the current directory but that there could be a new device like
> "home_" or something that did specifically include the current-path,
> exe-path or whatever.

Yes, there could be, but that exceeds the simple home/current dir thing. The 
advantage 
is that we can build this in a modular way. First I make the home dir thing & 
alter EX etc 
to take advantage of it. Then YOU alter Qpac2 (and Cueshell?) to take advantage 
of it 
(Ha!).
Things like FileInfo II should probably also be altered. I don't know right now 
whether 
the code is available?

> Hmm, why? Currently I don't see anything in my proposal that is
> strictly SMSQ/E specific.
> Thought I am beginning to hate QDOS compatibility, just out of spite.

Making this into a thing it can be incorporated into SMSQ/e, but I can also 
make it into 
a standalone file to be Lrespr'd Into Qdos. A modified Qpac II, for example, 
could take 
advantage of it.


 
> > However, my thinking goes: If all the Homedir is wanted for is to find the
> > location of some config file (as will often be the case) then the space
> > taken up by the Homedir string could simply be re-used as a Current dir.

Yes, but as usual, this has expanded to become more that a simple home dir...

> (...)
> 
> No offence meant, just wanted to give an example. The question is
> always "how do I know I'm running on a system that provides the
> service I want".

>From basic: try to use the keyword. Dilwyn (I think) had the right idea: check 
>whether 
the keyword is available, if yes use, else you know that the service isn't 
there.
>From MC: try to use the thing
>From C: same 


> Example: allocate the memory before the execution of the job with the
> job as the owner. It will get freed automatically on removal of the
> job. And how do you know that the memory is not valid anymore? Easy,
> the job-ID won't be valid anymore.

Correct. Except that I initially planned to have some kind of linked list. If 
the memory 
just goes away because the job is removed the list will be broken.
There are several solutions I not sure yet which one is best.

> 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 used 
continuously by that job.

Wolfgang

_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to