- Pharo-dev - lists.pharo.org

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