Google Summer Of Code 2010 news!!!
Locked
12345
12345
OpenCL support for Kedama [Re: [squeak-dev] Google Summer Of Code 2010 news!!!]
 
|
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 On Mar 6, 2010, at 4:04 AM, Mariano Martinez Peck wrote: Hi smalltalkers. I have been asked to be the admin of GSoC 2010. The backup or second admin is Janko Mivšek. As you may know, Squeak has participated in GSoC 2007, 2008 but failed (not accepted) in 2009. We are not sure if we will succeed this year but we will try to do as much as possible. |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Gilad Bracha-2
On Mon, Mar 8, 2010 at 00:24, Gilad Bracha <[hidden email]> wrote:
> I'm all for it, and hope that John or Eliot can mentor. Datapoints I'll add: > There is some support for parsing C headers in the Newspeak system. > Aliens have been ported to Strongtalk as well as Squeak. > Finally - what licensing would apply if GNU Smalltalk were used? GPL is a > big problem. Even LGPL elicits an immune response in a lot of commercial > contexts. Is there a GSoC policy on this? Last year's GST project was released under MIT license. The GST distribution includes in fact several MIT packages without relicensing it. It is also perfectly possible to develop a single GSoC under a variety of licenses (GPL/LGPL for code that will go in GNU Smalltalk, MIT for something else). If there is need, I'll take care with the student of the FSF copyright assignment fo GST-specific code. In other words, licensing is the least of the problems. BTW, I took a look at Aliens and it would be possible to port CObject to Squeak basing it on Aliens, since it provides a higher-level framework. Doing vice-versa would also be possible. A description of CObject can be found starting at http://www.gnu.org/software/smalltalk/manual/html_node/C-and-Smalltalk.html#C-and-Smalltalk Gilad, in your experience what % of the bindings you wrote were Smalltalk and what % was C code? Did you have any performance problems that you could fix using more C code? Paolo |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this 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 |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Paolo Bonzini-2
Hi Paolo,
On Mar 7, 2010, at 11:52 PM, Paolo Bonzini wrote:
"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 (a slightly related discussion of primitives in general is at http://gbracha.blogspot.com/2008/08/foreign-functions-vm-primitives-and.html)
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 |
Re: [smalltalk-research] Aliens and CObject
|
|
On 03/08/2010 04:07 PM, Gilad Bracha wrote:
> > "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. > 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 |
Re: [smalltalk-research] Aliens and CObject
|
|
On Mon, Mar 8, 2010 at 7:29 AM, Paolo Bonzini <[hidden email]> wrote:
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 |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by stephane ducasse-2
stephane ducasse wrote:
> Mariano > > Well I do not know anybody writing code under LGPL in Smalltalk. > So this is an issue. I think that having a license mess will not help. So we do not care about the fact that the project > use a apporved license, we care that people can/will use it afterwards. > So LGPL is not a good idea. GLORP is LGPL, with a subsequently added explanation of how the the license should be interpreted in a Smalltalk context. INAL, but this still seems muddy, since it's unclear whether or not the author's interpretation and intentions would override the actual license, which is LGPL. Or, is it the case that the actual license is LGPL + author addendums - gah, another license mess. |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
>>>>> "Yanni" == Yanni Chiu <[hidden email]> writes:
Yanni> GLORP is LGPL, with a subsequently added explanation of how the the Yanni> license should be interpreted in a Smalltalk context. INAL, but this Yanni> still seems muddy, since it's unclear whether or not the author's Yanni> interpretation and intentions would override the actual license, which Yanni> is LGPL. Or, is it the case that the actual license is LGPL + author Yanni> addendums - gah, another license mess. And I believe some heavyweights (with actual lawyers they paid) have already weighed in that the LGPL is equivalent to the *GPL* in a Smalltalk context, so unless the code is explicitly dual-licensed with a more permissive license as well, it taints the entire distro. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
>>>>> "Randal" == Randal L Schwartz <[hidden email]> writes:
Randal> And I believe some heavyweights (with actual lawyers they paid) have Randal> already weighed in that the LGPL is equivalent to the *GPL* in a Randal> Smalltalk context, so unless the code is explicitly dual-licensed with Randal> a more permissive license as well, it taints the entire distro. Here's the reference: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124027.html -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: OpenCL support for Kedama [Re: [squeak-dev] Google Summer Of Code 2010 news!!!]
|
|
In reply to this post by Josh Gargus
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 On Mar 7, 2010, at 11:33 PM, Josh Gargus wrote:
|
Re: [Seaside] Google Summer Of Code 2010 news!!!
Administrator
|
In reply to this post by jgfoster
If I could vote I would vote for your idea :) |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Paolo Bonzini-2
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 On Mon, Mar 8, 2010 at 2:54 AM, Paolo Bonzini <[hidden email]> wrote: > We need to write a title, a little description and if possible titles like -- John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc. |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
On Tue, Mar 9, 2010 at 16:10, John O'Keefe
<[hidden email]> wrote: > I am willing to co-mentor a Grease project and/or a portable TCPIP > implementation (we will need this for the OpenSSL project anyway). I can contribute the GNU Smalltalk TCP/IP implementation under whatever license. It's all written by me(*) so I can relicense it. (*) see http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f=packages/sockets/ChangeLog;h=ab405c72a1698ce00bac93965fc856ef0b3d08ce;hb=HEAD UnixStream.st is not anymore part of the package, and Nicolas Burrus' work is not present anymore since I introduce IPv6 support. Paolo |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Gilad Bracha-2
On Sun, Mar 7, 2010 at 3:24 PM, Gilad Bracha <[hidden email]> wrote:
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 |
Re: OpenCL support for Kedama [Re: [squeak-dev] Google Summer Of Code 2010 news!!!]
|
|
In reply to this post by Josh Gargus
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. On Mar 8, 2010, at 10:55 PM, Josh Gargus wrote:
|
|
|
In reply to this post by Julian Fitzell-2
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 Julian Fitzell wrote: >On Sat, Mar 6, 2010 at 11:41 PM, Ralph Johnson <[hidden email]> wrote: > > >>>+ 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? >> >> > >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 >[hidden email] >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 >______________________________________________________________________ > > > > > |
Re: [Seaside] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Mariano Martinez Peck
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 On 6 March 2010 12:04, Mariano Martinez Peck <[hidden email]> wrote: > Hi smalltalkers. I have been asked to be the admin of GSoC 2010. The backup > or second admin is Janko Mivšek. As you may know, Squeak has participated in > GSoC 2007, 2008 but failed (not accepted) in 2009. We are not sure if we > will succeed this year but we will try to do as much as possible. > > We think that one of the most important reasons why we failed in 2009 is > that Google was looking for bigger communities that Squeak. This is why this > year we all go under the ESUG umbrella. We present ESUG as the mentor > organization and we cover ALL open-source Smalltalk dialects, not only > Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all invited to > participate. Also cross platform projects like Seaside, AidaWeb, Magma, etc > are welcome. > > <forThoseWhoDoesntKnowWhatGSoCIs> > It is a Google program that support (money) students to work on different > open-source projects. Google doesn't talk or manage directly to the students > but trough "Mentoring Organisations". Those organizations have to apply to > GSoC. They have to give a lot of information, included a list of > ideas/projects. Each project has a description and a mentor. Then the > students apply for each project. If the organization gets selected by Google > they will tell you how many "slots" they give. Suppose they give 5 but we > have 20 projects....then we vote and the most voted projects win. The > student has to do the project and the mentor has to help and guide him. The > mentor receives 500 USD and the student 4500USD. > For more information read: http://code.google.com/soc/ > </forThoseWhoDoesntKnowWhatGSoCIs> > > The most important thing is the deadlines we have. We started late so we are > very near to the first deadline which is 12/03/2010 (less than one week). > For that deadline we need to submit all the information of the mentor > organization (answering several questions) and give the list of > ideas/projects and the mentors of that. > > We have created a webpage (Thanks Janko!!) where we will put all the > information. We will make this page public soon (we still need to review a > couple of things). > But for the moment we would REALLY appreciate if tell us your ideas. To do > this, just answer to this email. Then we will collect the information and > put in the website. For each idea you need: a short title and a paragraph > (for the moment) explaining the idea. > After, we need that the people that are willing to be mentors start to apply > as mentors...please, consider yourself being mentor. Sometimes it is not > that difficult. I mean, don't be shy as sometimes being helpful, being aware > of the dates, answering emails, etc is more important than the Smalltalk > knoweldege. We can have a lot of ideas, but we need also mentors for that. > We even would need a "substitute" for each mentor... > > Just as an example you can see the ideas of the previous years: > 2007: http://wiki.squeak.org/squeak/5936 > 2008: http://wiki.squeak.org/squeak/6031 > 2009: http://wiki.squeak.org/squeak/6120 > > That's all for the moment. > > Cheers > > Mariano > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > |
Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Eliot Miranda-2
Eliot
> What the starting point is will depend on to what extent Cog has been open sourced (Teleplace may choose to open source single-threaded Cog initially, keeping back the threaded FFI for a while, it may not open source Cog at all; we'll see :) ). May be I the only one to notice the :) which I have problem to understand since for me it announces that COG may not be open-source. What would help teleplace to believe that open-sourcing it would be a win-win situation? A bigger community of contributors ? Making sure that the truck factor does not touch them in case elliot is called under other horizons? Now there is a bootstrap problem. How can a community show that an open-source model is better than a closed one, if the software is closed? STef |
MIT strikes back (was Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!)
|
|
On 03/10/2010 05:06 PM, Stéphane Ducasse wrote:
>> 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 |
Re: [Pharo-project] [Seaside] Google Summer Of Code 2010 news!!!
|
|
In reply to this post by Stan Shepherd
On Mar 10, 2010, at 3:08 PM, stan shepherd wrote: > 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. sounds cool In the same vein having a good support for stupid applications like my comix collection, our bibtext management system, all the applications edit copy search display in list display in report a stuff or a list of stuff. > 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? yes! > > 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 > > > On 6 March 2010 12:04, Mariano Martinez Peck <[hidden email]> wrote: >> Hi smalltalkers. I have been asked to be the admin of GSoC 2010. The backup >> or second admin is Janko Mivšek. As you may know, Squeak has participated in >> GSoC 2007, 2008 but failed (not accepted) in 2009. We are not sure if we >> will succeed this year but we will try to do as much as possible. >> >> We think that one of the most important reasons why we failed in 2009 is >> that Google was looking for bigger communities that Squeak. This is why this >> year we all go under the ESUG umbrella. We present ESUG as the mentor >> organization and we cover ALL open-source Smalltalk dialects, not only >> Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all invited to >> participate. Also cross platform projects like Seaside, AidaWeb, Magma, etc >> are welcome. >> >> <forThoseWhoDoesntKnowWhatGSoCIs> >> It is a Google program that support (money) students to work on different >> open-source projects. Google doesn't talk or manage directly to the students >> but trough "Mentoring Organisations". Those organizations have to apply to >> GSoC. They have to give a lot of information, included a list of >> ideas/projects. Each project has a description and a mentor. Then the >> students apply for each project. If the organization gets selected by Google >> they will tell you how many "slots" they give. Suppose they give 5 but we >> have 20 projects....then we vote and the most voted projects win. The >> student has to do the project and the mentor has to help and guide him. The >> mentor receives 500 USD and the student 4500USD. >> For more information read: http://code.google.com/soc/ >> </forThoseWhoDoesntKnowWhatGSoCIs> >> >> The most important thing is the deadlines we have. We started late so we are >> very near to the first deadline which is 12/03/2010 (less than one week). >> For that deadline we need to submit all the information of the mentor >> organization (answering several questions) and give the list of >> ideas/projects and the mentors of that. >> >> We have created a webpage (Thanks Janko!!) where we will put all the >> information. We will make this page public soon (we still need to review a >> couple of things). >> But for the moment we would REALLY appreciate if tell us your ideas. To do >> this, just answer to this email. Then we will collect the information and >> put in the website. For each idea you need: a short title and a paragraph >> (for the moment) explaining the idea. >> After, we need that the people that are willing to be mentors start to apply >> as mentors...please, consider yourself being mentor. Sometimes it is not >> that difficult. I mean, don't be shy as sometimes being helpful, being aware >> of the dates, answering emails, etc is more important than the Smalltalk >> knoweldege. We can have a lot of ideas, but we need also mentors for that. >> We even would need a "substitute" for each mentor... >> >> Just as an example you can see the ideas of the previous years: >> 2007: http://wiki.squeak.org/squeak/5936 >> 2008: http://wiki.squeak.org/squeak/6031 >> 2009: http://wiki.squeak.org/squeak/6120 >> >> That's all for the moment. >> >> Cheers >> >> Mariano >> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |