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

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

by Lukas Renggli

Ok, I think I solved the issue. Restarting the server on startup seems to solve the problem on all my machines. Thanks again for the hints! Lukas On 26 October 2010 20:41, Lukas Renggli <renggli(a)gmail.com> wrote: > Thank you Eliot for the answer. I will have to investigate and see if > this is a Seaside specific issue or related to Kom. > > Lukas > > 2010/10/26 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> ---------- 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 >> >> >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Oct. 26, 2010

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

by Lukas Renggli

Thank you Eliot for the answer. I will have to investigate and see if this is a Seaside specific issue or related to Kom. Lukas 2010/10/26 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > ---------- 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 > > > > _______________________________________________ > 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

Oct. 26, 2010

Re: [Pharo-project] Smells looking at collections

by Eliot Miranda

Hi Florin, 2010/10/26 Florin Mateoc <fmateoc(a)gmail.com> > Eliot wrote: > > Hi Levente, > > in my experience playing with the Dan and Alan Borning's multiple > inheritance implementation getting things to work was one thing, reasonably > straighforward, but getting tool support right (file-out format so that > things filed back in correctly, etc) was another, an dth ebulk of the work. > Looking at your proposal below I see no problem getting it to work but see > lots of problems integrating it, e.g. with Monticello, etc. Traits is > already integrated with Monticello, supported with tests, etc. As such it > is a much less risky or effortful proposition than a new scheme. So with > that in mind are there important functional benefits of your scheme's direct > state access as compared with traits that use accessors to access state that > each user of a trait must implement? i.e. what are the key benefits you see > in direct inst var access? > > best > Eliot > > > Hi Eliot, > > I think there is a strong argument for stateful traits, especially since we > are talking about collection smells. > One of the main selling points for traits (for me, at least) is that they > would allow us to clean up the mess > created by inheritance for reuse (Dictionary is a Set) in existing > libraries. > And obviously to create cleaner libraries going forward. > Well, inheritance for reuse is used not just for behavior, but for state as > well. > Stateful traits would allow for a cleaner separation between inheritance > and subtyping. > Stateful traits would even allow you to push the separation further and, as > part of your design, you could have state-only traits > complementing behavior-only traits. > Let us not forget that clean concepts are also easier to learn. I think it > is much more important to get the concepts right > than any existing integration with Monticello. Why does it matter that we > have tests and integration if people are not > using traits? > The argument is not over the utility of stateful traits. The argument is over how to access that state. The existing Traits implementation allows indirect access to state, where the Trait uses accessors that must be implemented by a class using the trait. This has the disadvantages listed by Levente, possibility of accessor selectors clashing with existing protocol, lack of privacy and poorer performance. One possible solution is to do a new traits implementation that supports state, but as discussed integration is hard and that could be a lot of work. There are other solutions to explore that could localise the changes. For example imagine adding some special illegal syntax that a variant of the compiler (a compiler mode or a subclass or...) can deal with and using that to reference trait state. Then changes are localised to - the compiler (to compile the syntax down onto the relevant inst vars) - class definition/trait composition (to ensure the state inst vars exist in the class) - shout (to highlight the new syntax) - the decompiler (so decompiled trait code displays the new syntax for trait state access) Another possibility might be a selector privacy hack. The selectors used to access state in a trait are known not to clash in the trait (they ca be so chosen by the trait author not to conflict with anything in the trait) but they cannot be guaranteed not to clash with a user of the trait. So post-compile the selectors for the trait's state could be changed to private values (keys that existed only in the method dictionary of the trait user). This doesn't have the performance of direct inst var access, but it solves the clash and privacy issues. And I expect there are other solutions too. In summary don't argue for or against stateful traits, instead think about how to add state to traits whilst having the most minimal impact on the rest of the infrastructure. best Eliot > Cheers, > Florin > > _______________________________________________ > 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] Proposal: adding 261 named colors

by StÃ©phane Ducasse

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

Oct. 26, 2010

Re: [Pharo-project] About Adding/modifying in SUnit or not?

by StÃ©phane Ducasse

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

Oct. 26, 2010

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

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

by Mariano Martinez Peck

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

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

by Alexandre Bergel

Cool! Alexandre On 23 Oct 2010, at 18:29, 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 26, 2010

Re: [Pharo-project] Pharo problem with Windows 7

by Alexandre Bergel

Cool! Alexandre On 24 Oct 2010, at 06:48, Christian Eduardo Palomares Peralta wrote: > Hi > > After three days i've got success, i totally disabled my antivirus and it works =) > > Thanks for the help to Alexandre Bergel, Torsten Bermann and Mariano Martinez > > Obviously i'm going to enable my antivirus and configure it > > -- > Christian Eduardo Palomares Peralta (ShinjiDev) - http://learningwebdev.blogspot.com > Administrador del Grupo Python-PerÃº > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 26, 2010

[Pharo-project] [update 1.2] #12216

by Marcus Denker

12216 ----- Issue 3161: StandardFileStream >> nextPutAll: stringOrByteArray Issue 3163: Fix Menu SmalltalkEditor more Issue 3159: TextMorph cleaning Issue 3077: Suggestion for Remodularisation -> Form - put depration call into sortBy: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 26, 2010

[Pharo-project] Smells looking at collections

by Florin Mateoc

Eliot wrote: Hi Levente, in my experience playing with the Dan and Alan Borning's multiple inheritance implementation getting things to work was one thing, reasonably straighforward, but getting tool support right (file-out format so that things filed back in correctly, etc) was another, an dth ebulk of the work. Looking at your proposal below I see no problem getting it to work but see lots of problems integrating it, e.g. with Monticello, etc. Traits is already integrated with Monticello, supported with tests, etc. As such it is a much less risky or effortful proposition than a new scheme. So with that in mind are there important functional benefits of your scheme's direct state access as compared with traits that use accessors to access state that each user of a trait must implement? i.e. what are the key benefits you see in direct inst var access? best Eliot Hi Eliot, I think there is a strong argument for stateful traits, especially since we are talking about collection smells. One of the main selling points for traits (for me, at least) is that they would allow us to clean up the mess created by inheritance for reuse (Dictionary is a Set) in existing libraries. And obviously to create cleaner libraries going forward. Well, inheritance for reuse is used not just for behavior, but for state as well. Stateful traits would allow for a cleaner separation between inheritance and subtyping. Stateful traits would even allow you to push the separation further and, as part of your design, you could have state-only traits complementing behavior-only traits. Let us not forget that clean concepts are also easier to learn. I think it is much more important to get the concepts right than any existing integration with Monticello. Why does it matter that we have tests and integration if people are not using traits? Cheers, Florin

Oct. 26, 2010

Re: [Pharo-project] export information to PDF

by Esteban Lorenzano

Ok, I made a small research. The functionality is still present in current squeak, but it is not working well (at least I was unable to get a valid postcript file with my attempts). So... this is something cool to have, and I will take a look in how to package it, and how to make it work again, but with some time... which I did not have at the moment. But I will have, eventually :) Cheers, Esteban On 2010-10-25 03:13:44 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: > if it works yes and if it does not pollutes everything. > So Esteban if you can package this behavior into a package we are > interested. Probably look in 3.9 > but I'm not sure that it was working there. > > > On Oct 25, 2010, at 12:42 AM, Esteban Lorenzano wrote: > >> Some time ago, there was a functionality to export a morph as a .ps >> file, I don't remember in which pharo version that function was >> lost...maybe it is in a package, and can be loaded, I really don't >> know, but it should be nice :) >> >> Cheers, >> Esteban >> >> On 2010-10-24 09:58:09 -0300, name name >> <onor16(a)gmail.com> said: >> >>> Hello, >>> Could you tell me how can I export (or where I can found ) information that >>> I can get with a getter into a .pdf file? >>> Thanks >>> >> ass=3D"text-cell">=A0=A0=A0=A0 Hello, Could you tell me how can I ex= >>> port (or where I can found )=20 >>> =A0information that I can get with a getter into a .pdf file? >>> Thanks >>> =09 >>> =09 >>> =09 >>> >>> _______________________________________________ >>> 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

Re: [Pharo-project] is there a way to gofer a configurationOf?

by Esteban Lorenzano

Hi, Yes, Dale is working on that and I will integrate it to Gofer Project Loader as soon as he and Mariano tell me it is ready :) On 2010-10-26 04:10:39 -0300, stephane ducasse <stephane.ducasse(a)free.fr> said: > Hi > > I would like in particular to do > > Gofer new squeaksource: 'Citezen'; package: 'ConfigurationOfCitezen; push > > and that all the dependent packages get pushed > > stef

Oct. 26, 2010

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

by Lukas Renggli

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] Learning on Sockets

by GÃ¶ran Krampe

On 10/25/2010 09:21 AM, laurent laffont wrote: > Thank you Noury. > > Indeed for those interested in, I've just remembered that PBE is on > github. So we can read it here > http://github.com/SquareBracketAssociates/PharoByExample-english/blob/maste… > > Cheers, > > Laurent. Nice! Although I *do* think you should tell the reader that for most uses you would not need to use Socket directly - SocketStream is much more comfortable. I notice you have a planned section on SocketStream, but please let the reader know earlier in the text. regards, GÃ¶ran

Oct. 26, 2010

Re: [Pharo-project] [squeak-dev] How weak finalization affects the performance

by Igor Stasenko

On 26 October 2010 10:30, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > Why does finalization do any work when running a block which I think just > creates garbage? Â Is finalization on a per class basis (i.e.: the VM > notifies the image that some objects might be notified, and the image just > enumerates through them), or on a per object basis (i.e.: the VM maintains a > finalization queue as in VisualWorks)? > There is no per-object or per-class finalization in Squeak. One must either register an object using WeakRegistry, or add own object to weak dependents (it should answer to #finalizeValues). Squeak VM signals the semaphore each time GC happen, and actually, a finalization process could do something arbitrary to react on such event. Putting delay there ensuring that even if you put a very ineffective finalization into weak dependents, it won't affect the performance too much. > On 10/26/10 0:25 , Igor Stasenko wrote: >> >> Here the idea, which came to Chris, >> put a delay into #finalizationProcess loop: >> >> finalizationProcess >> Â Â Â Â [true] whileTrue: >> Â Â Â Â Â Â Â Â [ WeakFinalizationList initTestPair. >> Â Â Â Â Â Â Â Â FinalizationSemaphore wait. >> Â Â Â Â Â Â Â Â FinalizationLock critical: >> Â Â Â Â Â Â Â Â Â Â Â Â [ >> Â Â Â Â Â Â Â Â Â Â Â Â WeakFinalizationList checkTestPair. >> Â Â Â Â Â Â Â Â Â Â Â Â FinalizationDependents do: >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [:weakDependent | >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â weakDependent ifNotNil: >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [weakDependent finalizeValues]]] >> Â Â Â Â Â Â Â Â Â Â Â Â ifError: >> Â Â Â Â Â Â Â Â Â Â Â Â [:msg :rcvr | rcvr error: msg]. >> Â Â Â Â Â Â Â Â 5 seconds asDelay wait. >> Â Â Â Â Â Â Â Â ]. >> >> >> And here a simple benchmark, which triggers GC often: >> >> [ Array new: 100 ] bench >> >> without delay: >> >> '2,450,000 per second.' >> '2,490,000 per second.' >> '2,490,000 per second.' >> '2,480,000 per second.' >> '2,530,000 per second.' >> >> with delay: >> >> '2,670,000 per second.' >> '2,680,000 per second.' >> '2,690,000 per second.' >> '2,730,000 per second.' >> >> roughly about ~8% faster :) >> >> But now lets put something big into weak array: >> >> | dict b | >> dict := WeakKeyDictionary new addAll: (( 1 to: 1000 ) collect: [:i | >> i->i] ); yourself. >> WeakArray addWeakDependent: dict. >> b := [ Array new: 100 ] bench. >> WeakArray removeWeakDependent: dict. >> b >> >> without delay: >> >> '1,840,000 per second.' >> '2,060,000 per second.' >> '2,130,000 per second.' >> >> with delay: >> >> '3,030,000 per second.' >> '2,880,000 per second.' >> '2,890,000 per second.' >> >> Do not forget to do: >> WeakArray restartFinalizationProcess >> >> when you changing the #finalizationProcess method, >> otherwise you won't see real numbers. >> >> So, i like the idea of putting delay there. >> Finalization is eventual, and there is no hard guarantees that it will >> happen in micro-second just after some object become garbage. >> So, be it 5 seconds or 1000 seconds not really matters. >> What is matters that with delay we win much more, by avoiding wasting >> time in finalization process too often. >> >> > > -- Best regards, Igor Stasenko AKA sig.

Oct. 26, 2010