- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SocketStream enh

by Noury Bouraqadi

On 18 aoÃ»t 2010, at 12:56, StÃ©phane Ducasse wrote: > >>>>> 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? > I tested the referenced code and it fixes issue 2765 (SocketStreamTest hangs). I put a detailed comment on GoogleCode. Noury

Aug. 18, 2010

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

by Henrik Johansen

I've submitted a slice to inbox, which contains a proposed fix. Details in the issue (2825) for those interested. Cheers, Henry On Aug 18, 2010, at 9:25 52AM, StÃ©phane Ducasse wrote: > 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 > > > _______________________________________________ > 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] test

by Fernando olivero

Aug. 18, 2010

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

by Fernando olivero

There are some tests and class side examples. Still missing a good tutorial. We could work on that together at ESUG. Fernando Fernando On Aug 18, 2010, at 2:02 PM, Lukas Renggli wrote: > On 18 August 2010 13:09, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >> 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. > > Is there any documentation/blog/tutorial that explains how to use the > NewTextMorph. > > I would like to integrate it with OmniBrowser at some point. > > Lukas > > >> >> 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 >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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] why TextMorph and PluggableTextMorph are not

by Lukas Renggli

On 18 August 2010 13:09, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > 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. Is there any documentation/blog/tutorial that explains how to use the NewTextMorph. I would like to integrate it with OmniBrowser at some point. Lukas > > 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 > > > _______________________________________________ > 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. 18, 2010

Re: [Pharo-project] SocketStream enh

by Philippe Marschall

On 08/18/2010 12:56 PM, StÃ©phane Ducasse wrote: > >>>>> 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? Sorry, didn't yet have time. Cheers Philippe

Aug. 18, 2010

Re: [Pharo-project] TextEditor>>possiblyChanged broke TextEditor quite well :(

by StÃ©phane Ducasse

good news. So I will do it. On Aug 18, 2010, at 1:11 PM, Fernando olivero wrote: > This method is used when installing an new editor on a TextMorph, and resusing the state of the previous one ( for example: selection interval). > > Currently we are just creating a new one, so YES, we could remove all senders. > > Fernando. > > On Aug 17, 2010, at 11:25 PM, StÃ©phane Ducasse wrote: > >> >>> >>> From: stephane ducasse <stephane.ducasse(a)gmail.com> >>> Date: August 17, 2010 10:46:05 PM GMT+02:00 >>> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >>> Subject: TextEditor>>possiblyChanged broke TextEditor quite well :( >>> >>> >>> Hi fernando >>> >>> apparently in TextEditor>>stateArrayPut: stateArray there is call to possiblyChanged which does not exist in pharo or Squeak >>> >>> TextEditor>>stateArrayPut: stateArray >>> | sel | >>> sel := stateArray at: 1. >>> self selectFrom: sel first to: sel last. >>> beginTypeInBlock := stateArray at: 2. >>> emphasisHere := stateArray at: 3. >>> morph possiblyChanged >>> >>> And this breaks the system when I try to integrate the ParagraphEditro replacement.... lost laready a couple of hours >>> >>> In CUIS it is defined as >>> >>> >>> PluggableTextMorph>>possiblyChanged >>> "A hook for notificating possible interested parties >>> Not used in base system" >>> >>> >>> TextMorph>>possiblyChanged >>> >>> TextMorphForEditView>>possiblyChanged >>> editView possiblyChanged >>> >>> >>> So? >>> Do we need that? if not we should remove all the senders >>> Stef >>> >>> >>> >>> >>> >>> >>> >> >> <ATT00001..txt> > > _______________________________________________ > 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] why TextMorph and PluggableTextMorph are not

by StÃ©phane Ducasse

Yes! > 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 > > > _______________________________________________ > 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] About porting and using the classificationModel in Pharo

by StÃ©phane Ducasse

On Aug 18, 2010, at 1:08 PM, Fernando olivero wrote: > 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? Yes > > http://map.squeak.org/package/9187f67b-a437-4e52-93f9-eecb9b48df78 > > > Thanks > Fernando > _______________________________________________ > 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] TextEditor>>possiblyChanged broke TextEditor quite well :(

by Fernando olivero

This method is used when installing an new editor on a TextMorph, and resusing the state of the previous one ( for example: selection interval). Currently we are just creating a new one, so YES, we could remove all senders. Fernando. On Aug 17, 2010, at 11:25 PM, StÃ©phane Ducasse wrote: > >> >> From: stephane ducasse <stephane.ducasse(a)gmail.com> >> Date: August 17, 2010 10:46:05 PM GMT+02:00 >> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >> Subject: TextEditor>>possiblyChanged broke TextEditor quite well :( >> >> >> Hi fernando >> >> apparently in TextEditor>>stateArrayPut: stateArray there is call to possiblyChanged which does not exist in pharo or Squeak >> >> TextEditor>>stateArrayPut: stateArray >> | sel | >> sel := stateArray at: 1. >> self selectFrom: sel first to: sel last. >> beginTypeInBlock := stateArray at: 2. >> emphasisHere := stateArray at: 3. >> morph possiblyChanged >> >> And this breaks the system when I try to integrate the ParagraphEditro replacement.... lost laready a couple of hours >> >> In CUIS it is defined as >> >> >> PluggableTextMorph>>possiblyChanged >> "A hook for notificating possible interested parties >> Not used in base system" >> >> >> TextMorph>>possiblyChanged >> >> TextMorphForEditView>>possiblyChanged >> editView possiblyChanged >> >> >> So? >> Do we need that? if not we should remove all the senders >> Stef >> >> >> >> >> >> >> > > <ATT00001..txt>

Aug. 18, 2010