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

[Pharo-project] Automatic/periodic image saves

by John Thornborrow

Hi, We've deployed a Pharo+Pier/Seaside image for our website, and (naturally) changes are made to the site via Pier. I'd like to know if there is a preferred method of saving the image to disk every, say, 12 hours? Many thanks, John. www.pinesoft.co.uk Consider your responsibility to the environment - think before you print! ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

June 17, 2009

Re: [Pharo-project] testWhileModificationBeforeNotInlined

by Nicolas Cellier

Ah, yes, I don't understand neither. For me, the non inlined version seems to work already and gives #(5 5 5 5 5). The inlined version fails and gives #(1 2 3 4 5), except if you fool the Compiler with the trick I have indicated: testWhileModificationBefore | index | index := 0. [ index < 5 ] whileTrue: [ index := index + 1. collection add: [1>2 ifTrue: [index:=0]. index ] ]. self assertValues: #(5 5 5 5 5) The point remains:some well known failing tests that won't be solved should go in known failures. Nicolas 2009/6/17 Lukas Renggli <renggli(a)gmail.com> > > I suggest this test be moved in known failures. > > Lukas ? > > I don't get it ;-) > > This looks fine to me. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 17, 2009

Re: [Pharo-project] [Fix] Issue890 Mantis6535 SortedCollection loose sortBlock

by Lukas Renggli

> OB is another story. For me, its at the border of being usable because > of its slowness. Just for the record: OB included with the Seaside One-Click image is only marginally slower than the standard system browser. Opening and closing OB system browser on the class WACounter: 636.15 ms Opening and closing SystemBrowser on the class WACounter: 555.00 ms Lukas -=--=--=--=--=--=--=--=--=--=--=--=--=--=- " Omni Browser " [ browsers := (1 to: 20) collect: [ :each | OBSystemBrowser onClass: WACounter ]. browsers do: [ :each | each open. World doOneCycle ]. browsers do: [ :each | each close. World doOneCycle ] ] timeToRun / 20.0 " System Browser " [ browsers := (1 to: 20) collect: [ :each | Browser new setClass: WACounter selector: nil ]. browsers do: [ :each | Browser openBrowserView: (each openEditString: nil) label: 'System Browser'. World doOneCycle ]. browsers do: [ :each | each changed: #close. World doOneCycle ] ] timeToRun / 20.0 -=--=--=--=--=--=--=--=--=--=--=--=--=--=- -- Lukas Renggli http://www.lukas-renggli.ch

June 17, 2009

Re: [Pharo-project] [Fix] Issue890 Mantis6535 SortedCollection loose sortBlock

by Adrian Lienhard

Hi Nicolas, On Jun 16, 2009, at 22:10 , Nicolas Cellier wrote: [...] > <rant> > Monticello is quite a drag, and pharo feels globally unresponsive > (even the core image). Yep, responsiveness can be improved. The core feels quite fast for me (on a MacBook Pro), but still, for example opening a browser is not instantaneous. Also, if you type really fast, the characters start appearing late (I think Bill complained about that recently). OB is another story. For me, its at the border of being usable because of its slowness. [...] > To me UI feel is mitigating all the good job made so far. So we should try to improve the GUI performance of the core. However, I'm not sure who can help... Cheers, Adrian

June 17, 2009

Re: [Pharo-project] testWhileModificationBeforeNotInlined

by Lukas Renggli

> I suggest this test be moved in known failures. > Lukas ? I don't get it ;-) This looks fine to me. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 17, 2009

Re: [Pharo-project] about Behavior>>flushCache

by Adrian Lienhard

The interpreter purges the whole cache: flushMethodCache "Flush the method cache. The method cache is flushed on every programming change and garbage collect." 1 to: MethodCacheSize do: [ :i | methodCache at: i put: 0 ]. 1 to: AtCacheTotalSize do: [ :i | atCache at: i put: 0 ]. Cheers, Adrian On Jun 16, 2009, at 22:32 , Gabriel Brunstein wrote: > does anybody know if the the method Behavior>>flushCache flush the > whole > method cache or just the methods of the receiver class ? > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 17, 2009

Re: [Pharo-project] BlockContextTest

by Adrian Lienhard

Hi Gabriel Could you post a list of these methods? Probably it makes sense to copy some of them over to BlockClosure to preserve compatibility for external clients (we had this before, e.g., #argumentCount, IIRC which is used by GLORP or Seaside). Else these tests can be removed. Adrian On Jun 17, 2009, at 02:28 , Gabriel Cotelli wrote: > Hi, > > I'm looking the failing tests... some tests defined in > BlockContextTest > relies on behavior not implemented in BlockClosure (but implemented > in the > old BlockContext)... > > If the only senders of this methods are in this test cases can I > remove > them? > > If I don't miss anything BlockContext should not be used anymore... > > Waiting for your comments... > Gabriel > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 17, 2009

Re: [Pharo-project] Segmentation fault when publishing a package

by Damien Cassou

2009/6/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Very known problem: http://code.google.com/p/pharo/issues/detail?id=855 > > 1) Download new exupery-0.15.1 from here: > http://gforge.inria.fr/frs/download.php/22421/pharo-vm-0.15.1b-linux.zip > > 2) On Ubuntu 9.04, find the UUIDPlugin folder and rename the _folder_ to > something like UUIDPlugin-not-used and all should be well. Do either one or the other solution. Not both. And the download link is always on http://pharo-project.org/download. Please report any other problem -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 17, 2009

Re: [Pharo-project] testWhileModificationBeforeNotInlined

by Nicolas Cellier

Well, the bloks collected in collection should all refer to the same temporary variable | index | in the context of execution of testWhileModificationBeforeNotInlined When these get executed by assertValues:, we can expect they all return the current value of this | index | temp, that is 5. That is not the case, because BlockClosure implementation creates a copy of outside temporaries it accesses (this is for optimization purposes). You can try to fool the compiler with this code: | index block | index := 0. block := [ index := index + 1. collection add: [ 1>2 ifTrue: [index:=0]. index ] ]. [ index < 5 ] whileTrue: block. There you get #(5 5 5 5 5) as expected... I suggest this test be moved in known failures. Lukas ? Nicolas 2009/6/17 Gabriel Cotelli <g.cotelli(a)gmail.com> > Doing some test fixing I noticed that testWhileModificationBeforeNotInlined > not fail.... but I think it should be: > > Here is the code: > > testWhileModificationBeforeNotInlined > > | index block | > index := 0. > block := [ > index := index + 1. > collection add: [ index ] ]. > [ index < 5 ] whileTrue: block. > self assertValues: #(5 5 5 5 5) > > I think this should produce in collection: #(1 2 3 4 5) ... there's another > tests with the block directly as collaborator of the whileTrue: (without > temp assignment) that produces the expected output... > > I'm missing something? > > Thanks > Gabriel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 17, 2009

Re: [Pharo-project] idea to have a better methodFinder :)

by Mariano Martinez Peck

On Tue, Jun 16, 2009 at 8:16 PM, Marcus Denker <denker(a)acm.org> wrote: > > On 16.06.2009, at 19:12, Mariano Martinez Peck wrote: > > > > > > > On Sun, Jun 14, 2009 at 5:59 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr > > > wrote: > > Hi > > > > the methodFInder hard codes the methods that should not be executed. > > Now with pragma we should be able to have a fully dynamic method > > finder where nothing is hardcoded. > > If somebody wants to give a try it would be great because MF is a cool > > tool. Now too static. > > > > I don't know what Pragma is, but Algernon seems VERY good from my > > point of view. I used it a lot in Squeak and now I really miss it on > > Pharo. Algernon authors won't port it to Pharo (I asked them). > > Perhaps when Pharo 1.0 is released I can spend some time to make it > > work. > > > What is Algernon? > Its really amazing. You can give it a try. Just download latest squeak-dev from Damien and try it :) I copy paste what squeaksource says about Algernon: Algernon is a productivity tool for Squeak programmers; your personal assistant for Squeak. Algernon aims to make programming in Squeak faster and more keyboard centric. It provides lightning quick access to any class, method, morph, or global variable, and even gives you a quick way to evaluate Smalltalk expressions. Press a system-wide hotkey to bring up the text box (ctrl-space by default). Start typing a class name, a morph's name, a category, or a global variable and a menu of matching items will show up and filter down as you type. Select an item from the list by navigating with the up/down arrows and hitting return. Algernon will perform a different action depending on the type of the item selected. For instance, if you selected a class or category, it will open it in a browser. If you selected a morph, a new instance of the morph will open. If you selected a global variable, an inspector will open. You can also perform actions other than the default by pressing tab and navigating a list of possible actions. Algernon also lets you drill into categories and classes. Press the right arrow key when a class is selected and you will be presented with a list of methods in that class, which you can then filter down by typing. Similarly, press the right arrow key when a category is selected and you will be presented with a list of its classes. Press the left arrow key at any point to go back to global searching. Algernon also has the capability to evaluate any one line Smalltalk expression. In this way Algernon can act as a mini workspace. Just bring up Algernon and type = and you will enter the expression mode. Type your expression (e.g., 3+5) and hit return to print the result on the Transcript. You can see a list of other actions by pressing the tab key. Algernon is also intelligent (it was named this way for a reason!). It will learn which items you open most often and will sort those higher in the list each time you use them. It will even learn which actions you like to associate with each item. Enjoy using Algernon, and we hope you love it as much as we do! > > Marcus > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 17, 2009