January 2011 - Pharo-dev - lists.pharo.org

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

by Tudor Girba

I like the simple border around the windows. I adopted it in the Glamorous Theme :) Cheers, Doru On 13 Jan 2011, at 19:36, Igor Stasenko wrote: > here is updated version of it. > more consistent colors > (note the ">" button now not highlighted by default, > also added thin border for lists > and thin border for system windows, > and removed 1pixel-wide shadow for system window. > > > -- > Best regards, > Igor Stasenko AKA sig. > <GLMOrangeUITheme.st><GLMOrangeUITheme.png> -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

Jan. 13, 2011

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

by Levente Uzonyi

On Thu, 13 Jan 2011, mkobetic(a)gmail.com wrote: > Thanks everyone for your responses. I studied the ConnectionQueue that Wilhelm pointed me to, that didn't clarify things for me too much and I wasn't able to get it working either. Finally Sven's version of the script got me going again. I can already see the first problem in the Xtreams implementation in that it uses non-blocking read in Socket>>readInto:, simply changing it to the blocking read doesn't seem to fix things though. Quite the opposite. So now I'm trying to zero in on the exact API at the Socket level to use. To expand on the test script a bit more, this is what I'd like to get going: > > | input output listener process sync | > sync := Semaphore new. > listener := Socket newTCP. > listener listenOn: 9999 backlogSize: 10. > process := [ > [ input := listener waitForAcceptFor: 10. > sync signal > ] ensure: [ listener close ] > ] fork. > output := Socket newTCP. > output connectToHostNamed: 'localhost' port: 9999. > sync wait. > [ output sendData: 'Hello!'; close. > input receiveData. > ] ensure: [ output close. input close. process terminate ] It works fine in my Squeak image. Using localhost may be a problem if your local interface has an IPv6 address. Use 127.0.0.1 instead. Levente > > Maybe I need some other calls in the last block, but I'm stuck even earlier again. When I interrupt the script above, the debugger highlights the whole last block (the ensure: receiver) and there's just the top level UndefinedObject>>DoIt context. Doesn't make much sense to me but debuggers have bugs as well. I'm guessing the process is stuck on the sync wait before that. But the sync semaphore has excess signals 1. And what is even stranger is that input is still nil. How is that possible ? Can someone get the above going ? > > I realize that I deviated from Sven's version by moving the read out of the accept process, but that shouldn't be a problem, or am I missing something ? I'm also wondering if there is a Socket test suite somewhere that already contains tests like the above, that I could mine for examples. I don't see any in the PharoCore1.2 image. > > Thanks, > > Martin > > "Sven Van Caekenberghe"<sven(a)beta9.be> wrote: >> | data input output listener socket1 socket2 process sync | >> data := #uninitialized. >> sync := Semaphore new. >> listener := Socket newTCP. >> listener listenOn: 9999 backlogSize: 10. >> process := [ [ >> socket1 := listener waitForAcceptFor: 10. >> socket1 waitForDataFor: 10. >> output := socket1 reading. >> data := output rest. >> sync signal ] ensure: [ listener close ] ] fork. >> socket2 := Socket newTCP. >> socket2 connectToHostNamed: 'localhost' port: 9999. >> input := socket2 writing. >> input write: 'Hello!'. >> sync wait. >> data asString > >> >> Sven >> >> PS: Yes, Socket (and friends) have some pretty confusing API, you have to stick to what you know that works ;-) >> > > >

Jan. 13, 2011

Re: [Pharo-project] Issue 3522 in pharo: wiki like help contents

by pharo＠googlecode.com

Comment #3 on issue 3522 by Torsten....(a)astares.de: wiki like help contents http://code.google.com/p/pharo/issues/detail?id=3522 I'm waiting for feeback on the <wikiStyleHelp:syntax:> idea

Jan. 13, 2011

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

by Tudor Girba

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 On 13 Jan 2011, at 16:22, Douglas Brebner wrote: > On 13/01/2011 11:29, Tudor Girba wrote: >> I tried to start from zero and add a new variable (e.g., color) only when I could not distinguish something. There are still things that are superfluous (e.g., the border around all tabs, or the bulky shape of an expander), but I did not have enough time and Morphic expertise to do better. >> >> Now, orange vs blue is actually not just a matter of taste because your orange is not the same as my blue. There are two reasons: (1) it is stronger, and (2) it appears in more places (e.g., at the bottom of the scrollbar). This means that it will compete for my attention with more force. This might be your intention, but it is not mine because it takes away from my main focus which is the content. >> > > I admit that I do like the blue for selections. > However, I find that the blue gradient on the buttons is difficult to see clearly. > > I suspect this is because the chosen blue has high contrast against the white background of the list but *extremely* poor contrast with the grey button/frame background. If you look at the browser in greyscale, the difference stands out starkly (see the attached image). > > I also find all of the buttons without white borders seem to blend into the background so much as to become difficult to distinguish. > > Otherwise, I do like it :) > <Pharo-button-grey.jpg> -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

Jan. 13, 2011

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

by mkobetic＠gmail.com

Thanks everyone for your responses. I studied the ConnectionQueue that Wilhelm pointed me to, that didn't clarify things for me too much and I wasn't able to get it working either. Finally Sven's version of the script got me going again. I can already see the first problem in the Xtreams implementation in that it uses non-blocking read in Socket>>readInto:, simply changing it to the blocking read doesn't seem to fix things though. Quite the opposite. So now I'm trying to zero in on the exact API at the Socket level to use. To expand on the test script a bit more, this is what I'd like to get going: | input output listener process sync | sync := Semaphore new. listener := Socket newTCP. listener listenOn: 9999 backlogSize: 10. process := [ [ input := listener waitForAcceptFor: 10. sync signal ] ensure: [ listener close ] ] fork. output := Socket newTCP. output connectToHostNamed: 'localhost' port: 9999. sync wait. [ output sendData: 'Hello!'; close. input receiveData. ] ensure: [ output close. input close. process terminate ] Maybe I need some other calls in the last block, but I'm stuck even earlier again. When I interrupt the script above, the debugger highlights the whole last block (the ensure: receiver) and there's just the top level UndefinedObject>>DoIt context. Doesn't make much sense to me but debuggers have bugs as well. I'm guessing the process is stuck on the sync wait before that. But the sync semaphore has excess signals 1. And what is even stranger is that input is still nil. How is that possible ? Can someone get the above going ? I realize that I deviated from Sven's version by moving the read out of the accept process, but that shouldn't be a problem, or am I missing something ? I'm also wondering if there is a Socket test suite somewhere that already contains tests like the above, that I could mine for examples. I don't see any in the PharoCore1.2 image. Thanks, Martin "Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > | data input output listener socket1 socket2 process sync | > data := #uninitialized. > sync := Semaphore new. > listener := Socket newTCP. > listener listenOn: 9999 backlogSize: 10. > process := [ [ > socket1 := listener waitForAcceptFor: 10. > socket1 waitForDataFor: 10. > output := socket1 reading. > data := output rest. > sync signal ] ensure: [ listener close ] ] fork. > socket2 := Socket newTCP. > socket2 connectToHostNamed: 'localhost' port: 9999. > input := socket2 writing. > input write: 'Hello!'. > sync wait. > data asString > > Sven > > PS: Yes, Socket (and friends) have some pretty confusing API, you have to stick to what you know that works ;-) >

Jan. 13, 2011

Re: [Pharo-project] Issue 3522 in pharo: wiki like help contents

by pharo＠googlecode.com

Comment #2 on issue 3522 by stephane.ducasse: wiki like help contents http://code.google.com/p/pharo/issues/detail?id=3522 If you have some cycles I would like to integrate a version in 1.2 because having a good help is important.

Jan. 13, 2011

[Pharo-project] PharoConf Annecy 2011

by laurent laffont

Hi, PharoConf Annecy will took place at IMUS (UniversitÃ© of Savoie), 10th February. Website here: http://pharoconf-annecy.seasidehosting.st/ (in french, but google translate starts to be wonderful :) It's a local event focused on real code, coding-dojo, katas using Pharo. If you're not far from Annecy, welcome ! Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

Jan. 13, 2011

Re: [Pharo-project] about GLMOrangeUITheme [WAS] Re: [update 1.2] #12302

by Alain Plantec

Hi all, yes, I agree list selection and selection colors (and some others) can be changed from the setting browser. I think that in the core only the default theme should be present. The others should be packaged separately and loadable on-demand or when a package is loaded as it is for moose/glamour. Cheers Alain Le 13/01/2011 21:27, Mariano Martinez Peck a Ã©crit : > > > On Thu, Jan 13, 2011 at 9:15 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > 12302 > ----- > > - GLMOrangeUITheme. Thanks Igor Stasenko > > > I don't agree with this kind of changes. > Tomorrow I want Watery2BlackTheme and GLMYellowUITHeme and what? we > are going to integrate it also? > > I don't understand. The change should be to create a setting to set > the color and then igor runs a script in his own image that set it to > orange. Me to yellow. And you to pink. > > > - Issue 3538: Add a "Browse test" in the TestRunner failed/error > list. Thanks Benjamin van Ryseghem > > Stef > >

Jan. 13, 2011

Re: [Pharo-project] Issue 3224 in pharo: Migrating MethodReference to MethodReferenceWithSource

by pharo＠googlecode.com

Updates: Status: Closed Comment #18 on issue 3224 by stephane.ducasse: Migrating MethodReference to MethodReferenceWithSource http://code.google.com/p/pharo/issues/detail?id=3224 finalllllly in 12303

Jan. 13, 2011

[Pharo-project] about GLMOrangeUITheme [WAS] Re: [update 1.2] #12302

by Mariano Martinez Peck

On Thu, Jan 13, 2011 at 9:15 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 12302 > ----- > > - GLMOrangeUITheme. Thanks Igor Stasenko > I don't agree with this kind of changes. Tomorrow I want Watery2BlackTheme and GLMYellowUITHeme and what? we are going to integrate it also? I don't understand. The change should be to create a setting to set the color and then igor runs a script in his own image that set it to orange. Me to yellow. And you to pink. > > - Issue 3538: Add a "Browse test" in the TestRunner failed/error list. > Thanks Benjamin van Ryseghem > > Stef >

Jan. 13, 2011