February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Spoon presentation 2012-02-24

by Craig Latta

Hi Guido-- > *nobody* around me has Apple. Would you please make your demo > installable on Windows or better Linux? Do you mean the Prezi presentation? That runs on MacOS and Windows (run prezi.exe). thanks, -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

Feb. 29, 2012

Re: [Pharo-project] Is athens configuration loading?

by Igor Stasenko

On 29 February 2012 22:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Can we play with it :)? > Yes, configuration seems to be working after some last-minute fixes. I now do some cleanup in AthensSurfaceExamples to make sure they using right class. > Stef -- Best regards, Igor Stasenko.

Feb. 29, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Esteban Lorenzano

Hi , It shouldn't be a problem. Best, Esteban El 29/02/2012, a las 15:26, "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> escribiÃ³: > Esteban, > > Dumb question: let's say I loaded 1.2 or so of FFI and 0.1 of Alien. Can I safely run the code you show in that image, or do I need to start over? > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] > Sent: Wednesday, February 29, 2012 12:45 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 > > Hi, > > I don't know which version of VM and Pharo are you using, but for using Alien properly in latest version you need to load FFI first: > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfFFI'; > load. > (ConfigurationOfFFI project version: '1.5') load. > > then Alien needs to be latest from Eliot's branch: > > Gofer it > squeaksource: 'Alien'; > package: 'Alien'; > load. > > that should work on latest Pharo images and latest vm builds :) > > best, > Esteban > > El 29/02/2012, a las 2:26p.m., Schwab,Wilhelm K escribiÃ³: > >> Sig, >> >> I just noted that Alien-examples contains a couple of classes with no methods. Where can I find examples of callbacks in action? >> >> Bill >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] >> Sent: Wednesday, February 29, 2012 12:13 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 >> >> Sig, >> >> I went back to 1.3 to get shout in browsers, and because it is theoretically more stable than 1.4. AFAIK, the key to finding libraries on Ubuntu is to use the #moduleName. Integration of the load function with ldconfig will do the rest, or should. The idea is a good one: one needs root access to change ldconfig's map, but anyone can read it. >> >> Bill >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Wednesday, February 29, 2012 10:01 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 >> >> On 29 February 2012 14:57, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> I appear to a 1.3 image in preliminary state. I'm sure stuff will be broken, and Cog is rearing its head by looking for external libraries in the wrong places; symlinks should clear that up, but it's ugly. >>> >> Bill, it's not about 1.3 or 1.4. it is how VM works (symlinks/lib search). >> In this regard, any pharo version is not anything better than other. >> Yes, we need to change that at some day. >> >>> I used the 1.3 seaside image as a base, and will have Seaside 2-3 problems to fix. Alien was the problem, probably breaking the compiler, as you suggested. >>> >> >> To correct you: it was not a suggestion. When Alien was released there >> was need to change compiler/parser in order to make it work. Eliot >> made a separate package for that. >> Now, after those changes were incorporated into Pharo itself, they are >> no longer needed. and moreover they might override existing methods >> with older/incompatible versions of it >> coming from Alien. >> Overrides are evil. Overrides in kernel are evil^2 :) >> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >>> Sent: Sunday, February 26, 2012 9:50 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 >>> >>> On 25 February 2012 11:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> Sig, >>>> >>>> This is helpful, as you have told me what is killing my images. Then you say to load then you say to load the latest config. Happy to comply, but how do I do that? >>>> >>> >>> (ConfigurationOfWhatever project version: 'x.y.z') load >>> >>> or better learn more about metacello, there's a well-written chapter >>> of it from the guys who care >>> https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Met… >>> >>>> Bill >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >>>> Sent: Saturday, February 25, 2012 12:39 AM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 >>>> >>>> On 25 February 2012 06:52, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> On 25 February 2012 06:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>>> Sig, >>>>>> >>>>>> Sorry about the empty reply. Migrate is fair game, and the image was healthy enough to file out the base (attached). Please look over how I install FFI to see if there are any mistakes. You might need to stub out a basic subclass (e.g. MigrateSig or anything else you want to call it) with a few methods (#me, #homeGrownClasses, etc.) to make it happy. Content of them can be simple to start. The "private stuff" has yet to enter the picture so shouldn't matter to us. >>>>>> >>>>>> THANKS!!! >>>>>> >>>>> Good. I will take a look. >>>>> >>>>>> Bill >>>> >>>> Ok, things for starting: >>>> >>>> >>>> Gofer new >>>> url:self mirror, 'MetacelloRepository'; >>>> package: 'ConfigurationOfAlien'; >>>> load. >>>> (Smalltalk globals classNamed: 'ConfigurationOfAlien') >>>> perform:#loadLatestVersion. >>>> >>>> >>>> Never ever use #loadLatestVersion, always use concrete version >>>> numbers, if you want to have stability. >>>> >>>> In our case, #loadLatestVersion is not quite latest, you can check it >>>> by yourself: >>>> >>>> >>>> ConfigurationOfAlien project updateProject. >>>> ConfigurationOfAlien project latestVersion "inspect it" >>>> >>>> 0.1 [ConfigurationOfAlien] >>>> so it actually loads not the latest available version, but the most >>>> old one. Because it is the only version with #release blessing. >>>> >>>> And i can tell you without even proceeding further, that it won't work >>>> in 1.3 neither in 1.4, because it is too old and not takes into >>>> account >>>> certain changes made in pharo. >>>> >>>> For instance: >>>> >>>> package: 'Alien-Prereqs' >>>> >>>> is no longer needed, as i told here: >>>> >>>> http://forum.world.st/Alien-Prerequisites-is-now-not-required-td3258432.html >>>> >>>> but its even worse, this version of config will be loading >>>> Alien-Prereqs-mha.3 which having even more overrides, >>>> and will definitely put image to its knees because compiler will be broken. >>>> >>>> So, try to load latest config first, if it would not help we will continue. >>>> >>>> P.S. to all people involved in using Alien.. some love needed to >>>> update configs for pharo 1.3 and 1.4 to finally get rid of >>>> 'Alien-Prereqs' package loading. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> > > >

Feb. 29, 2012

[Pharo-project] Is athens configuration loading?

by StÃ©phane Ducasse

Can we play with it :)? Stef

Feb. 29, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Igor Stasenko

On 29 February 2012 19:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > I just noted that Alien-examples contains a couple of classes with no methods. Â Where can I find examples of callbacks in action? > Bill, i am not maintainer of Alien. It is largely unknown to me. I even won't be surprised that you know it better than me. The main reason why you see Alien commits under my name was to fix issues with loading it into image. However it doesn't makes me responsible for other things which might or might not work there. About future: yes we want to unify all existing FFI solutions to one, working one. And i am working on that. But it doesn't means that Alien will stay as is and hence i became a person responsible for maintaining it. > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Wednesday, February 29, 2012 12:13 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 > > Sig, > > I went back to 1.3 to get shout in browsers, and because it is theoretically more stable than 1.4. Â AFAIK, the key to finding libraries on Ubuntu is to use the #moduleName. Â Integration of the load function with ldconfig will do the rest, or should. Â The idea is a good one: one needs root access to change ldconfig's map, but anyone can read it. > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, February 29, 2012 10:01 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 > > On 29 February 2012 14:57, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> I appear to a 1.3 image in preliminary state. Â I'm sure stuff will be broken, and Cog is rearing its head by looking for external libraries in the wrong places; symlinks should clear that up, but it's ugly. >> > Bill, it's not about 1.3 or 1.4. it is how VM works (symlinks/lib search). > In this regard, any pharo version is not anything better than other. > Yes, we need to change that at some day. > >> I used the 1.3 seaside image as a base, and will have Seaside 2-3 problems to fix. Â Alien was the problem, probably breaking the compiler, as you suggested. >> > > To correct you: it was not a suggestion. When Alien was released there > was need to change compiler/parser in order to make it work. Eliot > made a separate package for that. > Now, after those changes were incorporated into Pharo itself, they are > no longer needed. and moreover they might override existing methods > with older/incompatible versions of it > coming from Alien. > Overrides are evil. Overrides in kernel are evil^2 :) > >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Sunday, February 26, 2012 9:50 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 >> >> On 25 February 2012 11:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> This is helpful, as you have told me Â what is killing my images. Â Then you say to load then you say to load the latest config. Â Happy to comply, but how do I do that? >>> >> >> (ConfigurationOfWhatever project version: 'x.y.z') load >> >> or better learn more about metacello, there's a well-written chapter >> of it from the guys who care >> https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Met… >> >>> Bill >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >>> Sent: Saturday, February 25, 2012 12:39 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 >>> >>> On 25 February 2012 06:52, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 25 February 2012 06:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>> Sig, >>>>> >>>>> Sorry about the empty reply. Â Migrate is fair game, and the image was healthy enough to file out the base (attached). Â Please look over how I install FFI to see if there are any mistakes. Â You might need to stub out a basic subclass (e.g. MigrateSig or anything else you want to call it) with a few methods (#me, #homeGrownClasses, etc.) to make it happy. Â Content of them can be simple to start. Â The "private stuff" has yet to enter the picture so shouldn't matter to us. >>>>> >>>>> THANKS!!! >>>>> >>>> Good. I will take a look. >>>> >>>>> Bill >>> >>> Ok, things for starting: >>> >>> >>> Â Â Â Â Gofer new >>> Â Â Â Â Â Â Â Â url:self mirror, 'MetacelloRepository'; >>> Â Â Â Â Â Â Â Â package: 'ConfigurationOfAlien'; >>> Â Â Â Â Â Â Â Â load. >>> Â Â Â Â (Smalltalk globals classNamed: 'ConfigurationOfAlien') >>> perform:#loadLatestVersion. >>> >>> >>> Never ever use #loadLatestVersion, always use concrete version >>> numbers, if you want to have stability. >>> >>> In our case, #loadLatestVersion is not quite latest, you can check it >>> by yourself: >>> >>> >>> ConfigurationOfAlien project updateProject. >>> ConfigurationOfAlien project latestVersion Â "inspect it" >>> >>> 0.1 [ConfigurationOfAlien] >>> so it actually loads not the latest available version, but the most >>> old one. Because it is the only version with #release blessing. >>> >>> And i can tell you without even proceeding further, that it won't work >>> in 1.3 neither in 1.4, because it is too old and not takes into >>> account >>> certain changes made in pharo. >>> >>> For instance: >>> >>> package: 'Alien-Prereqs' >>> >>> is no longer needed, as i told here: >>> >>> http://forum.world.st/Alien-Prerequisites-is-now-not-required-td3258432.html >>> >>> but its even worse, this version of config will be loading >>> Alien-Prereqs-mha.3 which having even more overrides, >>> and will definitely put image to its knees because compiler will be broken. >>> >>> So, try to load latest config first, if it would not help we will continue. >>> >>> P.S. to all people involved in using Alien.. some love needed to >>> update configs for pharo 1.3 and 1.4 to finally get rid of >>> Â 'Alien-Prereqs' package loading. >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Feb. 29, 2012

Re: [Pharo-project] fun with NBOpenGL

by StÃ©phane Ducasse

so may be connecting to objective-C :) But the paperS first ;) Stef On Feb 29, 2012, at 8:37 PM, Jean Baptiste Arnaud wrote: > yes, ^^ ;-p > > On Feb 29, 2012, at 7:51 PM, StÃ©phane Ducasse wrote: > >> :) you seems to have fun after the lantronix XP. >> >> Stef >> >> On Feb 29, 2012, at 7:33 PM, Jean Baptiste Arnaud wrote: >> >>> <Screen shot 2012-02-29 at 7.31.10 PM.png> >> >> > > Regard > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > >

Feb. 29, 2012

Re: [Pharo-project] fun with NBOpenGL

by Jean Baptiste Arnaud

yes, ^^ ;-p On Feb 29, 2012, at 7:51 PM, StÃ©phane Ducasse wrote: > :) you seems to have fun after the lantronix XP. > > Stef > > On Feb 29, 2012, at 7:33 PM, Jean Baptiste Arnaud wrote: > >> <Screen shot 2012-02-29 at 7.31.10 PM.png> > > Regard Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Feb. 29, 2012

Re: [Pharo-project] Nearly limitless Image: revisited.

by Igor Stasenko

2012/2/29 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Good compromise is a step by step approach, something like: > > Â 1.step: image based persistence up to 1GB with hourly snapshot > Â 2.step: parts migrated to Fuel and file based persistence > Â 3.step: Gemstone, with "images" running in parallel (well, any DB > Â Â Â Â Â with images in parallel, Gemstone is certainly the easiest to > Â Â Â Â Â scale from image based persistence) > > 1GB limit is here just for simplicity, you can probably go further with > 64bit images. > yes you can. but then you will definitely need different GC strategy or change GC.. and this immediately turns advantages, like - very very simple into - very very hard because hacking GC is not that simple :) > Advantages: > > Â - very very simple start > Â - freedom of pure OO modeling, > Â - good enough for probably 90% of all projects > Â - fastest way from your dreams to reality > Â - speed of development - no impedance mismatch, no ORM nightmare > Â - you won't believe how much data you can put in 1GB image > Â - speed because of always in-memory data processing > Â - you can always scale further if you make your design from the start > Â Â with above steps in mind > Â - reliability good enough, on reliable hardware probably even better > Â Â than more complex solutions. Main reason: simplicity. > > Disadvantages: > > Â - you easy forgot to include later scalability requirements in > Â Â upfront design > Â - such scaling is easy only to OO database while migrating to > Â Â NoSQL (not to mention SQL) database later is very hard if not > Â Â possible > Â - up to about 1GB only, because of GC problems as Igor described > Â - active users limit (number of requests/s) > Â - single point of failure > Â - corrupted image will loose all data (but good backup approach helps) > Â - undetected image corruption fear (after many otherwise successful > Â Â snapshots, causing non-startable image) > Â - lengthy snapshots of bigger images (can be improved with two step > Â Â snapshots, first in memory, then on disk) > Â - loss of data between snapshots in case of power or machine failure > Â Â (but this is very rare those days) > > Bet regards > Janko > > S, Igor Stasenko piÅ¡e: >> Incidentally, we had a little chat with Marcus yesterday about that. >> >> No, i don't think it is feasible to use single image to store everything. >> It is convenient, cheap and of course it is way better than dealing >> with communicating with external DB/servers whatever. >> >> But there's one thing you should know already: the days of vertical >> growth is over. >> >> Running a service (under VM or not) on a single machine is asking for troubles: >> Â - limits on load >> Â - susceptible to power outage and other reliability problems >> Â etc >> >> Also, think that the amount of data you need to process correlates >> with CPU horsepower available. >> Which means that yes, you can run a huge image with 64Gb data in it.. >> but that means that responsiveness >> of your service will quite often fall beyond any usability limits. >> >> If we look in terms of VM and pick only one thing - garbage collection, >> you will see that there is certain limits beyond which a performance >> will drop too much, so you naturally >> will start thinking about ways to split data to separate chunks and >> run them on different machines/VMs. >> >> It is because GC's mark algorithm is O(n) bound, when n is total >> number of references between objects, >> and GC's scavenge algorithm is at best O(n) bound where n is total >> number of objects in object memory, >> and at worst is where n is total memory used by objects. >> No matter how you turn it, i just wanted to indicate that time to run >> GC is in linear dependency from the amount of data. >> >> Yes, we might invest a lot of effort in making GC more clever, more >> complex and more robust.. but no matter what you do, >> you cannot change the above facts. It means, that any improvements >> will be about diminishing returns, but won't change the picture >> radically. >> >> That means that sooner or later you will have to deal with it: a >> problem of splitting data on multiple independent chunks, >> and making your service to run on multiple machines , in order to use >> more CPU power, more memory and be more reliable etc. >> At this point, your main dilemma is to invent a fast and robust >> interfaces to communicate between images or between image(s)/ database >> etc. >> >> We should concentrate on things which dealing with inter-image >> communication and image-database communication, >> because it is the only way to ensure that we will answer upcoming >> future problems. Relying on using a single huge image is way to >> nowhere. >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > -- Best regards, Igor Stasenko.

Feb. 29, 2012

Re: [Pharo-project] Spoon presentation 2012-02-24

by Guido Stepken

Hi, Craig! Concerning your Spoon demo ... *nobody* around me has Apple. Would you please make your demo installable on Windows or better Linux? tnx in advance ... Guido

Feb. 29, 2012

Re: [Pharo-project] [squeak-dev] can this be done via modification to the Squeak/Pharo IDE?

by StÃ©phane Ducasse

On Feb 29, 2012, at 7:02 PM, Nick Ager wrote: > Hi Chris, > > > His comment on modality really emphasizes this point, and something I > think folks even in this community could stand to listen: when I > observe folks in their demo videos using Squeak or Pharo, almost every > time I see folks browsing in a modal way. They have a big > Package-Pane browser open and they're looking at one package, one > class and one method at a time... They have to do about 4-5 clicks to > "navigate" to a sent method, and 4-5 clicks to get back. This is way > too slow for ideas to emerge. > > I'd love to learn how to be more effective in the Pharo image. use nautilus and groups! They are cool. > Be great if you could share with us more effective ways to navigate around the code > .... even in a video :-) > > Nick

Feb. 29, 2012