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

[Pharo-project] DropList/EditableDropList fixes

by Gary Chambers

See http://code.google.com/p/pharo/issues/detail?id=2821 Regards, Gary

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by Lukas Renggli

Anyway, don't bother. I fixed it in OB-Morphic-lr.133. This should work in any version: Name: OB-Morphic-lr.133 Author: lr Time: 17 August 2010, 6:04:59 pm UUID: 728befb5-2f47-4d92-a6c3-3f1ca44bc21f Ancestors: OB-Morphic-lr.132 - don't use PluggableButtonMorphPlus, as it doesn't work anymore in upcoming versions On 17 August 2010 17:41, Lukas Renggli <renggli(a)gmail.com> wrote: > I cannot integrate that change-set because it breaks OB in Pharo 1.1. > > PluggableButtonMorphPlus was never deprecated and now you say it just > disappeared? :-( > > Lukas > > 2010/8/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi Lukas. Trying to evaluate: >> >> (ConfigurationOfOmniBrowser project version: '1.1-baseline') load:Â 'Core >> RB' >> >> I am trying to load OB and RB in Pharo 1.2 >> >> I found still refernces to Preferences and some other problems. >> >> I attach a changeset to fix the ones I found. If you want to check them >> lukas would be nice :) >> >> Thanks >> >> Mariano >> >> _______________________________________________ >> 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

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by Lukas Renggli

I cannot integrate that change-set because it breaks OB in Pharo 1.1. PluggableButtonMorphPlus was never deprecated and now you say it just disappeared? :-( Lukas 2010/8/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Lukas. Trying to evaluate: > > (ConfigurationOfOmniBrowser project version: '1.1-baseline') load:Â 'Core > RB' > > I am trying to load OB and RB in Pharo 1.2 > > I found still refernces to Preferences and some other problems. > > I attach a changeset to fix the ones I found. If you want to check them > lukas would be nice :) > > Thanks > > Mariano > > _______________________________________________ > 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

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by Lukas Renggli

2010/8/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Sorry...found another one. > > In MenuMorph >> add: label target: anObject selector: aSelector enabled: > aBoolean icon: aSymbol > > you do Preferences menuWithIcons > > but should beÂ UITheme currentSettings menuWithIcons Looks like I forgot to commit a whole batch of changes: Name: OB-Morphic-lr.132 Author: lr Time: 17 August 2010, 5:38:15 pm UUID: b03368be-fe23-445b-9586-f16372e5fc8b Ancestors: OB-Morphic-lr.131 - removed all references to Preferences Name: OB-Shout-lr.7 Author: lr Time: 17 August 2010, 5:38:45 pm UUID: b14c055a-6430-4772-9c89-f5cc890681fe Ancestors: OB-Shout-lr.6 - removed all references to Preferences Name: ECompletion-lr.135 Author: lr Time: 17 August 2010, 5:39:14 pm UUID: 783fd270-7bd5-43d7-abe6-a750dc6f869b Ancestors: ECompletion-lr.134 - improved the settings placement -- Lukas Renggli www.lukas-renggli.ch

Aug. 17, 2010

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

by Henrik Johansen

On Aug 16, 2010, at 9:49 30PM, 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). More converters are always nice :D Their code seems ok to me. > > 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 > - some minor clean up like removing unused class variables > > I'd appreciate it if somebody knowledgeable in these areas could review > the changes. I'm especially unsure about the Latin9 language > environment, but reusing Latin1 or Unicode seemed wrong. I'm not sure its too wrong, according to EncodedCharSet comment: "The other confusion comes from the name of "Latin1" class. It used to mean the Latin-1 (ISO-8859-1) character set, but now it primarily means that the "Western European languages that are covered by the characters in Latin-1 character set." I'd reckon the same holds true for Latin1Environment (Western ), Latin2Environment (Eastern), and Latin7Environment (Greek). I don't think CP1252/8859-15 warrants the same as they are basically alternative encodings to latin1 for western languages. Also: - leadingChar is used in StrikeFontSet to choose different glyph sets. This allows for StrikeFonts supporting more than the default latin1 glyphs, seems to me it would be "wrong" to use the same one for two different encodings. Not sure why this approach was taken rather than allowing additional strike font sets based on unicode code point ranges, then using leadingChar only to differentiate when the visual glyphs for those code points would be different. I suspect it maybe was developed to deal with Han unification first, then reused to support multiple character sets later. - LanguageEnvironment seems to have been used in conjunction with translation (note the entire old translation system was removed in Pharo and replaced by an external package), maybe to decide which encoding externally stored translation files should be read in as. Then, having environments with overlapping supportedLanguages seem somewhat weird as well. Modifying defaultEncodingName/systemConverterClass of Latin1Environment to use CP1252 for some Windows systems (as per Latin2) may be another approach, may or may not lead to unintended consequences elsewhere though, I did not investigate all uses. IMHO, for someone who wasn't involved in its developemnt, the whole multilingual package could use some cleaning, more class comments, and clearer statement of responsibilities. Cheers, Henry TLDR; More converters: yay! More LanguageEnvironments: o_O, not sure

Aug. 17, 2010

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

by Henrik Johansen

On Aug 17, 2010, at 3:38 20PM, TimM wrote: > Henrik Johansen wrote: > >> 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 :) > > I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed. > > Tim There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc. Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop. Try the following from a workspace to illustrate: "Interruptable with Cmd-dot" [true ] whileTrue. "Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)" [[true ] whileTrue] forkAt: Processor activePriority - 1 "Code run from a workspace will run in the UI process, so active priority will be the UI process priority" "Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles" [[true] whileTrue] fork "Fork forks of the process at same priority as active process" Cheers, Henry

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by Mariano Martinez Peck

Sorry...found another one. In MenuMorph >> add: label target: anObject selector: aSelector enabled: aBoolean icon: aSymbol you do Preferences menuWithIcons but should be UITheme currentSettings menuWithIcons cheers mariano On Tue, Aug 17, 2010 at 3:53 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Lukas. Trying to evaluate: > > (ConfigurationOfOmniBrowser project version: '1.1-baseline') load: 'Core > RB' > > I am trying to load OB and RB in Pharo 1.2 > > I found still refernces to Preferences and some other problems. > > I attach a changeset to fix the ones I found. If you want to check them > lukas would be nice :) > > Thanks > > Mariano >

Aug. 17, 2010

[Pharo-project] Load OB in Pharo 1.2

by Mariano Martinez Peck

Hi Lukas. Trying to evaluate: (ConfigurationOfOmniBrowser project version: '1.1-baseline') load: 'Core RB' I am trying to load OB and RB in Pharo 1.2 I found still refernces to Preferences and some other problems. I attach a changeset to fix the ones I found. If you want to check them lukas would be nice :) Thanks Mariano

Aug. 17, 2010

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

by TimM

Henrik Johansen wrote: > 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 :) I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed. Tim

Aug. 17, 2010

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

by Alexandre Bergel

> 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? I would love to see the categorization selectively happen on methods that are already categorized. Cheers, Alexandre > > 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 > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 17, 2010