- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Opal ?

by Marcus Denker

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). 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

June 21, 2012

Re: [Pharo-project] Worskpace question

by Guillermo Polito

On Thu, Jun 21, 2012 at 3:44 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > > On 21 Jun 2012, at 15:11, Hilaire Fernandes wrote: > > > I want to see the animation of the growing morph. > > Instead I get nothing. > > > > To get the animation, you have to enclose the loop in a forked process, > > but it is inelegant: > > Isn't the doIt evaluated in the UI processes? > > It is! > 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... > If the doIt is not evaluated in the UI process, just to a `Processor > yield` after every step you want to see. > Sometimes, when processing in different process, the correct way is to send updates to the UI process through World addDeferredUIMessage: [ ... ] Cheers, Guille > > 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

Re: [Pharo-project] Worskpace question

by Stefan Marr

On 21 Jun 2012, at 15:11, Hilaire Fernandes wrote: > I want to see the animation of the growing morph. > Instead I get nothing. > > To get the animation, you have to enclose the loop in a forked process, > but it is inelegant: Isn't the doIt evaluated in the UI processes? I bet there is a Morphic API that allows you to process the next drawing request. If the doIt is not evaluated in the UI process, just to a `Processor yield` after every step you want to see. 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

Re: [Pharo-project] Opal ?

by Goubier Thierry

Le 21/06/2012 15:30, Jean Baptiste Arnaud a Ã©crit : > > On Jun 21, 2012, at 3:22 PM, Goubier Thierry wrote: > >> Le 21/06/2012 15:16, Jean Baptiste Arnaud a Ã©crit : >>> >>> I understand but the logic itself will not change. The design is done. >>> The used case too. But it is not perfect but you put a lot of energy >>> on it. >>> M. Goubier want to to port its code, i think it should try, and if some >>> problem happen raise the issue. Instead to try and spend week on the old >>> compiler. >>> The experiment match perfectly with the opal Spirit. And we have someone >>> motivated to perform a experiment on Opal, don't say no. >> >> And you need to be motivated. > > 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? So far, I have only the IRDecompilerTests which are failing. Thierry >> Opal depends on Petit Parser, which depends on RB, where it should >> stop (I hope). >> >> 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 >> > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com <mailto:jbaptiste.arnaud@gmail.com> > > > > > > > -- 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] Opal ?

by Goubier Thierry

Le 21/06/2012 15:28, Frank Shearar a Ã©crit : > On 21 June 2012 14:22, Goubier Thierry<thierry.goubier(a)cea.fr> wrote: >> Le 21/06/2012 15:16, Jean Baptiste Arnaud a Ã©crit : >>> >>> >>> I understand but the logic itself will not change. The design is done. >>> The used case too. But it is not perfect but you put a lot of energy on >>> it. >>> M. Goubier want to to port its code, i think it should try, and if some >>> problem happen raise the issue. Instead to try and spend week on the old >>> compiler. >>> The experiment match perfectly with the opal Spirit. And we have someone >>> motivated to perform a experiment on Opal, don't say no. >> >> >> And you need to be motivated. >> >> Opal depends on Petit Parser, which depends on RB, where it should stop (I >> hope). > > PetitParser does not depend on RB. It depends on AST-Core and > AST-Compiler, which are (small) _parts_ of RB. Thanks. It's hard to guess which subsets of RB are needed when you encounter an error with some RB prefixed classes when loading a package. 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