Saturday, September 22, 2007
OWRTA #14
Ordered and unordered lists are complete. The rest is links, image and placeholder. And of course syntax switcher and parser code merging.
Friday, September 7, 2007
OWRTA #13 report, the lucky one
I've made a new line break processing. It works well for paragraphs and horizontal rule right now! There is no any lost/new line break after "edit-save-edit" cycle. I will implement this for other tags tomorrow, gn.
Tuesday, August 21, 2007
NewCompiler repport
Last two weeks I worked on decompilation and optimization
For the decompilation I made some fixes for the closure decompiler.
Mainly fixes concern scope. Now I have a clear view of how variables are accessed.
This is not really what you can understand when you read the implementation. And I think we should concentrate to go in this direction.
So there is 3 different way to access a variable (I am talking only about temp and inst var).
- "Simple access": This is when we access a variable that is not captured.
The generated bytecodes are #pushTemp: offset, #storeTemp: offset , #pushInstVar: offset or #storeInstVar: offset.
Example:
| a |
a := 3.
[ | b | b:= 5 factorial.]
- "Captured access": This is when we have to access to a temp defined in the same scope that is captured by a block.
Example:
| a b |
a := 2. "A captured access"
b := 1. "An other captured access"
[a + [b] value ] value.
The compiler here needs to access to the ClosureEnvironment stored in the MethodContext:
pushConstant: 2
pushThisContext
pushConstant: 5
send: privGetInstVar:
pushConstant: 1
send: privStoreIn:instVar:
- "Far captured access": When we want to access to a variable which is in the parent scope
| a b |
a := 2.
b := 1.
[| c |
c := 3.
a + [b + c] value ] value. "Two different kind of Far captured access "
The right closure need to be pushed before we can access to the temp.
for the inst var a:
pushInstVar: 1 "since the receiver of the block is the closure environment"
for b:
pushInstVar: 0
pushConstant: 2
send: privGetInstVar: " Closure environment are chain by storing them in the first slot of the parent closure environment ".
Now to optimize the NewCompiler I have implemented 5 bytecodes.
- the first one is to push or store the closure environment:
pushThisContext
pushConstant:5
send: privGetInstVar:
will be replace by:
pushThisEnv
This bytecode is needed when you create the block. (Remember the receiver of the block is the closure environment)
I have also implemented the bytecode for the "captured access" and the far "captured access":
pushConstant: 2
pushThisContext
pushConstant: 5
send: privGetInstVar:
pushConstant: 1
send: privStoreIn:instVar:
is replaced by:
pushNestedClosure: 0 offset: 0
and:
pushInstVar: 0
pushConstant: 2
send: privGetInstVar:
by:
pushNestedClosure: 1 offset: 1
If you get confused with the value of the offset is normal.
In the image and more particularly for the message #privGetInstVar:, the instance variable are count starting from 1.
But in the VM the offset is count starting from 0.
The last bytecode concern the closure creation:
pushConstant: ClosureEnvironment
pushConstant: 1
send #mew:
replace by:
new closure: 1
I have made a small benchmark to see the performance:
[| a | a := 0. #(1 2 3 4 5 6 7 8 9 10) do: [:each | a := each + a].a halt] bench.
the result is:
For the new compiler:
'405 558 per second.'.
For the old closure and old compiler:
'567 088 per second.'.
Full closure performance is now quite close the the non full closure performance.
Some other benchmark is needed to confirm that result.
They is also some other optimization inside the bytecode and primitive to make closure faster.
At the end the new compiler could have similar performance to the old one.
For the decompilation I made some fixes for the closure decompiler.
Mainly fixes concern scope. Now I have a clear view of how variables are accessed.
This is not really what you can understand when you read the implementation. And I think we should concentrate to go in this direction.
So there is 3 different way to access a variable (I am talking only about temp and inst var).
- "Simple access": This is when we access a variable that is not captured.
The generated bytecodes are #pushTemp: offset, #storeTemp: offset , #pushInstVar: offset or #storeInstVar: offset.
Example:
| a |
a := 3.
[ | b | b:= 5 factorial.]
- "Captured access": This is when we have to access to a temp defined in the same scope that is captured by a block.
Example:
| a b |
a := 2. "A captured access"
b := 1. "An other captured access"
[a + [b] value ] value.
The compiler here needs to access to the ClosureEnvironment stored in the MethodContext:
pushConstant: 2
pushThisContext
pushConstant: 5
send: privGetInstVar:
pushConstant: 1
send: privStoreIn:instVar:
- "Far captured access": When we want to access to a variable which is in the parent scope
| a b |
a := 2.
b := 1.
[| c |
c := 3.
a + [b + c] value ] value. "Two different kind of Far captured access "
The right closure need to be pushed before we can access to the temp.
for the inst var a:
pushInstVar: 1 "since the receiver of the block is the closure environment"
for b:
pushInstVar: 0
pushConstant: 2
send: privGetInstVar: " Closure environment are chain by storing them in the first slot of the parent closure environment ".
Now to optimize the NewCompiler I have implemented 5 bytecodes.
- the first one is to push or store the closure environment:
pushThisContext
pushConstant:5
send: privGetInstVar:
will be replace by:
pushThisEnv
This bytecode is needed when you create the block. (Remember the receiver of the block is the closure environment)
I have also implemented the bytecode for the "captured access" and the far "captured access":
pushConstant: 2
pushThisContext
pushConstant: 5
send: privGetInstVar:
pushConstant: 1
send: privStoreIn:instVar:
is replaced by:
pushNestedClosure: 0 offset: 0
and:
pushInstVar: 0
pushConstant: 2
send: privGetInstVar:
by:
pushNestedClosure: 1 offset: 1
If you get confused with the value of the offset is normal.
In the image and more particularly for the message #privGetInstVar:, the instance variable are count starting from 1.
But in the VM the offset is count starting from 0.
The last bytecode concern the closure creation:
pushConstant: ClosureEnvironment
pushConstant: 1
send #mew:
replace by:
new closure: 1
I have made a small benchmark to see the performance:
[| a | a := 0. #(1 2 3 4 5 6 7 8 9 10) do: [:each | a := each + a].a halt] bench.
the result is:
For the new compiler:
'405 558 per second.'.
For the old closure and old compiler:
'567 088 per second.'.
Full closure performance is now quite close the the non full closure performance.
Some other benchmark is needed to confirm that result.
They is also some other optimization inside the bytecode and primitive to make closure faster.
At the end the new compiler could have similar performance to the old one.
Saturday, August 18, 2007
OWRTA #12
Hello. I've implemented headings and tables (without "=" as table haders for now.). I'm planning to finish tables and start implementing next tags. Remaining tags are: Links, Lists, Image, Placeholder and partly Escape character. Current status page with examples.
Wednesday, August 15, 2007
Having MC2 look like MC1
I'm currently working on making MC2 really look like MC1. This is what results from the discussion we had with my mentor when he visited me two weeks ago. My main goal is to have the same features as in MC1 to ease adoption, not more not less.
What have changed recently:
- I've implemented the 'Changes' feature. Changes are calculated but a tool must be built to display them.
- I've also implemented a browser for repositories. This is really like the Repository Browser in MC1.
- Some classes avoids the creation of equal instances (the slices, the slice stati...).
- Corrects a bug with the directory repository.
Here is a screenshot of the two MC2 browsers. When there are '?' around a button label, that means the feature is not yet implemented.
What I plan to do in future weeks:
- Finish the implementation of the 'Changes'
- Change the format of commits to contain textual information (a zip with the source code, the change comment, and the binary data that is already generated)
What have changed recently:
- I've implemented the 'Changes' feature. Changes are calculated but a tool must be built to display them.
- I've also implemented a browser for repositories. This is really like the Repository Browser in MC1.
- Some classes avoids the creation of equal instances (the slices, the slice stati...).
- Corrects a bug with the directory repository.
Here is a screenshot of the two MC2 browsers. When there are '?' around a button label, that means the feature is not yet implemented.
What I plan to do in future weeks:
- Finish the implementation of the 'Changes'
- Change the format of commits to contain textual information (a zip with the source code, the change comment, and the binary data that is already generated)
Monday, August 13, 2007
DomView
I worked on html tables last week. DomView is now able to display simple tables(with small bugs).
I have to display HEAD and FOOT nodes and manage colspans/rowspans - it will be my next week task.
If those milestones are reached, i will have to work on table borders and others table CSS attributes.
Tomorrow,I will add screenshots on my blog.
I have to display HEAD and FOOT nodes and manage colspans/rowspans - it will be my next week task.
If those milestones are reached, i will have to work on table borders and others table CSS attributes.
Tomorrow,I will add screenshots on my blog.
Monday, August 6, 2007
HTML Tables
Last week was devoted to Html tables renderer. I thought of an effective manner to display tables.
This one is not completed yet, but I have a start. I will have to adapt this method to be able to render complex tables (with rowspan or/and collspan attributes).
First, I wanted to use an existing package named SFC-Layout - Finally i am writing my own code.
I will continue this work during this next week - I hope that a pretty screenshot will be available next week :-) .
This one is not completed yet, but I have a start. I will have to adapt this method to be able to render complex tables (with rowspan or/and collspan attributes).
First, I wanted to use an existing package named SFC-Layout - Finally i am writing my own code.
I will continue this work during this next week - I hope that a pretty screenshot will be available next week :-) .
OWRTA #11
Ok. Finally I've got Preformatted tags working. That also helped me to find some bugs which I've fixed too. I'm going to implement next tags in this week. Also I'm planning to get a new image from Keithy so I could start next task in parallel. The only problem with Preformatted is that string: //yoyo{{{preformatted}}}yoyoyo// will be in italics at any position (preformatted too). I thought that this is a bug, but Creole sandbox shows the same result. Please visit my site at Services -> CreoleTest and feel free to edit that page. (**bold**, //italics//,{{{preformatted}}},---- and \\).
Tuesday, July 31, 2007
Release of Monticello 2
Last week, I made refinements to Monticello 2 to build a release. Amongst them:
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.
- 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
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.
Monday, July 30, 2007
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.
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
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
Saturday, July 28, 2007
Friday, July 27, 2007
Thursday, July 26, 2007
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.
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.
Monday, July 23, 2007
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.
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,
- Load SocRecording-bvs.7 from the "SocRecording" Monticello repository at http://www.squeaksource.com/SocRecording.
- Open the Croquet(Master) demo somewhere on your network.
- 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.
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:
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.
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.
Sunday, July 22, 2007
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!
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!
Monday, July 16, 2007
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.
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.
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.
Tuesday, July 10, 2007
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)
If you want you can test my multi page at http://kamikaze.seasidehosting.st/ (services->Multi-Syntax testing)
Monday, July 9, 2007
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.
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.
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.
Monday, July 2, 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/
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:
I don't really know how much work is needed to get a basic working UI.
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:
- A working UI, with basic features
- Maybe creating a directory-based repository
I don't really know how much work is needed to get a basic working UI.
Monday, June 25, 2007
Slowly understanding MC2 design
This week was my last week of internship. I will now start to work fully on MC2. However, I did find some time to enhance the wiki page. I added a page about the merging algorithm and another one about the base classes with a diagram in each page. I also played a bit with the code and find a way to save and load slices. Have a look at the very bottom of the wiki page.
Tuesday, June 19, 2007
Projects warming up
It looks like our students have started working on their projects for real, after having been busy with finals, defenses etc.
Jerome, even if busy with his finals, has worked on the CSS viewer, named DomView. He worked on the Box Model, and DomView can now display box containers, as shown in the image. During this week, Jerome will work on text styles.
Jerome is documenting his work at http://jeromechauveau.free.fr/soc2007/docs/.
Benjamin is working on a Croquet Controller that logs the messages it receives. He modified one of the built-in controllers to log the messages on the Transcript window, and is now working on a new, custom controller able to store the received messages. During this week he'll try to have his controller replay simple sequences of messages.
Damien has started working on Monticello2, and he wrote a report on his work here.
Oleg will be busy with his finals until today, Tuesday June 19th, and has promised that starting tomorrow he will work hard on his project.
Mathieu has been busy fixing bugs in the BlockClosure decompiler, and will keep working on it during this week. He's also working on integrating the new compiler subsystem with the Refactoring Engine.
Jerome, even if busy with his finals, has worked on the CSS viewer, named DomView. He worked on the Box Model, and DomView can now display box containers, as shown in the image. During this week, Jerome will work on text styles.Jerome is documenting his work at http://jeromechauveau.free.fr/soc2007/docs/.
Benjamin is working on a Croquet Controller that logs the messages it receives. He modified one of the built-in controllers to log the messages on the Transcript window, and is now working on a new, custom controller able to store the received messages. During this week he'll try to have his controller replay simple sequences of messages.
Damien has started working on Monticello2, and he wrote a report on his work here.
Oleg will be busy with his finals until today, Tuesday June 19th, and has promised that starting tomorrow he will work hard on his project.
Mathieu has been busy fixing bugs in the BlockClosure decompiler, and will keep working on it during this week. He's also working on integrating the new compiler subsystem with the Refactoring Engine.
Thursday, June 14, 2007
Start coding on Monticello 2
I've finally started working on Monticello 2, as part of the Google Summer of Code 2007.
Reading the source code of MC2, I found it well written and lots of unit-tests are presents. Colin and Avi are really good developers.
While reading, I refactored and cleaned the code. The resulting packages can be downloaded at http://www.squeaksource.com/Monticello2.
I've also updated the wiki page with links to documentation http://wiki.squeak.org/squeak/5624.
Playing a bit with the model interfaces, I didn't find a way to load a package previously saved in a file-based repository. It seems the method MDMemo>>getSnapshotFrom: is missing.
It's not clear whether Colin and Avi want to keep their "slicing" model. The "slicing" model is the possibility to store anything to a repository: a method, an instance variable, a class, a package... According to Avi, it seems it was a good idea, but it complicates things a lot. We will have to discuss about that particular problem.
What I plan to do in the following days is to continue reading and enhancing the source code, and find a way to load a slice from a repository.
Reading the source code of MC2, I found it well written and lots of unit-tests are presents. Colin and Avi are really good developers.
While reading, I refactored and cleaned the code. The resulting packages can be downloaded at http://www.squeaksource.com/Monticello2.
I've also updated the wiki page with links to documentation http://wiki.squeak.org/squeak/5624.
Playing a bit with the model interfaces, I didn't find a way to load a package previously saved in a file-based repository. It seems the method MDMemo>>getSnapshotFrom: is missing.
It's not clear whether Colin and Avi want to keep their "slicing" model. The "slicing" model is the possibility to store anything to a repository: a method, an instance variable, a class, a package... According to Avi, it seems it was a good idea, but it complicates things a lot. We will have to discuss about that particular problem.
What I plan to do in the following days is to continue reading and enhancing the source code, and find a way to load a slice from a repository.
Friday, June 8, 2007
Status Report
Hi all,
here's a quick report on the status of the five Summer of Code projects.:
- Oleg, Mathieu, Damien and Jerome have been busy with university work, so they couldn't do much work on their SoC projects.
- Benjamin spent the first SoC week exploring the Croquet system and reading its documentation. His plan for this week was to build a simple Controller that can log external Croquet messages sent to it, for later replay.
[My apologies if this message was posted so late, but my laptop died - yet again!]
here's a quick report on the status of the five Summer of Code projects.:
- Oleg, Mathieu, Damien and Jerome have been busy with university work, so they couldn't do much work on their SoC projects.
- Benjamin spent the first SoC week exploring the Croquet system and reading its documentation. His plan for this week was to build a simple Controller that can log external Croquet messages sent to it, for later replay.
[My apologies if this message was posted so late, but my laptop died - yet again!]
Wednesday, May 30, 2007
HTML/CSS Parser
If you want to have more informations about my GSOC project, please visit my blog at: jeromechauveau.free.fr/blogsoc...
Sunday, May 27, 2007
Working on Monticello 2
After some discussions with my mentor Stéphane Ducasse, I have decided to improve Monticello 2 (MC2) and make it usable to every squeaker as part of the Google Summer of Code.
I have started by opening a repository on SqueakSource on which I will be able to put my own work. It currently contains the last available versions of MC2 packages.
Then, I sent an email to the Squeak-dev mailing list requesting information about MC2: its design, its state... Colin Putney and Avi Bryant kindly answered, giving details.
I also found old posts on Colin's and Avi's blogs talking about MC2 design.
Finally, I've received a mail from Keith Hodges giving information about the current status of his work on Monticello and what I can do to improve MC2.
The next task I would like to achieve is opening a wiki page on the Squeak Swiki containing all information I can grab about MC2. This pages will also be used as a place for me to write new documentation.
Any feedback will be appreciated.
I have started by opening a repository on SqueakSource on which I will be able to put my own work. It currently contains the last available versions of MC2 packages.
Then, I sent an email to the Squeak-dev mailing list requesting information about MC2: its design, its state... Colin Putney and Avi Bryant kindly answered, giving details.
I also found old posts on Colin's and Avi's blogs talking about MC2 design.
Finally, I've received a mail from Keith Hodges giving information about the current status of his work on Monticello and what I can do to improve MC2.
The next task I would like to achieve is opening a wiki page on the Squeak Swiki containing all information I can grab about MC2. This pages will also be used as a place for me to write new documentation.
Any feedback will be appreciated.
Monday, May 21, 2007
Seven Days to GSoC start: looking forward and looking back
Next monday will mark the start of the Google Summer of Code 2007: from that day the students will officially start working on their projects (and getting paid, too). But since there's nothing forbidding them to start working earlier, I've just sent our five students an email asking whether they've done anything during this interim period and, in case, what they've done.
While we wait for them to reply, I'd like to look back for a moment to the selection process. Using an agile/XP term, we could call this a little retrospective.
So, what went well with our selection process? First of all, the fact that we had so many student proposal, and most of them came from students sincerely interested in working on/with Squeak, and not just in it for the money. The fact that we had to coordinate with many other GSoC projects in order to select our 5 students is another proff of the level of the students who applied for a Squeak project.
Another thing that I'd like to remark is the level of involvement of our mentors. They all took their job seriously, throughly examining and evaluating all the proposals. Kudos to them!
What could be improved? Personally, I felt that there was a little "creeping" in the mentor and proposal lists. We started with ~10 mentors and 12 proposals on our list, we ended up with 14 mentors and 18 proposals. Freezing the two lists a little earlier can make coordination a little easier.
I'd also like to have more people on the Squeak IRC channel during the whole proposal submission period. This way people coming into #squeak to ask for info will have more opportunities for a correct answer.
What could we experiment with? In the past weeks I was toying with the idea of a Squeak bounties system. If we'd manage to put this or a similar system in place during the autumn, we could also use it for gathering proposals for next year's Summer of Code.
Also, for next year's Summer of Code it would be worth considering positioning Squeak as an umbrella project, managing proposals involving the main Squeak system, Seaside, Squeakland, Sophie, Croquet etc.
These are some of the points I wanted to make. Do you have any comments or any more points to add to the discussion? if so, then the comment form is waiting you!
While we wait for them to reply, I'd like to look back for a moment to the selection process. Using an agile/XP term, we could call this a little retrospective.
So, what went well with our selection process? First of all, the fact that we had so many student proposal, and most of them came from students sincerely interested in working on/with Squeak, and not just in it for the money. The fact that we had to coordinate with many other GSoC projects in order to select our 5 students is another proff of the level of the students who applied for a Squeak project.
Another thing that I'd like to remark is the level of involvement of our mentors. They all took their job seriously, throughly examining and evaluating all the proposals. Kudos to them!
What could be improved? Personally, I felt that there was a little "creeping" in the mentor and proposal lists. We started with ~10 mentors and 12 proposals on our list, we ended up with 14 mentors and 18 proposals. Freezing the two lists a little earlier can make coordination a little easier.
I'd also like to have more people on the Squeak IRC channel during the whole proposal submission period. This way people coming into #squeak to ask for info will have more opportunities for a correct answer.
What could we experiment with? In the past weeks I was toying with the idea of a Squeak bounties system. If we'd manage to put this or a similar system in place during the autumn, we could also use it for gathering proposals for next year's Summer of Code.
Also, for next year's Summer of Code it would be worth considering positioning Squeak as an umbrella project, managing proposals involving the main Squeak system, Seaside, Squeakland, Sophie, Croquet etc.
These are some of the points I wanted to make. Do you have any comments or any more points to add to the discussion? if so, then the comment form is waiting you!
Monday, May 14, 2007
How to load the NewCompiler
Hi everyone,
I juste want to add a litle tip about how to load the NewCompiler so here is the basic tree dependency:
So in oder to load the NewCompiler you have to fulfill the dependency. You can find them all in Squeaksource.
The next post I will show you how to write bytecode easily.
Let comments if you find it interesting or if you want any tips about the NewCompiler.
I juste want to add a litle tip about how to load the NewCompiler so here is the basic tree dependency:
So in oder to load the NewCompiler you have to fulfill the dependency. You can find them all in Squeaksource.
The next post I will show you how to write bytecode easily.
Let comments if you find it interesting or if you want any tips about the NewCompiler.
Thursday, May 3, 2007
NewCompiler ToDo
This last 3 days I have met Marcus at Bern and we discuss about things to do and the way of doing them.
Then here the work to be done:
- The more important things: make the decompiler work so we can propose it to the 3.10/3.11 release team.
- Have 2 parser so we can work on one without breaking it all
- Remove the reference to the RBParser and RBToken
- Clean the interface of the RBNode
- Integrate the continuations from Seaside
- Make debug it work in the debugger
- Profile the compiler to optimize it.
- Create some visitor to have the AST annotations and remove the token
- Work on the VM and new bytecodes/primitives
- ...
Up to now I have look at VMMaker and implement some bytecodes the improve the performance of the method with closures by 6. Those bytecode are experimental and we should propose some more efficient.
We have also change the organization of the NewCompiler. So now we have 3 packages:
- AST: Package for the RBNode and RBToken (which should be removed)
- NewParser: Package containing the parser so you can use it for your purpose without loading the complete compiler. We make this package mostly to make the RefactoringEngine using the SqueakParser so we can remove the RBParser.
- NewCompiler: The closure compiler
Then here the work to be done:
- The more important things: make the decompiler work so we can propose it to the 3.10/3.11 release team.
- Have 2 parser so we can work on one without breaking it all
- Remove the reference to the RBParser and RBToken
- Clean the interface of the RBNode
- Integrate the continuations from Seaside
- Make debug it work in the debugger
- Profile the compiler to optimize it.
- Create some visitor to have the AST annotations and remove the token
- Work on the VM and new bytecodes/primitives
- ...
Up to now I have look at VMMaker and implement some bytecodes the improve the performance of the method with closures by 6. Those bytecode are experimental and we should propose some more efficient.
We have also change the organization of the NewCompiler. So now we have 3 packages:
- AST: Package for the RBNode and RBToken (which should be removed)
- NewParser: Package containing the parser so you can use it for your purpose without loading the complete compiler. We make this package mostly to make the RefactoringEngine using the SqueakParser so we can remove the RBParser.
- NewCompiler: The closure compiler
Thursday, April 26, 2007
Introduction to the NewCompiler project
Here is a short description for the NewCompiler for Squeak project.
This project aims to:
- provide a better framework interface
- bring full closures to an usable state
- provide many ways to manipulate your code (e.g. ByteSurgeon, ChangeBoxes, Reflectivity, Gutenberg..)
Last year for the Summertalk I implemented the following features:
- complete support for method pragmas
- enhanced error messages for the new parser
- support for parsing and modeling comments
I have discussed with Marcus, we started the project by doing some benchmark to see how slow the NewCompiler is compared to the current one. The conclusion was that we need new bytecodes and new primitives to make the closures as fast as blocks were before.
We will also document the closures and how the user can interact with the NewCompiler.
If have questions feel free to join the NewCompiler mailing list.
This project aims to:
- provide a better framework interface
- bring full closures to an usable state
- provide many ways to manipulate your code (e.g. ByteSurgeon, ChangeBoxes, Reflectivity, Gutenberg..)
Last year for the Summertalk I implemented the following features:
- complete support for method pragmas
- enhanced error messages for the new parser
- support for parsing and modeling comments
I have discussed with Marcus, we started the project by doing some benchmark to see how slow the NewCompiler is compared to the current one. The conclusion was that we need new bytecodes and new primitives to make the closures as fast as blocks were before.
We will also document the closures and how the user can interact with the NewCompiler.
If have questions feel free to join the NewCompiler mailing list.
Sunday, April 15, 2007
Introducing... Squeak's Summer of Code 2007 Projects
With this post, I'd like to introduce to you the five projects that have been selected for this year's Summer of Code. They are:
Developing a package model
by Damien Cassou, mentored by Stephane Ducasse
Improving the Compiler frameworks
by Mathieu Suen, mentored by Marcus Denker
A Squeak HTML/CSS Viewer
by Jerome Chauveau, mentored by Todd Blanchard
Collaborative Development
by Benjamin Vanderheyden Schroeder, mentored by Ralph Johnson
One Wiki to Rule Them All
by Oleg Korsak, mentored by Keith Patrick Hodges
This five projects have been selected among 35 proposals submitted by 25 students.
Developing a package model
by Damien Cassou, mentored by Stephane Ducasse
Improving the Compiler frameworks
by Mathieu Suen, mentored by Marcus Denker
A Squeak HTML/CSS Viewer
by Jerome Chauveau, mentored by Todd Blanchard
Collaborative Development
by Benjamin Vanderheyden Schroeder, mentored by Ralph Johnson
One Wiki to Rule Them All
by Oleg Korsak, mentored by Keith Patrick Hodges
This five projects have been selected among 35 proposals submitted by 25 students.
Saturday, April 14, 2007
Welcome to the Summer of Squeak!
Hello, and welcome to the Summer of Squeak!
This blog is dedicated to the Squeak projects for the Google Summer of Code 2007 program. It is a collective blog managed by the students, mentors and admins of the Squeak Summer of Code group.
With this blog, we hope to give you an insider view on the projects, and help you track them. So if you have any question or remark, don't hesitate to leave a comment or to send us a message.
This blog is dedicated to the Squeak projects for the Google Summer of Code 2007 program. It is a collective blog managed by the students, mentors and admins of the Squeak Summer of Code group.
With this blog, we hope to give you an insider view on the projects, and help you track them. So if you have any question or remark, don't hesitate to leave a comment or to send us a message.
Subscribe to:
Posts (Atom)