Safarà Development Status

Hi Squeakers, few news about the Safarà development status.

Portability

Safarà now runs on Pharo
With few changes, the main features of Safarà runs on Pharo, which, here on, will be the main platform of development. The only issue, I will tackle, in maintaining Safarà working both on Squeak and on Pharo is about the Parser class as I previously used the Parser2 class for editing Smalltalk code.


Stability

As we need to refactor some internal part of Safarà to improve the speed, I worked a lot on adding more unit tests. They are really useful to check that refactorings do not introduce new bugs and to find with the profiler the bottlenecks of the system.


We got the 92% of code coverage of the Safarà-Core category by running all the tests in Safarà-Core-Tests (98 tests). The remaining 8% is mainly about methods of abstract classes (question: is there a way to make Test Runner Coverage analysis ignore an abstract class?) and some basic accessors. This part can be improved further as some tests do not test some behaviors at boundaries, but, actually, they already give me a good warranty when refactoring.


Code Quality
A big effort has been also put in refactoring the code (both of the implementation and the tests) to make the code critics tool "happy". At the moment we have only two problems, related to the main object SAEditor which have too many variables (14) and too many methods (64).


I tried to group variables in new objects: a MarkManager (4 of them), an UIManager (3 of them), CommandManager (2 of them), but I was not satisfied with this solution, too much complicated.
Furthermore, objects that should use the SAEditor accessors with statements like
editor markManager cursorsAtPoint size = 1 fails the Demeter Law.

I do not know if I should mind about the problem of having too many methods, as the SAEditor object should be the only object exposed to the GUI. The GUI communicates with the model through the Command pattern, and a lot of other communications are implemented with Announcements, but queries about the editor internal state is mainly done with traditional methods sending.
Thus, the number of methods for cursor/range/marker querying is big. For the same reason stated above I do not find useful to use an other solution.
In facts, we can have a clear design just by partitioning methods into categories.

Next steps
Here on, we can work on improving performance of Safarà. The problems resides mainly in the Morphic part.
For the model part, the task is not so difficult as I individuated, thanks to the Profiler, the bottlenecks.
For the UI part, I started also to look at Sophie, who use a complete different drawing scheme. It should not be difficult to rewrite the SASafaraMorph in the same way. More in the next posts.


Happy Hacking

Safara project: results, personal experience and future directions

Hi Squeakers,

The Google Summer of Code period is over and I'd like to spend some words about the project I was involved in, Safara, a text editor for Squeak . The results obtained (from a project and a personal perspective) and what we still need to do is the gist of the post. If you are interested in knowing what Safara is look at squeak-source or in the blog archive.

Results

First the bad news: Safara is not ready to use yet. It needs more
major features (like undo, completion, search/replace, templates) and
it should be a little bit faster (though some steps in that direction
has been already made). Safara is a big and ambitious project so I
expected this situation.

Then the good one: Safara is extensible and easily portable, so the
main goal of the Summer of Code project has been achieved. I am quite
satisfied about the design decision we took. Also the code quality
should be quite good as stated by SLint.

My first true Smalltalk Experience

Safara was the first (real) Smalltalk project I was involved in.
Actually I decided to join the Summer of Code with the Squeak Org.
because I needed an opportunity to improve my Smalltalk skills. You
can never learn a language without writing a big (roughly in terms of
number of lines of code) software. Playing with morphic toy examples,
developing little seaside apps or just copying some examples from a
book can be enough to learn the language and some good code styling
convention but not to really understand how the language can help you
in modeling the problem you want to solve. IMHO.

After three months of full time development with Squeak Smalltalk I
changed my mind about Smalltalk, and maybe Smalltalk changed a little
bit my mind about programming. Maybe now I am a better programmer also
when I develop with another object oriented language.
I was impressed by two aspects.

Smalltalk snippets of code, intended as the real lines of code you
write, are really simple and clear. The consequence is that when you
develop in Smalltalk you put your focus more on the whole design of
the software, and less on the single line of code.

Again, as the syntax rules are simple and the whole environment is
object oriented you have really powerful tools that helps you to code,
as the linter and the refactoring tools.

I also appreaciated the image-based style of development but I was
already used to it, so I got less surprises and I just enjoy my self
playing with inspectors and debuggers, modifying my application when
It is live and running.

Next steps

I have a short to-do list, whose outline follows. We need to run a code
coverage analysis, and write more tests to fix some bugs (mainly
related to command extensions and text presentation). We also need to
refactor the context menu (the one usually triggered by a right
click), in order to allow extensions like completion, spell checking
and so on.

I am still working on Safara but obviously putting less effort than in
the Summer of Code period, as I'd like to bring a new editor to the
Squeak community, or at least an alpha version before Christmas. I
don't want to release too early as I think it can be a bad advertising
for the whole project. After the first release It will be important to
create a community around Safara, with a website, a bug/issue tracker
and so on. At the moment the development mailing list is enough.

So if you are interested in the Safara project stay tuned and look at
the squeak-dev and the squeak-announcements mailing list.

Safarà Status

A first prototype of Safarà is ready at last.

Currently it supports basic ascii text editing, that can seem not so much.

Actually I am really happy for the work done as I think (and I hope) I met several goals:

1. extensibility in terms of features: you can add features (commands gestures syntaxes) to Safarà at runtime, without interfering or having to interact with other layers;
   
2. portability over implementations: the model does not know anything about the UI as they are completely decoupled and communication between them occurs by using announcements. Thus, you can write also a non-morphic UI for example. Just make your UI objects subscribe to the right announce and write a bridge to translate the GUI-dependent events to the Safarà events;
3. Classes and methods are well categorized, documented and tested.
   

So, what are the next steps?

For the Morphic UI: Do not use TextMorph as base class but a custom morph

For the model: Integrate into Safarà some code wrote by Lukas for syntax-aware commands

You can find the latest snapshot here. There is also a developer mailing list, you can subscribe to. As Safarà partecipate to the ESUG 2008 awards you can find additional documentation about the project goals and design here.

For the most curious, this is a snapshot