Re: [Esug-list] Google Summer Of Code 2010 news!!!
Locked
12
12
Re: [Esug-list] Google Summer Of Code 2010 news!!!
 
|
> 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 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!
|
|
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 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!
|
|
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 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!
|
|
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 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!
|
|
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 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!
|
|
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 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [squeak-dev] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
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 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
HTTP messaging project (was Google Summer of Code..)
|
|
On 07. 03. 2010 00:02, Julian Fitzell wrote:
> + 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. This is actually very good idea and because we need to reimplement the Swazoo HTTP messaging part due to licensing reasons anyway, even more timely. So, idea is to make an independent HTTP messaging library to be used for both web servers and clients, and also for internal use in web frameworks like Seaside, Aida and Iliad, to avoid unnecessary converting as it happens now. As a Swazoo maintainer a have quite an interest and I'm therefore willing to mentor that project. -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Esug-list] HTTP messaging project (was Google Summer of Code..)
|
|
On 03/07/2010 10:59 AM, Janko Mivšek wrote:
> This is actually very good idea and because we need to reimplement the > Swazoo HTTP messaging part due to licensing reasons anyway, even more > timely. Don't get me started on this... Are you sure there's no more pressing need for Swazoo? Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Seaside] Re: [Esug-list] HTTP messaging project (was Google Summer of Code..)
|
|
On 07. 03. 2010 11:00, Paolo Bonzini wrote: > On 03/07/2010 10:59 AM, Janko Mivšek wrote: >> This is actually very good idea and because we need to reimplement the >> Swazoo HTTP messaging part due to licensing reasons anyway, even more >> timely. > > Don't get me started on this... Are you sure there's no more pressing > need for Swazoo? Certainly, like improving the HTTP Server part according to your suggestions and actual code. Also unifiying the portability layer (Sport and Grease) under a common umbrella is a good idea, then we can move Swazoo on that layer. But Julian's idea came just at the right moment and it has a broader appeal. We can then redesign the HTTP server part in the meantime. I see many synergies there. Best regards Janko _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Seaside] Re: [Esug-list] HTTP messaging project (was Google Summer of Code..)
|
|
On 03/07/2010 11:17 AM, Janko Mivšek wrote:
>> > Don't get me started on this... Are you sure there's no more pressing >> > need for Swazoo? > Certainly, like improving the HTTP Server part according to your > suggestions and actual code. Also unifiying the portability layer (Sport > and Grease) under a common umbrella is a good idea, then we can move > Swazoo on that layer. > > But Julian's idea came just at the right moment and it has a broader > appeal. We can then redesign the HTTP server part in the meantime. I see > many synergies there. Ok, then I agree. :-) But let's set the priorities straight. :-) Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Paolo Bonzini-2
Mariano
Well I do not know anybody writing code under LGPL in Smalltalk. So this is an issue. I think that having a license mess will not help. So we do not care about the fact that the project use a apporved license, we care that people can/will use it afterwards. So LGPL is not a good idea. Stef On Mar 8, 2010, at 12:29 AM, Mariano Martinez Peck wrote: > > > On Mon, Mar 8, 2010 at 12:24 AM, Gilad Bracha <[hidden email]> wrote: > I'm all for it, and hope that John or Eliot can mentor. Datapoints I'll add: > > There is some support for parsing C headers in the Newspeak system. > Aliens have been ported to Strongtalk as well as Squeak. > > > Finally - what licensing would apply if GNU Smalltalk were used? GPL is a big problem. Even LGPL elicits an immune response in a lot of commercial contexts. Is there a GSoC policy on this? > > > > Yes, as you can read here: > > http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#licenses > > it says: > > • What licenses do I have choose from? > That depends on your mentoring organization. All code created by student participants must be released under an Open Source Initiative approved license. It's also extremely likely that your mentoring organization will have a preferred license(s) and that you will need to release your code under the license(s) chosen by that organization. > > > And as you can read in the link, LGPL seems to be accepted...so, from the GSoC point of view there is no problem with the license. > > Cheers > > Mariano > > On Sun, Mar 7, 2010 at 3:09 PM, Mariano Martinez Peck <[hidden email]> wrote: > > > 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. > > > I think this project could be a good idea for GSoC. As I said, I would love if it (optionally at least) could not to block the complete VM while a function is being called. > > I would also love what you said: parse .h of libraries and automatically create the wrapper for Smalltalk. At least create the invocations to the functions, and map the structures to objects... > > We need to write a title, a little description and if possible titles like "technical details", "benefits to the students" and "benefits to the community". > > If you are interested please send it to me and I add it to the list. > > We also need a mentor (and a student, of course)...anyone is willing to do it ? > > Cheers > > Mariano > > > > -- > Cheers, Gilad > _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Paolo Bonzini-2
On Mon, Mar 8, 2010 at 00:24, Gilad Bracha <[hidden email]> wrote:
> I'm all for it, and hope that John or Eliot can mentor. Datapoints I'll add: > There is some support for parsing C headers in the Newspeak system. > Aliens have been ported to Strongtalk as well as Squeak. > Finally - what licensing would apply if GNU Smalltalk were used? GPL is a > big problem. Even LGPL elicits an immune response in a lot of commercial > contexts. Is there a GSoC policy on this? Last year's GST project was released under MIT license. The GST distribution includes in fact several MIT packages without relicensing it. It is also perfectly possible to develop a single GSoC under a variety of licenses (GPL/LGPL for code that will go in GNU Smalltalk, MIT for something else). If there is need, I'll take care with the student of the FSF copyright assignment fo GST-specific code. In other words, licensing is the least of the problems. BTW, I took a look at Aliens and it would be possible to port CObject to Squeak basing it on Aliens, since it provides a higher-level framework. Doing vice-versa would also be possible. A description of CObject can be found starting at http://www.gnu.org/software/smalltalk/manual/html_node/C-and-Smalltalk.html#C-and-Smalltalk Gilad, in your experience what % of the bindings you wrote were Smalltalk and what % was C code? Did you have any performance problems that you could fix using more C code? Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Paolo Bonzini-2
> We need to write a title, a little description and if possible titles like
> "technical details", "benefits to the students" and "benefits to the > community". > > If you are interested please send it to me and I add it to the list. > > We also need a mentor (and a student, of course)...anyone is willing to do > it ? I'm willing to co-mentor it, depending on the focus of the project, though I'd prefer the Grease projects more. Just a note: our proposals are _ideas_. A student will be able to come up with something completely different, and we will have to find a mentor and everything else. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by stephane ducasse-2
stephane ducasse wrote:
> Mariano > > Well I do not know anybody writing code under LGPL in Smalltalk. > So this is an issue. I think that having a license mess will not help. So we do not care about the fact that the project > use a apporved license, we care that people can/will use it afterwards. > So LGPL is not a good idea. GLORP is LGPL, with a subsequently added explanation of how the the license should be interpreted in a Smalltalk context. INAL, but this still seems muddy, since it's unclear whether or not the author's interpretation and intentions would override the actual license, which is LGPL. Or, is it the case that the actual license is LGPL + author addendums - gah, another license mess. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
>>>>> "Yanni" == Yanni Chiu <[hidden email]> writes:
Yanni> GLORP is LGPL, with a subsequently added explanation of how the the Yanni> license should be interpreted in a Smalltalk context. INAL, but this Yanni> still seems muddy, since it's unclear whether or not the author's Yanni> interpretation and intentions would override the actual license, which Yanni> is LGPL. Or, is it the case that the actual license is LGPL + author Yanni> addendums - gah, another license mess. And I believe some heavyweights (with actual lawyers they paid) have already weighed in that the LGPL is equivalent to the *GPL* in a Smalltalk context, so unless the code is explicitly dual-licensed with a more permissive license as well, it taints the entire distro. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
>>>>> "Randal" == Randal L Schwartz <[hidden email]> writes:
Randal> And I believe some heavyweights (with actual lawyers they paid) have Randal> already weighed in that the LGPL is equivalent to the *GPL* in a Randal> Smalltalk context, so unless the code is explicitly dual-licensed with Randal> a more permissive license as well, it taints the entire distro. Here's the reference: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124027.html -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
Thanks thanks thanks thanks for a refresh on that!
Thanks! Stef On Mar 8, 2010, at 5:55 PM, Randal L. Schwartz wrote: >>>>>> "Randal" == Randal L Schwartz <[hidden email]> writes: > > Randal> And I believe some heavyweights (with actual lawyers they paid) have > Randal> already weighed in that the LGPL is equivalent to the *GPL* in a > Randal> Smalltalk context, so unless the code is explicitly dual-licensed with > Randal> a more permissive license as well, it taints the entire distro. > > Here's the reference: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124027.html > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Paolo Bonzini-2
On Tue, Mar 9, 2010 at 16:10, John O'Keefe
<[hidden email]> wrote: > I am willing to co-mentor a Grease project and/or a portable TCPIP > implementation (we will need this for the OpenSSL project anyway). I can contribute the GNU Smalltalk TCP/IP implementation under whatever license. It's all written by me(*) so I can relicense it. (*) see http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f=packages/sockets/ChangeLog;h=ab405c72a1698ce00bac93965fc856ef0b3d08ce;hb=HEAD UnixStream.st is not anymore part of the package, and Nicolas Burrus' work is not present anymore since I introduce IPv6 support. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Paolo Bonzini-2
Eliot
> What the starting point is will depend on to what extent Cog has been open sourced (Teleplace may choose to open source single-threaded Cog initially, keeping back the threaded FFI for a while, it may not open source Cog at all; we'll see :) ). May be I the only one to notice the :) which I have problem to understand since for me it announces that COG may not be open-source. What would help teleplace to believe that open-sourcing it would be a win-win situation? A bigger community of contributors ? Making sure that the truck factor does not touch them in case elliot is called under other horizons? Now there is a bootstrap problem. How can a community show that an open-source model is better than a closed one, if the software is closed? STef _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
«
Return to Gnu
|
1 view|%1 views
| Free forum by Nabble | Edit this page |