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 affect this project?
Implementing it as a thing means I can makje a standalone version for Qdos. The filenames etc don't impact this IF it is done is such a way that the filename don't have a limited length. I'm even doubtfull about "reasonable" lengths. If the memory isn't of a fixed size (and in the Thing scheme there is no reason that it should be) then the filename lengths becomes irrelevant. The only time it does become relevant is when it is supposed to be passed to the job. > 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. Ah, but then I have the "privilege" of coding it. he, he... > 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? I'd go for the sexiest any time, but that may be due to the fact that I live in France. More seriously, we're all trying to go in the same direction, even if we implement it differently (there is no right/wrong solution there, I think). 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. Something that starts of as the home directory, but may be manipulated by the job itself. > 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. Yes and no. We can always talk more, but at some stage we're (I'm) going to start actually doing something... Moreover, perhaps we shoukd differentiate between the desgin concept (what we want/need) and the implementation. > 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. OK why not. But, to my mind, this is a totally separate issue. There was also the issue Jochen had raised on this list some time (years?) ago: SOme form;of interrupting a job that is doing some long processing. But, as I said, this is, at least to my mind, something different. Let's keep with the policy of the little steps.... > Maybe we need an overall development plan before we continue poking around? Again, yes and no. Yes, an overall development plan would be great. No, it isn't such a good idea because we here on this list will NEVER agree on something like that. Also, a development plan is all very nice, but who will do the development? The state of SMSQE development so far has always been that those who want to participate - do. If we have some kind of development plan then we need some coordinator who "forces" people to do what is necessary... > > 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? Not Invented Here. :-)) (...) >> 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: (that's what I meant) > DATA_USE 'win1_prg' > DDOWN 'ext' > PRINT DATAD$ > > would print win1_prg_ext_ on your screen. > Yes, thanks Wolfgang ---------------------------------------- www.scp-paulet-lenerz.com _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
