Hi,
I have discovered a problem with my DrGeo command line handler. Its
purpose, under linux only for now, is to let the user open a DrGeo
sketch file from the desktop file manager by double-clicking on the file.
Sadly, it seems it does not work when non ascii characters are present
in the path
On 20 Jan 2015, at 16:21, Hilaire hila...@drgeo.eu wrote:
I forgot again Pharo internal string are not utf-8 but ByteString, so
the string need to be converted back to utf8.
No they are not - Strings and Characters in Pharo are using plain Unicode
encoding internally.
What you see in your
Command line arguments enter the image level via
VirtualMachine#getSystemAttribute:
At that point they are already Strings.
In your case, they must already be wrong at that point.
On 20 Jan 2015, at 16:51, Hilaire hila...@drgeo.eu wrote:
Le 20/01/2015 16:34, Sven Van Caekenberghe a écrit
Responding to myself for archiving purpose.
I forgot again Pharo internal string are not utf-8 but ByteString, so
the string need to be converted back to utf8.
For example in one of the handler method, it can be modified as follow:
DrGeoCommandLineHandlerloadSketch: aString
| utfString |
Le 20/01/2015 16:34, Sven Van Caekenberghe a écrit :
No they are not - Strings and Characters in Pharo are using plain Unicode
encoding internally.
Thanks for the update, and the reference link.
Hilaire
--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu
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?
Dale
On Thu, Jul 24, 2014 at 7:42 AM,
On 25 Jul 2014, at 21:25, Dale Henrichs dale.henri...@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
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
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
You can try to get the current working directory this way:
argumentsAsFileReferences
|pwd |
pwd := (Smalltalk os environment at: 'PWD' ifAbsent: [ Smalltalk os
environment at: 'CD' ]) asFileReference.
^ self argumentsWithoutOptions collect: [ :each | pwd resolveReference:
each asFileReference
Oh! That might just do the trick for me...
Turns out that I've got one more problem in that the gsDevKit pharo vm
and/or gsdevkit image files can be installed in arbitrary locations ... for
this one I guess I need to consider installing pharo and pharo-ui in
/usr/local/ ... will work for
Sick of sed and Perl ? There is fun in Object Icon and Rebol ( r3 or Red )
( Icon, UNICON or pythonic Converge PL.)
And I even use xcurl scripts for MIT Curl ( www.curl.com ) (now SCSK Curl
at www.curlap.com )
But Object Icon has to be built at the command line ;-)
I gave up on Io and have been
I run server-side JavaScript but would not dream of using JS to do jobs !
Humour : for years the command-line params for VW Smalltalk were some kind
of unpublished hush-hush secret for build mavens and image-stripping gurus
on hp/ux servers. Not so for Gnu Smalltalk ;-)
There is always APL ;-)
I've used GST in the past for simple scripting too. Worth a try!
2014-07-24 13:24 GMT+02:00 Robert Shiplett grshipl...@gmail.com:
I run server-side JavaScript but would not dream of using JS to do jobs !
Humour : for years the command-line params for VW Smalltalk were some kind
of
What are you using to do jobs on the commandline. I'm sick of doing bash and
sed,perl,jq,... stuff.
Me too. I dream about editing my pharo script in Pharo, deploying them
from pharo and debugging
them if necessary.
What would be the quickest start when using a normal image?
passing a code
I don't know if my Atlas library could be of assistance here. Atlas will
allow you to use python and python libraries from inside pharo via a socket
bridge. I am very noob when it comes to terminal but I hear that python is
very popular for command line stuff especially on linux and macos where it
Norbert,
I've just recently made the decision to start using Pharo3.0 to do all of
the heavy lifting for my GsDevKit project[1] shell scripts.
I use boilerplate bash code to setup the environment[2] and then call Pharo
CommandLineHandler[3] to do the real work ...
I embed the script
On 24 Jul 2014, at 16:07, Dale Henrichs dale.henri...@gemtalksystems.com
wrote:
Norbert,
I've just recently made the decision to start using Pharo3.0 to do all of the
heavy lifting for my GsDevKit project[1] shell scripts.
I use boilerplate bash code to setup the environment[2] and
Hi Norbert,
On 24 Jul 2014, at 12:37, Norbert Hartl norb...@hartl.name wrote:
What are you using to do jobs on the commandline. I'm sick of doing bash and
sed,perl,jq,... stuff. What would be the quickest start when using a normal
image? And what if I want to give coral a start. Does it
Am 24.07.2014 um 13:32 schrieb Bernat Romagosa tibabenfortlapala...@gmail.com:
I've used GST in the past for simple scripting too. Worth a try!
Thanks but to me this doesn't sound like a good idea. Why? Because I like to
have something that is easy to use. And I doubt that all things I like
Dale,
thanks for this extensive explanation. That looks all really good but I think
I'm looking for the exact opposite. You arrange a lot of pieces in a huge
environment and you make it bootstrap itself. The environment/project is
defined and all parts need to work together. I'm looking for
Le 24 juil. 2014 16:20, Dale Henrichs dale.henri...@gemtalksystems.com
a écrit :
Esteban,
Right now the classes are embedded in my tODE common package (I use the
parser in Pharo and GemStone) ... I'll pull out the classes and tests
(rename them so you can evolve the implementation independent
Sven,
that's it. I didn't know you can do it this way. So this an pragmatic approach
that can be optimized later towards tiny image and/or coral.
Great, thanks,
Norbert
Am 24.07.2014 um 16:17 schrieb Sven Van Caekenberghe s...@stfx.eu:
Hi Norbert,
On 24 Jul 2014, at 12:37, Norbert Hartl
On 24 Jul 2014, at 16:34, p...@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
Norbert,
Ah, yes different use case ... for the scripts I'm writing I wanted to
leverage loaded code as I've got a whole class hierarchy supporting the
GsDevKit environment and did not relish the idea of doing that all in bash
distributed across a number of different scripts ...
Haha, I live in
Am 24.07.2014 um 16:56 schrieb Dale Henrichs dale.henri...@gemtalksystems.com:
Haha, I live in tODE all the time, where Smalltalk _is_ the scripting
language so I don't feel your particular brand of pain:)
*takingjohnwaynepose* That's good for ya, boy! But I've got a business to
run…*nods*
With a smaller image, it gets a lot faster (except the first time)
total 149096
drwx--@ 12 stephan staff 408 24 jul 17:58 .
drwx--+ 3243 stephan staff110262 24 jul 17:48 ..
-rw-r--r--@1 stephan staff 6148 24 jul 17:49 .DS_Store
-rw-rw-r--@1 stephan staff
27 matches
Mail list logo
