[squeak-dev] Summer(s) of Code 2007/2008

> On Wed, 2008-03-05 at 16:17 +0100, cdrick wrote:
>> in the same spirit, I think squeakNOS for eeepc would be excellent
>> :)... especially in a touch screen version
>> (http://www.youtube.com/watch?v=3VaerIGpO5Q&feature=related only a  
>> mod
>> for windows right now but should be in production for newer version).
>>
>> Cédrick
>>
> Ok, than the project would be to write a software layer which enables
> us to use linux device drivers. Without utilizing devices even squeak
> is not much fun :)

> On Mar 5, 2008, at 16:42 , Norbert Hartl wrote:
>
> > On Wed, 2008-03-05 at 16:17 +0100, cdrick wrote:
> >> in the same spirit, I think squeakNOS for eeepc would be excellent
> >> :)... especially in a touch screen version
> >> (http://www.youtube.com/watch?v=3VaerIGpO5Q&feature=related only a  
> >> mod
> >> for windows right now but should be in production for newer version).
> >>
> >> Cédrick
> >>
> > Ok, than the project would be to write a software layer which enables
> > us to use linux device drivers. Without utilizing devices even squeak
> > is not much fun :)
>
> Actually, writing device drivers is not that hard if you know the  
> hardware. The XO contains drivers for all its hardware in its  
> firmware (OFW, written in Forth), and rumor has it that no driver is  
> larger than 2 pages.
>

> Bert Freudenberg wrote:
>> On Mar 5, 2008, at 16:17 , cdrick wrote:
>>
>>> in the same spirit, I think squeakNOS for eeepc would be  
>>> excellent :)
>>
>> Or for the OLPC XO? :)
>
> That is on my to-do list, but it would be better if someone else  
> does it
> first. Though I am a student again I don't have time to participate in
> the SOC (specially since it will be winter here, with just a short
> vacation). Another issue is that something that works on my old  
> BTest-2
> machine would have some problems on newer models.

>
> On Mar 5, 2008, at 18:10 , Jecel Assumpcao Jr wrote:
>
>> Bert Freudenberg wrote:
>>> On Mar 5, 2008, at 16:17 , cdrick wrote:
>>>
>>>> in the same spirit, I think squeakNOS for eeepc would be excellent :)
>>>
>>> Or for the OLPC XO? :)
>>
>> That is on my to-do list, but it would be better if someone else does it
>> first. Though I am a student again I don't have time to participate in
>> the SOC (specially since it will be winter here, with just a short
>> vacation). Another issue is that something that works on my old BTest-2
>> machine would have some problems on newer models.
>
> Well, if it performs acceptable on the B2, it will fly on the
> production machines :)
>
> - Bert -
>

> Bert Freudenberg wrote:
>> Well, if it performs acceptable on the B2, it will fly on the
>> production machines :)
>
> In terms of performance, it should be very close to what the included
> eToys achieve now on the two machines, so we can even run some
> benchmarks and have an idea of what the improvement would be. Note  
> that
> the extra memory wouldn't help since even 128MB is far more RAM than
> this system would need.
>
> A B2 version of SqueakNOS might not run correctly on newer models  
> due to
> hardware differences (Geode NX vs GX, camera interface and other
> changes). But it would be easy to make any necessary changes.
>
> For the initial port, I was thinking of a "proof of concept" where the
> graphics code would be patched to work at 1200x900 instead of 1024x768
> and the rest would be unchanged. If the keyboard and mouse work (and
> they probably would) then this would already allow some interesting
> demos. None of the rest of the hardware would work.
>
> The milestone that would move SqueakNOS from a cute demo to a  
> practical
> alternative is being able to save an image. The project stalled before
> that was achieved. Everything that needs to be devoloped can be  
> done at
> the Smalltalk level - you don't need any changes to the VM after it is
> basically working. But without being able to save you are limited to a
> painful cross development cycle: see some bug or improvement, make
> change, test it, go back to the PC, type the change once again,  
> save the
> image, create a new bootable disk, boot the XO again and see if the
> change was properly incorporated. It would be much nicer (and make the
> difference between the project actually moving forward or staying  
> as it
> is now) to: see some bug or improvement, make change, test it and save
> image.
>
> The gain in productivity would be comparable to OLPC moving from the
> cross development with LinuxBIOS to native development with
> OpenFirmware. Behold, the power of the interactive prompt!
>
> The internal Flash should be off limits, for now. So saving images  
> means
> either a USB drive (very complex drivers), using the wifi network  
> (very
> complex drivers in addition to USB and a TCP/IP stack) or a SD card
> (most likely the simplest option). I would start out with multiple raw
> partitions to get as quickly as possible to the point of native
> development and then would code a FAT file system using that,  
> eventually
> moving to saving on regular files.
>
> After that things should move much faster, and it would be possible to
> add the camera, USB and the most popular types of devices, the  
> internal
> wifi and so on.

> On Sun, 02 Mar 2008 23:04:21 +0100, giovanni <[hidden email]> wrote:
>
>> Hi all,
>>
>> in no more than two weeks, the 2008 edition of the Google Summer of
>> Code will
>> start.
>> ... In
>> comparison to last year's effort, I propose two changes:
>>
> ...
>> - we choose more "down to earth" projects that have a bigger
>> possibility of being included in the software we release (the main
>> Squeak image, Seaside, Croquet etc).
>
> I doubt that can be decided in advance, i.e. before a SoC project
> delivers. Also, applicants who aim more for a package based on Squeak
> than for an integral part of a Squeak release are unfortunately shyed away.
>
> Are there really such an overwhelming number of applicants and, do most
> of them propose compilers, dev tools, SCM tools, image shrink-dryers,
> modularizators, traitisizers, bang-new-UIs and the like?
>

> Klaus D. Witzel wrote:
>> On Wed, 05 Mar 2008 00:38:37 +0100, Andreas Raab wrote:
>>
>>> Klaus D. Witzel wrote:
>>>> I bet one (1.-) CHF that GTK support will not be included in the
>>>> next Squeak release, not counting 3.10, not talking about an
>>>> optional package.
>>>
>>> Why does everyone seem so exclusively focused on doing something that
>>> ends up "in the next Squeak release"?
>>
>> Well, hum, I was the one who doubted that? ;-)
>
> Well, not only. Giovanni explicitly stated that as a "negative
> observation" and I really fail to see what is negative about it. More
> like practical reality given that we're talking about students who are
> (hopefully) doing this to learn something. If it's got a useful outcome
> that's great but the baseline assumption should be that it *won't* end
> up in a Squeak release.

> On Mar 2, 2008, at 11:04 PM, giovanni wrote:
>
>>  Damien
>> has stopped working on Monticello 2, but Colin has remused the work on
>> that,
>> even though he's not using Damien's code.
>
> On 5-Mar-08, at 1:30 AM, stephane ducasse replied:
>
>> Now for damien I mentored damien in the hope that colin would join and
>> take the lead with the goal to
>> really get an impact and improve MC2.
>
> Just to set the record straight, I am using quite a bit of Damien's
> code, just not all of it.
>
> When I resumed work on MC2, I had a new idea for how to organized the
> interface and present things to the user. Damien's work went in a
> different direction, so merged in as much of his stuff as I could, and
> set aside the parts that were incompatible with my own direction.
>
> I think Damien did a fine job, and made a significant contribution to
> the project.
>

> Andreas Raab ha scritto:
>> Klaus D. Witzel wrote:
>>> I bet one (1.-) CHF that GTK support will not be included in the next  
>>> Squeak release, not counting 3.10, not talking about an optional  
>>> package.
>>  Why does everyone seem so exclusively focused on doing something that  
>> ends up "in the next Squeak release"? Is this a requirement for GSOC? I  
>> certainly don't see the HydraTools ever getting into a Squeak release  
>> but that doesn't make them any less useful for Squeak.
>
> As I said in my reply to Klaus, there's no need for the projects to be  
> geared toward inclusion in the next Squeak release. It's just that I'd  
> like for our students to be able to deliver something at the end of the  
> Summer.