- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Another thought about globals

by Sergi Reyner

Sergi Reyner wrote > > kilon alios wrote >> I think it would make even the transition from workspace to browser >> easier, >> or even completely replace workspace with the browser. >> >> I always found workspace unnecessary anyway. > It may be that I am still too unfamiliar with Smalltalk, but I cannot see > how removing the Workspace would be a good thing. > > Cheers, > Sergi PS: my bad, I thought I was already subscribed to the pharo-dev mailing list :S -- View this message in context: http://forum.world.st/Another-thought-about-globals-tp4730022p4730071.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 14, 2013

Re: [Pharo-dev] strange bug when opening the morph menu

by Nicolai Hess

Ah, that one. I thought you meant the window menu from the little arrow icon on the right. 2013/12/14 Tudor Girba <tudor(a)tudorgirba.com> > What do you mean by slow? > > The problem is that the morph menu (Cmd+Shift+RightClick) does not open > when the title is too large. > > Cheers, > Doru > > > On Sat, Dec 14, 2013 at 12:01 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > >> I am not sure how to reproduce this. >> I do not see anything slow >> >> Alexandre >> >> >> On Dec 14, 2013, at 11:10 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> > Hi, >> > >> > Try this: >> > >> > 1. Execute >> > Workspace open >> > 2. Try to get the menu of the window >> > ==> it opens just fine >> > >> > 1. Execute >> > Workspace open label: (1 to: 100) asOrderedCollection asString >> > 2. Try to get the menu of the window >> > ==> it does not open properly (it opens large and it closes quickly) >> and the mouse remains in dragging mode >> > >> > I opened a bug report: >> > >> https://pharo.fogbugz.com/f/cases/12426/Morph-menu-has-strange-behavior-whe… >> > >> > Does anyone have any idea of why it happens? >> > >> > Cheers, >> > Doru >> > >> > >> > -- >> > www.tudorgirba.com >> > >> > "Every thing has its own flow." >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Dec. 14, 2013

Re: [Pharo-dev] strange bug when opening the morph menu

by Tudor Girba

What do you mean by slow? The problem is that the morph menu (Cmd+Shift+RightClick) does not open when the title is too large. Cheers, Doru On Sat, Dec 14, 2013 at 12:01 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > I am not sure how to reproduce this. > I do not see anything slow > > Alexandre > > > On Dec 14, 2013, at 11:10 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > Try this: > > > > 1. Execute > > Workspace open > > 2. Try to get the menu of the window > > ==> it opens just fine > > > > 1. Execute > > Workspace open label: (1 to: 100) asOrderedCollection asString > > 2. Try to get the menu of the window > > ==> it does not open properly (it opens large and it closes quickly) and > the mouse remains in dragging mode > > > > I opened a bug report: > > > https://pharo.fogbugz.com/f/cases/12426/Morph-menu-has-strange-behavior-whe… > > > > Does anyone have any idea of why it happens? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow." > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 14, 2013

Re: [Pharo-dev] Another thought about globals

by kilon alios

why we need globals anyway ? why not use classes instead ? The only use I see of globals is in workspace and I am sure we could find a way to automate or make the creation of classes faster inside workspace instead of using globals. Since OO is the very foundation of Pharo I don't see why one would need globals anyway. If that forces us to make object more flexible so be it. Way better than creating concepts that works with this tools and not work with the other tool or could work if you do this and that , ending up making things more complex than they need to be. I think it would make even the transition from workspace to browser easier, or even completely replace workspace with the browser. I always found workspace unnecessary anyway. On Sat, Dec 14, 2013 at 12:47 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > > > > > As you may know, smalltalk global dictionary contain all symbols defined > globally, > > so you can access them directly in any piece of code i.e. when you write: > > > > Object new > > > > it actually means 'send message #new to object, associated with #Object > name in globals dictionary. > > > > Most of globals are classes, but some of them , like Transcript, World, > Display etc are not. > > And i was always thinking there's something wrong with these globals > (actually there's multiple 'wrongs'), but finally, i think i can answer > myself, what is most basic wrong with them: they miss any form of > declaration. > > > > Most of variables in smalltalk require declaration, such as temps, > method arguments, instance variables , class variables, pool variables, > > but not globals. > > Even classes, from formal point of view do not require declaration, > > because actually the usual: > > > > Object subclass: #Collection > > instanceVariableNames: '' > > classVariableNames: 'MutexForPicking RandomForPicking' > > poolDictionaries: '' > > category: 'Collections-Abstract' > > > > is _definition_ but not declaration: > > > > Collection definition => > > > > 'Object subclass: #Collection > > instanceVariableNames: '''' > > classVariableNames: ''MutexForPicking RandomForPicking'' > > poolDictionaries: '''' > > category: ''Collections-Abstract''' > > > > in fact, it is just a message sent to 'Object' variable (at some moment > in the past) , and there's nothing > > in language which enforces the rule that evaluating such expression must > declare new global, named Collection, except from environment we're working > in. > > > > The absence of declaration for globals leads to following problems: > > since declaration point is not defined, all tools (including compiler) > assume that given name always been there, and always accessible. Which > leads to bootstrap problems. > > There's no way to determine if given piece of code (which uses some > global) will keep functioning properly, once you unload certain package. No > way to determine dependencies (and as consequence the order of code loading > during bootstrapping). > > Also, it is hard to determine, to which package certain global belongs. > While it is easy to tell for classes since they having category, for > globals like Transcript, Display etc, there's no way to tell anything. > > Piece of cake, you can say: since Display is instance of DisplayScreen > class, then such variable must belong to same package as DisplayScreen, > right? > > Wrong! > > Just for example, imagine i create variable named MyWindowMousePosition, > which will contain an instance of Point. Does it means that such variable > should belong to same package as Point class? I guess not. > > > > So, to sum up, i think we should really think how to introduce a way to > declare globals in package-based ecosystem, where each global belongs to > certain package, and then since packages form dependency hierarchy, you can > easily detect whether you allowed to use certain global in given context or > not, > > to prevent forming dependency loops. > > But even if we will weaken contract and allow having dependency loops, > even in such case declarations can help us to clearly tell which pieces of > code will stop functioning properly, if package which declares given > variable are not present in system. > > > > The last aspect of bootstrapping problem is order of initialization, > > because declaring variable doesn't means you can use it right away, > > since it may be not properly initialized yet (otherwise we will be > forced to always use lazy initialization pattern). > > > > From this perspective, IMO package should not only have unordered list > of classes/symbols it declares/defines, but also contain information in > which order they must be initialized while loaded. > > From other side, i don't really like introducing too much formalism and > rules, and keep them as minimal as possible, following smalltalk spirit. > > > > What you think? > > I think packages should be first class citizens. A package once loaded > provides an environment/namespace/... that declares all the (exported) > symbols that should be accesible global. The smalltalk dictionary should > rather be a list of those namespaces/environments/... A package should also > have an initialize method where you could specify order of class > initialization if necessary ( and other things). Furthermore I would like > to see class initializers idempotent. So when loading a package the package > initialize is invoked first and then the class initializers, As they are > idempotent a possible double invocation is not a problem. > Dependencies are always hard. I would start thinking about metacello > defining all the possible dependencies regarding platforms, platform > versions etc. At load time there is only one dependency graph and that > could be reflected by the system. And this graph is not dependent on the > tool that loaded the code. > With this in place unloading should be rather easy. Dependencies can warn > the user about an harmful action and when the namespace is removed all > global definitions are automaticall removed. > > That is what I think. But I also think that there should be a possibility > to load something that doesn't end being global. A way to load a package > that isn't added to the global namespace (smalltalk dictionary) but to a > package namespace would also be very good. Not everything needs to global > but we can only load global things. That is a flaw in my opinion. And it > prevents cool things like loading multiple versions of a code in separate > packages. > > Norbert >

Dec. 14, 2013

Re: [Pharo-dev] strange bug when opening the morph menu

by Alexandre Bergel

I am not sure how to reproduce this. I do not see anything slow Alexandre On Dec 14, 2013, at 11:10 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Try this: > > 1. Execute > Workspace open > 2. Try to get the menu of the window > ==> it opens just fine > > 1. Execute > Workspace open label: (1 to: 100) asOrderedCollection asString > 2. Try to get the menu of the window > ==> it does not open properly (it opens large and it closes quickly) and the mouse remains in dragging mode > > I opened a bug report: > https://pharo.fogbugz.com/f/cases/12426/Morph-menu-has-strange-behavior-whe… > > Does anyone have any idea of why it happens? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow." -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 14, 2013

Cleaning a surface/canvas in Athens

by Alexandre Bergel

Hi! Just wondering. Isnât a bit strange to have to do this in order to clean a surface: -=-=-=-= surface drawDuring: [:cs | surface clear. â¦ ] -=-=-=-= Shouldnât it be -=-=-=-= surface drawDuring: [:cs | cs clear. â¦ ] -=-=-=-= instead? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 14, 2013

Re: [Pharo-dev] Another thought about globals

by Norbert Hartl

> Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > > As you may know, smalltalk global dictionary contain all symbols defined globally, > so you can access them directly in any piece of code i.e. when you write: > > Object new > > it actually means 'send message #new to object, associated with #Object name in globals dictionary. > > Most of globals are classes, but some of them , like Transcript, World, Display etc are not. > And i was always thinking there's something wrong with these globals (actually there's multiple 'wrongs'), but finally, i think i can answer myself, what is most basic wrong with them: they miss any form of declaration. > > Most of variables in smalltalk require declaration, such as temps, method arguments, instance variables , class variables, pool variables, > but not globals. > Even classes, from formal point of view do not require declaration, > because actually the usual: > > Object subclass: #Collection > instanceVariableNames: '' > classVariableNames: 'MutexForPicking RandomForPicking' > poolDictionaries: '' > category: 'Collections-Abstract' > > is _definition_ but not declaration: > > Collection definition => > > 'Object subclass: #Collection > instanceVariableNames: '''' > classVariableNames: ''MutexForPicking RandomForPicking'' > poolDictionaries: '''' > category: ''Collections-Abstract''' > > in fact, it is just a message sent to 'Object' variable (at some moment in the past) , and there's nothing > in language which enforces the rule that evaluating such expression must declare new global, named Collection, except from environment we're working in. > > The absence of declaration for globals leads to following problems: > since declaration point is not defined, all tools (including compiler) assume that given name always been there, and always accessible. Which leads to bootstrap problems. > There's no way to determine if given piece of code (which uses some global) will keep functioning properly, once you unload certain package. No way to determine dependencies (and as consequence the order of code loading during bootstrapping). > Also, it is hard to determine, to which package certain global belongs. While it is easy to tell for classes since they having category, for globals like Transcript, Display etc, there's no way to tell anything. > Piece of cake, you can say: since Display is instance of DisplayScreen class, then such variable must belong to same package as DisplayScreen, right? > Wrong! > Just for example, imagine i create variable named MyWindowMousePosition, which will contain an instance of Point. Does it means that such variable should belong to same package as Point class? I guess not. > > So, to sum up, i think we should really think how to introduce a way to declare globals in package-based ecosystem, where each global belongs to certain package, and then since packages form dependency hierarchy, you can easily detect whether you allowed to use certain global in given context or not, > to prevent forming dependency loops. > But even if we will weaken contract and allow having dependency loops, even in such case declarations can help us to clearly tell which pieces of code will stop functioning properly, if package which declares given variable are not present in system. > > The last aspect of bootstrapping problem is order of initialization, > because declaring variable doesn't means you can use it right away, > since it may be not properly initialized yet (otherwise we will be forced to always use lazy initialization pattern). > > From this perspective, IMO package should not only have unordered list of classes/symbols it declares/defines, but also contain information in which order they must be initialized while loaded. > From other side, i don't really like introducing too much formalism and rules, and keep them as minimal as possible, following smalltalk spirit. > > What you think? I think packages should be first class citizens. A package once loaded provides an environment/namespace/... that declares all the (exported) symbols that should be accesible global. The smalltalk dictionary should rather be a list of those namespaces/environments/... A package should also have an initialize method where you could specify order of class initialization if necessary ( and other things). Furthermore I would like to see class initializers idempotent. So when loading a package the package initialize is invoked first and then the class initializers, As they are idempotent a possible double invocation is not a problem. Dependencies are always hard. I would start thinking about metacello defining all the possible dependencies regarding platforms, platform versions etc. At load time there is only one dependency graph and that could be reflected by the system. And this graph is not dependent on the tool that loaded the code. With this in place unloading should be rather easy. Dependencies can warn the user about an harmful action and when the namespace is removed all global definitions are automaticall removed. That is what I think. But I also think that there should be a possibility to load something that doesn't end being global. A way to load a package that isn't added to the global namespace (smalltalk dictionary) but to a package namespace would also be very good. Not everything needs to global but we can only load global things. That is a flaw in my opinion. And it prevents cool things like loading multiple versions of a code in separate packages. Norbert

Dec. 14, 2013

strange bug when opening the morph menu

by Tudor Girba

Hi, Try this: 1. Execute Workspace open 2. Try to get the menu of the window ==> it opens just fine 1. Execute Workspace open label: (1 to: 100) asOrderedCollection asString 2. Try to get the menu of the window ==> it does not open properly (it opens large and it closes quickly) and the mouse remains in dragging mode I opened a bug report: https://pharo.fogbugz.com/f/cases/12426/Morph-menu-has-strange-behavior-whe… Does anyone have any idea of why it happens? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow."

Dec. 14, 2013

Re: [Pharo-dev] About Athens and Cairo

by Alexandre Bergel

Thanks Kilon for the explanation. Alexandre On Dec 14, 2013, at 10:56 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > No cairo is not GPU accelerated , rendering is done by your CPU , but of course the graphic card is the one that display things. > > here is a detailed explanation -> http://lists.cairographics.org/archives/cairo/2012-October/023609.html > > please note that even in the case of opengl backend I very much disagree that this is true hardware acceleration. What the opengl backend is doing is to render cairo surfaces as opengl textures. So even though the texture themselves are hardware accelerated and will even use the the memory of the GPU the process of rendering to the texture will happen solely on the CPU. So its more like a CPU library trying to be hardware accelerated. > > But even using the OS backends like Quartz is not quite the same. Because you still call C code and C code is executed by your CPU and that C code suppose to call GPU functions. Opengl speed is for the very reason of shaders meaning that it compiles programs that are run solely on the gpu hence true GPU acceleration. > > Saying that you should not be experiencing slow downs unless you were doing something really intense. I have seen benchmarks of Cairo and they are blazing fast. Usually slow down are primarily because of bad code. I have seen animation in athens take out 50% of my dual core and others only a 5%. Cant say I am sure what happens under the surface maybe Igor may offer a more detailed look into this. I do feel however that slow speed are 99% to be blamed on Pharo way of rendering things. > > Something similar happens for browsers, SVG is GPU accelerated, Javascript is super fast but it only takes the slowness of DOM (HTML) itself to bring the whole system on its knees. It only take one slow part to ruin the experience. I think a solution to this would be to bypass pharo rendering completely, create a new window and render directly to that window running Pharo headless. > > > On Sat, Dec 14, 2013 at 10:58 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I have some random questions about the Cairo binding supported by Athens. > > - the rendering is done by the graphic card isnât it? > > - Once rendered, is the produced bitmap copied by the CPU in Pharo? With Roassal3d, we are facing a problem of performance because there is an unnecessary copy between the graphic card and the Form displayed by Pharo. I guess we have the same problem with Cairo. > > - Is there an example of clipping in Cairo? > > - Any idea how efficient the clipping is? I mean, will I gain a lot by not displaying elements located outside the visual part or should I leave the clipping do the job? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 14, 2013

Re: [Pharo-dev] About Athens and Cairo

by Alexandre Bergel

> Le 14/12/2013 09:58, Alexandre Bergel a Ã©crit : >> - the rendering is done by the graphic card isnât it? > > I think it is sofware based, by the libcairo. Yes, but on http://cairographics.org it is written: Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 14, 2013