- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Text editing (was: Re: Aaah, the pain or ParagraphEditor refactoring)

by Lukas Renggli

> Can you explain where the performance problems are in your approach? > And how do you define "too slow"? Also see my other mail. As I said, we didn't optimize yet, we wanted to first get the model right. AFAIK it always redraws the complete editor even when only the cursor position changes. Text is drawn character by character, to be able to have sophisticated graphical annotations. It is usable for small methods, but noticeably slower than ParagraphEditor. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 27, 2009

Re: [Pharo-project] Some issues with Pharo-dev build #10243

by Damien Cassou

On Thu, Feb 26, 2009 at 10:07 PM, David RÃ¶thlisberger <squeak(a)webcitas.ch> wrote: > Just curious: Did you load this versions by hand? Because those versions of OB are > still alpha, so we have to expect dev-dev behavior in those. ;) pharo-dev is now based on #loadOBAlpha. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 27, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Lukas Renggli

> Lukas, can you make a more detailed overview,please, at what stage it > is, and why it too slow. > I wasn't aware it even exists! SafarÃ was one of the Google Summer of Code 2008 projects. Luigi Panzeri is the author of SafarÃ , I was mentoring him. I have it running in a 3.9 image together with OmniBrowser. 1. Load OB-Morphic-lr.45, OmniBrowser-lr.407 and OB-Standard-lr.323 from http://source.wiresong.ca/ob/. 2. Load RoelTyper-rw.60, Shout-lr.2, ECompletion-lr.93 and ECompletionOmniBrowser-dc.4 from http://source.lukas-renggli.ch/unsorted. 3. Load Safara-Core.LPM.16, Safara-Morphic-LPM.16 and Safara-Extensions-LPM.11 from http://www.squeaksource.com/Safara. 4. Execute SAMorphicPlatform install to use SafarÃ instead of the default ParagraphEditor. For small code snippets basic editing works reasonably well. For larger texts (more than a screen) redrawing is extremely slow (due to the fact that formatting is stored in ordered collections). Our goal was to first make it work, before optimizing. The code itself is solid and there are a couple of test cases. Some parts certainly require some refactoring to make them more extensible and easier to use. As you can see in the demo, the basic functionality such as text editing, text selection, syntax highlighting and contextual menus are there. Luigi was one of the best students I ever worked with. He worked very hard on SafarÃ and I am impressed by the result, especially given that he was relatively new to Smalltalk and Squeak when the project started. He has a strong background in Lisp and Emacs and therefore has good knowledge on the workings of an editor. I heard that he is interested to continue working on SafarÃ this summer. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Philippe Marschall

Michael Rueger wrote: > Philippe Marschall wrote: > >>> There is actually on more method (attached) that we need to add to >>> either Kom or Seaside to make Pharo and Squeak compatible on the API level. >> Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm.583 >> for what I would find acceptable. > > OK, can you explain how I should make Seaside work on both Pharo and > Squeak? I spent two days figuring out a minimal set of changes that > would not require doing some ugly hack testing for which underlying > platform you are dealing with and you say that is not acceptable? You > *want* ugly hacks? I don't understand... - Monkey patching either Seaside or Kom is not acceptable. We have this issue partially because Kom is monkey patching Squeak. - Forking Seaside for Pharo is not acceptable. - Relying on a forked Kom is not acceptable, we need to have a consistent interface for Kom in both Squeak an Pharo. That kinda limits our options. Second the fix is not that ugly. It just sends #asString to something it expects to be a String. This is not a that uncommon idiom. And we already have to do something way uglier for ensuring author initials. That's what happens if you break the API. You brake a lot of code and cause a lot of pain for a lot of people. Cheers Philippe

Feb. 27, 2009

[Pharo-project] Text editing (was: Re: Aaah, the pain or ParagraphEditor refactoring)

by Michael Rueger

Lukas Renggli wrote: >> Is there anything to look at though, just curious from a Sophie point of >> view how you approached the problem. > > Documentation: > > http://vst.ensm-douai.fr/Esug2008Media/uploads/1/safara-EsugAwards2008.pdf > > Implementation (a lot of work will be required): > > http://www.squeaksource.com/Safara.html Interesting! Quite a few of the concepts can be found in Sophie too (a bit different, but nonetheless), so there seems to be some merit to those :-) Can you explain where the performance problems are in your approach? And how do you define "too slow"? MIchael

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Michael Rueger

Philippe Marschall wrote: >> There is actually on more method (attached) that we need to add to >> either Kom or Seaside to make Pharo and Squeak compatible on the API level. > > Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm.583 > for what I would find acceptable. OK, can you explain how I should make Seaside work on both Pharo and Squeak? I spent two days figuring out a minimal set of changes that would not require doing some ugly hack testing for which underlying platform you are dealing with and you say that is not acceptable? You *want* ugly hacks? I don't understand... I'm not even touching seaside (except the one method rename/addition for a method being called by Seaside). Michael

Feb. 27, 2009

Re: [Pharo-project] Guys please sign the license agreement so that

by Rob Rothwell

Ok...it may take a while to get there from the United States! Rob On Thu, Feb 26, 2009 at 6:19 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > we do not have problem in the future... > > http://pharo.gforge.inria.fr/licenseDocuments/ > > Thanks > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Igor Stasenko

2009/2/26 Lukas Renggli <renggli(a)gmail.com>: >> Is there anything to look at though, just curious from a Sophie point of >> view how you approached the problem. > > Documentation: > > Â http://vst.ensm-douai.fr/Esug2008Media/uploads/1/safara-EsugAwards2008.pdf > > Implementation (a lot of work will be required): > > Â http://www.squeaksource.com/Safara.html > Lukas, can you make a more detailed overview,please, at what stage it is, and why it too slow. I wasn't aware it even exists! > Lukas > > -- > Lukas Renggli > http://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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 26, 2009

Re: [Pharo-project] lisencing

by John M McIntosh

>> Hi, >> I just saw the list of pending packages for pharo-dev and I noted >> that >> there is a package made by me (OB-Algernon), it is a little package >> with few changes to algernon... I if I might make a suggestion, in my left hand I have a database of names and initials of people who have signed up, in the right some code that looks at each method in the Pharo image, and tags any with a pragma if it can't figure out who owns it, or if the author isn't in the database. Run it before each release, post exceptions somewhere. Frankly any centralized initial, name registration going forward should capture an email address for later usage.... -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Feb. 26, 2009

Re: [Pharo-project] lisencing

by henrik.s.johansen＠veloxit.no

Speaking of which, I have a related question: The issues marked with "Check:", which are mostly Mantis bug fixes to Squeak, what's the procedure for those? 1. Use the code submitted as fixes as a starting point, and assume it's under a valid licence? 1a. If so, how do we submit as the contributer for unaltered methods the person who made the Squeak patch instead of the person checking it? 1b. For derived/removed/extended changes made by the checker, who do we tag as the change author? 2. Read the bug descriptions and make corresponding changes to Pharo? Cheers, Henry Siterer "Esteban Lorenzano" <estebanlm(a)gmail.com>: > Hi, > I just saw the list of pending packages for pharo-dev and I noted that > there is a package made by me (OB-Algernon), it is a little package > with few changes to algernon... but I have not signed the agreement > (because I thought that none of my codes was included in pharo) > So I ask: I have to sign the agreement? how? > (In any case, I want to sign the agreement "just in case" -that will > allow me to contribute to pharo, if I find the time-... is that > possible?) > > Cheers, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009