- Pharo-dev - lists.pharo.org

[regression reporter]regression occurred
by no-reply＠ci.inria.fr Oct. 1, 2013

Oct. 1, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=li… 1 regressions found. Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

1 0

[update 3.0] #30435
by Marcus Denker Oct. 1, 2013

Oct. 1, 2013

1 0

Re: [Pharo-dev] failing moose tests
by Stephan Eggermont Sept. 30, 2013

Sept. 30, 2013

There has been a fixed package on smalltalkhub since 10 days, so it looks like a configuration problem Name: Moose-Test-HismoImporter-StephanEggermont.5 Author: StephanEggermont Time: 20 September 2013, 2:45:53.012 pm UUID: 766c5b47-daa6-4b51-af8f-091539186c59 Ancestors: Moose-Test-HismoImporter-AndreHora.4 Fixed some tests

1 0

Re: [Pharo-dev] failing moose tests
by Stephan Eggermont Sept. 30, 2013

Sept. 30, 2013

>>> Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery15Days 64 ms 3 >>> Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery2Years 52 ms 3 >>> Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery6Months 51 ms 3 Don't know where they come from. The implementation should be using everyNDays/Months/Years AFAIK Stephan

1 0

failing moose tests
by Camillo Bruni Sept. 30, 2013

Sept. 30, 2013

For the vm release tests, we run all the moose tests but there are 3 that constantly fail: https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM-AcceptanceTest/SLAVE=rmod… >>> Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery15Days 64 ms 3 >>> Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery2Years 52 ms 3 >>> Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery6Months 51 ms 3 All of them fail with the same symptoms: MooseHismoImporter(Object)>>doesNotUnderstand: #every15Days MooseHismoImporterTest>>testEvery15Days MooseHismoImporterTest(TestCase)>>performTest Any clue? ------------------------------------------------------------------------------ REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo Pharo.image save Moose ./pharo Moose.image config $REPO ConfigurationOfMoose --install=stable ./pharo Moose.image mooseimagesetup ./pharo Moose.image test --junit-xml-output "Moose.*" ------------------------------------------------------------------------------

1 0

[update 3.0] #30434
by Marcus Denker Sept. 30, 2013

Sept. 30, 2013

30434 ----- 7130 Scrollbars on the left. Nobody needed it for years --> remove https://pharo.fogbugz.com/f/cases/7130 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1283.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.130…

1 0

ConfigurationOfGhost: Where?
by phil＠highoctane.be Sept. 30, 2013

Sept. 30, 2013

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

4 4

Sept. 30, 2013

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

1 0

Backport of memory issue solution to Pharo 2.0?
by phil＠highoctane.be Sept. 30, 2013

Sept. 30, 2013

I am experiencing the ever growing image issue in dev work and it is really a pain. Any back porting to 2.0? TIA Phil

4 6

[update 3.0] #30433
by Marcus Denker Sept. 30, 2013

Sept. 30, 2013

1 0