|
Sure, no problem. I can test OSX and Windows... somebody else will have to test in Linux. Couple of questions about this: Which of these should it apply to? - Interactive execution (yes, obviously) - Threads initiated in a specific file -- that is, if you do loadPath and the file starts a routine, what should the routine get back if it asks for thisProcess.nowExecutingPath? I'm thinking it should return nil, mainly because doing anything else would be extremely difficult and probably bad for performance. - Asynchronous callback functions... hmm... slippery slope... the more I think about it, the more I think it's a lot of risk fur not much gain. Probably the best policy, then, is set it for interactive and executeFile execution and let it be nil everywhere else. Hmm... actually there is one thing I don't like about that. interpretPrintCmdLine { var res, func, code = cmdLine, saveExecutingPath = thisProcess.nowExecutingPath; "\n".post; preProcessor !? { cmdLine = preProcessor.value(cmdLine, this) }; func = this.compile(cmdLine); thisProcess.nowExecutingPath = Document.current.path; protect { res = func.value; } { thisProcess.nowExecutingPath = saveExecutingPath; }; codeDump.value(code, res, func, this); res.postln; } Since you have to protect every interactive block, error output is really unhelpful. Is it worth it? Or should we not protect{} it and document that asynchronous code should not count on getting the right answer from nowExecutingPath? Not sure which is the lesser evil... strip error output of its usefulness, or leave garbage in the variable when there's an error. hjh On Dec 20, 2007, at 3:22 PM, Scott Wilson wrote: Would this be worth revisiting now that Document has been refactored? : H. James Harkins : jamshark70@xxxxxxxxxxxxxxxxx : http://www.dewdrop-world.net .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman |