Hello all,

Craig suggests that we do not post an article that has candidates answer my questions because my questions are loaded. I did ask people to submit their own questions, but if this is what the community wants the please say so now. I would still be interested in hearing other questions, including having questions submitted by candidates!

Also Craig suggests that we do not post emails supporting candidates but let candidates speak for themselves. My goal in asking the community to do this is to get a conversation started, which as you know, is actually pretty difficult to do in this community. There is not much time left before we vote.

So it is very important that the community say if you want an article and if you would like to have community members support their candidates with some thoughts posted here.

Please respond and let us know what you would like me to do, if anything, to help inform you the community and keep you informed as this election proceeds.

Thanks,

Ron Teitelbaum

p.s. I ordered the candidates in the order that they declared but I can change that to alphabetical.

From: Craig Latta Sent: Monday, February 19, 2007 12:51 PM

Hi Ron--

...

We have a short time to find out more about these candidates before the election. I will be sending the same questions to each candidate and will publish a final article...

 You posed a set of candidate questions earlier which were quite

loaded; in particular, they conveyed a certain point of view of yours, and effectively asked whether or not the candidate agrees with you. :) This didn't seem so good. Much better (but potentially a lot of work), would be to compile a set of top-asked questions from the community, a la Slashdot. I don't think it's right for one person to claim authority for deciding what questions to ask. Certainly the questions could be better.

...

In the mean time I encourage people to support your favorite candidate! Please post a recommendation for your favorite candidate, include details about that candidate that people may not know.

 Hm, I'm not sure this is such a great idea either. :)  As a voter,

I'm most interested in what each candidate is motivated to say on their own behalf. And the candidates should probably decide what new facts about themselves to present. It seems most fair to let the candidates speak for themselves.

...

It is sometimes difficult for people to talk about themselves so I encourage you to help.

 I think that's a good point; I think a better way to go about it

would be for interested voters to contact their favorite candidates directly and suggest strengths for them to emphasize when addressing all of us.

 Another thought about the "None of the Above" candidate. If NA

doesn't displace anyone from winning (i.e., for this election, seven people beat "NA"), then there doesn't seem to be any reason to reveal NA's ranking; all it may do is hurt the feelings of anyone ranked lower.

 Finally, it seems most fair to list candidates in alphabetical order.


 thanks again!

-C

-- Craig Latta http://netjam.org/resume

All,

As a reminder these were the questions that I originally suggested. I did receive other questions that I was planning on incorporating today.

1) Do you support stepping up fundraising? If so what do you propose to do with the money collected?

2) Do you support bounty projects? If so can you lay out how you would like to see a bounty program administered?

3) Do you support incorporation and not for profit tax status for Squeak Foundation?

4) What do you believe is the future of Smalltalk?

5) What do you think the community is doing right, what should be improved?

6) Should the Squeak be represented at more conferences?

7) Should Tim be given a gazillon dollars for his excellent work on Squeak?

They are not arbitrary questions or one sided Ron's agenda questions. I thought they were pretty well sanitized and general. Some of them are downright softballs!

Ron

-----Original Message----- From: tim Rowledge [mailto:tim@rowledge.org] Sent: Monday, February 19, 2007 1:58 PM To: Ron@USMedRec.com; The general-purpose Squeak developers list Subject: Re: election details *PLEASE READ*

On 19-Feb-07, at 10:32 AM, Ron Teitelbaum wrote:

...

Craig suggests that we do not post an article that has candidates answer my questions because my questions are loaded.

I pretty much agree with Craig here; no bad intent is needed by anyone in the process and yet it can very easily become a nasty argument. It seems to be the nature of email/group communications. Survey questions (and what Ron was suggesting is essentially a survey) are very difficult to write in such a way as to *elicit opinions* rather than *agreement with implied opinion in the question*.

1. Have you stopped beating your spouse yet?
2. Do you agree that we must always fight against stopping <foo>

being prevented, if indeed it not happening caused nothing to not be undoably redone? 3) Why? Explain in 750 words, double spaced on unlined paper. In green crayon.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 7) "You question the worthiness of my Code?! I should kill you where you stand!"

On 19-Feb-07, at 12:42 PM, Edgar J. De Cleene wrote:

El 2/19/07 4:08 PM, "Ron Teitelbaum" Ron@USMedRec.com escribió:

...

7. Should Tim be given a gazillon dollars for his excellent work

on Squeak?

And be nominated officially Imperator and all swore loyalty to he :=)

Hmm, I could handle the gazillion dollars and I think I'd probably do stuff most people would approve of. On the other hand, I've had executive power etc and it isn't as much fun as you'd think.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Couldn't pour water out of a boot with instructions on the heel.

Well, it is a tough thing. I would personally like to know about where the candidates stand on things I want to see happen and things I don't want to see happen. But I don't know how to word my questions in an unloaded way. :)

I would just want to know things like, how much change does the candidate want or would support? Something drastic changes (and imo awful) like moving to a more file based, less image architecture, or a more conservative (but forward moving!) approach.

From: "Ron Teitelbaum" Ron@USMedRec.com Reply-To: Ron@USMedRec.com, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'tim Rowledge'" tim@rowledge.org,"'The general-purpose Squeak developers list'"squeak-dev@lists.squeakfoundation.org Subject: RE: election details *PLEASE READ* Date: Mon, 19 Feb 2007 14:08:01 -0500

All,

As a reminder these were the questions that I originally suggested. I did receive other questions that I was planning on incorporating today.

1. Do you support stepping up fundraising? If so what do you propose to do

with the money collected?

2. Do you support bounty projects? If so can you lay out how you would

like to see a bounty program administered?

3. Do you support incorporation and not for profit tax status for Squeak

Foundation?

4. What do you believe is the future of Smalltalk?

5. What do you think the community is doing right, what should be improved?

6. Should the Squeak be represented at more conferences?

7. Should Tim be given a gazillon dollars for his excellent work on Squeak?

They are not arbitrary questions or one sided Ron's agenda questions. I thought they were pretty well sanitized and general. Some of them are downright softballs!

Ron

...

-----Original Message----- From: tim Rowledge [mailto:tim@rowledge.org] Sent: Monday, February 19, 2007 1:58 PM To: Ron@USMedRec.com; The general-purpose Squeak developers list Subject: Re: election details *PLEASE READ*

On 19-Feb-07, at 10:32 AM, Ron Teitelbaum wrote:

...

Craig suggests that we do not post an article that has candidates answer my questions because my questions are loaded.

I pretty much agree with Craig here; no bad intent is needed by anyone in the process and yet it can very easily become a nasty argument. It seems to be the nature of email/group communications. Survey questions (and what Ron was suggesting is essentially a survey) are very difficult to write in such a way as to *elicit opinions* rather than *agreement with implied opinion in the question*.

1. Have you stopped beating your spouse yet?
2. Do you agree that we must always fight against stopping <foo>

being prevented, if indeed it not happening caused nothing to not be undoably redone? 3) Why? Explain in 750 words, double spaced on unlined paper. In green crayon.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 7) "You question the worthiness of my Code?! I should kill you where you stand!"

_________________________________________________________________ Find what you need at prices you’ll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001...

A significant number of questions seem to be on the *technical* aspects of Squeak. As I have tried to explain (http://wiki.squeak.org/ squeak/5932) I do not see the *foundation board* as a technical forum but rather one dedicated to the running of the foundation. Technical matters more properly belong with a technical forum, something I think we will want to establish.

As such, I have no intention of answering technical questions in the context of the board elections.

In re. the matters I see as relevant to a board election:- - I would love to increase fund-raising and we have in fact made a small but hopefully profitable start by ordering in stock of more of the well received enamel badges - I like the general principle of bounties and sponsorships etc but I have some problems with how they can be organised so that they are seen as fair, equitable, transparent and worthwhile. And you can't go offering bounties without having funds to pay them! - I (indeed all the current board) support finding a sensible legal basis of establishment for the foundation. It may be independent incorporation, it might be association with another body, it might be taking over a small nation and claiming sovereignty. - I suggest establishing a technical forum to co-ordinate and push the technical areas of Squeak

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One chip short of a cookie.

"Ron Teitelbaum" Ron@USMedRec.com writes:

As a voter I would like people to answer my questions, but I'm abstaining from asking again. I will most likely vote for candidates that spend some time actually participating in a conversation, answering questions, filling in the wiki page and addressing issues about building, managing, and supporting our community.

That is how I would like it to be looked at, too. Deciding what questions should be answered is, itself, a democratic issue. :)

That said, it does not take any official action to get these discussions going. All it takes is a motivated community member to ask all the candidates a question and then post their responses. Feel free to write a giant flashing red "DID NOT RESPOND" for any candidate that did not even write you back.

-Lex

Thanks for your answers Craig.

I think you may have read my intentions wrong concerning the incorporation. While compiling this list I went over the issues that were asked by the community. Most of the issues that seemed to be very important were licensing, funding (and corporate sponsorship, or engaging more businesses), incorporation, and most of all bounty projects. The rest are things that I'm interested in: the future of Smalltalk and how we can improve the community. The conference question has been coming up recently in different lists and I think the community agrees that we should be raising money and one of the major things we could be doing is sponsoring people to attend conference and represent Squeak. I'd be interested if the board agrees with that. I didn't think it would be appropriate to ask questions about current development and things that are still being debated so I left those questions out.

During the last election the major issue was, if we are going to incorporate why haven't we? I put that question in there as a softball to give you and others a chance to say what is going on or voice their support for this important issue. I am not against incorporation.

The email you are talking about was some current advice and some ancient history that I gave to Bert. He asked me if he could forward my advice to you. I thought I was pretty clear what my issues are and if the board would like to continue with the conversations and advice I was giving it before the current board was elected and eliminated my participation I will be happy to help where I can. I suppose you did me a favor since I was spending too much time on it anyway. My goals are pretty simple; I'm trying to help the community where I can. I believe it would be good for the community for the next board to be more open, ask for and accept more help.

I appreciate your talent and contributions to the community. You did a very nice job organizing board and finally getting things moving.

Thanks again for answering the questions,

Ron Teitelbaum

From: Craig Latta Sent: Tuesday, February 20, 2007 8:15 PM

Hi Ron--

...

Do you support stepping up fundraising? If so, what do you propose to do with the money collected?

 It seems to me that there is a very strong consensus in the

community in support of increased fundraising; I support it as well. In fact, this consensus is so strong that the first part of the question strikes me as very odd. Clearly (to me), the tricky part, and where there *is* disagreement, is about creating an appropriate legal entity to receive and disburse the funds.

 If we had funding, I would suggest we spend it on keeping the

community's online facilities running (hosting bills, etc.). If we can devise a fair and productive way to fund development, I would support that as well.

...

Do you support bounty projects? If so, can you lay out how you would like to see a bounty program administered?

 As I said above, I support funding development in a fair and

productive way. The typical "bounty" seems to consist of a vague statement of the desired result and a rather arbitrary financial reward. I think doing something like this in the Squeak community would almost certainly lead to bitterness, because it would be a race where every loser would invest far more effort than is reasonable. I think it would create unconstructive competition. It would turn developers into footrace contestants working in secret, each hoping to beat the others. There would be significant pressure to claim to be first, rather than doing the job properly; and I suspect there would be a great deal of arguing over whether the goal was actually met, and the people arguing would have a financial interest in the outcome. Not good!

 For each desired result, I would much rather see the appropriate

community team solicit and refine bids from interested developers, in public, and choose one. With a dialog between bidders and the rest of the community, I think we'd be more likely to define the goal with sufficient detail, and choose appropriate rewards. I expect that a bid could be rescinded if work went over schedule, etc.

 Of course, for any of this to be possible, we need to have a budget

which is both sufficiently large and *sustainable*.

...

Do you support incorporation and not for profit tax status for Squeak Foundation?

 This question strikes me as especially loaded. The Squeak

Foundation board of directors has already been working toward this for months, as you can read in the board meeting notes. Isn't it a bit late to be asking this question? Why didn't you take issue with our approach when we mentioned it in the meeting notes? The main signal I get from this question is that you oppose incorporation as a distinct tax-exempt organization, and that you're somehow trying to draw support for that point of view. Not long after you initially posted these questions, my suspicion was proved correct by a subsequent message you sent to the board (which I leave to you to repeat in public if you wish).

 At best, I think you have a conflict of interest on this issue

(between speaking for the community in asking campaign questions and having your own agenda on this issue).

...

What do you believe is the future of Smalltalk?

 I think the future of Smalltalk is one in which it is seen as the

easiest way to teach the expression of intent with a computer, and the most productive way to build meaningful systems. So far I think Smalltalk has done rather well on the second part, but very poorly on the first.

...

What do you think the community is doing right, what should be improved?

 The community has started to delegate tasks to the right interested

people, which is great. The way we communicate, though, isn't terribly effective. I think it'd help if we devoted more effort to real-time communication (e.g., via the Squeak IRC channel, Skype, and in-person conferences).

...

Should the Squeak be represented at more conferences?

 Of course it should. I can't imagine why anyone would answer "no"

to this question, so it seems very odd. There are, however, reasons why we might not able to accomplish it, such as a lack of funds or available time. I hope no one will confuse a lack of resources with a lack of desire.

...

Should Tim be given a gazillon dollars for his excellent work on Squeak?

 We should all have a gazillion dollars for our excellent work on

Squeak.

...

They are not arbitrary questions or one sided Ron's agenda questions.

 I hope I made myself clear about that in my answers.

...

I thought they were pretty well sanitized and general. Some of them are downright softballs!

 Whether or not they're softballs is beside the point. Some of the

questions were *leading*, not necessarily aggressive. I think tough questions are fine.

 Well, judging by the inevitable email storm around questioning, it

seems to me that to remain above reproach a candidate must answer any and all questions asked by anyone everywhere (lest a flashing red "DID NOT RESPOND" descend from the skies :). I'll certainly try to answer any question I see, as my available time allows. But you'll pardon me if I answer the questions I see between the lines as well. :)

 Finally, thanks for your work on the elections team, Ron (and

thanks to Daniel and the rest of the team). While I disagree with some of your ideas about how to conduct an election, I do appreciate your work.

 thanks again,

-C

-- Craig Latta http://netjam.org/resume

Hi Stef,

I would love you have you answer my questions, and all the questions that appear on the wiki site. The issue that Craig raised wondered if my questions had some sort of implied Ron's agenda attached to them. If you feel that my questions have some sort of agenda please feel free as Craig did to point that out in your answer.

I really think it would have been better to have created an article for weeklySqueak since we are getting 500-1000 readers a day which is larger then our community. I thought it would be good press for us so I threw what I thought were softball questions which I guess were miss-interpreted.

I certainly understand Craig's point of view considering our private disagreements about the board, but I didn't intend any agenda, nor did I have ulterior motives. I accept the responsibility for the miss-understanding and apologize if my comments and questions were taken that way.

I have pretty thick skin, and I know you do too, even if your comments don't always show that. Giving that I know you can take some criticism I would like to add an additional question for you to answer.

Your comments on the wiki site say that if things are not better based on the first meeting after the election you will resign again. My question to you is do you feel that is fair to the board to leave it with only 6 members because you do not agree with the other board members? Can you find a way to stay and work out your differences instead?

Thanks Stef!

Ron Teitelbaum Squeak Community Member

From: stephane ducasse Sent: Friday, February 23, 2007 3:51 PM

Sorry I was terribly busy with my house. Now should each candidates reply to the questions of ron following what craig just did? I'm confused I thought that we should not but Craig seems to reply to all the questions.

Stef

...

Hi Ron--

...

Do you support stepping up fundraising? If so, what do you propose to do with the money collected?

 It seems to me that there is a very strong consensus in the

community in support of increased fundraising; I support it as well. In fact, this consensus is so strong that the first part of the question strikes me as very odd. Clearly (to me), the tricky part, and where there *is* disagreement, is about creating an appropriate legal entity to receive and disburse the funds.

 If we had funding, I would suggest we spend it on keeping the

community's online facilities running (hosting bills, etc.). If we can devise a fair and productive way to fund development, I would support that as well.

...

Do you support bounty projects? If so, can you lay out how you would like to see a bounty program administered?

 As I said above, I support funding development in a fair and

productive way. The typical "bounty" seems to consist of a vague statement of the desired result and a rather arbitrary financial reward. I think doing something like this in the Squeak community would almost certainly lead to bitterness, because it would be a race where every loser would invest far more effort than is reasonable. I think it would create unconstructive competition. It would turn developers into footrace contestants working in secret, each hoping to beat the others. There would be significant pressure to claim to be first, rather than doing the job properly; and I suspect there would be a great deal of arguing over whether the goal was actually met, and the people arguing would have a financial interest in the outcome. Not good!

 For each desired result, I would much rather see the appropriate

community team solicit and refine bids from interested developers, in public, and choose one. With a dialog between bidders and the rest of the community, I think we'd be more likely to define the goal with sufficient detail, and choose appropriate rewards. I expect that a bid could be rescinded if work went over schedule, etc.

 Of course, for any of this to be possible, we need to have a

budget which is both sufficiently large and *sustainable*.

...

Do you support incorporation and not for profit tax status for Squeak Foundation?

 This question strikes me as especially loaded. The Squeak

Foundation board of directors has already been working toward this for months, as you can read in the board meeting notes. Isn't it a bit late to be asking this question? Why didn't you take issue with our approach when we mentioned it in the meeting notes? The main signal I get from this question is that you oppose incorporation as a distinct tax- exempt organization, and that you're somehow trying to draw support for that point of view. Not long after you initially posted these questions, my suspicion was proved correct by a subsequent message you sent to the board (which I leave to you to repeat in public if you wish).

 At best, I think you have a conflict of interest on this issue

(between speaking for the community in asking campaign questions and having your own agenda on this issue).

...

What do you believe is the future of Smalltalk?

 I think the future of Smalltalk is one in which it is seen as the

easiest way to teach the expression of intent with a computer, and the most productive way to build meaningful systems. So far I think Smalltalk has done rather well on the second part, but very poorly on the first.

...

What do you think the community is doing right, what should be improved?

 The community has started to delegate tasks to the right

interested people, which is great. The way we communicate, though, isn't terribly effective. I think it'd help if we devoted more effort to real-time communication (e.g., via the Squeak IRC channel, Skype, and in-person conferences).

...

Should the Squeak be represented at more conferences?

 Of course it should. I can't imagine why anyone would answer "no"

to this question, so it seems very odd. There are, however, reasons why we might not able to accomplish it, such as a lack of funds or available time. I hope no one will confuse a lack of resources with a lack of desire.

...

Should Tim be given a gazillon dollars for his excellent work on Squeak?

 We should all have a gazillion dollars for our excellent work on

Squeak.

...

They are not arbitrary questions or one sided Ron's agenda questions.

 I hope I made myself clear about that in my answers.

...

I thought they were pretty well sanitized and general. Some of them are downright softballs!

 Whether or not they're softballs is beside the point. Some of the

questions were *leading*, not necessarily aggressive. I think tough questions are fine.

 Well, judging by the inevitable email storm around

questioning, it seems to me that to remain above reproach a candidate must answer any and all questions asked by anyone everywhere (lest a flashing red "DID NOT RESPOND" descend from the skies :). I'll certainly try to answer any question I see, as my available time allows. But you'll pardon me if I answer the questions I see between the lines as well. :)

 Finally, thanks for your work on the elections team, Ron (and

thanks to Daniel and the rest of the team). While I disagree with some of your ideas about how to conduct an election, I do appreciate your work.

 thanks again,

-C

-- Craig Latta http://netjam.org/resume

...

4. What do you believe is the future of Smalltalk?

I believe every other language is asymptotically approaching Smalltalk.

Hm. Can't really let this statement stand by itself. While I think (hope) it isn't meant that way I find ignorance one of the hardest things to tolerate. Saying that "every other language is asymptotically approaching Smalltalk" sounds too much like "and therefore we can safely ignore them" to my mind. My wish for people representing Squeak (not only, but particularly those) would be to be open and engaging in discussion about the strengths and weaknesses of each system and language. This means acknowledging that other languages (including Java) have their strengths (yes, including Java) and that a discussion (regardless of its outcome) about what parts may be worthwhile to adopt in the context of Squeak is desirable and should be held with an open mind towards improving both language and system.

Personally, I think Python is a good example in this regard. There are a lot of new features proposed every time and they are often weighed based on how "Pythonic" they feel (which is a beautifully underspecified term to keep the discussion open and discuss how a feature relates in the context of other language features). And while I will admit that language changes can go overboard (recently I discovered "whitespaceless" Python which is about as *disgusting* a language abuse as they get) a lot of good features get integrated in Python by looking at and learning from other languages and systems.

In any case, I think it is important for people representing Squeak to stay open to improvements *to the language* and not just to claim that "eventually, every other language will get there so really there will never, ever be anything to learn here".

Cheers, - Andreas

<Andreas>...I think it is important for people representing Squeak to stay open to improvements *to the language* and not just to claim that "eventually, every other language will get there so really there will never, ever be anything to learn here". </Andreas>

Your comment made me think of the difference in attitude between French speakers and English Speakers.

The French have L'Academie Francaise--and woe unto those it deems to be sullying French with foreignisms.

The English have no such thing. English has a huge vocabulary--much of it stolen shamlessly from other languages.

In my opinion, Smalltalkers act more like French speakers. And that definitely gets noticed, let me tell you.

Other programming languages have been stealing from Smalltalk for decades. It's time we returned the favor.

--Alan

On Wed, 21 Feb 2007 00:43:25 -0800, Göran Krampe goran@krampe.se wrote:

I wholeheartedly agree with Andreas. While I also think *many* languages, especially open source "scripting" (I hate the term) languages, are indeed getting closer and closer to Smalltalk in *many* aspects (Ruby being one of the prime examples of course), it is IMHO definitely not true of ALL languages or ALL aspects.

Can Ruby be considered as getting closer to Smalltalk if they started with Smalltalk and deliberately moved away? :-)

I like (and use) a lot of languages but I don't find myself missing language features when using Squeak. I do miss certain IDE elements, however. And I do miss having a minimal starting point to build from.

From: Roel Wuyts Roel.Wuyts@ulb.ac.be Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Wed, 21 Feb 2007 22:52:45 +0100

I drink do that. Cheers Andreas.

It's fun that especially a very open and reflective language like Smalltalk actually is not extended very much (or only within small research projects not taken up by the community). Where are the macro systems ? Variable length argument lists ? Nifty versioning and packaging systems ? Monads ? Usable typing systems ? etc. etc.

But before we decide a feature is missing from Squeak because someone else has it, we must first think *why* some other place has it. For an extreme example, C has pointers and Squeak doesn't. Does anyone think Squeak needs pointers?

Likewise, Haskell has Monads. But that is because there is no other language supported way to represent state change. It is a very nice language, but for Monads to work right, I think you kind of need the whole thing (i.e. partial application, type checking, the things that make Haskell Haskell).

So far, any time I would have reached for variable length argument lists in other languages, I used meta-programming in Smalltalk. And Macro systems? It can be put in easily, and I have code that generates code, but due to the nature of Smalltalk, we can add language constructs without having to resort to macros as Lisp does.

Having said all that, I think Squeak could use more formal Lazy evaluation support, and I published some classes for it. And the package system is a known open issue. I personally believe change sets could be made more advanced to help out in a lot of areas (for one, to help with documenting that elusive "why").

I think we should try to take things from other languages that make sense for smalltalk, but I don't think there will be a time when one language (even smalltalk!) will be perfect for every task. We will still need at least Haskell. :)

_________________________________________________________________ Refi Now: Rates near 39yr lows! $430,000 Mortgage for $1,399/mo - Calculate new payment http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-17727&moid=7...

karl writes:

Another issue that will come up in the near future is multi core processors. What must be done with Squeak to utilize all the processors and what are the benefits and drawback of the different approaches ? What can the board do to help in this effort ?

The only gain from a multithreaded VM is speed. It seems sensible to aim to compete with C for scalar performance before moving to parallelization.

That said, the biggest difficulty with moving the VM to multithreaded execution is the garbage collector and write barrier. Replacing the write barrier with a card marking scheme designed for fast scaler performance could easily be combined with adding a mostly parallel old space collector. A mostly parallel old space collector would remove the number of pauses over a few milliseconds which would be nice for multimedia type soft real time systems. With a mostly parallel collector then adding multiple parallel mutators (threads) should be relatively easy but will expose exciting concurrency bugs in the image.

For practical use running multiple images is probably the way to go if you want to scale up. Swarms of Spoons. SMP machines don't scale that far. Non-symmetric machines scale further. Grids scale furthest. Running a GCed system on hardware where you care about how close the memory is to the CPU you're on is going to create interesting performance characteristics.

That said, I think we should go multithreaded but there's other things we should do first. Some of those things will provide most of the plumbing needed to go multithreaded.

Bryce

From: karl karl.ramberg@comhem.se Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Thu, 22 Feb 2007 22:44:07 +0100

...

I think we should try to take things from other languages that make sense for smalltalk, but I don't think there will be a time when one language (even smalltalk!) will be perfect for every task. We will still need at least Haskell. :)

Another issue that will come up in the near future is multi core processors. What must be done with Squeak to utilize all the processors and what are the benefits and drawback of the different approaches ? What can the board do to help in this effort ?

Afaik there are 3 ways of handling true concurrent execution (i.e. not green threads):

1) Fine-grained locking/shared thread state:

The old way of running heavy weight threads, sharing memory across threads and using some kind of locking to protect against race conditions.

Positive: Hrm, well I guess there is the most support for this, since it is probably the most common. If you don't use any locking but only read the data shared this is very fast approach.

Negative: It simply doesn't scale well. It also doesn't compose well. You can't simply put two independently created pieces of code together that use locking and expect it to work. Stated another way, fine-grained locking is the manual memory management of concurrency methodologies [1]. If any part of your code is doing fine-grain locking, you can never "just use it" somewhere else. You have to dig deep down in every method to make sure you aren't going to cause a deadlock.

This one would probably be very hard to add to Squeak based on what John said.

2) Shared state, transactional memory:

Think relational database. You stick a series of code in an "atomic" block and the system does what it has to to make it appear as the memory changes occurred atomically.

Positive: This approach affords some composability. You still should know if the methods your calling are going to operate on memory, but in the case that you put two pieces of code together that you know will, you can just slap an atomic block around them and it works. The system can also ensure that nested atomic blocks work as expected to further aid composability. This approach can often require very few changes to existing code to make it thread safe. And finally, you can still have all (most?) of the benefits of thread-shared memory without having to give up so much abstraction (i.e. work at such a low level).

Negative: To continue the above analogy, I consider this one the "reference counted memory management" of options. That is, it works as expected, but can end up taking more resources and time in the end. My concern with this approach is that it still does need some knowledge of what the code you are calling does at a lower level. And most people aren't going to want to worry about it so they will just stick "atomic" everywhere. That probably wont hurt anything, but it forces the system to keep track of a lot more things then it should, and this bookkeeping is not free.

This one would also require some VM (probably very big) changes to support and could be tough to get right.

3) Share nothing message passing:

Basically, no threads, only independent processes that send messages between each other to get work done.

Positive: This approach also allows a high level of composability. If you get new requirements, you typically add new processes to deal with them. And at last, you don't have to think about what the other "guy" is going to do. A system designed in this manner is very scalable; in Erlang for example, a message send doesn't have to worry if it is sending to a local process or a totally different computer. A message send is a message send. There is no locking at all in this system, so no process is sleeping waiting for some other process to get finished with a resource it wants (low level concerns). Instead a process will block waiting for another process to give him work (high level concerns).

Negative: This requires a new way of architecting in the places that use it. What we are used to is; call a function and wait for an answer. An approach like this works best if your message senders never care about answers. The "main loop" sends out work, the consumers consume it and generate output that they send to other consumers (i.e. not the main loop). In some cases, what we would normally do in a method is done in a whole other process. Code that uses this in smalltalk will also have to take care, as we *do* have state that could leak to local processes. We would either have to make a big change how #fork and co. work today to ensure no information can be shared, or we would have to take care in our coding that we don't make changes to data that might be shared.

I think this one would be, by far, the easiest to add to Squeak (unless we have to change #fork and co, of course). I think the same code that writes out objects to a file could be used to serialize them over the network. The system/package/whatever can check the recipient of a message send to decide if it is a local call that doesn't need to be serialized or not.

[1] The big win usually cited for GC's is something to the effect of "well, people forget to clean up after themselves and this frees up their time by not making them". But really, the big win was composability. In any GC-less system, it is always a nightmare of who has responsibility for deleting what, when. You can't just use a new vendor API, you have to know if it cleans up after itself, do I have to do it, is there some API I call? With a GC you just forget about it, use the API and everything works.

_________________________________________________________________ Win a Zune™—make MSN® your homepage for your chance to win! http://homepage.msn.com/zune?icid=hmetagline

Nice summary. The only thing I have to add is that your approach (3) is how Croquet works. We currently don't do it inside a single image but we have been talking about it and at some point we will get around to it.

Cheers, - Andreas

J J wrote:

...

From: karl karl.ramberg@comhem.se Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Thu, 22 Feb 2007 22:44:07 +0100

...

I think we should try to take things from other languages that make sense for smalltalk, but I don't think there will be a time when one language (even smalltalk!) will be perfect for every task. We will still need at least Haskell. :)

Another issue that will come up in the near future is multi core processors. What must be done with Squeak to utilize all the processors and what are the benefits and drawback of the different approaches ? What can the board do to help in this effort ?

Afaik there are 3 ways of handling true concurrent execution (i.e. not green threads):

1. Fine-grained locking/shared thread state:

The old way of running heavy weight threads, sharing memory across threads and using some kind of locking to protect against race conditions.

Positive: Hrm, well I guess there is the most support for this, since it is probably the most common. If you don't use any locking but only read the data shared this is very fast approach.

Negative: It simply doesn't scale well. It also doesn't compose well. You can't simply put two independently created pieces of code together that use locking and expect it to work. Stated another way, fine-grained locking is the manual memory management of concurrency methodologies [1]. If any part of your code is doing fine-grain locking, you can never "just use it" somewhere else. You have to dig deep down in every method to make sure you aren't going to cause a deadlock.

This one would probably be very hard to add to Squeak based on what John said.

2. Shared state, transactional memory:

Think relational database. You stick a series of code in an "atomic" block and the system does what it has to to make it appear as the memory changes occurred atomically.

Positive: This approach affords some composability. You still should know if the methods your calling are going to operate on memory, but in the case that you put two pieces of code together that you know will, you can just slap an atomic block around them and it works. The system can also ensure that nested atomic blocks work as expected to further aid composability. This approach can often require very few changes to existing code to make it thread safe. And finally, you can still have all (most?) of the benefits of thread-shared memory without having to give up so much abstraction (i.e. work at such a low level).

Negative: To continue the above analogy, I consider this one the "reference counted memory management" of options. That is, it works as expected, but can end up taking more resources and time in the end. My concern with this approach is that it still does need some knowledge of what the code you are calling does at a lower level. And most people aren't going to want to worry about it so they will just stick "atomic" everywhere. That probably wont hurt anything, but it forces the system to keep track of a lot more things then it should, and this bookkeeping is not free.

This one would also require some VM (probably very big) changes to support and could be tough to get right.

3. Share nothing message passing:

Basically, no threads, only independent processes that send messages between each other to get work done.

Positive: This approach also allows a high level of composability. If you get new requirements, you typically add new processes to deal with them. And at last, you don't have to think about what the other "guy" is going to do. A system designed in this manner is very scalable; in Erlang for example, a message send doesn't have to worry if it is sending to a local process or a totally different computer. A message send is a message send. There is no locking at all in this system, so no process is sleeping waiting for some other process to get finished with a resource it wants (low level concerns). Instead a process will block waiting for another process to give him work (high level concerns).

Negative: This requires a new way of architecting in the places that use it. What we are used to is; call a function and wait for an answer. An approach like this works best if your message senders never care about answers. The "main loop" sends out work, the consumers consume it and generate output that they send to other consumers (i.e. not the main loop). In some cases, what we would normally do in a method is done in a whole other process. Code that uses this in smalltalk will also have to take care, as we *do* have state that could leak to local processes. We would either have to make a big change how #fork and co. work today to ensure no information can be shared, or we would have to take care in our coding that we don't make changes to data that might be shared.

I think this one would be, by far, the easiest to add to Squeak (unless we have to change #fork and co, of course). I think the same code that writes out objects to a file could be used to serialize them over the network. The system/package/whatever can check the recipient of a message send to decide if it is a local call that doesn't need to be serialized or not.

[1] The big win usually cited for GC's is something to the effect of "well, people forget to clean up after themselves and this frees up their time by not making them". But really, the big win was composability. In any GC-less system, it is always a nightmare of who has responsibility for deleting what, when. You can't just use a new vendor API, you have to know if it cleans up after itself, do I have to do it, is there some API I call? With a GC you just forget about it, use the API and everything works.

---

Win a Zune™—make MSN® your homepage for your chance to win! http://homepage.msn.com/zune?icid=hmetagline

Yes, I think it could be done fairly easily. To make it easier I would want some kind of "spawn" to spawn a process (calls OSPluginFork where supported), and a package that lets me do something like:

ConcurrencySystem sendMsg: message to: somePID "where somePID can be local of off box"

And the process recieves it with something like:

ConcurrencySystem recieveMsgOfType: someMessageDescriptionThing orType: someOtherOne orType: systemNetworkFailure ofType: systemProcessFailure

Something like that, the way Erlang has. :)

From: "David T. Lewis" lewis@mail.msen.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Concurrent Squeak (was Re: election details *PLEASE READ*) Date: Fri, 23 Feb 2007 07:09:45 -0500

You can do approach (3) with an ordinary Squeak image if you are using a unix platform (including OS X, I think) with OSProcess. Use #forkHeadlessSqueakAndDo: to start the "threads", and connect them with OSPipes. The endpoints of an OSPipe are FileStreams, so you can read and write serialized objects between the images. The #forkSqueak turns out to be surprisingly fast and memory efficient.

I'm not up to speed on Croquet, but some variant of this technique might be a convenient way to start up a large number of cooperating Croquet images, presumably using sockets instead of OSPipe.

Dave

On Thu, Feb 22, 2007 at 10:21:42PM -0800, Andreas Raab wrote:

...

Nice summary. The only thing I have to add is that your approach (3) is how Croquet works. We currently don't do it inside a single image but we have been talking about it and at some point we will get around to it.

Cheers,

• Andreas

J J wrote:

...

Afaik there are 3 ways of handling true concurrent execution (i.e. not green threads):

1. Fine-grained locking/shared thread state:

The old way of running heavy weight threads, sharing memory across threads and using some kind of locking to protect against race

conditions.

...

...

Positive: Hrm, well I guess there is the most support for this, since it is probably the most common. If you don't use any locking but only read the data shared this is very fast approach.

Negative: It simply doesn't scale well. It also doesn't compose well. You can't simply put two independently created pieces of code together that use locking and expect it to work. Stated another way, fine-grained locking is the manual memory management of concurrency methodologies [1]. If any part of your code is doing fine-grain locking, you can never "just use it" somewhere else. You have to dig deep down in every method to make sure you aren't going to cause a deadlock.

This one would probably be very hard to add to Squeak based on what

John

...

...

said.

2. Shared state, transactional memory:

Think relational database. You stick a series of code in an "atomic" block and the system does what it has to to make it appear as the

memory

...

...

changes occurred atomically.

Positive: This approach affords some composability. You still should know if the methods your calling are going to operate on memory, but in the case that you put two pieces of code together that you know will, you can just slap an atomic block around them and it works. The system can also ensure that nested atomic blocks work as expected to further aid composability. This approach can often require very few changes to existing code to make it thread safe. And finally, you can still have all (most?) of the benefits of thread-shared memory without having to give up so much abstraction (i.e. work at such a low level).

Negative: To continue the above analogy, I consider this one the "reference counted memory management" of options. That is, it works as expected, but can end up taking more resources and time in the end. My concern with this approach is that it still does need some knowledge of what the code you are calling does at a lower level. And most people aren't going to want to worry about it so they will just stick "atomic" everywhere. That probably wont hurt anything, but it forces the system to keep track of a lot more things then it should, and this bookkeeping is not free.

This one would also require some VM (probably very big) changes to support and could be tough to get right.

3. Share nothing message passing:

Basically, no threads, only independent processes that send messages between each other to get work done.

Positive: This approach also allows a high level of composability. If you get new requirements, you typically add new processes to deal with them. And at last, you don't have to think about what the other "guy" is going to do. A system designed in this manner is very scalable; in Erlang for example, a message send doesn't have to worry if it is sending to a local process or a totally different computer. A message send is a message send. There is no locking at all in this system, so no process is sleeping waiting for some other process to get finished with a resource it wants (low level concerns). Instead a process will block waiting for another process to give him work (high level

concerns).

...

...

Negative: This requires a new way of architecting in the places that use it. What we are used to is; call a function and wait for an answer. An approach like this works best if your message senders never care about answers. The "main loop" sends out work, the consumers consume it and generate output that they send to other consumers (i.e. not the main loop). In some cases, what we would normally do in a method is done in a whole other process. Code that uses this in smalltalk will also have to take care, as we *do* have state that could leak to local processes. We would either have to make a big change how #fork and co. work today to ensure no information can be shared, or we would have to take care in our coding that we don't make changes to

data

...

...

that might be shared.

I think this one would be, by far, the easiest to add to Squeak (unless we have to change #fork and co, of course). I think the same code that writes out objects to a file could be used to serialize them over the network. The system/package/whatever can check the recipient of a message send to decide if it is a local call that doesn't need to be serialized or not.

[1] The big win usually cited for GC's is something to the effect of "well, people forget to clean up after themselves and this frees up their time by not making them". But really, the big win was composability. In any GC-less system, it is always a nightmare of who has responsibility for deleting what, when. You can't just use a new vendor API, you have to know if it cleans up after itself, do I have to do it, is there some API I call? With a GC you just forget about it, use the API and everything works.

---

Win a Zune??make MSN? your homepage for your chance to win! http://homepage.msn.com/zune?icid=hmetagline

_________________________________________________________________ Find what you need at prices you’ll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001...

I agree. This is important to get exposed and I'm sure that todd was not implying much but your remark is correct.

I would like to see how we can get more process-aware/thread safe libraries

...

...

4. What do you believe is the future of Smalltalk?

I believe every other language is asymptotically approaching Smalltalk.

Hm. Can't really let this statement stand by itself. While I think (hope) it isn't meant that way I find ignorance one of the hardest things to tolerate. Saying that "every other language is asymptotically approaching Smalltalk" sounds too much like "and therefore we can safely ignore them" to my mind. My wish for people representing Squeak (not only, but particularly those) would be to be open and engaging in discussion about the strengths and weaknesses of each system and language. This means acknowledging that other languages (including Java) have their strengths (yes, including Java) and that a discussion (regardless of its outcome) about what parts may be worthwhile to adopt in the context of Squeak is desirable and should be held with an open mind towards improving both language and system.

Personally, I think Python is a good example in this regard. There are a lot of new features proposed every time and they are often weighed based on how "Pythonic" they feel (which is a beautifully underspecified term to keep the discussion open and discuss how a feature relates in the context of other language features). And while I will admit that language changes can go overboard (recently I discovered "whitespaceless" Python which is about as *disgusting* a language abuse as they get) a lot of good features get integrated in Python by looking at and learning from other languages and systems.

Do you have some pointers to the features you find interesting?

In any case, I think it is important for people representing Squeak to stay open to improvements *to the language* and not just to claim that "eventually, every other language will get there so really there will never, ever be anything to learn here".

Cheers,

• Andreas

On Mon, Feb 19, 2007 at 02:08:01PM -0500, Ron Teitelbaum wrote:

3. Do you support incorporation and not for profit tax status for Squeak

Foundation?

I have an addendum for this question for the candidates. Viewpoints Research Institute is already a non-profit entity dedicated to the development of Squeak. What do you envision is the purpose of the Squeak Foundation with respect to Viewpoints, and how to you think they should contribute to one another in terms of funds and talent pools?

Hi everyone.

I think the discussion phase between finding candidates and voting should allow both voters and candidates to form some expectations about what is going to happen in the next term. In this light, I think Ron, like me, wants only to help this process along, but a list of questions may constrict, rather than help.

And in this particular phase of the election, I think our place should only to help. So I propose that we step back and let the mailing list do its job. I will propose that the election team will create a wiki page documenting the election, including having a list of candidates. If each candidate sends us an appropriate link, voters will have some handy reference material at the time of the vote.

Sound good?

Daniel

Brad Fuller wrote:

Craig Latta wrote:

...

Hi Ron--

...

We have a short time to find out more about these candidates before the election. I will be sending the same questions to each candidate and will publish a final article...

 You posed a set of candidate questions earlier which were quite

loaded; in particular, they conveyed a certain point of view of yours, and effectively asked whether or not the candidate agrees with you. :) This didn't seem so good. Much better (but potentially a lot of work), would be to compile a set of top-asked questions from the community, a la Slashdot. I don't think it's right for one person to claim authority for deciding what questions to ask. Certainly the questions could be better.

I don't recall the questions. But your suggestions are good.

...

...

In the mean time I encourage people to support your favorite candidate! Please post a recommendation for your favorite candidate, include details about that candidate that people may not know.

 Hm, I'm not sure this is such a great idea either. :)  As a voter,

I'm most interested in what each candidate is motivated to say on their own behalf. And the candidates should probably decide what new facts about themselves to present. It seems most fair to let the candidates speak for themselves.

And, it could get ugly. There has been some finger pointing in the past. Most messages, though, show respect for others.

Better safe than sorry and maybe collect a list of questions, shuffle them in random list order, and let each candidate answer, if they so choose to.

Hi German :-)

Ron and I have no monopoly on good questions...

Here's a simple game all voters can play. Take the list of candidates, and try to sort it by your preference. You're are simply preparing now, what you'll have to do to vote anyway. In each case where you're not sure whether you prefer A or B, do as I suggested above: read up on both, and ask some questions. Your can put them on a reply to this thread.

Daniel

Germán Arduino wrote:

I wonder, if Ron not send the mail with the proposal of questions and support mail of the rest of Squeakers, what happened? May be nothing...

And we, the voters, need some way to know the plans, goals, details, etc of the candidates to vote with responsability. Myself at leas,t take the voting opportunity each year very seriously and try my best as voter. But I need information. And this is that Ron is trying to give us.

Don't know the better way, but the candidates must explain (please in a wiki or so but OUTSIDE the list) all they consider must comment.

Cheers.

2007/2/19, Daniel Vainsencher danielv@tx.technion.ac.il:

...

Hi everyone.

I think the discussion phase between finding candidates and voting should allow both voters and candidates to form some expectations about what is going to happen in the next term. In this light, I think Ron, like me, wants only to help this process along, but a list of questions may constrict, rather than help.

And in this particular phase of the election, I think our place should only to help. So I propose that we step back and let the mailing list do its job. I will propose that the election team will create a wiki page documenting the election, including having a list of candidates. If each candidate sends us an appropriate link, voters will have some handy reference material at the time of the vote.

Sound good?

Daniel

Brad Fuller wrote:

...

Craig Latta wrote:

...

Hi Ron--

...

We have a short time to find out more about these candidates before the election. I will be sending the same questions to each candidate and will publish a final article...

 You posed a set of candidate questions earlier which were quite

loaded; in particular, they conveyed a certain point of view of

yours,

...

...

and effectively asked whether or not the candidate agrees with

you. :)

...

...

This didn't seem so good. Much better (but potentially a lot of

work),

...

...

would be to compile a set of top-asked questions from the

community, a

...

...

la Slashdot. I don't think it's right for one person to claim

authority

...

...

for deciding what questions to ask. Certainly the questions could be better.

I don't recall the questions. But your suggestions are good.

...

...

In the mean time I encourage people to support your favorite candidate! Please post a recommendation for your favorite candidate, include details about that candidate that people may not know.

 Hm, I'm not sure this is such a great idea either. :)  As a 

voter,

...

...

I'm most interested in what each candidate is motivated to say on

their

...

...

own behalf. And the candidates should probably decide what new facts about themselves to present. It seems most fair to let the candidates speak for themselves.

And, it could get ugly. There has been some finger pointing in the past. Most messages, though, show respect for others.

Better safe than sorry and maybe collect a list of questions, shuffle them in random list order, and let each candidate answer, if they so choose to.

2007/2/19, Adrian Lienhard adi@netstyle.ch:

I suggest to create a wiki page with

• a section listing questions. Everybody can add questions or add his

name to an existing question to show his interest

• a section (or extra page) for each candidate in which he can

present himself and, if he likes to, answer questions

I think a central place for this information would be helpful because else its really hard to keep track of what candidates state. When we elect, nobody wants to search the mail archives to find out who a candidate is.

Adrian

FULL AGREE.

On 2/19/07, Daniel Vainsencher danielv@tx.technion.ac.il wrote:

Hi everyone.

I think the discussion phase between finding candidates and voting should allow both voters and candidates to form some expectations about what is going to happen in the next term. In this light, I think Ron, like me, wants only to help this process along, but a list of questions may constrict, rather than help.

And in this particular phase of the election, I think our place should only to help. So I propose that we step back and let the mailing list do its job. I will propose that the election team will create a wiki page documenting the election, including having a list of candidates. If each candidate sends us an appropriate link, voters will have some handy reference material at the time of the vote.

Sound good?

Yes. I would also encourage people(candidates and voters) to blog. With blogs people can feel free to express themselves and we can all choose to sample views we find valuable(whether we agree or not). Email lists are a shared space that has to be managed lest it get out of control. However, I think we need more expression not less and blogs help distribute the management overhead. Express yourselves!

Laurence

Daniel

Brad Fuller wrote:

...

Craig Latta wrote:

...

Hi Ron--

...

We have a short time to find out more about these candidates before the election. I will be sending the same questions to each candidate and will publish a final article...

 You posed a set of candidate questions earlier which were quite

loaded; in particular, they conveyed a certain point of view of yours, and effectively asked whether or not the candidate agrees with you. :) This didn't seem so good. Much better (but potentially a lot of work), would be to compile a set of top-asked questions from the community, a la Slashdot. I don't think it's right for one person to claim authority for deciding what questions to ask. Certainly the questions could be better.

I don't recall the questions. But your suggestions are good.

...

...

In the mean time I encourage people to support your favorite candidate! Please post a recommendation for your favorite candidate, include details about that candidate that people may not know.

 Hm, I'm not sure this is such a great idea either. :)  As a voter,

I'm most interested in what each candidate is motivated to say on their own behalf. And the candidates should probably decide what new facts about themselves to present. It seems most fair to let the candidates speak for themselves.

And, it could get ugly. There has been some finger pointing in the past. Most messages, though, show respect for others.

Better safe than sorry and maybe collect a list of questions, shuffle them in random list order, and let each candidate answer, if they so choose to.

Roel Wuyts Roel.Wuyts@ulb.ac.be writes:

In my opinion it is not the task of an election committee to prepare questions or start a discussion (no matter how well the intentions, as in this case). It is the task of the committee to help the process though: setting up a wiki, provide a resume with all the names of the candidates, ask all the candidates for a small abstract of their plans and a link to more detailed information, etc.

Right on. We may as well start good habits.

This said, I would love to see someone, or even better multiple people, maintaining web pages or wiki pages that collect and distill what the candidates have said.

-Lex

Il giorno mer, 21/02/2007 alle 02.06 +0200, Daniel Vainsencher ha scritto:

Note that the wiki page exists [1], it has links to election pages for each of the candidates.

Todd, Cees, Brad, Craig and Tim have used those to put up some information and links about themselves and their intentions. There are two questions there pending answers for Stef and Tansel.

[1] http://wiki.squeak.org/squeak/Squeak%20Foundation%20Board%202007%20Election

Keith and I put up some info in our pages, too. They are reachable from the url above.

Giovanni

Yes, and this don't help so much........

2007/2/22, Klaus D. Witzel klaus.witzel@cobss.com:

Thank you Giovanni,

so now we can see that some of the candidates' pages are still blank...

/Klaus

Sended by private.

2007/2/23, Tansel tansel@squeakonline.com:

Hi,

If someone kindly forward me the usercode/password to edit my page or pages in the swiki I'd gladly put some info up, answer the questions and place them on the page. I can't seem to find any emails that refer to the u/c password pair.

Thanks

Tansel

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Germán Arduino Sent: Friday, 23 February 2007 2:38 PM To: The general-purpose Squeak developers list Subject: Re: election details (was "Squeak Foundation Board 2007 Candidates")

Yes, and this don't help so much........

2007/2/22, Klaus D. Witzel klaus.witzel@cobss.com:

...

Thank you Giovanni,

so now we can see that some of the candidates' pages are still blank...

/Klaus