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

Re: [Pharo-project] A step toward reducing complexity

by StÃ©phane Ducasse

We should rename it and fork it so that doru gets less conflicts Stef On Mar 25, 2011, at 9:08 AM, Tudor Girba wrote: > Thanks, Doug. This was on my to do list for a long time. > > Just a note: GLMUITheme is part of Glamour. Please do not fork it in Pharo and integrate fixes there because then it will just get messy. I will integrate it in Glamour. > > If you want to evolve it in the context of Pharo, you should rename it an put it in a different package (this would probably make sense anyway). > > Cheers, > Doru > > > On 25 Mar 2011, at 08:44, StÃ©phane Ducasse wrote: > >> Thanks. >> May be the windowActiveDropShadowStyle could be just added to the UITheme class? >> >> Open a bug entry and attach code or slice there so that >> - have a look >> - not forget to integrate the fix. >> >> Stef >> >>> Reduce the complexity of user interface themes >>> >>> In general, user interface themes should inherit directly from UITheme, not >>> from a chain of themes. When you have a chain of themes, you are stuck with >>> the intermediate themes, whether you need/use them or not. Consider >>> GLMUITheme. Currently it is under UIThemeWatery2, which is under >>> UIThemeWatery, which is under UITheme. >>> >>> Some characteristics inherited from the chain are missing, but in principal, >>> GLMUITheme can be moved directly under UITheme with just 3 changes. >>> >>> 1. Add an instanceVariable 'windowActiveDropShadowStyle' >>> >>> UITheme subclass: #GLMUITheme >>> instanceVariableNames: 'windowActiveDropShadowStyle' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Glamour-Morphic-Theme' >>> >>> 2. Add a class method >>> >>> isAbstract >>> "Answer whether the receiver is considered to be abstract." >>> ^false >>> >>> 3. Add an instance method >>> >>> windowActiveDropShadowStyle: anObject >>> "Set the value of windowActiveDropShadowStyle" >>> windowActiveDropShadowStyle := anObject >>> >>> >>> Because GLMOrangeUITheme inherits these changes, it does not need >>> modification. >>> >>> >>> -- >>> View this message in context: http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.h… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > >

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by StÃ©phane Ducasse

For example I took the soup package and I added comments and tests After a couple of days the package was cooler. And this can be done by a lot of people. Stef > > On Mar 24, 2011, at 10:30 PM, nullPointer wrote: > >> I donÂ´t understand something. The implementation of new widgets will based on >> SimpleMorphic, o really will be the base Morph is based in SimpleMorphic? > > > From what I see and after the discussion with alain: > we should build new widget on Morphic and after port them to the new core he has in mind. > >> If I could create new widgets and new UI functionalities I must work with >> SimpleMorphic? > > Not really except if you start to clean SimpleMorphic and migrate other code there too. > >> Will be change some things for work with openGL or others or really all is >> based in classic morphic? > > We do not know. Right now we should get a new canvas. > > Now if you want to see this front moving faster, you should help us because you played a lot with the system > and you know more than most of us. >> >> Regards. >> >> -- >> View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3403869.… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by StÃ©phane Ducasse

Geert the key problem is that if people do not jump in the water and decide to do something then nothing will happen beside reporting what other cool communities are doing. So of course been aware that technology YZ K has a cool stuff is important, but more important is to build our own. What I learned is that if every I do something then I make progress every single day. So if all of us would open our browser and produce a little something then everyday we would do a large progress. Stef > > StÃ©phane Ducasse wrote: >> >> ... >> We are rewriting from scratch the basic tools >> - Browser (Nautilus soon to be announced - with groups, package browsers, >> refactorings, may be plugin architecture) >> - Finder >> - TestRunner (soon) >> - MCBrowser >> ... >> > > Yes, it would be great if it were easier to create/modify/customize Pharo's > tools! When rewriting I hope this will include improving the usability and > intuitiveness to get non-Smalltalkers up-to-speed faster. > > ps. on a side note, has anyone seen Jens MÃ¶nig's javascript morphic in the > browser http://www.chirp.scratchr.org/blog > http://www.chirp.scratchr.org/blog great stuff, make sure to watch the demo > on his iPad! > > -- > View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3404753.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 25, 2011

Re: [Pharo-project] A step toward reducing complexity

by DougEdmunds

Not my intention to fork it. It does pick up some characteristics from the chain, which I didn't explore. On 3/25/2011 1:09 AM, Tudor Girba [via Smalltalk] wrote: > Thanks, Doug. This was on my to do list for a long time. > > Just a note: GLMUITheme is part of Glamour. Please do not fork it in > Pharo and integrate fixes there because then it will just get messy. I > will integrate it in Glamour. > > If you want to evolve it in the context of Pharo, you should rename it > an put it in a different package (this would probably make sense anyway). > > Cheers, > Doru > > > On 25 Mar 2011, at 08:44, StÃ©phane Ducasse wrote: > >> Thanks. >> May be the windowActiveDropShadowStyle could be just added to the > UITheme class? >> >> Open a bug entry and attach code or slice there so that >> - have a look >> - not forget to integrate the fix. >> >> Stef >> >>> Reduce the complexity of user interface themes >>> >>> In general, user interface themes should inherit directly from > UITheme, not >>> from a chain of themes. When you have a chain of themes, you are > stuck with >>> the intermediate themes, whether you need/use them or not. Consider >>> GLMUITheme. Currently it is under UIThemeWatery2, which is under >>> UIThemeWatery, which is under UITheme. >>> >>> Some characteristics inherited from the chain are missing, but in > principal, >>> GLMUITheme can be moved directly under UITheme with just 3 changes. >>> >>> 1. Add an instanceVariable 'windowActiveDropShadowStyle' >>> >>> UITheme subclass: #GLMUITheme >>> instanceVariableNames: 'windowActiveDropShadowStyle' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Glamour-Morphic-Theme' >>> >>> 2. Add a class method >>> >>> isAbstract >>> "Answer whether the receiver is considered to be abstract." >>> ^false >>> >>> 3. Add an instance method >>> >>> windowActiveDropShadowStyle: anObject >>> "Set the value of windowActiveDropShadowStyle" >>> windowActiveDropShadowStyle := anObject >>> >>> >>> Because GLMOrangeUITheme inherits these changes, it does not need >>> modification. >>> >>> >>> -- >>> View this message in context: > http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.h… > <http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.h…> >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > > > > > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404765.h… > > To unsubscribe from A step toward reducing complexity, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. > -- View this message in context: http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404773.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by StÃ©phane Ducasse

On Mar 24, 2011, at 10:30 PM, nullPointer wrote: > I donÂ´t understand something. The implementation of new widgets will based on > SimpleMorphic, o really will be the base Morph is based in SimpleMorphic? >From what I see and after the discussion with alain: we should build new widget on Morphic and after port them to the new core he has in mind. > If I could create new widgets and new UI functionalities I must work with > SimpleMorphic? Not really except if you start to clean SimpleMorphic and migrate other code there too. > Will be change some things for work with openGL or others or really all is > based in classic morphic? We do not know. Right now we should get a new canvas. Now if you want to see this front moving faster, you should help us because you played a lot with the system and you know more than most of us. > > Regards. > > -- > View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3403869.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 25, 2011

Re: [Pharo-project] A step toward reducing complexity

by Tudor Girba

Thanks, Doug. This was on my to do list for a long time. Just a note: GLMUITheme is part of Glamour. Please do not fork it in Pharo and integrate fixes there because then it will just get messy. I will integrate it in Glamour. If you want to evolve it in the context of Pharo, you should rename it an put it in a different package (this would probably make sense anyway). Cheers, Doru On 25 Mar 2011, at 08:44, StÃ©phane Ducasse wrote: > Thanks. > May be the windowActiveDropShadowStyle could be just added to the UITheme class? > > Open a bug entry and attach code or slice there so that > - have a look > - not forget to integrate the fix. > > Stef > >> Reduce the complexity of user interface themes >> >> In general, user interface themes should inherit directly from UITheme, not >> from a chain of themes. When you have a chain of themes, you are stuck with >> the intermediate themes, whether you need/use them or not. Consider >> GLMUITheme. Currently it is under UIThemeWatery2, which is under >> UIThemeWatery, which is under UITheme. >> >> Some characteristics inherited from the chain are missing, but in principal, >> GLMUITheme can be moved directly under UITheme with just 3 changes. >> >> 1. Add an instanceVariable 'windowActiveDropShadowStyle' >> >> UITheme subclass: #GLMUITheme >> instanceVariableNames: 'windowActiveDropShadowStyle' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Glamour-Morphic-Theme' >> >> 2. Add a class method >> >> isAbstract >> "Answer whether the receiver is considered to be abstract." >> ^false >> >> 3. Add an instance method >> >> windowActiveDropShadowStyle: anObject >> "Set the value of windowActiveDropShadowStyle" >> windowActiveDropShadowStyle := anObject >> >> >> Because GLMOrangeUITheme inherits these changes, it does not need >> modification. >> >> >> -- >> View this message in context: http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.h… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- www.tudorgirba.com "We are all great at making mistakes."

March 25, 2011

Re: [Pharo-project] GUIs with Pharo / how to learn smalltalk

by StÃ©phane Ducasse

Hi Daniel > I have two questions, a technical one and a more general one. > > In broad strokes, what are people doing for GUIs? My guess would be using Morphic, but googling around you find more abuse than use, it looks like, and very little live links to up-to-date documentation. It makes me wonder: is there something other than Morphic which is being used? Or is everyone doing web apps? Or is there some other GUI toolkit I haven't found yet, and that's where all the action is? Whenever I see a neat Morphic window or something, I feel a bit like there's a party going on somewhere and I didn't get an invitation. Like the first rule of Morphic club is you don't talk about Morphic club. Not really truth. :) Now we are cleaning the system and trying to make sure that we understand it. However it does not prevent you to learn. Look at Benjamin: (a smart second year students), he built Finder and now he is building Nautilus. Start by looking at some examples and ask for feedback. People will help you. Now this is clear that the documentation is not at the level it should be. > The general question I have is basically, am I the problem? No > Is it that the documentation isn't where I expect to find it, or in the form I'm used to seeing, or that it isn't relevant somehow in the Smalltalk universe? If you can VisualWorks there is a lot of documentation. Now they have engineers too. > Or is it all really intuitive except for me? :) No I'm often puzzled too. The point is that I learn everyday more about the system and when I do not like the way it is done I try to fix it. My main goal is to learn every day. Sometimes this is frustrating but in general it works. > I could accept that, I suppose, but how did you Smalltalk wizards become wizards? I do not know. But probably starting to read - mailing-list - read the code - break it by putting the wrong self halt at the wrong place The cool aspect of Pharo is that it is really improving day after day. And that when there is something ugly you can be sure that one of these days we will fix it. Now we should go step by step. > Did you just dive in and start reading the code in your own image? Yes. When I started been an harvester for Squeak, here is what I did. read the bug report (there was none so it was easy) read the submitted code and if I do not understand pass to the next one until I find something that I can understand I still do that everyday. My goal is to have read a lot of the code. > Was there some master Smalltalk wizard that you knew who showed you how to do these things? I learned smalltalk alone. Now if you can pair program with somebody this is much cooler. You have pharoCasts, have a look at them. > I'm currently reading Smalltalk Best Practice Patterns Excellent book > and it's one of the best programming books I've ever read. I see that there is a great deal of mastery of programming going around in Smalltalk circles, but I don't see the books that take you past beginner towards master, You have smalltalk by example (even if it is for VW I like it). It is more about design than Pharo by example and I would like to have one like that in the future but too busy right now. > other than SBPP. So what's the trick going on here? How did you guys become excellent? > > I hope none of this comes across as negative; Not at all. We know our problems > I think surely it's that I'm missing something. > > Thanks, > > â > Daniel Lyons > >

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by Geert Claes

StÃ©phane Ducasse wrote: > > ... > We are rewriting from scratch the basic tools > - Browser (Nautilus soon to be announced - with groups, package browsers, > refactorings, may be plugin architecture) > - Finder > - TestRunner (soon) > - MCBrowser > ... > Yes, it would be great if it were easier to create/modify/customize Pharo's tools! When rewriting I hope this will include improving the usability and intuitiveness to get non-Smalltalkers up-to-speed faster. ps. on a side note, has anyone seen Jens MÃ¶nig's javascript morphic in the browser http://www.chirp.scratchr.org/blog http://www.chirp.scratchr.org/blog great stuff, make sure to watch the demo on his iPad! -- View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3404753.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011

Re: [Pharo-project] [squeak-dev] positionalMesssge breaks literal array parsing

by Igor Stasenko

On 25 March 2011 08:14, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Anyway, if we would keep an alternate syntax,I recommend using a > subclass of Parser and leave the SmalltalkParser alone. > +1 > Nicolas > > 2011/3/25 Matthew Fulmer <tapplek(a)gmail.com>: >> On Thu, Mar 24, 2011 at 02:12:31PM -0700, Eliot Miranda wrote: >>> What is this support for? Â Is it for those funky ffi calls in the OpenGL >>> code? Â Can it not be hoisted out of the scanner and into the parser proper? >>> [and optimistically anyone have a fix already?] >> >> I was under the impression those were never in the compiler. I >> had to add the support to the Compiler myself (the code was in >> the inbox, but now has been removed to the treated inbox). >> OpenGL no longer has positional methods; they were removed >> >> -- >> Matthew Fulmer (a.k.a. Tapple) >> >> > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

Re: [Pharo-project] pharo closures

by StÃ©phane Ducasse

On Mar 25, 2011, at 2:51 AM, Toon Verwaest wrote: > Ok, I will do so. (read the f-ing paper) I only read the blogpost until now. which paper? Is there something more than the blog? I read the old VW5 paper but eliot told me that this is old and not accurate with Cog anymore. > > I just realized that I actually made a mistake in my mental model of your model. See! It's complex! > So I realized that getting to the remotes is exactly as fast as going to the parent or outer context. > > This makes it as fast as having a method context with maximally 2 nested contexts (3 blocks nested), and faster than deeper nestings. How often does it occur that you have deeper nesting in Pharo? Is it worthwhile to make the remote arrays just for those cases? > > Is the copying really worthwhile to make those cases faster? > > My biggest problem until now is... why wouldn't you be able to do everything you do with the remote arrays, directly with the context frames? Why limit it to only the part that is being closed over? The naive implementation that just extends squeak with proper closure-links will obviously be slow. I agree that you need a stack. Now I'd just like to read why you choose to just take a part of the frame (the remote array) rather than the whole frame. This would avoid the copyTemps thing... > > But then. I guess I should go off and read the f-ing paper. I hope that particular thing is described there, since it's basically the piece I'm missing. > > Also I don't exactly know what Peter Deutsch did, but if it was the straightforward implementation then it seems obvious you get such a speedup. Implementing it is less obvious, naturally ;) > These responses are exactly why I posed the question here... I'd like to understand why. No offense. > > cheers, > Toon > > > On 03/25/2011 02:22 AM, Eliot Miranda wrote: >> Toon, >> >> what you describe is how Peter Deutsch designed closures for ObjectWorks 2.4 & ObjectWorks 2.5, whose virtual machine and bytecode set served all the way through VisualWorks 3.0. If you read the context management paper you'll understand why this is a really slow design for a JIT. When I replaced that scheme by one essentially isomorphic to the Squeak one the VM became substantially faster; for example factors of two and three in exception delivery performance. The description of the problem and the performance numbers are all in the paper. There are two main optimizations I performed on the VisualWorkas VM, one is the closures scheme and the other is PICs. Those together sped-up what was the fastest commercial Smalltalk implementation by a factor of two on most platforms and a factor of three on Windows. >> >> I'm sorry it's complex, but if one wants good performance it's a price well-worth paying. After all I was able to implement the compiler and decompiler within a month, and Jorge proved at INRIA-Lille that I'm far form the only person on the planet who understands it. Lispers have understood the scheme for a long time now. >> >> best, >> Eliot >> >> On Thu, Mar 24, 2011 at 6:01 PM, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: >> >> I can't say that i clearly understood your concept. But if it will >> simplify implementation >> without seemingly speed loss, i am all ears :) >> >> >> test >> |b| >> [ |a| >> a + b ] >> >> Suppose you can't compile anything away, then you get >> >> |============== >> |MethodContext >> | >> |a := ... >> |============== >> ^ >> | >> |============== >> |BlockContext >> | >> |b := ... >> |============== >> >> And you just look up starting at the current context and go up. Except if the var is from the homeContext, then you directly follow the home-context pointer. >> Since all contexts link to the home-context, this makes it 1 pointer indirection to get to the method's context. 1 for the parent context. So that makes only 2 indirections starting from the 3 nested block (so when you have [ ... [ ... [ ... ] ... ] ... ]; where all of them are required for storing captured data. ifTrue:ifFalse: etc blocks obviously don't count. And blocks without shared locals could be left out (although we might not do that, for debugging reasons). >> >> Hope that helps. >> >> cheers, >> Toon >> >> >

March 25, 2011