Smalltalk › Pharo › Pharo Smalltalk Developers

What a mess

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Torsten Bergmann

What a mess

>as i said.. it is too clever :)

Yes and as I already noted on issue #3595 relative paths are now
supported but relative means currently "relative to the image location"
since "FileDirectory default" is used.
I think there is not yet a primitive to tell you where the VM is located
and that was the reason to implement it like this.

But in a typical scripting language paths are relative to
the executable (the VM in this case).

diamond.exe ../foo.dia

So if I build a new scripting language (with a custom diamond.exe VM)
based on Pharo the VM location is required - the image itself could
life elsewhere on the hard disk (given in the ini file for
instance).

Bye
T.

--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

Igor Stasenko

Re: What a mess

On 16 March 2011 17:07, Torsten Bergmann <[hidden email]> wrote:

>>as i said.. it is too clever :)
>
> Yes and as I already noted on issue #3595 relative paths are now
> supported but relative means currently "relative to the image location"
> since "FileDirectory default" is used.
> I think there is not yet a primitive to tell you where the VM is located
> and that was the reason to implement it like this.
>
> But in a typical scripting language paths are relative to
> the executable (the VM in this case).
>
> diamond.exe ../foo.dia

mm. no. Typically a relative paths are relative to the directory where
you issued the command line,
not relative to the directory where command located.

>
> So if I build a new scripting language (with a custom diamond.exe VM)
> based on Pharo the VM location is required - the image itself could
> life elsewhere on the hard disk (given in the ini file for
> instance).
>
> Bye
> T.
>
>
>
> --
> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
>
>

--
Best regards,
Igor Stasenko AKA sig.

Eliot Miranda-2

Re: What a mess

On Wed, Mar 16, 2011 at 9:14 AM, Igor Stasenko <[hidden email]> wrote:

On 16 March 2011 17:07, Torsten Bergmann <[hidden email]> wrote:
>>as i said.. it is too clever :)
>
> Yes and as I already noted on issue #3595 relative paths are now
> supported but relative means currently "relative to the image location"
> since "FileDirectory default" is used.
> I think there is not yet a primitive to tell you where the VM is located
> and that was the reason to implement it like this.
>
> But in a typical scripting language paths are relative to
> the executable (the VM in this case).
>
> diamond.exe ../foo.dia

mm. no. Typically a relative paths are relative to the directory where
you issued the command line,
not relative to the directory where command located.

Right.

Aren't we going to replace all the old FileDirectory crap with Colin's code? Please??

>
> So if I build a new scripting language (with a custom diamond.exe VM)
> based on Pharo the VM location is required - the image itself could
> life elsewhere on the hard disk (given in the ini file for
> instance).
>
> Bye
> T.
>
>
>
> --
> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
>
>

--
Best regards,
Igor Stasenko AKA sig.

Stéphane Ducasse

Re: What a mess

>
>
> mm. no. Typically a relative paths are relative to the directory where
> you issued the command line,
> not relative to the directory where command located.
>
> Right.
>
> Aren't we going to replace all the old FileDirectory crap with Colin's code? Please??

We are working on it but it takes time.

S.

>
> >
> > So if I build a new scripting language (with a custom diamond.exe VM)
> > based on Pharo the VM location is required - the image itself could
> > life elsewhere on the hard disk (given in the ini file for
> > instance).
> >
> > Bye
> > T.
> >
> >
> >
> > --
> > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>