- Pharo-dev - lists.pharo.org

[Pharo-project] Default Theme (was [update 1.2] #12297)

by Torsten Bergmann

>- Glamourous setting as default. Arrghhh ... how ugly. I like the Watery2 theme more and would like to keep it as default. Any chance we can put it back ... should we vote? It is also used in various screenshots and screencasts and has given Pharo already a visual identity. So why switch to Glamourous as default? Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Jan. 12, 2011

Re: [Pharo-project] Issue 2897 in pharo: Compiler fixes from eliot

by pharo＠googlecode.com

Updates: Status: Fixed Comment #2 on issue 2897 by stephane.ducasse: Compiler fixes from eliot http://code.google.com/p/pharo/issues/detail?id=2897 (No comment was entered for this change.)

Jan. 12, 2011

[Pharo-project] [update 1.2] #12297

by StÃ©phane Ducasse

12297 ----- - Issue 3525: Compiler>>parserClass is broken and does not querying the class for providing the parser class. Thanks Igor Stasenko. - Glamourous setting as default.

Jan. 12, 2011

Re: [Pharo-project] Issue 2454 in pharo: decompiler fix

by pharo＠googlecode.com

Updates: Status: Accepted Labels: -Milestone-1.2 Milestone-1.3 Comment #6 on issue 2454 by stephane.ducasse: decompiler fix http://code.google.com/p/pharo/issues/detail?id=2454 In 12295 we tested with igor and without the fix in pharo we get the same as in Squeak: test | one two | two := 2. ^{[one := 1]. [ [one + two] value]} is decompiled into test | two one | two := 2. ^ {[one := 1]. [[one + two] value]}

Jan. 12, 2011

Re: [Pharo-project] Issue 2454 in pharo: decompiler fix

by pharo＠googlecode.com

Updates: Status: Fixed Comment #5 on issue 2454 by stephane.ducasse: decompiler fix http://code.google.com/p/pharo/issues/detail?id=2454 (No comment was entered for this change.)

Jan. 12, 2011

Re: [Pharo-project] senders vs implementors

by Marcus Denker

On Jan 12, 2011, at 3:25 PM, Tudor Girba wrote: > Hi, > > I think I encountered an error in allImplementorsOf:, but I am not quite sure and I wanted to run it by you first. > > If you evaluate > (self systemNavigation allSendersOf: #browse) anyOne sourceCode. > > you get the source as expected. > > > However, if you evaluate: > (self systemNavigation allImplementorsOf: #browse) anyOne sourceCode. > > you get an error. > > The last snippet used to work just fine in Pharo 1.1.1. > > > I consider it a bug. What do you think? Yes, this is a bug. (the whole MethodReference stuff is right now in the process of being re-designed...) One workound is to get the real method and ask it for the code: (self systemNavigation allImplementorsOf: #browse) anyOne compiledMethod getSource. arcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 12, 2011

Re: [Pharo-project] Issue 3533 in pharo: add Dictionary>>at:ifAbsentPutValue:

by pharo＠googlecode.com

Comment #1 on issue 3533 by stephane.ducasse: add Dictionary>>at:ifAbsentPutValue: http://code.google.com/p/pharo/issues/detail?id=3533 at: key ifAbsentPutValue: anObject "Return the value at the given key. If key is not included in the receiver store the new value." ^ self at: key ifAbsent: [self at: key put: anObject ]

Jan. 12, 2011

Re: [Pharo-project] Xtreams up to date

by mkobetic＠gmail.com

mkobetic(a)gmail.com wrote: > Hm, that is odd. Maybe I need to try a fresh load and see. I normally get a single failure in one of the socket tests which we haven't tracked down yet. Can you give me a bit more about the kind of errors and failures you see. Does it look like stuff is completely missing ? Maybe I messed up the publishing after the various class moves that I did recently. No, fresh load into one-click 1.1.1 works for me. I guess I need to try different versions.

Jan. 12, 2011

[Pharo-project] Issue 3533 in pharo: add Dictionary>>at:ifAbsentPutValue:

by pharo＠googlecode.com

Status: Accepted Owner: stephane.ducasse Labels: Milestone-1.3 New issue 3533 by stephane.ducasse: add Dictionary>>at:ifAbsentPutValue: http://code.google.com/p/pharo/issues/detail?id=3533 Igor suggests to add this method in dictionary to avoid to use block closure when not necessary. Here the block has to be passed and executed. When you know the value you want to put this is extra work. at: key ifAbsentPut: aBlock "Return the value at the given key. If key is not included in the receiver store the result of evaluating aBlock as new value." ^ self at: key ifAbsent: [self at: key put: aBlock value]

Jan. 12, 2011

Re: [Pharo-project] Xtreams up to date

by Henrik Sperre Johansen

Den 12.01.2011 14:25, skrev Sven Van Caekenberghe: > On 12 Jan 2011, at 10:44, Torsten Bergmann wrote: > >> Used your Gofer script in Pharo-core 1.2 and Pharo-dev 1.1., >> but after loading I run the tests with many errors and failures... >> >> Is it Squeak only? (which I doubt since the loading script uses >> Gofer instead of Installer and Gofer is Pharo while Installer is >> Squeak). >> >> Would be nice if we could have a working ConfigurationOfXtream in http://squeaksource.com/MetacelloRepository so it is easy accessible and working packages are versioned together using Metacello. >> >> Thx >> T. >> -- >> NEU: FreePhone - kostenlos mobil telefonieren und surfen! >> Jetzt informieren: http://www.gmx.net/de/go/freephone > I see that Martin Kobetic has been doing some checkins lately, maybe you should ask him. > I would be nice if Xtreams works well on Pharo. > > Sven Many is perhaps an overstatement, when I loaded into a 1.2dev image, all failures/errors where in relation to XTSocketReadWriting, and many of those passed if ran independently/restarted in the debugger... Can't just load the CoreTests and have all tests pass though, due to the isAbstract implementation in XTReadingWritingTest. Maybe XTReadingWritingTest, XTInfiniteReadingWritingTests and XTFiniteReadingWritingTests should be moved to the Terminals-Tests package? Cheers, Henry

Jan. 12, 2011