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

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