[squeak-dev] Google Summer Of Code 2010 news!!!

This post might be inappropriate. Click to display it.

Mariano Martinez Peck

2012-01-28 12:32:56 UTC

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

Mariano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100306/172e1ab3/attachment.htm

Lawson English

2012-01-28 12:32:56 UTC

Post by Paolo Bonzini
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
- 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

On the Mac version, having the power of Squeak combined with the power
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

Paolo Bonzini

2012-01-28 12:32:56 UTC

They seem to be very close to what I had in mind, in particular Hudson.

Paolo

Paolo Bonzini

2012-01-28 12:32:56 UTC

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

Paolo Bonzini

2012-01-28 12:32:56 UTC

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

Gilad Bracha

2012-01-28 12:32:58 UTC

This post might be inappropriate. Click to display it.

Josh Gargus

2012-01-28 12:32:59 UTC

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

Gilad Bracha

2012-01-28 12:32:59 UTC

Josh,

Thanks for the thought. I can certainly mentor such work - I'm already doing this with a number of Masters students. That said, I have no idea if the ESUG community cares to include Newspeak related stuff in its list of projects. My honest impression is that Newspeak doesn't really appeal to the Smalltalk community, though I'd love to be proven wrong.

One reason for this apparent lack of interest is that might be the fact that Newspeak is not really a Smalltalk dialect. It's more of a Smalltalk descendant. It is quite easy to migrate from Smalltalk to Newspeak however; we've done that with a substantial body of code (most of the Strongtalk version of the blue book libraries, our own GUI and IDE code and a few other things) and the result is generally better than the original because of Newspeak's modularity properties.

Post by Josh Gargus
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

Cheers, Gilad

Josh Gargus

2012-01-28 12:32:59 UTC

What do you base this impression on? The amount of contributions to Newspeak? The level of activity on the forums?

I have less data to go on than you do, but my guess is that Newspeak hasn't been quite mature enough for people who want to build projects in Newspeak (as opposed to working on Newspeak itself). It seems like the situation is steadily improving (unfortunately, I haven't yet found time to play with the most recent release).

Anyway, in this case it's not the broad Smalltalk that matters, it's ESUG. After looking at their website and the diversity of Smalltalk activities that they support, I would be surprised if they wouldn't happily include Newspeak projects under their GSoC umbrella. Can't hurt to ask...

Post by Gilad Bracha
One reason for this apparent lack of interest is that might be the fact that Newspeak is not really a Smalltalk dialect.

It's a Smalltalk to me, along with Smalltalk-72 and Self. I've taken it for granted that most here see it that way, but I may be wrong. Can I get a show of hands of anyone who doesn't think Newspeak is a Smalltalk?

Cheers,
Josh

Post by Gilad Bracha
It's more of a Smalltalk descendant. It is quite easy to migrate from Smalltalk to Newspeak however; we've done that with a substantial body of code (most of the Strongtalk version of the blue book libraries, our own GUI and IDE code and a few other things) and the result is generally better than the original because of Newspeak's modularity properties.

Cheers, Gilad

Ronald Spengler

2012-01-28 12:33:00 UTC

Hell, Ruby #isKindOf: Smalltalk, in that it has Smalltalk in it's
lineage. The best Ruby code is written like passable Smalltalk code,
with unnecessary syntax:)

Even hideous ECMA Script owes both it's past and it's future to Self.

Is Newspeak really such a departure then? I think Self is a Smalltalk.
Anyway, I think it would be neat to see Newspeak in GSoC. And Squeak!

Josh,
Thanks for the thought. ? I can certainly mentor such work - I'm already doing this with a number of Masters students. That said, I ?have no idea if the ESUG community cares to include Newspeak related stuff in its list of projects. ?My honest impression is that Newspeak doesn't really appeal to the Smalltalk community, though I'd love to be proven wrong.

What do you base this impression on? ?The amount of contributions to Newspeak? ?The level of activity on the forums?
I have less data to go on than you do, but my guess is that Newspeak hasn't been quite mature enough for people who want to build projects in Newspeak (as opposed to working on Newspeak itself). ?It seems like the situation is steadily improving (unfortunately, I haven't yet found time to play with the most recent release).
Anyway, in this case it's not the broad Smalltalk that matters, it's ESUG. ?After looking at their website and the diversity of Smalltalk activities that they support, I would be surprised if they wouldn't happily include Newspeak projects under their GSoC umbrella. ? Can't hurt to ask...

One reason for this apparent lack of interest is that might be the fact that Newspeak is not really a Smalltalk dialect.

It's a Smalltalk to me, along with Smalltalk-72 and Self. ?I've taken it for granted that most here see it that way, but I may be wrong. ?Can I get a show of hands of anyone who doesn't think Newspeak is a Smalltalk?
Cheers,
Josh

?It's more of a Smalltalk descendant. It is quite easy to migrate from Smalltalk to Newspeak however; we've done that with a substantial body of code (most of the Strongtalk version of the blue book libraries, our own GUI and IDE code and a few other things) and the result is generally better than the original because of Newspeak's modularity properties.

Cheers, Gilad

--
Ron

Michael Haupt

2012-01-28 12:33:00 UTC

Hi Josh,

me. The underlying abstractions are fundamentally different, and so is
the way of applying abstraction to problem domains. Smalltalk is
rather far away from late-binding (almost?) everything. Smalltalk
classes / objects are not modules the way the are in Newspeak.

Best,

Michael

Frank Shearar

2012-01-28 12:33:01 UTC

Post by Josh Gargus

What do you base this impression on? The amount of contributions to Newspeak? The level of activity on the forums?
I have less data to go on than you do, but my guess is that Newspeak hasn't been quite mature enough for people who want to build projects in Newspeak (as opposed to working on Newspeak itself). It seems like the situation is steadily improving (unfortunately, I haven't yet found time to play with the most recent release).
Anyway, in this case it's not the broad Smalltalk that matters, it's ESUG. After looking at their website and the diversity of Smalltalk activities that they support, I would be surprised if they wouldn't happily include Newspeak projects under their GSoC umbrella. Can't hurt to ask...

Post by Gilad Bracha
One reason for this apparent lack of interest is that might be the fact that Newspeak is not really a Smalltalk dialect.

For what it's worth, I'll raise my hand for the "is a Smalltalk" side.

This debate reminds me of the Lisp family: Dylan, Common Lisp, Scheme,
Logo, ...

frank

Julian Fitzell

2012-01-28 12:33:01 UTC

On Sun, Mar 7, 2010 at 3:23 PM, Frank Shearar

This debate reminds me of the Lisp family: Dylan, Common Lisp, Scheme, Logo,

Yup, kind of a pointless philosophical debate. The only actually
relevant question is whether anyone would object if there was a
student who really wanted to work on Newspeak for the summer and did
so under ESUG's banner. I can't see a downside to that... it's not
like someone who would otherwise have worked on Seaside is now going
to be suddenly "stolen away" by Newspeak, leaving fewer students for
the rest of us. :)

Having more interesting projects and stellar mentors can only help
ESUG's application I would think.

Julian

Gilad Bracha

2012-01-28 12:33:02 UTC

Josh,

Post by Josh Gargus

What do you base this impression on? The amount of contributions to Newspeak? The level of activity on the forums?

Yes to both of those.

Post by Josh Gargus
I have less data to go on than you do, but my guess is that Newspeak hasn't been quite mature enough for people who want to build projects in Newspeak (as opposed to working on Newspeak itself).

Newspeak on Squeak is very stable and has been since it was first released. What might be an issue is that Newspeak will evolve.
This means that you need to be willing to migrate forward as things change. By and large, these migrations will be fully automated.

Post by Josh Gargus
It's a Smalltalk to me, along with Smalltalk-72 and Self.

Ok, if you think of Self as a Smalltalk, then Newspeak would be too. I don't - there is the Smalltalk language family, to which all belong, and there is the Smalltalk language (with all its many dialects) , which is something different. It is a question of degree.

I'll respond to Janko separately.

Cheers, Gilad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100307/a941a475/attachment.htm

Janko Mivšek

2012-01-28 12:33:00 UTC

Hi guys,

I'm in favor to invite Newspeak under this year GSoC umbrella, specially
for projects which will get Newspeak and Smalltalks closer together,
like code exchange ones, maybe even Monticello/Metacello on Newspeak?
Also portability libraries like Sport/Grease, actually everything which
eases portability of code between us.

That way Newspeak ideas will be known better and can be adapted in
future Smalltalks, and vice versa, Newspeak can profit from wast amount
of existing Smalltalk code.

What do other Newspeakers and Smalltalkers think about that?

Best regards
Janko
GSoC co-admin

Post by Gilad Bracha
Josh,
Thanks for the thought. I can certainly mentor such work - I'm already doing this with a number of Masters students. That said, I have no idea if the ESUG community cares to include Newspeak related stuff in its list of projects. My honest impression is that Newspeak doesn't really appeal to the Smalltalk community, though I'd love to be proven wrong.
One reason for this apparent lack of interest is that might be the fact that Newspeak is not really a Smalltalk dialect. It's more of a Smalltalk descendant. It is quite easy to migrate from Smalltalk to Newspeak however; we've done that with a substantial body of code (most of the Strongtalk version of the blue book libraries, our own GUI and IDE code and a few other things) and the result is generally better than the original because of Newspeak's modularity properties.

Cheers, Gilad

--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Gilad Bracha

2012-01-28 12:33:02 UTC

Hi Janko,

Post by Janko MivÅ¡ek
Hi guys,
I'm in favor to invite Newspeak under this year GSoC umbrella,

Great!

Post by Janko MivÅ¡ek
specially
for projects which will get Newspeak and Smalltalks closer together,

So here is a very simple project. Create a nice tool in Newspeak that facilitates import/export from/to Smalltalk.
Most of the pieces already exist. The basics are easy, and as much polish can be added as time allows.

Title: Newspeak/Smalltalk Import/Export Tool

Description:
Create tooling in the Newspeak IDE that facilitates conversion of code from Smalltalk to Newspeak (import) and from Newspeak to Smalltalk (export).

Technical details: The tool will extend and integrate existing components in Newspeak, such as the Newspeak to Strongtalk compiler that essentially does source-to-source conversion to Smalltalk and spits out file out format for Strongtalk. It is easily adapted to other dialects. One can file in Squeak into the the system, and have tools that semi-automatically migrate it in stages to Newspeak. These tools need to be made more robust, more sophisticated and better integrated. Adaptations to a number of different Smalltalk dialects beyond Squeak are desirable. Integration of tools such as Grease, Sport or Slime is a possibility.

Benefits to Student: Students will gain experience with technologies such as parser combinators, advanced module systems, mirror based reflection and GUI programming in the context of a IDE as well as exposure to a variety of Smalltalk dialects and to Newspeak and its modularity structures.

Benefits to the Community: increased sharing of software. Newspeak gains from the vast amount of available software in the Smalltalk community, and Smalltalk gains from some of the advances made in Newspeak.

Cheers, Gilad

Ciprian Teodorov

2012-01-28 12:33:00 UTC

Hi all,

I think that Newspeak at GSoC under ESUG umbrella is a very good idea. It
will help Newspeak evolve but also I think that will help the smalltalk
community open its eyes and understand that evolution is the key to success.
In my point of view Newspeak is a great step forward for the smalltalk
community. Newspeak is a bold project that fixes (or at least tries to fix)
lots of the problems the software community has for the moment, but also
gives to smalltalk some of the thinks it never had.

Moreover as a smalltalk software developer I cannot help myself not noticing
that the smalltalk community seems to be fixed on, what I call, the
"BlueBook complex -- if it's not it the BlueBook it doesn't exist". Yes I
agree the bluebook was a great step forward but, guys, we should accept
change especially when it comes in terms of evolution.

So as a community lets help Newspeak mature, lets show the world that
smalltalk is not dead, lets be the parents Newspeak needs in this moment.

Cheers

Post by Gilad Bracha
Josh,
Thanks for the thought. I can certainly mentor such work - I'm already
doing this with a number of Masters students. That said, I have no idea if
the ESUG community cares to include Newspeak related stuff in its list of
projects. My honest impression is that Newspeak doesn't really appeal to
the Smalltalk community, though I'd love to be proven wrong.
One reason for this apparent lack of interest is that might be the fact
that Newspeak is not really a Smalltalk dialect. It's more of a Smalltalk
descendant. It is quite easy to migrate from Smalltalk to Newspeak however;
we've done that with a substantial body of code (most of the Strongtalk
version of the blue book libraries, our own GUI and IDE code and a few other
things) and the result is generally better than the original because of
Newspeak's modularity properties.

Post by Josh Gargus
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?

Post by Josh Gargus
Cheers,
Josh

Cheers, Gilad

--
Ciprian TEODOROV
Ph.D Student
Lab-STICC/AS CNRS UMR 3192
University of Brest

phone: (+33)(0) 6 08 54 73 48
mail: ***@univ-brest.fr
as.univ-brest.fr/ciprian
www.teodorov.ro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100307/447bff7e/attachment.htm

Mariano Martinez Peck

2012-01-28 12:33:02 UTC

the question is, do you have projects to be part of GSoC Gilad ?

If true, send me the title of the project, a description and if possible,
titles as "Technical Details", "Benefits to the Student" and "Benefits to
the Community".

The deadline is....2 or 3 days :)

Ahh each project needs a mentor. Those projects without mentors will be
discarded. The same mentor cannot be in more than one project.

Cheers

Mariano

Post by Gilad Bracha
Josh,
Thanks for the thought. I can certainly mentor such work - I'm already
doing this with a number of Masters students. That said, I have no idea if
the ESUG community cares to include Newspeak related stuff in its list of
projects. My honest impression is that Newspeak doesn't really appeal to
the Smalltalk community, though I'd love to be proven wrong.
One reason for this apparent lack of interest is that might be the fact
that Newspeak is not really a Smalltalk dialect. It's more of a Smalltalk
descendant. It is quite easy to migrate from Smalltalk to Newspeak however;
we've done that with a substantial body of code (most of the Strongtalk
version of the blue book libraries, our own GUI and IDE code and a few other
things) and the result is generally better than the original because of
Newspeak's modularity properties.

Post by Josh Gargus
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?

Post by Josh Gargus
Cheers,
Josh

Cheers, Gilad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100307/05107fef/attachment.htm

keith

2012-01-28 12:32:58 UTC

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100306/2a5744ff/attachment.htm

Ralph Johnson

2012-01-28 12:32:58 UTC

Post by keith
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100306/9e7b3ba8/attachment.htm

Ken G. Brown

2012-01-28 12:32:58 UTC

This appears to be it
<http://www.squeaksource.com/Bob.html>

Ken G. Brown

Post by keith
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

keith

2012-01-28 12:32:58 UTC

Post by keith
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

squeaksource.com/bob

http://ftp.squeak.org/3.11-obsolete/images/

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100307/2ba9773a/attachment.htm

keith

2012-01-28 12:32:58 UTC

Post by keith
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

squeaksource.com/bob

http://ftp.squeak.org/3.11-obsolete/images/

Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100306/411f0109/attachment.htm

keith

2012-01-28 12:32:58 UTC

An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100307/8c21e90d/attachment.htm

keith

2012-01-28 12:32:58 UTC

I bit superfluous considering this project has already been done.

Keith

Julian Fitzell

2012-01-28 12:32:58 UTC

Post by Mariano Martinez Peck
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

Janko Mivšek

2012-01-28 12:33:00 UTC

Post by Julian Fitzell
+ 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

Paolo Bonzini

2012-01-28 12:33:00 UTC

Post by Janko MivÅ¡ek
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

Janko Mivšek

2012-01-28 12:33:00 UTC

Post by Paolo Bonzini

Post by Janko MivÅ¡ek
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

Paolo Bonzini

2012-01-28 12:33:00 UTC

Post by Janko MivÅ¡ek

Post by Paolo Bonzini
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

Julian Fitzell

2012-01-28 12:33:00 UTC

Post by Janko MivÅ¡ek

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

I'm not suggesting it is the most urgent item, merely that it is
beneficial, well defined (or at least well-scoped :) ), and
potentially interesting for a student.

Gah... have to hit reply-all for cross-posted mailing lists posts... sigh.

Julian

Julian Fitzell

2012-01-28 12:33:00 UTC

Post by Julian Fitzell
+ 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...

The various packages are all derived from the same one originally.? They
have different GUis, and often have to interface to the system differently
because different versions of Smalltalk have different APIs for classes and
methods.? Does Grease provide an API for classes and methods?? Does it have
a GUI?? Other than that, they will differ only because people have added
features to one version and not to the other.? So, which version did you
want to use?

Niall Ross

2012-01-28 12:33:21 UTC

Dear Julian,
I believe the VW, VA and Dolphin versions are close as regards the
model layer. VW has made some low-level changes to support namespaces.
In the past, VW and VA also used the same UI, thanks to a porting layer
provided by John, but they are moving apart; however the custom
refactoring project has maintained compatibility between its VA and VW3
versions until now (but are expecting to drop this). Dolphin simply
connected the model-layer RB to their existing browser. (Joseph Pelrine
et al provided the same to VA in addition to the separate RB UI.)

Whoever ported the Squeak RB took a mix of approaches, with shortcuts in
the BrowserEnvironment hierarchy that I've always wanted to fix. I've
never made the time, or recruited a Squeaker to port the custom
refactoring add-ons to Squeak and in the process make the fixes.

FYI, at the moment, the project is both integrating custom refactoring
ideas bit by bit into either mainstream VW or compatible goodies (some
are in 7.7, more will be in 7.8) and backporting some VW corrections to
the main stream of custom refactoring.

For the model-layer, Grease is probably little needed - may simplify one
or two things.

Yours faithfully
Niall Ross

Post by Julian Fitzell

The various packages are all derived from the same one originally. They
have different GUis, and often have to interface to the system differently
because different versions of Smalltalk have different APIs for classes and
methods. Does Grease provide an API for classes and methods? Does it have
a GUI? Other than that, they will differ only because people have added
features to one version and not to the other. So, which version did you
want to use?

I know, but they've essentially forked over the years. They may have
been one package once but they certainly aren't now and because of
that they continue to diverge. It may be that Grease isn't needed at
all - I don't know because I haven't dug into it. If all the current
functionality can be done with only ANSI APIs, then great. And no,
obviously the UI will continue to be different between platforms. Just
like Seaside, it's fine to have platform-specific subpackages but the
core should be loadable (ie. it would be nice if it was) on all
platforms.
Julian
_______________________________________________
Esug-list mailing list
http://lists.esug.org/listinfo/esug-list
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Mariano Martinez Peck

2012-01-28 12:33:03 UTC

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100308/4da6bf42/attachment.htm

Gilad Bracha

2012-01-28 12:33:03 UTC

Post by Mariano Martinez Peck

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?

Post by Paolo Bonzini
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100307/35a7e557/attachment.htm

Mariano Martinez Peck

2012-01-28 12:33:03 UTC

Post by Mariano Martinez Peck

Post by Gilad Bracha
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

Post by Gilad Bracha
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:

1. 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 <http://www.opensource.org/licenses/>. 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

Post by Gilad Bracha
On Sun, Mar 7, 2010 at 3:09 PM, Mariano Martinez Peck <

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100308/f788b1ab/attachment.htm

stephane ducasse

2012-01-28 12:33:05 UTC

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

Post by Gilad Bracha
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?
http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#licenses
? 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
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

Yanni Chiu

2012-01-28 12:33:07 UTC

Post by Mariano Martinez Peck
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.

Randal L. Schwartz

2012-01-28 12:33:07 UTC

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
<***@stonehenge.com> <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

Randal L. Schwartz

2012-01-28 12:33:07 UTC

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

Paolo Bonzini

2012-01-28 12:33:05 UTC

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

Gilad Bracha

2012-01-28 12:33:07 UTC

Hi Paolo,

Post by Paolo Bonzini
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.

"It" is ambiguous here. From what I could see, CObjects already has some facilities for automagically deriving bindings from C headers, and in that sense is higher level. While Newspeak has a fair amount of C parsing code, we never got around to adding such auto-magic. We started at the low level because of the considerations Andres mentioned. I believe we could solve them, but it probably goes beyond a SoC project.

On the other hand, the big advantage of aliens is that they do not require a special primitive-like syntactic construct. The Alien implementation itself requires a primitive, but you don't need special syntax to use aliens. Aliens are a better fit with security, though this is probably immaterial to this discussion.

For a discussion of these issues, please see

http://gbracha.blogspot.com/2008/12/unidentified-foreign-objects-ufos.html

(a slightly related discussion of primitives in general is at http://gbracha.blogspot.com/2008/08/foreign-functions-vm-primitives-and.html)

Post by Paolo Bonzini
Gilad, in your experience what % of the bindings you wrote were
Smalltalk and what % was C code?

I'm not sure I understand the question. All our FFI bindings are done the same way, using aliens. No C code is involved - but you do need an intimate understanding of the foreign data representation (how many bytes, basically).

Post by Paolo Bonzini
Did you have any performance
problems that you could fix using more C code?

I assume you are referring to usages of the FFI (I have lots of Smalltalk/Newspeak code that runs slower than C :-) ).

Performance of the FFI has not been an issue. We have a native Windows GUI built upon using aliens, so things get exercised pretty thoroughly. Of course, there is some overhead to using an FFI, and it could perhaps be further improved. I'll let Eliot comment on that if he wants to.

Cheers, Gilad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100308/03a12b25/attachment.htm

Paolo Bonzini

2012-01-28 12:33:07 UTC

Post by Gilad Bracha
"It" is ambiguous here. From what I could see, CObjects already has
some facilities for automagically deriving bindings from C headers, and
in that sense is higher level.

Not so much automagic, but yes---you can say something like

CStruct subclass: #SdlCursor
declaration: #(
(#area (#ptr #CObject))
(#hotX #short)
(#hotY #short)
(#data (#ptr #CObject))
(#mask (#ptr #CObject))
(#save (#ptr #CObject))
(#wmCursor (#ptr #CObject)))
classVariableNames: ''
poolDictionaries: ''
category: 'LibSDL-Core'

and the SdlCursor class will have all the required accessors. (There is
similarly CUnion).

The other more high-level feature of CObject, as far as I can see, is
that it includes classes like CInt, CDouble, CString, CPtr or CArray.
These embed the ABI knowledge; they support C-like pointer arithmetic
(i.e. incrementing a CInt is equivalent to incrementing an int *). Like
an Alien, they can represent any of malloced/GCed/foreign storage,
though the arithmetic has bounds checking only if the backing store for
the CObject is garbage collected. They are also the basic building
blocks for CStruct/CUnion.

Post by Gilad Bracha
On the other hand, the big advantage of aliens is that they do not
require a special primitive-like syntactic construct. The Alien
implementation itself requires a primitive, but you don't need special
syntax to use aliens.

Though there is a special primitive-like construct in GNU Smalltalk, it
is just a shortcut that is expanded at compile time to a normal
primitive. In particular it expands to one of these templates

descr callInto: nil. ^self
^(descr callInto: ValueHolder now) value
^(descr callInto: ValueHolder now) value narrow

depending on the return type of the call (respectively void, anything
but CObject, and CObject), where descr is a compile-time literal and
CFunctionDescriptor>>#callInto: returns its argument. This however is
considered an implementation detail, hence the special syntax.

Paolo

Gilad Bracha

2012-01-28 12:33:07 UTC

The other more high-level feature of CObject, as far as I can see, is that
it includes classes like CInt, CDouble, CString, CPtr or CArray. These embed
the ABI knowledge; they support C-like pointer arithmetic (i.e. incrementing
a CInt is equivalent to incrementing an int *). Like an Alien, they can
represent any of malloced/GCed/foreign storage, though the arithmetic has
bounds checking only if the backing store for the CObject is garbage
collected. They are also the basic building blocks for CStruct/CUnion.

Some of this sort of thing exists in the module CAPI in the Newspeak
version. A fair amount of convenience is available using such wrappers. We
also have a Win32API module. These things only contain functionality we
actually used, but they do help avoid repeating some of the boiler plate. A
higher level mechanism is certainly useful.

--
Cheers, Gilad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100308/2a2f0104/attachment.htm

Eliot Miranda

2012-01-28 12:33:10 UTC

Post by Gilad Bracha
I'm all for it, and hope that John or Eliot can mentor.

I would like to mentor something in this area, but I think the basic goal of
a cross-platform system is not achievable in GSoC this summer. A
specification of a non-blocking architecture and a reference implementation
may be possible. Cross-platform is too big for a summer project and will
require input from dialects and vendors. What affects my thinking is the
following:

1. I designed and implemented the VisualWorks THAPI system, a threaded
extension to the VisualWorks FFI.

2. I have a functional prototype of a multi-threaded FFI for the Cog VM
based on David Simmons' VMs.

1's architecture is poor, being complex, slow and not very general (allows
only FFI calls to be threaded).
2's architecture is rather simple, rather fast and very general (allows
threading to be much more widely used, e.g. calls within plugins can be made
threaded by surrounding them with two calls, disownVM and ownVM).

3. I have looked at marshalling semantics in the context of the VW FFI,
Andreas' Squeak FFI & Alien, and am still of the opinion, one shared by
David,
- that the generation of marshalling stubs has to be lifted up into
Smalltalk based on simple ABI compilers that somehow (e.g. through RTL)
communicate down to a JIT that generates and caches marshalling code (i.e.
that VM attempts to interpret simplified call specs, as happens in the VM
and Squeak FFIs are in general doomed to poor performance and bugs)
- that type coercion code also has to be lifted (e.g. character conversions
on strings, null termination, type coercion)
- that one be able to depend on a pinning garbage collector to deal with the
issues of passing objects through the FFI (although there are workaround
hacks that can serve temporarily)

I don't see the point of spending a GSoC trying to implement an obsolete
(unthreaded, lowest-common-denominator) cross-platform FFI; it won't get
used. I do see benefit in an open-source reference implementation that
provides some of the above (at least threading/non-blocking). If people
agree that an open-source reference implementation is worth pursuing, then I
will happily mentor. 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 :) ). There are other starting
points (current Squeak VMs, GST, Newspeak).

But the outline above is a move towards better cross-platform commonality,
not less, because it's an architecture in which the image does more (type
coercion, compiling call signatures to RTL sequences) and the VM (except for
the threading ;) ) does less. And so this direction does lead towards
better cross-platform facilities.

best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100309/1fcc5664/attachment.htm

Paolo Bonzini

2012-01-28 12:33:15 UTC

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.

Isn't this what you wanted to allow companies to do, when you chose the
MIT license? I don't understand, why should you care?

I see some irony...

Paolo

Stéphane Ducasse

2012-01-28 12:33:21 UTC

What the starting point is will depend on to what extent Cog has

Post by Eliot Miranda
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.

Isn't this what you wanted to allow companies to do, when you chose the
MIT license? I don't understand, why should you care?
I see some irony...

Not me. Freedom of choice is a political attitude. I understand GPL goal but I
do not adhere to it. I respect people pushing it but not in my way. I'm not sure
that we should debate that here but we do not have the single answer.

Stephen Pair

2012-01-28 12:33:22 UTC

Post by StÃ©phane Ducasse

On Wed, Mar 10, 2010 at 7:37 PM, Nicolas Cellier <

What the starting point is will depend on to what extent Cog has

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.

Isn't this what you wanted to allow companies to do, when you chose the
MIT license? I don't understand, why should you care?

We shouldn't. Well, except if previous annoucements strongly
suggested this would be the case...

Post by StÃ©phane Ducasse

I see some irony...

Not me. Freedom of choice is a political attitude. I understand GPL goal

but I

Post by StÃ©phane Ducasse
do not adhere to it. I respect people pushing it but not in my way. I'm

not sure

Post by StÃ©phane Ducasse
that we should debate that here but we do not have the single answer.

Not sure the goals differ much, but indeed these are two radically
different strategies.
The question is: would COG have ever started under a GPL derivative?
Who knows?
Since it did not happen, current choice is between an hypothetical
something MIT or nothing...
Bah, at least we already get a closure VM in Squeak.

I would guess that Cog would not have started because if squeak were under
GPL, squeak wouldn't have been used by Teleplace to begin with...of course,
that's just speculation on my part (and Cog may very well have gotten
started under different circumstances).

I actually appreciate the role that the GPL played in the evolution of the
GNU Unix tools. Without GPL, the Unix vendors would very likely have simply
co-opted that code and sucked the life out of the GNU project very early on.
I don't believe GPL should be used for squeak however (and I think there
are general problems with that license as it relates to Smalltalk code (i.e.
it was written with C like linking in mind)).

What I believe is needed is a license that has time limited, GPL like
requirements for sharing enhancements and after that time period reverts to
a pure and simple MIT license (where the conversion date can be chosen by
the author). It is essential that such a date be specified in the license
upon initial release. Each new version would also come under a new license
that could have a timeout further into the future. That would help ensure
that a project isn't co-opted early on by commercial interests while
simultaneously ensuring that at a defined point in time, it becomes
available for anyone to use without any restrictions of any kind (except the
limitations on liability in the MIT license). It also would not preclude
commercial interests from paying for a different license in that early
period.

- Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100311/cde3d7f4/attachment.htm

Stéphane Ducasse

2012-01-28 12:33:21 UTC

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

John M McIntosh

2012-01-28 12:33:21 UTC

Ok, I'm a bit behind in my email but I would help mentor if need be. Just to ensure it works ok on os-x and also to ensure support for objective-c creeps in there somehow since Apple's direction is towards everything in Objective-C frameworks versus "C" library calls.

Post by Gilad Bracha
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?
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

--
===========================================================================
John M. McIntosh <***@smalltalkconsulting.com> Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100310/0aff3f05/attachment.htm

Paolo Bonzini

2012-01-28 12:33:05 UTC

Post by Mariano Martinez Peck
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

Paolo Bonzini

2012-01-28 12:33:09 UTC

On Tue, Mar 9, 2010 at 16:10, John O'Keefe

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

John O'Keefe

2012-01-28 12:33:13 UTC

I am willing to co-mentor a Grease project and/or a portable TCPIP
implementation (we will need this for the OpenSSL project anyway).

John

Post by Paolo Bonzini

Post by Mariano Martinez Peck
We need to write a title, a little description and if possible titles

Post by Mariano Martinez Peck
"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

Post by Mariano Martinez Peck
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
_______________________________________________
Esug-list mailing list
http://lists.esug.org/listinfo/esug-list

--
John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100309/00230582/attachment.htm

Stéphane Rollandin

2012-01-28 12:32:57 UTC

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

Bert Freudenberg

2012-01-28 12:33:01 UTC

* MIDI support for the linux VM
Basically implement the MIDI plugin that has been missing for years in the linux VM

That would be nice - though there is a t least some MIDI support in the ALSA plugin IIRC - have you looked at that?

Post by StÃ©phane Rollandin
* DBus support for all platforms
(don't really know about the current state of affairs here)

Is DBus used on anything but Linux? In any case, the DBusPlugin is a wrapper for libdbus so I'd expect it to just work ...

- Bert -

Stéphane Rollandin

2012-01-28 12:33:01 UTC

Post by StÃ©phane Rollandin
* MIDI support for the linux VM
Basically implement the MIDI plugin that has been missing for years in the linux VM

That would be nice - though there is a t least some MIDI support in the ALSA plugin IIRC - have you looked at that?

no. any pointer ?

Post by StÃ©phane Rollandin
* DBus support for all platforms
(don't really know about the current state of affairs here)

Is DBus used on anything but Linux? In any case, the DBusPlugin is a wrapper for libdbus so I'd expect it to just work ...

there is a DBus port for Windows; Emacs support it, for example. I don't
know about other platforms.

Stef

Bert Freudenberg

2012-01-28 12:33:01 UTC

Post by StÃ©phane Rollandin
* MIDI support for the linux VM
Basically implement the MIDI plugin that has been missing for years in the linux VM

That would be nice - though there is a t least some MIDI support in the ALSA plugin IIRC - have you looked at that?

no. any pointer ?

http://squeakvm.org/svn/squeak/trunk/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc

- Bert -

Stéphane Rollandin

2012-01-28 12:33:01 UTC

Post by Bert Freudenberg
http://squeakvm.org/svn/squeak/trunk/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc

ok, thanks. is this part of the linux VM ?

Bert Freudenberg

2012-01-28 12:33:01 UTC

Post by Bert Freudenberg
http://squeakvm.org/svn/squeak/trunk/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc

ok, thanks. is this part of the linux VM ?

I think so.

- Bert -

Stéphane Rollandin

2012-01-28 12:33:01 UTC

actually I have not made myself clear about the MIDI support:

currently I'm developing a musical composition framework on Windows,
where the MIDIplugin works fine. on linux, there is no MIDIplugin built
in the VM

so I have this test:

| plugins |

plugins _ (SmalltalkImage current listBuiltinModules, SmalltalkImage
current listLoadedModules) collect: [:pn | (pn findTokens: ' ') first
asSymbol].

self assert: (plugins identityIncludes: #MIDIPlugin).

... which fails in linux, and I would like to have it green, and use the
MIDIplugin exactly as in Windows.

is this possible now ? is it possible from the code you gave me ?

best,

Stef

Bert Freudenberg

2012-01-28 12:33:01 UTC

currently I'm developing a musical composition framework on Windows, where the MIDIplugin works fine. on linux, there is no MIDIplugin built in the VM
| plugins |
plugins _ (SmalltalkImage current listBuiltinModules, SmalltalkImage current listLoadedModules) collect: [:pn | (pn findTokens: ' ') first asSymbol].
self assert: (plugins identityIncludes: #MIDIPlugin).
... which fails in linux, and I would like to have it green, and use the MIDIplugin exactly as in Windows.
is this possible now ? is it possible from the code you gave me ?
best,
Stef

Maybe. But be aware that your test is faulty. #listLoadedModules only lists loaded plugins and does not find available external plugins. You should remove #listBuiltinModules from your test, and ensure the plugin was loaded before (by calling any primitive in that module).

- Bert -

Stéphane Rollandin

2012-01-28 12:33:01 UTC

Post by Bert Freudenberg
Maybe. But be aware that your test is faulty.

thanks, I will fix it.

still, my question remains: can we at the moment have a MIDI support in
linux ? like, just be able to use SimpleMIDIPort ?

AFAIK this has been missing for years.

regards,

Stef

Bert Freudenberg

2012-01-28 12:33:02 UTC

Post by Bert Freudenberg
Maybe. But be aware that your test is faulty.

thanks, I will fix it.
still, my question remains: can we at the moment have a MIDI support in linux ? like, just be able to use SimpleMIDIPort ?

I don't know. Try it. Report back if it loads the plugin, and if it works.

Post by StÃ©phane Rollandin
AFAIK this has been missing for years.

Interest has been low. But the ALSA MIDI support was added 3 years ago and nobody much cared.

If you really care, dig into the C code and make it work - the VM maintainers happily accept patches. :)

- Bert -

Stéphane Rollandin

2012-01-28 12:33:02 UTC

Post by StÃ©phane Rollandin
still, my question remains: can we at the moment have a MIDI support in linux ? like, just be able to use SimpleMIDIPort ?

I don't know. Try it. Report back if it loads the plugin, and if it works.

oh, it doesn't. there is no MIDI support in the linux VM, I have already
said so a few times now, let's say it's the last time I say it :)

Post by Bert Freudenberg
If you really care, dig into the C code and make it work - the VM maintainers happily accept patches. :)

no, I won't, sorry, it's not trivial and I have no experience in that
domain.

cheers,

Stef

David T. Lewis

2012-01-28 12:33:02 UTC

(cc to vm-dev list)

Post by StÃ©phane Rollandin
still, my question remains: can we at the moment have a MIDI support in
linux ? like, just be able to use SimpleMIDIPort ?
AFAIK this has been missing for years.

Stef,

I don't know the status of MIDIPlugin support on Linux but I can tell
you that the plugin does compile, and I think that it is distributed
as a builtin plugin in Ian's latest VM at http://squeakvm.org/unix/.

I'm afraid that I know very little about MIDI, and I don't have any
actual MIDI devices to test on (*), but if you (or someone else) are
in a position to do the testing, perhaps we can collaborate to get it
working. I think that this plugin was done originally for Windows,
so it might be necessary to do some work mapping it properly to device
names on Linux. We did something like this recently for the SerialPlugin
to make it work with USB serial devices, and I'm sure it would be
possible to do something similar for MIDI if that is the issue.

Dave

(*) Actually maybe I do have such a device, I'll have to go read the
manual and see if I can figure out what it does.

Stéphane Rollandin

2012-01-28 12:33:02 UTC

hi,

thanks for your help !

actually no special hardware is needed to test the MIDI plugin, packages
timidity and pmidi are enough

Timidity is a soft synth; it can be started in server mode with command

timidity -iA -B2,8 -Os1l -s 44100

now we have a list of available MIDI ports with command

pmidi -l

in my system this lists 6 ports. one is enough for testing: in a Squeak
workspace, evaluate

SimpleMIDIPort primPortCount

I get 0, because the primitive failed.

there is indeed a so.MIDIPlugin file in the VM library folder, but to my
eyes it does not seem to work. any help appreciated... this is with the
latest VM, 3.11.3-2135

best,

Stef

David T. Lewis

2012-01-28 12:33:02 UTC

Post by StÃ©phane Rollandin
hi,
thanks for your help !
actually no special hardware is needed to test the MIDI plugin, packages
timidity and pmidi are enough
Timidity is a soft synth; it can be started in server mode with command
timidity -iA -B2,8 -Os1l -s 44100
now we have a list of available MIDI ports with command
pmidi -l
in my system this lists 6 ports. one is enough for testing: in a Squeak
workspace, evaluate
SimpleMIDIPort primPortCount
I get 0, because the primitive failed.

OK, I'll have a look at it. Thanks for the pointers.

I tried running "pmidi -l" on my laptop, and get this:

***@linux-6xfc:~/squeak> pmidi -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0

So that probably means I have a midi device on my sound card. I guess
that should be all I need to test the plugin, right?

Dave

Stéphane Rollandin

2012-01-28 12:33:02 UTC

Post by David T. Lewis
Port Client name Port name
14:0 Midi Through Midi Through Port-0
So that probably means I have a midi device on my sound card.

or a software port (you will have another one if your start jack, for
example)

Post by David T. Lewis
I guess
that should be all I need to test the plugin, right?

I think so, yes.

Stef

Gary Dunn

2012-01-28 12:33:02 UTC

* MIDI support for the linux VM
Basically implement the MIDI plugin that has been missing for years in the linux VM

That would be nice - though there is a t least some MIDI support in the ALSA plugin IIRC - have you looked at that?

Post by StÃ©phane Rollandin
* DBus support for all platforms
(don't really know about the current state of affairs here)

Is DBus used on anything but Linux? In any case, the DBusPlugin is a wrapper for libdbus so I'd expect it to just work ...

FreeBSD uses dbus, at least when Gnome is installed. I think KDE also
uses it.

--
Gary Dunn, Honolulu
***@aloha.com
http://openslate.net/
http://e9erust.blogspot.com/
Sent from Slate001

Mariano Martinez Peck

2012-01-28 12:32:57 UTC

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

Post by Mariano Martinez Peck
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...
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100306/708ade65/attachment.htm

Jan Vrany

2012-01-28 12:32:58 UTC

Hi there,

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.

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

James Foster

2012-01-28 12:33:00 UTC

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.

I'd be willing to mentor a Namespaces for Pharo/Squeak project. See http://wiki.squeak.org/squeak/5948.

James Foster

Geert Claes

2012-01-28 12:33:09 UTC

Post by James Foster

I'd be willing to mentor a Namespaces for Pharo/Squeak project. See
http://wiki.squeak.org/squeak/5948.
James Foster

If I could vote I would vote for your idea :)

--
View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582770p1586073.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.

Torsten Bergmann

2012-01-28 12:33:00 UTC

James Foster

Post by James Foster
I'd be willing to mentor a Namespaces for Pharo/Squeak project.

That would be really cool to have. I liked the ones in Smalltalk/MT
where I can write

MyNamespace::MyClass

Thx
T.

--
GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Frank Shearar

2012-01-28 12:33:01 UTC

Post by James Foster
James Foster

Post by James Foster
I'd be willing to mentor a Namespaces for Pharo/Squeak project.

That would be really cool to have. I liked the ones in Smalltalk/MT
where I can write
MyNamespace::MyClass

And G?ran hasn't replied yet?!

frank

Gary Dunn

2012-01-28 12:33:02 UTC

Post by Mariano Martinez Peck
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...
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.
Cheersg for the application period to open
Mariano

Please see the Open Slate Ideas page for the list of projects we will be
submitting.

http://openslate.net/ideas.html

Have been waiting for the application period to open, which it just did.
I don't think any of ours are suitable for Smalltalk beyond Squeak, but:

1. Will there be a Squeak submission, which OSP could join? From
this it sounds like "no."

2. Does anyone think any of ours should go forward to ESUG?

--
Gary Dunn, Honolulu
***@aloha.com
http://openslate.net/
http://e9erust.blogspot.com/
Sent from Slate001

Josh Gargus

2012-01-28 12:33:04 UTC

Yoshiki and I are willing to mentor a project to add OpenCL support to Kedama. We're currently hammering out our project description; hopefully we'll have something tomorrow.

Thanks,
Josh

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100307/1cd20cba/attachment.htm

Josh Gargus

2012-01-28 12:33:08 UTC

Here is the project description that Yoshiki and I arrived at:

Kedama is an extension of the Etoys tile-scripting environment to support exploration of the emergent properties of decentralized systems, such as traffic jams or ant colonies, by simulating them with massive numbers of end-user scriptable objects. As part of Etoys, Kedama has a large installed base of users; in particular, it is installed on each XO computer produced by the One Laptop Per Child project (http://laptop.org). OpenCL is a low-level, industry-standard framework for performing general-purpose computation on the GPU.

The goal of the project is to take advantage of the enormous power of modern GPUs to enable end-users to construct larger and more elaborate simulations. The successful applicant will use the existing Squeak OpenCL bindings to implement the current Kedama primitives, and to implement a GPU-friendly memory model (although Kedama's end-user model is massively parallel, the current implementation takes some reasonable shortcuts in it's CPU implementation). Once these goals have been achieved, performance will be profiled to identify the hotspots most amenable to optimization (we have an idea where these will be, but you never know until you measure). Based on this data and the amount of time remaining, suitable optimizations will be chosen and implemented.

The precise details of the project are open-ended, and there is no shortage of technical challenges for a sophisticated applicant to solve. However, since the intent is to make the result immediately available to the existing Kedama/Etoys community, it is better to set conservative goals to ensure a production-quality result. For similar reasons, it is essential to minimize changes to Kedama's end-user semantics, so that existing Kedama programs continue to run. The applicant's proposal should reflect this, although they are encouraged to propose a plan with optional, more ambitious goals that will be attempted if time permits.

In addition to learning cutting-edge GPGPU techniques, the student will gain insight into the tension between end-user accessibility and maximum performance for a real community of users. Two separate communities will benefit from this project: Squeak and Kedama/Etoys. The educational goals of Kedama/Etoys will be served by enabling users to undertake even more ambitious simulations. Squeak will gain an application that provides an example of using massively-parallel hardware from a highly dynamic language. Given Squeak's popularity in higher education, and the interest already shown in Squeak's young OpenCL bindings, this project will be sure to draw the interest of many talented students in the years to come.

Thank you Mariano, Janko, and ESUG for helping Squeak to benefit from GSoC!

Cheers,
Josh

Post by Josh Gargus
Yoshiki and I are willing to mentor a project to add OpenCL support to Kedama. We're currently hammering out our project description; hopefully we'll have something tomorrow.
Thanks,
Josh

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100308/41be34d1/attachment.htm

Josh Gargus

2012-01-28 12:33:11 UTC

OK, here's a modified proposal with the sections clearly labeled.

Cheers,
Josh

Title:
OpenCL for Kedama

Mentors:
Josh Gargus and Yoshiki Ohshima

Level:
Moderate to Difficult

Overview:
Kedama is an extension of the Etoys tile-scripting environment to support exploration of the emergent properties of decentralized systems, such as traffic jams or ant colonies, by simulating them with massive numbers of end-user scriptable objects. As part of Etoys, Kedama has a large installed base of users; in particular, it is installed on each XO computer produced by the One Laptop Per Child project (http://laptop.org). OpenCL is a low-level, industry-standard framework for performing general-purpose computation on the GPU.

Technical Details:
The goal of the project is to take advantage of the enormous power of modern GPUs to enable end-users to construct larger and more elaborate simulations. The successful applicant will use the existing Squeak OpenCL bindings to implement the current Kedama primitives, and to implement a GPU-friendly memory model (although Kedama's end-user model is massively parallel, the current implementation takes some reasonable shortcuts in it's CPU implementation). Once these goals have been achieved, performance will be profiled to identify the hotspots most amenable to optimization (we have an idea where these will be, but you never know until you measure). Based on this data and the amount of time remaining, suitable optimizations will be chosen and implemented.

The precise details of the project are open-ended, and there is no shortage of technical challenges for a sophisticated applicant to solve. However, since the intent is to make the result immediately available to the existing Kedama/Etoys community, it is better to set conservative goals to ensure a production-quality result. For similar reasons, it is essential to minimize changes to Kedama's end-user semantics, so that existing Kedama programs continue to run. The applicant's proposal should reflect this, although they are encouraged to propose a plan with optional, more ambitious goals that will be attempted if time permits.

Benefits to Student:
The student will improve their skills in two main areas: high-performance computing and end-user design. They will implement cutting-edge GPGPU techniques in Squeak, and learn how to efficiently harness the power of the GPU from a highly-dynamic language (i.e. how the Squeak/OpenCL binding is implemented). Secondly, the student will gain insight into a real-world design problem: the tension between end-user accessibility and maximum performance for a sizable community of users.

Benefits to Community:
Two separate communities will benefit from this project: Squeak and Kedama/Etoys. The educational goals of Kedama/Etoys will be served by enabling users to undertake even more ambitious simulations. Squeak will gain an application that provides an example of using massively-parallel hardware from a highly dynamic language. Given Squeak's popularity in higher education, and the interest already shown in Squeak's young OpenCL bindings, this project will be sure to draw the interest of many talented students in the years to come.

Post by Josh Gargus
Kedama is an extension of the Etoys tile-scripting environment to support exploration of the emergent properties of decentralized systems, such as traffic jams or ant colonies, by simulating them with massive numbers of end-user scriptable objects. As part of Etoys, Kedama has a large installed base of users; in particular, it is installed on each XO computer produced by the One Laptop Per Child project (http://laptop.org). OpenCL is a low-level, industry-standard framework for performing general-purpose computation on the GPU.
The goal of the project is to take advantage of the enormous power of modern GPUs to enable end-users to construct larger and more elaborate simulations. The successful applicant will use the existing Squeak OpenCL bindings to implement the current Kedama primitives, and to implement a GPU-friendly memory model (although Kedama's end-user model is massively parallel, the current implementation takes some reasonable shortcuts in it's CPU implementation). Once these goals have been achieved, performance will be profiled to identify the hotspots most amenable to optimization (we have an idea where these will be, but you never know until you measure). Based on this data and the amount of time remaining, suitable optimizations will be chosen and implemented.
The precise details of the project are open-ended, and there is no shortage of technical challenges for a sophisticated applicant to solve. However, since the intent is to make the result immediately available to the existing Kedama/Etoys community, it is better to set conservative goals to ensure a production-quality result. For similar reasons, it is essential to minimize changes to Kedama's end-user semantics, so that existing Kedama programs continue to run. The applicant's proposal should reflect this, although they are encouraged to propose a plan with optional, more ambitious goals that will be attempted if time permits.
In addition to learning cutting-edge GPGPU techniques, the student will gain insight into the tension between end-user accessibility and maximum performance for a real community of users. Two separate communities will benefit from this project: Squeak and Kedama/Etoys. The educational goals of Kedama/Etoys will be served by enabling users to undertake even more ambitious simulations. Squeak will gain an application that provides an example of using massively-parallel hardware from a highly dynamic language. Given Squeak's popularity in higher education, and the interest already shown in Squeak's young OpenCL bindings, this project will be sure to draw the interest of many talented students in the years to come.
Thank you Mariano, Janko, and ESUG for helping Squeak to benefit from GSoC!
Cheers,
Josh

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100309/1b439347/attachment.htm

stan shepherd

2012-01-28 12:33:14 UTC

I know the deadline approaches, however- how does the community feel
about a project to implement a real demonstration system (along the
lines of defunct Sushi store)? Presumably in Seaside, but whichever
framework the community/mentor/student decided on. With a nice
interface using (again presumptively) jQueryUI to give a pleasant
end-user experience. Similarly implementing a persistence solution.
The idea is to present potential newcomers to Smalltalk with a viable
stack that could be picked up as is, to give a starting point for
developing web applications. Potentially they could simply make a
hosted copy, on the same server.

The idea would be that on the various examples page, you could access
an e-commerce site running a Smalltalk technology stack. Ideally
really selling something Smalltalk related, (proceeds to eg ESUG),
maybe also an Amazon affiliate page . If you liked it, you could copy
the whole project, change eg your Paypal details, change your
products, and be in business. (Obviously there are real world
considerations - this is the concept). And coders looking for examples
would see code that was fully completed, not onClick: (... some alert
saying you clicked but no real example of how to handle it, eg how to
transfer the order line details to the payments server).

I think it would do wonders for the take-up of Smalltalk.

If people like the idea in general, I'm happy to write up the brief. I
don't think i'm the right person for the mentor, but you know who you
are ;)

For the student, they would get experience in implementing the
application itself , as well as assembling the stack. They could be
the next Auctomatic founders.

Do people think it's useful for me to develop a proposal?

Cheers, ..Stan

PS I realise that picking a component as part of the stack is fraught
with possibilities of offending supporters of an alternative project.
But more Smalltalkers overall means more potential users of each
project

Post by Mariano Martinez Peck
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...
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
_______________________________________________
seaside mailing list
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Stéphane Ducasse

2012-01-28 12:33:21 UTC