Sven, It was just that in your example you didn't mention that the .st file had to be in the image directory and I was sorta hoping that there was a real solution to that problem ... It does mean that for gsDevKit I will still need to use bash wrapper files for all scripts that may be copied to arbitrary locations on disk ... oh well ... If that problem gets fixed, I will convert gsDevKit to use pharo-based scripts for almost everything:) Dale On Fri, Jul 25, 2014 at 1:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
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 <dale.henrichs@gemtalksystems.com> 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 <sven@stfx.eu> wrote:
On 25 Jul 2014, at 21:25, Dale Henrichs < dale.henrichs@gemtalksystems.com> 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 <sven@stfx.eu> wrote:
On 24 Jul 2014, at 16:34, phil@highoctane.be 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