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

Re: [Pharo-users] ZdcSocketStream dnu #position

by StÃ©phane Ducasse

https://pharo.fogbugz.com/default.asp?11088 On Jun 30, 2013, at 9:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Again, Paul, > > It was a typo ;-) > I added two new unit test as well. > > Here are the relevant commits: > > === > Name: Zinc-HTTP-SvenVanCaekenberghe.372 > Author: SvenVanCaekenberghe > Time: 30 June 2013, 9:06:10.101049 pm > UUID: 98ea090f-27d4-498e-8111-95e954d010a9 > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.371 > > Fixed a typo in ZnStringEntity>>#readFrom: (thanks Paul DeBruicker for reporting the issue) > === > Name: Zinc-Tests-SvenVanCaekenberghe.191 > Author: SvenVanCaekenberghe > Time: 30 June 2013, 9:07:42.519249 pm > UUID: 25345906-5574-4fd3-a5d9-eeee711fdf58 > Ancestors: Zinc-Tests-SvenVanCaekenberghe.190 > > Added ZnClientTests>>testGet[Large]WideStringHTML > === > > You'll have to load #bleedingEdge to get these. > > Thanks again for testing the latest version and reporting the issue. > > Sven > > On 30 Jun 2013, at 20:19, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi Paul, >> >> On 30 Jun 2013, at 19:38, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >> >>> Hi - >>> >>> I've got both Zinc and Zodiac loaded into a Pharo 2 image. When I do a >>> ZnClient #get: to an http connection I'm getting the dnu mentioned in >>> the subject of this email. >>> >>> >>> The message send that causes it is in ZnStringEntity>>#readFrom: >>> >>> >>> ZnNetworkingUtils default socketStreamClass prints: 'ZdcSocketStream' >>> >>> Changing that to 'SocketStream' like so: >>> >>> ZnNetworkingUtils default socketStreamClass: SocketStream >>> >>> makes everything work . >>> >>> >>> Just wanted to let you know >>> >>> >>> Paul >> >> Thanks a lot for reporting this issue. >> >> It is a bit weird though: I normally don't use #position on principle, but apparently I did in some recent optimisation code, I also vaguely remember adding #position somewhere.. >> >> Furthermore, all unit tests are green on both 2.0 and latest 3.0 with ZdcSocketStream as default. >> >> Step one would be to add a unit test. >> >> Is it possible for you to give me the URL or a similar one exposing the problem - it would have to be related to non-ASCII, non-Latin-1 characters I guess. >> >> Thanks, >> >> Sven >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > >

June 30, 2013

Re: [Pharo-users] trait question

by Tudor Girba

Hi, Theoretically, I could do the same for inheritance as well. But, that would be too complex for most cases, so it is the implicit behavior. To me, the decision for trait handling is similar. Cheers, Doru On Sun, Jun 30, 2013 at 2:54 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > On 2013-06-30, at 11:16, Sebastian Tleye <stleye(a)gmail.com> wrote: > > I also like this uniform because it's easier to program, > > Up to now i haven't had the need to separate them. > > > > 2013/6/30 Tudor Girba <tudor(a)tudorgirba.com> > >> +1 > >> > >> Keeping things uniform is a plus in this case, even though we might lose > >> some flexibility. > >> > >> Doru > > > But you know that you can do this right now? > > Object subclass: #Foo > uses: TMyTrait classTrait > > and the same on the class-side :/ > > Foo class > uses: TMyOtherTrait > instanceVariableNames: 'a b c' > > so from that point of view the current system allows for a messy/flexible > combination > of instance-side and class-side traits. > > > -- www.tudorgirba.com "Every thing has its own flow"

June 30, 2013

Re: [Pharo-users] ZdcSocketStream dnu #position

by Sven Van Caekenberghe

Hi Again, Paul, It was a typo ;-) I added two new unit test as well. Here are the relevant commits: === Name: Zinc-HTTP-SvenVanCaekenberghe.372 Author: SvenVanCaekenberghe Time: 30 June 2013, 9:06:10.101049 pm UUID: 98ea090f-27d4-498e-8111-95e954d010a9 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.371 Fixed a typo in ZnStringEntity>>#readFrom: (thanks Paul DeBruicker for reporting the issue) === Name: Zinc-Tests-SvenVanCaekenberghe.191 Author: SvenVanCaekenberghe Time: 30 June 2013, 9:07:42.519249 pm UUID: 25345906-5574-4fd3-a5d9-eeee711fdf58 Ancestors: Zinc-Tests-SvenVanCaekenberghe.190 Added ZnClientTests>>testGet[Large]WideStringHTML === You'll have to load #bleedingEdge to get these. Thanks again for testing the latest version and reporting the issue. Sven On 30 Jun 2013, at 20:19, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Paul, > > On 30 Jun 2013, at 19:38, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > >> Hi - >> >> I've got both Zinc and Zodiac loaded into a Pharo 2 image. When I do a >> ZnClient #get: to an http connection I'm getting the dnu mentioned in >> the subject of this email. >> >> >> The message send that causes it is in ZnStringEntity>>#readFrom: >> >> >> ZnNetworkingUtils default socketStreamClass prints: 'ZdcSocketStream' >> >> Changing that to 'SocketStream' like so: >> >> ZnNetworkingUtils default socketStreamClass: SocketStream >> >> makes everything work . >> >> >> Just wanted to let you know >> >> >> Paul > > Thanks a lot for reporting this issue. > > It is a bit weird though: I normally don't use #position on principle, but apparently I did in some recent optimisation code, I also vaguely remember adding #position somewhere.. > > Furthermore, all unit tests are green on both 2.0 and latest 3.0 with ZdcSocketStream as default. > > Step one would be to add a unit test. > > Is it possible for you to give me the URL or a similar one exposing the problem - it would have to be related to non-ASCII, non-Latin-1 characters I guess. > > Thanks, > > Sven > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

June 30, 2013

Re: [Pharo-users] ZdcSocketStream dnu #position

by Sven Van Caekenberghe

Hi Paul, On 30 Jun 2013, at 19:38, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi - > > I've got both Zinc and Zodiac loaded into a Pharo 2 image. When I do a > ZnClient #get: to an http connection I'm getting the dnu mentioned in > the subject of this email. > > > The message send that causes it is in ZnStringEntity>>#readFrom: > > > ZnNetworkingUtils default socketStreamClass prints: 'ZdcSocketStream' > > Changing that to 'SocketStream' like so: > > ZnNetworkingUtils default socketStreamClass: SocketStream > > makes everything work . > > > Just wanted to let you know > > > Paul Thanks a lot for reporting this issue. It is a bit weird though: I normally don't use #position on principle, but apparently I did in some recent optimisation code, I also vaguely remember adding #position somewhere.. Furthermore, all unit tests are green on both 2.0 and latest 3.0 with ZdcSocketStream as default. Step one would be to add a unit test. Is it possible for you to give me the URL or a similar one exposing the problem - it would have to be related to non-ASCII, non-Latin-1 characters I guess. Thanks, Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

June 30, 2013

ZdcSocketStream dnu #position

by Paul DeBruicker

Hi - I've got both Zinc and Zodiac loaded into a Pharo 2 image. When I do a ZnClient #get: to an http connection I'm getting the dnu mentioned in the subject of this email. The message send that causes it is in ZnStringEntity>>#readFrom: ZnNetworkingUtils default socketStreamClass prints: 'ZdcSocketStream' Changing that to 'SocketStream' like so: ZnNetworkingUtils default socketStreamClass: SocketStream makes everything work . Just wanted to let you know Paul

June 30, 2013

Log4s is fixed

by Donald

The new version 17 of log4s in ss3.gemstone works without the dependency on Benoits Bindings package. Feedback welcome. -- Donald [|] A bad day in [] is better than a good day in {}

June 30, 2013

Re: [Pharo-users] trait question

by StÃ©phane Ducasse

> > > But you know that you can do this right now? > > Object subclass: #Foo > uses: TMyTrait classTrait > > and the same on the class-side :/ > > Foo class > uses: TMyOtherTrait > instanceVariableNames: 'a b c' > > so from that point of view the current system allows for a messy/flexible combination > of instance-side and class-side traits. yes because you can have class side trait. and this is too complex. I agree. In fact I really have a love/hate feeling about traits. Stef

June 30, 2013

Re: [Pharo-users] trait question

by StÃ©phane Ducasse

On Jun 30, 2013, at 2:54 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > uses: TMyOtherTrait

June 30, 2013

Re: [Pharo-users] trait question

by Damien Cassou

On Sun, Jun 30, 2013 at 2:54 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > But you know that you can do this right now? I think these examples only show that some verifications are missing. I don't know any source code using that. To me it's more a bug than a feature. I would keep things simple: applying a trait to a class applies the classTrait to the metaclass. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 30, 2013

Re: [Pharo-users] trait question

by Camillo Bruni

On 2013-06-30, at 11:16, Sebastian Tleye <stleye(a)gmail.com> wrote: > I also like this uniform because it's easier to program, > Up to now i haven't had the need to separate them. > > 2013/6/30 Tudor Girba <tudor(a)tudorgirba.com> >> +1 >> >> Keeping things uniform is a plus in this case, even though we might lose >> some flexibility. >> >> Doru But you know that you can do this right now? Object subclass: #Foo uses: TMyTrait classTrait and the same on the class-side :/ Foo class uses: TMyOtherTrait instanceVariableNames: 'a b c' so from that point of view the current system allows for a messy/flexible combination of instance-side and class-side traits.

June 30, 2013