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

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

by Igor Stasenko

On 13 January 2011 21:57, Alain Plantec <alain.plantec(a)free.fr> wrote: > 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. +1 i think we should get rid of all themes and leave only single default one. Actually today i was attempting to make sure that orange could be turned into any other color of choice by picking a different color in settings. Unfortunately its not so easy, because some widget do not honor / using theme settings correctly. And theme by itself not always honors the settings. As a wish for future, i think we should fold all UI settings under a per-theme settings, so when user selects a concrete UI theme, then theme could control, which UI Settings it makes public and this allows to be modified, and which are not, and should always use built-in (like window color or icons). Then theme could control whether it supports changing particular setting or not. For instance i could use single color (orange) to define colors for multiple things: - Menu selection color - Find replace selection color ... others and to user show only 'Selection color' > Cheers > Alain > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2011

Re: [Pharo-project] Hudson -> Jenkins

by Igor Stasenko

On 14 January 2011 00:11, Torsten Bergmann <astares(a)gmx.de> wrote: > FYI: > http://www.theregister.co.uk/2011/01/11/hudson_renamed_jenkins/ it is strange, why they (Oracle) simply do not give it away... why bullying nice people who doing things for free, and will continue doing it anyways? > -- > NEU: FreePhone - kostenlos mobil telefonieren und surfen! > Jetzt informieren: http://www.gmx.net/de/go/freephone > > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2011

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

by pharo＠googlecode.com

Comment #6 on issue 3522 by aplantec: wiki like help contents http://code.google.com/p/pharo/issues/detail?id=3522 Take my WikiStyleHelpBuilder (.st attached). The only change concerns the section start char which is $! instead of $= in your .cs Attachments: WikiStyleHelpBuilder.st 3.5 KB

Jan. 13, 2011

[Pharo-project] Hudson -> Jenkins

by Torsten Bergmann

FYI: http://www.theregister.co.uk/2011/01/11/hudson_renamed_jenkins/ -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

Jan. 13, 2011

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

by pharo＠googlecode.com

Comment #5 on issue 3522 by Torsten....(a)astares.de: wiki like help contents http://code.google.com/p/pharo/issues/detail?id=3522 So we take this changeset (which is the same as from my post on http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/039166.ht…) and start from it to extend it with the "double pragma". Attachments: WikiStyleHelp.5.cs 3.7 KB

Jan. 13, 2011

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

by Igor Stasenko

On 13 January 2011 23:09, Tudor Girba <tudor.girba(a)gmail.com> wrote: > I like the simple border around the windows. I adopted it in the Glamorous Theme :) > btw, i suggest you to fix all the places to use theme settings instead of direct colors, so your theme settings could be changed from Settings UI For example: glamorousBaseSelectionColorFor: aButton ^ settings selectionColor instead of: glamorousBaseSelectionColorFor: aButton ^ self class baseSelectionColor and by changing 'Selection color' in settings, i can change Orange->Blue :) Btw, there is a bug in Polymorph, it ignores the 'Find replace selection color' setting There is one widget which doesn't honors the text selection color - find and replace dialog. Btw, it would be cool to make theme consistent with all colors, used by settings (filter by *color*) > Cheers, > Doru > > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2011

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

by Sven Van Caekenberghe

On 13 Jan 2011, at 22:56, mkobetic(a)gmail.com wrote: > Can someone get the above going ? Yes, the following works as expected for me (Pharo 1.1.1 + latest Xtreams + Cog based VM): | input output listener process sync data | data := #uninitialized. 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. data := input receiveData. ] ensure: [ output close. input close. process terminate ]. data. > 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. I have encountered strange things when using sockets from different processes, that is why I moved the code in the block. But it should work, and now it does ;-) Sven

Jan. 13, 2011

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

by mkobetic＠gmail.com

"Levente Uzonyi"<leves(a)elte.hu> wrote: > 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. Odd. The image I was using must have been corrupt somehow. When I took fresh Pharo 1.2 image the script worked fine. Thanks for the confirmation! Martin

Jan. 13, 2011

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

by pharo＠googlecode.com

Comment #4 on issue 3522 by aplantec: wiki like help contents http://code.google.com/p/pharo/issues/detail?id=3522 Sorry Torsten...I'm doing too much things in parallel Your proposition to have <wikiStyleHelp:syntax:> and <wikiStyleHelp:> as default for pier syntax is ok for me. And its cool because my setting browser comments are ready for this :)

Jan. 13, 2011

Re: [Pharo-project] [squeak-dev] Xtreams up to date

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > Thank you for all this work, this is a really interesting project, I am glad you are putting in the effort to bring this to Pharo/Squeak. Thanks. It's Nicolas who deserves the praise. I'm just trying to help out. > ... > I tried to look at one of the others XTFileReadingWritingTest>>#testWriteFromCollectionAt > > | data | > data := #[1 2 3 4 5 6 7]. > self assert: (self output write: 4 from: data at: 1) = 4. > self assert: (self input read: 4) = (data first: 4). > self assert: (self output write: 3 from: data at: 5) = 3. > self assert: (self input read: 3) = (data last: 3) > > The failure is at the last assertion. If I understand the code correctly, you write to a file in 2 steps (and yes the file contains the data). The input stream is created lazily, after the first write. But it seems strange to me to expect an open reading file stream to see newly written data ? Closing/reopening input works as expected. So you are also testing a particular OS feature here IMHO. Maybe this works on some OS's but it does not seem to work for me (Mac OS X, Cog VM), but other elements might be involved (caching/buffering at various levels, vm, primitives, ..). The intent of the test certainly is that the data would be visible. It's the same generic test we run across all the terminals. I can't give any authoritative statement whether it should work with files everywhere or not, but I can say that it does work across Linux, Windows and OSX in VW. I think the key aspect of this tests is that it's the same process doing the reading and writing. Actually maybe it's even that it must be the same descriptor. I'll have to take a closer look to see what's going on, but it seems to pass for me with Pharo (1.1.1 or 1.2, cog or standard VM) on Linux. I can test it on Windows as well, but I don't have OSX available for this. Does anyone know if it is reasonable to expect it to work on OSX ? I'm certainly not bent on keeping the test that way, our primary goal is to test the API on all terminals. But if it is meant to work this way even on files, then we probably should keep it that way.

Jan. 13, 2011