Re: [Pharo-users] why is adding instance variables so slow?

[Tudor Girba]

Hi,

Please let’s move this discussion on pharo-dev. And keep going :)

Cheers,
Doru




> On Apr 14, 2017, at 12:09 PM, Denis Kudriashov  wrote:
> 
> 
> 2017-04-14 11:09 GMT+02:00 teso...@gmail.com :
> Hi, I think the problem was not clearly explained. This is the scenario that 
> is problematic. 
> This scenario does not happen in the new Spur implementation of forwarding, 
> but I think is happening in the old one.
> 
> 1. You have, let's say 3 instances of ClassA.
> 2. You add a new instance variable to ClassA. It produces
>2a. A new ClassAv2 is created with the instances variables of ClassA and 
> the newone
>2b. 3 Instances of ClassAv2 are created
>2c. The values of the instance variables of ClassA are copied to the ones 
> in ClassAv2 (the ones missing are left in nil).
>2d. The 3 instances of ClassA are becomed forward to the 3 instances of 
> ClassAv2
>2e. The ClassA is becomed forward ClassAv2
> 
> I still not see why my example not reflects all these steps. I checked also 
> scenario with class becoming:
> 
> c1 := Class1 new.
> c2 := Class2 new.
> c1 becomeForward: c2.
> Class1 becomeForward: Class2.
> Class2 allInstances "=>#(aClass2)"
> 
> It also works in Cog

--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

Re: [Pharo-users] Pharo 6.0 On windows crash while trying to run AthensFlakeDemo

[Ricardo Pacheco]

Thanks a lot Cyril. Worked very well!!


Regards,

Ricardo



--
View this message in context: 
http://forum.world.st/Pharo-6-0-On-windows-crash-while-trying-to-run-AthensFlakeDemo-tp4942238p4942265.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] [ANN] Prometheas : a Pharo wiki database

[Dimitris Chloupis]

I plan to embed it inside the playground and create a small Pharo API for
it. If I can I will provide access for it from the right click menu , like
do it and print it . It will take sometime but it's coming inside Pharo.
On Sat, 15 Apr 2017 at 20:43, Juraj Kubelka 
wrote:

> Nice!
>
> Could you provide the database content using JSON REST API? We could then
> have this as a part of Help Browser.
>
> Cheers,
> Juraj
>
> --
> Juraj Kubelka
>
> > El 14-04-2017, a las 09:30, Dimitris Chloupis 
> escribió:
> >
> > Part of my Discord bot as a goal was to add the ability to create
> database entries so that people can quickly find documentation.
> >
> > It was quite a challenge for me because I had to learn how heroku works,
> PostgreSQL and all the other things but I did it!!!
> >
> > In any discord channel you have now 3 commands !doc , !docadd ,
> !docremove
> >
> > 1) !doc 
> > search for a term in the documentation database
> > eg. !doc pharo
> >
> > 2) !docadd
> > add a new entry to the documentation database
> > eg. !docadd "pharo" "Pharo is a modern implementation of Smalltalk"
> "{'smalltalk','live coding','language'}" "{'squeak','IDE'}"
> >
> > 3)!docremove 
> > remove a term from database
> > eg. !docremove pharo
> >
> > tags , is for more complex searches in the future, links for sending
> users to relevant documentation
> >
> > I am also planning to give access to pharo users to the database from
> inside the pharo image, if its easy enough to use PostgreSQL from inside
> Pharo. Currently the bot is fully coded in python.
> >
> > The goal is not to create a full documentation but rather quick help
> tips for fast pointing to the right direction.
> >
> > This is also an invite to experience pharo devs and newcomers to start
> adding to this database.
> >
> > The database is PostgreSQL , one of the most populars, I have nothing
> against MongoDB , its just that it works better with heroku where I host
> the database. But if in the future find a way to do it for free I can move
> to MongoDB, but no promises.
> >
> > Anyway this was an excuse for me to learn database programming that I
> had abandoned 25 years ago (DBASE).
> >
> > So have fun with this :)
>
>

Re: [Pharo-users] Pharo 6.0 On windows crash while trying to run AthensFlakeDemo

[Cyril Ferlicot D.]

On 16/04/2017 00:11, Esteban Lorenzano wrote:
> 
> no, is a known issue, then. 
> maybe some launcher user can tell you how to update the vm?
> 
> Esteban
> 

Hi, Launcher user here!

Download the latest vm, put it were you can execute it (mine is in
C:\Program Files(x86)\Pharo\vmSpur for example, because I wanted it to
be in the same place than the launcher).

Then in PharoLauncher open the settings (button at the bottom right),
and you'll have a setting to set the vm path for spur images (Spur vm
full path). Select the .exe of the vm.

Don't forget to save your image (ctrl/alt + shift + s).

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] Pharo 6.0 On windows crash while trying to run AthensFlakeDemo

[Esteban Lorenzano]

> On 15 Apr 2017, at 23:50, Ricardo Pacheco  
> wrote:
> 
> Thanks a lot Esteban. This time everything worked OK and the demo run without
> a problem.
> 
> So the crash I was facing must be related to the VM included in the
> PharoLauncher.
> 
> Should I report it or do something about that? 

no, is a known issue, then. 
maybe some launcher user can tell you how to update the vm?

Esteban

> 
> Thanks,
> 
> Ricardo
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Pharo-6-0-On-windows-crash-while-trying-to-run-AthensFlakeDemo-tp4942238p4942259.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] Pharo 6.0 On windows crash while trying to run AthensFlakeDemo

[Ricardo Pacheco]

Thanks a lot Esteban. This time everything worked OK and the demo run without
a problem.

So the crash I was facing must be related to the VM included in the
PharoLauncher.

Should I report it or do something about that? 

Thanks,

Ricardo



--
View this message in context: 
http://forum.world.st/Pharo-6-0-On-windows-crash-while-trying-to-run-AthensFlakeDemo-tp4942238p4942259.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 On windows crash while trying to run AthensFlakeDemo

[Esteban Lorenzano]

you need to also download the sources: 

http://files.pharo.org/get-files/60/sources.zip

and put them aside of the image (or the vm), otherwise it will not work.

cheers, 
Esteban

ps: PharoLauncher is shipping with an old VM and most probably many things on 
Pharo 6.0 will not work. Hopefully there will be an update of the launcher 
after release...

> On 15 Apr 2017, at 23:37, Ricardo Pacheco  
> wrote:
> 
> Esteban,
> 
> My computer is using Windows 10.
> 
> I'm using the Pharo Launcher 0.2.11-2016.09.22 (as indicated in the
> README.txt or 3.0.20131220 as indicated in the Control panel's Programs and
> characteristics).
> (http://files.pharo.org/platform/launcher/pharo_installer-0.2.11.exe)
> 
> The image I was using was the latest Pharo 6.0 (Beta) downloaded today.
> http://files.pharo.org/image/60/latest.zip
> 
> With that combination I got the crash while trying to run: AthensFlakeDemo
> new openInWorld. 
> 
> As an additional test, I downloaded the VM version that you included
> (http://files.pharo.org/get-files/60/pharo-win-latest.zip) with the latest
> image as of today (60465), but got the following errors:
> First it complained abut the missing PharoV50.cources, but loaded Pharo.
> Then I tried to run the demo, but got the following error: Could not find
> accessor for variable named "aFormat"
> 
> FFICallout>>loaderForArgNamed:
> FFICallout>>loaderForArgNamed:indirectIndex:
> FFICallout>>argName:indirectIndex:type:ptrArity:
> FFIFunctionParser>>parseArgument
> FFIFunctionParser>>parseArguments
> FFIFunctionParser>>parseNamedFunction:
> FFICalloutMethodBuilder>>parseSignature:
> FFICalloutMethodBuilder>>generate
> FFICalloutMethodBuilder>>build:
> FFICalloutAPI>>function:module:
> AthensCairoSurface class(Object)>>nbCall:
> AthensCairoSurface class>>primImage:width:height:
> AthensCairoSurface class>>extent:format:
> AthensCairoSurface class>>extent:
> AthensFlakeDemo>>initialize
> AthensFlakeDemo class(Behavior)>>new
> UndefinedObject>>DoIt
> OpalCompiler>>evaluate
> RubSmalltalkEditor>>evaluate:andDo:
> RubSmalltalkEditor>>highlightEvaluateAndDo:
> [ textMorph textArea editor highlightEvaluateAndDo: arg1 action.
> textMorph shoutStyler style: textMorph text ] in [ textMorph textArea
>   handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: arg1
> action.
>   textMorph shoutStyler style: textMorph text ] ] in
> GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
> RubEditingArea(RubAbstractTextArea)>>handleEdit:
> [ textMorph textArea
>   handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: arg1
> action.
>   textMorph shoutStyler style: textMorph text ] ] in
> GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
> WorldState>>runStepMethodsIn:
> WorldMorph>>runStepMethods
> WorldState>>doOneCycleNowFor:
> WorldState>>doOneCycleFor:
> WorldMorph>>doOneCycle
> WorldMorph class>>doOneCycle
> [ [ WorldMorph doOneCycle.
> Processor yield.
> false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess
> [ self value.
> Processor terminateActive ] in BlockClosure>>newProcess
> 
> Please let me know if you need me to do some other test or if you want I can
> give you access t my computer using TeamViewer.
> 
> Regards.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Pharo-6-0-On-windows-crash-while-trying-to-run-AthensFlakeDemo-tp4942238p4942257.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] Pharo 6.0 On windows crash while trying to run AthensFlakeDemo

[Ricardo Pacheco]

Esteban,

My computer is using Windows 10.

I'm using the Pharo Launcher 0.2.11-2016.09.22 (as indicated in the
README.txt or 3.0.20131220 as indicated in the Control panel's Programs and
characteristics).
(http://files.pharo.org/platform/launcher/pharo_installer-0.2.11.exe)

The image I was using was the latest Pharo 6.0 (Beta) downloaded today.
http://files.pharo.org/image/60/latest.zip

With that combination I got the crash while trying to run: AthensFlakeDemo
new openInWorld. 

As an additional test, I downloaded the VM version that you included
(http://files.pharo.org/get-files/60/pharo-win-latest.zip) with the latest
image as of today (60465), but got the following errors:
First it complained abut the missing PharoV50.cources, but loaded Pharo.
Then I tried to run the demo, but got the following error: Could not find
accessor for variable named "aFormat"

FFICallout>>loaderForArgNamed:
FFICallout>>loaderForArgNamed:indirectIndex:
FFICallout>>argName:indirectIndex:type:ptrArity:
FFIFunctionParser>>parseArgument
FFIFunctionParser>>parseArguments
FFIFunctionParser>>parseNamedFunction:
FFICalloutMethodBuilder>>parseSignature:
FFICalloutMethodBuilder>>generate
FFICalloutMethodBuilder>>build:
FFICalloutAPI>>function:module:
AthensCairoSurface class(Object)>>nbCall:
AthensCairoSurface class>>primImage:width:height:
AthensCairoSurface class>>extent:format:
AthensCairoSurface class>>extent:
AthensFlakeDemo>>initialize
AthensFlakeDemo class(Behavior)>>new
UndefinedObject>>DoIt
OpalCompiler>>evaluate
RubSmalltalkEditor>>evaluate:andDo:
RubSmalltalkEditor>>highlightEvaluateAndDo:
[ textMorph textArea editor highlightEvaluateAndDo: arg1 action.
textMorph shoutStyler style: textMorph text ] in [ textMorph textArea
handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: arg1
action.
textMorph shoutStyler style: textMorph text ] ] in
GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
RubEditingArea(RubAbstractTextArea)>>handleEdit:
[ textMorph textArea
handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: arg1
action.
textMorph shoutStyler style: textMorph text ] ] in
GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
WorldMorph class>>doOneCycle
[ [ WorldMorph doOneCycle.
Processor yield.
false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess
[ self value.
Processor terminateActive ] in BlockClosure>>newProcess

Please let me know if you need me to do some other test or if you want I can
give you access t my computer using TeamViewer.

Regards.









--
View this message in context: 
http://forum.world.st/Pharo-6-0-On-windows-crash-while-trying-to-run-AthensFlakeDemo-tp4942238p4942257.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 On windows crash while trying to run AthensFlakeDemo

[Esteban Lorenzano]

it works for me (on Win7) so the rigor questions: 

1) VM version?
2) Image version?

If is not the same, can you try with this one: 
http://files.pharo.org/get-files/60/pharo-win-latest.zip and latest 6.0 image 
and tell me what happens?

thanks!
Esteban

> On 15 Apr 2017, at 17:50, Ricardo Pacheco  
> wrote:
> 
> I have been trying to run the AthensFlakeDemo in Pharo 6, updated as of
> today, in Windows 10 using this command:
> 
> AthensFlakeDemo new openInWorld.
> 
> Every time I run it, Pharo crashes.
> 
> 
> It looks to me like a bug, but before reporting a bug I want to ask you if I
> need to install/do something else prior to trying to run this demo.
> 
> Thanks
> 
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Pharo-6-0-On-windows-crash-while-trying-to-run-AthensFlakeDemo-tp4942238.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] Pharo6 server deployment and no home directory

[Juraj Kubelka]

> El 15-04-2017, a las 04:11, Holger Freyther  escribió:
> 
> 
>> On 15. Apr 2017, at 07:59, Holger Freyther  wrote:
>> 
>> 
>> * Why isn't the migration from Ston to Fuel more explicit?
>> * Why is "load" trying to save?
>> * Why is "ensure:" used instead of load?
>> * Not sure why "self preferences exists" seems to end in true?
> 
> Is there an option to not run startUp options at all or single step through 
> them? I have the suspicion that "exists" returns true while it should not. 
> Will see how to move forward.

Maybe GlobalIdentifier should not write and read anything if --no-preferences 
option is used. I will check this on Monday. I am without computer now. 

Juraj

> 
> holger
> 
> 
> Breakpoint 4, dir_EntryLookup (pathString=0x84cd258 
> "/home/build/.config/pharo", pathStringLength=25, nameString=0x84ce920 
> "org.pharo.gt.spotter.event.recorder.fuel", nameStringLength=40, 
>name=0xfffcb1bc "", nameLength=0xfffcb1ac, creationDate=0xfffcb1a4, 
> modificationDate=0xfffcb1b0, isDirectory=0xfffcb1a8, sizeIfFile=0xfffcb198, 
> posixPermissions=0xfffcb1b4, isSymlink=0xfffcb1b8)
>at 
> /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c:270
> 270in 
> /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c
> (gdb) p printCallStack()
> 0xfffd41a0 M UnixStore(DiskStore)>basicEntryAt: 0x842dd28: a(n) UnixStore
> 0xfffd41c0 M UnixStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x842dd28: a(n) 
> UnixStore
> 0xfffd41e4 M UnixStore(FileSystemStore)>exists: 0x842dd28: a(n) UnixStore
> 0xfffd4200 M FileSystem>exists: 0x842dd38: a(n) FileSystem
> 0xfffd421c M FileReference>exists 0x84c9d78: a(n) FileReference
> 0xfffd4234 M FileLocator(AbstractFileReference)>exists 0x84c32c8: a(n) 
> FileLocator
> 0xfffd4254 I 
> GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>load: 0x84a6d40: 
> a(n) GlobalIdentifierFuelPersistence
> 0xfffd4278 I 
> GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>ensure: 
> 0x84a6d40: a(n) GlobalIdentifierFuelPersistence
> 0xfffd429c I 
> GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>ensure: 
> 0x84a6d30: a(n) GlobalIdentifierStonPersistence
> 0xfffd42c0 I GlobalIdentifier>ensure 0x84a6510: a(n) GlobalIdentifier
> 0xfffd42e0 I GlobalIdentifier class>initializeUniqueInstance 0x9a2def0: a(n) 
> GlobalIdentifier class
> 0xfffd4300 I GlobalIdentifier class>uniqueInstance 0x9a2def0: a(n) 
> GlobalIdentifier class
> 0xfffccfd0 I SystemSettingsPersistence class>resumeSystemSettings 0x9a2d9f0: 
> a(n) SystemSettingsPersistence class

Re: [Pharo-users] [ANN] Prometheas : a Pharo wiki database

[Juraj Kubelka]

Nice!

Could you provide the database content using JSON REST API? We could then have 
this as a part of Help Browser. 

Cheers,
Juraj

--
Juraj Kubelka

> El 14-04-2017, a las 09:30, Dimitris Chloupis  
> escribió:
> 
> Part of my Discord bot as a goal was to add the ability to create database 
> entries so that people can quickly find documentation.
> 
> It was quite a challenge for me because I had to learn how heroku works, 
> PostgreSQL and all the other things but I did it!!!
> 
> In any discord channel you have now 3 commands !doc , !docadd , !docremove
> 
> 1) !doc 
> search for a term in the documentation database
> eg. !doc pharo 
> 
> 2) !docadd
> add a new entry to the documentation database
> eg. !docadd "pharo" "Pharo is a modern implementation of Smalltalk" 
> "{'smalltalk','live coding','language'}" "{'squeak','IDE'}"
> 
> 3)!docremove 
> remove a term from database
> eg. !docremove pharo
> 
> tags , is for more complex searches in the future, links for sending users to 
> relevant documentation
> 
> I am also planning to give access to pharo users to the database from inside 
> the pharo image, if its easy enough to use PostgreSQL from inside Pharo. 
> Currently the bot is fully coded in python.
> 
> The goal is not to create a full documentation but rather quick help tips for 
> fast pointing to the right direction. 
> 
> This is also an invite to experience pharo devs and newcomers to start adding 
> to this database. 
> 
> The database is PostgreSQL , one of the most populars, I have nothing against 
> MongoDB , its just that it works better with heroku where I host the 
> database. But if in the future find a way to do it for free I can move to 
> MongoDB, but no promises. 
> 
> Anyway this was an excuse for me to learn database programming that I had 
> abandoned 25 years ago (DBASE). 
> 
> So have fun with this :)  

[Pharo-users] best practices for using external files for testing

[Peter Uhnak]

Hi,

is there a common/best practice for using external files in tests?

In my specific case I am interested in git-based projects, where I have a big 
(~1MB) file stored in repository and I would like to use it in my tests.

For GitFileTree project I could presumably use the following to access it:

'OP-XMI' asPackage mcPackage workingCopy repositoryGroup remotes first 
directory / 'tests' / 'my-test-file.xmi'

This will retrieve the MCPackage of the Package and then retireve where it the 
repo is actually stored on the disk.

Are there better ways to do this? Could something similar be done with IceBerg?

(p.s. in theory I could compile the entire file (e.g. 1MB) to a method, but 
that is very ugly to me)

Thanks,
Peter

[Pharo-users] Pharo 6.0 On windows crash while trying to run AthensFlakeDemo

[Ricardo Pacheco]

I have been trying to run the AthensFlakeDemo in Pharo 6, updated as of
today, in Windows 10 using this command:

AthensFlakeDemo new openInWorld.

Every time I run it, Pharo crashes.


It looks to me like a bug, but before reporting a bug I want to ask you if I
need to install/do something else prior to trying to run this demo.

Thanks







--
View this message in context: 
http://forum.world.st/Pharo-6-0-On-windows-crash-while-trying-to-run-AthensFlakeDemo-tp4942238.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

On 15 April 2017 at 14:45, Esteban Lorenzano  wrote:

> this belongs to pharo-dev, please continue there :)
>

Looks to me like I should make a small replacement for mvm that is for nix.

Nix indeed does its own thing.

The downside is that it's restricted: the build runs in a sandbox, can't
touch the network, has to declare the sha256 of any dependencies that it
needs. Nothing - not one byte - is allowed to change from one build to the
next without being accounted for and that breaks the mvm script.

On the plus side it will supply all of the dependencies, with exactly the
expected version and exactly the expected build options, so that is less
work for mvm to do i.e. the third-party stuff should be taken care of
automatically.

I'm taking a poke now.

However, I must remind myself that this is a distraction, since I am trying
to get a _stable_ VM for Pharo 5.0. Somehow I have been swept up in this
enthusiasm for building the bleeding edge Pharo 6.0 VM that is not actually
of any practical use to me :-) although it will be in the near future.

Re: [Pharo-users] Pharo 6 snap install

[Esteban Lorenzano]

this belongs to pharo-dev, please continue there :)


> On 15 Apr 2017, at 14:25, Alistair Grant  wrote:
> 
> On Sat, Apr 15, 2017 at 02:14:26PM +0200, Luke Gorrie wrote:
>> On 15 April 2017 at 11:53, Alistair Grant  wrote:
>> 
>>(actually, I'm not sure why you're bothering since 6 should
>>be out before the end of the month, but that's your choice :-)).
>> 
>> 
>> I just want something stable and reasonably modern for running existing
>> applications and building new ones.
>> 
>> If that means waiting for Pharo 6.0 release then that is okay with me.
>> 
>> 
>>The (V6) linux install relies on a number of bash scripts to launch pharo
>>(bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo).  How are you producing
>>these, or are you doing something else?
>> 
>> 
>> Here is where those scripts are generated in the existing pharo-vm packaging:
>> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/pharo/vm/
>> build-vm.nix#L50-L70
> 
> Ahh, so Nix is doing its own thing, not using the ZeroConf scripts.
> 
> 
>> (I didn't write the nix packaging code but I have volunteered to maintain it 
>> so
>> if it's out of date then I should fix that.)
> 
> It will be for V6.  Esteban has changed the scripts to ensure that Pharo
> versions of libraries are loaded (from memory)(this is also partly why I
> would like to use the full build process).
> 
> 
>>git clone https://github.com/pharo-project/pharo-vm.git 
>> 
>>git checkout 
>>cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
>>./mvm
>>--
>> 
>>BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my
>>experience is that it is significantly less stable than the latest
>>binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb
>> 
>> 
>> This is really the bleeding edge :-) both of those commits were pushed within
>> the past three days!
> 
> Yep, V6 is still in testing. :-)
> 
> Cheers,
> Alistair

Re: [Pharo-users] Pharo6 ombu-session files in pharo-local

[Stephane Ducasse]

Yes this is what we want to do to help the deployment aspect of Pharo. But
this is work in perspective.
Once we will have something we will ask you to try and let us know if this
is working for you.

Laste year I started to check because I wanted a silent Pharo: no hidden
writing on files but the changes got lost.

On Sat, Apr 15, 2017 at 10:24 AM, Holger Freyther 
wrote:

> Hi,
>
> as part of moving a test image from Pharo5 to Pharo6 I also noticed that
> on each start a new "ombu-session" folder will be created (and never
> cleaned up). For a server-side deployment this is quite unfortunate as I
> want/need to use a fixed amount of disk space.
>
> I think Norbert has similar concerns with this feature. We are using
> "image-launch" to run the image and then either
> systemd|monit|runit|kubernetes will execute (and re-execute) image-launch.
> So potentially many many folders are created and never used.
>
> On deployments with many images, it is rare to make online changes and
> even more rare to try to recover them. Would it be possible to create the
> underlying storage or disable it completely?
>
>
> thank you
> holger
>

Re: [Pharo-users] How can I set the SmaccDebugParser in Moose

[Stephane Ducasse]

John? How do we activate the Smacc debugger in moose?

On Fri, Apr 14, 2017 at 10:36 PM, Andrei Chis 
wrote:

> Not exactly sure how to do to it because I never used it.
> From what I see in SmaCCParserDebugger>>handlesContext: if you have in
> the stack a context created by  SmaCCParser>>parse you should have a
> 'SmaCCParser' button at the top right of the window. But maybe John can
> provide you with more details.
>
> Cheers,
> Andrei
>
>
> On Fri, Apr 14, 2017 at 2:45 PM, Stephane Ducasse  > wrote:
>
>> Andrei?
>> Help?
>>
>>
>>
>> On Fri, Apr 7, 2017 at 3:14 PM, Stephane Ducasse > > wrote:
>>
>>> Hi
>>>
>>> I found the SmaCCParserDebugger and I found the debug menu in the Smacc
>>> tool.
>>> Now I get a GT and byteCode debugger but I do not find a way to make the
>>> new debugger actif.
>>>
>>> Stef
>>>
>>
>>
>

Re: [Pharo-users] Pharo 6 snap install

[Alistair Grant]

On Sat, Apr 15, 2017 at 02:14:26PM +0200, Luke Gorrie wrote:
> On 15 April 2017 at 11:53, Alistair Grant  wrote:
> 
> (actually, I'm not sure why you're bothering since 6 should
> be out before the end of the month, but that's your choice :-)).
> 
> 
> I just want something stable and reasonably modern for running existing
> applications and building new ones.
> 
> If that means waiting for Pharo 6.0 release then that is okay with me.
> 
> 
> The (V6) linux install relies on a number of bash scripts to launch pharo
> (bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo).  How are you producing
> these, or are you doing something else?
> 
> 
> Here is where those scripts are generated in the existing pharo-vm packaging:
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/pharo/vm/
> build-vm.nix#L50-L70

Ahh, so Nix is doing its own thing, not using the ZeroConf scripts.


> (I didn't write the nix packaging code but I have volunteered to maintain it 
> so
> if it's out of date then I should fix that.)

It will be for V6.  Esteban has changed the scripts to ensure that Pharo
versions of libraries are loaded (from memory)(this is also partly why I
would like to use the full build process).


> git clone https://github.com/pharo-project/pharo-vm.git
> git checkout 
> cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
> ./mvm
> --
> 
> BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my
> experience is that it is significantly less stable than the latest
> binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb
> 
> 
> This is really the bleeding edge :-) both of those commits were pushed within
> the past three days!

Yep, V6 is still in testing. :-)

Cheers,
Alistair

Re: [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

On 15 April 2017 at 11:53, Alistair Grant  wrote:

> (actually, I'm not sure why you're bothering since 6 should
> be out before the end of the month, but that's your choice :-)).
>

I just want something stable and reasonably modern for running existing
applications and building new ones.

If that means waiting for Pharo 6.0 release then that is okay with me.

The (V6) linux install relies on a number of bash scripts to launch pharo
> (bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo).  How are you producing
> these, or are you doing something else?
>

Here is where those scripts are generated in the existing pharo-vm
packaging:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/
development/pharo/vm/build-vm.nix#L50-L70

(I didn't write the nix packaging code but I have volunteered to maintain
it so if it's out of date then I should fix that.)

git clone https://github.com/pharo-project/pharo-vm.git
> git checkout 
> cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
> ./mvm
> --
>
> BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my
> experience is that it is significantly less stable than the latest
> binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb
>

This is really the bleeding edge :-) both of those commits were pushed
within the past three days!

I will take a look at the ./mvm script now.

Re: [Pharo-users] Pharo 6 snap install

[Alistair Grant]

On Sat, Apr 15, 2017 at 09:53:49AM +, Alistair Grant wrote:
> 
> If you just want to build a single V6 pharo executable (no scripts,
> linux 64 bit in the example below):
> 
> --
> #!/bin/bash
> set -e
> 
> git clone https://github.com/pharo-project/pharo-vm.git
> git checkout 
> cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
> ./mvm
> --

And remembered that this will produce dragons, hopefully this will work:

--
#!/bin/bash
set -e

git clone https://github.com/pharo-project/pharo-vm.git
git checkout 
cd pharo-vm
../genVersion.sh
cd opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
./mvm
--

where genVersion.sh is:

--
#! /bin/bash

echo "`cat opensmalltalk-vm/platforms/Cross/vm/sqSCCSVersion.h | 
opensmalltalk-vm/.git_filters/RevDateURL.smudge`" > 
opensmalltalk-vm/platforms/Cross/vm/sqSCCSVersion.h
echo "`cat opensmalltalk-vm/platforms/Cross/plugins/sqPluginsSCCSVersion.h | 
opensmalltalk-vm/.git_filters/RevDateURL.smudge`" > 
opensmalltalk-vm/platforms/Cross/plugins/sqPluginsSCCSVersion.h
--

In case the mailer does formatting: there are only two lines of code,
each beginning with echo.

Cheers,
Alistair

Re: [Pharo-users] Pharo 6 snap install

[K K Subbu]

On Friday 14 April 2017 03:39 PM, Luke Gorrie wrote:


- The latest Pharo VM source release is compatible with the latest Pharo
image.


This is too strong a condition. For the OS, an image is just a 
filesystem within a file. It is sufficient if the VM does not use the 
same executable name if it cannot execute the same image. After all, the 
VM is a machine and is not likely evolve as rapidly as the image it 
runs. If it cannot handle an image format then it should not reuse that 
VM's name.


Linux already supports binfmt_misc fs to handle such images. VMMaker can 
generate magic(5) file in addition to src/* files from which package 
post-installers can register multiple interpreters in 
/proc/sys/fs/binfmt_misc/. Python and Qemu use this to run different 
bytecode and instruction sets.


BTW, I am attaching a magic pattern file generated automatically from 
ImageFormat class in VMMaker image to illustrate my point.


Regards .. Subbu
# Smalltalk image file formats
0   lelong  6502Smalltalk image V3 32b  (%d)
!:mime application/squeak-image
0   belong  6502Smalltalk image V3 32b  (%d)
!:mime application/squeak-image
0   lelong  6504Smalltalk image V3 32b +C (%d)
!:mime application/cog-image
0   belong  6504Smalltalk image V3 32b +C (%d)
!:mime application/cog-image
0   lelong  68000   Smalltalk image V3 64b  (%d)
!:mime application/squeak64-image
4   belong  68000   Smalltalk image V3 64b  (%d)
!:mime application/squeak64-image
0   lelong  68002   Smalltalk image V3 64b +C (%d)
!:mime application/cog64-image
4   belong  68002   Smalltalk image V3 64b +C (%d)
!:mime application/cog64-image
0   lelong  6505Smalltalk image V3 32b +C+NF (%d)
!:mime application/cog-image
0   belong  6505Smalltalk image V3 32b +C+NF (%d)
!:mime application/cog-image
0   lelong  68003   Smalltalk image V3 64b +C+NF (%d)
!:mime application/cog64-image
4   belong  68003   Smalltalk image V3 64b +C+NF (%d)
!:mime application/cog64-image
0   lelong  6521Smalltalk image Spur 32b +C+NF (%d)
!:mime application/spur-image
0   belong  6521Smalltalk image Spur 32b +C+NF (%d)
!:mime application/spur-image
0   lelong  68019   Smalltalk image Spur 64b +C+NF (%d)
!:mime application/spur64-image
4   belong  68019   Smalltalk image Spur 64b +C+NF (%d)
!:mime application/spur64-image
0   lelong  68021   Smalltalk image Spur 64b +C+NF+Tag (%d)
!:mime application/spur64-image
4   belong  68021   Smalltalk image Spur 64b +C+NF+Tag (%d)
!:mime application/spur64-image

Re: [Pharo-users] Pharo 6 snap install

[Alistair Grant]

Hi Luke,

On Sat, Apr 15, 2017 at 10:34:31AM +0200, Luke Gorrie wrote:
> On 15 April 2017 at 10:08, Alistair Grant  wrote:
> 
> How about trying:
> 
> $ git clone https://github.com/pharo-project/pharo-vm.git
> $ cd pharo-vm
> $ git checkout b8ec25a570d7539653e1d793e97609adb509aaed
> 
> and build that?  It should be the source code for the binary VM on
> get.pharo.org.
> 
> 
> First, thanks for taking the time to play along with me here, it really helps
> to make sure I don't hold things up due to a misunderstanding.

No problem.  My answers below relate to Pharo 6, I haven't tried 
building V5 (actually, I'm not sure why you're bothering since 6 should 
be out before the end of the month, but that's your choice :-)).


> Grabbing the source directly from Git is attractive if 
> (a) I know that I am choosing a good version and 

The Pharo50-stable tag points to this commit.  Presumably it is kept at 
the latest build, but someone else would have to confirm.

If the same isn't already done for V6, I'll certainly be pushing for it 
(either a moving tag, or release numbers).


> (b) I am able to build it in a good way.
> 
> Seems like a workable solution to (a) is to periodically check for a new 
> binary
> release, work out which commit it is based off, and build that. This seems
> fairly reasonable and is probably also possible to automate. (I suppose you 
> got
> the commit-id from --version or from checking Jenkins.)
> 
> I see (b) as problematic though. The source tarball releases have a simple
> build procedure ("make") while the Git checkouts require a more involved one
> (bootstrapping the VM from an existing Pharo image.) So I would need to revise
> the nix build scripts quite a bit if I want to build from Git instead of the
> tarballs. However, it seems that on the master branch last week the VM build
> procedure has been reworked so that it is _not_ necessary to run the
> bootstrapping procedure anymore, which sounds great to me, except that I
> understand this new build procedure to be quite bleeding edge and not yet
> documented or used for a binary release (it's not included in the commit that
> you cite above.)
> 
> So what to make of all that? Just right now I see only bad alternatives:
> sticking with the source release means not supporting Pharo 5.0, updating the
> build scripts to do bootstrapping takes effort and is already obsoleted by
> changes on the VM master branch, and shipping the VM master branch means 
> making
> a pseudo-release without any QA and potentially causing problems for people
> downstream (there are lots of commits landing on that branch and I have no 
> idea
> which ones are important/stable.)
> 
> So the most reasonable course of action from my point of view seems to be to
> sit and wait for a better solution to come along e.g. a new source release of
> the VM or a "blessed" Git commit ID that includes the updated build scripts.
> The downside is that meanwhile NixOS users can't run the 5.0 image. Could be
> that Pharo 6.0 will resolve this and that is fine for me -- but of course I'd
> take a solution sooner if there is a simple one.

I agree that the build seems a bit messy at the moment.  Given how busy 
everyone is with the release, I'm keeping quiet for now, but afterwards 
I'd like to get my snap package completely automated.  Personally, I 
think getting the build working reliably from git is worth the trouble 
(can test any commit, test patches before submitting pull request, etc).

The (V6) linux install relies on a number of bash scripts to launch pharo 
(bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo).  How are you producing 
these, or are you doing something else?

I'd prefer to get the build using the image working properly as that is 
where these scripts are generated (I think).

If you just want to build a single V6 pharo executable (no scripts,
linux 64 bit in the example below):

--
#!/bin/bash
set -e

git clone https://github.com/pharo-project/pharo-vm.git
git checkout 
cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
./mvm
--

BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my 
experience is that it is significantly less stable than the latest 
binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb

Cheers,
Alistair

Re: [Pharo-users] Pharo6 ombu-session files in pharo-local

[Cyril Ferlicot D.]

Le 15/04/2017 à 10:24, Holger Freyther a écrit :
> Hi,
> 
> as part of moving a test image from Pharo5 to Pharo6 I also noticed that on 
> each start a new "ombu-session" folder will be created (and never cleaned 
> up). For a server-side deployment this is quite unfortunate as I want/need to 
> use a fixed amount of disk space.
> 
> I think Norbert has similar concerns with this feature. We are using 
> "image-launch" to run the image and then either 
> systemd|monit|runit|kubernetes will execute (and re-execute) image-launch. So 
> potentially many many folders are created and never used.
> 
> On deployments with many images, it is rare to make online changes and even 
> more rare to try to recover them. Would it be possible to create the 
> underlying storage or disable it completely?
> 
> 
> thank you
>   holger
> 

Hi Holger,

`ombu-session ` is the directory used by epicea to log all the changes
of the application by session of coding. It will contains the same
informations that the .changes file.

It cannot be cleanup because we do not want to lose those logs since we
might need them to recover lost changes.

In deployment you can disable Epicea.

`EpMonitor current disable`

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

[Cyril Ferlicot D.]

Le 15/04/2017 à 08:14, Nicolai Hess a écrit :

> How to reproduce:
> 
> "Create a Trait"
> Trait named:#TRoot
> uses:{} package:'MyPackage'.
> 
> "Add some methods"
> (Smalltalk classOrTraitNamed:'TRoot') compile:'trootA'.
> (Smalltalk classOrTraitNamed:'TRoot') compile:'trootB'.
> (Smalltalk classOrTraitNamed:'TRoot') compile:'trootC'.
> 
> "Create another Trait using this Trait"
> Trait named:#TRootUser
> uses:{(Smalltalk classOrTraitNamed:'TRoot')} package:'MyPackage'.
> 
> "Add more methods.
> Note, methods still added on TRoot"
> (Smalltalk classOrTraitNamed:'TRoot') compile:'troot1'.
> (Smalltalk classOrTraitNamed:'TRoot') compile:'troot2'.
> (Smalltalk classOrTraitNamed:'TRoot') compile:'troot3'.
> 
> "Trait TRootUser should not have any local methods"
> (RPackageOrganizer default packageNamed:'MyPackage') methods inspect.
> 
> 
> Exprected outcome:
> All methods are only defined on Trait TRoot.
> Actual  outcome:
> Methods from TRoot added before creating the Trait that uses TRoot, are
> *added* to the using trait, but only in the RPackage, the trait, *using*
> TRoot still *knows* that it does not hold any
> local methods:
> 
> TRootUser localMethods.
> ->  "#()"
> TRoot localMethods
> -> "{TRoot>>#troot1. TRoot>>#troot3. TRoot>>#trootC. TRoot>>#trootB.
> TRoot>>#trootA. TRoot>>#troot2}"
> 
> Now, if we store a snapshot of this package, the RGMethodDefinitions,
> wrongly assigned to trait TRootUser, will be flattened into that trait.
> 
> 

This is cool that it was found with a reproducible case. We got the same
problem at Synectique.

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

On 15 April 2017 at 10:08, Alistair Grant  wrote:

> How about trying:
>
> $ git clone https://github.com/pharo-project/pharo-vm.git
> $ cd pharo-vm
> $ git checkout b8ec25a570d7539653e1d793e97609adb509aaed
>
> and build that?  It should be the source code for the binary VM on
> get.pharo.org.
>

First, thanks for taking the time to play along with me here, it really
helps to make sure I don't hold things up due to a misunderstanding.

Grabbing the source directly from Git is attractive if (a) I know that I am
choosing a good version and (b) I am able to build it in a good way.

Seems like a workable solution to (a) is to periodically check for a new
binary release, work out which commit it is based off, and build that. This
seems fairly reasonable and is probably also possible to automate. (I
suppose you got the commit-id from --version or from checking Jenkins.)

I see (b) as problematic though. The source tarball releases have a simple
build procedure ("make") while the Git checkouts require a more involved
one (bootstrapping the VM from an existing Pharo image.) So I would need to
revise the nix build scripts quite a bit if I want to build from Git
instead of the tarballs. However, it seems that on the master branch last
week the VM build procedure has been reworked so that it is _not_ necessary
to run the bootstrapping procedure anymore, which sounds great to me,
except that I understand this new build procedure to be quite bleeding edge
and not yet documented or used for a binary release (it's not included in
the commit that you cite above.)

So what to make of all that? Just right now I see only bad alternatives:
sticking with the source release means not supporting Pharo 5.0, updating
the build scripts to do bootstrapping takes effort and is already obsoleted
by changes on the VM master branch, and shipping the VM master branch means
making a pseudo-release without any QA and potentially causing problems for
people downstream (there are lots of commits landing on that branch and I
have no idea which ones are important/stable.)

So the most reasonable course of action from my point of view seems to be
to sit and wait for a better solution to come along e.g. a new source
release of the VM or a "blessed" Git commit ID that includes the updated
build scripts. The downside is that meanwhile NixOS users can't run the 5.0
image. Could be that Pharo 6.0 will resolve this and that is fine for me --
but of course I'd take a solution sooner if there is a simple one.

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

[Hilaire]

Indeed that's it. Adding methods after the second traits was created
shows up the bug. I open a ticket.

https://pharo.fogbugz.com/f/cases/19938/Traits-methods-flattened


Le 15/04/2017 à 08:14, Nicolai Hess a écrit :
> 
> How to reproduce:
> 

-- 
Dr. Geo
http://drgeo.eu

[Pharo-users] Pharo6 ombu-session files in pharo-local

[Holger Freyther]

Hi,

as part of moving a test image from Pharo5 to Pharo6 I also noticed that on 
each start a new "ombu-session" folder will be created (and never cleaned up). 
For a server-side deployment this is quite unfortunate as I want/need to use a 
fixed amount of disk space.

I think Norbert has similar concerns with this feature. We are using 
"image-launch" to run the image and then either systemd|monit|runit|kubernetes 
will execute (and re-execute) image-launch. So potentially many many folders 
are created and never used.

On deployments with many images, it is rare to make online changes and even 
more rare to try to recover them. Would it be possible to create the underlying 
storage or disable it completely?


thank you
holger

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

[Hilaire]

Great! It is nice you can reproduce it, because my attempt failed with
the exemple package attached.

Le 15/04/2017 à 08:14, Nicolai Hess a écrit :
> 
> Le 14/04/2017 à 15:24, Denis Kudriashov a écrit :
> >
> > Could you create example set of packages to reproduce problem? (to be
> > not dependant on your private code)
> >
> 
> 
> How to reproduce:
> 

-- 
Dr. Geo
http://drgeo.eu


Traits-Bug-hf.4.mcz
Description: Binary data

Re: [Pharo-users] Pharo 6 snap install

[Alistair Grant]

On Sat, Apr 15, 2017 at 09:50:29AM +0200, Luke Gorrie wrote:
> On 15 April 2017 at 09:12, Alistair Grant  wrote:
> 
> On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote:
> > The latest stable image release is Pharo-50771.image.
> > The latest stable VM source release is pharo-vm-2016.02.18.
> > These two releases are not compatible: This interpreter (vers. 6505)
> cannot
> > read image file (vers. 6521).
> 
> Is this from a VM you built yourself?
> 
> 
> This is a VM built from source during packaging for NixOS Linux.
> 
> 
>   What's the output of:
> 
> $ pharo --version
> 
> 
> Here it is:
> 
> 
> $ pharo-vm-nox --version
> 3.9-7 #1 Tue Mar 28 16:26:45 UTC 2017 gcc 5.4.0 [Production ITHB VM]
> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  5 2016
> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  5 2016
> https://github.com/pharo-project/pharo-vm.git Commit:
> ba1aa855f546b084ec0ebdeb85a36f2352f97b49 Date: 2016-02-18 17:17:13 +0100
> By: Esteban Lorenzano  Jenkins build #15040
> Linux localhost 4.4.23 #1-NixOS SMP Fri Sep 30 08:20:43 UTC 2016 i686 GNU/
> Linux
> plugin path: /nix/store/
> 5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/
> pharo-vm-i386-2016.02.18/ [default: /nix/store/
> 5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/
> pharo-vm-i386-2016.02.18/]
> 
> 
> Note that the date 2016-02-18 corresponds with the latest non-spur source
> tarball release at http://files.pharo.org/vm/src/vm-unix-sources/
> 
> 
> I just downloaded:
> 
> $ curl http://get.pharo.org/50+vm | bash
> 
> And it started without problem.
> 
> 
> I *think* the difference is that you are downloading the VM as a binary and I
> am downloading it as source code, and we get different versions because
> pharo.org is regularly shipping updated binaries but not updating the source
> code releases at the same time. So the source releases lag behind over time 
> and
> now it's at the point that they can't run the 5.0 image.

How about trying:

$ git clone https://github.com/pharo-project/pharo-vm.git
$ cd pharo-vm
$ git checkout b8ec25a570d7539653e1d793e97609adb509aaed

and build that?  It should be the source code for the binary VM on
get.pharo.org.

Cheers,
Alistair

Re: [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

On 15 April 2017 at 09:12, Alistair Grant  wrote:

> On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote:
> > The latest stable image release is Pharo-50771.image.
> > The latest stable VM source release is pharo-vm-2016.02.18.
> > These two releases are not compatible: This interpreter (vers. 6505)
> cannot
> > read image file (vers. 6521).
>
> Is this from a VM you built yourself?


This is a VM built from source during packaging for NixOS Linux.

  What's the output of:
>
> $ pharo --version
>

Here it is:

$ pharo-vm-nox --version
3.9-7 #1 Tue Mar 28 16:26:45 UTC 2017 gcc 5.4.0 [Production ITHB VM]
NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  5 2016
NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  5 2016
https://github.com/pharo-project/pharo-vm.git Commit:
ba1aa855f546b084ec0ebdeb85a36f2352f97b49 Date: 2016-02-18 17:17:13 +0100
By: Esteban Lorenzano  Jenkins build #15040
Linux localhost 4.4.23 #1-NixOS SMP Fri Sep 30 08:20:43 UTC 2016 i686
GNU/Linux
plugin path:
/nix/store/5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/pharo-vm-i386-2016.02.18/
[default:
/nix/store/5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/pharo-vm-i386-2016.02.18/]


Note that the date 2016-02-18 corresponds with the latest non-spur source
tarball release at http://files.pharo.org/vm/src/vm-unix-sources/

I just downloaded:
>
> $ curl http://get.pharo.org/50+vm | bash
>
> And it started without problem.
>

I *think* the difference is that you are downloading the VM as a binary and
I am downloading it as source code, and we get different versions because
pharo.org is regularly shipping updated binaries but not updating the
source code releases at the same time. So the source releases lag behind
over time and now it's at the point that they can't run the 5.0 image.

Re: [Pharo-users] Pharo 6 snap install

[Alistair Grant]

On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote:
> On 14 April 2017 at 22:20, Stephane Ducasse  wrote:
> 
> This is what we always have when we release and we freeze it. 
> The vm 60 will be compatible with latest pharo 60 image. 
> 
> 
> It is possible that I have misunderstood the whole situation and there is no
> problem at all. That would be awesome. Let's check :-) here is my 
> understanding
> of the state of the world right now:

I think so...

> The latest stable image release is Pharo-50771.image.
> The latest stable VM source release is pharo-vm-2016.02.18.
> These two releases are not compatible: This interpreter (vers. 6505) cannot
> read image file (vers. 6521).

Is this from a VM you built yourself?  What's the output of:

$ pharo --version

I just downloaded:

$ curl http://get.pharo.org/50+vm | bash

And it started without problem.

The VM is dated Wed May  4 11:54:28 CEST 2016.


> So the problem is that if a distribution packages the latest VM source release
> then the users won't be able to run the Pharo 5 VM that they download from
> pharo.org or via the pharo-launcher image.
> 
> Is that correct? If so that's fine and hopefully we can fix it for Pharo 6.0.
> But if I am misunderstanding and a fix is available today that would also be
> good to know.
> 
> I am looking for the "latest VM source release" in http://files.pharo.org/vm/
> src/vm-unix-sources/ and assuming that non-spur is the stable option for
> pre-6.0 images.

Occasional bugs aside, my understanding is that V5.0 VMs will work with
V5.0 images.  They should at least start up OK.

Cheers,
Alistair

Re: [Pharo-users] Pharo6 server deployment and no home directory

[Holger Freyther]

> On 15. Apr 2017, at 07:59, Holger Freyther  wrote:
> 
> 
> * Why isn't the migration from Ston to Fuel more explicit?
> * Why is "load" trying to save?
> * Why is "ensure:" used instead of load?
> * Not sure why "self preferences exists" seems to end in true?

Is there an option to not run startUp options at all or single step through 
them? I have the suspicion that "exists" returns true while it should not. Will 
see how to move forward.

holger


Breakpoint 4, dir_EntryLookup (pathString=0x84cd258 
"/home/build/.config/pharo", pathStringLength=25, nameString=0x84ce920 
"org.pharo.gt.spotter.event.recorder.fuel", nameStringLength=40, 
name=0xfffcb1bc "", nameLength=0xfffcb1ac, creationDate=0xfffcb1a4, 
modificationDate=0xfffcb1b0, isDirectory=0xfffcb1a8, sizeIfFile=0xfffcb198, 
posixPermissions=0xfffcb1b4, isSymlink=0xfffcb1b8)
at 
/home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c:270
270 in 
/home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c
(gdb) p printCallStack()
0xfffd41a0 M UnixStore(DiskStore)>basicEntryAt: 0x842dd28: a(n) UnixStore
0xfffd41c0 M UnixStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x842dd28: a(n) 
UnixStore
0xfffd41e4 M UnixStore(FileSystemStore)>exists: 0x842dd28: a(n) UnixStore
0xfffd4200 M FileSystem>exists: 0x842dd38: a(n) FileSystem
0xfffd421c M FileReference>exists 0x84c9d78: a(n) FileReference
0xfffd4234 M FileLocator(AbstractFileReference)>exists 0x84c32c8: a(n) 
FileLocator
0xfffd4254 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>load: 
0x84a6d40: a(n) GlobalIdentifierFuelPersistence
0xfffd4278 I 
GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d40: 
a(n) GlobalIdentifierFuelPersistence
0xfffd429c I 
GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d30: 
a(n) GlobalIdentifierStonPersistence
0xfffd42c0 I GlobalIdentifier>ensure 0x84a6510: a(n) GlobalIdentifier
0xfffd42e0 I GlobalIdentifier class>initializeUniqueInstance 0x9a2def0: a(n) 
GlobalIdentifier class
0xfffd4300 I GlobalIdentifier class>uniqueInstance 0x9a2def0: a(n) 
GlobalIdentifier class
0xfffccfd0 I SystemSettingsPersistence class>resumeSystemSettings 0x9a2d9f0: 
a(n) SystemSettingsPersistence class