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

reloading with green tests RB in Pharo 3.0

by StÃ©phane Ducasse

Using a new and clean configuration I can reload RB (critics, environment, core/changes) I hope to get the time to reload Nautilus and atfter the others. I really think that we will need to be able to execute unload and postLoad action (we can already). I wonder if I will be able to do it for KeyMapping for example. We will see. Stef

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by StÃ©phane Ducasse

On Oct 2, 2013, at 10:24 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Wed, Oct 2, 2013 at 5:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Mariano > > why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? > > Yes, it will probably be like this. But by then time I use 5GB my server will probably have 100GB by then. Indeed so you will have to find a real solution to manage your data and having a large database in memory may not be the way to go. > > Of course Pharo is limited and I hope that with the new Cog > > Indeed, I hope it too. And yes, it seems this will change with what Eliot is doing. > > it will be different but soon it will not fit in the ram of your OS. > > Stef > > > >> On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Mariano, >> >> On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> > Hi guys. >> > First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research. >> > >> > I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. >> >> I do not understand. >> >> IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ? >> >> More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. >> And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well.... >> >> >> As you most probably know, you can get pretty far with Pharo. >> >> Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high. >> >> After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does. >> >> >> Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo. >> >> You will always find more tools and libraries on the Pharo side, as the community is much larger. >> >> >> Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same. >> >> >> Thanks for the discussion! >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by Mariano Martinez Peck

On Wed, Oct 2, 2013 at 5:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Mariano > > why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? > Yes, it will probably be like this. But by then time I use 5GB my server will probably have 100GB by then. > Of course Pharo is limited and I hope that with the new Cog > Indeed, I hope it too. And yes, it seems this will change with what Eliot is doing. > it will be different but soon it will not fit in the ram of your OS. > > Stef > > > > On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> Mariano, >> >> On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> > Hi guys. >> > First, let me apologize for the amount of emails I am sending. I am >> doing an analysis to see if GemStone is a good candidate for a project I am >> working and so it deserves some research. >> > >> > I wondered if any has ever tried porting any of these tools to >> GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. >> >> I do not understand. >> >> IMHO there is only one reason to go to Gemstone, and that is to use its >> capabilities as OODB. All the technologies you mention are persistency >> related and would not be needed in that case, right ? >> > > More or less. Fuel would be awesome to move data between Pharo and > GemStone. SIXX has demonstrated some limitations. > And regarding Glorp / native postgres driver and Voyage/Mongo is because > what I may store in GemStone is not the only DB in the game. I may have > OTHER DBs that for a reason not important here, should remain either in a > relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of > course, I can have a Pharo image that does the job and provides > web-services (or anything similar) to my GemStone....but of course it is > easier if these DB clients would work in GemStone as well.... > > >> >> As you most probably know, you can get pretty far with Pharo. > > > Yes I know. But this particular application may have a lot of data > processing, algorithms, etc, which may probably NOT fit in 1GB of memory > and the effort to distribute the process among multiple images could be > high. > > >> After that, there is load-balancing, partitioning, message queues. Pretty >> much what any technology stack does. >> >> > Indeed. But I would still need a persistency solution that satisfy all my > needs. I should write this down and compare the alternatives in Pharo. > > >> You will always find more tools and libraries on the Pharo side, as the >> community is much larger. >> >> > Sure. But at least I would only miss the "deployment" libraries, since in > any case I will continue developing in Pharo, so all the development tools > and all the environment will be the same. > > > Thanks for the discussion! > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Oct. 2, 2013

about configuration to manage the image

by StÃ©phane Ducasse

Now I redid the configuration of Refactoring and Critics and publish the new package in the correct repository (ok marcus you did it so this is great but it will not scale) because there was a new changes touching all the packages. So this was a bad idea from me. => for now no separate repository => no move of package in between => I suggest that we load in the image the configuration and probably the process should manipulate configurations (I did not want to touch the metacello toolbox), I think that I will lose days thereâ¦. Or we simply gave up with the idea to have an image that can be modular. So we have to think and get smart. Stef

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by StÃ©phane Ducasse

Mariano why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? Of course Pharo is limited and I hope that with the new Cog it will be different but soon it will not fit in the ram of your OS. Stef > On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Mariano, > > On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > Hi guys. > > First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research. > > > > I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. > > I do not understand. > > IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ? > > More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. > And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well.... > > > As you most probably know, you can get pretty far with Pharo. > > Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high. > > After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does. > > > Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo. > > You will always find more tools and libraries on the Pharo side, as the community is much larger. > > > Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same. > > > Thanks for the discussion! > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by Mariano Martinez Peck

On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Mariano, > > On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > Hi guys. > > First, let me apologize for the amount of emails I am sending. I am > doing an analysis to see if GemStone is a good candidate for a project I am > working and so it deserves some research. > > > > I wondered if any has ever tried porting any of these tools to GemStone: > Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. > > I do not understand. > > IMHO there is only one reason to go to Gemstone, and that is to use its > capabilities as OODB. All the technologies you mention are persistency > related and would not be needed in that case, right ? > More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well.... > > As you most probably know, you can get pretty far with Pharo. Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high. > After that, there is load-balancing, partitioning, message queues. Pretty > much what any technology stack does. > > Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo. > You will always find more tools and libraries on the Pharo side, as the > community is much larger. > > Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same. Thanks for the discussion! -- Mariano http://marianopeck.wordpress.com

Oct. 2, 2013

Re: [Pharo-dev] new bug in RPackage

by StÃ©phane Ducasse

> I'm so tired of RPackage... :( I can imagine. This notification stuff is so brittle. This is why I like doru's idea to have a one to one mapping and we are getting there. We should kill this dependency on announcement. I can try to help but again RPackage is working this is just the system around and this is why I would like to avoid to have new requirements for RPackage. Stef >> In fact what is intriguing is that >> >> RPackageOrganizer default >> packageNamed: 'Refactoring-Core' >> >> in the image used to generate the configuration >> >> classExtensionSelectors is correct defined >> a Dictionary(#ClassTrait->a Set(#soleInstance) #TClassDescription->a Set(#whichSelectorsReallyRead:) ) >> >> So either the package is wrongly saved but this is not the case. >> Or while reloading it the logic is wrong. May be it should not raise systemMethodRecategorizedActionFrom: >> because it may be not be a recatogiration (or may be it was a override). >> >> Stef >> >> >> >> On Oct 2, 2013, at 9:28 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> >>> esteban >>> >>> tomorrow I can show you the bug I found. >>> >>> during the test of the correct reloading of RB >>> >>> (ConfigurationOfRefactoring project version: #stable) load >>> >>> in my noNautilus and no RB I got >>> >>> >>> systemMethodRecategorizedActionFrom: ann >>> "a protocol has been renamed >>> a method has been removed. // WILL BE TREATED WITH SystemMethodRemovedAnnouncement >>> a method has been moved to another category >>> -maybe from the classic category to an extending package >>> -maybe from an extending package to another extending package >>> -maybe from an extending package to a classic category >>> - maybe from a classic category to another classic category" >>> >>> | oldProtocol newProtocol method methodPackage destinationPackage | >>> >>> oldProtocol := ann oldProtocol. >>> "old protocol might be nil:" >>> oldProtocol asString ifNil: [oldProtocol := '']. >>> newProtocol := ann newProtocol. >>> method := ann methodRecategorized. >>> >>> "1). See compiledMethod >> packageFromOrganizer:" >>> >>> "we have to pay attention that this announcement can come from TraitDescription>>updateOrganizationSelector:oldCategory:newCategory: . In this context, it can happen that the method referenced by the event is nil. In this case I think we should change nothing" >>> >>> >>> method isNil ifFalse: [ >>> "If the method origin is not the one of the event, we do not care about that method" >>> method origin = ann methodClass ifFalse: [^ self]. >>> >>> methodPackage := method packageFromOrganizer: self. >>> "if newProtocol is nil, it means that we are in a 'methodRemoved' case. Nothing should be modified (all the work will be done when catching methodRemovedAnnouncement) " >>> newProtocol isNil ifTrue: [^self]. >>> "it can happen that oldProtocol is Nil. in this case we should do nothing" >>> oldProtocol ifNil: [^ self]. >>> "maybe the category has changed" >>> newProtocol asLowercase = oldProtocol asLowercase >>> ifFalse: [ >>> "according the extension specified is valid or not, the method will be defined as an extension of an external package or in the class parent package" >>> destinationPackage := (self hasPackageForProtocol: newProtocol inClass: method methodClass) >>> ifTrue: [ self packageForProtocol: newProtocol inClass: method methodClass ] >>> ifFalse: [ >>> (newProtocol beginsWith: '*') >>> ifTrue: [ self ensureExistAndRegisterPackageNamed: newProtocol allButFirst capitalized ] >>> ifFalse: [ method methodClass package ] ]. >>> methodPackage := (self hasPackageForProtocol: oldProtocol inClass: method methodClass) >>> ifTrue: [ self packageForProtocol: oldProtocol inClass: method methodClass ] >>> ifFalse: [ method methodClass package ]. >>> >>> "then, we will remove the method from the method package, and add it to the destination package (we check before that the source package and the destination package are different)." >>> methodPackage = destinationPackage >>> ifFalse: [ >>> (methodPackage methods includes: method) >>> ifTrue: [ methodPackage removeMethod: method ]. >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> where method was ClassTrait>>#soleInstance and apparently it does not exit raising an error >>> >>> classDefinitionSelectors in RPackage is >>> a Set(#instanceVariableNames: #classTrait #copy #adoptInstance:from: #compile:classified:withStamp:notifying:logSource: #baseTrait #name #baseTrait: #isClassTrait #definition #classTrait: #initializeWithBaseTrait: #new #isBaseTrait) >>> >>> classExtensionSelectors is Set new >>> and after investigation: >>> soleInstance on ClassTrait is defined as an extension on *refactoring-core >>> => >>> >>> >>> >>> destinationPackage addMethod: method. >>> >>> SystemAnnouncer uniqueInstance >>> methodRepackaged: method >>> from: methodPackage >>> to: destinationPackage. >>> ] >>> ] >>> ] >> >> > >

Oct. 2, 2013

Re: [Pharo-dev] Pharo hangout analysis

by kilon

Definitely a success story as a first. The one thing missing as I pointed out is meeting notes, so people who connect have an idea where you are and what you doing, so they don't have to ask you each time someone joins. As I found it this is possible through the hangout apps -> Google Drive -> hangout notes. I think it will be better if you follow a schedule , or at least pick a theme (or multiple) for each meeting. It will give it a purpose and make it look less random. I really loved the share screen experience, seeing you code has been a valuable lesson and I would love to watch more coding sessions and eventually participating myself when I feel more confident with Pharo. I also really liked the fact that the meeting lasted so long. The idea of video recording those sessions for later watching is also very appealing to me. Well done :) -- View this message in context: http://forum.world.st/Pharo-hangout-analysis-tp4712008p4712043.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by phil＠highoctane.be

I am also asking myself the same questions. But there are ways to achieve it all with Pharo I think. It may require more shuffling of data but it can be done. Especially when looking at the problems with uncoupling the parts (like I do here w/ RabbitMQ and Stamp). Much easier to use services (returning json or Ston (better)) to load user views on data. Not as nice as pure OO everywhere but still very productive. Phil On Wed, Oct 2, 2013 at 9:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Mariano, > > On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > Hi guys. > > First, let me apologize for the amount of emails I am sending. I am > doing an analysis to see if GemStone is a good candidate for a project I am > working and so it deserves some research. > > > > I wondered if any has ever tried porting any of these tools to GemStone: > Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. > > I do not understand. > > IMHO there is only one reason to go to Gemstone, and that is to use its > capabilities as OODB. All the technologies you mention are persistency > related and would not be needed in that case, right ? > > As you most probably know, you can get pretty far with Pharo. After that, > there is load-balancing, partitioning, message queues. Pretty much what any > technology stack does. > > You will always find more tools and libraries on the Pharo side, as the > community is much larger. > > Sven > > > Thanks a lot in advance, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > >

Oct. 2, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=wi… 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion

Oct. 2, 2013