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. Now is the time to chop and
change and take a few wrong turns, as we dont have the code base to drag
around.
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 affect this project?
And how can we be expected to come up with solutions before we even agree on
what it is were trying to do? You may know exactly what it is you want to
do. Marcel's ideas appear to be somewhat different (as this discussion
revealed) I have an inkling of what I want but I dont know if anyone else
wants it.
Are we even really talking about the same project? That the implementation
ideas are different is obvious. Does the implementation affect the
functionality or does the functionality dictate the implementation? Or do
we have the "Supermarket syndrome" ie a number of different choices that
produce identical results. Which to chose? The cheapest, the strongest or
the sexiest?
Practical people dont like being held up by planning and philosophical
considerations. And yes, there is a risk of it all running into the sand if
theres too much talk and too little action. But I believe the optimal
solution will only be found if we take the trouble to search for it. It
doesnt matter if we have to wait another year, its just a fraction of what
weve waited so far.
The CD issue cropped up as we were talking of HD. But how about other things
while we are toying with the idea of doing something about jobs? It would,
for example, be great for a job to have some kind of Quit code: When a job
is removed it can either be called with a "soft" request (which the job
could reject or delay, eg as a result of user input "Save file before
quitting Y/N?") or a "hard" request, which would allow it a few seconds to
prepare itself for death after which it would be snuffed out without further
ado, ready or not.
Maybe we need an overall development plan before we continue poking around?
> More seriously, I don't pretend to know it all and if you have a better
> idea, I (generally) don't suffer from the NIH syndrome.
What is the NIH syndrome?
> > Actually I can think of one sure method to find a Home Directory [HD]
> > string. Taking the structure to look like this:
<>
I think I can answer all your questions, but I doubt it would be very useful
at
this stage.
<>
> 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 be set when the
> memory is released.
This is not documented anywhere to my knowledge. Details would be welcome.
The key file Common Heap header (smsq/keys/chp) mentions a chp_orel "Offset
of pointer to RELease code from chp_drlk" Is that it?
<>
> Incidentally, I don't know the DUP & DDOWN commands. Whilst I have no
> problem understanding the DUP command (after all there is only one
> parent dir), am correct in assuming the DDOWN command has one
> obligatory parameter, the name of the dir?
No, the name of the next sub dir:
DATA_USE 'win1_prg'
DDOWN 'ext'
PRINT DATAD$
would print win1_prg_ext_ on your screen.
Per
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
