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

Re: [Pharo-project] where is the inbox for 3.0?

by Esteban Lorenzano

it should be already there since a couple of versions, afaik Esteban On Mar 22, 2013, at 11:37 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > thanks > We should add it to 3.0a > > Stef > > On Mar 21, 2013, at 10:59 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main' >> user: '' >> password: '' >> >> Ben >> >> On Mar 21, 2013, at 10:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> >>> >> >

March 22, 2013

Re: [Pharo-project] where is the inbox for 3.0?

by stephane ducasse

thanks We should add it to 3.0a Stef On Mar 21, 2013, at 10:59 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > MCHttpRepository > location: 'http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main' > user: '' > password: '' > > Ben > > On Mar 21, 2013, at 10:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> >

March 22, 2013

[Pharo-project] [update 3.0] #30005

by Marcus Denker

30005 ----- 10055 Spec better add:withSpec: handling https://pharo.fogbugz.com/f/cases/10055/Spec-better-add-withSpec-handling 7262 remove #stringRepresentation https://pharo.fogbugz.com/f/cases/7262/remove-stringRepresentation Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Layout-MarcusDenker.31 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Core-MarcusDenker.93 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Collections-Strings-MarcusDe…

March 22, 2013

Re: [Pharo-project] fogbugz filters

by Benjamin

Cool ;) I fixed FridaySprint which was returning nothing (strange bug from fogbugz i guess) Ben On Mar 21, 2013, at 8:24 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I just added a couple of useful filters on fogbugz for all those > people complaining about not finding things :P > > https://pharo.fogbugz.com/default.asp?pg=pgManageFilters > > have fun! >

March 21, 2013

Re: [Pharo-project] SocketStream>>#next:

by Nicolas Cellier

In other Smalltalk (VW, Dolphin, ...) there is nextAvailable: anInteger "Answer the next anInteger elements of the receiver. If there are not enough elements available, answer a collection of as many as are available." while next: would raise an Error if incomplete... Maybe it's time to adopt it. Nicolas 2013/3/21 Igor Stasenko <siguctua(a)gmail.com>: > On 21 March 2013 20:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> >> Related to a hard to find Zinc bug that I just discovered, I require some feedback as to the semantics of SocketStream>>#next: >> >> IMHO, the current implementation is semantically wrong. I would expect the semantics to be: try to read count elements and return a new species collection containing them. If less elements are available, return a smaller collection. ( It then becomes effectively a limited #upToEnd). >> >> I always implemented #next: by delegating to #next:into:, to #next:into:startingAt: and finally #readInto:startingAt:count: (see for example ZdcAbstractSocketStream, ZnLimitedReadStream or ZnChunkedReadStream). >> >> When you look at the implementations of #next:into:, #next:into:startingAt: and #readInto:startingAt:count: on SocketStream, the fact that ConnectionClosed is not signalled is clearly stated. Yet SocketStream>>#next: is different, it does signal ConnectionClosed, which makes it impossible (unless you proceed the exception) to read up to end. And this is what InflateStream>>#getFirstBuffer expects. And which fails when less than 65536 bytes are available. Note that InflateStream reads its subsequent buffers using #next:into:startingAt: (see #moveSourceToFront) so that it properly reads up to end without signalling ConnectionClosed for larger payloads. >> >> I can easily program around it, but I think SocketStream>>#next: is wrong and should be changed. >> >> Any opinions ? >> >> Sven >> > I agree, the implementation notes of #next: should be: > - read the N elements from receiver, answer a collection of read elements. > if receiver at end, or will reach end before reading all N elements, > answer a collection of elements > which were successfully read. > .. > the caller can always check the collection size, and if it < N, (and > he insists on having N) he can either throw an error or handle it more > graciously. > > '' readStream next: 5 > answering '' > so, it actually consistent with what i stating. > > A reference implementation (in Stream), however doesn't works like that: > > next: anInteger > "Answer the next anInteger number of objects accessible by the receiver." > > | aCollection | > aCollection := OrderedCollection new. > anInteger timesRepeat: [aCollection addLast: self next]. > ^aCollection > > this code will always answer collection of N elements.. > the bad side of it, that if stream reaching end, the tail will be > filled with 'userful' nils. :) > > so , based on ReadStream implementation we can assume that caller > already expects > to receive <=N elements, but not N with partly filled with nils. > > Because then you cannot distinguish whether this nil goes from stream > data or from stream itself, e.g.: > > #( 1 3 nil 4 5 nil nil ) readStream next: 10. > >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> > > > > -- > Best regards, > Igor Stasenko. >

March 21, 2013

Re: [Pharo-project] one-click is dead, now we have platform specific builds

by Igor Stasenko

On 21 March 2013 21:09, Chris Muller <asqueaker(a)gmail.com> wrote: >>>> windows and linux users (specially newcomers) where having bad >>>> reaction with the structure that the one-click enforces. >>> >>> I'm interested in the details. Are they documented somewhere, or >>> can you enumerate here? >> >> https://news.ycombinator.com/item?id=5395496 describes one newbie's >> first impressions of the all-in-one approach. > > Hmm, I've got to wonder whether, if it had actually _worked_ the first > time for him, whether he'd have written those negative comments at > all. I mean, at first he actually wrote: > > "I was excited to get started, so I figured I could download the > "one-click" for version 1.4 and get started right away." > > At that point, he had no problems with the _idea_ of one-click. It > later seemed it was only the implementation he didn't like. > > I'm interested in the topic of app-accessibility, and that's why I'm > really parsing his words and trying to understand. Since he also > wrote: > > "...and it definitely doesn't show that the developers know how to > properly distribute their software for multiple platforms..." > > I wish he'd have enlightened us all, WHAT is the the way to properly > distribute one's software for multiple platforms besides the browser.. > i can tell you how: - we should distribute an xml file, with .jnlp extension :) (of course, you will need java run time already installed on your platform, but who cannot install it? it is just a couple of clicks on java.com site ;) -- Best regards, Igor Stasenko.

March 21, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Camillo Bruni

On 2013-03-21, at 20:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 21 Mar 2013, at 14:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 21 Mar 2013, at 14:37, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: >> >>> I will check, however it happes for a lot of packages. >>> Some work, and some do not work. >> >> Strange, I don't think it has to do with the contents, the MC unzipping has not yet even happened. >> Maybe the size is an element (chunking, buffering). >> >>> @Sven I have a linux installation on virtual box where I could reproduce this problem. >>> I can give you access to it. >> >> OK, continuing off list. >> >> Sven > > Andrei was very helpful in giving me remote access to a machine with a Pharo 2.0 image running inside their network, so that I could have a look at his problem myself - Thanks Andrei ! > > I think I finally found the cause of this mysterious bug. > > The bug only appears when ZnEntityReader>>#readEntityFromStream needs to read a GZIP compressed response without an explicit Content-Length (so that it has to read up to end - pretty rare, apparently more common in the case of certain proxies) for a total size less than 65536 bytes (that is why it didn't happen on all cases ;-). yes I think that's how far I came as well :) > In these particular circumstances, a GZipReadStream was created directly on top of a raw SocketStream, which immediately sends a #next: 65536 to the SocketStream. Which fails with a ConnectionClosed instead of returning just the available bytes (like #upToEnd). > > The fix depends on the question which method is actually wrong, the subject of my next mail ;-) awesome! thanks for the nailing that one down! :)

March 21, 2013

Re: [Pharo-project] SocketStream>>#next:

by Igor Stasenko

On 21 March 2013 20:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Related to a hard to find Zinc bug that I just discovered, I require some feedback as to the semantics of SocketStream>>#next: > > IMHO, the current implementation is semantically wrong. I would expect the semantics to be: try to read count elements and return a new species collection containing them. If less elements are available, return a smaller collection. ( It then becomes effectively a limited #upToEnd). > > I always implemented #next: by delegating to #next:into:, to #next:into:startingAt: and finally #readInto:startingAt:count: (see for example ZdcAbstractSocketStream, ZnLimitedReadStream or ZnChunkedReadStream). > > When you look at the implementations of #next:into:, #next:into:startingAt: and #readInto:startingAt:count: on SocketStream, the fact that ConnectionClosed is not signalled is clearly stated. Yet SocketStream>>#next: is different, it does signal ConnectionClosed, which makes it impossible (unless you proceed the exception) to read up to end. And this is what InflateStream>>#getFirstBuffer expects. And which fails when less than 65536 bytes are available. Note that InflateStream reads its subsequent buffers using #next:into:startingAt: (see #moveSourceToFront) so that it properly reads up to end without signalling ConnectionClosed for larger payloads. > > I can easily program around it, but I think SocketStream>>#next: is wrong and should be changed. > > Any opinions ? > > Sven > I agree, the implementation notes of #next: should be: - read the N elements from receiver, answer a collection of read elements. if receiver at end, or will reach end before reading all N elements, answer a collection of elements which were successfully read. .. the caller can always check the collection size, and if it < N, (and he insists on having N) he can either throw an error or handle it more graciously. '' readStream next: 5 answering '' so, it actually consistent with what i stating. A reference implementation (in Stream), however doesn't works like that: next: anInteger "Answer the next anInteger number of objects accessible by the receiver." | aCollection | aCollection := OrderedCollection new. anInteger timesRepeat: [aCollection addLast: self next]. ^aCollection this code will always answer collection of N elements.. the bad side of it, that if stream reaching end, the tail will be filled with 'userful' nils. :) so , based on ReadStream implementation we can assume that caller already expects to receive <=N elements, but not N with partly filled with nils. Because then you cannot distinguish whether this nil goes from stream data or from stream itself, e.g.: #( 1 3 nil 4 5 nil nil ) readStream next: 10. > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > -- Best regards, Igor Stasenko.

March 21, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Andrei Vasile Chis

Thanks for taking the time to look into this. Cheers, Andrei On Thu, Mar 21, 2013 at 8:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 21 Mar 2013, at 14:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 21 Mar 2013, at 14:37, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: >> >>> I will check, however it happes for a lot of packages. >>> Some work, and some do not work. >> >> Strange, I don't think it has to do with the contents, the MC unzipping has not yet even happened. >> Maybe the size is an element (chunking, buffering). >> >>> @Sven I have a linux installation on virtual box where I could reproduce this problem. >>> I can give you access to it. >> >> OK, continuing off list. >> >> Sven > > Andrei was very helpful in giving me remote access to a machine with a Pharo 2.0 image running inside their network, so that I could have a look at his problem myself - Thanks Andrei ! > > I think I finally found the cause of this mysterious bug. > > The bug only appears when ZnEntityReader>>#readEntityFromStream needs to read a GZIP compressed response without an explicit Content-Length (so that it has to read up to end - pretty rare, apparently more common in the case of certain proxies) for a total size less than 65536 bytes (that is why it didn't happen on all cases ;-). > > In these particular circumstances, a GZipReadStream was created directly on top of a raw SocketStream, which immediately sends a #next: 65536 to the SocketStream. Which fails with a ConnectionClosed instead of returning just the available bytes (like #upToEnd). > > The fix depends on the question which method is actually wrong, the subject of my next mail ;-) > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

March 21, 2013

Re: [Pharo-project] Pharo Portable was Re: one-click is dead, now we have platform specific builds

by Chris Muller

>> Hi Sean, >> yes, the procedure is still there, and it is still possible to produce >> one-click distributions... maybe we could produce a "portable" version (I >> think the portable concept captures better what a one-click is... because a >> one click is not a one click, you still need to double click on it :D ) "One-click" in this context generally means "one stop". It could involve a few clicks and/or gestures, but the important meaning is there is only one initial place from which the software is installed and not having to, for example, pre-install something else first. So, from that aspect, neither Squeak nor Pharo is one-click on 64-bit Linux because one has to install the 32-bit libs first. :(

March 21, 2013