Aaah, the pain or ParagraphEditor refactoring ;-)

> 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

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Feb 26, 2009, at 7:00 PM, Lukas Renggli wrote:

>>>> Just for information, couldn't Safaràa be introduced here ?
>>>
>>> Safarà is not useable yet. It is too slow :-(
>>
>> So is it killed by over-engineering or over flexibility?
>
> Writing an editor is not trivial.

I did not mean it was.
I just wanted to know.

Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/2/26 Lukas Renggli <[hidden email]>:
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!



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli wrote:
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

do you think that this is a matter of running a profiler or that there  
is something
consuming too much messages (double dispatch or something like that?)
Do you know if its author would like to continue in a SummerTalk or  
related?

Stef

On Feb 26, 2009, at 8:33 PM, Lukas Renggli wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On
> 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.


Excellent! Lukas can you make sure that the follow up project will be  
part of the GSOC
topics. Else we could have a Summertalk as fallback.
ESUG wants projects that have real use for the community (since this  
was not the case with
some previous projects).



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> Can you explain where the performance problems are in your approach?

At the current state, the problem are the followings:

Safarà Commands, the user can invoke (e.g. uppercase words, insert char, paste, browse methods, etc.), act on meaningful pieces (ranges) of texts (words, characters, regions, smalltalk parsed expressions, etc.). At every command invokation, parsers rebuild the range database.
That is fine and done right, except that in some cases I could use better algorithm (as Lukas said, first make it work, then make it fast) as a lot of simple commands has often only a local effect on the text range database, then not a full rebuild is really needed.

Text is presented with different visual properties (foreground colors, underline, right font, etc.), depending on its meaning (syntax highlighting, and more). At a first stage Safarà drew character x character, but it was too slow.

The problem is that the meaning of the text is stored into ranges that are overlapping, instead I need runs (non overlapping ranges of text) in order to present the text. So I have to implement an algorithm that rebuild and perhaps cache better the run database. I have never really completed to do that, as I stopped to work on it. The work at squeaksource about runs was coded in a sprint made at the last ESUG)

Second problem: perhaps it is a bad idea to parse the whole content of the buffer at each command invokation, i.e. user input. Parsing/SyntaxHighLighting stuff should be processed in background.

>> And how do you define "too slow"?

Too slow to convince me to use it to code Safarà itself.

It hangs your pc for few seconds on long texts (> 10 lines) on each insertion.

All this feedbacks/rumors about Safarà is really motivating for me. I hope to go back working on it to make it usable. I am quite confident that I can do it and I d like to do that before the summer.

Luigi Panzeri

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Luigi PAnzeri wrote:

> The problem is that the meaning of the text is stored into ranges that are
> overlapping, instead I need runs (non overlapping ranges of text) in order
> to present the text. So I have to implement an algorithm that rebuild and
> perhaps cache better the run database. I have never really completed to do
> that, as I stopped to work on it. The work at squeaksource about runs was
> coded in a sprint made at the last ESUG)

A lot of the features and problems you describe we also encountered and
(partially) solved in the Sophie text rendering. We are also using
ranges (called markers in Sophie) which allow to add layers on top of
the underlying content.
We avoided some of the problems you describe by dealing with edits and
rendering in a multi stage process.

First the edits manipulate the text structure (a tree of sections and
text runs) and updating marker ranges in the process. Marker update is
pretty efficient as it only involves adjusting a few offsets.

Then a display structure/list is generated while applying any style
transformations added by the markers affecting the text. Overlapping
markers a split into runs during the compositing process, also a very
efficient process.

At last the display list is rendered.

Some operations like cursor movement and selections can be handled
without going through the above steps, simply by overlaying them on the
display structure.

But, it only took us three years to get there and there is still a lot
to be improved. On the other hand Sophie text also deals with embedded
images, links, trigger overlays etc, so it is a fairly complex system
overall. But imagine being able to embed images, audio or video into
method source/comments :-) OK, theoretically ParagraphEditor can do that
to, but you don't want to know ;-)

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/2/28 Luigi PAnzeri <[hidden email]>: A better would be to use a tokenized view on edit buffer, where each
token has its range.
When user edits a text, first you detect which token is affected, then
rescan it, and rescan next tokens until you find that rest of text is
matching previously parsed tokens.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project