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

[Pharo-project] pharo-project.org: Twitter feed working again

by Marcus Denker

Hi, The twitter feed is shown again on the pharo-project.org website. See http://www.pharo-project.org Marcus

March 22, 2013

[Pharo-project] sorry, builds broken

by Camillo Bruni

I accidentally broke the zerconf scripts, though I learnt something doing so - need to test them on all 3 platforms separately - our windows slave has a broken git installation :)

March 22, 2013

Re: [Pharo-project] Updated the download page

by Marcus Denker

On Mar 22, 2013, at 3:34 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2013/3/22 Marcus Denker <marcus.denker(a)inria.fr>: >> >> http://www.pharo-project.org/pharo-download >> Instead of 1.4 and 2.0 it now lists 2.0 and 3.0 > > Markus, it should say there the 3.0 is Alpha. > > If somebody goes straight to that URI, unless they look at the sidebar > (which is unlikely) they may end up downloading an unstable version. > Done Marcus

March 22, 2013

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

by Sven Van Caekenberghe

Andrei, Igor, Nicolas, I just changed the implementation to SocketStream>>next: next: anInteger ^ self nextInto: (self streamBuffer: anInteger) and all NetworksTests-* and Zinc/Zdc tests are still green. @Andrei: could you please verify that this fixes your actual problem ? @Igor: I agree ;-) @Nicolas: Part of the problem is that the current implementors of #next: are inconsistent with each other, which is enough of a problem already. Looking at FileStream > StandardFileStream > MultiByteFileStream, they are inconsistent, for example. #nextAvailable: says better what we mean, agreed. But the 'available' word is not used anywhere else either. As Igor showed, how can the strange #next: behavior be useful ? I am more for simplifying what we have, instead of adding more selectors. And I think we all agree the current situation is not perfect, and more beautiful streams lurk in the future. Sven On 21 Mar 2013, at 22:45, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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 22, 2013

Re: [Pharo-project] Updated the download page

by Esteban A. Maringolo

2013/3/22 Marcus Denker <marcus.denker(a)inria.fr>: > > http://www.pharo-project.org/pharo-download > Instead of 1.4 and 2.0 it now lists 2.0 and 3.0 Markus, it should say there the 3.0 is Alpha. If somebody goes straight to that URI, unless they look at the sidebar (which is unlikely) they may end up downloading an unstable version. Regards!

March 22, 2013

[Pharo-project] Updated the download page

by Marcus Denker

http://www.pharo-project.org/pharo-download Instead of 1.4 and 2.0 it now lists 2.0 and 3.0

March 22, 2013

[Pharo-project] [update 3.0] #30007

by Marcus Denker

30007 ----- 10091 Update the Grab button https://pharo.fogbugz.com/f/cases/10091 7499 remove setting and code: #useHistoricalShortcuts https://pharo.fogbugz.com/f/cases/7499 7557 Adding an entry to the World menu to clear all breakpoints https://pharo.fogbugz.com/f/cases/7557 7620 Kill Object>>at:modify: https://pharo.fogbugz.com/f/cases/7620 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1061 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/StartupPreferences-MarcusDen… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Settings-Polymorph-MarcusDen… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Polymorph-Widgets-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Morphic-MarcusDenker.1374 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/MonticelloGUI-MarcusDenker.2… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1341

March 22, 2013

[Pharo-project] Not so nice refactoring behavior in Nautilus

by Stephan Eggermont

Hi, We're moving some code to Pharo 2.0 and noticed the following. When removing a method with a selector that is found often in the system, the warnings come one at a time, instead of in one dialog for all. That slows refactoring down quite a bit. Cheers, Stephan & Diego

March 22, 2013

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

by Sven Van Caekenberghe

On 21 Mar 2013, at 22:20, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > 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 :) Sure, you and I were looking at the same spot before, but actually being in the debugger made all the difference. BTW, AFAIK it was Andrei who figured out that proceeding from the exception actually produced a correct result. I really had to 'see' this to believe it. And even then it took some quiet thinking to understand the issue. >> 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 22, 2013

[Pharo-project] [update 3.0] #30006

by Marcus Denker

30006 ----- 10067 When creating Slices, only the SS3 inbox is offered https://pharo.fogbugz.com/f/cases/10067 10004 SmalltalkImage current reportCPUandRAM > DNU https://pharo.fogbugz.com/f/cases/10004 7282 DNU with Glamour: PaginatedMorphTreeMorph>>setSelectedMorph: https://pharo.fogbugz.com/f/cases/7282 10068 Undeclared in ScriptLoader>>#pharo20Repository https://pharo.fogbugz.com/f/cases/10068 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1060 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Morphic-MarcusDenker.1372 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Monticello-MarcusDenker.777

March 22, 2013