- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Regarding SimpleMorphic

by csrabak＠bol.com.br

Em 31/03/2011 18:10, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> escreveu: > On Mar 31, 2011, at 8:08 PM, csrabak(a)bol.com.br wrote: > > > Benjamin, > > Testing the understanding of the diagram of yours: > > Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser > > Model, Debugger and Debugger Model all inherit from Object? > > the representation of "based on" means that it changes states in > > the model counterpart, and "use" means that has some similarity > > but not enough to inherit from the other classes? > > based on means, that the view (on right) is based on the model (on > left) This still tautological: does "based on" means the structure is one-to-one correspondent? Or are we re-introducing the MVC paradigm and the "based on" means that the View has to know the inners of the Model in order to be built? > use means that the View use/is composed with the other view. > By example, Browser is based on BrowserModel, and Browser (as a > Morph by example) contains a PluggableCodeMorph This one explains well your thought, or at least I've the belief I understood. > > > Is it better like that ? The second part, much better, for the first one I'm still lost :-( > (I'm sorry, but I'm not sure to be able to do a good UML ^^) OK. Let's see if after fully understanding your idea we can come by something.

April 1, 2011

[Pharo-project] Issue 3938 in pharo: Fix ugly flashing in list morph

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3938 by marcus.d...(a)gmail.com: Fix ugly flashing in list morph http://code.google.com/p/pharo/issues/detail?id=3938 .. especially bad with a apple mouse that tries to scroll left and right Attachments: FlashFix.1.cs 2.7 KB

April 1, 2011

Re: [Pharo-project] [update 1.3] #13127 - 13129

by Eliot Miranda

On Fri, Apr 1, 2011 at 9:26 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Eliot signalled recently in squeak-dev that a Compiler recompileAll > was necessary because of some decompiler edge cases, but I did not > understand fully why. > Maybe we can differ it after integrating Issue 2559 > One doesn't need a recompileAll. The following will do just fine: (SystemNavigation new allCallsOn: #repeat) do: [:ea| ea actualClass recompile: ea methodSymbol] In general if one changes the set if inlined selectors one should recompile all senders of those selectors. The decompiler assumes that it is decompiling the same btecodes as the current compiler produces for the methods source. Hence the bytecode needs to be kept in sync with the compiler. > > Nicolas > > 2011/4/1 Marcus Denker <marcus.denker(a)inria.fr>: > > [update 1.3] #13127 - 13129 > > > > Issue 3934: Add isDisplayed in SystemWindow (Benjamin) > > Issue 3933: Better behavior for selection in PluggableListMorphOfMany > and PluggableMorphListMorphOfMany (Benjamin) > > Issue 2360: [Failing Test] nil out locals in a block if > readBeforeWritten (Nicolas) > > > > Thanks a lot Nicolas!! > > > > Part1: > > > > First stage for reducing Squeak/Pharo Compiler differences: > > This is a pre-requisite for > > issue 2360 > > > > > > - let visitor pattern #accept: return its own result rather than the node > > - remove old code generation methods > > - merge ByteCodeAgnosticMethodNode into MethodNode > > > > MessageNode initialize must be performed at the end of this stage. > > > > Part 2: > > > > - correctly move 'locationCounter localsPool' in MethodNode ivar (they > were undeclared) > > - use #notOptimizedIn: rather #than noteOptimized. > > - do not optimize a todo that would overwrite its limit (common changes > with 3677) > > - connect the OptimizedBlockLocalTempReadBeforeWrittenVisitor to > nilReadBeforeWrittenTemps in optimized blocks > > - add #testOptimizedBlockLocalNilling1 and > #testOptimizedBlockLocalNilling2 > > > > Part 3: > > > > This change includes Compiler and Decompiler changes to handle optimized > #repeat loops. > > Note that MessageNode class>>#initialize of Part2 already includes > necessary hook. > > (Sorry, some methods have changed several times in trunk, and it's easier > to upgrade several fixes at once). > > If you don't want this change in Pharo (why ?) then don't forget to > change MessageNode class>>#initialize > > > > > > > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > > >

April 1, 2011

[Pharo-project] encouraging the ACM to provide some Mac pages templates

by Eliot Miranda

Hi All, I've just seen Theo's call for papers for the Dynamic Languages Symposium in October and I'm going to write a paper on Cog. Alas I see that the ACM has yet to provide any templates other that for Word and LaTeX. I'm a fan of Apple's Pages word processor for Mac OS X, part of their iWork suite, as I'm sure many of you are. Anyway, I have this morning contacted the ACM's Electronic Publishing Manager, Gerald Murray, and he has asked me to send him an email asking for such a template. He can't make the decision on his own but has agreed to submit the request higher up the chain, and as we discussed it would help if I could add additional voices in support. So if you are interested in a Pages ACM paper template or you're interested in other researchers having access to the same please reply to this email, indicating whether you're an ACM member or not, and whether you've submitted a paper or three beforehand, and I'll add your name and email address to my submission. Also feel free to spread this request far and wide to other Mac-centric folk who would be interested. I'll send the email on Monday, April 4th. And just so you're sure, this is /not/ an April Fool. AdvThanksance. best Eliot

April 1, 2011

[Pharo-project] Issue 3937 in pharo: Breaking Announcement system

by pharo＠googlecode.com

Status: Accepted Owner: Benjamin...(a)gmail.com Labels: Milestone-1.3 New issue 3937 by Benjamin...(a)gmail.com: Breaking Announcement system http://code.google.com/p/pharo/issues/detail?id=3937 If an error occur during the propagation of an Announcement, then the further receiver will not be informed ... It can break the system easily because it breaks the synchronicity

April 1, 2011

Re: [Pharo-project] [update 1.3] #13127 - 13129

by Nicolas Cellier

Eliot signalled recently in squeak-dev that a Compiler recompileAll was necessary because of some decompiler edge cases, but I did not understand fully why. Maybe we can differ it after integrating Issue 2559 Nicolas 2011/4/1 Marcus Denker <marcus.denker(a)inria.fr>: > [update 1.3] #13127 - 13129 > > Issue 3934: Â Â Add isDisplayed in SystemWindow (Benjamin) > Issue 3933: Â Â Better behavior for selection in PluggableListMorphOfMany and PluggableMorphListMorphOfMany (Benjamin) > Issue 2360: Â Â [Failing Test] nil out locals in a block if readBeforeWritten (Nicolas) > > Thanks a lot Nicolas!! > > Part1: > > First stage for reducing Squeak/Pharo Compiler differences: > This is a pre-requisite for > issue 2360 > > > - let visitor pattern #accept: return its own result rather than the node > - remove old code generation methods > - merge ByteCodeAgnosticMethodNode into MethodNode > > MessageNode initialize must be performed at the end of this stage. > > Part 2: > > - correctly move 'locationCounter localsPool' in MethodNode ivar (they were undeclared) > - use #notOptimizedIn: rather #than noteOptimized. > - do not optimize a todo that would overwrite its limit (common changes with 3677) > - connect the OptimizedBlockLocalTempReadBeforeWrittenVisitor to nilReadBeforeWrittenTemps in optimized blocks > - add #testOptimizedBlockLocalNilling1 and #testOptimizedBlockLocalNilling2 > > Part 3: > > This change includes Compiler and Decompiler changes to handle optimized #repeat loops. > Note that MessageNode class>>#initialize of Part2 already includes necessary hook. > (Sorry, some methods have changed several times in trunk, and it's easier to upgrade several fixes at once). > If you don't want this change in Pharo (why ?) then don't forget to change Â MessageNode class>>#initialize > > > > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

April 1, 2011

[Pharo-project] Issue 3936 in pharo: should recompile whole image in update

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3936 by marcus.d...(a)gmail.com: should recompile whole image in update http://code.google.com/p/pharo/issues/detail?id=3936 should recompile whole image in update... with all those compiler changes

April 1, 2011

Re: [Pharo-project] Issue 3934 in pharo: Add isDisplayed in SystemWindow

by Gary Chambers

Is not #isInWorld not sufficient? Regards, Gary ----- Original Message ----- From: <pharo(a)googlecode.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Friday, April 01, 2011 4:09 PM Subject: [Pharo-project] Issue 3934 in pharo: Add isDisplayed in SystemWindow > Status: FixProposed > Owner: Benjamin...(a)gmail.com > Labels: Nautilus > > New issue 3934 by Benjamin...(a)gmail.com: Add isDisplayed in SystemWindow > http://code.google.com/p/pharo/issues/detail?id=3934 > > isDisplayed > " Answer true if I am a submorph of World, ie if I am displayed " > > Attachments: > SystemWindow.BenjaminVanRyseghem.1.cs 303 bytes > >

April 1, 2011

[Pharo-project] Issue 3935 in pharo: remove TranscriptTest from Deprecated 13

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3935 by marcus.d...(a)gmail.com: remove TranscriptTest from Deprecated 13 http://code.google.com/p/pharo/issues/detail?id=3935 remove TranscriptTest from Deprecated 13

April 1, 2011

Re: [Pharo-project] Issue 2360 in pharo: [Failing Test] nil out locals in a block if readBeforeWritten

by pharo＠googlecode.com

Updates: Status: Closed Comment #17 on issue 2360 by marcus.d...(a)gmail.com: [Failing Test] nil out locals in a block if readBeforeWritten http://code.google.com/p/pharo/issues/detail?id=2360 all now in 13129

April 1, 2011