- Pharo-dev - lists.pharo.org

Re: [Pharo-project] why TextMorph and PluggableTextMorph are not

by Fernando olivero

WEIRD! IMO There should be no need for PluggableTextMorph, I think the work on NewTextMorph goes into that direction, a customizable and extensible text morph, that announces whatever happens to it. On Aug 17, 2010, at 9:46 PM, StÃ©phane Ducasse wrote: > well in the same hierarchy? > I like because I'm so naive about how the world could be :) > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2010

[Pharo-project] About porting and using the classificationModel in Pharo

by Fernando olivero

Hi, is there a port to Pharo1.2 of the ClassificationModel. (http://scg.unibe.ch/archive/papers/Wuyt04aClassifications.pdf) If not would the Star Browser for Squeak , be a good place to start from? http://map.squeak.org/package/9187f67b-a437-4e52-93f9-eecb9b48df78 Thanks Fernando

Aug. 18, 2010

Re: [Pharo-project] SocketStream enh

by StÃ©phane Ducasse

>>>> I will integrate the following SocketStream tests and before I would love to see if this >>>> does not impact seaside >>>> >>>> http://code.google.com/p/pharo/issues/detail?id=2767 Does anybody have the time to give feedback on this important network changes? Stef

Aug. 18, 2010

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

by StÃ©phane Ducasse

may be you should contact yoshiki. On Aug 18, 2010, at 9:59 AM, Philippe Marschall wrote: > On 08/17/2010 04:55 PM, Henrik Johansen wrote: >> >> 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 > > OK, if nobody says it's a good idea and the right thing to do I'll drop > the LanguageEnvironment. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2010

[Pharo-project] [update 1.2] #12098

by Marcus Denker

12098 ----- Issue 2826: add empty PluggableButtonMorphPlus Issue 2824: PluggableTextMorphWithModel is not used Issue 2333: MCSnapshotBrowser>>allClassNames would incorrectly list the classe -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 18, 2010

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

by Philippe Marschall

On 08/17/2010 04:55 PM, Henrik Johansen wrote: > > 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 OK, if nobody says it's a good idea and the right thing to do I'll drop the LanguageEnvironment. Cheers Philippe

Aug. 18, 2010

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

by StÃ©phane Ducasse

thanks david for the pointer. Yes we should investigate that again. On Aug 18, 2010, at 3:20 AM, David T. Lewis wrote: > Probably completely off the mark but just in case it jogs someone's > memory, the fixes for this issue that went into Squeak 3.9 were > tracked on Mantis here: > > http://bugs.squeak.org/view.php?id=1041 > > Possibly one of the patches got undone by accident? > > HTH, > Dave > > > On Tue, Aug 17, 2010 at 10:28:31PM +0200, Adrian Lienhard wrote: >> I heard about that problem too... >> >> In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo. >> >> Has anybody an idea why this doesn't work anymore? >> >> Adrian >> >> On Aug 17, 2010, at 16:27 , Henrik Johansen wrote: >> >>> >>> 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 >>> _______________________________________________ >>> 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. 18, 2010

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

by Marcus Denker

On Aug 17, 2010, at 11:16 PM, Lukas Renggli wrote: > Or you would keep the empty but deprecated class > PluggableButtonMorphPlus in the image and make everybody happy :-) > Yes, let's do that... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 18, 2010

Re: [Pharo-project] HTML parser (again)

by laurent laffont

On Wed, Aug 18, 2010 at 7:50 AM, Andrei Stebakov <lispercat(a)gmail.com>wrote: > I've been looking for a nice and fast HTML parser. > I've found Zulq Alam's Soup > (http://www.squeaksource.com/@vHckXt8_6gVtXFxy/XMrjDbIs) it looks nice > but it's way too slow for me (takes 5 sec to parse the page, my > current lisp parser takes about 1 sec for that.) > I found another one, Todd Blanchard's HTML and CSS parser > (http://www.squeaksource.com/@iMgHmTKVxU00wEdz/A0jkqk71) but I > couldn't load it into Pharo 1.1 or Squeak 4.1. > It complains about some syntax error and leaves the progress bar which > I can't kill... > I wonder if anyone (Todd?) can take a look at the parser and figure > out how to fix it? > > What other options I have for an HTML parser? > Looking at Pharo speed I wonder if there is any way to optimize it? Is > JIT or some other speed optimization in plans for Pharo/Squeak? > What do you need to do ? There's XMLSupport http://www.squeaksource.com/XMLSupport.html Scamper might have a standalone HTML parser http://www.squeaksource.com/Scamper.html The CogVM has JIT. Laurent. > > Thank you, > Andrei > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 18, 2010

Re: [Pharo-project] We want your photo

by laurent laffont

Added Oscar. Laurent On Tue, Aug 17, 2010 at 1:10 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > 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. 18, 2010