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

[Pharo-project] [update 2.0] #20150

by Esteban Lorenzano

20150 ----- Issue 6113: jenkins pharo tests for windows http://code.google.com/p/pharo/issues/detail?id=6113 (not working yet... but close)

June 21, 2012

Re: [Pharo-project] [Pharo-users] Spec version 1.0

by Sven Van Caekenberghe

On 21 Jun 2012, at 11:29, Benjamin wrote: > [1] http://hal.inria.fr/docs/00/70/80/67/PDF/SpecTechReport.pdf Hmm, documentation, lovely! Thx, Sven

June 21, 2012

Re: [Pharo-project] Opal ?

by Goubier Thierry

Le 21/06/2012 16:01, Marcus Denker a Ã©crit : > > On Jun 21, 2012, at 3:36 PM, Goubier Thierry wrote: >>> >>> It seem the final objective is to send something to Esug ? >> >> If I make it in time, yes. Ok, it seems I shouldn't try the RecompileTests then? > No, I don't use them right now... > >> So far, I have only the IRDecompilerTests which are failing. > > That is the one that depends on PetitParser (experiment, not needed will be done after > the rest works). > > State of things: > > 1) Backend. > > BC->IR->BC seem ok. > > - IRComparer new compareImage > shows 16 differences, mostly pop-combining and unused code after return skipped, seems good. > (this compares #abstractSymbolic on the bytecode level) > > - IRComparer new compareImageFrameSize > 10 methods have smaller framesize , 2 a larger one. > This needs to be checked. > > 2) AST to IR > AST-IR-BC > - OCRecompiler new inspect; recompileImage > shows 10 problems. 2 are undeclareds, one is related to primitive errors (which > is not yet supported). Rest are wrong stack depth on jump targets in the backend. > - CompilerComparer new compare: Morph > (this compares #abstractSymbolic on the bytecode level) > ==> 39 differences, need to be analyzed (same for the whole image). Ok, this is where I may see things. To insert things in the AST, I can subclass the RBProgramNodeVisitor ? > 3) Missing: IR->AST, mapping BC to text offset needs to be checked, and then integration > into the system. Error handling, things like that. > > On the good side, > > OCRecompiler new doInstallMethods; recompileImage > > seems to work. (did not yet run too many tests, first the rest of the problems need to be > fixed). > > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > > Thanks! Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 21, 2012

Re: [Pharo-project] New System Progress Bar

by Schwab,Wilhelm K

Events are preferable to exceptions for updating the bar. Exceptions should be reserved for things that are exceptional :) Event registrations should be weak so that one *can* set and forget, but one should also be able to explicitly unregister if desired/needed. I will also take this opportunity to re-assert that weak collections should be inherently thread-safe and self-repairing. Pharo's weaklings do not measure up to Dolphin's in these areas. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Thursday, June 21, 2012 10:14 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] New System Progress Bar To help explain the changes, here's a snippet from the fix to "Issue 6099: Deprecate #value: for system progress (was red cross during updates)" (http://code.google.com/p/pharo/issues/detail?id=6099) The API (see SystemProgressItemMorph) is not set in stone, but it's already much less confusing than the old pseudo-class implementation. Ultimately, I'd like to move to announcements instead of exceptions to signal progress, and decouple the progress model/view - maybe just [un]registering the progress morph to enable/disable. The slice in the inbox for this issue should fix the "red cross during updates" problem... MOTIVATION: The old system progress worked like this (for example)... SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar value: x. bar value: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. * The work block ([ :bar | ... ] above) would accept one argument * That argument (:bar above) would be a block, that would act as a pseudo-class. Depending on what was passed to #value:, it would perform different functions. Two are illustrated above: - #value: aNumber; where aNumber is between the min and max of the progress range -> Set the bar's current progress mark to that position. For example, 'bar value: 50' above would show the operation half complete - #value: aString -> Set the label of the progress morph to aString This was very confusing, so we created a real class, SystemProgressItemMorph, which now gets passed to the work block, and has a real API. So, for example, the following becomes: SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar current: x. bar label: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. As you can see, '#value: newValue' has become '#current: newValue', and '#value: newLabel' has become '#label: newLabel'. One wrinkle is that some users were passing a nil-like block instead of the the pseudo-class to suppress the system progress bar. For example: informUserDuring: aBlock aBlock value: [:string | ]. Above, [:string | ] would now cause a DNU when sent, for example, #current:, which obviously blocks don't understand. So, these cases were changed like so: informUserDuring: aBlock aBlock value: DummySystemProgressItem new. Where DummySystemProgressItem simply ignores all messages without signaling an error -- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

Re: [Pharo-project] badDirectoryPath

by Esteban Lorenzano

that was changed not much time ago, and... while I don't remember exactly while it was like that, I remember there was a good reason for that On Jun 21, 2012, at 4:16 PM, Sean P. DeNigris wrote: > lookupDirectory: fullPath filename: fileName > <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> > ^ #badDirectoryPath > > Why are we returning #badDirectoryPath instead of signaling an exception, > maybe FileDoesNotExist? > > -- > View this message in context: http://forum.world.st/badDirectoryPath-tp4635913.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 21, 2012

Re: [Pharo-project] Tests Gueard report for 20144

by Sean P. DeNigris

Many of the tests from "Test guard for 20132" are now green. I guess maybe http://code.google.com/p/pharo/issues/detail?id=6069 is obsolete? Although, I see the two Gofer tests still failing here... -- View this message in context: http://forum.world.st/Tests-Gueard-report-for-20144-tp4635801p4635915.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

Re: [Pharo-project] Worskpace question

by Guillermo Polito

Maybe for a 5' experiment is well :). But World doOneCycle do handle events also, not just rendering, what should lead to a wrong state :). I don't forbid anybody to use it, just tell him to think about it :P. On Thu, Jun 21, 2012 at 4:13 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi: > > On 21 Jun 2012, at 15:57, Guillermo Polito wrote: > > > I bet there is a Morphic API that allows you to process the next drawing > request. > > > > Hmm, that sounds like forcing the framework... I think that having a > second process is the right way... > > For an experiment? Getting the concurrency right in a second process sound > a lot less appealing than using `World doOneCycle`, which seems to be used > in other places for the same purpose as well: > > MorphicUIManager>>#spawnNewProcess > UIProcess := [ > [World doOneCycle. Processor yield. false] whileFalse: []. > ] newProcess priority: Processor userSchedulingPriority. > UIProcess resume > > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > >

June 21, 2012

[Pharo-project] badDirectoryPath

by Sean P. DeNigris

lookupDirectory: fullPath filename: fileName <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> ^ #badDirectoryPath Why are we returning #badDirectoryPath instead of signaling an exception, maybe FileDoesNotExist? -- View this message in context: http://forum.world.st/badDirectoryPath-tp4635913.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

[Pharo-project] New System Progress Bar

by Sean P. DeNigris

To help explain the changes, here's a snippet from the fix to "Issue 6099: Deprecate #value: for system progress (was red cross during updates)" (http://code.google.com/p/pharo/issues/detail?id=6099) The API (see SystemProgressItemMorph) is not set in stone, but it's already much less confusing than the old pseudo-class implementation. Ultimately, I'd like to move to announcements instead of exceptions to signal progress, and decouple the progress model/view - maybe just [un]registering the progress morph to enable/disable. The slice in the inbox for this issue should fix the "red cross during updates" problem... MOTIVATION: The old system progress worked like this (for example)... SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar value: x. bar value: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. * The work block ([ :bar | ... ] above) would accept one argument * That argument (:bar above) would be a block, that would act as a pseudo-class. Depending on what was passed to #value:, it would perform different functions. Two are illustrated above: - #value: aNumber; where aNumber is between the min and max of the progress range -> Set the bar's current progress mark to that position. For example, 'bar value: 50' above would show the operation half complete - #value: aString -> Set the label of the progress morph to aString This was very confusing, so we created a real class, SystemProgressItemMorph, which now gets passed to the work block, and has a real API. So, for example, the following becomes: SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar current: x. bar label: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. As you can see, '#value: newValue' has become '#current: newValue', and '#value: newLabel' has become '#label: newLabel'. One wrinkle is that some users were passing a nil-like block instead of the the pseudo-class to suppress the system progress bar. For example: informUserDuring: aBlock aBlock value: [:string | ]. Above, [:string | ] would now cause a DNU when sent, for example, #current:, which obviously blocks don't understand. So, these cases were changed like so: informUserDuring: aBlock aBlock value: DummySystemProgressItem new. Where DummySystemProgressItem simply ignores all messages without signaling an error -- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

Re: [Pharo-project] Worskpace question

by Stefan Marr

Hi: On 21 Jun 2012, at 15:57, Guillermo Polito wrote: > I bet there is a Morphic API that allows you to process the next drawing request. > > Hmm, that sounds like forcing the framework... I think that having a second process is the right way... For an experiment? Getting the concurrency right in a second process sound a lot less appealing than using `World doOneCycle`, which seems to be used in other places for the same purpose as well: MorphicUIManager>>#spawnNewProcess UIProcess := [ [World doOneCycle. Processor yield. false] whileFalse: []. ] newProcess priority: Processor userSchedulingPriority. UIProcess resume Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

June 21, 2012