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

[Pharo-project] Issue 3877 in pharo: Check reduced complexity for UI themes

by pharo＠googlecode.com

Status: Accepted Owner: Torsten....(a)astares.de Labels: Milestone-1.3 New issue 3877 by Torsten....(a)astares.de: Check reduced complexity for UI themes http://code.google.com/p/pharo/issues/detail?id=3877 We should check if this: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-March/045170.html is an improvement.

March 25, 2011

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

by StÃ©phane Ducasse

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

March 25, 2011

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

by Alain Plantec

Hi nullPointer & all New widgets are built with Morphic. Morphic is the current UI framework for Pharo and it is important to improve it. SimpleMorphic is not well integrated and is far from be usable. the goal would be to build a new framework from it by cleaning it, by integrating polymorph into it and by migrating the new cool widgets of Benjamin and others into it. As Stephane said, I'm willing to dig into it. but it is not sure at all it is feasible, that I will succeed, that it will be a good solution... and currently I'm too busy and I try to not open pharo too often :( about opengl, i don't know, a good canvas is certainly the key. cheers Alain Le 24/03/2011 22:30, nullPointer a Ã©crit : > 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? > > If I could create new widgets and new UI functionalities I must work with > SimpleMorphic? > Will be change some things for work with openGL or others or really all is > based in classic morphic? > > 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] [squeak-dev] positionalMesssge breaks literal array parsing

by Nicolas Cellier

Anyway, if we would keep an alternate syntax,I recommend using a subclass of Parser and leave the SmalltalkParser alone. 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) > >

March 25, 2011

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

by Ricardo Moran

I'm not even close to being a smalltalk wizard, so I can't really answer your questions. However, you should probably read "Pharo by example" ( http://pharobyexample.org/) AFAIK it is one of the best books for newbies like me and it has a nice chapter about Morphic that should get you started. Also, you should probably look at Polymorph as well: http://www.pharocasts.com/search/label/gui. Cheers, Richo On Fri, Mar 25, 2011 at 2:48 AM, Daniel Lyons <fusion(a)storytotell.org>wrote: > Hi, > > 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. > > The general question I have is basically, am I the problem? 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? Or is > it all really intuitive except for me? :) I could accept that, I suppose, > but how did you Smalltalk wizards become wizards? Did you just dive in and > start reading the code in your own image? Was there some master Smalltalk > wizard that you knew who showed you how to do these things? I'm currently > reading Smalltalk Best Practice Patterns 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, 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; I think surely it's that I'm > missing something. > > Thanks, > > â > Daniel Lyons > > >

March 25, 2011

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

by laurent laffont

On Fri, Mar 25, 2011 at 6:48 AM, Daniel Lyons <fusion(a)storytotell.org>wrote: > Hi, > Hi, > > 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. > Documentation still poor, but have you looked at: http://www.pharocasts.com/search/label/gui http://book.pharo-project.org/book/GUI http://www.youtube.com/user/nullPointerSM and http://www.squeaksource.com/UIBuilder.html > The general question I have is basically, am I the problem? 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? Or is > it all really intuitive except for me? :) I could accept that, I suppose, > but how did you Smalltalk wizards become wizards? Did you just dive in and > start reading the code in your own image? Was there some master Smalltalk > wizard that you knew who showed you how to do these things? I'm currently > reading Smalltalk Best Practice Patterns 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, other than SBPP. So > what's the trick going on here? How did you guys become excellent? > It's not intuitive, disturbing, took me some time to learn basic stuff, but had a lot of fun and discovered lot of beauty. I learn by doing some documenting project like ProfStef, Pharocasts, COTD and writing some personal tools with Pharo. > I hope none of this comes across as negative; I think surely it's that I'm > missing something. > That's not negative. It just shows that some work is still needed to lower the barrier for newcomers. Please help :) Laurent. > > Thanks, > > â > Daniel Lyons > > >

March 25, 2011

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

by Daniel Lyons

Hi, 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. The general question I have is basically, am I the problem? 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? Or is it all really intuitive except for me? :) I could accept that, I suppose, but how did you Smalltalk wizards become wizards? Did you just dive in and start reading the code in your own image? Was there some master Smalltalk wizard that you knew who showed you how to do these things? I'm currently reading Smalltalk Best Practice Patterns 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, 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; I think surely it's that I'm missing something. Thanks, â Daniel Lyons

March 25, 2011

Re: [Pharo-project] "Does Committing Code to an Open Source Project Mean Committing Career Suicide?"

by DougEdmunds

"Does Committing Code to an Open Source Project Mean Committing Career Suicide?" No. -- View this message in context: http://forum.world.st/Does-Committing-Code-to-an-Open-Source-Project-Mean-C… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011

[Pharo-project] A step toward reducing complexity

by DougEdmunds

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.

March 25, 2011

Re: [Pharo-project] pharo closures

by Igor Stasenko

On 25 March 2011 02:51, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > Ok, I will do so. (read the f-ing paper) I only read the blogpost until now. > > 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... > Perhaps because you don't need to copy unnecessary stuff, which closure not accessing anyways. This could save some cycles. > 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 >> > > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011