Yes, for some reason, the shebang (#!) machinery passes ./test2.st as argument to pharo, which it seems can only be resolved if it is in the image directory (as opposed to the current shell directory).
I have no time to look at this now, but I vaguely remember that pharo mixed the concept of current working directory and image directory (at least in some places). On 25 Jul 2014, at 21:43, Dale Henrichs <[email protected]> wrote: > Sven, > Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I get the > following (it works if I `cp ./test.st /Users/daleh/gsDevKitHome/pharo`): > > nehalem:junk daleh$ pwd > /Users/daleh/junk > nehalem:junk daleh$ cat test.st > #!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo > --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit > FileStream stdout nextPutAll: 42 factorial asString; cr. > nehalem:junk daleh$ ./test.st > FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st > FileHandle>>streamError > FileHandle>>readStream > FileSystem>>readStreamOn: > FileReference>>readStream > FileReference(AbstractFileReference)>>readStreamDo: > STCommandLineHandler>>installSourceFile: > STCommandLineHandler>>installSourceFiles in Block: [ :reference | self > installSourceFile: reference ]...etc... > OrderedCollection>>do: > STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [ > :reference | self installSourc...etc... > BlockClosure>>ensure: > STCommandLineHandler>>installSourceFiles > STCommandLineHandler>>activate > STCommandLineHandler class(CommandLineHandler class)>>activateWith: > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in > Block: [ aCommandLinehandler activateWith: commandLine ] > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: > PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand > PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: > PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self > handleArgument: (self arguments ifEmpty: [ ...etc... > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activate > PharoCommandLineHandler>>activate > PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: > PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: > aCommandLine ] > WorldState>>runStepMethodsIn: > WorldMorph>>runStepMethods > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > MorphicUIManager>>spawnNewProcess in Block: [ ... > > > > On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe <[email protected]> wrote: > > On 25 Jul 2014, at 21:25, Dale Henrichs <[email protected]> > wrote: > > > Sven, > > > > I'm using Pharo3.0 and it appears that the .st scripts have to be located > > in the same directory as the image and changes files ... I see that you > > are using Pharo4.0 ... > > > > So is it possible to get Pharo3.0 to work on .st files in arbitary > > directores? > > Are you using the shebang or direct version ? > In any case, I am always using absolute paths. > Does that not work for you ? > > > Dale > > > > > > On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <[email protected]> wrote: > > > > On 24 Jul 2014, at 16:34, [email protected] wrote: > > > > > One question I have is how fast the load of an image and processing by an > > > image is when compared with bash. > > > > Obviously, it is slower, there is a whole image that needs to be loaded, > > etc. > > > > $ cat test.st > > #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless > > /Users/sven/tmp/pharo4/Pharo.image st --quit > > FileStream stdout nextPutAll: 42 factorial asString; cr. > > > > $ time ./test.st > > 1405006117752879898543142606244511569936384000000000 > > > > real 0m0.644s > > user 0m0.516s > > sys 0m0.067s > > > > So about half a second overhead. > > > > Sven > > > > >
