- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [FWD] Options for Visualization

by Damir Majer

Hi Damien, Thanks for the Info, Cheers, Damir Damien Cassou wrote > On Wed, Apr 17, 2013 at 2:30 PM, Damir Majer < > damir@ > > wrote: >> IÂ´m searching for Options to visualize diagrams, for example an >> class-diagram. > > you may want to ask on the Moose-dev < > moose-dev@.unibe > > mailing > list as well. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill ----- -- Damir Majer ... be agile: www.majcon.de -- View this message in context: http://forum.world.st/FWD-Options-for-Visualization-tp4682108p4682159.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 17, 2013

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

by Esteban Lorenzano

btw... as someone pointed here, I need to clarify something I said: I didn't mentioned Eliot because I was talking about the plugins... When we talk about the VM itself, the number of people who are capable of work on it reduces from 10 to maybe 5 (Eliot and some others like Igor... but certainly not me :) Disclaimer done... is so obvious for me that Eliot is "the master-guru" that I just forget to mention him (I'm really sorry for that). Esteban On Apr 17, 2013, at 6:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > you're right... I will cut&paste and write something extra next days :) > > On Apr 17, 2013, at 4:25 PM, phil(a)highoctane.be wrote: > >> Very interesting email, worth a post somewhere. >> >> >> 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> >> 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] do you know what is this?

by Esteban Lorenzano

you're right... I will cut&paste and write something extra next days :) On Apr 17, 2013, at 4:25 PM, phil(a)highoctane.be wrote: > Very interesting email, worth a post somewhere. > > > 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> > 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] Xtreams's FileDirectory dependence

by Nicolas Cellier

+1 for using a brand new and much cleaner FileSystem But you must let some time to lazy developpers, so FIleSystemLegacy should be used in some ConfigurationOf in the interim. 2013/4/17 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-04-17, at 17:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 17 Apr 2013, at 17:09, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > >> FileSystemLegacy is your friend: > >> > >> http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy > > > > Yes, that is one possibility. > > > > But we want a clean loading Xtreams using FileSystem directly, do we not > ? > > > yes definitely ;). > but for loading it the first time, this is easier. > >

April 17, 2013

Re: [Pharo-project] Problems with Association page

by Esteban Lorenzano

yeah, I fixed... I changed my website and forget to update the association. how shameful :S ;) On Apr 17, 2013, at 6:26 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 17, 2013, at 2:52 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > >> I visited the association page ( http://association.pharo.org/web ) and found some dead links you may be interested into fixing >> >> I am talking about the automatic scrolling bar at the top. >> 1) The VM for Pharo in OSX and iOS by Esteban Lorenzano >> >> http://smallworks.com.ar/products/vm (dead) >> >> correct -> http://smallworks.com.ar/web/products?_s=qhm7QT0Pl8cvtxWo&_k=f0_WADzS-ZFY2L… >> >> 2) >> Roassal by Alexandre Bergel >> >> http://objectprofile.com/roassal-home.html (dead) >> >> Correct -> http://objectprofile.com/#/pages/products/roassal/overview.html >> >> etc >> >> There may be other dead links , I have not tried all of them but you get the picture. >> > Yes, the people who submitted the projects need to fix those linksâ¦ > > Marcus

April 17, 2013

Re: [Pharo-project] Problems with Association page

by Marcus Denker

On Apr 17, 2013, at 2:52 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > I visited the association page ( http://association.pharo.org/web ) and found some dead links you may be interested into fixing > > I am talking about the automatic scrolling bar at the top. > 1) The VM for Pharo in OSX and iOS by Esteban Lorenzano > > http://smallworks.com.ar/products/vm (dead) > > correct -> http://smallworks.com.ar/web/products?_s=qhm7QT0Pl8cvtxWo&_k=f0_WADzS-ZFY2L… > > 2) > Roassal by Alexandre Bergel > > http://objectprofile.com/roassal-home.html (dead) > > Correct -> http://objectprofile.com/#/pages/products/roassal/overview.html > > etc > > There may be other dead links , I have not tried all of them but you get the picture. > Yes, the people who submitted the projects need to fix those linksâ¦ Marcus

April 17, 2013

Re: [Pharo-project] SPy VM

by kilon

I did know that, cause I try to follow PyPy development . I did not know it was still actively developed. I thought it was abandoned, glad I am proven wrong. Pitty It cant use cpython libraries. But who knows, maybe one day. -- View this message in context: http://forum.world.st/SPy-VM-tp4682145p4682147.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 17, 2013

[Pharo-project] SPy VM

by Yuriy Tymchuk

Did you know that there is smalltalk vm in PyPy? https://bitbucket.org/pypy/lang-smalltalk

April 17, 2013

[Pharo-project] How to get the AST Node for a Context

by Marcus Denker

Hi, We implemented this today: #sourceNode for MethodContext. It returns the AST node of context, as part of the whole AST of the method. thisContext sourceNode Returns: DoIt ^ thisContext sourceNode ------------ [ thisContext sourceNode ] value ==> RBBlockNode([ thisContext sourceNode ]) --------------- But even for optimized blocks it works: [ true ifTrue:[thisContext sourceNode ]] value RBBlockNode([ thisContext sourceNode ]) The AST is the one used for code generation, with all information of Semantic Analysis *and* the possibility to get the IR with all information, too. So: [ true ifTrue:[|a|thisContext sourceNode ]] value scope ===> an OCOptimizedBlockScope 4 Marcus

April 17, 2013

Re: [Pharo-project] Xtreams's FileDirectory dependence

by Camillo Bruni

On 2013-04-17, at 17:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 17 Apr 2013, at 17:09, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> FileSystemLegacy is your friend: >> >> http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy > > Yes, that is one possibility. > > But we want a clean loading Xtreams using FileSystem directly, do we not ? yes definitely ;). but for loading it the first time, this is easier.

April 17, 2013