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

Re: [Pharo-users] Open Source OODB's

by Dennis Schetinin

Hi Esteban, Sure, I'm aware of those and other solutions and I've even used few of them. I'm sorry I can't explain myself adequately now, but I'm dreaming about some other kind of persistence, the one that (just like GemStone) doesn't make me to rebuild my application to migrate from image-based to a more granular solution. Or better, use the one from the very beginning if I want. Smalltalk monitors changes in source code (though it still does it in a bit coarse wayâ¦ I mean storing final results instead of deltas etc.). We have great metaprogramming and reflection capabilities. We can hook quite deep into message passing. And we can patch our VM as a last resort. Why don't we still have some of the persistence features GemStone has, and have them as a loadable framework? Even for the price of lower performance? Perhaps, I'm a dreamer (sure I am) and don't understand some basic obstacles for that, but can someone explain what are they? -- Best regards, Dennis Schetinin 2013/4/8 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > for smaller projects you have: > > - the image it self :) > - SandstoneDB http://www.squeaksource.com/SDGoodsStore.html > - Magma http://www.squeaksource.com/Magma.html > - ... and I'm sure there are others :) > > Esteban > > On Apr 6, 2013, at 4:40 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > > +1 > > BTW, I think that's a shame for smalltalkers to have so many libs for > external persistence solutions. That's not a paradox. Alternatives are > good, but Smalltalk was the first environment that had built-in persistence > as much as 35, if not 40 years ago. Is there much progress since that time? > I wouldn't say so. GemStone is great, but it's monolithic. And pricey. And > that's one more Smalltalk in our Balkans. > > Why Pharo or Squeak don't have a framework (based on Fuel for example) > that allows to control changes, execute transaction, save some parts of > image instead of whole image etc.? This could be less efficient then > GemStone, but loadable on demand, customizable and usable in smaller > projects. Maybe there's such a project living already? Or is it too much > for modern Smalltalk? > > It's not complaining. I know the answer: there's no usable persistence > solution because I didn't create it :) I just want to know if someone else > thinks the same way as I do? Consider that a very first step towards > starting such a project, if it is feasible at allâ¦ > > > -- > > Best regards, > > > Dennis Schetinin > > > 2013/4/6 stephane ducasse <stephane.ducasse(a)free.fr> > >> >> >> Hi >> 2013/4/1 Victor Stan <victor.stan(a)gmail.com> >> >>> Hi, >>> >>> Are there any open source OODB's out there? Alternatives to GemStone? >>> >> >> I think there is no alternavise to GemStone. >> >> >> I hope not :) >> Gemstone is good but an ecosystem with only one solution would look >> rather limited to me. >> >> Because GemStome is not just data store. It is applicaton server where >> you work in multi user image system. >> Imagine single Pharo image which can work under different parallel VM >> instances (maybe running on different machines) which have concurrent >> access to same image objects, can commit it changes (save same image). >> >> >> > >

April 22, 2013

Re: [Pharo-users] Open Source OODB's

by Dennis Schetinin

Sorry for such a late answer, I was away for some time and have just managed to break through the piles of e-mails. :) If I'm not mistaken, Oak is based on Riak, i.e. external storage engine. Actually, I was talking about Smalltalk-based solution. Why do you prefer an âexternally supported backendâ? -- Best regards, Dennis Schetinin 2013/4/8 GÃ¶ran Krampe <goran(a)krampe.se> > Hey! > > > On 04/06/2013 04:40 PM, Dennis Schetinin wrote: > >> Why Pharo or Squeak don't have a framework (based on Fuel for example) >> that allows to control changes, execute transaction, save some parts of >> image instead of whole image etc.? This could be less efficient then >> GemStone, but loadable on demand, customizable and usable in smaller >> projects. Maybe there's such a project living already? Or is it too much >> for modern Smalltalk? >> > > I already posted about such a project in this thread, Oak, why didn't you > notice?: > > http://goran.krampe.se/2012/**12/29/oak/<http://goran.krampe.se/2012/12/29/oak/> > > > It's not complaining. I know the answer: there's no usable persistence >> solution because I didn't create it :) I just want to know if someone >> else thinks the same way as I do? >> > > Feel free to help out with Oak. It is exactly what you are asking for. > > regards, GÃ¶ran > >

April 22, 2013

[ANN] Pharo VM for Ubuntu updated

by Damien Cassou

Installing the pharo vm under Ubuntu is just a matter of: sudo add-apt-repository ppa:cassou/pharo sudo apt-get update sudo apt-get install pharo-vm Recent changes: - latest VM packaged - separation between pharo-vm-core (few dependencies) and pharo-vm-desktop (depends on pharo-core + opengl + x11 + cairo) - no more warnings from the packaging systems - pharo man page - no more embedded libraries (pcre and libjpeg) (thanks to Esteban Lorenzano) Todo list: - make Pharo a graphical executable that lets user create and launch images (more on that in my next email) - see if Debian would be interested in including this package -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

April 22, 2013

Software Integration Survey

by Martin Dias

Hi all, We are conducting an academic research to improve tools for software integration. If you maintain a project with multiple contributors, we will greatly appreciate your participation. Your answers will be used for research purposes and to support the development of new tools. You can later access the results of this study, make free use of our tools to support the integration of changes, and maybe receive a gift. https://sondages.inria.fr/index.php/667625/lang-en Best regards, MartÃn Dias, Nicolas Anquetil, VerÃ³nica Isabel Uquillas, StÃ©phane Ducasse and the RMOD Inria team

April 22, 2013

Re: [Pharo-users] Package load times

by Mariano Martinez Peck

I have been noticing this slowdown too. Sorry I don't have much to say, but it is way slower than in 1.4. You are not alone! On Sun, Apr 21, 2013 at 4:30 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > igor can you open a bug entry so that we do not forget it. > tx > > Stef > On Apr 21, 2013, at 5:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 20 April 2013 22:56, Chris <cpmbailey(a)btinternet.com> wrote: > >> I've recently upgraded a project to Pharo 2 which went relatively > smoothly > >> but thought I'd share my experience with loading times > >> > >> In Pharo 1.4, it used to take about 5-6 minutes to build everything > from a > >> base image but I noticed that if I ran the package loads inside a > >> SystemChangeNotifier uniqueInstance doSilently: then the load time went > down > >> to like 2 minutes without any other side effects. > >> > >> In Pharo 2, it was taking a lot longer so I ran it through the > equivalent > >> SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in > terms > >> of speed but all of the classes ended up unpackaged. After a little bit > of > >> digging I eventually found that by running MCWorkingCopy > >> unregisterForNotifications before the package load, it came back to a > >> sensible load time and everything seems to work again. > > > > SystemAnnouncer suspension is buggy. > > > > announce: anAnnouncement > > self isSuspended > > ifFalse: [ > > self private announce: anAnnouncement. > > super announce: anAnnouncement ] > > should be: > > > > announce: anAnnouncement > > self private announce: anAnnouncement. > > self isSuspended > > ifFalse: [ > > super announce: anAnnouncement ] > > > > > >> > >> My question is can this practice become part of a configuration load? I > >> tried loading Iliad from the package cache just as an example and if > you do > >> a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy > >> unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy > >> registerForNotifications. only takes 42 seconds. The main problem seems > to > >> be MCPackageManager>>#methodModified which sets the package modified > state > >> is taking about 60m/s to run each time because it is initializing an > >> RPackage for every package in the system. Is there any way this can be > >> cached better? > >> > > yes the code there needs review. > > > >> Cheers > >> Chris > >> > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > -- Mariano http://marianopeck.wordpress.com

April 21, 2013

Re: [Pharo-users] Package load times

by stephane ducasse

igor can you open a bug entry so that we do not forget it. tx Stef On Apr 21, 2013, at 5:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 April 2013 22:56, Chris <cpmbailey(a)btinternet.com> wrote: >> I've recently upgraded a project to Pharo 2 which went relatively smoothly >> but thought I'd share my experience with loading times >> >> In Pharo 1.4, it used to take about 5-6 minutes to build everything from a >> base image but I noticed that if I ran the package loads inside a >> SystemChangeNotifier uniqueInstance doSilently: then the load time went down >> to like 2 minutes without any other side effects. >> >> In Pharo 2, it was taking a lot longer so I ran it through the equivalent >> SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms >> of speed but all of the classes ended up unpackaged. After a little bit of >> digging I eventually found that by running MCWorkingCopy >> unregisterForNotifications before the package load, it came back to a >> sensible load time and everything seems to work again. > > SystemAnnouncer suspension is buggy. > > announce: anAnnouncement > self isSuspended > ifFalse: [ > self private announce: anAnnouncement. > super announce: anAnnouncement ] > should be: > > announce: anAnnouncement > self private announce: anAnnouncement. > self isSuspended > ifFalse: [ > super announce: anAnnouncement ] > > >> >> My question is can this practice become part of a configuration load? I >> tried loading Iliad from the package cache just as an example and if you do >> a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy >> unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy >> registerForNotifications. only takes 42 seconds. The main problem seems to >> be MCPackageManager>>#methodModified which sets the package modified state >> is taking about 60m/s to run each time because it is initializing an >> RPackage for every package in the system. Is there any way this can be >> cached better? >> > yes the code there needs review. > >> Cheers >> Chris >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 21, 2013

Re: [Pharo-users] Package load times

by Igor Stasenko

On 20 April 2013 22:56, Chris <cpmbailey(a)btinternet.com> wrote: > I've recently upgraded a project to Pharo 2 which went relatively smoothly > but thought I'd share my experience with loading times > > In Pharo 1.4, it used to take about 5-6 minutes to build everything from a > base image but I noticed that if I ran the package loads inside a > SystemChangeNotifier uniqueInstance doSilently: then the load time went down > to like 2 minutes without any other side effects. > > In Pharo 2, it was taking a lot longer so I ran it through the equivalent > SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms > of speed but all of the classes ended up unpackaged. After a little bit of > digging I eventually found that by running MCWorkingCopy > unregisterForNotifications before the package load, it came back to a > sensible load time and everything seems to work again. SystemAnnouncer suspension is buggy. announce: anAnnouncement self isSuspended ifFalse: [ self private announce: anAnnouncement. super announce: anAnnouncement ] should be: announce: anAnnouncement self private announce: anAnnouncement. self isSuspended ifFalse: [ super announce: anAnnouncement ] > > My question is can this practice become part of a configuration load? I > tried loading Iliad from the package cache just as an example and if you do > a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy > unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy > registerForNotifications. only takes 42 seconds. The main problem seems to > be MCPackageManager>>#methodModified which sets the package modified state > is taking about 60m/s to run each time because it is initializing an > RPackage for every package in the system. Is there any way this can be > cached better? > yes the code there needs review. > Cheers > Chris > > -- Best regards, Igor Stasenko.

April 21, 2013

Re: [Pharo-users] Package load times

by stephane ducasse

Thanks for investigating that. We will have to have a look. We have a sprint in two weeks and I will sit with esteban if he wants to have a look. Stef On Apr 20, 2013, at 10:56 PM, Chris <cpmbailey(a)btinternet.com> wrote: > I've recently upgraded a project to Pharo 2 which went relatively smoothly but thought I'd share my experience with loading times > > In Pharo 1.4, it used to take about 5-6 minutes to build everything from a base image but I noticed that if I ran the package loads inside a SystemChangeNotifier uniqueInstance doSilently: then the load time went down to like 2 minutes without any other side effects. > > In Pharo 2, it was taking a lot longer so I ran it through the equivalent SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms of speed but all of the classes ended up unpackaged. After a little bit of digging I eventually found that by running MCWorkingCopy unregisterForNotifications before the package load, it came back to a sensible load time and everything seems to work again. > > My question is can this practice become part of a configuration load? I tried loading Iliad from the package cache just as an example and if you do a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy registerForNotifications. only takes 42 seconds. The main problem seems to be MCPackageManager>>#methodModified which sets the package modified state is taking about 60m/s to run each time because it is initializing an RPackage for every package in the system. Is there any way this can be cached better? > > Cheers > Chris > >

April 21, 2013

Re: [Pharo-users] Package load times

by Sven Van Caekenberghe

Hi Chris, On 20 Apr 2013, at 22:56, Chris <cpmbailey(a)btinternet.com> wrote: > I've recently upgraded a project to Pharo 2 which went relatively smoothly but thought I'd share my experience with loading times > > In Pharo 1.4, it used to take about 5-6 minutes to build everything from a base image but I noticed that if I ran the package loads inside a SystemChangeNotifier uniqueInstance doSilently: then the load time went down to like 2 minutes without any other side effects. > > In Pharo 2, it was taking a lot longer so I ran it through the equivalent SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms of speed but all of the classes ended up unpackaged. After a little bit of digging I eventually found that by running MCWorkingCopy unregisterForNotifications before the package load, it came back to a sensible load time and everything seems to work again. > > My question is can this practice become part of a configuration load? I tried loading Iliad from the package cache just as an example and if you do a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy registerForNotifications. only takes 42 seconds. The main problem seems to be MCPackageManager>>#methodModified which sets the package modified state is taking about 60m/s to run each time because it is initializing an RPackage for every package in the system. Is there any way this can be cached better? > > Cheers > Chris I can't answer myself, but I support your question. Loading takes way too long, your solution seems to go in the right direction, now it is up to the experts... Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

April 20, 2013

Package load times

by Chris

I've recently upgraded a project to Pharo 2 which went relatively smoothly but thought I'd share my experience with loading times In Pharo 1.4, it used to take about 5-6 minutes to build everything from a base image but I noticed that if I ran the package loads inside a SystemChangeNotifier uniqueInstance doSilently: then the load time went down to like 2 minutes without any other side effects. In Pharo 2, it was taking a lot longer so I ran it through the equivalent SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms of speed but all of the classes ended up unpackaged. After a little bit of digging I eventually found that by running MCWorkingCopy unregisterForNotifications before the package load, it came back to a sensible load time and everything seems to work again. My question is can this practice become part of a configuration load? I tried loading Iliad from the package cache just as an example and if you do a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy registerForNotifications. only takes 42 seconds. The main problem seems to be MCPackageManager>>#methodModified which sets the package modified state is taking about 60m/s to run each time because it is initializing an RPackage for every package in the system. Is there any way this can be cached better? Cheers Chris

April 20, 2013