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

Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?

by Henrik Johansen

On Aug 17, 2010, at 2:05 11PM, TimM wrote: > Hi guys - it seems really easy to hang my seaside image and then have to force quit and restart. I thought that cmd-. was supposed to recover, but it never seems to work for me. > > Am I doing something wrong? (I am using a pharo 1.1 seaside3.0rc3 image with the mac 4.2.5 vm). > > I had the following code: > > modelUpdate > self pusher javascript: [ :jsScript | > jsScript << (self generateUpdateScriptWith: jsScript) ] > > > generateUpdateScriptWith: jsScript > > ^aJScript goto: anActionUrl withoutQuery > > > I think that the << operator is adding something that has already been added via aJScript goto: - and so its recursive. > > Anyway - when I hit this with my browser - the cpu of my Pharo image goes to 99% and I can hit Cmd-. all I want, but eventually it just dies - or I have to do a force quit. > > Should it be so easy to kill an image like this? > > Tim Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :) Cheers, Henry

Aug. 17, 2010

[Pharo-project] Should I be able to hang my pharo 1.1 image so easily?

by TimM

Hi guys - it seems really easy to hang my seaside image and then have to force quit and restart. I thought that cmd-. was supposed to recover, but it never seems to work for me. Am I doing something wrong? (I am using a pharo 1.1 seaside3.0rc3 image with the mac 4.2.5 vm). I had the following code: modelUpdate self pusher javascript: [ :jsScript | jsScript << (self generateUpdateScriptWith: jsScript) ] generateUpdateScriptWith: jsScript ^aJScript goto: anActionUrl withoutQuery I think that the << operator is adding something that has already been added via aJScript goto: - and so its recursive. Anyway - when I hit this with my browser - the cpu of my Pharo image goes to 99% and I can hit Cmd-. all I want, but eventually it just dies - or I have to do a force quit. Should it be so easy to kill an image like this? Tim

Aug. 17, 2010

[Pharo-project] Call for presentation for OSDC (free conference on dynamic languages)

by StÃ©phane Ducasse

http://www.osdc.fr/ http://act.osdc.fr/osdc2010fr/index.html http://act.osdc.fr/osdc2010fr/sponsorship.html 9 and 10 October at Paris. Stef

Aug. 17, 2010

Re: [Pharo-project] We want your photo

by laurent laffont

Added Gary Laurent On Mon, Aug 16, 2010 at 10:12 PM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > for http://pharo-project.org/community/contributors > > and a little description of your Pharo usage and / or contributions. > > Thanks, > <http://pharo-project.org/community/contributors> > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ >

Aug. 17, 2010

Re: [Pharo-project] Ideas of AutomaticMethodCategorizer ???

by Mariano Martinez Peck

ok....For those who were not here hahaha. We have just talked with Stef. There is no problem because AutomaticMethodCategorizer ONLY takes into account the methods that are not yet categorized. Thus....if you have *Something it means it is already categorized...thus, it does nothing. Is it ok? Mariano On Tue, Aug 17, 2010 at 10:08 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > This is not up to AutomaticMethodCategorizer. > > yes it is. > The automaticCategorizer should not when it get applied to a class breaks > packages > > > I mean, by code, the only defined rules are the ones that are in > #defaultCategorizationRules > > If you want you can add more rules. For a rule you can say something like > this: > > > > add: (MethodCategorizationRule whenSelectorMatches: 'is*' categorizeIn: > #testing); > > > > if you do something like this for example: > > > > add: (MethodCategorizationRule whenSelectorMatches: 'is*' categorizeIn: > #*Something); > > > > There will be no error in AutomaticMethodCategorizer and Something will > be recognized as it were a package. > > > > More or less could happen the same with a selector that doesn't apply to > any rule. For example, suppose #aFunnySelector doesn't match any rule, but > there are 10 implementors in the image and the 80% of them has category > *Something. Then. it will apply *Something also to that selector. > > > > That's what I understood. However, I don't think it is a big deal and we > can live with that. > > No! > Automatic categorizer should be able to be applied system wide and not > break all the packages. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2010

Re: [Pharo-project] adding ISO-8859-15 and CP-1252 support

by Philippe Marschall

On 08/16/2010 09:49 PM, Philippe Marschall wrote: > Hi > > I decided to write ISO-8859-15 and CP-1252 support [1] (mostly for > selfish reasons so that Seaside on Pharo would support ISO-8859-15 and > CP-1252). > > A couple of notes: > - the five unmapped bytes of CP-1252 (not ISO-8859-15, the comment is > wrong) are mapped to the Unicode replacement character (U+FFFD) > - a new Latin9 language environment is introduced I also snatched the first free leading char (17) for this. Cheers Philippe

Aug. 17, 2010

Re: [Pharo-project] Ideas of AutomaticMethodCategorizer ???

by StÃ©phane Ducasse

> This is not up to AutomaticMethodCategorizer. yes it is. The automaticCategorizer should not when it get applied to a class breaks packages > I mean, by code, the only defined rules are the ones that are in #defaultCategorizationRules > If you want you can add more rules. For a rule you can say something like this: > > add: (MethodCategorizationRule whenSelectorMatches: 'is*' categorizeIn: #testing); > > if you do something like this for example: > > add: (MethodCategorizationRule whenSelectorMatches: 'is*' categorizeIn: #*Something); > > There will be no error in AutomaticMethodCategorizer and Something will be recognized as it were a package. > > More or less could happen the same with a selector that doesn't apply to any rule. For example, suppose #aFunnySelector doesn't match any rule, but there are 10 implementors in the image and the 80% of them has category *Something. Then. it will apply *Something also to that selector. > > That's what I understood. However, I don't think it is a big deal and we can live with that. No! Automatic categorizer should be able to be applied system wide and not break all the packages. Stef

Aug. 17, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by StÃ©phane Ducasse

yes this will be much more efficient with a black board stef On Aug 17, 2010, at 12:25 AM, Dale Henrichs wrote: > Stef, > > Can we arrange to have a discussion about this issue at ESUG? There are a number of closely related things that need to be considered and I think that with email it is not easy ... > > Dale > > StÃ©phane Ducasse wrote: >> this was more or less what I had in mind but with a limited knowledge of metacello. >> Stef >>> >>> I think that we should do is a piece of code that does the following: >>> >>> - Take a ConfiguraitonOfXXX and do a "publish in Pharo Repository" >>> - This can propmt which Pharo version, or directly which PharoRepository >>> - Then it will ask which VERSION should be loaded in the already selected Pharo version >>> - It should be asked WHICH group (optional) >>> >>> Once this is done, the code has to do the following: >>> >>> - Iterates all the project and packages referenced and COPY ALL OF THEM into the same repository. Or maybe we can have another repo. This will copy all the .mzc of the project and its dependencies. With this you will make sure that you have EVERYTHING you need to load it. >>> - take that ConfigurationOfXXX and automatically compile a class side #load that based in your answers, does the correct job. >>> In addition, this method should do a repositoryOverride: with the selected repository. >>> Example: >>> >>> load >>> | version | >>> version := self project version: selectedVersion. >>> version repositoryOverrides: selectedPharoRepository. >>> version load: selectedGroup. >>> >>> Maybe it can implement a particular load: that recieves the common parameter >>> >>> >>> >>> Then, if you are in Pharo 1.0 the only thing you have to do is to explore the repository PharoRepository10 and browse the confs....you select the one you want and load it (with Gofer or Monticello Browser). Once that is done, you just evaluate: >>> >>> ConfiguarationOfXXX load. >>> and that's all. >>> >>> What do you think ? >>> Dale? >>> >>> >>> Cheers >>> >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2010

Re: [Pharo-project] which Shout repository should we use?

by StÃ©phane Ducasse

> Yes, that's good enough. My question was more general than this particular situation. I wanted to discuss which repository Pharo official images should use. why can't we use a configurationOfXX based on a pharoShout folder With Gofer we can script the pull from repositories. > > Cheers, > Doru > > > > On 16 Aug 2010, at 18:25, Lukas Renggli wrote: > > 2010/8/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sun, Aug 15, 2010 at 6:21 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > this is a good question. > for now I would just update the configuration to point for the repo of > lukas :) > > But now for example, I need to remove the style instVar in > PluggableShoutMorph because in Pharo 1.2 it has already such instVar. > But I don't know if I can commit or if Lukas would integrate such change in > his repo beacuse that will break Shout to load in Pharo 1.1 (the image he > uses) > > I will fix it as soon as the PharoCore 1.2 release candidate is out > and I am able to use the image. > > so... lukas what do you think we should do? > > So either fix it in Pharo or create your own 'temporary' version of > Shout in the repository where you keep all the versions for building > the images. > > 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 > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > > _______________________________________________ > 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

Aug. 17, 2010

Re: [Pharo-project] whileTrue: implementation

by Marcus Denker

I added a entry in the bugtracker for this so we don't forget: http://code.google.com/p/pharo/issues/detail?id=2819 On Aug 16, 2010, at 8:53 PM, Eliot Miranda wrote: > > BTW here's the VisualWorks 7.7 method. For me it's a little too clever. > > whileFalse: aBlock > "Evaluate the argument, aBlock, as long as the value of the receiver is false." > > ^self value > ifFalse: > [aBlock value. > [self value] whileFalse: [aBlock value]] > > "This method is inlined if both the receiver and the argument are literal > blocks. In all other cases, the code above is run. Note that the code > above is defined recursively. However, to avoid actually building an > activation record each time this method is invoked recursively, we have > used the '[...] whileFalse: [..]' form in the last line, rather than the more > concise 'self whileFalse: aBlock'. Using literal blocks for both the receiver > and the argument allows the compiler to inline #whileFalse:, which (in the > absence of type inferencing) could not be done if we were to use > 'self whileFalse: aBlock'." > > but it's accurate and does the job of turning > | a b | > a := [i <= j]. > b := [i := i + 1]. > a whileTrue: b > into an iterative execution. > > So at the very least we should improve the comment in whileTrue: and whileFalse: to point to the compiler optimization in MessageNode and IMO the VisualWorks implementation is the best compromise between clarity and honesty given the lack of tail-recursion elimination. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 17, 2010