December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Continuous Integration Server for Pharo?

by Lukas Renggli

Colin gave me the following text to forward to this thread: > Colin, could you provide more information on Mason (maybe the mail you > once sent to me)? Pharo people are interested to investigate the > system. Sure. Here's that email, slightly reworked to bring it up to date with the current state of Mason. This isn't the grand design I started with, it's what's emerging, so it's a bit fuzzy and might be a bit hard to see in the current code. The core model is a hierarchy of targets. Targets represent the artifacts that Mason can produce, such as files, directories, images, packages etc, and the hierarchy represents the desired state, which Mason will work to create. There's a Canvas-like API for creating target hierarchies, and Products are objects that know how to specify targets using that API. A Product is an abstract thing, which represents a high-level concept such as "the latest version of a given package" or "the HTML documentation for a project." The role of a Product is to reduce that abstraction to a set of concrete targets which it specifies using the canvas API. A Product probably has to examine the environment to decide what targets to specify - it might scan a repository to determine the latest version of a package or scan a directory of creole files to determine which HTML files need to be generated. Given a target hierarchy, Mason can generate a Build. A Build contains a number of jobs, which collectively create the artifacts specified by the targets. Jobs essentially MethodObjects, and each do small amounts of work. The Build is responsible for running the jobs and managing dependencies between them. The build runs the jobs in parallel where possible, and since many jobs involve IO or spawning other processes via OSProcess, so there's actually a pretty decent performance advantage. Those are the broad outlines. There's a few issues here still, both architectural and with the current implementation. One is that building a target tree may be an unnecessary intermediate step. It would feasible to have targets just be transient entities the way TagBrushes are in Seaside - Products would specify a Build directly. Another is that I haven't tried to do any optimization along the lines of make - everything is built fresh every time. The targets -> build converter could try to examine the disk and see if it could avoid building things that are already up to date. I have an idea to address both these issues by having a step that walks over the target tree and optimizes it before the Build is created. This could involve identifying and merging common intermediate steps, and then doing the make trick of eliminating any targets that already exist and are up-to-date. For now though, I've been quite happy with even the unoptimized version. I've used it to build distribution SAR archives for OB, MC2 and Filesystem, development images, load-order and package dependency testing etc. Colin -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 2, 2009

[Pharo-project] [ann 1.1] pre-built #11068

by Marcus Denker

http://gforge.inria.fr/frs/download.php/24963/PharoCore-1.1-11068-alpha.zip

Dec. 2, 2009

Re: [Pharo-project] Issue 332, 1489, 1529: arithmetic protocols extracted from core

by Simon Denier

On 2 dÃ©c. 2009, at 09:56, csrabak(a)bol.com.br wrote: > Em 02/12/2009 01:41, Simon Denier < Simon.Denier(a)inria.fr > escreveu: >> >> On 1 dÃ©c. 2009, at 21:07, csrabak(a)bol.com.br wrote: >> >>> I'm trying to follow the directions given at: >>> http://code.google.com/p/pharo/wiki/HowToContribute. >>> However, after the SLICE asks for the first comment, it freezes >>> the image and the small window "Writing definitions" stays at 50% >>> progress and nothing happens then. > >> Hi Cesar, I took your changeset and prepared a Slice, I did not >> have any problem. > > Nice to know, Simon. Just to understand how I can troubleshoot > this: did you > empoly a core or dev image to do the Monticello stuff? A core image. Perhaps you can try to repeat the steps, Monticello can take some times to do its stuff, from time to time. -- Simon

Dec. 2, 2009

Re: [Pharo-project] lukas-renggli.ch down, mirrors exists ?

by Simon Denier

On 2 dÃ©c. 2009, at 08:05, Mariano Martinez Peck wrote: > > > 2009/12/2 laurent laffont <laurent.laffont(a)gmail.com> > Hello, > > I want to check if there's updates to Slime package as I faces > several bugs but sources.lukas-renggli.ch seems to be down. Is > there a mirror ? > > > About the bugs (Slime-lr.24,current pharo rc1 web image), when I > select refactor > code critics: > > - it seems that ParserTreeSearcher has been renamed to > RBParserTreeSearcher. Thus there's several errors like > WAChangesStateWhileRenderingRule>>initialize (ParseTreeSearcher is > Undeclared) > > - this done, I have the error: AnObsoleteParseTreeSearcher(Object) > >>doesNotUnderstand: #executeTree:initialAnswer: (from > RBAssignmentIfTrueRule>>checkMethod:) > > > How do I save a stack trace to a text file (or clipboard) from the > debugger ? > > Look for the file called PharoDebug.log which is in the directory > where the image is. It will have not only the stacktrace but also > much more information, as VM version, OS, etc. or.... In the debugger, open the contextual menu and there is an item 'mail out bug report' to directly send the stack trace with VM version etc to the pharo list (or whoever you want to, but by default it's the Pharo ml). Of course you can edit the message to make it shorter (we dont need the full stack in general) and describe your problem etc. > > Best, > > Mariano > > > > Regards, > > Laurent Laffont > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Dec. 2, 2009

Re: [Pharo-project] Issue 332, 1489, 1529: arithmetic protocols extracted from core

by csrabak＠bol.com.br

Em 02/12/2009 01:41, Simon Denier < Simon.Denier(a)inria.fr > escreveu: > > On 1 dÃ©c. 2009, at 21:07, csrabak(a)bol.com.br wrote: > > > I'm trying to follow the directions given at: > >http://code.google.com/p/pharo/wiki/HowToContribute. > > However, after the SLICE asks for the first comment, it freezes > > the image and the small window "Writing definitions" stays at 50% > > progress and nothing happens then. > Hi Cesar, I took your changeset and prepared a Slice, I did not > have any problem. Nice to know, Simon. Just to understand how I can troubleshoot this: did you empoly a core or dev image to do the Monticello stuff?

Dec. 2, 2009

[Pharo-project] [update 1.1] #11068

by Marcus Denker

11068 ----- Issue 1534: some more random cleans... Issue 1531: Integer>>#asFraction (only a typo in the comment) Issue 840: MorphViewHierarchyBrowser code Issue 1535: Time>>asMilliSeconds missing ======= brings a new useful tool for understanding morphic: World exploreViewHierarchy (a menu can "flash" the morph to show where it is on the screen). ========== ... removes lots of useless preferences.... "The paradox of Choice": Less is more. Preferences removePreference: #balloonHelpInMessageLists. Preferences removePreference: #projectViewsInWindows. Preferences removePreference: #projectZoom. Preferences removePreference: #automaticKeyGeneration. Preferences removePreference: #oliveHandleForScriptedObjects. Preferences removePreference: #canRecordWhilePlaying. Preferences removePreference: #fenceSoundEnabled. Preferences removePreference: #includeSoundControlInNavigator. Preferences removePreference: #projectsSentToDisk. Preferences removePreference: #menuButtonInToolPane.

Dec. 2, 2009

Re: [Pharo-project] Time asMilliseconds...

by StÃ©phane Ducasse

Hernan I checked and this method is not in Squeak3.9, squeaktrunk, Now we could easily add self asDuration asMilliSeconds I will do that On Dec 1, 2009, at 6:33 PM, Hernan Wilkinson wrote: > is not in the image anymore...is there a reason? > > Henan. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 2, 2009

Re: [Pharo-project] is this correct ?

by Lukas Renggli

#become: swaps the two pointers, so both objects continue to exist. Use the asymmetric variant #becomeForward: to get rid of an object. And you probably also need a "Smalltalk garbageCollect" to make the object really disappear. Lukas 2009/12/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > become: changes the pointer pointing to the objects not the object itself. > So I'm not sure that instance should be changed. > > If I remember correctly what allinstances does is that it use nextObject to > iterate over the object spaces. > > Stef > > On Dec 2, 2009, at 10:21 AM, Mariano Martinez Peck wrote: > >> Hi! Â Look this peace of code: >> >> | instance | >> instance := TestCase new. >> Transcript show: TestCase allInstances size; cr. >> instance become: 'aString'. >> Transcript show: TestCase allInstances size; cr. >> >> >> The size of TestCase instances is always the same. Although I used become: (and changed to an instance of another class) to one of its instances. >> >> So, my main question is, is this correct ? Â Or the message allInstances to TestCase should not take into account the instance I sent the message become: Â ? >> >> Thanks in advance. >> >> Mariano >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 2, 2009

Re: [Pharo-project] lukas-renggli.ch down, mirrors exists ?

by laurent laffont

> > > Look for the file called PharoDebug.log which is in the directory where the > image is. It will have not only the stacktrace but also much more > information, as VM version, OS, etc. > > Best, > > Mariano > > Cool ! Thank You ! Laurent

Dec. 2, 2009

Re: [Pharo-project] lukas-renggli.ch down, mirrors exists ?

by Mariano Martinez Peck

2009/12/2 laurent laffont <laurent.laffont(a)gmail.com> > Hello, > > I want to check if there's updates to Slime package as I faces several bugs > but sources.lukas-renggli.ch seems to be down. Is there a mirror ? > > > About the bugs (Slime-lr.24,current pharo rc1 web image), when I select > refactor > code critics: > > - it seems that ParserTreeSearcher has been renamed to > RBParserTreeSearcher. Thus there's several errors like > WAChangesStateWhileRenderingRule>>initialize (ParseTreeSearcher is > Undeclared) > > - this done, I have the error: > AnObsoleteParseTreeSearcher(Object)>>doesNotUnderstand: > #executeTree:initialAnswer: (from RBAssignmentIfTrueRule>>checkMethod:) > > > How do I save a stack trace to a text file (or clipboard) from the debugger > ? > Look for the file called PharoDebug.log which is in the directory where the image is. It will have not only the stacktrace but also much more information, as VM version, OS, etc. Best, Mariano > > > Regards, > > Laurent Laffont > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 2, 2009