I support Wolfgang in making very clear what is to be achieved before
designing the specification.
There seem to be three problems to my mind.
1. The problem of a program finding its own information such as
configuration and help files.
2. The problem of a program knowing where to write the data.
3. The problem of deep directory trees being limited by the QL file name
length.
Any solution to my mind must be
1. Be compatable with existing QLs
2. Be the same for all devices.
3. As far as possible be as similar as possible to existing QL usage.
Problems 1 & 2 would seem to be solved by Configuration blocks
I suggested as an alternative passing parameters -p & -d for program
data directories.
George Gwilt already uses the second solution in some of his programs.
Hence the suggestion to adapt present programs where possile ot include
both.
The other standard method is paths for which there is already an
extension which I ought to investigate and probably use.
For directory changing prog_use, data_use, dup & ddown are the standard QL
comands.
They are to mind adequate if QL specific and hence I see no reason to change
them.
DATAD$ is equivalent home directory anyway.
So the real problem is 3 deep directory structures.
As I understand it the present directory system hides files with names
containing the file name of the directory when using the command dir or
wstat. mkdir makes a directory file.
So if the system is to be compatable it has to respond the same on 'old'
QLs.
Hence the suggestion of adapting the present system.
Perhaps the present directory name could be replaced by a two bytes so that
win1_sys_bin_net_peek becomes win1_ac_bc_net_peek. Directory file win1_sys_
appears as win1_ab_ on an old QL and directory file win1_sys_bin_ appears as
win1_ab_bc_ Or less transparently but enabling deeper directories win1_bc_
represents win1_sys_bin_.
By this means near backward compatability could be maintained.
Does this cover all the problems and can it be improved on?
----- Original Message -----
From: "P Witte" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 15, 2005 1:50 PM
Subject: Re: [ql-users] I'm home, dear.
> 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
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
