Release of Monticello 2

Last week, I made refinements to Monticello 2 to build a release. Amongst them:

• intelligent naming of generated files
• 2 loading problems corrected
• more automatic refresh of the browser
• the browser is registered in the open... menu
• new actions in the browser

Then, I announced the release on squeak-dev. However, I didn't get any feedback, nor comments...

I'm still waiting for 5 answers from Colin and Avi. This lack of help from both of them prevents me from going much further. I would also like comments from the community.

This week my mentor Stéphane Ducasse is visiting me. We will discuss about how I should continue.

DomView Weekly Report

I have just finished the Acid1 test page renderer.
I am really happy to complete this step. Last little details are now correctly displayed: Radio buttons and irregular borders (I am not sure that the border draw method is the finale one).

Here the screenshot ( Click on it for the real size ).

The css loading algorithm proved to be useless. You could go on my blog for more explanations.
This week I will work on html tables. First I will have to think of an effective manner for their render.

NewCompiler repport #8

Last week I have looked at VMMaker.
VMMaker is a tool that let you write the interpreter of Squeak.
VMMaker is written in Squeak. So you can read slang(a subset of smalltalk) to understand how the VM work.
Slang are translated to C that is part of the VM code source.

I have implemented some primitive to make BlockClosure faster.
In Squeak primitives are special methods that are built inside the VM.
To specify a primitive you have to use the pragma #primitive:

Take a look at SmallInteger>>+
If you have VMMaker loaded inside the image you can see what the VM dose.
The corresponding method of SmallInteger>>+ is Interpreter>>primitiveAdd.
So when the message #+ is sent to an integer the VM call the subroutine primitiveAdd.

Most of the time Slang only call ObjectMemmory and Interprete methods.
The both classes represent the internal state of the VM. They also manipulate reify contexts.

For optimizing the BlockClosure I have implemented 2 primitive one for #value and one for either #value: or #value:value:…
Now the performance of the closure are closed to the old block.

I have also discussed with Marcus Denker to know which bytecodes should be implemented. We finally agreed on 3 bytecodes:

- creating the ClosureEnvironment(CE)
- store in the CE
- push in the CE

A part from VMMaker I also contnue fixing the decompiler for closure.
Especially for scope and captured variable.

Still, the decompiler for old block is finish and ready to use

OWRTA #10

DUH! Finally I've finished this horizontal rule which helped me to find some errors in code. So... new tags are available: line break (\\) and Horizontal Rule (----). Check this out. Feel free to edit it now! Paragraph bug is was fixed too ;)

OWRTA #9

Tonight I've modified Piers wikiWriter's class copy so now everybody can edit-save-edit in Creole syntax (not so many tags for now). There was ability to edit-save in Creole before. After next edit - all markup was shown in Pier. Check how it works here

Seaside and Sails first report

Hi there!
I just finished Proof-of-Concept blog example. It accessible at http://www.squeaksource.com/SeasideAndSails/ now.

Two words about Sails: it's an add-on to Seaside for fast generation of web application from Domain Model or Relational Model - ready-to use prototype with automatic storing in RDB or/and in OODB. You can read more at Giovanni Corriga's intro, at Sails wiki page or you can look at Sails Tutorial .

This Proof-of-Concept is reincarnation of famous Blog at 15 min video , mutated in "Blog in 5 minute" now. All you need is your Domain Model, described by magritte's describers. Then you just tell #generate to Sails - and your ready and even registered blog appear.

OWRTA #8

Ok. It seems that simple bold-italic nesting works fine for now.

OWRTA #7

Sorry that I'm late. I've just finished paragraph-by-paragraph Creole parsing implementation and implemented multi-line syntax support.

So this construction:


will become:


and parsed tree is:


This week I will continue to implement other syntax parts and then I will implement wikiWriter to write back correct syntax in TextArea. Also I think I will not go to the ESUG, because there is only 5 weeks to complete my tasks, so I prefer to stick with my current tasks (ESUG organisators! Please, don't kill me). I will notify them today.

Message histogram

A byproduct of today's work is a simple histogram that shows Croquet messages received by a computer. To try it out,

1. Load SocRecording-bvs.7 from the "SocRecording" Monticello repository at http://www.squeaksource.com/SocRecording.
   
2. Open the Croquet(Master) demo somewhere on your network.
   
3. Do "CroquetMessageHistogramMorph new openInHand" in a Workspace.
   

OmniBrowser based UI for Monticello2

This week, I've decided to stop working with ToolBuilder to mock up the graphical interface. As I have some knowledge about OmniBrowser, I chose OB to test ideas.

This revealed to be a really good idea. I don't loose time with low abstractions anymore. OmniBrowser provides me all the necessary abstractions and I can concentrate on the model and the features.

To present my work, I have built a screencast:
http://damien.cassou.free.fr/monticello2/monticello2.ogg

This is encoded in Ogg/Theora which is a free open-source encoding. If you are on Linux, you should be able to play this video without problem. On MacOS, Damien Pollet told me to advertise Perian. I don't know for MS Windows users, but it should be easy.

During the current week, I will continue working on the UI. As soon as I have something ready to use by everyone, I will post an announce on the squeak-dev mailing list.

I have some problems with the MC2 model. I've sent mails to the mailing list but, currently, they prevent me from going much further without answers from Colin and/or Avi.

DomView Weekly Report

My last week was focused on the ACID1 test page.

I still have some problems with the CSS loading algorithm that is why the render is not perfect.
Here a screenshot:

Next week, I will complete this task - I have to:

• Resolve the css loading problem


• Make links clickable


• Display forms elements (here radio buttons)


• Resolve the in line element placement

Weekly update

I have of course done many weekly updates in private, but this is my first post (!) to this blog, so I will give some background as well.

My name is Benjamin Schroeder; I am working on recording Squeak programming sessions for later playback, using Croquet as a foundation. The plan is to start with 2D, rather than trying to figure out appropriate browser/workspace/inspector UIs for use in a 3D Croquet world.

So far, I have had some success recording and playing back simple Croquet interaction sequences, using the standard 3D Croquet simple demo island. There is another recording project at Minnesota; it takes a slightly different approach, but I may switch to using their code at some point if it is publicly available.

The standard Croquet interaction paradigm is 3D. There are 2D "embedded apps", but it is not clear whether these are properly replicated (and hence recordable) or not. Recently, I have been working on replicating simple 2D worlds using Croquet. To that end, I have been stripping down the Croquet "harness" object to reduce its reliance on OpenGL. The act of stripping parts out, while keeping very basic functionality working, has helped me understand more about what happens during a Croquet session.

I now understand how to replicate a single Morph, headless, across a network. I think my next step is to display the Morph inside an owner that converts mouse events to "future" sends, and then to try more complicated morphs. I am told that Tweak works better than Morphic with the synchronization mechanisms used during Croquet replication, and so I will likely switch to Tweak at some point. I have been learning a little about Tweak, but still have much to understand.

New guests from ESUG's SummerTalk projects

SummerTalk is a project sponsored by ESUG similar to Google Summer of Code. While the latter focuses on Open Source projects and is programming-languages agnostic, the former focuses on Smalltalk projects (while keeping the requirements for the work to be under an open-source license).

We've decided to invite the SummerTalk partecipants who are working on Squeak-related projects to join this blog as guest authors. These new guests are Juraj Kubelka, who's working on improving the OmniBrowser framework, and Yuriy Mironenko, who's working on an add-on to Seaside called Sails.

Welcome, guys!

NewCompiler week #5 repport

Until the last week, I was fixing some tests for the decompiler. This week, I am starting to decompile the complete image.
To do that, I take a method compiled with the NewCompiler. I decompile it to an AST and recompile it to a CompiledMethod, then I reinstall the method inside the class.

It is necessary to take a method compiled with the NewCompiler because the NewCompiler does some optimization that the decompiler know.

I do this for all the methods in the image.
This helps to find a lot of bug.
At the beginning I had 37 tests now I have 71 tests.
The decompiler still don't work but only for a few methods.

This week I will finish to fix the decompiler(for the old block).
I also need to decompile with the block closure.
The next things to do will be to implement a primitive for BlockClosure>>value and more generally work on performance.

DomView report

I always worked on clear/box/float displaying. Todd gave me a very usefull link:
a W3C's test page. My objective is to displayed this web page. Its code contains a lot of accepted cases. First I have to obtains the good boxes placement. Next, I will have to
work on colors, borders/paddings/margins - those properties could be specified by several ways.

Currently this test page is not correctly displayed, but I have a start. I am changing my CSS loading algorithm in order to compute size in pixels during this loading. For example: #foo{width:10%}. The css value will be change by the pixel value during the css loading algorithm. Before, values were unchanged - the value was computed in the getter. I will explain this new way advantages in the domView documentation.

OWRTA #6

OK. Sorry guys, but previous problem with PRParagraphs wasn't so simple as I thought. But it's ok now. It works, both pier and creole syntax switches can be used right now in PRMyMultiPage-s. I've integrated switching mechanism deeper than in previous version. Now it works on the PR*Parser->parseText level and doesn't make any PRParagraphs at every syntax switch. Also I've removed PreParser and its structure at all... I believe that this will not be needed anymore. Theoretically there is better performance for now (better than with PreParser at least). Also there is a simple/dummy visiting modification to view/edit modified Document structure with new PR*Syntax structures. It needs to be modified in future. On this week I'm planning to implement Creole syntax.

If you want you can test my multi page at http://kamikaze.seasidehosting.st/ (services->Multi-Syntax testing)

DomView

Last week, I worked on blocks placements: a difficult problem...There are always bugs with 'float' and 'clear' elements.
Images are now correctly displayed (with their good dimensions). This week, i will continue my work on element placement.

Monticello 2 graphical interface

Last week, I've worked on the graphical interface. Colin and Avi had made some experiments but it wasn't really usable. With the new GUI, the user is able to save any package he wants. I'm currently working on the 'loading' part of the GUI.

As soon as I have something basically working, I will make things easy and announce on the mailing list. People will then be able to start playing with Monticello 2.

Next week I won't be able to work on the Google Summer of Code because I'll present Smalltalk, Squeak and Seaside at RMLL/LSM 2007.

OWRTA report

I've finally got a parsed tree with all syntax switches needed. Maybe it's not a perfect algorithm but at least it works. The only problem with that tree is that there is a new paragraph at every syntax switch. When I'll fix that I will work on visitin+accessing stuff to get it working correctly.

Actually there are more frequent (when something is done) reports on my site. See a News section for them http://kamikaze.seasidehosting.st/

Correcting bugs, playing with the MC2 UI

Hi,

another Google SoC week has just finished. During this last week I corrected some bugs with the PackageInfo slice not verifying its content.

Monticello2 has a good test base. The tests are well designed and I will continue enhancing them.

I tried to implement a directory-based repository. I wanted it to be like in MC1. It basically worked, however one file was created for each element in the commit: one file per method, per class, per inst var… I will try again later :-).

I also had some discussions with Colin. Some of my design choices or ideas were not that good. I will continue discussing with him and Avi to avoid a big conflict at the end ; I would prefer their approval on my work.

Currently, I'm working on an MC1 kind of browser. I would like something people familiar with MC1 will be able to use easily.

I would like to announce as soon as possible a working version. I will work on that. This means:

1. A working UI, with basic features
2. Maybe creating a directory-based repository
   

I don't really know how much work is needed to get a basic working UI.