I'm sure I remember someone making this work but can't spot any info right now.
One should be able to make it so that a .st file could be made executable, start it with something akin to #! squeak my.image and continue with | t f | t:= [f := 4784969 fastDoublingFib asString] timeToRun. FileStream stdout nextPutAll: 'fib(4784969) = '; nextPutAll: f; cr; nextPutAll: 'time = '; nextPutAll: t asString; nextPutAll: ' mS'; cr To effectively filein the remainder of the file contents. Shouldn't we? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: IAM: Increase Amperage Above Maximum |
On Sun, May 5, 2019 at 6:11 AM tim Rowledge <[hidden email]> wrote: I'm sure I remember someone making this work but can't spot any info right now. I think that could work if `squeak` is in your path. Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? Fabio
|
> On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: > > Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? That's what I thought but it doesn't appear to actually do that. I've been looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand but so far nothing is doing quite what I anticipated. Most annoyingly I can't get any sort of debugging output using the usual -x flag. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: PDH: Page to Disk for the Hell of it |
On Sun, May 05, 2019 at 12:48:13PM -0700, tim Rowledge wrote:
> > > > On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: > > > > Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? > > That's what I thought but it doesn't appear to actually do that. I've been looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand but so far nothing is doing quite what I anticipated. > Most annoyingly I can't get any sort of debugging output using the usual -x flag. > One part of the current problem is that we have somehow broken the script loader: URI class>>#basicNew has been deprecated. This class is deprecated. USe one ofthe Url classes instead Turning off the "Show deprecation warnings" preference works around that issue. Dave |
> On 2019-05-05, at 1:51 PM, David T. Lewis <[hidden email]> wrote: > > On Sun, May 05, 2019 at 12:48:13PM -0700, tim Rowledge wrote: >> >> >>> On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: >>> >>> Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? >> >> That's what I thought but it doesn't appear to actually do that. I've been looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand but so far nothing is doing quite what I anticipated. >> Most annoyingly I can't get any sort of debugging output using the usual -x flag. >> > > One part of the current problem is that we have somehow broken the script loader: Wait, you've actually got it running squeak and trying to load something? How? It doesn't get as far as Squeak on my Pi. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Did you hear about Christopher Robin Hood? He stole from the rich to give to the Pooh |
On Sun, May 05, 2019 at 02:06:14PM -0700, tim Rowledge wrote:
> > > > On 2019-05-05, at 1:51 PM, David T. Lewis <[hidden email]> wrote: > > > > On Sun, May 05, 2019 at 12:48:13PM -0700, tim Rowledge wrote: > >> > >> > >>> On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: > >>> > >>> Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? > >> > >> That's what I thought but it doesn't appear to actually do that. I've been looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand but so far nothing is doing quite what I anticipated. > >> Most annoyingly I can't get any sort of debugging output using the usual -x flag. > >> > > > > One part of the current problem is that we have somehow broken the script loader: And the next issue after that is the code loader, which probably used to be smart enough to skip over the shebang line in the hello.sq script, but apparently no longer does so. > > Wait, you've actually got it running squeak and trying to load something? How? It doesn't get as far as Squeak on my Pi. > I'm actually having a hard time dredging this out of deep backing store from my grey matter, but a couple of things do still work (just in Squeak, not in the grey matter). Following the tip from Chris Cunnington, I read the squeak man page. That covers the idea of the self-executing script, which should work fine once we fix the deprecation issue and re-teach the script loader to skip over the first line of a script file that begins with '#!'. The other thing that still works is taking an image file and prepending it with 512 characters of gunk before the actual image, in which the first part of those 512 characters is a shebang line. All of the VMs will try skipping over the first 512 bytes of an image file if the first few bytes do not look like a valid image format identifier, which allows you to treat the image file as both a unix script and a Squeak image file at the same time. Both of these start the image, but neither of them can load a script due to the aforementioned issues. Dave |
> On 2019-05-05, at 2:32 PM, David T. Lewis <[hidden email]> wrote: >> >> Wait, you've actually got it running squeak and trying to load something? How? It doesn't get as far as Squeak on my Pi. >> > > I'm actually having a hard time dredging this out of deep backing store > from my grey matter, but a couple of things do still work (just in Squeak, > not in the grey matter). > > Following the tip from Chris Cunnington, I read the squeak man page. That > covers the idea of the self-executing script, which should work fine once > we fix the deprecation issue and re-teach the script loader to skip over > the first line of a script file that begins with '#!'. Hmm, well we have some interesting problems here. Like *which* man page does one pay attention to, and does it even faintly reflect reality? For example, on a Pi running the Debian derived Raspbian OS, `man squeak` produces something quite different to the version on squeakvm,org, but the version on github/opensmalltalk appears at first glance to be the same and 9 years untouched. The -help info from a recent Cog vm is quite different in its list of options. I also stumbled over some very out of date info on the swiki about running squeak on Debian. On my Pi, attempting to run a file like this - -------------------- #!/usr/bin/squeak -- | t f | t:= [f := 4784969 fastDoublingFib asString] timeToRun. FileStream stdout nextPutAll: 'fib(4784969) = '; nextPutAll: f; cr; nextPutAll: 'time = '; nextPutAll: t asString; nextPutAll: ' mS'; cr -------------------- Results in ++++++++++++++++++++ ./ReallyFastFib.st FileStrenextPutAll: 'fib(4784gFib asString] timeToRun. Usage: /usr/lib/squeak/5.0-201610101924/squeak [<option>...] [<imageName> [<argument>...]] /usr/lib/squeak/5.0-201610101924/squeak [<option>...] -- [<argument>...] ALSA <option>s: -nomixer disable mixer (volume) ...{snip lots of hrelp option info} +++++++++++++++++++++ The strangely garbled line of Smalltalk is particularly amusing. I have tried various combinations, including naming the image file explicitly, passing things off to another shell script that names the image file and so on. No luck so far. Actually manually running `squeak my.image ReallyFastFib.st` works as one would currently expect, getting to where the code loader barfs over the #!. Evidently we have some serious drift that needs sorting out, as well as actual functional problems. And I suppose one should wave a flag and point out that the way squeak is 'supported' in Debian repositories is horrible and years outdated and perhaps worse, appears to carefully mangle the vm code. It's been that way for ages. If anyone has contacts in the appropriate places perhaps we could get it sorted out? > > The other thing that still works is taking an image file and prepending > it with 512 characters of gunk before the actual image, in which the first > part of those 512 characters is a shebang line. I remember that; I might have even used in the deep past. I'm amazed it would still work. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Nostalgia: The good old days multiplied by a bad memory... |
Back in the day Avi would attach a file.st script to a loading image. That’s where the Smalltalk would go.
And if you need more arguments, the man page makes it clear you can add them after the file name. (SmalltalkImage getSystemAttribute: is very useful). You’d use a Bash script to start it. Like this: #!/bin/sh /usr/local/lib/squeak/3.10-4/squeak -vm-display-null -vm-sound-null $image file.st& So, you’d use two files: one to start an image; and, one with your Smalltalk code. I’d be very surprised if this didn’t still work. Lukas used to load blank images into his Jenkins/Hudson server the same way. He’d have a different file.st for different applications loading into a generic image. Unless you have some actual need to put everything in one file, then I’d suggest you use this tried and true way. You can choose where you want the output to end up. You’re trying to do something I’ve never seen work. Chris Steel Panther - The Burden Of Being Wonderful
|
> On 2019-05-05, at 5:40 PM, Chris Cunnington <[hidden email]> wrote: > {snip} > You’d use a Bash script to start it. Like this: > > #!/bin/sh > /usr/local/lib/squeak/3.10-4/squeak -vm-display-null -vm-sound-null $image file.st& {snip} Yeah, that stuff is working ok (modulo the curious problem I recently reported with the stdin/out/err filehandles not getting initialised) but it would be nice if the supposed to work trick with the #! stuff actually worked. I'm pretty certain it *used* to. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? |
In reply to this post by David T. Lewis
On Sun, May 05, 2019 at 05:32:19PM -0400, David T. Lewis wrote:
> On Sun, May 05, 2019 at 02:06:14PM -0700, tim Rowledge wrote: > > > > > > > On 2019-05-05, at 1:51 PM, David T. Lewis <[hidden email]> wrote: > > > > > > On Sun, May 05, 2019 at 12:48:13PM -0700, tim Rowledge wrote: > > >> > > >> > > >>> On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: > > >>> > > >>> Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? > > >> > > >> That's what I thought but it doesn't appear to actually do that. I've been looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand but so far nothing is doing quite what I anticipated. > > >> Most annoyingly I can't get any sort of debugging output using the usual -x flag. > > >> > > > > > > One part of the current problem is that we have somehow broken the script loader: > > And the next issue after that is the code loader, which probably used to be smart > enough to skip over the shebang line in the hello.sq script, but apparently no > longer does so. Fixed in trunk now (System-dtl.1062). Turn off deprecation warnings to work around the other issue, I don't know the story on that one. But otherwise things should be back to normal. Dave |
On Sun, May 05, 2019 at 11:03:34PM -0400, David T. Lewis wrote:
> On Sun, May 05, 2019 at 05:32:19PM -0400, David T. Lewis wrote: > > On Sun, May 05, 2019 at 02:06:14PM -0700, tim Rowledge wrote: > > > > > > > > > > On 2019-05-05, at 1:51 PM, David T. Lewis <[hidden email]> wrote: > > > > > > > > On Sun, May 05, 2019 at 12:48:13PM -0700, tim Rowledge wrote: > > > >> > > > >> > > > >>> On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: > > > >>> > > > >>> Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? > > > >> > > > >> That's what I thought but it doesn't appear to actually do that. I've been looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand but so far nothing is doing quite what I anticipated. > > > >> Most annoyingly I can't get any sort of debugging output using the usual -x flag. > > > >> > > > > > > > > One part of the current problem is that we have somehow broken the script loader: > > > > And the next issue after that is the code loader, which probably used to be smart > > enough to skip over the shebang line in the hello.sq script, but apparently no > > longer does so. > > Fixed in trunk now (System-dtl.1062). > > Turn off deprecation warnings to work around the other issue, I don't know > the story on that one. But otherwise things should be back to normal. > The deprecation warning is raised by URI class>>basicNew, called by String>>asURI. The deprecation was added recently in Network-tpr.231, but I don't know what the replacement class should be. Presumably String>>asURI needs to be updated, and that should fix the remaining problem with shebang script loading. Dave |
On Mon, May 06, 2019 at 08:14:44AM -0400, David T. Lewis wrote:
> On Sun, May 05, 2019 at 11:03:34PM -0400, David T. Lewis wrote: > > On Sun, May 05, 2019 at 05:32:19PM -0400, David T. Lewis wrote: > > > On Sun, May 05, 2019 at 02:06:14PM -0700, tim Rowledge wrote: > > > > > > > > > > > > > On 2019-05-05, at 1:51 PM, David T. Lewis <[hidden email]> wrote: > > > > > > > > > > On Sun, May 05, 2019 at 12:48:13PM -0700, tim Rowledge wrote: > > > > >> > > > > >> > > > > >>> On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: > > > > >>> > > > > >>> Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? > > > > >> > > > > >> That's what I thought but it doesn't appear to actually do that. I've been looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand but so far nothing is doing quite what I anticipated. > > > > >> Most annoyingly I can't get any sort of debugging output using the usual -x flag. > > > > >> > > > > > > > > > > One part of the current problem is that we have somehow broken the script loader: > > > > > > And the next issue after that is the code loader, which probably used to be smart > > > enough to skip over the shebang line in the hello.sq script, but apparently no > > > longer does so. > > > > Fixed in trunk now (System-dtl.1062). > > > > Turn off deprecation warnings to work around the other issue, I don't know > > the story on that one. But otherwise things should be back to normal. > > > > The deprecation warning is raised by URI class>>basicNew, called by String>>asURI. > The deprecation was added recently in Network-tpr.231, but I don't know what > the replacement class should be. > > Presumably String>>asURI needs to be updated, and that should fix the remaining > problem with shebang script loading. > Changing to use String>>asUrl instead of String>>asURI seems like the right thing to do, but additional changes will be needed in ProjectLauncher>>startUpAfterLogin to make it work. Dave |
In reply to this post by David T. Lewis
On 06/05/19 3:02 AM, David T. Lewis wrote:
> The other thing that still works is taking an image file and prepending > it with 512 characters of gunk before the actual image, in which the first > part of those 512 characters is a shebang line. All of the VMs will try > skipping over the first 512 bytes of an image file if the first few bytes > do not look like a valid image format identifier, which allows you to > treat the image file as both a unix script and a Squeak image file at > the same time. I suspect this goes back to a time when early PCs and Macs had a 512-byte bootsector in the beginning of their disks. So one could pack bootsector+image+st into a raw disk or transfer it across network without worrying about filesystems or layouts. It would still be useful for embedded boards. Regards .. Subbu |
In reply to this post by David T. Lewis
Some interesting success on the Pi now; with latest updates for Dave's 'ignore the hashbang' and turning off the deprecation warning.
I'm not sure why my earlier attempts failed since so far as I can see they should have worked. Maybe I got some strange char in the file that wasn't visible? Anyway there are several functional scenarios +++++++++++++ #!/usr/bin/squeak -- FileStream stdout nextPutAll: 'hello world'; cr. Smalltalk snapshot: false andQuit: true ++++++++++ will run and expects to find the 'squeak.image' in the CWD or as specified by the SQUEAK_IMAGE environment variable. The -- is required in order to let the vm know you are not trying to run an image named as the script file. +++++++++++++ #!/usr/bin/squeak /home/pi/Squeak/my.image FileStream stdout nextPutAll: 'hello world'; cr. Smalltalk snapshot: false andQuit: true ++++++++++ also works as long as you don't also have the -- (because that makes the vm try to find an image named "my.image --", which seems like a parsing rule that might be improvable) The remaining problem is that any attempt to include any option (say #!/usr/bin/squeak -fullscreen --) confuses things as it leads to the vm being unable to recognise any of the options. The weird bit is that the final command is - LD_LIBRARY_PATH=/usr/lib/squeak/5.0-201610101924:/lib/arm-linux-gnueabihf:/lib:/usr/lib/arm-linux-gnueabihf:/usr/lib: /usr/lib/squeak/5.0-201610101924/squeak -fullscreen /home/pi/Squeak/squeak.image ./HelloWorld.st ... and the errors starts off with - unknown option: -fullscreen /home/pi/Squeak/squeak.image Usage: /usr/lib/squeak/5.0-201610101924/squeak [<option>...] [<imageName> [<argument>...]] /usr/lib/squeak/5.0-201610101924/squeak [<option>...] -- [<argument>...] ... which looks pretty odd since that describes what it got. Very odd. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Manual Writer's Creed: Garbage in, gospel out. |
On Mon, May 06, 2019 at 03:53:30PM -0700, tim Rowledge wrote:
> > The remaining problem is that any attempt to include any option (say #!/usr/bin/squeak -fullscreen --) confuses things as it leads to the vm being unable to recognise any of the options. This is a tricky one, and unfortunately it is not something that you can easily work around. What is happening here is is that '-fullscreen --' is being passed to the VM as a single argument with an embedded space. Different unix systems may implement this differently, and I found a good summary at https://www.in-ulm.de/~mascheck/various/shebang/ (scroll down and look for the section on "showargs"). The most common implementation is for the unix exec machinery to take the first part of the shebang line (/usr/bin/squeak) and let it be argv[0], then any remaining stuff on the line is argv[1], and the name of the invoking script (./hello.sq) is passed as argv[2]. This is just enough cleverness to allow the script (/usr/bin/squeak or /bin/sh or whatever) to receive a single argument (such as --) and figure out what to do from there. Anything more clever than this would require an additional level of option parsing that would normally be performed by a shell (such as bash). The exec mechanism makes no attempt to do that. > The weird bit is that the final command is - > LD_LIBRARY_PATH=/usr/lib/squeak/5.0-201610101924:/lib/arm-linux-gnueabihf:/lib:/usr/lib/arm-linux-gnueabihf:/usr/lib: /usr/lib/squeak/5.0-201610101924/squeak -fullscreen /home/pi/Squeak/squeak.image ./HelloWorld.st It all looks good, but the hidden "gotcha" that bites you here is that '-fullscreen /home/pi/Squeak/squeak.image' is actually a single argument token, even though it looks like it is two separate arguments. Dave |
On 07/05/19 5:11 AM, David T. Lewis wrote:
> The most common implementation is for the unix exec machinery to take the first > part of the shebang line (/usr/bin/squeak) and let it be argv[0], then any > remaining stuff on the line is argv[1], and the name of the invoking script > (./hello.sq) is passed as argv[2]. This is just enough cleverness to allow the > script (/usr/bin/squeak or /bin/sh or whatever) to receive a single argument > (such as --) and figure out what to do from there. Right! The linux code is in [1]. The argv[0]/argv[1] pair was introduced to support path detection when the interpreter location could vary between different systems. #!/usr/bin/env squeak etc.. It is fortuitous that we use it to pass the default image (--). The script handler [1] is one of many image handlers in the kernel. The linux kernel uses a clever indirection to remain small but extensible. Instead of trying to load a executable directly, the kernel chains through a list of handlers (aka binfmt) [2] to find a matching interpreter. The trivial case is native ELF file that the processor can execute directly. In general, each binfmt defines an association between a matching rule and interpreter path :name :type:offset:magic:mask :interpreter :flags where the type/offset/magic/mask fields are parsing rules to detect file format and "interpreter" is the full path to the interpreter. These associations can even be edited at run time [3]. For instance, classic Squeak images can be registered with: $ echo ':squeakv3:M::\x66\x19\x00\x00::/usr/local/bin/squeak:' | sudo tee /proc/sys/fs/binfmt_misc/register $ ./squeak.image hello.st and removed with $ echo -1 | sudo tee /proc/sys/fs/binfmt_misc/squeakv3 This match detection does not extend to argument syntax because kernel modules must not hard code option syntax. It is the interpreter that should parse its args. A second point in this discussion is that most script interpreters use $# character as comment leader in their script, so embedding #! works out fine for them. But Squeak uses $" for its comment leader. If we wish to execute .st file directly, we need to create a binfmt rule that depends on Squeak comment character (say $" $! $"): :squeak:M::\x22\x5c\x22::/usr/local/lib/squeak.image: ----- hello.sq -------- "!" FileSystem stdout ..... ----------------------- [1] https://elixir.bootlin.com/linux/latest/source/fs/binfmt_script.c [1] See binfmt_*.c in https://elixir.bootlin.com/linux/latest/source/fs [2] https://www.kernel.org/doc/Documentation/admin-guide/binfmt-misc.rst Regards .. Subbu |
> On 2019-05-06, at 11:27 PM, K K Subbu <[hidden email]> wrote: > {snip} > :squeak:M::\x22\x5c\x22::/usr/local/lib/squeak.image: > > ----- hello.sq -------- > "!" > FileSystem stdout ..... > ----------------------- That is so. Damn. Clever. Wow. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim 999, the number of the Aussie Beast. |
In reply to this post by David T. Lewis
On Sun, May 05, 2019 at 04:51:08PM -0400, David T. Lewis wrote:
> > On Sun, May 05, 2019 at 12:48:13PM -0700, tim Rowledge wrote: > > > > > On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: > > > > > > Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? > > > > That's what I thought but it doesn't appear to actually do that. I've been > > looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand > > but so far nothing is doing quite what I anticipated. Most annoyingly I > > can't get any sort of debugging output using the usual -x flag. > > > > One part of the current problem is that we have somehow broken the script loader: > > URI class>>#basicNew has been deprecated. This class is deprecated. USe one ofthe Url classes instead > > Turning off the "Show deprecation warnings" preference works around that issue. > This is fixed in trunk as of System-dtl.1064, so it should be safe to turn your deprecation warnings back on again now. Dave |
Pretty cool. If Tim gets this working to his satisfaction I hope he makes a post with an example.
Chris > On May 13, 2019, at 9:55 PM, David T. Lewis <[hidden email]> wrote: > > On Sun, May 05, 2019 at 04:51:08PM -0400, David T. Lewis wrote: >> >> On Sun, May 05, 2019 at 12:48:13PM -0700, tim Rowledge wrote: >>> >>>> On 2019-05-05, at 7:38 AM, Fabio Niephaus <[hidden email]> wrote: >>>> >>>> Otherwise, `#!/path/to/vm/squeak /path/to/my.image` should work, right? >>> >>> That's what I thought but it doesn't appear to actually do that. I've been >>> looking at https://en.wikipedia.org/wiki/Shebang_(Unix) to try to understand >>> but so far nothing is doing quite what I anticipated. Most annoyingly I >>> can't get any sort of debugging output using the usual -x flag. >>> >> >> One part of the current problem is that we have somehow broken the script loader: >> >> URI class>>#basicNew has been deprecated. This class is deprecated. USe one ofthe Url classes instead >> >> Turning off the "Show deprecation warnings" preference works around that issue. >> > > This is fixed in trunk as of System-dtl.1064, so it should be safe > to turn your deprecation warnings back on again now. > > Dave > > |
> On 2019-05-13, at 7:11 PM, Chris Cunnington <[hidden email]> wrote: > > Pretty cool. If Tim gets this working to his satisfaction I hope he makes a post with an example. It nearly does it. Right now you can (with a fully updated trunk image, specifically on Raspbian, maybe other linuxes, no way for me to test) make a .st file executable and add a line of the form #!/usr/bin/squeak /home/pi/Squeak/TPR-Squeak5.3-18560.image as the first line. You can run this from a commandline with the usual ./MyAmazing.st As an example will open the specified image, install a fast fibonacci method (thanks Nicolas!), add a fibonacci server method to WebServer and fire up Webserver. This is seriously cool. Double-clicking the .st works too, thought in Raspbian you do have to say to execute it or execute it in a terminal (either works, by the way. No idea how to stop the make-a-choice dialogue). Of course, you can do the more manual squeak myAmazing.image WebFib.st as well Note that this is all without making use of Dave's excellent shell stuff, something else to play with. And indeed the amazing suggestion about the /proc/sys/fs/binfmt_misc/register magic from Subbu. The bit that I'd like to find a way to improve is having the ability to *not* open any windows. Right now the main window opens (as I've said many times, no window should open until some image code forces it to) and the UI is started up and the filing in etc happens after that. I don't know how we can nicely handle that; after all some legitimate uses of a script file would be to start a GUI application. Others would be of the 'calculate optimal firing solution and quit' variety. Two apparent bugs also require some thought and probably solving by someone else a) Windows appears to be unable to write to stdout - and probably therefore unable to read from stdin - despite the code appearing to be in the VM sources. b) Ubuntu (at least) seems to have a problem with stdout etc not being initialised properly unless we reset the StartUpList order. Why Raspbian did not have that problem I can't imagine - they're both Debian based IIRC. So all in all, damn cool stuff that could be made coolerer with some help. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Bayard(n): a person armed with the self-confidence of ignorance WebFib.st (3K) Download Attachment |
Free forum by Nabble | Edit this page |