- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [SPAM] Congrats

by Sven Van Caekenberghe

On 14 Jan 2011, at 17:17, Miguel CobÃ¡ wrote: > 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 FÃ©licitations, StÃ©phane! Sven

Jan. 14, 2011

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

by Schwab,Wilhelm K

Sven, Thanks for the code! The fact that I have to decide what constitutes an "infinite" delay seems wrong to me. It should just do what I tell it and either calmly wait for an event to let the code move forward (assuming that only the calling thread is blocked). One example: if I know I typed an incorrect address, then any time is wasted. If it's correct and the connection is slow (I downloaded a pdf of a paper earlier this week, and it was miserably slow but worked fine), I probably want the code to keep running without trying to think for itself. "This looping improves liveliness and responsiveness to other events." Why does looping on things that should be blocking until events arrive improve response to other events? This seems like a bailing wire solution to the problem. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Friday, January 14, 2011 9:36 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket question (Was Re: Xtreams up to date) On 14 Jan 2011, at 12:54, Schwab,Wilhelm K wrote: 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] Congrats

by Steven Baker

I can't find an english translation. Can someone summarize this in english for me? Thanks, -Steven On Fri, Jan 14, 2011 at 8:17 AM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > 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] Socket question (Was Re: Xtreams up to date)

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > 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. Given that accept is generally done on the server side, usually in a background process, I have to say I'd be inclined to side with Wilhelm on this one. I don't see much that the server can do than go back into another accept loop. You can't predict how long will it take for the next client to connect, so a timeout isn't a sign of an issue. So I don't see much use for timeout on accept. I'm not quite sure what you mean by "improving liveliness". If the implementation needs to get out of accept to let other processes respond to events, then I wouldn't call that a feature. But these are really more philosophical points. In practice, wrapping a loop around an accept timeout isn't a big deal either, as long as it works as needed.

Jan. 14, 2011

Re: [Pharo-project] How to bundle an application with icons?

by Hilaire Fernandes

Le 14/01/2011 15:03, Dimitry Golubovsky a Ã©crit : > Hi, > > Fernando Olivero wrote: > >> Hi Dimitry , i've did an external icon family importer and manager. > >> It's in squeaksource, under the name of ExternalIconFamily. > >> Gofer it >> squeaksource: 'ExternalIconFamily'; >> package: 'ExternalIconFamily'; >> load. > >> This framework allows importing and managing any external icon family. >> Once imported , the icon family is reified into the image, as a >> subclass of ExternalIconFamily. >> As an example it comes with a tiny subset of the Oxygen icon family imported. > > [skip] > > Thanks a lot. I am currently working on other aspects of the > application, but this icon importer will be a great customization > tool. I'll definitely give it a try. > You may want to take a look at DrGeo, in the DrGIcons class for icons import and handling. Hilaire

Jan. 14, 2011

Re: [Pharo-project] Congrats

by Hilaire Fernandes

Waou! Go go Steph! Le 14/01/2011 17:17, Miguel CobÃ¡ a Ã©crit : > Congrats StÃ©ph, > > http://www.inria.fr/centre-de-recherche-inria/lille-nord-europe/actualites/… > > Cheers

Jan. 14, 2011

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

by Gary Chambers

Example: UITheme currentSettings windowColor: Color orange. World themeChanged. UITheme current class defaultSettings windowColor: Color lightBlue. World themeChanged. " no change" UITheme currentSettings windowColor: Color yellow. World themeChanged. UITheme current class beCurrent "uses default of light blue" Switching between themes uses the theme defaults rather than any modifications to the current theme. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, January 14, 2011 5:40 PM Subject: Re: [Pharo-project] [update 1.2] #12297 > Well, i imagine that different themes can have a different set of > editable settings available, > and from that perspective the ThemeSettings is limiting, since > it contains a list of 'standard' properties, no more no less. > > So, i proposing to rewrite all uses of: > > UITheme currentSettings foo > > with: > > UITheme current foo > > and let theme decide how to answer the requested value. > > For example, one could do: > > MyTheme>>fooColor > ^ Color red "non-editable, hardcoded value" > > while another one could decide to use color from settings: > > MyCoolTheme>>fooColor > ^ settings at: #fooColor default: Color red > > And also each theme could tell settings browser, which public > properties it having, > so, depending on currently installed theme, user could see and change > only those, which related to it. > > Then settings could be a simple dict, where keys is symbols and values > is property values. > and then, when you changing the current theme , it should simply do: > > newTheme settings: oldTheme settings > > so, nothing will be lost, even if new theme does not using some > properties, and when user will switching back to > old theme, it will continue using settings which already registered by/for > it. > > On 14 January 2011 18:05, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> 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. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 14, 2011

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

by Gary Chambers

Well, currentSettings is a delegation to the current theme settings... Is equivalent to UITheme current settings. Settings are abstracted out to declutter the theme. The point I was making is that there are settings on the current theme (volatile) and default settings per theme. I take your point, for ease of overriding, but the settings (as called) ware abstracted out since UITheme is already quite a large facade... I don't agree with settings being a dictionary, too many things are already inexplicit! Some kind of meta-description is appropriate though, for use in the Settings browser. Is that not the case already? Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, January 14, 2011 5:40 PM Subject: Re: [Pharo-project] [update 1.2] #12297 > Well, i imagine that different themes can have a different set of > editable settings available, > and from that perspective the ThemeSettings is limiting, since > it contains a list of 'standard' properties, no more no less. > > So, i proposing to rewrite all uses of: > > UITheme currentSettings foo > > with: > > UITheme current foo > > and let theme decide how to answer the requested value. > > For example, one could do: > > MyTheme>>fooColor > ^ Color red "non-editable, hardcoded value" > > while another one could decide to use color from settings: > > MyCoolTheme>>fooColor > ^ settings at: #fooColor default: Color red > > And also each theme could tell settings browser, which public > properties it having, > so, depending on currently installed theme, user could see and change > only those, which related to it. > > Then settings could be a simple dict, where keys is symbols and values > is property values. > and then, when you changing the current theme , it should simply do: > > newTheme settings: oldTheme settings > > so, nothing will be lost, even if new theme does not using some > properties, and when user will switching back to > old theme, it will continue using settings which already registered by/for > it. > > On 14 January 2011 18:05, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> 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. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 14, 2011

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

by Igor Stasenko

Well, i imagine that different themes can have a different set of editable settings available, and from that perspective the ThemeSettings is limiting, since it contains a list of 'standard' properties, no more no less. So, i proposing to rewrite all uses of: UITheme currentSettings foo with: UITheme current foo and let theme decide how to answer the requested value. For example, one could do: MyTheme>>fooColor ^ Color red "non-editable, hardcoded value" while another one could decide to use color from settings: MyCoolTheme>>fooColor ^ settings at: #fooColor default: Color red And also each theme could tell settings browser, which public properties it having, so, depending on currently installed theme, user could see and change only those, which related to it. Then settings could be a simple dict, where keys is symbols and values is property values. and then, when you changing the current theme , it should simply do: newTheme settings: oldTheme settings so, nothing will be lost, even if new theme does not using some properties, and when user will switching back to old theme, it will continue using settings which already registered by/for it. On 14 January 2011 18:05, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > 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. >> > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 14, 2011

[Pharo-project] Pharo issues on Google

by Gary Chambers

Is the Pharo issues google site not working? Regards, Gary

Jan. 14, 2011