- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Changes in MongoTalk

by Francois Stephany

> Next on my list: numberToSkip[1]. With "limit" and "numberToSkip", we > should be able to have something like pagination easily. Done. Once again, stop me if I'm doing stupid stuff :p Is there a dedicated place to talk about Mongo/Voyage? I feel like I'm polluting the pharo ML...

Sept. 24, 2012

Re: [Pharo-project] [update 2.0] #20301

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote >> Issue 6697: Zn+Zdc Update 2012-09-19 >> http://code.google.com/p/pharo/issues/detail?id=6697 > > Thanks! Thanks to Sven for all these improvements (per http://code.google.com/p/pharo/issues/detail?id=6697#c5) > These are the differences since the last time Zn was integrated (on the > main package): > > Zinc-HTTP-SvenVanCaekenberghe.304 (18 September 2012, 1:51:37 am) > Added option ZnServer class>>#alwaysRestart: to fine tune the > shutDown/startUp behavior, defaults to previous behavior > > Zinc-HTTP-SvenVanCaekenberghe.303 (18 September 2012, 10:03:40 am) > Refactored ZnNetworkingUtils>>#socketStreamToUrlDirectly: to honor/use the > correct timeout both when doing a DNS lookup as well as during connect by > using NetNameResolver directly as well as using > #openConnectionToHost:port:timeout > > Zinc-HTTP-SvenVanCaekenberghe.302 (17 September 2012, 4:08:37 am) > Added HTTPProgress signalling to ZnByteArrayEntity, ZnStringEntity as well > as ZnUtils class>>#readUpToEnd:limit: > Refactored streaming and HTTPProgress signalling in ZnUtils by addition of > ZnUtils class>>#[streamingBufferSize|signalProgress:total:] > > Zinc-HTTP-SvenVanCaekenberghe.301 (17 September 2012, 10:10:49 am) > Fixed a bug where HTTPProgress notifications would trigger a retry. > Thanks Camillo Bruni for finding this problem and suggesting a solution. > Now, retries are only triggered by (NetworkError, ZnParseError), while the > #ifFailBlock will be trigger on any Error. > Furthermore, #noteRetrying: and noteIgnoringExceptionOnReusedConnection: > will report on the actual exception. > The default #ifFailBlock is now [ :exception | exception pass ] for some > cleaner code. > > Zinc-HTTP-SvenVanCaekenberghe.300 (5 September 2012, 1:59:02 am) > removal of all classes in Zinc-HTTP-Deprecated > - ZnClientOld > - ZnFixedClient > - ZnExtendedFixedClient > - ZnUserAgent > - ZnHttpClient > - ZnUserAgentSettings > as well as all their unit test classes > > Zinc-HTTP-SvenVanCaekenberghe.299 (5 September 2012, 1:21:19 am) > changed maximumEntitySize concept from a normal class variable on > ZnConstants to a dynamic/process-specific variable ZnMaximumEntitySize; > added the option #maximumEntitySize to ZnServer > > Zinc-HTTP-SvenVanCaekenberghe.298 (5 September 2012, 11:24:50 am) > introduction of options in ZnServer; > refactored port, bindingAddress, delegate, authenticator and reader as > options > > Zinc-HTTP-SvenVanCaekenberghe.297 (27 August 2012, 9:41:58 am) > #includesSubString: becomes #includesSubstring: > > Zinc-HTTP-SvenVanCaekenberghe.296 (22 August 2012, 3:00:39 am) > added [ZnDefaultServerDelegate|ZnMonticelloServerDelegate]>>#value: > > Zinc-HTTP-SvenVanCaekenberghe.295 (22 August 2012, 11:15:01 am) > fixed type (wws should be wss); > patched ZnNetworkingUtils>>#socketStreamToUrlDirectly: to treat wss as > needing a #connect > > Zinc-HTTP-SvenVanCaekenberghe.294 (21 August 2012, 1:29:19 am) > extended ZnMultithreadedServer>>#executeRequestResponseLoopOn: with two > new features related to the response objects generated by delegates: > - the response object now also can answer whether or not it > #wantsConnectionClose > - after a response is written (flushed and logged), the response objects > gets a chance to continue using the connection in the current > thread/process for its own custom purposes through #useConnection: > > Zinc-HTTP-SvenVanCaekenberghe.293 (20 August 2012, 2:10:54 am) > changed ZnSingleThreadedServer>>#serveConnectionOn: to no longer fork a > worker thread/process as this is against the key idea of the class (this > in not really active code, so this cleanup in more theoretical) -- View this message in context: http://forum.world.st/update-2-0-20301-tp4648317p4648620.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 24, 2012

Re: [Pharo-project] headless CogVM on Windows

by Sean P. DeNigris

EstebanLM wrote > yeah... we need a real headless mode (no systry, nothing... just a deamon > running) Yes, from "Issue 72: Don't open an Dialog on Mac in headless mode" (http://code.google.com/p/cog/issues/detail?id=72) > This is even more important now with the MBP retina. A "headless" cog > image always forces the GPU to discrete mode, draining the battery. I > often use headless (e.g. for Jenkins jobs and web scrapers) and in > addition to the distraction of the unneeded window popping up, the switch > to the power hogging GPU for no reason is even more of a drag. -- View this message in context: http://forum.world.st/headless-CogVM-on-Windows-tp4648318p4648619.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Igor Stasenko

okay, i found what is wrong with first post (didn't read carefully). The instVarNames is a class-side protocol i.e. part of a class behavior, while instVarNamed: is an instance-side protocol i.e. "hackishly access to instance variable with given name" So, this is ok: Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups') And this is ok too: Nautilus instVarNamed: 'groups' worked because Nautilus is an instance of its metaclass. But this is wrong, since 'Nautilus class' is an instance of Metaclass, and metaclass doesn't have 'groups' variable. Nautilus class instVarNamed: 'groups' -> error -- Best regards, Igor Stasenko.

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Camillo Bruni

On 2012-09-23, at 23:33, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: > This is weird, I'm not seeing the problem at all! > > I've always thought of *#instVarNamed:* as a sibling method to > *#instVarAt:*(which maybe is more obviously an instance method). So > *anAddress instVarNamed: 'street'* would return a Street, just as *anAddress > instVarAt: 2* could. But anAddress, being just an instance, doesn't need to > know about its class definition directly, since it can always ask its class > if it needs to, so for example *anAddress class instVarNames* would return > the names of all the instance variables defined in the Address class. > > Now can someone please explain why that is confusing? I don't see the problem either :P...

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Peter Hugosson-Miller

This is weird, I'm not seeing the problem at all! I've always thought of *#instVarNamed:* as a sibling method to *#instVarAt:*(which maybe is more obviously an instance method). So *anAddress instVarNamed: 'street'* would return a Street, just as *anAddress instVarAt: 2* could. But anAddress, being just an instance, doesn't need to know about its class definition directly, since it can always ask its class if it needs to, so for example *anAddress class instVarNames* would return the names of all the instance variables defined in the Address class. Now can someone please explain why that is confusing? -- Cheers, Peter On Sun, Sep 23, 2012 at 10:59 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, Sep 23, 2012 at 6:55 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> since groups is an instance variable on the class side >> >> >> Nautilus class instVarNames >> -> #('maxSize' 'cachedLastClasses' 'groups') >> >> ok we get the instance variables >> >> so it was strange that the class could not find the instance variable >> using instVarNamed: >> >> Nautilus class instVarNamed: 'groups' >> -> error >> >> I was confused. >> >> > Looks strange to me as well. I would like that it actually works :) > > >> >> Stef >> >> >> On Sep 23, 2012, at 5:42 PM, Camillo Bruni wrote: >> >> > >> > On 2012-09-23, at 17:38, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >> wrote: >> > >> >> On a class, should answer the inst of the corresponding metaclass >> >> >> >> Like when you ask the inst var of an instance, you get the inst var of >> the corresponding class >> >> >> >> Ben >> > >> > but that works...., I don't get it :D >> > >> > >> > >> > Nautilus instVarNamed: #maxSize >> > Nautilus new instVarNamed: #announcer >> > >> > and: >> > >> > Nautilus class instVarNames includes: #maxSize. >> > Nautilus instVarNames includes: #announcer. >> > >> > >> > everything fine and symmetrical here... >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Mariano Martinez Peck

On Sun, Sep 23, 2012 at 6:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > since groups is an instance variable on the class side > > > Nautilus class instVarNames > -> #('maxSize' 'cachedLastClasses' 'groups') > > ok we get the instance variables > > so it was strange that the class could not find the instance variable > using instVarNamed: > > Nautilus class instVarNamed: 'groups' > -> error > > I was confused. > > Looks strange to me as well. I would like that it actually works :) > > Stef > > > On Sep 23, 2012, at 5:42 PM, Camillo Bruni wrote: > > > > > On 2012-09-23, at 17:38, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > wrote: > > > >> On a class, should answer the inst of the corresponding metaclass > >> > >> Like when you ask the inst var of an instance, you get the inst var of > the corresponding class > >> > >> Ben > > > > but that works...., I don't get it :D > > > > > > > > Nautilus instVarNamed: #maxSize > > Nautilus new instVarNamed: #announcer > > > > and: > > > > Nautilus class instVarNames includes: #maxSize. > > Nautilus instVarNames includes: #announcer. > > > > > > everything fine and symmetrical here... > > > -- Mariano http://marianopeck.wordpress.com

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by StÃ©phane Ducasse

since groups is an instance variable on the class side Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups') ok we get the instance variables so it was strange that the class could not find the instance variable using instVarNamed: Nautilus class instVarNamed: 'groups' -> error I was confused. Stef On Sep 23, 2012, at 5:42 PM, Camillo Bruni wrote: > > On 2012-09-23, at 17:38, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> On a class, should answer the inst of the corresponding metaclass >> >> Like when you ask the inst var of an instance, you get the inst var of the corresponding class >> >> Ben > > but that works...., I don't get it :D > > > > Nautilus instVarNamed: #maxSize > Nautilus new instVarNamed: #announcer > > and: > > Nautilus class instVarNames includes: #maxSize. > Nautilus instVarNames includes: #announcer. > > > everything fine and symmetrical here...

Sept. 23, 2012

Re: [Pharo-project] I found this highly relevant to Pharo :)

by Benjamin

" It's COBOL so we can say it's automatically ugly " Told ya ;) Ben On Sep 23, 2012, at 6:38 PM, Igor Stasenko wrote: > http://www.infoq.com/presentations/Ugly-Code > > -- > Best regards, > Igor Stasenko. >

Sept. 23, 2012

[Pharo-project] I found this highly relevant to Pharo :)

by Igor Stasenko

http://www.infoq.com/presentations/Ugly-Code -- Best regards, Igor Stasenko.

Sept. 23, 2012