- Pharo-dev - lists.pharo.org

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

Oct. 1, 2013

1 0

eGov Hackathon in Namur, Belgium, this friday and week end - takers?
by phil＠highoctane.be Oct. 1, 2013

Oct. 1, 2013

There has been 4 people bailing out and having paid their space I am going to use Pharo as a showcase over there. Any takers to join me to hack for the common good and showcase Pharo's powers? (Additional perk: I've Pharo t-shirts ) Here is the info: http://hackathonegovwallonia.net/ Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

1 0

[update 3.0] #30436
by Esteban Lorenzano Oct. 1, 2013

Oct. 1, 2013

30436 ----- 11732 add NonInteractiveTranscript to kernel packages https://pharo.fogbugz.com/f/cases/11732 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-EstebanLorenza…

1 0

Primitives lookupEntryIn:index: fails on mac with the latest vm
by Andrei Chis Oct. 1, 2013

Oct. 1, 2013

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

4 7

I want to remove Pharo/XMLWriter since it is in PharoExtras/XMLWriter
by StÃ©phane Ducasse Oct. 1, 2013

Oct. 1, 2013

Hi guys does anybody use Pharo/XMLWriter because the official repo is PharoExtras/XMLWriter And I want to remove Pharo/XMLWriter Stef

1 0

SlotVirus
by Torsten Bergmann Oct. 1, 2013

Oct. 1, 2013

>we now have nearly everything double in the system: > >We should really clean up. And introduce namespaces ;)

1 0

Weird issue with removing instance vars from class def: instance vars jumbled
by phil＠highoctane.be Oct. 1, 2013

Oct. 1, 2013

I guess this has happened to other people. In Pharo 20 and while using Seaside, I was adding, removing , changing components which were making a component and it happened that if I had, let say: a b c d e f turned into a c f Well, c kind of pointed to a b in existing instances and f to old c etc; No matter how much I unregister and reregisted my app, this continued. I got out of the problem by filing out the code and filing it in back, which recomplied the whole component. Weird. I can understand that some existing bytecode wasn't updated when rearranging instvars but for someone new to the game, this would really be weird. Clues? Phil

4 8

unexpected lack of Method Version History (due to CI process?)
by btc＠openinworld.com Oct. 1, 2013

Oct. 1, 2013

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

3 4

[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=ma… 1 regressions found. Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

1 0

[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=wi… 2 regressions found. Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral Zinc.Tests.ZnServerTests.testEntityTooLarge

1 0