- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About Seed, Hazelnut and related

by Ben Coman

Edgar J. De Cleene wrote: > >From the excellent blog http://playingwithobjects.wordpress.com/ Guille > was doing we read > > The results of the project so far are: > * It can create an Smalltalk image living inside another image. > This sounds useful to my earlier question to mixing open and closed source.

June 5, 2012

Re: [Pharo-project] Next step in cleaning DataStream

by Mariano Martinez Peck

On Tue, Jun 5, 2012 at 3:36 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Guys..the fact of having to make everything deprecated instead of removing > it is really a pain. Now ReferenceStream is not removed but > deprecated..meaning that it *should* work. So instead of removing > everything I have to change it a lot so that it "still" works but > deprecated. Can we just assume that ReferenceStream will be removed in 2.0 > please? In addition, if someone is really worried about ReferenceStream then he can always do a fileout of 1.4 and import it in Pharo 2.0 (and adapt it if necessary) > > > On Tue, Jun 5, 2012 at 1:32 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Ok. Perfect. So let's assume DataStream is used only for Motnicello. I >> will rename it to MCDataStream, move it to Monticello Package and see all >> what I can remove/clean. >> I will let you know. >> >> Cheers >> >> >> On Tue, Jun 5, 2012 at 12:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: >> >>> +1 >>> >>> On Jun 4, 2012, at 6:15 PM, Damien Cassou wrote: >>> >>> > On Mon, Jun 4, 2012 at 6:09 PM, Pavel Krivanek < >>> pavel.krivanek(a)gmail.com> wrote: >>> >> I think it is a good proposal. Then it can be in separate package or >>> as part >>> >> of MC package. >>> > >>> > I would put DataStream and its friends within the monticello package, >>> > and prepend MC to their names. Then, you can clean the resulting >>> > classes if you want to. >>> > >>> > -- >>> > Damien Cassou >>> > http://damiencassou.seasidehosting.st >>> > >>> > "Lambdas are relegated to relative obscurity until Java makes them >>> > popular by not having them." James Iry >>> > >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

June 5, 2012

Re: [Pharo-project] Next step in cleaning DataStream

by Mariano Martinez Peck

On Tue, Jun 5, 2012 at 3:36 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Guys..the fact of having to make everything deprecated instead of removing > it is really a pain. Now ReferenceStream is not removed but > deprecated..meaning that it *should* work. So instead of removing > everything I have to change it a lot so that it "still" works but > deprecated. Can we just assume that ReferenceStream will be removed in 2.0 > please? > > > And moreover, I have another question. With this change, I remove DiskProxy and if I move MCDataStream to Monticello package, then the only class that remains in System-Object Storage is DeepCopier. It makes no sense to keep only that class there. So, I vote for removing the package and move that class somewhere. Now.. any ideas what that "somewhere" could be? > On Tue, Jun 5, 2012 at 1:32 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Ok. Perfect. So let's assume DataStream is used only for Motnicello. I >> will rename it to MCDataStream, move it to Monticello Package and see all >> what I can remove/clean. >> I will let you know. >> >> Cheers >> >> >> On Tue, Jun 5, 2012 at 12:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: >> >>> +1 >>> >>> On Jun 4, 2012, at 6:15 PM, Damien Cassou wrote: >>> >>> > On Mon, Jun 4, 2012 at 6:09 PM, Pavel Krivanek < >>> pavel.krivanek(a)gmail.com> wrote: >>> >> I think it is a good proposal. Then it can be in separate package or >>> as part >>> >> of MC package. >>> > >>> > I would put DataStream and its friends within the monticello package, >>> > and prepend MC to their names. Then, you can clean the resulting >>> > classes if you want to. >>> > >>> > -- >>> > Damien Cassou >>> > http://damiencassou.seasidehosting.st >>> > >>> > "Lambdas are relegated to relative obscurity until Java makes them >>> > popular by not having them." James Iry >>> > >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

June 5, 2012

Re: [Pharo-project] Trouble loading XML RPC

by Noury Bouraqadi

On 5 juin 2012, at 13:28, garduino wrote: >> Can I get write access grant to the repo, so I can upload any improvement >> I do ? > > Sure, I added you as developer. Let me know if works ok. > Thanx. I'll try it. >> What I wanted to do is to cut off everything not XML RPC and complete >> based on sUnit tests. >> BTW, any simple way to load all SUnit tests for all packages ? > > I'm not sure of understand what you mean. > Actually, I get only tests from xml rpc with your procedure. I thought there might be a way to get all tests for all required packages, to test their compatibility with Pharo 2.0 But, it seems that I have to load them by hand. Any way, I tried on Pharo 2.0. There is the issue of underscores, but this is no big deal. The good news is that the client side seems to work. At least the tests are green for parts that does not rely on a local server (XMLRPCTest is red!). Tests with Flicker do pass. There is however XMLROCDecoderTest>>#testDecoder that fails. The reason is that now Pharo does take care of nanoseconds, but the encoder does not handle it. I guess this is not supported in the protocol. Isn't it? So, I propose to fix it but putting nanoseconds to zero XMLRPCDateAndTime>>time: t "set the time portion of the datetime." time := Time fromSeconds: t seconds truncated Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

June 5, 2012

[Pharo-project] [update 2.0] #20110

by Torsten Bergmann

2012/6/5 Sven Van Caekenberghe <sven at beta9.be>: > Haha, very funny. > > It's a good thing there are so many jokes hidden inside the image. > > We could add a couple/many more: > > self deny: 1 = 2. Now that Pharo becomes a "real" piece of software shouldnt we add a "real" easter egg [1]. Maybe: self assert: Smalltalk theAnswerToLifeTheUniverseAndEverything = 42 ;) Bye T. [1] http://en.wikipedia.org/wiki/Easter_egg_(media) -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

June 5, 2012

Re: [Pharo-project] ClassBoxes... bitrotted, or usable?

by StÃ©phane Ducasse

On Jun 5, 2012, at 9:52 AM, Jan Vrany wrote: > On 04/06/12 22:56, Alexandre Bergel wrote: >> This was the implementation in Modular Smalltalk if I remember correctly. >> >> In plain Smalltalk you send a message named #msg and the lookup gives you a compile method. >> In Modular Smalltalk, there is an intermediary step: #msg -> #Namespace.msg -> compile method >> > > I see. What I do not see is how to achieve this without a cost at runtime. Given that it should support imports. Without imports, SNs are > pretty much useless :-) I guess that you are saying that you need a look up between selectornamespace because you can have A>String>>foo ^ 666 A>String>>bar ^ self foo => compiled into A>String>>bar ^ self #A.foo B import A B>String>>foo ^ 42 in B 'ababab' foo -> 42 'ababab' bar =>compiled in ababab' #B.bar should still execute 'ababab' #A.bar since it is not redefined Yes I agree with you. Stef

June 5, 2012

Re: [Pharo-project] ClassBoxes... bitrotted, or usable?

by StÃ©phane Ducasse

> >> Jan did you have a look at http://timelessrepo.com/refinements-in-ruby >> Because I would like to know if there are more selector or classbox oriented or something else? >> > Briefly. That post is more a "wow-that's-cool" sort of post rather than in-depth technical report. Looks like classboxes without local > rebinding - that's what they say, after all. Yes I just read it and it looks more like selectorNamespaces but without any explanations.

June 5, 2012

Re: [Pharo-project] Next step in cleaning DataStream

by Mariano Martinez Peck

Guys..the fact of having to make everything deprecated instead of removing it is really a pain. Now ReferenceStream is not removed but deprecated..meaning that it *should* work. So instead of removing everything I have to change it a lot so that it "still" works but deprecated. Can we just assume that ReferenceStream will be removed in 2.0 please? On Tue, Jun 5, 2012 at 1:32 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Ok. Perfect. So let's assume DataStream is used only for Motnicello. I > will rename it to MCDataStream, move it to Monticello Package and see all > what I can remove/clean. > I will let you know. > > Cheers > > > On Tue, Jun 5, 2012 at 12:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> +1 >> >> On Jun 4, 2012, at 6:15 PM, Damien Cassou wrote: >> >> > On Mon, Jun 4, 2012 at 6:09 PM, Pavel Krivanek < >> pavel.krivanek(a)gmail.com> wrote: >> >> I think it is a good proposal. Then it can be in separate package or >> as part >> >> of MC package. >> > >> > I would put DataStream and its friends within the monticello package, >> > and prepend MC to their names. Then, you can clean the resulting >> > classes if you want to. >> > >> > -- >> > Damien Cassou >> > http://damiencassou.seasidehosting.st >> > >> > "Lambdas are relegated to relative obscurity until Java makes them >> > popular by not having them." James Iry >> > >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

June 5, 2012

Re: [Pharo-project] About announcements

by Igor Stasenko

On 5 June 2012 06:17, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > Â Hi All! > > Â Im adding an announcer in my project, 'cause, in order to build a call > graph, ill need to know about inferencer-stack movements.Â I was thinking, > the meaning of it is to create an announcement object with it configuration > for any push or pop of a stack that's similar to the runtime stack, these > are a lots lots lots of objects proably with lesser optimization than > BlockClosure. I was thinking in add extension methods that allow me > something like > i am not sure you using right thing for your task. an announcement is an event which you broadcast to subscribers. you can announce any object as announcement.. just make sure your subscription handles it.. i.e. you can use: announcer on: BlockAnnouncement send: #doBlock: to: self if you write: BlockAnnouncement class>>handles: announcement ^ announcement class == BlockClosure Myclass>>doBlock: closure .... do anything you like... x := closure value .. etc So, you can announce like: announcer announce: [ Stack push ] > self announce: [ StackPush new ] ifAnyIsInteresetedIn: StackPush. > > > Well, i have two questions: > > a) Am i right? > b) subscriptions variable at SubscriptionRegistry is an OrderedCollection, > but is commonly accessed to get the subscriptors related with some concrete > type, why not a Dictionary? is not faster than an OrderCollection in the > tipical case of use? Ok, it could complicate calls like 'remove: > subscriptor' but, commonly if you have the subscriptor, you have the > Announcement type. Maybe the common ammount of subscriptors in a announcer > is too little? > > Thanks! -- Best regards, Igor Stasenko.

June 5, 2012

[Pharo-project] [update 2.0] #20112

by Marcus Denker

20112 ----- Issue 6009: Improved ProcessTest http://code.google.com/p/pharo/issues/detail?id=6009 Issue 6023: Enhance MCHttpRepository>>readStreamForFileNamed:do: to require binary data http://code.google.com/p/pharo/issues/detail?id=6023 Issue 6022: Nuke Stream>>isTypeHTTP and Stream>>sleep http://code.google.com/p/pharo/issues/detail?id=6022 -- Marcus Denker -- http://marcusdenker.de

June 5, 2012