Squeak-dev November 2009

squeak-dev@lists.squeakfoundation.org

89 participants
351 discussions

Re: Squeak direction: Was: Re: [squeak-dev] Terms of Reference: discussion is open
by Miguel Enrique Cobá Martinez 06 Nov '09

06 Nov '09

El jue, 05-11-2009 a las 17:47 -0300, Jecel Assumpcao Jr escribió: > Edgar J. De Cleene wrote: > > On 11/5/09 4:27 PM, Igor Stasenko wrote: > > > As for Keith's proposals: first time i heard about them not long ago > > > in IRC chat, and i reacted. > > > > Ha ha ha. > > > > Good joke ! > > Only Board member and qualified Squeaker who don't know ? > > > > I don't agree with Keith 98% of the time, but you can't said he don't try to > > discuss about the release process and how he think Squeak should be made. > > By "Keith's proposals" Igor meant the set of rules Keith suggested for > the board and teams recently on IRC, which Igor then brought to the > board for discussion and we have brought to squeak-dev. Igor was not > aware of previous attempts to define such rules even though Miguel said > this discussion was many months old. I don't said that. That's the reason for the change in the subject. I said that againg I see a neverending discussion about things that, although can be important indeed, just delay the changes, that the users want to see. Of course I agree that the terms are important and in extreme cases will be the sword that will solve problems, but in 90% of the cases it won't be (hopefully) invoked. While that is discussed, there is no real advance on squeak any different than before, when everyone walk in its own direction, just like the trunk commits show the personal itches being scratched by each commiter. > For one attempt to start this > discussion, see my post from February - > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134 > 288.html > > -- Jecel > > Cheers -- Miguel Cobá http://miguel.leugim.com.mx

6 14

Re: [squeak-dev] Terms of Reference: discussion is open
by Phil (list) 06 Nov '09

06 Nov '09

On Nov 5, 2009, at 3:26 PM, Jecel Assumpcao Jr wrote: > I pointed out to Keith on IRC a while ago that it was simply > impossible > for the board to "break the rules" since we have never had any > rules. He > has kindly suggested a possible set of such rules and I think that > is a > good starting point for a discussion. > > In the page in the blog I have added some links to the rules or > organizations of other Free Software projects. Most other project have > no rules that I could find and even these are pretty informal. > > Given that our community is pretty small, that elections are frequent > (every 12 months) and that re-elections are very common (most of the > current board was part of the previous one), I don't think most of the > proposed rules would help very much. I'll make a brief comment on each > one: I generally agree with your interpretation/comments on items 1-8. > > 9) There should be a grievance procedure and an equal opportunities > policy including disability awareness > > I didn't attempt to paraphrase this because I didn't understand it. > This seems to be two different points (let's call them 9a and 9b though they should probably really be 9 and 10): 9a) a grievance procedure when someone feels that the preceding terms have been violated 9b) I *think* he's talking about the Board having some sort of obligation to attempt to work with limitations of individual contributors. Keith made reference several times that he was unable to take one (or more) course(s) of action being suggested (in IRC) and at least a couple of board members *seemed* to understand what he was referring to (either that or they were taking his response at face value) The intent of these appears to be to have the Board make accommodations to the needs of individual contributors and to provide some sort of recourse to contributors should they believe that things aren't being handled properly at a finer level of granularity than 'wait for the next election cycle'. > One thing that Keith mentioned, a "vote of no confidence" followed > by an > ad hoc election, didn't get included in this list. Without that I > don't > see what the answer could be to "what happens if the rules get > broken?" > I think a lot of that was/is the result of how the situation was handled. > Given that the next election is at most 12 months away and that any ad > hoc election would probably pick the exact same board that was just > kicked out, I am against such a rule. But without it, none of the > others > "have any teeth". > > I would be happy with general principals rather than rules, and the > board has previous tried to define that: > > http://squeakboard.wordpress.com/our-mission/ > > -- Jecel > > I agree that adding a lot of mandatory process and rules probably wouldn't have changed the outcome of this, or future, situations. Direction can change for any number of reasons (priorities, contributors, pressures internal/external, etc.) and when it does, just have an open and inclusive dialog about what and why things need to change. Also, communicating ahead of time with any impacted parties, publicly or privately, would be a *very* good idea. Those seemed to be the key things missing here as it appeared arbitrary, and frankly, rather cold in how it was carried out. One can get away with that approach in a business where (presumably) people are being compensated to put up with it. In a volunteer arrangement, not so much. I appreciate this open discussion taking place. If nothing else, it is a worthwhile exercise to discuss Keith's proposal and see what, if any, changes people would like to see made in light of recent events. Phil

3 2

Re: [squeak-dev] Terms of Reference: discussion is open
by Igor Stasenko 06 Nov '09

06 Nov '09

2009/11/6 Ken G. Brown <kbrown(a)mac.com>: > IMHO, such smart guys that are doing the majority of contributions to trunk could have figured out the way forward with Keith's established future methodology using Installer, Sake/Packages, Bob the Builder, MC 1.5/1.6 in about ten minutes. Some were already up to speed on the way forward. They could then have contributed fixes to the tools for that methodology where required and we would be now in the future instead of stuck in the past, forked yet again with the old trunk methodology (it's not a 'new' development model) that got us into the difficulties in the first place. > Ken, as i said before, i would be really happy to have MC 1.6 adopted by trunk and pharo. And given the feedback of other people, they want it too. I think that MC should be a standalone project, which can be loaded to virtually any squeak fork. But we need people who actively maintaining it and improving it. And definitely, MC should be not a core part of system. It should be made optional, as any other non-kernel part of system. Once this will happen, we could move forward and adopt next tools & methodology. Step by step. So, Ken, if you think you are motivated enough, step forward and make an offer to community. And we can discuss the plan & organization of MC maintenance. Because its really bad that such critical part of system, which used by multiple forks, don't have any central comitte, which watching the progress, pushing the fixes and moving it forward. > Ken G. Brown > > > At 2:23 PM -0300 11/6/09, Jecel Assumpcao Jr apparently wrote: >>Ronald Spengler wrote: >>> When the announcement that there was going to be a trunk repository >>> and a contrib repository was made, I suddenly had hope again. The fact >>> that there was a two-man release team that I didn't even know about >>> (being a noob, I guess) didn't make a whit of difference to me, >>> because they weren't shipping anything. >> >>There was actually a one man release team (Matthew for 4.0) and another >>two man release team (Keith and Matthew for 3.11), and though they both >>were very busy with other things in their lives I think the board's >>position (which I fully agreed with) that the relicensing was the >>priority and new development would complicate it was the main cause of >>the seeming lack of progress in Squeak. And I actually looked at the >>archives of the Pharo mailing list at the time and compared it with the >>number of entries on Mantis and found out that though they seemed very >>different, the level of activity in both projects was comparable. >> >>Unfortunately, appearance can matter more than reality. The *right* >>thing for the board to have done would be to talk to Matthew and Keith >>about the new direction, have a final vote in the following meeting and >>then announce it here. Letting Keith find out with everybody else was >>bad, so I see where the scheme explained by Phil would come in. But my >>impression at the time was that two weeks of silence on squeak-dev (to >>wait for the next board meeting) would cause lots of people to leave and >>they might not later hear about the new process and decide to come back. >>So I voted we do the wrong thing instead (the needs of the many outweigh >>the needs of the few and that sort of thing) and still stand by that >>decision. >> >>I can't imagine some higher authority defending a developer from the >>board even if this episode shows the need for something like that. So >>the alternative is to complain about anything you don't like here on >>squeak-dev. That has been done and even though there seemed to be no >>immediate results it might have an effect (or not) in the next election. >> >>-- Jecel > > > -- Best regards, Igor Stasenko AKA sig.

1 0

Sophie 2.0 ported to Java. Why?
by alesch 06 Nov '09

06 Nov '09

Hi List: Does anyone know why Sophie is being ported to Java? In http://sophie2.org/trac/wiki/AboutPage this page , they mention Astea Solutions and their contributed Java codebase... "Sophie is currently being significantly revised and improved, thanks to a third grant from the Mellon Foundation in October, 2008 and to a Java codebase contributed by Astea Solutions, a company formed to design and develop proprietary and open source electronic publishing products. With this funding, Sophie is not only being rewritten in Java to enhance its stability, but is being transformed from its initial iteration as a powerful multimedia authoring too into a reading and authoring environment that incorporates the recent cultural shifts instigated by social networking and software." I have not used Sophie myself, but was it unstable? Thanks! -- View this message in context: http://n4.nabble.com/Sophie-2-0-ported-to-Java-Why-tp441245p441245.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

7 7

The Trunk: Kernel-tbn.288.mcz
by commits＠source.squeak.org 06 Nov '09

06 Nov '09

Torsten Bergmann uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-tbn.288.mcz ==================== Summary ==================== Name: Kernel-tbn.288 Author: tbn Time: 6 November 2009, 11:34:20 am UUID: aad7e55c-fd95-f744-8a85-e7b176c70810 Ancestors: Kernel-ul.287 categorize and format ChronologyConstants>>initialize as a first commit test =============== Diff against Kernel-ul.287 =============== Item was changed: + ----- Method: ChronologyConstants class>>initialize (in category 'class initialization') ----- - ----- Method: ChronologyConstants class>>initialize (in category 'as yet unclassified') ----- initialize + "ChronologyConstants initialize" + + SqueakEpoch := 2415386. "Julian day number of 1 Jan 1901" - "ChronologyConstants initialize" SqueakEpoch := 2415386. "Julian day number of 1 Jan 1901" SecondsInDay := 86400. SecondsInHour := 3600. SecondsInMinute := 60. NanosInSecond := 10 raisedTo: 9. NanosInMillisecond := 10 raisedTo: 6. DayNames := #(Sunday Monday Tuesday Wednesday Thursday Friday Saturday). MonthNames := #(January February March April May June July August September October November December). DaysInMonth := #(31 28 31 30 31 30 31 31 30 31 30 31) !

1 0

Magritte Validation Question
by Udo Schneider 06 Nov '09

06 Nov '09

Hi, I have a question regarding Magritte Validation. Given the following description descriptionAcquireRetryDelay ^ MANumberDescription new selectorAccessor: #acquireRetryDelay label: 'Aquire Retry Delay'; group: 'C3P0'; priority: 100; beRequired; beInteger; bePositive; yourself I do have a problem if the user enters a non-number. This is IMHO caused by #bePositive which checks if a given number is positive by sending #positive. However if the user enters "aaa" the object being validated is the String ... which does not understand #positive. If I remove the #bePositive condition everything is find and I do get (expected) Validation Errors complaining about invalid input and non-integer. So I'm wondering if I need to somehow specify to check the #bePositive condition (or any other condition for this case) only /after/ the correct type has been validated/determined. Any pointers? CU, Udo

2 3

working RFBs
by Chris Cunnington 06 Nov '09

06 Nov '09

RFB's that work in Squeak 3.10.2: - the latest on Squeaksource written by Ian Piumarta - RFBs 7 and 9 on http://source.lukas-renggli.ch/unsorted/ RFB's that do not work: - the one on the Squeak Map Package Loader - RFB 28 on http://source.lukas-renggli.ch/unsorted/ I figure that somewhere between RFB 9 and RFB 28 on http://source.lukas-renggli.ch/unsorted/, the code becomes Pharo only. I think that the Squeak Map Package Loader has become a snare and a delusion, and so perhaps it's time we removed it from the Squeak distribution. If anybody knows of any other publicly available RFBs for Squeak, please say so. That way we can have a full tally of the possibilities. Chris

1 0

Daily Commit Log
by commits＠source.squeak.org 06 Nov '09

06 Nov '09

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2009-November/001730.h… Name: Collections-ar.183 Ancestors: Collections-ul.179, Collections-ul.180, Collections-ul.181, Collections-ul.182 Merging Collections-ul.179, Collections-ul.180, Collections-ul.181, Collections-ul.182: - added: String >> #hashWithInitialHash: which lets the string to decide which hash implementation to use, this way ByteStrings can use the primitive implementation instead of the general one - speed up mergesort for the general case (using <= for comparison), sacrificing < 1% performance for other cases - allow symbols to be evaluated as comparison blocks. For example: sorting an Array in descening order can be as simple as: array sort: #>=, it's also faster than using a block. - simplified Dictionary >> #keysSortedSafely - simplified WeakRegistry >> #keys - save a few bytecodes in #scanFor: of identity based collections when their size is between 4097 and 8191 - fix: WeakKeyDictionary >> #finalizeValues: (increment the tally, and make sure that we don't lose the key) - collect the objects which should be finalized into an IdentitySet instead of an OrderedCollection in WeakRegistry >> #finalizeValues this should give better performance in WeakKeyDictionary >> #finalizeValues: ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-November/001731.h… Name: Kernel-ul.287 Ancestors: Kernel-nice.286 - simplified ClassDescription >> #organization ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-November/001732.h… Name: Monticello-ul.331 Ancestors: Monticello-nice.330 - faster hashing with String >> #hashWithInitialHash:. Load Collections-ul.179 before this package. =============================================

1 0

Terms of Reference: discussion is open
by Igor Stasenko 05 Nov '09

05 Nov '09

The discussion about Squeak Oversight Board Terms of Reference is now open. Please review the page on board's blog (http://squeakboard.wordpress.com/discussion-terms-of-reference/) is page and do not hesitate to take a part in discussion. With your help, let us define clearly what is the range of Board’s responsibilities, what decisions Board allowed to make and what is not. Where lies the end of Board’s power and starting power of Teams and/or individuals. You can, of course, post here, or add comments on blog. -- Best regards, Igor Stasenko AKA sig.

9 14

[ANN] Squeak Squeak3.10.2-Trunk-091024 could be fun
by Edgar J. De Cleene 05 Nov '09

05 Nov '09

In the mandatory pict at http://img11.imageshack.us/i/trunkmetprocustes.jpg/ , you could see the old Rompecabezas in ProcustesEnd format loaded and running. How you could have it: In you Monticello Browser , add MCHttpRepository location: 'http://www.squeaksource.com/Ladrillos' user: '' password: '' Pick Monticello-edc.331.mcz ( load automatic PackageInfo-Base-edc.30.mcz) Then pick MorphicPuzzle-edc.1.mcz Now you have some only SqueakLightII have until now, how put any kind of things into .mcz , load, run. Need polish, I left for younger Squeakers. Special thanks to my old friend Jerome Peace, I discover some of his code is still out of 3.10.2, I put as extensions in MorphicPuzzle. Also very, very thanks to Andreas and all working in silence for trunk moves on Edgar P.S, The picture was send to me eras ago and who send said Squeak is a ³bolsa de gatos² , seems me very nice and appropriate to us

1 0

Jump to page: