Re: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

[Andreas Sunardi]

Hi Alistair,

I found fogbugz #19717 where this was discussed.

https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder

The issue seems to be the current working directory is saved in instance
variable workingDirectory. When the image is moved to another directory,
this workingDirectory becomes incorrect. Instance variable 'store', through
its #defaultWorkingDirectory, always gives the right answer (however, this
answer is the image directory, not directory where the command is invoked,
which is the issue in #05723 you mentioned).

Here's a snippet from fogbugz #19717 original problem on how to reproduce
it:
QUOTE
1/ open an image. evaluate './pharo-local' asFileReference and keep the
inspector.
2/ save and quit
3/ move the image to another directory
4/ open the image
5/ evaluate self fullName on the file reference => it will give a wrong
path with a reference to the working directory used at file reference
creation.
ENDQUOTE

I don't know if it's still debatable, which './pharo-local' the file
reference should refer to, but I think I agree with fogbugz #19717 that it
should stay as relative path.

But this is a separate issue than losing the ability to change working
directory, which seems to me an unintentional side-effect in the solution.
I'll see if I can jump onto $05723 to request support for changing working
directory.

On a side note, is current working directory the same as image directory in
Pharo? I wonder why we have these issues if they are separate things. I
haven't dived into this, so I can't say much.

--
Andreas

On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <akgrant0...@gmail.com>
wrote:

> On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
> > It isn't only #changeDirectory: method that is missing. Method #
> > workingDirectoryPath: and instance variable workingDirectory are also
> missing.
> >
> > FileSystem >> changeDirectory: aPath
> >   self workingDirectoryPath: (self resolve: aPath)
> >
> > FileSystem >> workingDirectoryPath: aPath
> >   aPath isAbsolute
> > ifFalse: [ self error: 'Cannot set the working directory to a
> relative
> > path' ].
> >   workingDirectory := aPath
> >
> >
> > To solve my problem, I implemented those and also fixed
> #initializeWithStore:
> > and changed #workingDirectoryPath
> >
> > FileSystem >> initializeWithStore: aStore
> >   store := aStore.
> >   workingDirectory := store defaultWorkingDirectory
> >
> > FileSystem >> workingDirectoryPath
> >   ^ workingDirectory
> >
> >
> > Those are from Pharo 5. However, this breaks Monticello (when opening
> > Monticello Browser). A FileSystem instance has instance variable
> > workingDirectory set to nil. This should be impossible. I set 'self
> halt' in #
> > initializeWithStore:. It doesn't get triggered, which tells me the
> instance
> > isn't created by normal way. I don't know what's going on there.
> >
> >
> > To fix it, I changed #workingDirectoryPath to
> >
> > FileSystem >> workingDirectoryPath
> >   workingDirectory ifNil: [
> > workingDirectory := store defaultWorkingDirectory ].
> >   ^ workingDirectory
> >
> >
> > That solves my problem, but this is a specific tool. I don't know what
> other
> > problems those changes will cause. This #ifNil: guard is not in Pharo 5,
> so
> > that makes me worry. In general, the change in FileSystem gives
> impression that
> > the it is intentional. But I haven't found the new Pharo 6.1 way to
> change
> > working directory, if there's any.
>
> I couldn't find a fogbugz issue relating to this - if anyone knows the
> issue, please post it here as it would be good to understand the
> rationale for the change.
>
> My interpretation of the changes are that the decision was made to hard
> code the working directory to the image directory.  There are quite a
> few people who don't agree with this. :-)
>
> There is already a proposed patch to change the working directory to the
> process working directory, see fogbugz #05723.
> https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory
>
> The patch is waiting on a fix to include UFFI in the kernel.
>
> It currently doesn't allow the working directory to be changed,
> but if I remember correctly, Rajula developed the code to change the
> working directory.
>
> I think this approach has the advantage that it will automtically work
> with forked processes, e.g. using OSProcess / OSSubprocess.
>
> It would be worthwhile adding a comment to the issue asking Rajula to
> add the change directory functionality to the patch.
>
> Cheers,
> A

Re: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

[Andreas Sunardi]

It isn't only #changeDirectory: method that is missing. Method
#workingDirectoryPath: and instance variable workingDirectory are also
missing.

FileSystem >> changeDirectory: aPath
  self workingDirectoryPath: (self resolve: aPath)

FileSystem >> workingDirectoryPath: aPath
  aPath isAbsolute
ifFalse: [ self error: 'Cannot set the working directory to a relative
path' ].
  workingDirectory := aPath


To solve my problem, I implemented those and also fixed
#initializeWithStore: and changed #workingDirectoryPath

FileSystem >> initializeWithStore: aStore
  store := aStore.
  workingDirectory := store defaultWorkingDirectory

FileSystem >> workingDirectoryPath
  ^ workingDirectory


Those are from Pharo 5. However, this breaks Monticello (when opening
Monticello Browser). A FileSystem instance has instance variable
workingDirectory set to nil. This should be impossible. I set 'self halt'
in #initializeWithStore:. It doesn't get triggered, which tells me the
instance isn't created by normal way. I don't know what's going on there.


To fix it, I changed #workingDirectoryPath to

FileSystem >> workingDirectoryPath
  workingDirectory ifNil: [
workingDirectory := store defaultWorkingDirectory ].
  ^ workingDirectory


That solves my problem, but this is a specific tool. I don't know what
other problems those changes will cause. This #ifNil: guard is not in Pharo
5, so that makes me worry. In general, the change in FileSystem gives
impression that the it is intentional. But I haven't found the new Pharo
6.1 way to change working directory, if there's any.


--
Andreas

On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> Thanks for reporting.
> I do not remember an action around me for this change.
> Do you have the definition in Pharo 50 at hand?
>
> Stef
>
> On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
> > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been
> > using FileSystem>>changeDirectory to make my program (Pharo 5) runs in
> the
> > current working directory (thus able to find local files).
> >
> > This is now broken because #changeDirectory doesn't exist anymore. The
> > change seems intentional.
> >
> > Question: Is there a different way in Pharo 6 do set working directory
> or is
> > this a bug?
> >
> > --
> > Andreas
>
>

Re: [Pharo-users] CodeImporter. 256 literals limit

[Andreas Sunardi]

Esteban, I'm happy to report this package works for me, in my RH/CentOS 6
environment. I have to do a bit more since I have to install it in a
network path (can't install in each server).

If there's a download option instead of an rpm, such as that in Pharo 5
download website, that would be great. But I don't want to complain about
it. The response and support from this community has been very impressive
and I'm very grateful for it. Thank you very much!

--
Andreas



On Wed, Aug 30, 2017 at 2:02 AM, Esteban Lorenzano <esteba...@gmail.com>
wrote:

> you can try the new (still experimental) packaging for Pharo:
>
> CentOS 6.8:
>
> # Add the repo
> $ yum-config-manager --add-repo http://download.opensuse.org/
> repositories/devel:/languages:/pharo:/latest/CentOS_6/devel:
> languages:pharo:latest.repo
>
> # Install 32bit packages (with X11 dependency for *-ui or not)
>
> $ yum install pharo6-32-ui.i686 or pharo6-32.i386
>
> # Install 64bit packages
>
> $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64
>
> that will install correct vm for your distribution.
>
> cheers,
> Esteban
>
>
>
> On 29 Aug 2017, at 18:58, Andreas Sunardi <a.suna...@gmail.com> wrote:
>
> Point well taken. Unfortunately, I'm not in charge of the infrastructure.
> I don't know if my experience is typical or not, but it's difficult for IT
> to find a period to disrupt engineering projects, potentially breaking
> tools, without drawing fire from engineering :)
>
>
> On Tue, Aug 29, 2017 at 8:45 AM, Richard Sargent <richard.sargent@
> gemtalksystems.com> wrote:
>
>> my work environment is using RedHat6/CentOS6 with glibc 2.12
>>>
>>
>> That's seven years of unpatched security vulnerabilities! Are you sure
>> you really want to stay at such great risk?
>>
>>
>> On Tue, Aug 29, 2017 at 8:30 AM, Andreas Sunardi <a.suna...@gmail.com>
>> wrote:
>>
>>> That sounds good. Unfortunately for me, my work environment is using
>>> RedHat6/CentOS6 with glibc 2.12. Is there Pharo6 with glibc < 2.15 support.
>>> Or is there a way for me to build that myself?
>>>
>>> It's quite a departure to change my DSL into defining multiple methods.
>>> But that's my own problem.
>>>
>>> I'm happy to hear Pharo 6 can support a lot more literals. I tested my
>>> code on Pharo 6 (on my Windows box) and it works. I see SistaV1 compiler in
>>> Pharo 5 setting, but that causes Pharo to crash.
>>>
>>> Thank you guys for your answers. I think I have the information I need
>>> to make decision. But if there is a way to get Pharo 6 that works with
>>> glibc < 2.15, please let me know.
>>>
>>> Thank you
>>> --
>>> Andreas
>>>
>>> On Tue, Aug 29, 2017 at 12:34 AM, Clément Bera <bera.clem...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> If your tool works in Pharo 6, you can use the other bytecode set which
>>>> supports up to 32k literals. To do so, go to:
>>>> World Menu > Settings > Compiler > Encoder
>>>> and pick SistaV1 instead of V3PlusClosures
>>>> Try to load your code. The default Pharo 6 VM supports both bytecode
>>>> sets.
>>>>
>>>> Alternatively you need to split your methods with many literals in
>>>> multiple methods with less literals, which is usually quite tricky to do
>>>> right.
>>>>
>>>> On Tue, Aug 29, 2017 at 4:52 AM, Andreas Sunardi <a.suna...@gmail.com>
>>>> wrote:
>>>>
>>>>> I have written a tool (Pharo5) where user gives an input file to it,
>>>>> where the content is a smalltalk code, a DSL. I used a subclass of
>>>>> CodeImporter class to evaluate this input file.
>>>>>
>>>>> Recently my user used an input file where it hit the 256 literal limit
>>>>> (total of unique string, number, method name, etc), down in
>>>>> OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be
>>>>> hard coded and related to byte code generator, not something I can simply
>>>>> increase. I wasn't aware of this limitation.
>>>>>
>>>>> Before I overhaul my tool, I thought I should ask. Is there another
>>>>> alternative to evaluate a smalltalk file/script? The file is small, 27k,
>>>>> but the number of unique literals in it is > 256. Is it possible at all,
>>>>> seeing that the limit is related to byte code generator.
>>>>>
>>>>> Thank you in advance
>>>>> --
>>>>> Andreas Sunardi
>>>>>
>>>>
>>>>
>>>
>>
>
>

[Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

[Andreas Sunardi]

I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been
using FileSystem>>changeDirectory to make my program (Pharo 5) runs in the
current working directory (thus able to find local files).

This is now broken because #changeDirectory doesn't exist anymore. The
change seems intentional.

Question: Is there a different way in Pharo 6 do set working directory or
is this a bug?

--
Andreas

[Pharo-users] Engineering notation

[Andreas Sunardi]

I probably telling what has been known for ages, but some months ago I was
pleasantly surprise to find a space is not needed between the receiver and
the message when the receiver is a number. Because of that I'm able to
define, for example #u, #n and #k for micron, nano and kilo units, and use
them as in 1u, 1n and 1k.

I don't know if this is intended or not, but I'm using it to my benefit. I
want to share this in case some body finds this and thinks it should be
fixed. I'm pleading to leave it as is.

--
Andreas Sunardi

Re: [Pharo-users] CodeImporter. 256 literals limit

[Andreas Sunardi]

Point well taken. Unfortunately, I'm not in charge of the infrastructure. I
don't know if my experience is typical or not, but it's difficult for IT to
find a period to disrupt engineering projects, potentially breaking tools,
without drawing fire from engineering :)


On Tue, Aug 29, 2017 at 8:45 AM, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:

> my work environment is using RedHat6/CentOS6 with glibc 2.12
>>
>
> That's seven years of unpatched security vulnerabilities! Are you sure you
> really want to stay at such great risk?
>
>
> On Tue, Aug 29, 2017 at 8:30 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>> That sounds good. Unfortunately for me, my work environment is using
>> RedHat6/CentOS6 with glibc 2.12. Is there Pharo6 with glibc < 2.15 support.
>> Or is there a way for me to build that myself?
>>
>> It's quite a departure to change my DSL into defining multiple methods.
>> But that's my own problem.
>>
>> I'm happy to hear Pharo 6 can support a lot more literals. I tested my
>> code on Pharo 6 (on my Windows box) and it works. I see SistaV1 compiler in
>> Pharo 5 setting, but that causes Pharo to crash.
>>
>> Thank you guys for your answers. I think I have the information I need to
>> make decision. But if there is a way to get Pharo 6 that works with glibc <
>> 2.15, please let me know.
>>
>> Thank you
>> --
>> Andreas
>>
>> On Tue, Aug 29, 2017 at 12:34 AM, Clément Bera <bera.clem...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> If your tool works in Pharo 6, you can use the other bytecode set which
>>> supports up to 32k literals. To do so, go to:
>>> World Menu > Settings > Compiler > Encoder
>>> and pick SistaV1 instead of V3PlusClosures
>>> Try to load your code. The default Pharo 6 VM supports both bytecode
>>> sets.
>>>
>>> Alternatively you need to split your methods with many literals in
>>> multiple methods with less literals, which is usually quite tricky to do
>>> right.
>>>
>>> On Tue, Aug 29, 2017 at 4:52 AM, Andreas Sunardi <a.suna...@gmail.com>
>>> wrote:
>>>
>>>> I have written a tool (Pharo5) where user gives an input file to it,
>>>> where the content is a smalltalk code, a DSL. I used a subclass of
>>>> CodeImporter class to evaluate this input file.
>>>>
>>>> Recently my user used an input file where it hit the 256 literal limit
>>>> (total of unique string, number, method name, etc), down in
>>>> OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be
>>>> hard coded and related to byte code generator, not something I can simply
>>>> increase. I wasn't aware of this limitation.
>>>>
>>>> Before I overhaul my tool, I thought I should ask. Is there another
>>>> alternative to evaluate a smalltalk file/script? The file is small, 27k,
>>>> but the number of unique literals in it is > 256. Is it possible at all,
>>>> seeing that the limit is related to byte code generator.
>>>>
>>>> Thank you in advance
>>>> --
>>>> Andreas Sunardi
>>>>
>>>
>>>
>>
>

Re: [Pharo-users] CodeImporter. 256 literals limit

[Andreas Sunardi]

That sounds good. Unfortunately for me, my work environment is using
RedHat6/CentOS6 with glibc 2.12. Is there Pharo6 with glibc < 2.15 support.
Or is there a way for me to build that myself?

It's quite a departure to change my DSL into defining multiple methods. But
that's my own problem.

I'm happy to hear Pharo 6 can support a lot more literals. I tested my code
on Pharo 6 (on my Windows box) and it works. I see SistaV1 compiler in
Pharo 5 setting, but that causes Pharo to crash.

Thank you guys for your answers. I think I have the information I need to
make decision. But if there is a way to get Pharo 6 that works with glibc <
2.15, please let me know.

Thank you
--
Andreas

On Tue, Aug 29, 2017 at 12:34 AM, Clément Bera <bera.clem...@gmail.com>
wrote:

> Hi,
>
> If your tool works in Pharo 6, you can use the other bytecode set which
> supports up to 32k literals. To do so, go to:
> World Menu > Settings > Compiler > Encoder
> and pick SistaV1 instead of V3PlusClosures
> Try to load your code. The default Pharo 6 VM supports both bytecode sets.
>
> Alternatively you need to split your methods with many literals in
> multiple methods with less literals, which is usually quite tricky to do
> right.
>
> On Tue, Aug 29, 2017 at 4:52 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>> I have written a tool (Pharo5) where user gives an input file to it,
>> where the content is a smalltalk code, a DSL. I used a subclass of
>> CodeImporter class to evaluate this input file.
>>
>> Recently my user used an input file where it hit the 256 literal limit
>> (total of unique string, number, method name, etc), down in
>> OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be
>> hard coded and related to byte code generator, not something I can simply
>> increase. I wasn't aware of this limitation.
>>
>> Before I overhaul my tool, I thought I should ask. Is there another
>> alternative to evaluate a smalltalk file/script? The file is small, 27k,
>> but the number of unique literals in it is > 256. Is it possible at all,
>> seeing that the limit is related to byte code generator.
>>
>> Thank you in advance
>> --
>> Andreas Sunardi
>>
>
>

[Pharo-users] CodeImporter. 256 literals limit

[Andreas Sunardi]

I have written a tool (Pharo5) where user gives an input file to it, where
the content is a smalltalk code, a DSL. I used a subclass of CodeImporter
class to evaluate this input file.

Recently my user used an input file where it hit the 256 literal limit
(total of unique string, number, method name, etc), down in
OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be
hard coded and related to byte code generator, not something I can simply
increase. I wasn't aware of this limitation.

Before I overhaul my tool, I thought I should ask. Is there another
alternative to evaluate a smalltalk file/script? The file is small, 27k,
but the number of unique literals in it is > 256. Is it possible at all,
seeing that the limit is related to byte code generator.

Thank you in advance
--
Andreas Sunardi

Re: [Pharo-users] Pharo starts completely minimized

[Andreas Sunardi]

Where did I see this pharo-ui? I thought I saw it before. I never used it,
I always use 'pharo' script/executable, but now I can't find it. I checked
windows(P5/P6). linux(P5/P6), mac(P6) and I don't find this pharo-ui.

There's -iconic (Pharo 5) and --iconic (Pharo 6) options.

$ pharo --help | grep iconic
--iconicstart up iconified

I wonder if that is set in pharo-ui. But again, I can't find pharo-ui file.

On Thu, Jul 6, 2017 at 7:24 PM, sergio ruiz  wrote:

> For some reason, every time i start pharo. like: ./pharo-ui Pharo.image
>
> it starts as a tiny box.. a completely minimized window..
>
> any ideas?
>
> should i be starting it differently?
>
> Thanks!
>
>
>
> 
> peace,
> sergio
> photographer, journalist, visionary
>
> Public Key: http://bit.ly/29z9fG0
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> http://www.Village-Buzz.com 
> http://www.ThoseOptimizeGuys.com 
> http://www.coffee-black.com
> http://www.painlessfrugality.com
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101
>

Re: [Pharo-users] Pharo6.0 for linux and PharoV60.sources location

[Andreas Sunardi]

Hi Stef,

Thank you for the clarification. It helps to know whether something is
intended or not. I appreciate very much that you took time to response and
clarify.

And congratulation to Clement :)


On Tue, Jul 4, 2017 at 11:20 PM, Marc Hanisch via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Marc Hanisch <marc.hani...@googlemail.com>
> To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Cc:
> Bcc:
> Date: Wed, 5 Jul 2017 08:20:45 +0200
> Subject: Re: [Pharo-users] Pharo6.0 for linux and PharoV60.sources location
> Hi Stephane,
>
> thanks for that kind reply! No problem!
> I'm unfortunately not too deep into Pharo, but maybe I can help with
> the packaging / build process for the Linux downloads (at least my
> Linux knowledge is far better than my Pharo knowledge ;-))?
>
> Best regards,
> Marc
>
> 2017-07-05 8:00 GMT+02:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> > Hi marc
> >
> > We are a bit under water in this moment making sure that we can handle
> > pull requests for Pharo 70.
> > I'm sure that it will get better in the future.
> > Esteban is moving, we got many articles to send, clement hand it in its
> phd :).
> > And many more.
> >
> > So we are sorry about the support.
> >
> > Stef
> >
> > On Mon, Jul 3, 2017 at 1:14 PM, Marc Hanisch via Pharo-users
> > <pharo-users@lists.pharo.org> wrote:
> >>
> >>
> >> -- Forwarded message --
> >> From: Marc Hanisch <marc.hani...@googlemail.com>
> >> To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> >> Cc:
> >> Bcc:
> >> Date: Mon, 3 Jul 2017 13:14:52 +0200
> >> Subject: Re: [Pharo-users] Pharo6.0 for linux and PharoV60.sources
> location
> >> Hi Andreas,
> >>
> >> Yes, that was me. Unfortunately I did not get an answer. I solved this
> by copying the sources file into the location where Pharo is looking for it.
> >>
> >> Due to the missing sources file, variables and arguments got renamed
> automatically...
> >>
> >> I still don't understand why the sources file is spread 3 or 4 times
> across the directory structure...
> >>
> >> Best regards,
> >> Marc
> >>
> >> Am 03.07.2017 12:16 schrieb "Andreas Sunardi" <a.suna...@gmail.com>:
> >>>
> >>> Pardon me if this has been discussed before. I seem to recall somebody
> ran into this issue or related to this, but I don't remember what the
> solution was, if there was any.
> >>>
> >>> The linux Pharo 6 download package from Pharo web site has different
> VM directory structure than Pharo 5. The PharoV60.sources file is not
> located in the same directory as the VM binary. As a result, if user has
> image + changes files in another directory, Pharo always gives notification
> that the sources file is not found. This is not so with the Pharo 5.
> >>>
> >>> In most cases, it's just a notification, but in the past I've run into
> an error in debugging session when I tried to look into a method because of
> missing sources file.
> >>>
> >>> Can this be corrected or is it expected for the user to manage sources
> file where about? I'm hoping a correction or clarification would at least
> benefit new comers.
> >>>
> >>> --
> >>> Andreas
> >>>
> >>>
> >>
> >
>
>
>

[Pharo-users] Pharo6.0 for linux and PharoV60.sources location

[Andreas Sunardi]

Pardon me if this has been discussed before. I seem to recall somebody ran
into this issue or related to this, but I don't remember what the solution
was, if there was any.

The linux Pharo 6 download package from Pharo web site has different VM
directory structure than Pharo 5. The PharoV60.sources file is not located
in the same directory as the VM binary. As a result, if user has image +
changes files in another directory, Pharo always gives notification that
the sources file is not found. This is not so with the Pharo 5.

In most cases, it's just a notification, but in the past I've run into an
error in debugging session when I tried to look into a method because of
missing sources file.

Can this be corrected or is it expected for the user to manage sources file
where about? I'm hoping a correction or clarification would at least
benefit new comers.

--
Andreas

Re: [Pharo-users] Pharo command line, stdout and integrating with other tools?

[Andreas Sunardi]

If I'm not mistaken, this is Pharo's eval command line handler you're
talking about. If so, it is not correct to say 'it also return the result
of that method or yourself'. To return the result (and print it to stdout)
of that method is the goal of eval command line handler.

How about making your method to return empty string, or better create your
own command line handler. I believe the minimal you need to do is to
subclass EvaluateCommandLineHandler, override class method #commandName and
override method #evaluate:. Something like this, perhaps

ProceesCommandLineHandler class >> commandName
  ^ 'process'

ProcessCommandLineHandler >> evaluate: aStream
  Smalltalk evaluate: aStream.

Save your image, then you can call
./pharo -headless myimage.image process StandardFileStream stdout print: 42

and it'll print 42 and nothing else.

I'm not sure I understand the double quote (") character issue that \"
solves. Example?



On Thu, Jun 29, 2017 at 7:02 AM, Tim Mackinnon  wrote:

> Hi - I've been playing with using Pharo with Aws lambda and have got an
> image to launch in that environment.
>
> However now I need to better integrate Pharo with its calling environment
> - and I know there was a concerted effort to make Pharo play better which I
> should be able to leverage.
>
> So I am calling  Pharo from a NodeJS wrapper  (the suggested aws method
> for integrating alternative languages like Ruby, Go etc).
>
> I got this to work - however as an observation, it is rather awkward
> passing parameters to Pharo using the "eval" mechanism as other languages
> and environments frequently use the " character (particularly with Json)
> and this causes Pharo to fail if you don't \" this. I'm wondering if others
> have noted this and whether we can do this better somehow? For now a little
> nodeJS regex fu gets me past it.
>
> However my next question is about passing information back to the calling
> application.
>
> I can see that there is a stdout method on Fikestream that I can write to
> (great), however in my ./pharo eval call, which sends to a class method
> doing this - it also returns the result of that method or yourself? I guess
> this convention is great for the "eval 42 factorial" example but not so
> great of you just want to return some Json via stdout in a format of the
> calling environment?
>
> Is there something simple trick I can do to  stop this extra result and
> just let me use stdout myself? Or do I have to return a Smalltalk string
> and then regex convert it to a new format in my calling language?
>
> I'm wondering if others have done this, or if anyone has some advice?
>
> It feels like a usecase that we might be able to do better somehow?
>
> Tim
>
> Sent from my iPhone
>
>

Re: [Pharo-users] Pharo6 bootstrap how to

[Andreas Sunardi]

I'm also interested in this topic. I've built some small tools but a bit
troubled with the installation size. I'd like to reduce it, but still be
able to go in and debug when there's problem and to restore a set of
packages/classes to add back a removed feature if I later found I need it.

I recently started to look at Dr.Geo to learn how to develop and deploy a
Pharo based application. So, I'm thankful to Hilaire for bringing this
topic up and I'm looking forward to learn from Dr. Geo and from the outcome
of this topic.

On Sat, Jul 1, 2017 at 6:29 AM, Stephane Ducasse 
wrote:

> https://www.peteruhnak.com/blog/2016/07/25/how-to-use-
> git-and-github-with-pharo/
>
> But you should look on the blog of dale henrichs
> I did not check but he probably explained how to define baseline.
>
>
>
> On Tue, Jun 27, 2017 at 1:02 PM, Pavel Krivanek
>  wrote:
> > Right now we do not have such source.
> >
> > -- Pavel
> >
> >
> > 2017-06-26 18:42 GMT+02:00 Hilaire :
> >>
> >> Do you have a page explaining the process so people can try out?
> >>
> >> Hilaire
> >>
> >> Le 26/06/2017 à 16:29, Pavel Krivanek a écrit :
> >> > You need to do it manually. You should probably start with own copy of
> >> > BaselineOfIDE and then try to remove packages you don't need. You
> should
> >> > do it slowly and check if you are still able to generate a working
> >> > image.
> >> >
> >> > -- Pavel
> >>
> >> --
> >> Dr. Geo
> >> http://drgeo.eu
> >>
> >>
> >
>
>

Re: [Pharo-users] How to deploy headless app without changes and source files?

[Andreas Sunardi]

For now, in my 'deployed' image, I have:
1. Disabled SourceFilesArray >> forceChangesToDisk
I did not find any code branch that would avoid this, so for now I just
made it do nothing. Maybe I should disable ChangesLog >> logChange: instead.

2. Disabled PharoFilesOpener >> changesFileOrNil
Same story. But this only causes warning get printed out, not error.
Disabling it removes the warning message.

3. Set changesFileStream to nil (SourceFiles changesFileStream: nil).
Some code does have guard against nil value for this changes stream.

This works for me if I do not have the changes file with the image. If I
have the changes file and it's read-only, that's a different problem.

It seems that this was possible before, judging from the older links I
found in my original email and the existence of some guards against
non-existence changes file.

I'll check those links and perhaps see if I can be helpful there, but I
right now have delivery to make. And I can't wait to try Pharo 6 too.

--
Andreas


On Tue, Jun 6, 2017 at 6:37 PM, Ben Coman <b...@openinworld.com> wrote:

>
>
> On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>> Hi Stef,
>>
>> I can't have changes file bundled with the tool because the tool is
>> installed in a centralized location in my network and multiple users will
>> run it. So the image is in a central location and read-only and so is the
>> changes file (if I must have a changes file). The tool is only a processor.
>> It does not need to keep/save its state.
>>
>> Hence, I cannot have multiple users writing to that one and the same
>> changes file.
>>
>> I'm trying to dissect the call chain to ChangesLog and try to cut it so
>> Pharo won't write to the changes file. I'm sure I should not do this. There
>> must be a better way.
>>
>
> I guess this use case just hasn't been critical for other people (there
> are lots of competing priorities) and they've found ways of working around
> it, like making your network located tool a script that copies itself
> itself to a use folder and run from there.  But of course it would be
> better for Pharo to work cleanly without a changes file. To make it better,
> someone has to do it, so feel free to propose some code changes (with
> discussion of such on pharo-dev list).
>
> Here is one hint (something related I worked on recently)...
> https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-
> when-sources-file-missing
> To view the changes, open image 60494 (easiest using PharoLauncher)
> and load the slice.
>
> Filtering the issue tracker on "changes file" pops up a few other
> possibilities (I haven't reviewed them, and you might find others)
> https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes-
> file-is-not-writable
> https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-
> that-opens-the-sources-and-changes-files
>
> cheers -ben
>
>
>>
>> On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> We started to work on making the system ready to stop using these files.
>>> There are two things.
>>> - the changes are a tape that logs what you are doing and right now
>>> the system is not done to accept not to log
>>> So I imagine that you can remove the changes file but then do not
>>> compile code.
>>> - I do not get the "so I can't have changes file bundled with the tool."
>>> you do not have a bat or script that launches the application that is
>>> somewhere in a folder where you have the vm and the image? you could
>>> have the changes file there.
>>>
>>> We are interested in your scenario because last year I got a guy
>>> working on making pharo silent. I do not know if its changes got
>>> integrated into pharo.
>>> This is really something that we want to have.
>>> - having sources and changes in a specific location
>>> - having no source and no changes (even if it means lose your code).
>>> - ...
>>>
>>> Stef
>>>
>>> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.suna...@gmail.com>
>>> wrote:
>>> > Sorry to bring this up again. But it turns out that I had the image
>>> > directory writable by myself, so it created a new changes file. That's
>>> why
>>> > Pharo didn't complain about missing changes file. When I removed write
>>> > permission in the tool installation, Pharo gives error for not having
>>> or not
>>> > able to write to changes file.
>>> >
>>> > I guess I'm back to the problem

Re: [Pharo-users] How to deploy headless app without changes and source files?

[Andreas Sunardi]

Hi Stef,

I can't have changes file bundled with the tool because the tool is
installed in a centralized location in my network and multiple users will
run it. So the image is in a central location and read-only and so is the
changes file (if I must have a changes file). The tool is only a processor.
It does not need to keep/save its state.

Hence, I cannot have multiple users writing to that one and the same
changes file.

I'm trying to dissect the call chain to ChangesLog and try to cut it so
Pharo won't write to the changes file. I'm sure I should not do this. There
must be a better way.


On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> We started to work on making the system ready to stop using these files.
> There are two things.
> - the changes are a tape that logs what you are doing and right now
> the system is not done to accept not to log
> So I imagine that you can remove the changes file but then do not compile
> code.
> - I do not get the "so I can't have changes file bundled with the tool."
> you do not have a bat or script that launches the application that is
> somewhere in a folder where you have the vm and the image? you could
> have the changes file there.
>
> We are interested in your scenario because last year I got a guy
> working on making pharo silent. I do not know if its changes got
> integrated into pharo.
> This is really something that we want to have.
> - having sources and changes in a specific location
> - having no source and no changes (even if it means lose your code).
> - ...
>
> Stef
>
> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
> > Sorry to bring this up again. But it turns out that I had the image
> > directory writable by myself, so it created a new changes file. That's
> why
> > Pharo didn't complain about missing changes file. When I removed write
> > permission in the tool installation, Pharo gives error for not having or
> not
> > able to write to changes file.
> >
> > I guess I'm back to the problem how to deploy a tool without changes
> file. I
> > have multiple users that will be running this tool, which is installed
> in a
> > centralized site, so I can't have changes file bundled with the tool.
> >
> > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
> >>
> >> I had my changes and sources files in the bundle but has their write
> >> permission removed, and that causes the error. Simply deploying the tool
> >> without the changes file seems to fix it. Pharo5 doesn't complain if the
> >> changes file isn't there.
> >>
> >> However, without the sources file, I get this warning that pharo cannot
> >> locate the sources file. Including the sources file in the deployed
> tool is
> >> fine with me.
> >>
> >> So, I think that's my solution. Thanks!
> >>
> >>
> >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.suna...@gmail.com>
> >> wrote:
> >>>
> >>> I found this StackOverflow question:
> >>>
> >>> https://stackoverflow.com/questions/14737695/is-it-
> possible-to-deploy-a-pharo-image-without-changes-and-
> sources-files/14747328
> >>>
> >>> and this older forum thread:
> >>>
> >>> https://www.mail-archive.com/pharo-project@lists.gforge.
> inria.fr/msg21170.html
> >>>
> >>> I'm using Pharo5.0 and neither of these options is available anymore.
> >>> What is the new way to do this?
> >>>
> >>> --
> >>> Andreas Sunardi
> >>
> >>
> >
>
>

Re: [Pharo-users] How to deploy headless app without changes and source files?

[Andreas Sunardi]

Sorry to bring this up again. But it turns out that I had the image
directory writable by myself, so it created a new changes file. That's why
Pharo didn't complain about missing changes file. When I removed write
permission in the tool installation, Pharo gives error for not having or
not able to write to changes file.

I guess I'm back to the problem how to deploy a tool without changes file.
I have multiple users that will be running this tool, which is installed in
a centralized site, so I can't have changes file bundled with the tool.

On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.suna...@gmail.com> wrote:

> I had my changes and sources files in the bundle but has their write
> permission removed, and that causes the error. Simply deploying the tool
> without the changes file seems to fix it. Pharo5 doesn't complain if the
> changes file isn't there.
>
> However, without the sources file, I get this warning that pharo cannot
> locate the sources file. Including the sources file in the deployed tool is
> fine with me.
>
> So, I think that's my solution. Thanks!
>
>
> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>> I found this StackOverflow question:
>> https://stackoverflow.com/questions/14737695/is-it-possible-
>> to-deploy-a-pharo-image-without-changes-and-sources-files/14747328
>>
>> and this older forum thread:
>> https://www.mail-archive.com/pharo-project@lists.gforge.inri
>> a.fr/msg21170.html
>>
>> I'm using Pharo5.0 and neither of these options is available anymore.
>> What is the new way to do this?
>>
>> --
>> Andreas Sunardi
>>
>
>

Re: [Pharo-users] How to deploy headless app without changes and source files?

[Andreas Sunardi]

I had my changes and sources files in the bundle but has their write
permission removed, and that causes the error. Simply deploying the tool
without the changes file seems to fix it. Pharo5 doesn't complain if the
changes file isn't there.

However, without the sources file, I get this warning that pharo cannot
locate the sources file. Including the sources file in the deployed tool is
fine with me.

So, I think that's my solution. Thanks!


On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.suna...@gmail.com> wrote:

> I found this StackOverflow question:
> https://stackoverflow.com/questions/14737695/is-it-
> possible-to-deploy-a-pharo-image-without-changes-and-
> sources-files/14747328
>
> and this older forum thread:
> https://www.mail-archive.com/pharo-project@lists.gforge.
> inria.fr/msg21170.html
>
> I'm using Pharo5.0 and neither of these options is available anymore. What
> is the new way to do this?
>
> --
> Andreas Sunardi
>

[Pharo-users] How to deploy headless app without changes and source files?

[Andreas Sunardi]

I found this StackOverflow question:
https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pharo-image-without-changes-and-sources-files/14747328

and this older forum thread:
https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.html

I'm using Pharo5.0 and neither of these options is available anymore. What
is the new way to do this?

--
Andreas Sunardi

Re: [Pharo-users] Saving selected changes in Monticello

[Andreas Sunardi]

I definitely will check Komitter and I can use and fallback to Ben's
method. Thank you to all of you.

On Mon, Jun 5, 2017 at 12:58 AM, Peter Uhnak <i.uh...@gmail.com> wrote:

> Komitter could indeed help you, see https://www.peteruhnak.com/
> blog/2016/08/12/fine-grained-committing-and-extending-nautilus/
>
> Peter
>
> On Mon, Jun 05, 2017 at 08:27:23AM +0200, serge.stinckw...@gmail.com
> wrote:
> > Kommiter available in default image allows you do cherry pick quite
> easily.
> >
> > Envoyé de mon iPhone
> >
> > > Le 5 juin 2017 à 07:14, Ben Coman <b...@openinworld.com> a écrit :
> > >
> > >
> > >
> > >> On Mon, Jun 5, 2017 at 10:12 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
> > >> I have a half done changes in my image, but I need to distribute the
> other changes that are done. I thought I was going to do this all at once,
> but now I realize I should split this into 2 commit versions.
> > >>
> > >> Is there a way in Monticello to say save my changes, but not this and
> that changes? I can't seem to find it nor in books. How do people deal with
> this situation?
> > >
> > > AFAIK, Monticello cannot cherry pick.  One work around is probably
> something like...
> > > 1. Save the mcz locally
> > > 2. Merge back into a fresh image selecting only the bits you want.
> > > 3. Save as a second mcz.
> > > One issue is that the second mcz will have the first mcz as an
> ancestor, so before 2 you might create a new changeset to file out after 2,
> and load that into a second new image. yuck!
> > >
> > > Another alternative might be to use Tools > ChangeSorter to move the
> code you want to exclude from the mcz to a changeset, file that out and
> then revert that code in the image. After save the package to a mcz, reload
> the changeset.
> > >
> > > cheers -ben
>
>

[Pharo-users] Saving selected changes in Monticello

[Andreas Sunardi]

I have a half done changes in my image, but I need to distribute the other
changes that are done. I thought I was going to do this all at once, but
now I realize I should split this into 2 commit versions.

Is there a way in Monticello to say save my changes, but not this and that
changes? I can't seem to find it nor in books. How do people deal with this
situation?

--
Andreas Sunardi

Re: [Pharo-users] Rectangle and Polygon classes' bugs?

[Andreas Sunardi]

Ah, I see, so Rectangle is in the context of display geometry not Cartesian
coordinate (I don't know if I'm using the right words here, but I hope you
get what I mean). You're right, the package is 'Graphics-Shapes'. For some
reason, I thought it said 'Geometry'

I'm building something for layout geometry and these would be the wrong
classes to use then. Question #2 would be a moot point.

Thanks for the answer. You've saved me from going to the wrong path.

--
Andreas Sunardi

On Fri, May 19, 2017 at 9:53 AM, Ben Coman <b...@openinworld.com> wrote:

>
>
> On Sat, May 20, 2017 at 12:23 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>> Pharo 5.0
>>
>> It seems like a bug to me, but perhaps I misunderstand something.
>>
>> 1) Comment in Rectangle class >> origin:corner: method shows 'origin'
>> should be top left and 'corner' should be bottom right. This method calls
>> Rectangle >> setPoint:point:. But this method calculates 'origin' to be
>> bottom left corner and 'corner' to be top right. Now all the edge and
>> corner methods are wrong.
>>
>> r := Rectangle origin: 0@0 corner: 10@10.
>> r topLeft.  => (0@0)   "should be 0@10"
>> r bottomRight.  => (10@10)  "should be 10@0"
>> r top.  => 0  "should be 10"
>> r bottom.  => 10  " should be 0"
>>
>
> Would this depend on where you consider 0@0 to be on the screen?
>   (em := EllipseMorph new) openInWorld.
>   em bounds "==> (0@0) corner: (50@40)"
>
>
>
>> 2) Why Polygon >> bounds (which is PathShape >> bounds) returns a
>> rectangle with a corner 1 point larger than the actual boundary?
>>
>> p1 := Polygon vertices: {0@0 . 0@10 . 10@10 . 10@0}.
>> p1 bounds.  => (0@0) corner: (11@11).  "should be 0@0 and 10@10"
>>
>> This seems to be a fix to Rectangle >> containsPoint: strange behavior.
>> By strange behavior, I mean:
>>
>> r := Rectangle point: 0@0 point: 10@10.
>> r containsPoint: 0@0.  => true
>> r containsPoint: 10@10.  => false  "should be true"
>> { r topLeft . r topRight . r bottomLeft . r bottomRight } allSatisfy [
>> :corner | r containsPoint: corner ].  => false  "should be true"
>>
>
>
> I want to fix this in my image, but Rectangle is used all over the place
>> and I'm worry I'll break a lot of things. I wonder if I just misunderstood
>> how these are supposed to be used. Can anybody help me understand if this
>> is intentional or a bug?
>>
>
> Sorry, I don't know about this.
> cheers -ben
>

[Pharo-users] Rectangle and Polygon classes' bugs?

[Andreas Sunardi]

Pharo 5.0

It seems like a bug to me, but perhaps I misunderstand something.

1) Comment in Rectangle class >> origin:corner: method shows 'origin'
should be top left and 'corner' should be bottom right. This method calls
Rectangle >> setPoint:point:. But this method calculates 'origin' to be
bottom left corner and 'corner' to be top right. Now all the edge and
corner methods are wrong.

r := Rectangle origin: 0@0 corner: 10@10.
r topLeft.  => (0@0)   "should be 0@10"
r bottomRight.  => (10@10)  "should be 10@0"
r top.  => 0  "should be 10"
r bottom.  => 10  " should be 0"


2) Why Polygon >> bounds (which is PathShape >> bounds) returns a rectangle
with a corner 1 point larger than the actual boundary?

p1 := Polygon vertices: {0@0 . 0@10 . 10@10 . 10@0}.
p1 bounds.  => (0@0) corner: (11@11).  "should be 0@0 and 10@10"

This seems to be a fix to Rectangle >> containsPoint: strange behavior. By
strange behavior, I mean:

r := Rectangle point: 0@0 point: 10@10.
r containsPoint: 0@0.  => true
r containsPoint: 10@10.  => false  "should be true"
{ r topLeft . r topRight . r bottomLeft . r bottomRight } allSatisfy [
:corner | r containsPoint: corner ].  => false  "should be true"


I want to fix this in my image, but Rectangle is used all over the place
and I'm worry I'll break a lot of things. I wonder if I just misunderstood
how these are supposed to be used. Can anybody help me understand if this
is intentional or a bug?

PS: I looked at RectangleTest and I'm not sure I understand why they are
testing what they are testing.

--
Andreas Sunardi

[Pharo-users] Is there a bind key to go to next argument?

[Andreas Sunardi]

Is there a bind key to jump to the next argument slot? After using TAB for
method completion, I wonder if there's a key/command to jump to the next
argument slot. I checked the keymap browser and either it isn't there or I
missed it.

The closest I've done so far is Meta + Right, but this needs to be
performed 3 times to go to the next argument.

--
Andreas

Re: [Pharo-users] PetitParser installation fails in Pharo 5.0

[Andreas Sunardi]

It isn't glibc issue. Perhaps my wording makes it unclear. When I said
'linux' or 'linux with old glibc', I was referring to the image versions
that come with those download options. I wasn't referring to glibc itself.

--
Andreas Sunardi


On Sun, May 14, 2017 at 3:14 AM, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> I do not really see why loading a package would be related to old glibc
> but may be :)
> With software who knows.
> Now what is important for you is that you always tries to load and produce
> configurations.
>
> Stef
>
> On Sun, May 14, 2017 at 2:03 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>>  Hi Stephane,
>>
>> I shall read that Metacello chapter. I had considered this case closed
>> until you replied again. I took another peek and I think I found the root
>> cause. And for the sake of those who stumble on this email thread, I should
>> clarify this.
>>
>> This is probably related to my old email thread about running Pharo 5.0
>> on linux with old glibc, which resulted in Pharo5.0-linux-oldLibC download
>> to work properly.
>> http://lists.pharo.org/pipermail/pharo-users_lists.pharo.
>> org/2016-October/028431.html
>>
>> Following your solution, after installing PetitParser from Catalog
>> Browser in Windows version, I noticed the ConfigurationOfPetitParser
>> version is TudorGirba.80, the version I had problem in linux. I then
>> wondered why it didn't work on my linux with old glibc versions. Here's
>> what I found
>>
>> Download and version (SystemVersion current imageVersionString):
>> centos  Pharo-5.0-50761-
>> linux Pharo-5.0-50772-
>> linux-oldLibC *Pharo-6.0-60257-*
>>
>> Pharo5.0-linux-oldLibC has image for Pharo 6.0. This is the one I use
>> where PetitParser installation failed.
>>
>> Using Catalog Browser, or Gofer instruction from smalltalkhub, for #load
>> and #loadDevelopment versions, PetitParser installation works fine for
>> images that come from linux and centos  versions, but not from
>> linux-oldLibC.
>>
>> So, I believe that is the problem. I'm not sure what's the right
>> solution, but I think I can stay in this image and use TudorGirba.77
>> version or I can try using image from linux version.
>>
>> Thanks again. If you hadn't replied about Metacello, I'd have never taken
>> another look and found this.
>>
>> --
>> Andreas Sunardi
>>
>> On Sat, May 13, 2017 at 12:45 AM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> You should read the beginning of the chapter on metacello.
>>> Metacello is a map
>>> Monticello element of the map
>>>
>>> You load elements by asking the map.
>>>
>>> Stef
>>>
>>> On Sat, May 13, 2017 at 3:43 AM, Andreas Sunardi <a.suna...@gmail.com>
>>> wrote:
>>>
>>>> Hi Stephane,
>>>>
>>>> Indeed, PetitParser installation from Catalog Browser works just fine!
>>>> Thank you very much.
>>>>
>>>> I used Monticello Browser before, but not Catalog Browser. I didn't
>>>> know this is the preferred method to install package. I don't think
>>>> DeepIntoPharo mentions about Catalog Browser, but maybe my version is
>>>> outdated.
>>>>
>>>> Thanks again, Stephane.
>>>>
>>>> --
>>>> Andreas Sunardi
>>>>
>>>> On Fri, May 12, 2017 at 12:48 PM, Stephane Ducasse <
>>>> stepharo.s...@gmail.com> wrote:
>>>>
>>>>> Sorry I meant the catalogBrowser.
>>>>> Using the catalogBrowser on a given version of Pharo you should access
>>>>> the configuration for this version (if people updated it correctly).
>>>>> Our plan is to make sure that such configurations are validated.
>>>>> Stef
>>>>>
>>>>> On Fri, May 12, 2017 at 9:47 PM, Stephane Ducasse <
>>>>> stepharo.s...@gmail.com> wrote:
>>>>>
>>>>>> Hi andreas
>>>>>>
>>>>>> Normally you should be able to load a package using the
>>>>>> ConfigurationBrowser and the configuration (now I do not know the one of
>>>>>> PetitParser)
>>>>>> should take care of the pharo version for you.
>>>>>>
>>>>>> stef
>>>>>>
>>>>>>
>>>>>> On Fri, May 12, 2017 at 7:06 PM, Andreas Sunardi <a.suna...@gmail.c

Re: [Pharo-users] PetitParser installation fails in Pharo 5.0

[Andreas Sunardi]

Hi Ben,

It's the linux download page from Pharo website
http://pharo.org/gnu-linux-installation


--
Andreas

On Sun, May 14, 2017 at 5:20 AM, Ben Coman <b...@openinworld.com> wrote:

> On Sun, May 14, 2017 at 8:03 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
> >  Hi Stephane,
> >
> > I shall read that Metacello chapter. I had considered this case closed
> until
> > you replied again. I took another peek and I think I found the root
> cause.
> > And for the sake of those who stumble on this email thread, I should
> clarify
> > this.
> >
> > This is probably related to my old email thread about running Pharo 5.0
> on
> > linux with old glibc, which resulted in Pharo5.0-linux-oldLibC download
> to
> > work properly.
> > http://lists.pharo.org/pipermail/pharo-users_lists.
> pharo.org/2016-October/028431.html
> >
> > Following your solution, after installing PetitParser from Catalog
> Browser
> > in Windows version, I noticed the ConfigurationOfPetitParser version is
> > TudorGirba.80, the version I had problem in linux. I then wondered why it
> > didn't work on my linux with old glibc versions. Here's what I found
> >
> > Download and version (SystemVersion current imageVersionString):
> > centos  Pharo-5.0-50761-
> > linux Pharo-5.0-50772-
> > linux-oldLibC *Pharo-6.0-60257-*
>
> Can you provide the links for those downloads?
>
> cheers -ben
>
> >
> > Pharo5.0-linux-oldLibC has image for Pharo 6.0. This is the one I use
> where
> > PetitParser installation failed.
> >
> > Using Catalog Browser, or Gofer instruction from smalltalkhub, for #load
> and
> > #loadDevelopment versions, PetitParser installation works fine for images
> > that come from linux and centos  versions, but not from linux-oldLibC.
> >
> > So, I believe that is the problem. I'm not sure what's the right
> solution,
> > but I think I can stay in this image and use TudorGirba.77 version or I
> can
> > try using image from linux version.
> >
> > Thanks again. If you hadn't replied about Metacello, I'd have never taken
> > another look and found this.
> >
> > --
> > Andreas Sunardi
> >
> > On Sat, May 13, 2017 at 12:45 AM, Stephane Ducasse <
> stepharo.s...@gmail.com>
> > wrote:
> >>
> >> You should read the beginning of the chapter on metacello.
> >> Metacello is a map
> >> Monticello element of the map
> >>
> >> You load elements by asking the map.
> >>
> >> Stef
> >>
> >> On Sat, May 13, 2017 at 3:43 AM, Andreas Sunardi <a.suna...@gmail.com>
> >> wrote:
> >>>
> >>> Hi Stephane,
> >>>
> >>> Indeed, PetitParser installation from Catalog Browser works just fine!
> >>> Thank you very much.
> >>>
> >>> I used Monticello Browser before, but not Catalog Browser. I didn't
> know
> >>> this is the preferred method to install package. I don't think
> DeepIntoPharo
> >>> mentions about Catalog Browser, but maybe my version is outdated.
> >>>
> >>> Thanks again, Stephane.
> >>>
> >>> --
> >>> Andreas Sunardi
> >>>
> >>> On Fri, May 12, 2017 at 12:48 PM, Stephane Ducasse
> >>> <stepharo.s...@gmail.com> wrote:
> >>>>
> >>>> Sorry I meant the catalogBrowser.
> >>>> Using the catalogBrowser on a given version of Pharo you should access
> >>>> the configuration for this version (if people updated it correctly).
> >>>> Our plan is to make sure that such configurations are validated.
> >>>> Stef
> >>>>
> >>>> On Fri, May 12, 2017 at 9:47 PM, Stephane Ducasse
> >>>> <stepharo.s...@gmail.com> wrote:
> >>>>>
> >>>>> Hi andreas
> >>>>>
> >>>>> Normally you should be able to load a package using the
> >>>>> ConfigurationBrowser and the configuration (now I do not know the
> one of
> >>>>> PetitParser)
> >>>>> should take care of the pharo version for you.
> >>>>>
> >>>>> stef
> >>>>>
> >>>>>
> >>>>> On Fri, May 12, 2017 at 7:06 PM, Andreas Sunardi <
> a.suna...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Following DeepIntoPharo, I tried to install PetitParser into my
>

Re: [Pharo-users] PetitParser installation fails in Pharo 5.0

[Andreas Sunardi]

 Hi Stephane,

I shall read that Metacello chapter. I had considered this case closed
until you replied again. I took another peek and I think I found the root
cause. And for the sake of those who stumble on this email thread, I should
clarify this.

This is probably related to my old email thread about running Pharo 5.0 on
linux with old glibc, which resulted in Pharo5.0-linux-oldLibC download to
work properly.
http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2016-October/028431.html

Following your solution, after installing PetitParser from Catalog Browser
in Windows version, I noticed the ConfigurationOfPetitParser version is
TudorGirba.80, the version I had problem in linux. I then wondered why it
didn't work on my linux with old glibc versions. Here's what I found

Download and version (SystemVersion current imageVersionString):
centos  Pharo-5.0-50761-
linux Pharo-5.0-50772-
linux-oldLibC *Pharo-6.0-60257-*

Pharo5.0-linux-oldLibC has image for Pharo 6.0. This is the one I use where
PetitParser installation failed.

Using Catalog Browser, or Gofer instruction from smalltalkhub, for #load
and #loadDevelopment versions, PetitParser installation works fine for
images that come from linux and centos  versions, but not from
linux-oldLibC.

So, I believe that is the problem. I'm not sure what's the right solution,
but I think I can stay in this image and use TudorGirba.77 version or I can
try using image from linux version.

Thanks again. If you hadn't replied about Metacello, I'd have never taken
another look and found this.

--
Andreas Sunardi

On Sat, May 13, 2017 at 12:45 AM, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> You should read the beginning of the chapter on metacello.
> Metacello is a map
> Monticello element of the map
>
> You load elements by asking the map.
>
> Stef
>
> On Sat, May 13, 2017 at 3:43 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>> Hi Stephane,
>>
>> Indeed, PetitParser installation from Catalog Browser works just fine!
>> Thank you very much.
>>
>> I used Monticello Browser before, but not Catalog Browser. I didn't know
>> this is the preferred method to install package. I don't think
>> DeepIntoPharo mentions about Catalog Browser, but maybe my version is
>> outdated.
>>
>> Thanks again, Stephane.
>>
>> --
>> Andreas Sunardi
>>
>> On Fri, May 12, 2017 at 12:48 PM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> Sorry I meant the catalogBrowser.
>>> Using the catalogBrowser on a given version of Pharo you should access
>>> the configuration for this version (if people updated it correctly).
>>> Our plan is to make sure that such configurations are validated.
>>> Stef
>>>
>>> On Fri, May 12, 2017 at 9:47 PM, Stephane Ducasse <
>>> stepharo.s...@gmail.com> wrote:
>>>
>>>> Hi andreas
>>>>
>>>> Normally you should be able to load a package using the
>>>> ConfigurationBrowser and the configuration (now I do not know the one of
>>>> PetitParser)
>>>> should take care of the pharo version for you.
>>>>
>>>> stef
>>>>
>>>>
>>>> On Fri, May 12, 2017 at 7:06 PM, Andreas Sunardi <a.suna...@gmail.com>
>>>> wrote:
>>>>
>>>>> Following DeepIntoPharo, I tried to install PetitParser into my Pharo
>>>>> 5.0 image (I noticed PetitParser installation problem email in March). It
>>>>> failed with the message WinPlatform class was undefined. I went to Moose's
>>>>> PetitParser site in smalltalkhub and followed the instruction there, and
>>>>> this also failed.
>>>>>
>>>>> Out of frustration, I downloaded Moose 6.0 and thought I'd start from
>>>>> Moose image instead. But then I noticed Moose's PetitParser package has
>>>>> ConfigurationOfPetitParser from version TudorGirba.77 and the instruction 
>>>>> I
>>>>> followed was trying to install it using version TudorGirba.80. Back to my
>>>>> Pharo 5 image, I unload/remove ConfigurationOfPetitParser and load version
>>>>> TudorGirba.77. And this works!
>>>>>
>>>>> But this way to solve PetitParser installation problem seems wrong. I
>>>>> figure if this could very well happen with other packages too. What is the
>>>>> right way to find package version that works with my image/pharo version?
>>>>> Or is this an issue with PetitParser package itself and should I 
>>>>> ask/report
>>>>> this to Moose team?
>>>>>
>>>>> --
>>>>> Andreas Sunardi
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [Pharo-users] PetitParser installation fails in Pharo 5.0

[Andreas Sunardi]

Hi Stephane,

Indeed, PetitParser installation from Catalog Browser works just fine!
Thank you very much.

I used Monticello Browser before, but not Catalog Browser. I didn't know
this is the preferred method to install package. I don't think
DeepIntoPharo mentions about Catalog Browser, but maybe my version is
outdated.

Thanks again, Stephane.

--
Andreas Sunardi

On Fri, May 12, 2017 at 12:48 PM, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> Sorry I meant the catalogBrowser.
> Using the catalogBrowser on a given version of Pharo you should access the
> configuration for this version (if people updated it correctly).
> Our plan is to make sure that such configurations are validated.
> Stef
>
> On Fri, May 12, 2017 at 9:47 PM, Stephane Ducasse <stepharo.s...@gmail.com
> > wrote:
>
>> Hi andreas
>>
>> Normally you should be able to load a package using the
>> ConfigurationBrowser and the configuration (now I do not know the one of
>> PetitParser)
>> should take care of the pharo version for you.
>>
>> stef
>>
>>
>> On Fri, May 12, 2017 at 7:06 PM, Andreas Sunardi <a.suna...@gmail.com>
>> wrote:
>>
>>> Following DeepIntoPharo, I tried to install PetitParser into my Pharo
>>> 5.0 image (I noticed PetitParser installation problem email in March). It
>>> failed with the message WinPlatform class was undefined. I went to Moose's
>>> PetitParser site in smalltalkhub and followed the instruction there, and
>>> this also failed.
>>>
>>> Out of frustration, I downloaded Moose 6.0 and thought I'd start from
>>> Moose image instead. But then I noticed Moose's PetitParser package has
>>> ConfigurationOfPetitParser from version TudorGirba.77 and the instruction I
>>> followed was trying to install it using version TudorGirba.80. Back to my
>>> Pharo 5 image, I unload/remove ConfigurationOfPetitParser and load version
>>> TudorGirba.77. And this works!
>>>
>>> But this way to solve PetitParser installation problem seems wrong. I
>>> figure if this could very well happen with other packages too. What is the
>>> right way to find package version that works with my image/pharo version?
>>> Or is this an issue with PetitParser package itself and should I ask/report
>>> this to Moose team?
>>>
>>> --
>>> Andreas Sunardi
>>>
>>
>>
>

[Pharo-users] PetitParser installation fails in Pharo 5.0

[Andreas Sunardi]

Following DeepIntoPharo, I tried to install PetitParser into my Pharo 5.0
image (I noticed PetitParser installation problem email in March). It
failed with the message WinPlatform class was undefined. I went to Moose's
PetitParser site in smalltalkhub and followed the instruction there, and
this also failed.

Out of frustration, I downloaded Moose 6.0 and thought I'd start from Moose
image instead. But then I noticed Moose's PetitParser package has
ConfigurationOfPetitParser from version TudorGirba.77 and the instruction I
followed was trying to install it using version TudorGirba.80. Back to my
Pharo 5 image, I unload/remove ConfigurationOfPetitParser and load version
TudorGirba.77. And this works!

But this way to solve PetitParser installation problem seems wrong. I
figure if this could very well happen with other packages too. What is the
right way to find package version that works with my image/pharo version?
Or is this an issue with PetitParser package itself and should I ask/report
this to Moose team?

--
Andreas Sunardi

Re: [Pharo-users] Pharo5 download for linux - interpreter cannot read image file

[Andreas Sunardi]

I confirmed the new version is working just fine.

If this info is helpful, I'm running this new version on my CentOS 6.5 at
my work.

On Tue, Oct 11, 2016 at 3:02 AM, Esteban Lorenzano <esteba...@gmail.com>
wrote:

> I made a new version of http://files.pharo.org/platform/Pharo5.0-linux-
> oldLibC.zip, based on Yan's VM... They should work fine.
>
> Now... I need a CentOS compatible VM :P
>
> Esteban
>
> On 10 Oct 2016, at 08:29, Esteban Lorenzano <esteba...@gmail.com> wrote:
>
>
> On 10 Oct 2016, at 05:47, Andreas Sunardi <a.suna...@gmail.com> wrote:
>
> Hello Stef,
>
> IMHO, since the 'GNU/Linux w. libc < 2.15' download in Pharo download
> webpage is broken anyway, we should repackage that download. Then other
> people using this version doesn't have to follow extra instruction to patch
> it. Having said that, I understand you and the Pharo team may have a reason
> to not hastily repackage that download option.
>
>
> yes, it is :(
> I need to fix that link.
>
> Esteban
>
>
> So, here are the downloads needed:
> 1. 'GNU/Linux w. libc < 2.15' from Pharo download page
> http://pharo.org/gnu-linux-installation
> $ wget http://files.pharo.org/platform/Pharo5.0-linux-oldLibC.zip
>
> 2. Jan Vrany's Pharo 5 VM https://swing.fit.cvut.cz/j
> enkins/job/pharo-vm-spur-swing/. I used the current latest build, which
> is currently build #5, Jan 17, 2016
> $ wget https://swing.fit.cvut.cz/jenkins/view/All/job/pharo-
> vm-spur-swing/lastSuccessfulBuild/artifact/pharo-vm-spur-swing.zip
>
> 3. Pharo 5 sources file from http://files.pharo.org/sources/
> $ wget http://files.pharo.org/sources/PharoV50.sources.zip
>
> 4. Latest Pharo 5 image from http://files.pharo.org/image, which is
> currently 50761
> $ wget http://files.pharo.org/image/50/Pharo-Image-5.0-latest.zip
>
>
> Installation:
> 1. Unzip 'GNU/Linux w. libc < 2.15'
> $ unzip Pharo5.0-linux-oldLibC.zip
>
> 2. Replace VM in bin/ with  Jan Vrany's build
> $ cd pharo5.0/bin
> $ unzip ../../pharo-vm-spur-swing.zip
>
> 3. Put Pharo 5 sources file in the VM directory
> $ unzip ../../PharoV50.sources.zip
>
> 4. Replace image and changes file with the latest
> $ cd ../shared
> $ rm Pharo5.0.{image,changes}
> $ unzip ../../Pharo-Image-5.0-latest.zip
> $ mv Pharo-50761.image Pharo5.0.image
> $ mv Pharo-50761.changes Pharo5.0.changes
>
>
> Now, we can run pharo with libc < 2.15
> $ cd ..
> $ pharo
>
>
> I hope that help!
> --
> Andreas
>
> On Sat, Oct 8, 2016 at 10:10 AM, stepharo <steph...@free.fr> wrote:
>
>> Hi
>>
>> I would like a list of
>>
>> - links
>>
>> - actions (unix commands)
>>
>> so that we can add it to the web site so that other people using the same
>> version than you
>>
>> can install and run pharo simply.
>>
>>
>> Stef
>>
>>
>> Le 7/10/16 à 19:06, Andreas Sunardi a écrit :
>>
>> Hi Stef,
>>
>> Can you explain a little bit about what this 'How to' is? Just now I'm
>> able to finally run pharo5 on my CentOS with glibc version < 2.15 and I
>> wrote my finding in my other reply.
>>
>> Are you referring to how to put these things together to finally able to
>> run pharo? Or are you referring to my digging through the error?
>>
>>
>> On Thu, Oct 6, 2016 at 11:08 PM, stepharo <steph...@free.fr> wrote:
>>
>>> Hi andreas
>>>
>>> could you write a little how to so that we can put it on the web site?
>>>
>>> Stef
>>>
>>> Le 7/10/16 à 06:20, Andreas Sunardi a écrit :
>>>
>>> Thanks, Bernardo. That fogbugz case is exactly the problem I'm having.
>>>
>>> This VM (pharo-vm-spur-swing.zip) is able to open Pharo 5.0 image from
>>> Pharo download page. This is a good sign.
>>>
>>> Upon opening the image, I am, however, presented immediately with
>>> 'MessageNotUnderstood: receiver of "/" is nil'. It's coming from
>>> SystemSettingsPersistence class >> defaultPreferenceFileReference
>>>
>>> It boils down to
>>> OSEnvironment#getEnv: 'HOME'
>>>
>>> a failure in building an FFI call. The FFI call function signature is
>>> #( String getenv (String string) )
>>>
>>> The context object built from OSEnvironment#getEnv: gives answer 'arg1',
>>> instead of 'string', to a call to #method#argumentNames. Down the road, an
>>> IRMethod instance is trying to find the index for 'string' and can't find
>>> any, because what is stored is 'arg1'.
>>>
>>> I'm ou

Re: [Pharo-users] Pharo5 download for linux - interpreter cannot read image file

[Andreas Sunardi]

Hello Stef,

IMHO, since the 'GNU/Linux w. libc < 2.15' download in Pharo download
webpage is broken anyway, we should repackage that download. Then other
people using this version doesn't have to follow extra instruction to patch
it. Having said that, I understand you and the Pharo team may have a reason
to not hastily repackage that download option.

So, here are the downloads needed:
1. 'GNU/Linux w. libc < 2.15' from Pharo download page
http://pharo.org/gnu-linux-installation
$ wget http://files.pharo.org/platform/Pharo5.0-linux-oldLibC.zip

2. Jan Vrany's Pharo 5 VM https://swing.fit.cvut.cz/
jenkins/job/pharo-vm-spur-swing/. I used the current latest build, which is
currently build #5, Jan 17, 2016
$ wget https://swing.fit.cvut.cz/jenkins/view/All/job/pharo-vm-spur-swing/
lastSuccessfulBuild/artifact/pharo-vm-spur-swing.zip

3. Pharo 5 sources file from http://files.pharo.org/sources/
$ wget http://files.pharo.org/sources/PharoV50.sources.zip

4. Latest Pharo 5 image from http://files.pharo.org/image, which is
currently 50761
$ wget http://files.pharo.org/image/50/Pharo-Image-5.0-latest.zip


Installation:
1. Unzip 'GNU/Linux w. libc < 2.15'
$ unzip Pharo5.0-linux-oldLibC.zip

2. Replace VM in bin/ with  Jan Vrany's build
$ cd pharo5.0/bin
$ unzip ../../pharo-vm-spur-swing.zip

3. Put Pharo 5 sources file in the VM directory
$ unzip ../../PharoV50.sources.zip

4. Replace image and changes file with the latest
$ cd ../shared
$ rm Pharo5.0.{image,changes}
$ unzip ../../Pharo-Image-5.0-latest.zip
$ mv Pharo-50761.image Pharo5.0.image
$ mv Pharo-50761.changes Pharo5.0.changes


Now, we can run pharo with libc < 2.15
$ cd ..
$ pharo


I hope that help!
--
Andreas

On Sat, Oct 8, 2016 at 10:10 AM, stepharo <steph...@free.fr> wrote:

> Hi
>
> I would like a list of
>
> - links
>
> - actions (unix commands)
>
> so that we can add it to the web site so that other people using the same
> version than you
>
> can install and run pharo simply.
>
>
> Stef
>
>
> Le 7/10/16 à 19:06, Andreas Sunardi a écrit :
>
> Hi Stef,
>
> Can you explain a little bit about what this 'How to' is? Just now I'm
> able to finally run pharo5 on my CentOS with glibc version < 2.15 and I
> wrote my finding in my other reply.
>
> Are you referring to how to put these things together to finally able to
> run pharo? Or are you referring to my digging through the error?
>
>
> On Thu, Oct 6, 2016 at 11:08 PM, stepharo <steph...@free.fr> wrote:
>
>> Hi andreas
>>
>> could you write a little how to so that we can put it on the web site?
>>
>> Stef
>>
>> Le 7/10/16 à 06:20, Andreas Sunardi a écrit :
>>
>> Thanks, Bernardo. That fogbugz case is exactly the problem I'm having.
>>
>> This VM (pharo-vm-spur-swing.zip) is able to open Pharo 5.0 image from
>> Pharo download page. This is a good sign.
>>
>> Upon opening the image, I am, however, presented immediately with
>> 'MessageNotUnderstood: receiver of "/" is nil'. It's coming from
>> SystemSettingsPersistence class >> defaultPreferenceFileReference
>>
>> It boils down to
>> OSEnvironment#getEnv: 'HOME'
>>
>> a failure in building an FFI call. The FFI call function signature is
>> #( String getenv (String string) )
>>
>> The context object built from OSEnvironment#getEnv: gives answer 'arg1',
>> instead of 'string', to a call to #method#argumentNames. Down the road, an
>> IRMethod instance is trying to find the index for 'string' and can't find
>> any, because what is stored is 'arg1'.
>>
>> I'm out of my depth at this point, and this is a separate issue than not
>> being able to start the image. I have to think where I want to go from here.
>>
>> So, thank you for all of you, for the exceedingly quick and friendly help.
>>
>> Cheers!
>>
>> On Thu, Oct 6, 2016 at 5:42 PM, Bernardo Ezequiel Contreras <
>> vonbecm...@gmail.com> wrote:
>>
>>> Hold on,
>>>
>>>   There's also this issue
>>> https://pharo.fogbugz.com/f/cases/17353/build-spur-vm-for-de
>>> bian-old-libc
>>>
>>> where in one comment jan.vrany recommended his build
>>>
>>> https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/
>>>
>>> https://swing.fit.cvut.cz/jenkins/view/All/job/pharo-vm-spur
>>> -swing/lastSuccessfulBuild/artifact/pharo-vm-spur-swing.zip
>>>
>>> that i have used in debian wheezy with the old libc for quite a while. i
>>> don't use it anymore because im in jessie.
>>>
>>>
>>>
>>> On Thu, Oct 6, 2016 at 9:13 PM, Andreas Sunardi <a.suna...@gmail.com>
>>> wr

Re: [Pharo-users] Pharo5 download for linux - interpreter cannot read image file

[Andreas Sunardi]

Hi Stef,

Can you explain a little bit about what this 'How to' is? Just now I'm able
to finally run pharo5 on my CentOS with glibc version < 2.15 and I wrote my
finding in my other reply.

Are you referring to how to put these things together to finally able to
run pharo? Or are you referring to my digging through the error?


On Thu, Oct 6, 2016 at 11:08 PM, stepharo <steph...@free.fr> wrote:

> Hi andreas
>
> could you write a little how to so that we can put it on the web site?
>
> Stef
>
> Le 7/10/16 à 06:20, Andreas Sunardi a écrit :
>
> Thanks, Bernardo. That fogbugz case is exactly the problem I'm having.
>
> This VM (pharo-vm-spur-swing.zip) is able to open Pharo 5.0 image from
> Pharo download page. This is a good sign.
>
> Upon opening the image, I am, however, presented immediately with
> 'MessageNotUnderstood: receiver of "/" is nil'. It's coming from
> SystemSettingsPersistence class >> defaultPreferenceFileReference
>
> It boils down to
> OSEnvironment#getEnv: 'HOME'
>
> a failure in building an FFI call. The FFI call function signature is
> #( String getenv (String string) )
>
> The context object built from OSEnvironment#getEnv: gives answer 'arg1',
> instead of 'string', to a call to #method#argumentNames. Down the road, an
> IRMethod instance is trying to find the index for 'string' and can't find
> any, because what is stored is 'arg1'.
>
> I'm out of my depth at this point, and this is a separate issue than not
> being able to start the image. I have to think where I want to go from here.
>
> So, thank you for all of you, for the exceedingly quick and friendly help.
>
> Cheers!
>
> On Thu, Oct 6, 2016 at 5:42 PM, Bernardo Ezequiel Contreras <
> vonbecm...@gmail.com> wrote:
>
>> Hold on,
>>
>>   There's also this issue
>> https://pharo.fogbugz.com/f/cases/17353/build-spur-vm-for-debian-old-libc
>>
>> where in one comment jan.vrany recommended his build
>>
>> https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/
>>
>> https://swing.fit.cvut.cz/jenkins/view/All/job/pharo-vm-spur
>> -swing/lastSuccessfulBuild/artifact/pharo-vm-spur-swing.zip
>>
>> that i have used in debian wheezy with the old libc for quite a while. i
>> don't use it anymore because im in jessie.
>>
>>
>>
>> On Thu, Oct 6, 2016 at 9:13 PM, Andreas Sunardi <a.suna...@gmail.com>
>> wrote:
>>
>>> Thank you for the impressive quick response. Unfortunately, I have older
>>> glibc. So now I'm struggling with compiling glibc 2.15 for 32 bit on my 64
>>> bit CentOS 6.5 machine. Not an easy thing to do.
>>>
>>> I'll try those VMs once I succeed in building this glibc
>>>
>>> On Thu, Oct 6, 2016 at 12:41 PM, Bernardo Ezequiel Contreras <
>>> vonbecm...@gmail.com> wrote:
>>>
>>>> this
>>>> http://files.pharo.org/vm/pharo-spur32/linux/latest.zip
>>>>
>>>> works pretty well in Debian GNU/Linux 8 Jessie
>>>>
>>>>
>>>> On Thu, Oct 6, 2016 at 4:09 PM, Clément Bera <bera.clem...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks for reporting the problem.
>>>>>
>>>>> The error means the VM is incompatible with the image. There was a
>>>>> change of image format in Pharo 5, so the package has likely an old VM
>>>>> while the image has the new format, or the new VM while the image has the
>>>>> old format.
>>>>>
>>>>> Someone will look into that problem in the incoming weeks. Most Pharo
>>>>> maintainers are on Mac, we noticed recently that other OS were not
>>>>> maintained carefully enough (We're sorry about that) and we're trying to
>>>>> solve that problem.
>>>>>
>>>>> Meantime
>>>>>
>>>>> Can you try the latest VM from here (latest.zip):
>>>>> http://files.pharo.org/vm/pharo-spur32/linux/
>>>>>
>>>>> Or if still failing, the latest VM from here (latest.zip):
>>>>> http://files.pharo.org/vm/pharo/linux/
>>>>>
>>>>> One of these two VMs should work. Please tell me which one worked if
>>>>> you try.
>>>>>
>>>>> Thanks & Regards
>>>>>
>>>>> Clement
>>>>>
>>>>> On Thu, Oct 6, 2016 at 8:44 PM, Bernardo Ezequiel Contreras <
>>>>> vonbecm...@gmail.com> wrote:
>>>>>
>>>>&

Re: [Pharo-users] Pharo5 download for linux - interpreter cannot read image file

[Andreas Sunardi]

That's it! But it isn't as simple as that Here's what I did. I have pharo5
directory, unzipped from the Pharo download page (GNU/Linux w. libc <
2.15). I then took the VM Bernardo pointed me to and copy that VM into my
pharo5/bin.

That Pharo download (GNU/Linux w. libc <2.15) has shared/Pharo5.0.image
along with shared/PharoV40.sources

Next I grabbed the PharoV50.sources as Clement instructed. First I tried to
put it in shared/, because that's where PharoV40.sources is, even tough
Clement said to put it in the same folder as the VM.

Then I tried to run it, calling pharo binary or the wrapper. Here's what I
found:
1. pharo keeps looking for PharoV40.sources, looking in bin/ first (the VM
directory) and next in shared/

2. If the source file is in shared/, making PharoV40.sources a sym link to
PharoV50.sources, still gives me the same error.

3. However, if the source files is in bin/, making PharoV40.sources a sym
link to PharoV50.sources does not give me the error. Success!

4. For additional experiment, I took Pharo5.0.image from Windows download,
and put it in shared/ (along with the changes file). It picks up
PharoV50.sources in either bin/ or shared/. I removed PharoV40.sources in
both places and still works fine.

5. I remove PharoV50.sources in bin/ and shared/, so now I don't have any
sources file. Using Pharo5.0.image from Windows, I got notification pharo
can't find PharoV50.sources file, yet, I don't get that
MessageNotUnderstood error.


I think the image version is different in Windows and Linux download. The
image from Windows download starts with a welcome window. The image from
Linux download doesn't. I don't know how to check the image version.

I can now run pharo5 and I'm happy. The Linux download needs updated VM and
image, I think.

On Thu, Oct 6, 2016 at 10:45 PM, Clément Bera <bera.clem...@gmail.com>
wrote:

> Hello
>
> What you describe (arg1 instead of string) means the source file is not
> present. Sources are required for some FFI calls. Take the PharoV50.sources
> file (you can find it here http://files.pharo.org/sources/) and put it in
> the same folder as your VM. It should solve the problem.
>
> Best,
>
> Clement
>
>
> On Fri, Oct 7, 2016 at 6:20 AM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>> Thanks, Bernardo. That fogbugz case is exactly the problem I'm having.
>>
>> This VM (pharo-vm-spur-swing.zip) is able to open Pharo 5.0 image from
>> Pharo download page. This is a good sign.
>>
>> Upon opening the image, I am, however, presented immediately with
>> 'MessageNotUnderstood: receiver of "/" is nil'. It's coming from
>> SystemSettingsPersistence class >> defaultPreferenceFileReference
>>
>> It boils down to
>> OSEnvironment#getEnv: 'HOME'
>>
>> a failure in building an FFI call. The FFI call function signature is
>> #( String getenv (String string) )
>>
>> The context object built from OSEnvironment#getEnv: gives answer 'arg1',
>> instead of 'string', to a call to #method#argumentNames. Down the road, an
>> IRMethod instance is trying to find the index for 'string' and can't find
>> any, because what is stored is 'arg1'.
>>
>> I'm out of my depth at this point, and this is a separate issue than not
>> being able to start the image. I have to think where I want to go from here.
>>
>> So, thank you for all of you, for the exceedingly quick and friendly help.
>>
>> Cheers!
>>
>> On Thu, Oct 6, 2016 at 5:42 PM, Bernardo Ezequiel Contreras <
>> vonbecm...@gmail.com> wrote:
>>
>>> Hold on,
>>>
>>>   There's also this issue
>>> https://pharo.fogbugz.com/f/cases/17353/build-spur-vm-for-de
>>> bian-old-libc
>>>
>>> where in one comment jan.vrany recommended his build
>>>
>>> https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/
>>>
>>> https://swing.fit.cvut.cz/jenkins/view/All/job/pharo-vm-spur
>>> -swing/lastSuccessfulBuild/artifact/pharo-vm-spur-swing.zip
>>>
>>> that i have used in debian wheezy with the old libc for quite a while. i
>>> don't use it anymore because im in jessie.
>>>
>>>
>>>
>>> On Thu, Oct 6, 2016 at 9:13 PM, Andreas Sunardi <a.suna...@gmail.com>
>>> wrote:
>>>
>>>> Thank you for the impressive quick response. Unfortunately, I have
>>>> older glibc. So now I'm struggling with compiling glibc 2.15 for 32 bit on
>>>> my 64 bit CentOS 6.5 machine. Not an easy thing to do.
>>>>
>>>> I'll try those VMs once I succeed in building this glibc
>>>>
>>>> On Thu, Oct 6, 2016 at 12:41 PM, Bernardo Ezequiel Contrera

Re: [Pharo-users] Pharo5 download for linux - interpreter cannot read image file

[Andreas Sunardi]

Thanks, Bernardo. That fogbugz case is exactly the problem I'm having.

This VM (pharo-vm-spur-swing.zip) is able to open Pharo 5.0 image from
Pharo download page. This is a good sign.

Upon opening the image, I am, however, presented immediately with
'MessageNotUnderstood: receiver of "/" is nil'. It's coming from
SystemSettingsPersistence class >> defaultPreferenceFileReference

It boils down to
OSEnvironment#getEnv: 'HOME'

a failure in building an FFI call. The FFI call function signature is
#( String getenv (String string) )

The context object built from OSEnvironment#getEnv: gives answer 'arg1',
instead of 'string', to a call to #method#argumentNames. Down the road, an
IRMethod instance is trying to find the index for 'string' and can't find
any, because what is stored is 'arg1'.

I'm out of my depth at this point, and this is a separate issue than not
being able to start the image. I have to think where I want to go from here.

So, thank you for all of you, for the exceedingly quick and friendly help.

Cheers!

On Thu, Oct 6, 2016 at 5:42 PM, Bernardo Ezequiel Contreras <
vonbecm...@gmail.com> wrote:

> Hold on,
>
>   There's also this issue
> https://pharo.fogbugz.com/f/cases/17353/build-spur-vm-for-debian-old-libc
>
> where in one comment jan.vrany recommended his build
>
> https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/
>
> https://swing.fit.cvut.cz/jenkins/view/All/job/pharo-vm-spur-swing/
> lastSuccessfulBuild/artifact/pharo-vm-spur-swing.zip
>
> that i have used in debian wheezy with the old libc for quite a while. i
> don't use it anymore because im in jessie.
>
>
>
> On Thu, Oct 6, 2016 at 9:13 PM, Andreas Sunardi <a.suna...@gmail.com>
> wrote:
>
>> Thank you for the impressive quick response. Unfortunately, I have older
>> glibc. So now I'm struggling with compiling glibc 2.15 for 32 bit on my 64
>> bit CentOS 6.5 machine. Not an easy thing to do.
>>
>> I'll try those VMs once I succeed in building this glibc
>>
>> On Thu, Oct 6, 2016 at 12:41 PM, Bernardo Ezequiel Contreras <
>> vonbecm...@gmail.com> wrote:
>>
>>> this
>>> http://files.pharo.org/vm/pharo-spur32/linux/latest.zip
>>>
>>> works pretty well in Debian GNU/Linux 8 Jessie
>>>
>>>
>>> On Thu, Oct 6, 2016 at 4:09 PM, Clément Bera <bera.clem...@gmail.com>
>>> wrote:
>>>
>>>> Thanks for reporting the problem.
>>>>
>>>> The error means the VM is incompatible with the image. There was a
>>>> change of image format in Pharo 5, so the package has likely an old VM
>>>> while the image has the new format, or the new VM while the image has the
>>>> old format.
>>>>
>>>> Someone will look into that problem in the incoming weeks. Most Pharo
>>>> maintainers are on Mac, we noticed recently that other OS were not
>>>> maintained carefully enough (We're sorry about that) and we're trying to
>>>> solve that problem.
>>>>
>>>> Meantime
>>>>
>>>> Can you try the latest VM from here (latest.zip):
>>>> http://files.pharo.org/vm/pharo-spur32/linux/
>>>>
>>>> Or if still failing, the latest VM from here (latest.zip):
>>>> http://files.pharo.org/vm/pharo/linux/
>>>>
>>>> One of these two VMs should work. Please tell me which one worked if
>>>> you try.
>>>>
>>>> Thanks & Regards
>>>>
>>>> Clement
>>>>
>>>> On Thu, Oct 6, 2016 at 8:44 PM, Bernardo Ezequiel Contreras <
>>>> vonbecm...@gmail.com> wrote:
>>>>
>>>>> i already submitted a similar issue
>>>>> https://pharo.fogbugz.com/f/cases/18221/This-interpreter-ver
>>>>> s-6505-cannot-read-image-file-vers-6521
>>>>>
>>>>> check it and see if it is the same
>>>>>
>>>>> On Thu, Oct 6, 2016 at 3:20 PM, Andreas Sunardi <a.suna...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I'm on CentOS 6.5 and I downloaded Pharo 5 for GNU/Linux w. libc <
>>>>>> 2.15 and for CentOS. Both won't start (I have no problem with Windows
>>>>>> version):
>>>>>>
>>>>>> $ pharo
>>>>>> This interpreter (vers. 6505) cannot read image file (vers. 6521).
>>>>>> Press CR to quit...
>>>>>>
>>>>>> I'm unable to find report or information about this issue on the web.
>>>>>> I think it was like this ~2 months ago as well. Is this a known issue?
>>>>>>
>>>>>> First time posting question in this mailing list, so I beg your
>>>>>> pardon if I break any mailing list rule.
>>>>>>
>>>>>> --
>>>>>> Andreas S
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bernardo E.C.
>>>>>
>>>>> Sent from a cheap desktop computer in South America.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Bernardo E.C.
>>>
>>> Sent from a cheap desktop computer in South America.
>>>
>>
>>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.
>

Re: [Pharo-users] Pharo5 download for linux - interpreter cannot read image file

[Andreas Sunardi]

Thank you for the impressive quick response. Unfortunately, I have older
glibc. So now I'm struggling with compiling glibc 2.15 for 32 bit on my 64
bit CentOS 6.5 machine. Not an easy thing to do.

I'll try those VMs once I succeed in building this glibc

On Thu, Oct 6, 2016 at 12:41 PM, Bernardo Ezequiel Contreras <
vonbecm...@gmail.com> wrote:

> this
> http://files.pharo.org/vm/pharo-spur32/linux/latest.zip
>
> works pretty well in Debian GNU/Linux 8 Jessie
>
>
> On Thu, Oct 6, 2016 at 4:09 PM, Clément Bera <bera.clem...@gmail.com>
> wrote:
>
>> Thanks for reporting the problem.
>>
>> The error means the VM is incompatible with the image. There was a change
>> of image format in Pharo 5, so the package has likely an old VM while the
>> image has the new format, or the new VM while the image has the old format.
>>
>> Someone will look into that problem in the incoming weeks. Most Pharo
>> maintainers are on Mac, we noticed recently that other OS were not
>> maintained carefully enough (We're sorry about that) and we're trying to
>> solve that problem.
>>
>> Meantime
>>
>> Can you try the latest VM from here (latest.zip):
>> http://files.pharo.org/vm/pharo-spur32/linux/
>>
>> Or if still failing, the latest VM from here (latest.zip):
>> http://files.pharo.org/vm/pharo/linux/
>>
>> One of these two VMs should work. Please tell me which one worked if you
>> try.
>>
>> Thanks & Regards
>>
>> Clement
>>
>> On Thu, Oct 6, 2016 at 8:44 PM, Bernardo Ezequiel Contreras <
>> vonbecm...@gmail.com> wrote:
>>
>>> i already submitted a similar issue
>>> https://pharo.fogbugz.com/f/cases/18221/This-interpreter-ver
>>> s-6505-cannot-read-image-file-vers-6521
>>>
>>> check it and see if it is the same
>>>
>>> On Thu, Oct 6, 2016 at 3:20 PM, Andreas Sunardi <a.suna...@gmail.com>
>>> wrote:
>>>
>>>> I'm on CentOS 6.5 and I downloaded Pharo 5 for GNU/Linux w. libc < 2.15
>>>> and for CentOS. Both won't start (I have no problem with Windows version):
>>>>
>>>> $ pharo
>>>> This interpreter (vers. 6505) cannot read image file (vers. 6521).
>>>> Press CR to quit...
>>>>
>>>> I'm unable to find report or information about this issue on the web. I
>>>> think it was like this ~2 months ago as well. Is this a known issue?
>>>>
>>>> First time posting question in this mailing list, so I beg your pardon
>>>> if I break any mailing list rule.
>>>>
>>>> --
>>>> Andreas S
>>>>
>>>
>>>
>>>
>>> --
>>> Bernardo E.C.
>>>
>>> Sent from a cheap desktop computer in South America.
>>>
>>
>>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.
>

[Pharo-users] Pharo5 download for linux - interpreter cannot read image file

[Andreas Sunardi]

I'm on CentOS 6.5 and I downloaded Pharo 5 for GNU/Linux w. libc < 2.15 and
for CentOS. Both won't start (I have no problem with Windows version):

$ pharo
This interpreter (vers. 6505) cannot read image file (vers. 6521).
Press CR to quit...

I'm unable to find report or information about this issue on the web. I
think it was like this ~2 months ago as well. Is this a known issue?

First time posting question in this mailing list, so I beg your pardon if I
break any mailing list rule.

--
Andreas S