Hi smalltalkers. I have been asked to be the admin of GSoC 2010. The backup or second admin is Janko Mivšek. As you may know, Squeak has participated in GSoC 2007, 2008 but failed (not accepted) in 2009. We are not sure if we will succeed this year but we will try to do as much as possible.
We think that one of the most important reasons why we failed in 2009 is that Google was looking for bigger communities that Squeak. This is why this year we all go under the ESUG umbrella. We present ESUG as the mentor organization and we cover ALL open-source Smalltalk dialects, not only Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all invited to participate. Also cross platform projects like Seaside, AidaWeb, Magma, etc are welcome. <forThoseWhoDoesntKnowWhatGSoCIs> It is a Google program that support (money) students to work on different open-source projects. Google doesn't talk or manage directly to the students but trough "Mentoring Organisations". Those organizations have to apply to GSoC. They have to give a lot of information, included a list of ideas/projects. Each project has a description and a mentor. Then the students apply for each project. If the organization gets selected by Google they will tell you how many "slots" they give. Suppose they give 5 but we have 20 projects....then we vote and the most voted projects win. The student has to do the project and the mentor has to help and guide him. The mentor receives 500 USD and the student 4500USD. For more information read: http://code.google.com/soc/ </forThoseWhoDoesntKnowWhatGSoCIs> The most important thing is the deadlines we have. We started late so we are very near to the first deadline which is 12/03/2010 (less than one week). For that deadline we need to submit all the information of the mentor organization (answering several questions) and give the list of ideas/projects and the mentors of that. We have created a webpage (Thanks Janko!!) where we will put all the information. We will make this page public soon (we still need to review a couple of things). But for the moment we would REALLY appreciate if tell us your ideas. To do this, just answer to this email. Then we will collect the information and put in the website. For each idea you need: a short title and a paragraph (for the moment) explaining the idea. After, we need that the people that are willing to be mentors start to apply as mentors...please, consider yourself being mentor. Sometimes it is not that difficult. I mean, don't be shy as sometimes being helpful, being aware of the dates, answering emails, etc is more important than the Smalltalk knoweldege. We can have a lot of ideas, but we need also mentors for that. We even would need a "substitute" for each mentor... Just as an example you can see the ideas of the previous years: 2007: http://wiki.squeak.org/squeak/5936 2008: http://wiki.squeak.org/squeak/6031 2009: http://wiki.squeak.org/squeak/6120 That's all for the moment. Cheers Mariano |
> We think that one of the most important reasons why we failed in 2009 is
> that Google was looking for bigger communities that Squeak. This is why > this year we all go under the ESUG umbrella. We present ESUG as the > mentor organization and we cover ALL open-source Smalltalk dialects, not > only Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all > invited to participate. Also cross platform projects like Seaside, > AidaWeb, Magma, etc are welcome. Here is a list of ideas from me, all more or less involving cross-dialect pollination. These are based on my preferences, from most to least preferred 1) GNU Smalltalk includes a refactored version of Swazoo that supports SCGI and is also faster in general. Start from there and backport the changes to Squeak/Pharo. Use Seaside's Grease cross-dialect compatibility layer to get rid of (most of) the Sport dependency. 2) Convert existing cross-platform projects to use Grease. Demonstrate them using two-three dialects (VW, Squeak, GST). Discuss possible extensions to Grease and implement them. Document Grease extension based on the formalism of the ANSI standard. 3) I agreed with the FSF to relicense GNU Smalltalk's file system classes under MIT license. Port them to at least two other dialects (Squeak/Pharo count as one). Think of cool ways to use them. Possibly work out how to integrate them into Grease and make Seaside use them. 4) Build a continuous integration server using Seaside, Iliad or AidaWeb. Build an interface to version control systems (possibly supporting both independent systems such as Monticello or file-based such as svn/CVS/git) that can be used from Smalltalk and integrate it with Smalllint code reports. For a more ambitious project, the server should be able to start a new image, upgrade the package, run SUnit tests there and communicate back the results---the time to upgrade the package should be minimized of course! 5) Work on a cross-dialect foreign function call interface and implement it in at least two dialects. Candidates include Alien and GNU Smalltalk's CObject (using existing implementation has the advantage of having to implement in only _one_ other dialect!). Bonus points for implementing a C parser that would be able to construct bindings. GNU Smalltalk already contains a C preprocessor implementation. Paolo |
4) Build a continuous integration server using Seaside, Iliad or AidaWeb. Build an interface to version control systems (possibly supporting both independent systems such as Monticello or file-based such as svn/CVS/git) that can be used from Smalltalk and integrate it with Smalllint code reports. For a more ambitious project, the server should be able to start a new image, upgrade the package, run SUnit tests there and communicate back the results---the time to upgrade the package should be minimized of course! Are you aware of this two projects ? I don't know other dialects but in Pharo they work: - http://n4.nabble.com/Interim-build-server-td1296834.html#a1296834 - http://n4.nabble.com/ANN-Hudson-continuous-integration-server-support-td1296910.html#a1296910
Yes!!! And make it (optionally at least) not to block the complete VM while a function is being called. Cheers Mariano |
Mariano Martinez Peck wrote:
> > 4) Build a continuous integration server using Seaside, Iliad or > AidaWeb. Build an interface to version control systems (possibly > supporting both independent systems such as Monticello or > file-based such as svn/CVS/git) that can be used from Smalltalk > and integrate it with Smalllint code reports. For a more > ambitious project, the server should be able to start a new image, > upgrade the package, run SUnit tests there and communicate back > the results---the time to upgrade the package should be minimized > of course! > > > Are you aware of this two projects ? I don't know other dialects but > in Pharo they work: > > - http://n4.nabble.com/Interim-build-server-td1296834.html#a1296834 > - > http://n4.nabble.com/ANN-Hudson-continuous-integration-server-support-td1296910.html#a1296910 > > > > > 5) Work on a cross-dialect foreign function call interface and > implement it in at least two dialects. Candidates include Alien > and GNU Smalltalk's CObject (using existing implementation has the > advantage of having to implement in only _one_ other dialect!). > Bonus points for implementing a C parser that would be able to > construct bindings. GNU Smalltalk already contains a C > preprocessor implementation. > > > Yes!!! And make it (optionally at least) not to block the complete VM > while a function is being called. > > Cheers of F-Script would totally rule. Does the CObject FFI allow you to do what F_script does and examine the entire object tree written in Cocoa? That would at least for Macs, give you a full blown GUI external to the Squeak desktop. Lawson |
In reply to this post by Mariano Martinez Peck
Hi there,
> But for the moment we would REALLY appreciate if tell us your ideas. > To do this, just answer to this email. Then we will collect the > information and put in the website. For each idea you need: a short > title and a paragraph (for the moment) explaining the idea. Yet another project to deal with multiple dialects: Porting Monticello to Smalltalk/X ---- Over the years, lot of nice stuff has been developed for Squeak/Pharo. Porting the code to other dialects lacking monticello (such as Smalltalk/X) support is difficult and error-prone. Updating already ported code to a new version or merging changes back to the mainline is even worse. Monticello port will ease porting of other successful projects. AidaWeb, Seaside, SqueakDBX, Glamour, Mondrian or DeltaStreams are just few of them. GemStone pioneered this approach and its success show us that this is a reasonable way to go. The goal to this project is to port and integrate Monticello to the Smalltalk/X environment so the programmer will be able to load a code from a monticello repository and commit it back right from the Smalltalk/X IDE. Cheers, Jan |
In reply to this post by LawsonEnglish
On 03/06/2010 02:22 PM, Lawson English wrote:
> > 4) Build a continuous integration server using Seaside, Iliad or > AidaWeb. Build an interface to version control systems (possibly > supporting both independent systems such as Monticello or > file-based such as svn/CVS/git) that can be used from Smalltalk > and integrate it with Smalllint code reports. For a more > ambitious project, the server should be able to start a new image, > upgrade the package, run SUnit tests there and communicate back > the results---the time to upgrade the package should be minimized > of course! > > > Are you aware of this two projects ? I don't know other dialects but in > Pharo they work: > > http://n4.nabble.com/Interim-build-server-td1296834.html#a1296834 > http://n4.nabble.com/ANN-Hudson-continuous-integration-server-support-td1296910.html#a1296910 They seem to be very close to what I had in mind, in particular Hudson. Paolo |
In reply to this post by LawsonEnglish
On 03/06/2010 02:22 PM, Lawson English wrote:
> Does the CObject FFI allow you to do what F_script does and examine the > entire object tree written in Cocoa? That would at least for Macs, give > you a full blown GUI external to the Squeak desktop. You _can_ write an Objective-C binding using CObject (as in, it's been done). The painful part is converting NSArray <-> Array and NSString <-> String. However, nice-looking bindings will always have a part written in C that will be VM-dependent, which is why I put this project last. It is much less useful than it looks. Paolo |
On Mar 6, 2010, at 6:41 AM, Paolo Bonzini wrote: > On 03/06/2010 02:22 PM, Lawson English wrote: >> Does the CObject FFI allow you to do what F_script does and examine the >> entire object tree written in Cocoa? That would at least for Macs, give >> you a full blown GUI external to the Squeak desktop. We've done this using aliens in Newspeak (see ObjectiveCAline and friends). To do a real GUI is more involved, because of MacOS threading issues (which thread is in control etc.). We hope to fix this in time, and of course provide a fully native binding for the Brazil/Hopscotch GUI on macs, as we do on Windows. > > You _can_ write an Objective-C binding using CObject (as in, it's been done). The painful part is converting NSArray <-> Array and NSString <-> String. > > However, nice-looking bindings will always have a part written in C that will be VM-dependent, which is why I put this project last. It is much less useful than it looks. Inteoperating smoothly with the rest of the world is very useful. Cheers, Gilad |
On 03/06/2010 03:54 PM, Gilad Bracha wrote:
>>> You_can_ write an Objective-C binding using CObject (as in, it's >>> been done). The painful part is converting NSArray<-> Array and >>> NSString<-> String. >>> >>> However, nice-looking bindings will always have a part written in >>> C that will be VM-dependent, which is why I put this project >>> last. It is much less useful than it looks. > > Inteoperating smoothly with the rest of the world is very useful. I fully agree. But there's so much more involved in interoperating smoothly with the rest of the world than Aliens/CObjects, and what's left is very hard to do in a cross-dialect way. So, having cross-dialect Aliens/CObjects is a nice step, but unfortunately it is still far from being a full solution. Paolo |
In reply to this post by Mariano Martinez Peck
> But for the moment we would REALLY appreciate if tell us your ideas. To
> do this, just answer to this email. Then we will collect the information > and put in the website. For each idea you need: a short title and a > paragraph (for the moment) explaining the idea. * MIDI support for the linux VM Basically implement the MIDI plugin that has been missing for years in the linux VM * DBus support for all platforms (don't really know about the current state of affairs here) Stef |
In reply to this post by Mariano Martinez Peck
A little correction. At the beginning I though only open-source
Smalltalk dialects were possible, but now Janko let me know that non
open-source dialects are welcome too. What really has to be open-source
is the project/idea in particular, but the Smalltalk dialect in itself
can be non open-source.
Sorry for the noise. Mariano On Sat, Mar 6, 2010 at 1:04 PM, Mariano Martinez Peck <[hidden email]> wrote: Hi smalltalkers. I have been asked to be the admin of GSoC 2010. The backup or second admin is Janko Mivšek. As you may know, Squeak has participated in GSoC 2007, 2008 but failed (not accepted) in 2009. We are not sure if we will succeed this year but we will try to do as much as possible. |
In reply to this post by Paolo Bonzini-2
> 4) Build a continuous integration server using Seaside, Iliad or
> AidaWeb. Build an interface to version control systems (possibly > supporting both independent systems such as Monticello or file-based > such as svn/CVS/git) that can be used from Smalltalk and integrate > it with Smalllint code reports. For a more ambitious project, the > server should be able to start a new image, upgrade the package, run > SUnit tests there and communicate back the results---the time to > upgrade the package should be minimized of course! I bit superfluous considering this project has already been done. Keith |
In reply to this post by Mariano Martinez Peck
On 6 Mar 2010, at 13:07, Mariano Martinez Peck wrote:
Ok I will be clearer, Bob has a seaside interface, for watching the status of all builds and triggering manual builds. In your build spec, you give bob a url for any starting image, he downloads it, unzips it and finds the image within the zip file. He then launches said image, applies the scripts to build whatever you want, saves the build in the output directory zips it up adds a meta-data file so you can see what that build contains and uploads it to anywhere you specify via ftp, or signals it as ready for an rsync process to upload. (since the rsync might need to be run by a different process for security reasons) ftp uploads and downloads are done 5 at a time thanks to rio's support, and use unix ftp if OSProcess is available. Bob also watches any build result, either locally or in anyone else's build output folder that is available via ftp. When he spots that a published image has been updated he can trigger a build based on the new image, retrieving that via ftp. Everyone who wants to can run bob servers, there is a periodic service scheduler which reads a global build configuration from a central monticello repo. So you can publish a build spec to squeaksource for a build you would like to see, and every bob server can build it if it wants to subscribe to it. Subscription to a build is achieved simply by creating the output folder. Testing is provided by an SUnit package which generates results in simple text file reports, these results are viewable remotely via http. Multiple bobs can be configured to run tests on each of squeaks target platforms, run tests and publish results. if you really want it, it is there, Keith |
In reply to this post by Paolo Bonzini-2
On Sat, Mar 6, 2010 at 12:54 PM, Paolo Bonzini <[hidden email]> wrote:
>> We think that one of the most important reasons why we failed in 2009 is >> that Google was looking for bigger communities that Squeak. This is why >> this year we all go under the ESUG umbrella. We present ESUG as the >> mentor organization and we cover ALL open-source Smalltalk dialects, not >> only Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all >> invited to participate. Also cross platform projects like Seaside, >> AidaWeb, Magma, etc are welcome. > > Here is a list of ideas from me, all more or less involving cross-dialect > pollination. These are based on my preferences, from most to least > preferred > > 1) GNU Smalltalk includes a refactored version of Swazoo that supports SCGI > and is also faster in general. Start from there and backport the changes to > Squeak/Pharo. Use Seaside's Grease cross-dialect compatibility layer to get > rid of (most of) the Sport dependency. > > 2) Convert existing cross-platform projects to use Grease. Demonstrate them > using two-three dialects (VW, Squeak, GST). Discuss possible extensions to > Grease and implement them. Document Grease extension based on the formalism > of the ANSI standard. > > 3) I agreed with the FSF to relicense GNU Smalltalk's file system classes > under MIT license. Port them to at least two other dialects (Squeak/Pharo > count as one). Think of cool ways to use them. Possibly work out how to > integrate them into Grease and make Seaside use them. I think I'd be willing to be a mentor for anything Grease- or Seaside-related, though I might need to run that by my new employer depending on what the project ends up being. The above are good ideas. Also, off the top of my head: + Take the best parts of Seaside and Swazoo's HTTP protocol classes and create an HTTP package that could be optionally loaded with Grease and used by multiple projects. + Someone else suggested porting Monticello to Smalltalk/X. The same could be done for VA Smalltalk and a full port with UI for VW. + I'd really love to see a single RefactoringBrowser package that could be loaded on all the platforms using Grease. I have no idea if there's any chance of buy-in from the vendors on that one; maybe it would need a new class name prefix so it could be loaded in parallel... Those are just random mind wanderings... Julian |
In reply to this post by keith1y
I was thinking that Bob was not generally available. I'm glad to be wrong. I googled a bit and couldn't find it. Can you please tell me where to find it? -Ralph |
This appears to be it
<http://www.squeaksource.com/Bob.html> Ken G. Brown At 5:04 PM -0600 3/6/10, Ralph Johnson apparently wrote: >if you really want it, it is there, > > >I was thinking that Bob was not generally available. I'm glad to be wrong. I googled a bit and couldn't find it. Can you please tell me where to find it? > >-Ralph |
In reply to this post by Ralph Johnson
squeaksource.com/bob Keith |
In reply to this post by Ralph Johnson
squeaksource.com/bob I will also package up a running instance of the latest bob when I get a chance, it is on a sever I lent to my polish neighb Keith |
In reply to this post by Ralph Johnson
squeaksource.com/bob I will also package up a running instance of the latest bob when I get a chance, it is on a server I lent to my polish neighbour. Keith |
In reply to this post by Gilad Bracha
Since ESUG is going to act as the umbrella organization for GSoC projects in all Smalltalk dialects, perhaps this offers an opportunity for Newspeak to recruit some labor?
Cheers, Josh |
Free forum by Nabble | Edit this page |