- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.2] #12297

by Gary Chambers

Just FYI... On the class side of UITheme there is the defaultSettings... used when changing themes to initialise the new theme. Handy for having settings that survive theme changes. For those of you wanting to retain certain colour changes, this is the thing to edit. Should survive updates etc. Would be nice to have Settings support for both the current and defaults though ;-) Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, January 14, 2011 12:00 PM Subject: Re: [Pharo-project] [update 1.2] #12297 > On 14 January 2011 12:33, Douglas Brebner <squeaklists(a)fang.demon.co.uk> > wrote: >> On 13/01/2011 22:04, Tudor Girba wrote: >>> >>> That is a good point. I actually used the Sim Daltonism application (for >>> Mac) to check the color blindness issues, but it looks like I overlooked >>> Monochromacy (however, this is pretty rare). I will try to look into >>> that. >>> >>> Cheers, >>> Doru >> >> It's not just the colour blind that are affected (though they have it >> worst). Even people with perfect vision can find it difficult to >> distinguish >> adjacent areas of similar contrast. >> >> e.g. If you look at the save changes window that appears when quitting an >> image you'll notice the buttons almost disappear into the background. >> >> Still, it's good that someone is working on this :) >> > > yeah.. if you not cleaning your house, do not expect guests to come :) > >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 14, 2011

[Pharo-project] Congrats

by Miguel CobÃ¡

Congrats StÃ©ph, http://www.inria.fr/centre-de-recherche-inria/lille-nord-europe/actualites/… Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 14, 2011

Re: [Pharo-project] Issue 3486 in pharo: PluggableTextMorph should be able to support text styling

by pharo＠googlecode.com

Updates: Status: Closed Comment #17 on issue 3486 by stephane...(a)gmail.com: PluggableTextMorph should be able to support text styling http://code.google.com/p/pharo/issues/detail?id=3486 in 12306

Jan. 14, 2011

Re: [Pharo-project] Issue 3417 in pharo: BehaviorTest>>#testAllLocalCallsOn fails

by pharo＠googlecode.com

Comment #4 on issue 3417 by stephane...(a)gmail.com: BehaviorTest>>#testAllLocalCallsOn fails http://code.google.com/p/pharo/issues/detail?id=3417 in 12305

Jan. 14, 2011

[Pharo-project] [update 1.2] #12305

by StÃ©phane Ducasse

12305 ----- - GLMOrangeUITheme beCurrent. - Issue 3417: BehaviorTest>>#testAllLocalCallsOn fails. Stef

Jan. 14, 2011

Re: [Pharo-project] Issue 3417 in pharo: BehaviorTest>>#testAllLocalCallsOn fails

by pharo＠googlecode.com

Updates: Status: closed Comment #3 on issue 3417 by stephane...(a)gmail.com: BehaviorTest>>#testAllLocalCallsOn fails http://code.google.com/p/pharo/issues/detail?id=3417 A possible solution would be hash ^ super hash bitXor: self sourcePointer hash

Jan. 14, 2011

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

by Sven Van Caekenberghe

On 14 Jan 2011, at 12:54, Schwab,Wilhelm K wrote: > I am really bothered by the timeout on the accept, so much so that I think it has no place in the tests. Of course, one needs a way to clean up after a failure, but that should be done by another thread that waits for a "long" time and then cleans up anything that is left behind after the failure. > > Servers should be started and stopped and in between, they should wait for and accept connections. Clients should try to connect until told otherwise; timeouts can be reasonable options there, but should not be forced by the sockets system. Only the calling threads should be blocked, of course. I don't understand why this would bother you: it is the 'client/user' that decides about the timeout (you could use some very large number for an 'infinite' timeout). You need of course a loop around it. Here is the code from ZnSingleThreadedServer (which started from the Blackfoot example): listenLoop "We create a listening Socket, then wait for a connection. After each connection we also check that the listening Socket is still valid - if not we just make a recursive call to this method to start over." self initializeServerSocket. [ [ serverSocket isValid ifFalse: [ "will trigger #ifCurtailed: block and destroy socket" ^ self listenLoop ]. self serveConnectionOn: serverSocket ] repeat ] ifCurtailed: [ self releaseServerSocket ] serveConnectionOn: listeningSocket "We wait up to acceptWaitTimeout seconds for an incoming connection. If we get one we wrap it in a SocketStream and #executeOneRequestResponseOn: on it" | stream socket | socket := (listeningSocket waitForAcceptFor: self acceptWaitTimeout) ifNil: [ ^ self log: 'Wait for accept timed out' ]. stream := ZnNetworkingUtils socketStreamOn: socket. [ [ [ self executeOneRequestResponseOn: stream ] ensure: [ self log: 'Closing stream'. stream close ] ] ifCurtailed: [ self log: 'Destroying socket'. socket destroy ] ] forkAt: Processor highIOPriority named: 'Zinc HTTP Server Worker' Each #acceptWaitTimeout seconds, 'Wait for accept timed out' is printed on the log and another accept/wait starts. This looping improves liveliness and responsiveness to other events. Sven

Jan. 14, 2011

Re: [Pharo-project] Issue 2818 in pharo: Eliot and friends compiler fixes

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.2 Milestone-1.3 Comment #6 on issue 2818 by stephane...(a)gmail.com: Eliot and friends compiler fixes http://code.google.com/p/pharo/issues/detail?id=2818 (No comment was entered for this change.)

Jan. 14, 2011

Re: [Pharo-project] linux equivalent to monticello metacello...

by Esteban Lorenzano

wel... I made the "Gofer Project Loader" (http://smallworks.com.ar/en/community/GoferProjectLoader) to handle metacello configurations as apt-get. It's working, needs to add some fixes Adrian ask me like six months ago and I forget to do it... but there was "configurations for diferent pharo versions", very easy. Is there are still some interest, I can update it :P best, Esteban El 14/01/2011, a las 11:08a.m., laurent laffont escribiÃ³: > On Fri, Jan 14, 2011 at 2:43 PM, Geoffroy Couprie <geo.couprie(a)gmail.com> wrote: > On Fri, Jan 14, 2011 at 2:00 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > > > > > for the chapter on metacello I would like to have a table showing the equivalent between > > linux tools (if this is true) > > > > apt-get... and monticello/metacello > > > > can somebody point me to that ? > > > > I would say that the mapping is: > Monticello <-> dpkg (without the repository management) > Metacello <-> apt > > > Note that it's Debian / Ubuntu / .. equivalent. Because: > On ArchLinux / Chakra / ... > Monticello <-> pkg > Metacello <-> pacman > > On RedHat / CentOS / .... > Monticello <-> rpm > Metacello <-> yum > > and there's more :) > > Laurent

Jan. 14, 2011

Re: [Pharo-project] linux equivalent to monticello metacello...

by laurent laffont

On Fri, Jan 14, 2011 at 2:43 PM, Geoffroy Couprie <geo.couprie(a)gmail.com>wrote: > On Fri, Jan 14, 2011 at 2:00 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > > > > > for the chapter on metacello I would like to have a table showing the > equivalent between > > linux tools (if this is true) > > > > apt-get... and monticello/metacello > > > > can somebody point me to that ? > > > > I would say that the mapping is: > Monticello <-> dpkg (without the repository management) > Metacello <-> apt > > Note that it's Debian / Ubuntu / .. equivalent. Because: On ArchLinux / Chakra / ... Monticello <-> pkg Metacello <-> pacman On RedHat / CentOS / .... Monticello <-> rpm Metacello <-> yum and there's more :) Laurent

Jan. 14, 2011