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

Re: [Pharo-project] problem with metacello in 1.2

by StÃ©phane Ducasse

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 >> >

Oct. 26, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by StÃ©phane Ducasse

On Oct 25, 2010, at 10:12 AM, Niko Schwarz wrote: > Couldn't Adrian be the maintainer? I could step in, too. yes but it means being present and reactive. > I don't really know what you have in mind for a testing framework. We > have our own independent and fully compatible fork of SUnit: > akuhn/SUnit, which is quite a strong code basis. but do we need should, class factory..... > And on top of that we > have Phexample, which has its own > name, some extra features and gives a clear point where Pharo is > different from the rest. This is not the difference that we look for. This is addressing people problems. > Just a suggestion: Let Adrian maintain akuhn/SUnit, perhaps minus the > "should" syntax that you don't like (as in: #(a b c) size should = 3), > and make akuhn/SUnit part of Pharo core. The new features (having tests depend > on one another, "should" syntax) go into Phexample, and I could > maintain that. Why not. If adrian wants. Now first we should have - a better name - clean the code = remove class factory + add comments - make sure that the tools can work with it - move the long execution Sunit extension to it - make sure that the tests are green - integrate/digest latest Sunit feature > > Cheers, > > Niko > > On Sun, Oct 24, 2010 at 8:37 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Lack of maintainers, too many unwanted features, lack of explanation, >> large changes... >> >> And this is not that several persons did not look at the code. It got more than the average. >> >> Now I'm thinking that with discussion and care we should really get another testing framework with the same API that SUnit >> because if we want that PharoSunit is the same as Sunit then we are doomed to be backward compatible and no >> real improvements. >> >> Stef >> >> On Oct 23, 2010, at 10:58 PM, Adrian Kuhn wrote: >> >>> Sad to hear that. >>> >>> Technical difficulties, or just lack of customers? ^^ >>> >>> --AA >>> >>> On Oct 23, 2010, at 08:05 , StÃ©phane Ducasse wrote: >>> >>>> It was too difficult to integrate. >>>> >>>> Stef >>>> >>>> On Oct 23, 2010, at 2:01 PM, Niko Schwarz wrote: >>>> >>>>> What's the status of akuhn/SUnit? I couldn't find his code in 1.2 core. >>>>> >>>>> Niko >>>>> >>>>> On Wed, Feb 3, 2010 at 1:13 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>> this loads well in the latest 1,1 core :) >>>>>> so now we should really have a look and these cool changes >>>>>> >>>>>> Stef >>>>>> >>>>>> On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: >>>>>> >>>>>>> SystemChangeNotifier uniqueInstance >>>>>>> noMoreNotificationsFor: TestCase. >>>>>>> Gofer it >>>>>>> disablePackageCache; >>>>>>> squeaksource: 'akuhn'; >>>>>>> package: 'SUnit'; >>>>>>> package: 'SUnitGUI'; >>>>>>> load. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >> >> >> _______________________________________________ >> 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

Oct. 26, 2010

[Pharo-project] Fwd: Cog VM doesn't start to listen on socket

by Eliot Miranda

---------- 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 >

Oct. 26, 2010

Re: [Pharo-project] Proposal: adding 261 named colors

by Johan Fabry

No I did not find this package, need a bit more precise info ... In any case those colors could be added to the list too if we later recuperate the info. I propose the integrator has a look at the names and removes the ones deemed inapropriate, it should not be many of them. Please notify me when it is integrated, I would like to notify the xkcd guy, as that is his condition for use of the data. On 24 Oct 2010, at 17:56, StÃ©phane Ducasse wrote: > 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 -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Oct. 26, 2010

Re: [Pharo-project] Cog VM doesn't start to listen on socket

by Facundo Vozzi

Hi Lukas, I'm using Pharo 1.1 + Cog (04/10/2010) + Seaside 3 and haven't that problem. I started Kom (WAKom startOn: 9090) once and when I open my image it start automatically all times. Facundo ps: I'm using Windows 7. On Tue, Oct 26, 2010 at 9: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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2010

Re: [Pharo-project] Traceback from MIMEDocument>>guessTypeFromName

by Tony Fleig

Ah. Thank you. I see I should peruse the issues list for problems like this before trying to figure it out myself. Regards, TF On Tue, Oct 26, 2010 at 8:50 AM, Philippe Marschall < philippe.marschall(a)netcetera.ch> wrote: > On 10/26/2010 05:32 PM, Tony Fleig wrote: > > 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? > > Yes it is, see: > http://code.google.com/p/pharo/issues/detail?id=2797 > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2010

[Pharo-project] OCompletion doesn't work in Pharo 1.2 because of Preferences delete

by Mariano Martinez Peck

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. There is information here: http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ Thanks mariano

Oct. 26, 2010

Re: [Pharo-project] Traceback from MIMEDocument>>guessTypeFromName

by Philippe Marschall

On 10/26/2010 05:32 PM, Tony Fleig wrote: > 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? Yes it is, see: http://code.google.com/p/pharo/issues/detail?id=2797 Cheers Philippe

Oct. 26, 2010

[Pharo-project] Traceback from MIMEDocument>>guessTypeFromName

by Tony Fleig

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

Oct. 26, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Mariano Martinez Peck

grrrr now it works... damn it seems random :( On Tue, Oct 26, 2010 at 5:19 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Dale. No, the error seems reproducable. I am in PharoCore 12215 and I > have the same error when trying to evaluate, for example: > > (ConfigurationOfRefactoringBrowser project version: '1.6') load: 'Core > Tests' > > But the same happens with any conf, since what is failing is the > ensureMetacello. > > Don't know why. I think there was a change in PharoCore where this start to > happen. Maybe debugging you can realise...I couldn't :( > > cheers > > mariano > > > On Mon, Oct 25, 2010 at 8:57 PM, Dale Henrichs <dhenrich(a)vmware.com>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? >> >> 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 >>>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Oct. 26, 2010