OpenNARS port to Squeak using Seaside

Hi, I'm Cédrick Béler, a french PhD student and I've been selected for GSoC of squeak. The selected application consists in porting OpenNARS (Non-Axiomatic Reasoning Systems) to Squeak using Seaside for the GUI. My Mentors are Klaus D.Witzel and Pei Wang (creator/developer of NARS).

NARS is before all a reasoning system but a non-axiomatic one compared to usual semi-axiomatic ones we find in AI [1]. It attempts to uniformly explain and reproduce many cognitive facilities, including reasoning, learning, planning, etc, so as to provide a unified theory, model, and system for AI as a whole. The ultimate goal of NARS research is to build a thinking machine. What makes this system different from conventional reasoning systems is its ability to learn from its experience and to work with insufficient knowledge and resources. NARS theory exists. A book has been published recently (Rigid flexibility).

Since 2008, NARS is developed as open source software . A prototype exists in java for the core of the system but there is still a lot to do until the aim of having a thinking machine is reached. A port is underway in Python and we propose to start a squeak port because we think a dynamic and flexible environment and language as Smalltalk/Squeak could be very appropriate here.

Right now, I'm finishing writing my PhD dissertation so I will only spend moderate time on the project in June (delivery date is by the end of June). Once done, I'll be nearly full-time on the project. When coding, I'll be as much as possible on IRC (#squeak) on freenode under the nickname Cdrick. Feel free to contact me if you have any question in relation to this project. I will start the port with the stable core of the prototype (see here for more information)

Cédrick Béler (cdrick65 for my google account...)

[1] NARS (Non-Axiomatic Reasoning System) is a concrete example of non-axiomatic system. Here is a short definition of axiomatic, semi-axiomatic and non-axiomatic (quoted from Pei Wang publications)

1. pure-axiomatic system: In all aspects, the system has sufficient knowledge and resources with respect to the problems to be solved.
• Pure-axiomatic systems are studied in mathematics, and is not directly related to AI
2. semi-axiomatic system: In some, but not all, aspects, the system has sufficient knowledge and resources with respect to the problems to be solved.
• Most of the previous AI work in the inference framework belong to the category of semi-axiomatic system, which attempt to make partial extension or revision of mathematical logic, while keep the other parts.
3. non-axiomatic system: In all aspects, the system has insufficient knowledge and resources with respect to the problems to be solved.
• For AI, what is really needed are non-axiomatic systems, which do not assume the sufficiency of knowledge and resources in any aspect of the system.
  

Basically in NARS, solving the same problem several times has not to give the same solution... If you're intrigued by this theory, don't hesitate having a look at the available documentation :)

Introduction to the Safará project: a Source code editor for Squeak

Hi, I am Luigi Panzeri, one of the five student selected to work for the Squeak project. I have Lukas Renggli as a mentor.

The goal of the Safarà project is to develop an extensible code editor that can improve the DSL experience on Squeak, and at the same time can provide the same features, that come up with modern editors like Eclipse, Emacs and TextMate.

Actually, It aims to provide the following features:

* Highly configurable and customizable using Smalltalk code or a
graphical customization interface.

* Highly extensible in term of features and syntaxes supported.

* Easily embeddable as a widget in other applications (e.g. mail
reader, applications using DSLs, etc.).

* Well integrated with the tools present on a traditional Squeak
development image.

* Support for collaborative editing.

FreeCAD: 3D CAD with Motion Simulation Port to Croquet

Hi,
My name is Phua Khai Fong from Malaysia. I'm in my final year pursuing my electronics engineering degree in Multimedia University. I will be working on Croquet for GSOC and the goal of my project is to create a tool for in-world content creation. Currently, I am able to draw and extrude 3D solids which consists of cubes, cylinders, ellipses and polygons. I will be working with my mentor Dr. A.S. Koh and the Croquet community to add more controls to the content creation tool that I am working on which is also based on FreeCAD (for more info on FreeCAD, visit www.ar-cad.com). If you are interested to see the initial stuff, I do have a few videos online here .

Regards,


Phua Khai Fong
kayef8 [at] yahoo [dot] com

Introduction to the IRC Bot Framework project

Hi all,

I'm François Stephany, one of the five Squeak gsoc students.

The goal of this project is to build a framework for developing IRC bots. At the moment, the squeak related irc channels rely on non smalltalk bots (who said Lisp?) to provide the needed services. As smalltalkers, we like to eat our own dog food and have special needs. A bot written in smalltalk could have some smalltalkish functionalities (explore image, monticello tracking,...) that would be a bit tricky to provide in other languages.
Squeak already has a client: IRCe, it will be used (and refactored if needed) as a starting point.

The basic functionalities:
- channel logging
- channel administration
- pastebot
- storage bot/infobot

If you have any suggestion/wish for the bot, don't hesitate to tell !

See you all on IRC (#squeak)
[nick: fstephany on freenode -- Thanks Randal :]

Introduction to Squeak GTK project

Here is a short description of the Squeak GTK.

This project aims to :

- provide a full support of the GTK+ library included GDK, GLib, Cairo.
- provide a full support of the WebKit library.
- Create a MVC framework
- Create a basic toolset (inspector, reflective management of widget, efficient class browser, transcript, ...) if time permitted

You can find the project at : SqueakGTK

There is a SqueakVM with the callback patch and the SqueakGTK plugin generated. But you can find all the files to patch the squeakVM and build the plugin by hand ;)

Gwenael Casaccio

Google Summer of Code 2008

Hi all, and welcome back to the Summer of Squeak blog!

For the second year, the Squeak project has been accepted into the Google Summer of Code program.

This year we decided to reopen the blog a little earlier, while students applications are still open. So, if you're interested in proposing a project to Squeak, you're still in time!

If you need more info, just head to the Summer of Squeak webpage!


The Squeak Project Mentors

OWRTA #14

Ordered and unordered lists are complete. The rest is links, image and placeholder. And of course syntax switcher and parser code merging.

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.

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.

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.

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)

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.

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 :-) .

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 \\).

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.