Hi all,

we just finished our weekly Etoys developer meeting. If you want to join next time: Mondays 12 pm (noon) L.A. time in IRC #etoys on freenode.net.

Present: Bert (bertf), Tim (teefal), Yoshiki (ohshima), Jecel (jecel), Andreas (bander), Hilaire (hilaire)

* Andreas presented an interesting idea on migrating projects to new Squeak versions. Loading an instance of a class that changed semantically in the mean time (that is, not necessarily changed shape) would actually create a complete new instance with the new semantics.

* Bert talked briefly about a trunk-like update model for Etoys based on Monticello

* Jecel noted that recent versions of DrGeo depend on the "Polymorph" UI enhancements. Luckily Hilaire joined and explained there were goiing to be two different DrGeo versions. He also wants to get in a few fixes so he asked about our release schedule ...

*  ... which we discussed briefly. We tentatively settled on feature freeze in May and release some time before Squeakfest (so July latest, preferably June).

* As for actual release features, I wrote my top-priorities in the last mail (translatability, enable contributors). Tim would like a "facelift".

* The meeting was over by then, but a discussion ensued on the organization of Squeakland itself. This is going to be discussed in the next Squeakland Board meeting.

Detailed meeting log below.

- Bert -


<bertf> bander: nice to see you here :)
<bertf> ohshima: hi again
<bertf> anybody else here for the meeting?
<teefal> @HELP Etoys-Dev Meeting starting now
<teefal> ---
<ohshima> Hi.  I may not be "here" in person during the meeting however.
<teefal> --- SOFTWARE TEAM MEET START ---
<bertf> ohshima: "in person"?
<teefal> hi bander, hi ohshima
<teefal> hi bertf
<teefal> jecel?
<bertf> hi teefal. you want to run the meeting?
<teefal> dak_?
<teefal> sure
<teefal> dangjavageek?
<teefal> donghee_?
<teefal> kencausey?
<teefal> rgs_?
<jecel> teefal: I'm here
<teefal> saijanai_?
<teefal> walterbender?
<bertf> hi jecel
<teefal> hi jecel!
<bertf> well okay, I outlined my points in the invitation. what's on your list?
<bander> hi guys
<teefal> well, i'm just back from Haiti, where we trained 20 Haitians to use Etoys, who will then teach 160 kids
<rgs_> teefal: yes
<teefal> "The most important topic for today is how to restart actual development work. Either use the new update stream I made or switch to Monticello as soon as possible."
<teefal> "As for actual work to be done I think this summer's release should integrate bug fixes and focus on translation issues. We should add the translated quickguides, and break up the one huge po file into smaller pieces (the #1 request of translators)."
<teefal> "Feature-wise we will add Dr Geo as previously agreed. I'm not aware of other features that are ready-to-go yet, but we'll be wiser when the release is more in reach."
<bertf> those are from my invitation, yes
<bertf> guess that's why bander is here :)
<bander> I'm interested in discussing Etoys project conversion
<bander> I have a cunning plan :-)
<teefal> .pr conversion?
<bertf> oh. cool. let's hear it :)
<bander> yup
<teefal> translation?
<bander> It's gonna take a while - you got time?
<teefal> sure
<bertf> teefal:  update to newer Squeak I'd guess
<bander> bertf: correct
<jecel> with the closure VM, right?
<bertf> eventually, yes
<bander> the problem with project conversion is that we need a more "semantic" conversion than we have today
<bertf> and Cog :) :)
<bertf> ah, luckily ohshima is here 
<bander> so what I'm intending to do is to change project loading that all classes that are loaded are mapped to proxy classes first
<bander> I.e., SystemWindow -> ProxySystemWindowEtoys4
<bander> These would match the layout of the 'old classes'
<bander> Then, these dudes can perform semantic conversion
<bander> For example: ProxySystemWindowEtoys4 would delete all but the panel widgets
<bander> It would merely create a new SystemWindow, add those panels, return that
<bander> For unchanged classes, you'd keep the originals with the option to proxy them if there have been semantic changes
<bander> The proxy classes can be bundled up in some MC package i.e., "Etoys4-Import"
<bertf> How would you make the proxies?
<bander> You write 'em - perhaps with some help from the importer in creating proper class stubs
<bander> It's not fully automatic - it can't be
<bertf> right
<bander> So that's roughly it - it's a process rather than a finished solution but I think it could work
<bertf> well, not too different from teh class-reshape methods we have already
<bertf> or am I missing something?
<bander> VERY different :-)
<bander> Have you tried loading a SystemWindow exported in 3.10 into 4.1?
<bertf> becasue it's higher-level
<bertf> not yet
<bander> I used this example for a reason - there are no class shapes; there are semantic differences
<bander> Things like event handlers
<bertf> right
<bander> And it gives us a specific way to handle imports from various Etoys versions if we can identify the version beforehand
<bander> I.e., there might be ProxySystemWindow38 and ProxySystemWindowEtoys4 that do different things
<jecel> Yes, it would be great to unbreak some older projects that don't current load
<bander> When I was looking at Edgar's issues it dawned to me that we need more semantic conversion here.
<bander> Preserve the user content, throw away the old stuff that is no longer in use
<bertf> sounds like it could work
<teefal> what's your guess as to:
<teefal> 1. delay of development (brokenness period)
<teefal> 2. degree of risk (code stability)
<teefal> my concern is that we don't really have a robust testing team/process
<bander> 1) No clue. Depends on how much time people have, and how many projects we can test against.
<bander> 2) Very low, because these changes are 'side-ways' they are independent of other changes
<teefal> okay, glad to hear #2
<teefal> once you start the changes, will it impact other development?
<bander> Probably not, though it's hard to say for suer.
<bertf> it's largely orthogonal
<bertf> this would happen in trunk
<teefal> well, i'm for more flexibility, certainly
<bertf> we need to move closer to trunk to get developer brainshare
<teefal> when you say trunk, you mean squeak trunk, yes?
<bertf> yes
<bander> With regards to testing, one good thing is that Edgar has been asking for better project support, so this will be an excellent test case. When the fundamentals are in place, the Etoys import should "just" be an application of the mechanism
<bertf> oh man, that's exciting :)
<bertf> I really need to sit down and port the etoys stuff to trunk
<bander> I've always considered projects the 'deal-breaker' when it comes to move to a different basis...
<teefal> so changes will all be on the squeak side, with etoys eventually getting connected/merged with squeak trunk?
<teefal> ah, port to trunk ... how much work is that?
<jecel> Which is why the Scratch people originally planned to never change their base (didn't quite work out)
<bander> Yes, that would be the idea. Migrate Etoys to Squeak 4.1 / 4.2.
<bertf> teefal: that's one thing we're talking about today
<bertf> jecel: well Scratch has it a lot simpler since they have a separate model for projects
<jecel> bertf: Ah, I thought they used the same. But given that they have a Java player I should have guessed it wasn't so simple
<bertf> bander: you've done this already - how much effort do you think would it be to switch the Etoys image from an update stream to a trunk-like update model?
<bertf> Karl started on packetizing the image
<bertf> I tried on the weekend
<teefal> trunk-like update model = monticello?
<bertf> but ran into a few troubles ... still think it shouldn't be that much effort
<bertf> teefal: yes
<bander> bertf: Can't say for sure; too many variables
<bander> The only real way to find out is to give it a shot then discuss how it fails and how to get out of it
<bertf> that's my approach exactly ;)
<bertf> ok, you know where to find me the next weekends ;)
<jecel> Wasn't the main issue moving classes/method between packages so Trunk and Etoys match?
<bander> It's definitely one of them
<bertf> jecel: yes
<bertf> but also even loading a moder Monticello version is not trivial
<bertf> modern
<bander> It may be worthwhile to approach it differently
<bander> You might try to identify the packages in Etoys and load those directly into a trunk image
<bertf> jecel: the moving is what I meant with "packetizing"
<bander> Then find out what's missing and decide how to fix that
<jecel> That was supposed to be the advantage of LevelPlayingField, but it didn't work for me in Etoys
<bertf> bander: I wouldn't bet the farm yet on etoys-on-trunk. not for this summer's release
<bertf> jecel: neither for me
<bander> Hell, no!
<bander> bertf: This is for next year's release not this years
<bander> Sorry if I gave the wrong impression!
<bertf> but I'd still want to switch development to monticello
<bertf> now
<bander> Ah, got it - I thought you were still at Etoys conversion
<bertf> bander: that's more for teefal's benefit
<bertf> it's a prerequisite step anyway
<teefal> well, it certainly sounds like the right move long term
<jecel> bertf: I think Matthew had Monticello working in Etoys at one point. Or perhaps he was using a regular Squeak omage on his XO?
<teefal> we need more etoys developers, and being on trunk w/monticello, from what i hear, will really help
<bertf> jecel: don't know. in the etoys-dev image there still is an old MC version
<bertf> we could start from that
<bertf> that's what Karl did anyway
<bander> It really shouldn't be so hard to get the latest MC from trunk into Etoys - there are plenty of tests.
<bertf> bander: saw my mail on squeak-dev?
<bander> the one about ifNotNil: etc?
<bertf> eys
<bertf> and the later oneabout pragmas
<bertf> but at least that's solved already :)
<bander> how does that affect MC?
<bertf> MC in trunk uses pragmas and ifNotNil: with an argument
<bertf> that's a syntax error on a 3.8 compiler
<teefal> okay, i need to go ... trying to keep meets to half an hour, but feel free to keep talking
<teefal> as always
<bertf> thannks teefal
<teefal> we have a laundry list of things from our pilots that i'll post as issues, hopefully many will be easy fixes for new people to try
<teefal> bye
<bertf> bander: guess forst thing I'll push into the update stream is Eliot's pragma stuff
<bertf> first
<bander> Weird - didn't think MC used pragmas; we should be able to remove those uses.
<bertf> bander: there is one preference
<bander> Remote it for the Etoys image!
<bander> s/remote/remove
<bertf> yes, might do that too
<bertf> didn't get a response on squeak-dev really about this
<bander> I would fork MC, fix the issues you have in Etoys and use that version.
<bander> That way you can also update any improvements you need from the trunk
<bertf> yes. guess that's easier than fighting it
<bander> KISS :-)
<bertf> :)
<bertf> okay, thanks for that project idea
<bertf> I'll send meeting notes
<bertf> anything else we might talk about today?
<jecel> Dr. Geo
<bertf> jecel: ah, you caught that ;)
<bertf> what about it?
<jecel> I am 100% in favor of including it, but noticed that the latest version depnds on Polymorph
<bertf> I'd hope we simply load the ... urgh
<jecel> The previous version should work just fine, but we should talk to Hilare about his plans
<bertf> guess Hilaire got fed up with having to wait so long
<bertf> yes, I'll send him a separate mail
<bander> okay gotta run
<bander> nice seeing y'all
<bertf> thanks everyone!
<bertf> see you next week
<bertf> (and I hope I'll remember to announce it in #squeak too, then)
--> hilaire (~hilaire at bon74-1-88-184-136-97.fbx.proxad.net) has joined #etoys
<bertf> ah, hilaire, awesome!
<hilaire> getting busy lately
<bertf> good for you I hope?
<bertf> we talked about Dr. Geo, and I hoped we would simply load the package, but Jecel mentioned it mightdepend on Polymorph?
<bertf> hilaire?
<jecel> The version he is currently developing. There is a version ready to load into Etoys already, right?
<bertf> http://tracker.squeakland.org/browse/SQ-324
<hilaire> yes
<hilaire> there will be two versions with the same core but different UI
<hilaire> bertf: I am totally exhausted, some student drive me nuts
<bertf> hilaire: I can feel with you ;) 
<bertf> that's good to know
<bertf> so we'll go with the version attached to the ticket
<jecel> hilaire: that sound like a good plan. The idea is to have relatively few changes to Etoys for this summer and leave radical changes for next year
<bertf> hilaire: our meeting is over anyway. anything else you would like to speak about?
<hilaire> No, not really, I just read your email a few minutes ago
<hilaire> For the short term, I need to figureout some bugs I want to fix in the core.
<hilaire> What is the delay for next Etoys version
<bertf> you mean the target release date?
<hilaire> right
<jecel> I think it is supposed to come out before the start of the school year in the northern hemisphere
<jecel> So a month or two before September
<bertf> well we have not really settled on a schedule yet
<bertf> I'd ratehr want to have it earlier, before thevacation season
<teefal> earliest ... squeakfest ... latest ... mid aug
<teefal> or perhaps earlier
<teefal> mid june is start of vacation
<hilaire> ok, so I have plenty of time for last fixes in DrGeo
<bertf> hilaire: yes, it's not out for a month at least
<teefal> "Squeakfest 2010 will be held from July, 26 - 28 in Wilmington, NC. "
<teefal> I'd say we should really shoot for July 26th
<teefal> or earlier
--> scottwal (~scottwal at cpe-74-64-100-18.nyc.res.rr.com) has joined #etoys
<jecel> I wonder if there will be another SqueakFest in Brazil this year?
<teefal> perhaps june 21st for feature freeze?
<teefal> jecel, talk to marta ... so far, no, or at least not by that name
<bertf> I'm on vacation in July, so earlier would be better
<bertf> feature freeze can be much earlier, we do not have many features planned anyway
<teefal> we're having a big etoys workshop in st john starting May 22
<teefal> perhaps feature freeze may 22
<teefal> code freeze june 22
<teefal> or something like that
<teefal> two months for testing
<bertf> I don't think that workshop affects the development schedule in any way ;)
<hilaire> bed time for me
<hilaire> bye.
<bertf> thanks hilaire
<-- hilaire (~hilaire at bon74-1-88-184-136-97.fbx.proxad.net) has left #etoys
<jecel> teefal: last year it was able to take advantage of that large educational conference the following week. This year it would have to be stand-alone, and now Marta knows how much work one of these things are :-)
<bertf> but feature freeze in May sounds good
<teefal> st john pilot ... big opportunity to test new etoys release
<teefal> 40 new mentors
<teefal> much opportunity for feedback
<bertf> jecel: Marta said that *if* there was a Squeakfest in Brasil this year it would not be before September
<bertf> teefal: true. let's see what feedback we get from the last workshop
<jecel> bertf: thanks. That is a more reasonable time to fly south (not so cold)
<jecel> Are major changes to the looks still planned for this release? And if not, will it still be called Etoys 5.0?
<teefal> it's doubtful though we will be changing the easy stuff
<teefal> gallery layout, etc
<teefal> perhaps the load/save boxes
<teefal> don't know about etoys 5
<teefal> depends on how different it is
<teefal> probably won't be
<bertf> jecel: any opinion on the version number?
<jecel> It should reflect the level of changes (specially visual changes given our audience)
<teefal> let's write this up as an email to etoys-dev and discuss at the next software meet
<teefal> i'd love to do as much visual improvements as we can ... paint box, etc
<teefal> just to bring etoys into this decade :)
<teefal> perhaps that's what the next release is ... a facelift
<bertf> jecel: it will definitely be much less visually different than the 3 to 4 change
<bertf> teefal: facelift isn't exactly on the top priority list

[further discussion was not directly related to the software meeting, snipped]