September 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Bad behaviour at startup

by Denis Kudriashov

Ok, I will look at mails. In short: Start new seaside image. Add new zinc adaptor on port 10025 (for example). Save and close image. Block this port by firewall. Start image. It should close immediately. I have pharoDebug with THERE_BE_DRAGONS_HERE Error: Cannot create socket on port 10025 24 September 2012 12:18:00.807 pm VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 8eb3f452262d1b213fd1b6fd3cb682e292945ccf Date: Mon Jul 9 15:23:19 2012 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Image: Pharo1.4 [Latest update: #14456] 2012/9/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Check the mailing-list because this was already discussed. > igor and other spent time to streamline this process in particular in > headless mode. > > So can you tell us a bit more what you are doing and when? > > Stef > > > > Hello. > > > > I found very bad behaviour. > > I use Pharo1.4. > > And when there is some errors at startup Image just closed. It is > horrible > > > > I have image with seaside application which open socket at startup. > > So when I move to another computer where this port is busy (or closed by > firewall) Pharo opened and immediately closed. No chance to debug and fix > it. > > > > What you think about it? Is it fixed already at pharo 2.0? > > > > Best regards > > Denis > > > > > > >

Sept. 24, 2012

[Pharo-project] Default max heap size on OS-X

by Stephan Eggermont

Hi I noticed the default SqueakMaxHeapSize on CI for Mac is 536870912 bytes. Is there a specific reason for the default to be so low? I know there used to be problems with the windows vm. Stephan

Sept. 24, 2012

Re: [Pharo-project] Bad behaviour at startup

by StÃ©phane Ducasse

Check the mailing-list because this was already discussed. igor and other spent time to streamline this process in particular in headless mode. So can you tell us a bit more what you are doing and when? Stef > Hello. > > I found very bad behaviour. > I use Pharo1.4. > And when there is some errors at startup Image just closed. It is horrible > > I have image with seaside application which open socket at startup. > So when I move to another computer where this port is busy (or closed by firewall) Pharo opened and immediately closed. No chance to debug and fix it. > > What you think about it? Is it fixed already at pharo 2.0? > > Best regards > Denis > >

Sept. 24, 2012

[Pharo-project] Bad behaviour at startup

by Denis Kudriashov

Hello. I found very bad behaviour. I use Pharo1.4. And when there is some errors at startup Image just closed. It is horrible I have image with seaside application which open socket at startup. So when I move to another computer where this port is busy (or closed by firewall) Pharo opened and immediately closed. No chance to debug and fix it. What you think about it? Is it fixed already at pharo 2.0? Best regards Denis

Sept. 24, 2012

Re: [Pharo-project] Changes in MongoTalk

by StÃ©phane Ducasse

if the volume gets annoying we will tell you. for now talk here :) On Sep 24, 2012, at 8:17 AM, Francois Stephany wrote: > >> 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] instVarNames vs instVarNamed:

by StÃ©phane Ducasse

On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote: > 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" Yes this is exactly my point. I think that there is a protocol missing for class to be consistent. > 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. 24, 2012

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