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

Re: [Pharo-project] do you know what is this?

by phil＠highoctane.be

Of course we can still understand with an all in image style (leveraging ObjCBridge and NB). But it will be hard to study how things are occuring internally when leaving the image. e.g. using components from the OSX Frameworks for things like text editors may be powerful but ultimately, this will make us into "users" and not technology owners (mmmh, hard to explain what I want to convey). Pharo is an interesting platform to *really* understand how things do work at a low level. I agree with your view on doing most inside the image, plugins and stuff is actually hard to understand and master (I've been cutting my teeth at this for something like a year and still am a super n00b). One cool thing I'd like to have working is CUDA or OpenCL for example. That would be easier to do if on the image side of course. Phil 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi Phil, > > On Apr 17, 2013, at 9:26 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > > Regarding this, of the key points of Pharo is that most of the system is > able to be looked at from a lot of angles in source code form. > > > I do not understand this... why do you think that now you can do that and > with an all-in-image approach you cannot? > > > Removing that ability is not going to be nice. > > > why do you think that this will remove it? > > Esteban > > > But this doesn't mean we can't go the other way around of course, allowing > it to embrace new technical possibilities. But as extensions to a core that > stays under full control. > > At the moment, I've been tinkering with the idea of integrating a 3D demo > engine (DirectX based) with Pharo. > > The engine will get an API and being scripted from the Pharo side. > > The engine can currently do things like: > http://www.youtube.com/watch?v=oRnogMokS_8 > > Phil > > Phil > > > 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> > >> Hi, >> >> This is just the cairo library rendering in a quartz format. No native >> quartz access yet, so... >> >> 1) yes... is 100% compatible with Cairo (because it is Cairo :) >> 2) no GPU, no OpenGL, just optimized rendering (one of this days I will >> write the novel "how we render world canvas nowadays"... it is a thriller >> end-of-the-world story) >> >> we are thinking with Igor if a quartz native renderer has sense right >> now. Of course, in the long term, it has completely sense, but atm, I have >> the feeling that other more portable renderer (like an OpenGL renderer) is >> better investment. >> Anyway, we still have some other stuff to do before: >> >> - finish athens (including new text model) >> - finish bridge >> - test same with linux, windows >> etc. >> >> On Apr 17, 2013, at 7:50 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >> Hi >> >> 2013/4/17 Fernando Olivero <fernando.olivero(a)usi.ch> >> >>> NICE work Esteban! >>> >>> Does the AthensQuartzSurface, support all Athens related code? (paths, >>> paints,etc..) I will be more than happy to move away from the software >>> rendering of the current cairo backend. >>> >> >> Is Quartz work by GPU? is it use openGL? >> >> >>> >>> Fernando >>> >>> >>> >>> On Tue, Apr 16, 2013 at 8:41 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> > not to say about efficiency. >>> > >>> > I've been doing some cpu cycle tests. >>> > >>> > Rendering a 1600@1200 gradient to world canvas (repeat each 50ms): >>> ~90% cpu consumption >>> > >>> > Same test, but sending it direct to window canvas using bridge: ~40% >>> cpu consumption >>> > >>> > so... we are in the good path :) >>> > >>> > Esteban >>> > >>> > On Apr 16, 2013, at 8:28 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> > >>> >> On 16 April 2013 19:09, kilon <thekilon(a)yahoo.co.uk> wrote: >>> >>> And you guys then say that pharo is not macos first citizen >>> >>> >>> >>> ha >>> >>> >>> >>> ha >>> >>> >>> >>> and >>> >>> >>> >>> ha >>> >>> >>> >>> I am a macos user , I love my imac and macos, but my vote goes to >>> cross >>> >>> platform. >>> >>> >>> >>> Still another great library that is more than welcomed, definitely >>> cant do >>> >>> any harm ;) >>> >>> >>> >> >>> >> By saying that we don't need Cairo on MacOS i meant following: >>> >> >>> >> Athens designed to support multiple backends. >>> >> It is out of question, that better to use most suitable backend, >>> >> available on current platform. >>> >> >>> >> But apart of it stays ObjC bridge. Which would allow us to speak with >>> >> ObjC-runtime >>> >> (and Mac VM using it) directly. >>> >> >>> >>> >>> >>> >>> >>> -- >>> >>> View this message in context: >>> http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681975.html >>> >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com<http://nabble.com/> >>> . >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Best regards, >>> >> Igor Stasenko. >>> >> >>> > >>> > >>> >>> >> >> > >

April 17, 2013

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

by phil＠highoctane.be

I'll try to get there then :-) 2013/4/17 Marcus Denker <marcus.denker(a)inria.fr> > Hi, > > We are planning a sprint the 3rd of May: > > http://rmod.lille.inria.fr/web/pier/blog/2013-04-17 > > When? Friday May 3 > Where? Inria Lille Building B, RMoD Offices > > If you want to join, please send a mail so we can plan and open the > door for you. > > Marcus > > > > > >

April 17, 2013

Re: [Pharo-project] do you know what is this?

by Igor Stasenko

Well said, Esteban, well said. This is a same idea and message which i wanted to deliver doing my NativeBoost presentation at 2012's Smalltalks conference in Puerto Madryn. So, we are pretty well aligned with our vision :) On 17 April 2013 12:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > On Apr 17, 2013, at 11:23 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > >> Anyway, my only objection is the fact that we will have twice the code to >> maintain and more to worry about. > > let me explain this little thing a bit... > > Do you think that code doesn't need to be maintained and taken care how it is right now? > > I will draw you a picture of how it works this now > > /----------------------------------------------\ > | "Pretended wonderland" (image) | > =========================== > | Lots of things: I/O, FFI, etc. | > ----------------------------------------------- > | Virtual Machine (Cog, Stack, Int) | > \----------------------------------------------/ > > This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't? > > Well, wrong. > > Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). > The difference is: > > - in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) > - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. > In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work). > > So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. > As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work). > > Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. > Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). > This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance). > > So we need to change that. > > How to do it? There are two basic approaches possible: > The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. > As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all. > > Then it is our approach: move to the image all the things that can be moved. Then you will have this: > > /----------------------------------------------\ > | "Pretended wonderland" | > ----------------------------------------------- > | Abstract system layer in image | > | (that most of people will never | > | see anyway) | > =========================== > | Virtual Machine (Cog, Stack, Int) | > \----------------------------------------------/ > > With NativeBoost we can achieve same performance that we achieve using plain C. > And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. > And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) > And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it. > > Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. > And some times I feel that it is a power that the community is afraid to take :) > > lose your fear: having that power feels good :) > > And again: do you still think there is no need for maintain low level stuff? Think again. > > cheers, > Esteban > > -- Best regards, Igor Stasenko.

April 17, 2013

[Pharo-project] [Sprint] Sprint Lille May 3rd

by Marcus Denker

Hi, We are planning a sprint the 3rd of May: http://rmod.lille.inria.fr/web/pier/blog/2013-04-17 When? Friday May 3 Where? Inria Lille Building B, RMoD Offices If you want to join, please send a mail so we can plan and open the door for you. Marcus

April 17, 2013

[Pharo-project] [update 2.0] #20599

by Marcus Denker

20599 ----- 10297 Integrate 2.0: 10295 Zinc Update April 16th https://pharo.fogbugz.com/f/cases/10297

April 17, 2013

[Pharo-project] SmalltalkHub account and user email

by Tommaso Dal Sasso

Hello to everyone, I am Tommaso Dal Sasso and I just started my PhD in Lugano with Michele Lanza. I will focus on the automatization and improvement of the bug reporting process. I registered yesterday to SmalltalkHub, and I noticed that the users emails are publicly shown in the user details page. Maybe it is just a my obsession, but shouldn't the user be warned about this and/or be able to hide his address? Thank you. Tommaso

April 17, 2013

Re: [Pharo-project] do you know what is this?

by Igor Stasenko

On 17 April 2013 12:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Phil, > > On Apr 17, 2013, at 9:26 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > > Regarding this, of the key points of Pharo is that most of the system is > able to be looked at from a lot of angles in source code form. > > > I do not understand this... why do you think that now you can do that and > with an all-in-image approach you cannot? > > > Removing that ability is not going to be nice. > > > why do you think that this will remove it? Yes, especially that we're want to do straightly opposite: - move code from VM sources to image so people can understand it and use/change it much easier instead of keeping it frozen forever in VM. > > Esteban > > > But this doesn't mean we can't go the other way around of course, allowing > it to embrace new technical possibilities. But as extensions to a core that > stays under full control. > > At the moment, I've been tinkering with the idea of integrating a 3D demo > engine (DirectX based) with Pharo. > > The engine will get an API and being scripted from the Pharo side. > > The engine can currently do things like: > http://www.youtube.com/watch?v=oRnogMokS_8 > > Phil > > Phil > > > 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> >> >> Hi, >> >> This is just the cairo library rendering in a quartz format. No native >> quartz access yet, so... >> >> 1) yes... is 100% compatible with Cairo (because it is Cairo :) >> 2) no GPU, no OpenGL, just optimized rendering (one of this days I will >> write the novel "how we render world canvas nowadays"... it is a thriller >> end-of-the-world story) >> >> we are thinking with Igor if a quartz native renderer has sense right now. >> Of course, in the long term, it has completely sense, but atm, I have the >> feeling that other more portable renderer (like an OpenGL renderer) is >> better investment. >> Anyway, we still have some other stuff to do before: >> >> - finish athens (including new text model) >> - finish bridge >> - test same with linux, windows >> etc. >> >> On Apr 17, 2013, at 7:50 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >> Hi >> >> 2013/4/17 Fernando Olivero <fernando.olivero(a)usi.ch> >>> >>> NICE work Esteban! >>> >>> Does the AthensQuartzSurface, support all Athens related code? (paths, >>> paints,etc..) I will be more than happy to move away from the software >>> rendering of the current cairo backend. >> >> >> Is Quartz work by GPU? is it use openGL? >> >>> >>> >>> Fernando >>> >>> >>> >>> On Tue, Apr 16, 2013 at 8:41 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> > not to say about efficiency. >>> > >>> > I've been doing some cpu cycle tests. >>> > >>> > Rendering a 1600@1200 gradient to world canvas (repeat each 50ms): >>> > ~90% cpu consumption >>> > >>> > Same test, but sending it direct to window canvas using bridge: ~40% >>> > cpu consumption >>> > >>> > so... we are in the good path :) >>> > >>> > Esteban >>> > >>> > On Apr 16, 2013, at 8:28 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> > >>> >> On 16 April 2013 19:09, kilon <thekilon(a)yahoo.co.uk> wrote: >>> >>> And you guys then say that pharo is not macos first citizen >>> >>> >>> >>> ha >>> >>> >>> >>> ha >>> >>> >>> >>> and >>> >>> >>> >>> ha >>> >>> >>> >>> I am a macos user , I love my imac and macos, but my vote goes to >>> >>> cross >>> >>> platform. >>> >>> >>> >>> Still another great library that is more than welcomed, definitely >>> >>> cant do >>> >>> any harm ;) >>> >>> >>> >> >>> >> By saying that we don't need Cairo on MacOS i meant following: >>> >> >>> >> Athens designed to support multiple backends. >>> >> It is out of question, that better to use most suitable backend, >>> >> available on current platform. >>> >> >>> >> But apart of it stays ObjC bridge. Which would allow us to speak with >>> >> ObjC-runtime >>> >> (and Mac VM using it) directly. >>> >> >>> >>> >>> >>> >>> >>> -- >>> >>> View this message in context: >>> >>> http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681975.html >>> >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Best regards, >>> >> Igor Stasenko. >>> >> >>> > >>> > >>> >> >> > > -- Best regards, Igor Stasenko.

April 17, 2013

Re: [Pharo-project] do you know what is this?

by Esteban Lorenzano

Hi, On Apr 17, 2013, at 11:23 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > Anyway, my only objection is the fact that we will have twice the code to > maintain and more to worry about. let me explain this little thing a bit... Do you think that code doesn't need to be maintained and taken care how it is right now? I will draw you a picture of how it works this now /----------------------------------------------\ | "Pretended wonderland" (image) | =========================== | Lots of things: I/O, FFI, etc. | ----------------------------------------------- | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/ This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't? Well, wrong. Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). The difference is: - in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work). So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work). Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance). So we need to change that. How to do it? There are two basic approaches possible: The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all. Then it is our approach: move to the image all the things that can be moved. Then you will have this: /----------------------------------------------\ | "Pretended wonderland" | ----------------------------------------------- | Abstract system layer in image | | (that most of people will never | | see anyway) | =========================== | Virtual Machine (Cog, Stack, Int) | \----------------------------------------------/ With NativeBoost we can achieve same performance that we achieve using plain C. And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it. Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. And some times I feel that it is a power that the community is afraid to take :) lose your fear: having that power feels good :) And again: do you still think there is no need for maintain low level stuff? Think again. cheers, Esteban

April 17, 2013

Re: [Pharo-project] How to browse a selected method in code viewer

by Marcus Denker

On Apr 17, 2013, at 11:51 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > Is it a bug ? If I select a class and do alt+b it works , if I select the > entire message it does not . For example Yes, there is a bug report there already since Apr 9, 2012: https://pharo.fogbugz.com/f/cases/5628/More-permissive-navigation-Shortcuts… Marcus

April 17, 2013

Re: [Pharo-project] do you know what is this?

by Esteban Lorenzano

Hi Phil, On Apr 17, 2013, at 9:26 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Regarding this, of the key points of Pharo is that most of the system is able to be looked at from a lot of angles in source code form. I do not understand this... why do you think that now you can do that and with an all-in-image approach you cannot? > > Removing that ability is not going to be nice. why do you think that this will remove it? Esteban > > But this doesn't mean we can't go the other way around of course, allowing it to embrace new technical possibilities. But as extensions to a core that stays under full control. > > At the moment, I've been tinkering with the idea of integrating a 3D demo engine (DirectX based) with Pharo. > > The engine will get an API and being scripted from the Pharo side. > > The engine can currently do things like: http://www.youtube.com/watch?v=oRnogMokS_8 > > Phil > > Phil > > > 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > This is just the cairo library rendering in a quartz format. No native quartz access yet, so... > > 1) yes... is 100% compatible with Cairo (because it is Cairo :) > 2) no GPU, no OpenGL, just optimized rendering (one of this days I will write the novel "how we render world canvas nowadays"... it is a thriller end-of-the-world story) > > we are thinking with Igor if a quartz native renderer has sense right now. Of course, in the long term, it has completely sense, but atm, I have the feeling that other more portable renderer (like an OpenGL renderer) is better investment. > Anyway, we still have some other stuff to do before: > > - finish athens (including new text model) > - finish bridge > - test same with linux, windows > etc. > > On Apr 17, 2013, at 7:50 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hi >> >> 2013/4/17 Fernando Olivero <fernando.olivero(a)usi.ch> >> NICE work Esteban! >> >> Does the AthensQuartzSurface, support all Athens related code? (paths, >> paints,etc..) I will be more than happy to move away from the software >> rendering of the current cairo backend. >> >> Is Quartz work by GPU? is it use openGL? >> >> >> Fernando >> >> >> >> On Tue, Apr 16, 2013 at 8:41 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> > not to say about efficiency. >> > >> > I've been doing some cpu cycle tests. >> > >> > Rendering a 1600@1200 gradient to world canvas (repeat each 50ms): ~90% cpu consumption >> > >> > Same test, but sending it direct to window canvas using bridge: ~40% cpu consumption >> > >> > so... we are in the good path :) >> > >> > Esteban >> > >> > On Apr 16, 2013, at 8:28 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > >> >> On 16 April 2013 19:09, kilon <thekilon(a)yahoo.co.uk> wrote: >> >>> And you guys then say that pharo is not macos first citizen >> >>> >> >>> ha >> >>> >> >>> ha >> >>> >> >>> and >> >>> >> >>> ha >> >>> >> >>> I am a macos user , I love my imac and macos, but my vote goes to cross >> >>> platform. >> >>> >> >>> Still another great library that is more than welcomed, definitely cant do >> >>> any harm ;) >> >>> >> >> >> >> By saying that we don't need Cairo on MacOS i meant following: >> >> >> >> Athens designed to support multiple backends. >> >> It is out of question, that better to use most suitable backend, >> >> available on current platform. >> >> >> >> But apart of it stays ObjC bridge. Which would allow us to speak with >> >> ObjC-runtime >> >> (and Mac VM using it) directly. >> >> >> >>> >> >>> >> >>> -- >> >>> View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681975.html >> >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >>> >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> > >> >> > >

April 17, 2013