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

Re: [Pharo-project] Your earlier problems accessing Monticello

by Camillo Bruni

Guido is right now in Lille :P so you have to wait for a week. >From what I recall it was exactly that bug we had over in Argentina :) On 2013-03-23, at 11:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Guido, > > Some time ago you were unable to access Monticello from inside your particular network situation. > > http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-… > > We just were able to solve a similar case. > > http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Sma… > > Would it be possible to verify, first that your old problem still exists, and then try again with the following patch. > > SocketStream>>next: count > "Read count elements and return them in a collection. > If the receiver is #atEnd before count elements were read, return a smaller collection." > > ^ self nextInto: (self streamBuffer: count) > > That would be most helpful. > > Thx, > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

March 23, 2013

[Pharo-project] Your earlier problems accessing Monticello

by Sven Van Caekenberghe

Hi Guido, Some time ago you were unable to access Monticello from inside your particular network situation. http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-… We just were able to solve a similar case. http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Sma… Would it be possible to verify, first that your old problem still exists, and then try again with the following patch. SocketStream>>next: count "Read count elements and return them in a collection. If the receiver is #atEnd before count elements were read, return a smaller collection." ^ self nextInto: (self streamBuffer: count) That would be most helpful. Thx, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 23, 2013

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

by stephane ducasse

+1 I'm all in for fixing and getting a simpler and nicer system. > #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 23, 2013

Re: [Pharo-project] New consortium member: Thanks a lot High Octane!

by stephane ducasse

On Mar 22, 2013, at 5:32 PM, phil(a)highoctane.be wrote: > Hello, > > My pleasure. Hope to generate decent money with the platform so that I > can drown you guys in cash. BTW, I do have an opportunity for > something pretty around real-time dynamic inventory management > calculations, if you have the smarts, contact me privately, we may be > in for some cool stuff with Pharo. > > The site listed is an old one but I'll redo it in full to center it > around Pharo technology. Even the address is wrong, and I moved > several years ago (at least 4)â¦ sorry google. I thought that this web site was not the one I saw before. > > My current site is over http://philippeback.eu and hosts my business > of improving other businesses. For people who nothing better to do, > there is a blog on http://philippeback.be and something on youtube as > well (more pharo to be expected over there). > > Sorry to not have been able to go for the top two support slots, > hopefully I'll be able to next year. It is already wonderful. We know what is to make money. > > Phil > > 2013/3/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> We are really happy to announce that High Octane is a new member of the consortium. >> Thanks a lot for your trust, Philippe! >> >> http://www.highoctane.be/sections/vision.html >> >> Stef for the Pharo community! >

March 22, 2013

[Pharo-project] Fwd: 18 months Post-Doc Position on Software Engineering for Mobile Robotics

by Noury Bouraqadi

Begin forwarded message: > Date: 22 mars 2013 21:35:28 HNEC > Subject: 18 months Post-Doc Position on Software Engineering for Mobile Robotics > Source: CAR: Components, Agents, and Robots > Author: noury > > The CAR team (http://car.mines-douai.fr) carries research at the frontier of Software Engineering and Robotics. We study software architectures, languages and tools for controlling individual robots. We have developed an expertise in reflective and dynamic languages, as well as component models, for a modular robotic software architectures. Besides, our research also addresses coordination and cooperation inâ¦ Continue reading â > Read moreâ¦ > Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --

March 22, 2013

Re: [Pharo-project] [update 3.0] #30008

by stephane ducasse

> > 10094 Slice copy just copy the slice > https://pharo.fogbugz.com/f/cases/10094/ excellent!!! Now hen we copy a slice all its dependents get copied too :) Thanks ben. Stef

March 22, 2013

Re: [Pharo-project] Configurations PetitParser, Grease and Seaside31 for Pharo20

by stephane ducasse

>> > > Since the configuration of Seaside 3.1 is still unfinished: contact me if you would like to have this configuration, or SeasideRest and/or Magritte, as they depend on Seaside 3.1. > > The configurations of Grease and PetitParser are done and load properly. I included them here. Can I put them in the verified repository or does someone wants to check them and upload them here? > <ConfigurationOfGrease-DiegoLont.189.mcz><ConfigurationOfPetitParser-DiegoLont.30.mcz> We migrated the configurationOfPetitParser to its new home. So what is the difference? > > Cheers, > Diego >

March 22, 2013

Re: [Pharo-project] Where is the new Pharo 2.0 Inbox?

by Camillo Bruni

indeed confusing, the code behind works, but deserves some more love when handling errors and different types :P On 2013-03-22, at 21:27, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Yes, sure :-) > > 2013/3/22 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: >> When you add a repository, simply chose http then ;) >> >> Ben >> >> On Mar 22, 2013, at 9:00 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> >> wrote: >> >> Thx >> >> Again, same damn issue with adding repositories in MC: >> >> Added one in the list with Smalltalkhub and pasted the spec you provided. >> >> Net result: >> >> Stacktrace with MCSmalltalkhubRepository expected. >> >> Can't we get rid of those and stick to a MCHttpRepository? >> >> MCSmalltalkhubRepository >> owner: '' >> project: '' >> user: '' >> password: '' >> >> >> 2013/3/22 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >> On Mar 22, 2013, at 8:40 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> >> wrote: >> >> Looks like the one in the image isn't the right one. >> >> STH or something like that? >> >> Need it to check for closing my bugs in Fogbugz >> >> >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main' >> user: '' >> password: '' >> >> >> This is already in the 3.0 image as one of 3 repositories >> >> Marcus >> >> >> >> >

March 22, 2013

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

by stephane ducasse

Andrei we will introduce your debugger model in 3.0a. It is ok? Stef

March 22, 2013

Re: [Pharo-project] Where is the new Pharo 2.0 Inbox?

by phil＠highoctane.be

Yes, sure :-) 2013/3/22 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > When you add a repository, simply chose http then ;) > > Ben > > On Mar 22, 2013, at 9:00 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > > Thx > > Again, same damn issue with adding repositories in MC: > > Added one in the list with Smalltalkhub and pasted the spec you provided. > > Net result: > > Stacktrace with MCSmalltalkhubRepository expected. > > Can't we get rid of those and stick to a MCHttpRepository? > > MCSmalltalkhubRepository > owner: '' > project: '' > user: '' > password: '' > > > 2013/3/22 Marcus Denker <marcus.denker(a)inria.fr>: > > > On Mar 22, 2013, at 8:40 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > > Looks like the one in the image isn't the right one. > > STH or something like that? > > Need it to check for closing my bugs in Fogbugz > > > MCHttpRepository > location: 'http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main' > user: '' > password: '' > > > This is already in the 3.0 image as one of 3 repositories > > Marcus > > > >

March 22, 2013