- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PharoCore 1.3: Transcript Ctrl+S broken
by Marcus Denker Aug. 9, 2011

Aug. 9, 2011

On Aug 9, 2011, at 7:28 AM, Lukas Renggli wrote: > Ahh ok, I will rebuild my images then. I was using the ../unstable-core URL. > Yes, this points to gforge and laggs the very latest by around 10 updates. The image is always one that we know is not completely broken. (because very last update could be not in a good state). The other reason is that Hudson needs to start somewhere... and loading update is slow and tends to stress squeaksource. So Hudson takes the gforge image as a starter. Of course all that is done by hand (me uploading, me changing links... or even having to tell Adrian to change links). This is all not perfect, but there is always the question: Do we stop to improve Pharo until the process is perfect or do we do both in parallel? This can and will all be improved, step by step. Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] PharoCore 1.3: Transcript Ctrl+S broken
by Marcus Denker Aug. 9, 2011

Aug. 9, 2011

On Aug 9, 2011, at 7:07 AM, Lukas Renggli wrote: > On 8 August 2011 23:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Indeed it works also in 14078 > > Ahh ok, thanks. I thought I was using the latest image, but it seems > that I am using 13291. Aside, how do I get the latest 1.3 image? > -> "load updates" in core. -> or from the build server: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/ https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%20Core%201.3/ The gforge one is updated only every couple of updates. I will do that as soon as I know which VMs we will use for 1.3 (because I might need to re-do images as I always forget that I use cog and the saved images are not compatible to old VMs that some people seem to need). Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

[Pharo-project] Recursive calls hang image
by Sean P. DeNigris Aug. 9, 2011

Aug. 9, 2011

My image hung after executing: categoryName := $- asParser negate plus flatten, ($- asParser, #any asParser star flatten) optional star. categoryName parse: 'SuperMe'. On the Moose list [1], Lukas pointed out the bug in my code which led to direct recursion, and that hanging under this circumstance was a bug in Pharo. Is this a known bug, or shall I file an issue? [1] http://forum.world.st/PetitParser-crash-td3725129.html -- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728055.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 11

[Pharo-project] small fix to help newbies
by P. Aug. 9, 2011

Aug. 9, 2011

Hi folks, I'm sending this email to both Squeak-dev and Pharo-project as you can see. This is to suggest a fix. I typed this on a workspace: closure := [:x | Transcript show: x]. closure value: "hey". And when I "did it", the VM had me looking at this: closure := [:x | Transcript show: x]. closure value: "hey". Argument expected -> Which is cryptic at best for a newbie. I visited #squeak(a)irc.freenode.net and asked there. Ken Causey helped me out and even he missed the difference between "" and '' for a second. I believe it would be beneficial to newbies to have this enhanced somehow, to point out the fact that strings aren't double-quoted. Thanks, Peter

3 2

[Pharo-project] Cog VMMaker.oscog-eem.114/r2485
by Eliot Miranda Aug. 8, 2011

Aug. 8, 2011

Hi All, please find new VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2485/. These fix a couple of long-standing bugs. One is a rare crash in GC on copying a compiled method, caused by the VM not making sure that a copy of a method that has been compiled to machine code is an independent copy. The other is a potential bug in GC with become where a become causes some machine code methods to gain references to young objects but the VM forgets to include these methods in the young referrers (those machine code methods that refer to young objects). -- best, Eliot

2 3

[Pharo-project] exciting master topics with us :)
by StÃ©phane Ducasse Aug. 8, 2011

Aug. 8, 2011

Hi guys if you are interested we have a nice list of ideas for license and master topics. Let us know. We will publish them soon. Fuel was one of them and we are writing a really excellent paper on it and we will use it in Pharo for real :). Stef

1 0

[Pharo-project] Summary with UUID not so unique.
by Mariano Martinez Peck Aug. 8, 2011

Aug. 8, 2011

Hi guys. Can someone do a summary of the problem of UUID not so unique? because I have been bitten again. In my image, primMakeUUID is still calling the primitive: primMakeUUID <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> UUIDGenerator default generateBytes: self forVersion: 4. By my VM is still broken with this aspect. So....how should we deal with it? a) Change/Commmit/Integrate this: primMakeUUID UUIDGenerator default generateBytes: self forVersion: 4. b) there are new Cog VMs somewhere that I can use with this problem fixed? Thanks -- Mariano http://marianopeck.wordpress.com

3 2

[Pharo-project] FSGit for new Filesystem implementation
by Max Leske Aug. 8, 2011

Aug. 8, 2011

Hello everyone. I'm happy to announce that Camillo (with a little help from me) has adapted FSGit to run with the new Filesystem implementation (version 2.0.1). All tests are green. Nonetheless, please be careful when using it. There's also support for Monticello, although I haven't used that myself. AFAIK Camillo uses that part to store his Monticello versions in a git repository on his disk (correct me if I'm wrong). One new thing is that I wrote thorough tests for the handling of packs (thanks to Simon Denier for reporting the bug). Note that FSGit *cannot* write pack files and I have decided to not implement write support in the future (if someone else wants to however, I'm fine with that :) ). I'd like to thank all the people who have snuck looks at FSGit and pointed out important stuff. There's still a lot that can be improved but I feel that FSGit is on a good way. You can load FSGit through ConfigurationOfFSGit which you will find in the FSGit SqueakSource repository. This will also load Filesystem into the image. As usual, if you have suggestions or find a bug, hit me up directly or send an email to the list. Here's to the coolest Smalltalk environment available! :D Max

2 1

Re: [Pharo-project] [Vm-dev] Re: Troubles with #flushCache and #run:with:in:
by Jorge Ressia Aug. 8, 2011

Aug. 8, 2011

Hi Eliot, I am experiencing the same problem as Lukas. I was having random DNU on replaced methods. I fixed the problem by flushing the cache on the compiled methods only, before I was flushing on the selector and on the class. It is not yet clear to me what is the right way of flushing the cache. Any explanation on that? I think that this goes along with http://code.google.com/p/pharo/issues/detail?id=2255 http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html Eliot, if you need help debugging or testing a potential solution let me know, I have a bunch of test working on top of this. Cheers, On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > Â Â Â I'm in touch with Lukas on this but have no time to address it right now. Â worry not :) > > On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> Maybe cc'ing VM mailing list can help. >> >> On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> >>> Hi Eliot, >>> >>> I am using one of the latest VMs from your site (VM.r2434) and I >>> continue to have subtle problems with objects as methods (#flushCache, >>> #run:with:in:). >>> >>> The issue is that the test coverage in Pharo is kind of broken on Cog >>> for a long time already. It reports methods as not covered that are >>> clearly covered, and tests seem to randomly fail. >>> >>> I suspected that there is something wrong with the coverage code >>> itself. So I started to experiment with TestCoverage>>flushCache and >>> noticed that the current implementation >>> >>> Â Â TestCoverage>>flushCache >>> Â Â Â Â self reference methodSymbol flushCache >>> >>> performs not that well: The set of not covered methods is wrong and >>> many tests suddenly fail. If I replace it with >>> >>> Â Â TestCoverage>>flushCache >>> Â Â Â Â self reference actualClass flushCache >>> >>> I actually get accurate coverage information, but there are still a >>> few tests constantly failing. I tried to use all possible combinations >>> of #flushCache (also calling it on the compiled method), but only >>> flushing the cache on the class seems to work properly. So far so >>> good, but I really wonder what the correct way is to flush the cache? >>> :-) >>> >>> For my experiments I was using the package 'AST-Tests-Semantics'. This >>> is a small package with lots of test methods that cover each method >>> but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" >>> problem is that when running these tests in coverage mode, the same 4 >>> tests always fail: >>> >>> Â Â RBSemanticTest>>testBlockScope >>> Â Â RBSemanticTest>>testCascadeReceiver >>> Â Â RBSemanticTest>>testClassVariableBinding >>> Â Â RBSemanticTest>>testGlobalVariableBinding >>> >>> Not sure of how to debug that? Do you have an idea why these otherwise >>> passing tests suddenly fail? If you want to try to reproduce you can >>> use any Pharo image with the tests loaded, or use those that I used: >>> >>> Â Â http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… >>> Â Â http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… >>> >>> Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'. >>> >>> Any help or clarification would be appreciated :-) >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > > -- > best, > Eliot > > -- Jorge Ressia www.jorgeressia.com

1 0

[Pharo-project] Be careful, problem with WeakOrderedCollection in Pharo (there is a fix)
by Mariano Martinez Peck Aug. 8, 2011

Aug. 8, 2011

Hi Chris. We found a problem with WeakOrderedCollection in Pharo which may cause problems in Magma users in Pharo. Basically, once a WeakOrderedCollection needed to #grew, it stops being weak because the internal array was replaced by a Array instead of a WeakArray. (WeakOrderedCollection new instVarNamed: 'array') class ->>>> WeakArray (WeakOrderedCollection new grow instVarNamed: 'array') class ->>>> Array So....I can imagine that some applications running magma may grow a lot due to this bug. Just to check whether someone is having this bug or not, you may want to execute: WeakOrderedCollection allInstances select: [:each | (each instVarNamed: 'array') class = Array ] if you have instances, then that's a problem ;) To fix it, you can fileine the changes of the issue tracker: http://code.google.com/p/pharo/issues/detail?id=4596 and then you should fix the already created instances. cheers ps: I have no idea how much Magma uses WeakOrderedCollection, but I thought it was just worth it to raise a warning. -- Mariano http://marianopeck.wordpress.com

2 1