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

Re: [Pharo-project] [update 2.0] #20440

by StÃ©phane Ducasse

I will try to understand. Stef >> I'm "fixing the problem right now" >> Apparently we should do another >> ChangeSet cleanUp: true >> > > Something related to that was the reason why #cleanUpForRelease is broken. > > http://code.google.com/p/pharo/issues/detail?id=7028 > >> but this is what I did in the postscript of the previous update. >> The code of the changeSet should not be robust enough. >> >> Stef >> >> On Dec 19, 2012, at 10:10 AM, StÃ©phane Ducasse wrote: >> >>> Apparently the changes I integrated break the system. This is really strange since I tested them before pushing them. >>> >>> The changeSet should be in an inconsistent state >>> >>> >>> On Dec 18, 2012, at 10:17 PM, StÃ©phane Ducasse wrote: >>> >>>> >>>> 20440 >>>> ----- >>>> >>>> Issue 7141: Fix Find Class >>>> http://code.google.com/p/pharo/issues/detail?id=7141 >>>> Thanks benjamin van ryseghem >>>> >>>> Issue 7131: Clean change sets >>>> http://code.google.com/p/pharo/issues/detail?id=7131 >>>> >>>> Diff information: >>>> http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.72.diff >>>> http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.744.di… >>>> http://ss3.gemstone.com/ss/Pharo20/AsmJit-x86-StephaneDucasse.5.diff >>>> >>>> >>> >>> >> >> > >

Dec. 19, 2012

Re: [Pharo-project] [update 2.0] #20440

by Marcus Denker

On Dec 19, 2012, at 10:13 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I'm "fixing the problem right now" > Apparently we should do another > ChangeSet cleanUp: true > Something related to that was the reason why #cleanUpForRelease is broken. http://code.google.com/p/pharo/issues/detail?id=7028 > but this is what I did in the postscript of the previous update. > The code of the changeSet should not be robust enough. > > Stef > > On Dec 19, 2012, at 10:10 AM, StÃ©phane Ducasse wrote: > >> Apparently the changes I integrated break the system. This is really strange since I tested them before pushing them. >> >> The changeSet should be in an inconsistent state >> >> >> On Dec 18, 2012, at 10:17 PM, StÃ©phane Ducasse wrote: >> >>> >>> 20440 >>> ----- >>> >>> Issue 7141: Fix Find Class >>> http://code.google.com/p/pharo/issues/detail?id=7141 >>> Thanks benjamin van ryseghem >>> >>> Issue 7131: Clean change sets >>> http://code.google.com/p/pharo/issues/detail?id=7131 >>> >>> Diff information: >>> http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.72.diff >>> http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.744.di… >>> http://ss3.gemstone.com/ss/Pharo20/AsmJit-x86-StephaneDucasse.5.diff >>> >>> >> >> > >

Dec. 19, 2012

Re: [Pharo-project] [update 2.0] #20440

by StÃ©phane Ducasse

I'm "fixing the problem right now" Apparently we should do another ChangeSet cleanUp: true but this is what I did in the postscript of the previous update. The code of the changeSet should not be robust enough. Stef On Dec 19, 2012, at 10:10 AM, StÃ©phane Ducasse wrote: > Apparently the changes I integrated break the system. This is really strange since I tested them before pushing them. > > The changeSet should be in an inconsistent state > > > On Dec 18, 2012, at 10:17 PM, StÃ©phane Ducasse wrote: > >> >> 20440 >> ----- >> >> Issue 7141: Fix Find Class >> http://code.google.com/p/pharo/issues/detail?id=7141 >> Thanks benjamin van ryseghem >> >> Issue 7131: Clean change sets >> http://code.google.com/p/pharo/issues/detail?id=7131 >> >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.72.diff >> http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.744.di… >> http://ss3.gemstone.com/ss/Pharo20/AsmJit-x86-StephaneDucasse.5.diff >> >> > >

Dec. 19, 2012

Re: [Pharo-project] [update 2.0] #20440

by StÃ©phane Ducasse

Apparently the changes I integrated break the system. This is really strange since I tested them before pushing them. The changeSet should be in an inconsistent state On Dec 18, 2012, at 10:17 PM, StÃ©phane Ducasse wrote: > > 20440 > ----- > > Issue 7141: Fix Find Class > http://code.google.com/p/pharo/issues/detail?id=7141 > Thanks benjamin van ryseghem > > Issue 7131: Clean change sets > http://code.google.com/p/pharo/issues/detail?id=7131 > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.72.diff > http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.744.di… > http://ss3.gemstone.com/ss/Pharo20/AsmJit-x86-StephaneDucasse.5.diff > >

Dec. 19, 2012

[Pharo-project] [update 2.0] #20440

by StÃ©phane Ducasse

20440 ----- Issue 7141: Fix Find Class http://code.google.com/p/pharo/issues/detail?id=7141 Thanks benjamin van ryseghem Issue 7131: Clean change sets http://code.google.com/p/pharo/issues/detail?id=7131 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.72.diff http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.744.di… http://ss3.gemstone.com/ss/Pharo20/AsmJit-x86-StephaneDucasse.5.diff

Dec. 18, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 502 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Dec. 18, 2012

Re: [Pharo-project] Persistence Options

by Nicolas Petton

Yes, I'd really like to see Oak becoming more than a prototype. It requires more manpower though :) Nico Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > On Tue, Dec 18, 2012 at 5:35 AM, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > >> Hey! >> >> >> On 12/17/2012 07:08 PM, Torsten Bergmann wrote: >> >>> Persisting data is crucial for any application and there >>> are many ways to do it. Be it RDBMS, NoSQL stuff or in-image >>> persistency. There are many pre-built solutions: Gemstone, OpenDBX, >>> SandstoneDB, Mongo, ... >>> >>> From time to time I ask the question here on the list >>>> >>> to see how it evolves and what people actually use in >>> their Pharo applications: >>> >>> 1. What persistence option do we currently have >>> 2. What persistence is used in your Pharo application today >>> 3. Which persistence solution you want to use/would you >>> like to see in Pharo's future >>> 4. What would you recommend. >>> >> >> I can give some light on a few options that I have been involved in: >> >> TokyoTyrant >> =========== >> The "binding" I wrote hasn't been touched since I wrote it, but it is >> binary over SocketStream and VERY fast. There is now a new similar database >> called KyotoTycoon from the same author that he recommends as superior. >> Some differences: >> >> http://stackoverflow.com/**questions/4178414/what-is-the-** >> difference-between-tokyo-**cabinet-and-kyoto-cabinet<http://stackoverflow.com/questions/4178414/what-is-the-difference-between-t…> >> >> I am not using nor maintaining this library anymore though. Still the raw >> speed is amazing and if that is what you want then this one is hard to beat. >> >> NOTE: Not sure how it operates under Pharo but since it runs on top of >> SocketStream I suspect it just works. If someone tries it out, let me know. >> >> >> Phriak >> ====== >> This is a binding to Riak, perhaps the most insanely cool NoSQL database >> IMHO. Yeah, MongoDB is also very nice, but some aspects of Riak really >> makes me comfy and warm inside. >> >> The binding was started by Runar Jordahl called "EpigentRiakInterface", >> then I did a friendly fork and improved it even more, and then Nicolas >> Petton joined and improved it LOTS more, and now lately Paul De Bruicker >> has also joined with commits. >> >> Phriak is intentionally focused on Pharo and uses the Zinc components to >> implement the API which is HTTP based. Riak has protocol buffers too, but >> we haven't looked at that. >> >> This binding is maintained, pretty complete and very easy to use. Riak is >> also extremely easy to install. >> >> >> Oak >> === >> This is a not so well known little side project from Nicolas Petton that I >> also am messing around with now. Oak is an "OODBish layer" that first was >> written abstractly to work on top of Riak, MongoDB etc. Now we are >> refocusing it on Riak only, possibly keeping optional Memcache support. >> >> Oak uses two other very nice new technologies in Pharo: Fuel and Ghost. >> Fuel is well known, very good serialization library basically. Ghost is a >> new small library for making well behaving proxies, using a smarter >> approach than the old "subclass ProtoObject and implement >> #doesNotUnderstand:". >> > > :) Hope to have a journal paper soon! > > >> >> Net result is a semi transparent OODB which stores objects as Fuel blobs >> in Riak with UUIDs as keys. The auto faulting is done using Ghost proxies >> (so parts of your domain model are loaded "on demand" when you send >> messages to them). Oak is not super automagic like Magma - it doesn't do GC >> for example. But it is quite fast, small codebase and since it has a very >> simple model you can use other aspects of Riak through Phriak on the side. >> >> Oak is live and kicking and we are improving it by the day. So consider it >> a very interesting alpha, but still, small and simple codebase so you can >> use it already if you are not afraid to get your hands dirty. >> > > Yes, Oak is cool. We should continue with it! > > Cheers, > > -- > Mariano > http://marianopeck.wordpress.com -- Nicolas Petton http://nicolas-petton.fr

Dec. 18, 2012

Re: [Pharo-project] Persistence Options

by Mariano Martinez Peck

On Tue, Dec 18, 2012 at 5:35 AM, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hey! > > > On 12/17/2012 07:08 PM, Torsten Bergmann wrote: > >> Persisting data is crucial for any application and there >> are many ways to do it. Be it RDBMS, NoSQL stuff or in-image >> persistency. There are many pre-built solutions: Gemstone, OpenDBX, >> SandstoneDB, Mongo, ... >> >> From time to time I ask the question here on the list >>> >> to see how it evolves and what people actually use in >> their Pharo applications: >> >> 1. What persistence option do we currently have >> 2. What persistence is used in your Pharo application today >> 3. Which persistence solution you want to use/would you >> like to see in Pharo's future >> 4. What would you recommend. >> > > I can give some light on a few options that I have been involved in: > > TokyoTyrant > =========== > The "binding" I wrote hasn't been touched since I wrote it, but it is > binary over SocketStream and VERY fast. There is now a new similar database > called KyotoTycoon from the same author that he recommends as superior. > Some differences: > > http://stackoverflow.com/**questions/4178414/what-is-the-** > difference-between-tokyo-**cabinet-and-kyoto-cabinet<http://stackoverflow.com/questions/4178414/what-is-the-difference-between-t…> > > I am not using nor maintaining this library anymore though. Still the raw > speed is amazing and if that is what you want then this one is hard to beat. > > NOTE: Not sure how it operates under Pharo but since it runs on top of > SocketStream I suspect it just works. If someone tries it out, let me know. > > > Phriak > ====== > This is a binding to Riak, perhaps the most insanely cool NoSQL database > IMHO. Yeah, MongoDB is also very nice, but some aspects of Riak really > makes me comfy and warm inside. > > The binding was started by Runar Jordahl called "EpigentRiakInterface", > then I did a friendly fork and improved it even more, and then Nicolas > Petton joined and improved it LOTS more, and now lately Paul De Bruicker > has also joined with commits. > > Phriak is intentionally focused on Pharo and uses the Zinc components to > implement the API which is HTTP based. Riak has protocol buffers too, but > we haven't looked at that. > > This binding is maintained, pretty complete and very easy to use. Riak is > also extremely easy to install. > > > Oak > === > This is a not so well known little side project from Nicolas Petton that I > also am messing around with now. Oak is an "OODBish layer" that first was > written abstractly to work on top of Riak, MongoDB etc. Now we are > refocusing it on Riak only, possibly keeping optional Memcache support. > > Oak uses two other very nice new technologies in Pharo: Fuel and Ghost. > Fuel is well known, very good serialization library basically. Ghost is a > new small library for making well behaving proxies, using a smarter > approach than the old "subclass ProtoObject and implement > #doesNotUnderstand:". > :) Hope to have a journal paper soon! > > Net result is a semi transparent OODB which stores objects as Fuel blobs > in Riak with UUIDs as keys. The auto faulting is done using Ghost proxies > (so parts of your domain model are loaded "on demand" when you send > messages to them). Oak is not super automagic like Magma - it doesn't do GC > for example. But it is quite fast, small codebase and since it has a very > simple model you can use other aspects of Riak through Phriak on the side. > > Oak is live and kicking and we are improving it by the day. So consider it > a very interesting alpha, but still, small and simple codebase so you can > use it already if you are not afraid to get your hands dirty. > Yes, Oak is cool. We should continue with it! Cheers, -- Mariano http://marianopeck.wordpress.com

Dec. 18, 2012

[Pharo-project] [update 2.0] #20439

by StÃ©phane Ducasse

20439 ----- Fixing Spec binding problem Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.71.diff

Dec. 18, 2012

Re: [Pharo-project] Open a view to compare two metods

by Dario Trussardi

Thank, Ben it work fine into 1.4. Dario > I guess you can do something like > > (DiffMorph from: (MyClass>>#myFirstMethod) sourceCode to: (MyClass>>#mySecondMethod) sourceCode) openInWindow > > (I tried it in 2.0). > > Otherwise, I do no think that such a tool exists in 1.4 (in 2.0, you can do it with Nautilus). > > > Ben > > On Dec 18, 2012, at 4:11 PM, Dario Trussardi wrote: > >> Hi, >> i work with Pharo 1.4. >> >> I have a class with some methods. >> >> Now i'm interested to open a view to compare and see the difference relative two methods of a class. >> >> I see into method version the Compare to current buttons. >> >> It display the change. >> >> I can create this view relative to two methods of one class ? >> >> Thanks, >> >> Dario > >

Dec. 18, 2012