September 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] State of SVG importer

by Igor Stasenko

On 29 September 2013 21:40, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Sep 29, 2013, at 9:30 PM, Hilaire Fernandes < > hilaire.fernandes(a)gmail.com> wrote: > > > Le 29/09/2013 21:17, Hilaire Fernandes a Ã©crit : > >> You may want to fix it for earlier tester. > > > > I manage to load the needed package by hand. > > But there is a missing class AthensCairoSurface. > > Please could you check on a fresh pharo 2.0 the configuration and fix it? > > I think that we should work on pharo 30. We do not have the resource to > maintain it on 20. > First it should work on 30. > > yes , there are multiple important updates which made to NB which making current version of Athens incompatible with pharo 2.0. The last version of Athens, compatible with 2.0 image is 2.1. ConfigurationOfAthens loadVersion: '2.1'. and to load svg package use: (ConfigurationOfAthens project version: '2.1') load: 'SVG' (but you need to load XML support first). And since you planning to work on SVG, i recommend you to pick up the latest pharo 3.0 image where athens already installed and work there, on development version of Athens.

Sept. 30, 2013

Primitives lookupEntryIn:index: fails on mac with the latest vm

by Andrei Chis

Hi, I was trying to merge a slice into the latest Pharo 3 image when I got a FileSystemError in MacStore(DiskStore)>>basicEntry:path:nodesDo:. This happens as 'Primitives lookupEntryIn:index:' returns #badDirectoryPath. The bad part is that it goes into an infinite loop and blocks the image. The same scenario works ok with the stable pharo vm. I can reproduce this by going to the PharoInbox choosing a package that is not merged (let's say NativeBoost-Win32-CamilloBruni.42) and hit merge. If no error appears the first time, close the merge window and select merge again. For almost all packages, after a few time I get the previous error. Has anyone encountered this before? Might it be related to https://pharo.fogbugz.com/f/cases/7559 ? Cheers, Andrei

Sept. 30, 2013

About Soup and XML

by StÃ©phane Ducasse

Hi paul I do not think that it is wise in the long term to have split repository. For example it does not really make sense to me to have a part of XMLSupport in your private project and another part in squeaksource. So we should - update soup to use XMLReader in SmalltalkHub - and publish gemstone package in their corresponding base project Managing conifguration is complex enough to make things as simple as we can. So are you interested in helping? Stef baseline14: spec <version: '1.4-baseline'> spec for: #squeakCommon do: [ spec blessing: #baseline. spec description: 'Migrated to SmalltalkHub'. spec author: 'StephaneDucasse'. spec timestamp: '21/02/2013'. spec repository: 'http://www.smalltalkhub.com/mc/PharoExtras/Soup/main'. spec package: 'Soup-Core' with: [ spec requires: 'XMLSupport' ]; package: 'Soup-Tests-Core' with: [ spec requires: 'Soup-Core' ]; package: 'Soup-Help' with: [ spec requires: 'Soup-Core' ]; package: 'Soup-XPath' with: [ spec requires: 'Soup-Core' ]; package: 'Soup-Zinc' with: [ spec requires: 'Soup-Core' ]. spec project: 'XMLSupport' with: [ spec className: 'ConfigurationOfXMLSupport'; versionString: #stable; repository: 'http://www.squeaksource.com/XMLSupport' ]. spec group: 'default' with: #('Core' 'Tests'); group: 'Core' with: #('Soup-Core' 'Soup-XPath'); group: 'Tests' with: #('Soup-Tests-Core') ]. spec for: #gemstone do: [ spec repository: 'http://www.smalltalkhub.com/mc/PharoExtras/Soup/main'. spec project: 'XMLSupport' with: [ spec className: 'ConfigurationOfXMLSupport'; versionString: #stable; repository: 'http://www.smalltalkhub.com/mc/pdebruic/XMLSupport/main' ]. spec package: 'SoupGemstone-Core' with: [ spec requires: 'XMLSupport' ]; package: 'Soup-Tests-Core' with: [ spec requires: 'SoupGemstone-Core' ]; package: 'Soup-Help' with: [ spec requires: 'SoupGemstone-Core' ]; package: 'Soup-XPath' with: [ spec requires: 'SoupGemstone-Core' ]; package: 'Soup-Zinc' with: [ spec requires: 'SoupGemstone-Core' ]. spec group: 'default' with: #('Core' 'Tests'); group: 'Core' with: #('SoupGemstone-Core'); group: 'Tests' with: #('Soup-Tests-Core') ].

Sept. 30, 2013

How to use Seamless?

by StÃ©phane Ducasse

Begin forwarded message: > From: Nick Papoylias <npapoylias(a)gmail.com> > Subject: Re: [Mtalk-commits] How to use Seamless? > Date: September 30, 2013 8:40:11 PM GMT+02:00 > To: Noury Bouraqadi <bouraqadi(a)gmail.com> > Cc: mtalk-commits <mtalk-commits(a)lists.gforge.inria.fr> > > So I opened a new configuration for clean-up and commited what we discussed today. So this is version 0.3: > > Gofer it > url: 'http://ss3.gemstone.com/ss/Seamless'; > package: 'ConfigurationOfSeamless'; > load. > > ((Smalltalk at: #ConfigurationOfSeamless) project version: '0.3') load. > > The quickest fix for the above code was (at the end) to use: > > > "Image 2" > middleware2 := SeamlessDeamon newDefaultWithGlobalAccess. > middleware2 startOn: 2222. > remoteEnv := middleware connectOn: '127.0.0.1:1111' > remoteClass := remoteEnv at: #Object. > > This is how deamons can connect to each other without any SeamlessDeamonManager > (the #connectOn: returns the entryDictionary which is the globals in this case). But I forgot > 'cause I was always using the default ;) > > With the Manager alternatively (the new code): > > "Image 2" > middleware2 := SeamlessDeamonManager addDefaultGlobalAccessDeamonOnPort: 2222. > remoteClass := '127.0.0.1:1111' asRemoteEnvironment at: #Object. > > and when stopping: > > SeamlessDeamonManager stop: middware2. > > Now the default deamon is either set by the user directly (as above) or lazily initialized (as we fixed it) in case it does not exist. > > In the case of syntacti-sugar requests a default deamon is needed because when saying: > > '127.0.0.1:1111' asRemoteEnvironment. > > instead of: > > middleware connectOn: '127.0.0.1:1111'. > > Seamless does not know which deamon you want to used (thus uses or lazily initializes a default). > > ======================================================================== > > The puzzle app is now initializing properly sending messages to the puzzle and the pieces, checked > by logging. > > ======================================================================== > > When the vue is being opened though it hangs in: > > demarrerAffichage > | window | > window := vue openInWindowLabeled: self titreFenetre. > > Unfortunately this is Morphic+Proxies territory and I' ll need some time > to see what's going on here. > > Usually morphic makes things slow by constantly accessing the model > for every update on the screen. In this case though it seems > to just hang. > > So I' ll need more time for that. > > > > > > On Mon, Sep 30, 2013 at 2:53 PM, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Nick, > > I tried to make two image talk to each other. > I start a SeamlessDeamon on each one. > Then, I tried to get a proxy on a class in one image from the other image. > > > "Image 1" > middleware1 := SeamlessDeamon newDefaultWithGlobalAccess. > middleware1 startOn: 1111 > > "Image 2" > middleware2 := SeamlessDeamon newDefaultWithGlobalAccess. > middleware2 startOn: 2222. > remoteClass := '127.0.0.1:1111' asRemoteEnvironment at: #Object. > > But, I get a DNU exception : UndefinedObject doesNotUnderestand #connectOn: > > It's in the SeamlessDeamonManager>>#addressAsRemoteEnvironment: > The defaultDeamon is nil. I tried to set it up, but I got more strange errors, so I gave up. > > Any hint? > > Noury > > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > > > _______________________________________________ > Mtalk-commits mailing list > Mtalk-commits(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/mtalk-commits > > _______________________________________________ > Mtalk-commits mailing list > Mtalk-commits(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/mtalk-commits

Sept. 30, 2013

Re: [Pharo-dev] unexpected lack of Method Version History (due to CI process?)

by Marcus Denker

On Sep 30, 2013, at 5:40 PM, btc(a)openinworld.com wrote: > In the process of reviewing a fix to an issue [1] that I reported with PharoLauncher, I downloaded the latest CI result and browsed to the method I knew had changed [2]. I wanted to directly observe the change in the version history, but was surprised that there was no version history for the method. My uninformed intuition is this relates to some 'clean up for release' run as part of the build process to strip out old versions to compact the image delivered by the CI process, but does it make sense to do this for every build? > I can understand not wanting this to grow indefinitely to bloat the image - but perhaps this compaction would be better only for major releases? I guess the downside is that you are then not exercising the 'full release' process every build. However having in image Version History extending a fair way back in time has always seemed to me to be one of the very cool (i.e. useful features of Pharo/Smalltalk). Without this, it feels like 'something' has been lost. The ultimate solution would seem to be linking the method version history to a network resource for the full history only as required per method. Any chance anyone is working on something like that? > Keep in mind that the .changes history and monticello are completely separate. When you load a mc version, you just load *that version*. We really need to have the "versions" of the method go and ask the repo. Now the problem is that Monticello is not really nice: it has complete snapshots per commit in a zip file. Getting version out there of a method is not possibleâ¦ without building infrastructure for it. Marcus

Sept. 30, 2013

unexpected lack of Method Version History (due to CI process?)

by btc＠openinworld.com

In the process of reviewing a fix to an issue [1] that I reported with PharoLauncher, I downloaded the latest CI result and browsed to the method I knew had changed [2]. I wanted to directly observe the change in the version history, but was surprised that there was no version history for the method. My uninformed intuition is this relates to some 'clean up for release' run as part of the build process to strip out old versions to compact the image delivered by the CI process, but does it make sense to do this for every build? I can understand not wanting this to grow indefinitely to bloat the image - but perhaps this compaction would be better only for major releases? I guess the downside is that you are then not exercising the 'full release' process every build. However having in image Version History extending a fair way back in time has always seemed to me to be one of the very cool (i.e. useful features of Pharo/Smalltalk). Without this, it feels like 'something' has been lost. The ultimate solution would seem to be linking the method version history to a network resource for the full history only as required per method. Any chance anyone is working on something like that? cheers -ben [1] https://pharo.fogbugz.com/f/cases/11614 [2] PharoLauncher>>createImageFromTemplate

Sept. 30, 2013

Re: [Pharo-dev] Backport of memory issue solution to Pharo 2.0?

by Goubier Thierry

Le 30/09/2013 15:47, Esteban Lorenzano a Ã©crit : > Hi Thierry, > > I can take the backport wednesday during the hangout. > I think it will be easier for me that I already know what to do to > reproduce it in Pharo2 than for others to catch up first and then to > solve the problem. Yes, I guess it is :) > If you are planning to attend, we can work in it remote-together (I > don't know how that will work, but we can try ;) I'll try to be there, Thierry > Esteban > > On Sep 30, 2013, at 9:38 AM, Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > >> >> >> Le 30/09/2013 09:27, StÃ©phane Ducasse a Ã©crit : >>> esteban told me that he found a way to systematically reproduce the >>> problem with his massive online game or something like that. >>> >>> Stef >>> >>> >>> On Sep 30, 2013, at 9:26 AM, Goubier Thierry <thierry.goubier(a)cea.fr >>> <mailto:thierry.goubier@cea.fr>> wrote: >>> >>>> I did some work on the relevant issue, as far as I could understand >>>> it (issue 11639). >>>> >>>> Now, if I could find a way to check that it really cures the problem... >>>> >>>> Thierry >>>> >>>> Le 29/09/2013 21:14, StÃ©phane Ducasse a Ã©crit : >>>>> >>>>> On Sep 29, 2013, at 9:08 PM, "phil(a)highoctane.be >>>>> <mailto:phil@highoctane.be>" <phil(a)highoctane.be >>>>> <mailto:phil@highoctane.be>> wrote: >>>>> >>>>>> I am experiencing the ever growing image issue in dev work and it >>>>>> is really a pain. >>>>>> >>>>>> Any back porting to 2.0? >>>>> >>>>> Yes it is planned. Just did not have the time last week. >>>>> If somebody wants to help this is more than welcome. >>>>> >>>>>> >>>>>> TIA >>>>>> Phil >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Thierry Goubier >>>> CEA list >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>> 91191 Gif sur Yvette Cedex >>>> France >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>> >>> >>> >>> >>> >> > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 30, 2013

Re: [Pharo-dev] Backport of memory issue solution to Pharo 2.0?

by Esteban Lorenzano

Hi Thierry, I can take the backport wednesday during the hangout. I think it will be easier for me that I already know what to do to reproduce it in Pharo2 than for others to catch up first and then to solve the problem. If you are planning to attend, we can work in it remote-together (I don't know how that will work, but we can try ;) Esteban On Sep 30, 2013, at 9:38 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 30/09/2013 09:27, StÃ©phane Ducasse a Ã©crit : >> esteban told me that he found a way to systematically reproduce the problem with his massive online game or something like that. >> >> Stef >> >> >> On Sep 30, 2013, at 9:26 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> I did some work on the relevant issue, as far as I could understand it (issue 11639). >>> >>> Now, if I could find a way to check that it really cures the problem... >>> >>> Thierry >>> >>> Le 29/09/2013 21:14, StÃ©phane Ducasse a Ã©crit : >>>> >>>> On Sep 29, 2013, at 9:08 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> I am experiencing the ever growing image issue in dev work and it is really a pain. >>>>> >>>>> Any back porting to 2.0? >>>> >>>> Yes it is planned. Just did not have the time last week. >>>> If somebody wants to help this is more than welcome. >>>> >>>>> >>>>> TIA >>>>> Phil >>>> >>>> >>>> >>> >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> >> >> >> >

Sept. 30, 2013

Re: [Pharo-dev] ConfigurationOfGhost: Where?

by Mariano Martinez Peck

Yes, it is still in SS3. Some weeks ago I think someone reported that the #cannotInterpert: trick was not working anymore in latest Pharo (so proxies won't work). I didn't have the time yet to try different images/VMs and see if it works, but if I can give it a try today or tomorrow. Cheers On Sun, Sep 29, 2013 at 11:04 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > It is probably still on SS3 > > http://ss3.gemstone.com/ss/Ghost/ > > Stef > > On Sep 24, 2013, at 7:58 PM, phil(a)highoctane.be wrote: > > I am preparing my environment for development and am updating my webstack > configuration to match the new moves to SmalltalkHub. > > Now, I am trying to get my ConfigurationOfOak working. > > Fuel has moved to SmalltalkHub and it is fine. > > Now, where is Ghost .? > > I want to update this: > > spec > project: 'GhostProxies' with: [ > spec > className: 'ConfigurationOfGhost'; > loads: #('Core'); > versionString: #stable; > file: 'ConfigurationOfGhost'; > repository: 'http://ss3.gemstone.com/ss/Ghost' ]. > spec project: 'GhostProxiesTests' copyFrom: 'GhostProxies' with: [ > spec loads: #('Tests' ) ]. > > The search function on STH isn't helping much... > > Thanks for the help! > > Phil > > > -- Mariano http://marianopeck.wordpress.com

Sept. 30, 2013

[update 3.0] #30433

by Marcus Denker

Sept. 30, 2013