April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SimpleMorphic adoption schedule

by StÃ©phane Ducasse

On Apr 1, 2011, at 1:48 PM, Fernando Olivero wrote: > HI Tudor, i guess porting and updating SMx from the latest version > in CUIS, would be made around next week. > > This would give us: new Morph kernel, significantly simplified layout, > basic widgets simplified and unified ( for example only one class for > buttons) and anti-alised rounded corners for windows and buttons( Juan > implemented this taking ideas from Morphic3, way better than the OS > native widgets, just take a look at CUIS ). > > Then > > * Integrating Alain's editor state into the text morphs views > shouldn't take more than one day. > > ( I believe Glamour only requires up to here). fernando I do not think so. Glamour needs more. But we should start and see. > > * When Ben releases Nautilus, we would have to port it to SMx. ( to > have standard browsers) > * Polymorph and SMx merge, would take quite a while, depending on the > amount of people we get involved. > > So i dont know how much would it take to replace entirely Morphic with > SMx, having all the features of Polymorph also. Highly depends on the > people involved in this effort. > > But having a simple version of SMx, is feasible within 15 days . and > then gradually add pieces till we can trash any Old-Morphic > dependance. > > Fernando > > On Thu, Mar 31, 2011 at 12:56 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi Fernando, >> >> These are good news. >> >> I am very interested in using this in Glamour. Just one question: What is the expected schedule? >> >> Cheers, >> Doru >> >

April 1, 2011

Re: [Pharo-project] Solarized Color Scheme

by StÃ©phane Ducasse

the red in @param in java does not work so it is strange same remarks for ruby. Now the text color is nice and lavande are nice but I wonder for color blind people On Apr 1, 2011, at 1:27 PM, Tudor Girba wrote: > Interesting link. Thanks. > > Cheers, > Doru > > > On 1 Apr 2011, at 13:22, Sven Van Caekenberghe wrote: > >> I remember there were some discussions about (theme / syntax highlighting) colors on this list in the past, and someone said that picking good colors is an art. I came across this site: >> >> http://ethanschoonover.com/solarized >> >> And it seems to me that this could be a good basis for a professional color scheme in one of Pharo's look and feels. As a fan / user of Glamorous, using the light theme on top of it would seem great. >> >> I am just posting this as a way to bookmark this link and because it might be useful. >> >> Solarized is MIT licensed. >> >> Sven >> >> > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > >

April 1, 2011

Re: [Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #9 on issue 2559 by nicolas....(a)gmail.com: Senders of #ifNotNil: do not show http://code.google.com/p/pharo/issues/detail?id=2559 I forgot to say, recompileAll is required so as to be able to browse special senders

April 1, 2011

Re: [Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

by pharo＠googlecode.com

Comment #8 on issue 2559 by nicolas....(a)gmail.com: Senders of #ifNotNil: do not show http://code.google.com/p/pharo/issues/detail?id=2559 Name: SLICE-Issue-2559-SpecialMessages-browseThem-cascadeThem-overrideThem-nice.1 Dependencies: Compiler-nice.279 Let special selectors be a bit less special. Special selectors are inlined by the compiler if receiver and arguments follow certain rules (like being a block with prescribed number of arguments).. Inlining is very important for speeding up execution but there was a price to pay: 1) Until now, in case the rules are not followed, Compiler would sometimes send the message as an ordinary one, and would sometimes refuse to compile (though I already relaxed the rules a lot in the past few years). 2) Also you could not browse reference to them because they were inlined and had no marker in CompiledMethod. 3) And Compiler would refuse to cascade them because inlining was harder to implement in such case. Now, you can. 1) not respect the rules (in this case the message will always be sent) 2) browse references (there is literal added to the compiled code) 3) cascade (in a cascade, no message is inlined) While at it I removed the odd rules for compiling caseOf: and that simplifies Compiler. There is no support yet to prevent inlining, and thus to enable true overriding (if receiver/arguments respect the rules, message won't be sent but still inlined with a hardcoded implementation). However, you can hack by using any other argument but a Block: (2>1) ifTrue: ['print me'] yourself. This way you could activate your own override of ifTrue: Also you can write this if you feel like: (2>1) ifTrue: [2 inspect]; and: [2 odd]. Of course, from pragmatic point of view, you won't probably need this stuff. But if we can avoid useless sacrifices, let's avoid.

April 1, 2011

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