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

[Pharo-project] Fwd: Cog VM doesn't start to listen on socket
by Eliot Miranda Oct. 26, 2010

Oct. 26, 2010

---------- Forwarded message ---------- From: Eliot Miranda <eliot.miranda(a)gmail.com> Date: Tue, Oct 26, 2010 at 10:23 AM Subject: Re: Cog VM doesn't start to listen on socket To: Lukas Renggli <renggli(a)gmail.com> Hi Lukas, obviously we use sockets intensively in Teleplace and we see no problems that are to do with Cog. But Cog does throw up timing issues in your code because it has very different performance to the base VM (Smalltalk code is faster, most primitives have the same speed, allocation is slightly faster, etc). So my gut feeling is that what you're seeing is a timing related issue (race condition?) that is revealed when on Cog and hidden when on the normal VM. HTH (yeah, right... ed.) Eliot On Tue, Oct 26, 2010 at 5:04 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > Hi Eliot, > > I noticed that on the Cog VM the Kom Seaside server does not > automatically start to listen, even if there is a process waiting at > the semaphore of the socket. Singaling that semaphore from the process > browser fixes the problem and the Cog image is fully working until the > next time it is opened. > > The exact same image opened with an old VM does not show the problem > and immediately starts to listen by itself. > > Did anybody else notice the same problem? Anybody found a solution? > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

3 5

Re: [Pharo-project] OCompletion doesn't work in Pharo 1.2 because of Preferences delete
by StÃ©phane Ducasse Oct. 26, 2010

Oct. 26, 2010

On Oct 26, 2010, at 11:38 PM, Levente Uzonyi wrote: > On Tue, 26 Oct 2010, StÃ©phane Ducasse wrote: > >> >> On Oct 26, 2010, at 11:18 PM, Levente Uzonyi wrote: >> >>> On Tue, 26 Oct 2010, Mariano Martinez Peck wrote: >>> >>>> HI Ramain (or someone with time). >>>> >>>> OCompletion does not work anymore in Pharo 1.2 because of the Preferences >>>> removal. It would be nice if you could update it to use the new settings >>>> framework. >>> >>> I fixed some of the preference issues (i didn't upload it yet), but it's a PITA to make it work in Pharo 1.2, because too many things were changed and are therefore broken. >> >> I can imagine. >> We should really get a way to support automatic change application but this is a real job to build that. >> >>> Btw what's with the "keep deprecated stuff for the next 2 minor versions" policy? >> >> this is what we do: we will remove 1.1 deprecated methods in 1.3 alpha. May be we did not apply it totally and are messy with that >> because we did not deprecated all the preferences methods. >> >>> Preferences are gone in 1.2, but Settings were only introduced in 1.1 and Preferences doesn't seem to be deprecated at all in 1.1. So, according to the policy, Preferences should be available till at least 1.3. >> >> the preferences class is just there in 1.2 to help people loading their code. but the behavior is gone. > > No, it's not there. At least not in the core image (12216). then this is just a mistake. > > > Levente > >> >> Settings were introduced in 1.1 (but not used) so that people can migrate their code in 1.1 to save it in 1.2. >> Alain reminds that recently. >>> >>> >>> Levente >>> >>>> >>>> There is information here: >>>> http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ >>>> >>>> Thanks >>>> >>>> mariano >>>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] OCompletion doesn't work in Pharo 1.2 because of Preferences delete
by StÃ©phane Ducasse Oct. 26, 2010

Oct. 26, 2010

On Oct 26, 2010, at 11:18 PM, Levente Uzonyi wrote: > On Tue, 26 Oct 2010, Mariano Martinez Peck wrote: > >> HI Ramain (or someone with time). >> >> OCompletion does not work anymore in Pharo 1.2 because of the Preferences >> removal. It would be nice if you could update it to use the new settings >> framework. > > I fixed some of the preference issues (i didn't upload it yet), but it's a PITA to make it work in Pharo 1.2, because too many things were changed and are therefore broken. I can imagine. We should really get a way to support automatic change application but this is a real job to build that. > Btw what's with the "keep deprecated stuff for the next 2 minor versions" policy? this is what we do: we will remove 1.1 deprecated methods in 1.3 alpha. May be we did not apply it totally and are messy with that because we did not deprecated all the preferences methods. > Preferences are gone in 1.2, but Settings were only introduced in 1.1 and Preferences doesn't seem to be deprecated at all in 1.1. So, according to the policy, Preferences should be available till at least 1.3. the preferences class is just there in 1.2 to help people loading their code. but the behavior is gone. Settings were introduced in 1.1 (but not used) so that people can migrate their code in 1.1 to save it in 1.2. Alain reminds that recently. > > > Levente > >> >> There is information here: >> http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ >> >> Thanks >> >> mariano >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] Proposal: adding 261 named colors
by StÃ©phane Ducasse Oct. 26, 2010

Oct. 26, 2010

http://map.squeak.org/package/4fcb1d4d-ff16-46e2-bfa8-a7410f0cd5a3 Stef

1 0

Re: [Pharo-project] About Adding/modifying in SUnit or not?
by StÃ©phane Ducasse Oct. 26, 2010

Oct. 26, 2010

Yes this is important. test written in Sunit should run on it and new features can be incompatible. On Oct 25, 2010, at 4:07 PM, Lukas Renggli wrote: > I am all in for improving SUnit, but there must be some compatibility > mode that makes it easy not only to run, but also to write tests on > the official SUnit. This is crucial for projects like Seaside, > Magritte, Pier, PetitParser, ... that are supposed to work on various > other Smalltalk platforms. > > Lukas > > On 25 October 2010 15:51, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >> Yea, well, it depends on whether we want to be compatible with camp >> smalltalk's SUnit, as maintained by Niall Ross: >> http://sunit.sourceforge.net/devel.htm. Pharo already is using >> extensions, such as the possibility to mark tests as expected failures >> at all (that is impossible in standard SUnit). >> >> My humble opinion is that we must control our testing environment, and >> we already have an excellent cleanup of SUnit, namely akuhn/SUnit, >> http://www.squeaksource.com/akuhn.html. And we have progress in the >> form of Phexample, which builds ontop of SUnit. >> http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-ex… >> . I'd be more than happy if Pharo took a new SUnit as its standard >> testing framework, and I'd even be thrilled if enough people found >> Phexample useful enough, so that it could become standard over time. >> >> Niko >> >> 2010/10/25 Luc Fabresse <luc.fabresse(a)gmail.com>: >>> Hi all, >>> I am working on pushing environments in SystemNavigation. >>> SystemNavigationTest previously used ClassFactoryForTestCase from SUnit for >>> generating classes. >>> Now I need an environment-aware ClassFactoryForTestCase. >>> Should I directly modify ClassFactoryForTestCase since a class generator >>> should now be environment aware? >>> Should I subclass ClassFactoryForTestCase and put it in SUnit? >>> Should I never changed SUnit and put it elsewhere? ;-) >>> #Luc >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] problem with metacello in 1.2
by StÃ©phane Ducasse Oct. 26, 2010

Oct. 26, 2010

On Oct 25, 2010, at 8:57 PM, Dale Henrichs wrote: > Stef, > > I've wrapped my head around this one a little more ... the only stack that I saw, showed a 'Error: file is too short' error which is probably coming from the ZipArchive code ... this usually means that there was a network failure when trying to read a file from an HTTP repository. Perhaps SqueakSource was being saturated? Yes they got the same problem. > > Dale > > On 10/25/2010 11:44 AM, Dale Henrichs wrote: >> Stef, >> >> I'm not sure what problem you are referring to. I haven't released a new >> version of Metacello since the beginning of September.... >> >> Dale >> >> On 10/24/2010 09:55 AM, StÃ©phane Ducasse wrote: >>> Dale >>> >>> did something change on the server side? >>> >>> This is strange >>> >>> 199 - Issue 3048: MC method cache fix. Thanks Igor Stasenko >>> 200 - Issue 2653: Editor cursor fix: remove autoclose in texteditor. >>> - Issue 3128: AuthorRequestImprovement. Thanks Alain Plantec - Issue 3099: Create method in the debugger does not provides getter/setters implementors. Thanks Hernan Wilkinson >>> 201 - Issue 1800: MenuIcons and ThemeIcons should be merged. Big thanks to alain plantec!!! >>> 202 - Issue 3070: weird replacements in TextEditor. Thanks Alain Plantec!!! >>> 203 - Issue 654: inconsistent highlight color. Thanks Alain Plantec >>> - Issue 3101: Wrong Monticello packages initialization order. Thanks Pavel Krivanek >>> 204 - Issue 2868: allClassesUsingPool: allClassesUsingPoolVariable: for systemNavigation >>> - Issue 3046: BUG: LineMorph class>>from:to:color:width: returns a PolygonMorph >>> - Issue 3130: MethodReference>> #isLocalSelector should not be part of Monticello package >>> - Issue 3095: Character isLiteral is in wrong category >>> - Issue 3134: Cleaning uniclasses from smartRefStream >>> Jannik can you check with the Utilities trick I sent you to try >>> >>> Utilities readServer: Utilities serverUrls updatesThrough: 12200 saveLocally: false updateImage: true >>> >>> 199 >>> 200 >>> 201 >>> 202 >>> 203 >>> 204 >>> >>> so that we try to identify the problem >>> >>> Stef >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

1 0

Re: [Pharo-project] Proposal: adding 261 named colors
by StÃ©phane Ducasse Oct. 26, 2010

Oct. 26, 2010

I think that this is good to clean it a bit anyway. Did you have a look at the other package too? On Oct 24, 2010, at 7:34 PM, Johan Fabry wrote: > > Yes there are some fun names in there: ice, yelowish, midnight, barney. Also some very 'human-excreta-related' ones: puke, vomit, poo, booger, ... But I chose not to pass a watch-out-for-the-children filter. (What would I do with Barney for example ? :-P ) > > On 24 Oct 2010, at 03:46, StÃ©phane Ducasse wrote: > >> ok I read the code :) >> >> I like 'swamp' >> >> Stef >> >> On Oct 23, 2010, at 11:30 PM, Johan Fabry wrote: >> >>> Hi all, >>> >>> in the work of AspectMaps I was a bit let down by the named colors Pharo provides (Color red et cetera). Now I am happy to say that thanks to the XKCD color survey I was able to improve on this. I can now use 261 named colors thanks to a XKCDColor class, and I'd like to share the code, ideally to be included into Pharo. The code is available in bugreport http://code.google.com/p/pharo/issues/detail?id=3148 >>> >>> Here is the class comment fo XKCDColor: >>> >>> ---snip--- >>> A color named according to the XKCD color survey, as published in http://blog.xkcd.com/2010/05/03/color-survey-results/ ("Over five million colors were named across 222,500 user sessions.") >>> >>> Of the full table of 954 colors that is published only those were selected that did not have a space in their name, ignoring e.g. electric lime, nasty green, macaroni and cheese, pinkish tan, but also light light blue, strong blue. This results in a table of 261 named colors, but with duplicates such as ochre and ocre. These were left in since as they are common misspellings it is more convenient for the user. >>> >>> To instantiate: XCDColor named: aString where aString is one of the 261 named colors. If the name is not known, the color red is instantiated. Instances of XKCDColor know their XKCD color name, returned by the name accessor. >>> >>> Thanks to Randall Monroe of http://xkcd.com for providing the data. >>> ---snip--- >>> >>> And here is a picture of all the colors (Generated with Mondrian :-) ) >>> >>> <Colors.png> >>> >>> -- >>> Johan Fabry >>> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] Cog VM doesn't start to listen on socket
by Lukas Renggli Oct. 26, 2010

Oct. 26, 2010

Hi Eliot, I noticed that on the Cog VM the Kom Seaside server does not automatically start to listen, even if there is a process waiting at the semaphore of the socket. Singaling that semaphore from the process browser fixes the problem and the Cog image is fully working until the next time it is opened. The exact same image opened with an old VM does not show the problem and immediately starts to listen by itself. Did anybody else notice the same problem? Anybody found a solution? Lukas -- Lukas Renggli www.lukas-renggli.ch

2 1

[Pharo-project] Traceback from MIMEDocument>>guessTypeFromName
by Tony Fleig Oct. 26, 2010

Oct. 26, 2010

In Pharo1.1 update #11411, evaluating MIMEDocument guessTypeFromName: 'x.css' produces the attached traceback. Changing MIMEDocument>>guessTypeFromName: url "guesses a content type from the url" ^MIMEType forFileNameReturnSingleMimeTypeOrDefault: url asString asURI to MIMEDocument>>guessTypeFromName: url "guesses a content type from the url" ^MIMEType forFileNameReturnSingleMimeTypeOrDefault: url asString (removing asURI), makes it work as expected, answering 'css'. Is this a bug? Is my fix appropriate? I've made this change in my image. What is the process to get this addressed in the product? Thanks, TF

2 2

Oct. 26, 2010

Dale did something change on the server side? This is strange 199 - Issue 3048: MC method cache fix. Thanks Igor Stasenko 200 - Issue 2653: Editor cursor fix: remove autoclose in texteditor. - Issue 3128: AuthorRequestImprovement. Thanks Alain Plantec - Issue 3099: Create method in the debugger does not provides getter/setters implementors. Thanks Hernan Wilkinson 201 - Issue 1800: MenuIcons and ThemeIcons should be merged. Big thanks to alain plantec!!! 202 - Issue 3070: weird replacements in TextEditor. Thanks Alain Plantec!!! 203 - Issue 654: inconsistent highlight color. Thanks Alain Plantec - Issue 3101: Wrong Monticello packages initialization order. Thanks Pavel Krivanek 204 - Issue 2868: allClassesUsingPool: allClassesUsingPoolVariable: for systemNavigation - Issue 3046: BUG: LineMorph class>>from:to:color:width: returns a PolygonMorph - Issue 3130: MethodReference >> #isLocalSelector should not be part of Monticello package - Issue 3095: Character isLiteral is in wrong category - Issue 3134: Cleaning uniclasses from smartRefStream Jannik can you check with the Utilities trick I sent you to try Utilities readServer: Utilities serverUrls updatesThrough: 12200 saveLocally: false updateImage: true 199 200 201 202 203 204 so that we try to identify the problem Stef

3 4