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

Re: [Pharo-project] custom ui theme

by Gary Chambers

You could try sending #resetDefaultSettings to your new theme class, maybe something odd happened. The defaults are stored in a class instance variable so each theme can retain a, potentially user customised, set of settings that will survive selection between alternate themes. Had a go doing a subclass myself but encountered no apparent problem here. Regards, and good luck, Gary On Thu, 2010-01-14 at 21:51 +0100, Tudor Girba wrote: > Hi, > > I did not override this method: MyTheme class>>newDefaultSettings > > But, adding the code you mention does not seem to have an effect. > > Still confused :). > > Cheers, > Doru > > > On 14 Jan 2010, at 17:44, Stan Shepherd wrote: > > > > > > > Tudor Girba wrote: > >> > >> Hi, > >> > >> I am trying to tweak a bit the way the splitters are drawn in the > >> watery2 theme. So, I created a subclass of UIThemeWatery2 uitheme, > >> and > >> I just overrode resizer* and splitter* methods. > >> > >> However, when I make MyTheme beCurrent, the windows get painted in > >> Squeakish colors (blue, green) instead of gray. > >> > >> I am probably missing something, but I do not know what. What > >> should I > >> do to get the gray back? > >> > >> Cheers, > >> Doru > >> > >> > > > > Hi Doru, you might try in > > > > MyTheme class>>newDefaultSettings > > ^super newDefaultSettings standardColorsOnly: true > > > > Seems like you could have overridden an override > > > > Good luck, ...Stan > > > > -- > > View this message in context: http://n2.nabble.com/custom-ui-theme-tp4391907p4393746.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 15, 2010

[Pharo-project] [BUG][FIX][FIX], was: (Re: [squeak-dev] Re: Flaw in SocketStream>>peek detected)

by Igor Stasenko

My first attempt to fix it was also flawed. Thanks to Stephan for pointing it out. (You can read our discussion here: http://code.google.com/p/pharo/issues/detail?id=1813) I hope this time its fixing it! :) -- Best regards, Igor Stasenko AKA sig.

Jan. 15, 2010

Re: [Pharo-project] [squeak-dev] Re: SocketStream>>atEnd

by GÃ¶ran Krampe

Igor Stasenko wrote: > It appears that im wrong. sorry for disturbing :) ...but thanks for digging in the SocketStream code! It was quite a while since I wrote it :) While we are at it we should improve the primitive for searching in String/ByteArrays to include at stopAt: argument. This would increase speed and simplify the horribly tricky logic in the upTo: family of methods in SocketStream. The reason for the trickiness is the fact that the search primitive always searches to the very end of the buffer (there is no stopAt: parameter) AND the buffer can of course include old data after the current end marker in which we may find "false hits". I remember the pain in writing that code... regards, GÃ¶ran

Jan. 15, 2010

Re: [Pharo-project] SocketStream>>atEnd

by Igor Stasenko

It appears that im wrong. sorry for disturbing :) 2010/1/15 Igor Stasenko <siguctua(a)gmail.com>: > Hello guys, > > today, by examining closely the #atEnd implementation , i came to > conclision that is can be made as simple as: > > atEnd > Â ^ self isDataAvailable not > > > Because, take a close look at old implementation: > atEnd > Â Â Â Â self isInBufferEmpty ifFalse: [^false]. Â ----***--- > Â Â Â Â ^self isConnected not > Â Â Â Â Â Â Â Â and: [self isDataAvailable not] > > and: > isDataAvailable > > Â Â Â Â self isInBufferEmpty ifFalse: [^true]. Â ---***--- > Â Â Â Â ^socket dataAvailable > Â Â Â Â Â Â Â Â ifFalse: [false] > Â Â Â Â Â Â Â Â ifTrue: [self receiveDataIfAvailable; isDataAvailable] > > > a Socket>>dataAvailable answers false on closed or invalid socket. You > can check it quite simply: > > (SocketStream openConnectionToHostNamed: Â 'google.com' port: 80) > socket closeAndDestroy dataAvailable > (SocketStream openConnectionToHostNamed: Â 'google.com' port: 80) close > socket dataAvailable > Socket new dataAvailable > => all 3 answer false > > Therefore, a complex logic in #atEnd, could be simplified. > > Please, try to find a flaw in my conclusions. I think there's not. But > 2 (or more) heads always better than 1. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Jan. 14, 2010

[Pharo-project] SocketStream>>atEnd

by Igor Stasenko

Hello guys, today, by examining closely the #atEnd implementation , i came to conclision that is can be made as simple as: atEnd ^ self isDataAvailable not Because, take a close look at old implementation: atEnd self isInBufferEmpty ifFalse: [^false]. ----***--- ^self isConnected not and: [self isDataAvailable not] and: isDataAvailable self isInBufferEmpty ifFalse: [^true]. ---***--- ^socket dataAvailable ifFalse: [false] ifTrue: [self receiveDataIfAvailable; isDataAvailable] a Socket>>dataAvailable answers false on closed or invalid socket. You can check it quite simply: (SocketStream openConnectionToHostNamed: 'google.com' port: 80) socket closeAndDestroy dataAvailable (SocketStream openConnectionToHostNamed: 'google.com' port: 80) close socket dataAvailable Socket new dataAvailable => all 3 answer false Therefore, a complex logic in #atEnd, could be simplified. Please, try to find a flaw in my conclusions. I think there's not. But 2 (or more) heads always better than 1. -- Best regards, Igor Stasenko AKA sig.

Jan. 14, 2010

[Pharo-project] [update 1.1] #11159

by StÃ©phane Ducasse

11159 ----- - Issue 1743: move temps into inner scope so long that we will have to provide an image ... Stef

Jan. 14, 2010

[Pharo-project] Putting Algernon and WorkingSet in a Dev image

by Mariano Martinez Peck

I think both are really great tools and if people don't use them is mostly because they don't know that even they exist or how they work. What do you think about loading both tools in PharoDev? they are little tools and easy to install. Maybe we can give them a try during "one" PharoDev and if they don't like, they can just be don't included any more. Do you want to try them first ? For WorkginSet: read this mail: http://n2.nabble.com/ANN-WorkingSet-td4286093.html#a4286093 For Alegernon evaluate: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAlgernon'; load. ((Smalltalk at: #ConfigurationOfAlgernon) project version: '0.9.1') load. (Smalltalk at: #Algernon) openWelcomeWorkspace For the lazy ones, this is what that workspace says: "Algernon is a productivity tool for Pharo programmers; your personal assistant for Pharo. Algernon aims to make programming in Pharo faster and more keyboard centric. It is a launcher and quick way to access any category, class, morph, or global variable in your image. Pressing shift-return anywhere brings up Algernon. Start typing a class name, a morph's name, a category, an object, global variable and a list of items is filtered as you type. Press return to perform the default action on that item, or press tab to see a list of possible actions. Algernon can also evaluate Smalltalk expressions. Simply bring up Algernon and type = to enter expression mode to have quick access or print the results. Usage: Press shift-return to bring up Algernon. Start typing a name, then press return to perform the default action on the item, or hit tab to see a list of possible actions, included, for example, open that class in a new browser. Press right arrow to drill into a class or category and see its methods or classes, respectively. Press ctrl-r to refresh if you add new items that need to be indexed." What do you think ? Mariano ps: +1 for me :)

Jan. 14, 2010

Re: [Pharo-project] Time for a new election in squeak.org soon

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > Now in europe we have even problem to recruit male CS and the number of students in applied maths/maths > which is normally more than CS is decreasing too. May be they all want to be managers. > sorry, I can't resist (see attached picture) Alain > Stef > > >

Jan. 14, 2010

[Pharo-project] [update 1.1] #11158

by StÃ©phane Ducasse

11158 ----- - Issue 478: [Pending Etoy Cleaning] Object>>defaultNameStemForInstances - Issue 479: [Etoy Pending Cleaning] Object>> externalName - Issue 491: [Pending Etoy Cleaning] Morph>>defaultFloatPrecisionFor - Issue 490: [Pending Etoy Cleaning] Morph >> decimalPlacesForGetter: Thanks a ***lot *** alain

Jan. 14, 2010

Re: [Pharo-project] Time for a new election in squeak.org soon

by StÃ©phane Ducasse

Cleopatra was a really amazing queen. Now to comment on your point: - it is amazing that when I was teaching Scheme women were better than men in average and still they would not continue in CS. - when I went in India for lectures this was more 50-50 probably because coding is not a well payed job there. Now in europe we have even problem to recruit male CS and the number of students in applied maths/maths which is normally more than CS is decreasing too. May be they all want to be managers. Stef > > > On Thu, Jan 14, 2010 at 12:04 PM, Martin McClure <martin(a)hand2mouse.com> wrote: > Peter Hugosson-Miller wrote: > > > > PS. I still consider Pharo and Squeak to be highly intertwined > > communities so input from Pharons/Pharaos/Pharooosies/p... ah, what are > > you guys called? :) ...is also welcome. > > > > > > Hmmm... Pharies maybe ;-) > > Pharaohs! > > ...now if we were still using initials instead of full names I would > look for who had the initials "tut"... > > I wish we had more Cleos in the community.... > > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 14, 2010