help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Google Summer of Code


From: Nick Gasson
Subject: Re: [Help-smalltalk] Google Summer of Code
Date: Fri, 14 Mar 2008 20:39:03 +0000
User-agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109)

Paolo Bonzini wrote:

Sure.  Here are some possibilities:

1) GnuTLS bindings, including adding to Swazoo support for serving HTTPS. Other common libraries, such as GD, GSL or Expat would be interesting. In a project application you probably want to propose a coherent set of libraries to work on, with an example of an application that would tie them together.

2) Work on the GUI. You could write a Gtk or Blox back-end for OmniBrowser, or add the ability to develop in the GUI and sync the files on the file system.

2a) As part of this you could also develop a system to port changesets from other Smalltalks. The idea is to have a merge-like command that takes two foreign source code files (e.g. from SqueakSource) and merges the code into a GNU Smalltalk source file.

2b) Or, you could implement a "remote browser", i.e. something that could browse an already running system. In other words, the view/controller and the model would reside on two different instances of the VM. This requires implementing or porting some kind of distributed messaging system.

2c) The same, for debugging. Investigate possibly if the protocols that are used by Java debuggers are suitable to Smalltalk.

3) Work on command-line tools. You could port parts of the Refactoring Browser and make a command-line version of Smalllint for example.

4) Create a build tool that allows one to coordinate builds with Smalltalk scripts, like Rake or SCons (see also http://smalltalk.gnu.org/blog/bonzinip/sake-rake-smalltalk for an example of what I mean).

5) Add a GNU Smalltalk backend to SWIG.

6) Implement better strategies for block closures in order to improve performance.

7) Build a continuous integration server using Seaside, with code reports. This could have many directions: building an interface to version control systems (svn, CVS, git) that can be used from Smalltalk, analyze what problems would limit the uptime of a web application written using GNU Smalltalk and Seaside (memory leaks, etc.),...

8) Write an Eclipse front-end for GNU Smalltalk.

Paolo

Thanks for the list! The SWIG bindings project looks interesting. I'm aware of at least one existing Smalltalk SWIG backend (http://commonsmalltalk.wikispaces.com/SWIG), but there's no GST support and it hasn't been updated for a while. It'd be nice to develop something that was more GST specific, perhaps with a view to getting it integrated in the main SWIG distribution.

I think a SWIG backend could be useful for (1) too -- PyGSL (I think) uses SWIG to generate some of its GSL bindings. I'm also quite interested in working on an SDL library for GST (I was searching for one a little while ago, and found some code posted on this mailing list, but it was incomplete and I've seen nothing since).


Nick





reply via email to

[Prev in Thread] Current Thread [Next in Thread]