March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] RE: [vwnc] GSoC idea: Brainstorming portal for better community decision process

by Janko MivÅ¡ek

Hi Paul, On 11. 03. 2010 22:51, Paul Baumann wrote: >>> What do you think? > > Big mistake to ask that... :) Not at all :) > So "report" is the end goal? Not a big fancy report for big bosses of course. But a result in some easy understand form to base further decisions on. > Consensus doesn't accomplish anything. Many truly great things are not understood by a voting majority. A mixture of pride and reward is required to get work done. Few would anonymously give away great ideas. Who is going to implement a commonly recognized "great" idea that is not their own? Usually the quality and results of work lacking incentive are mediocre at best. What about the destructive personalities that take pride in destroying good ideas? It is those types that love to participate in consensus groups because that is how they derive satisfaction. The outcome of what you are proposing would be the common (mis)understanding of problems. Consensus doesn't mean that understanding is correct. Consensus doesn't mean that what is proposed will really accomplish anything. Consensus doesn't get the goals actually achieved. Consensus work does little more than mimic what someone else already struggled to prove successful--diminishing incentive from people who deserve the credit. I've never seen anything good come from a consensus. About consensus: I don't have in mind bad compromises etc, but moving the initial majory voting result from too frequent 51/49% slowly closer to ideal 100/0%. By continuing the argumented debate, revoting etc. Remember that majory voting usualy leaves a substantial percent of voters unsatisfied, which is not good and can lead to polarization of a community. Seeking a consensus is a technique to lower this percent. But this is also a cultural thing, Japanese are for instance more inclined to consensus seeking. About destructive personalities: Anonymity is here to solve and silence such people, because everyone can say what has in his mind freely, without fear of exposure and any represalies of any form. Also, the result of such idea gathering and voting is a strong argument against such the people. We have just now an example in Squeak community and with a collection of "ideas" with such a tool I'm sure we'd measure what a community really think quite precisely and this will be an undeniable argument against the guy, who thinks that only he knows well, what the community really think. About pride and reward: Well, authors of the best ideas at the end can be announced, but on the other side author of such idea will know that he wins even if he stays anonymous. Also remember that such a tool is not good for every possible case. I think the best is for collecting initial ideas as freely as possible and measuring the opinion about them from others. This can then be a base for the real decisions. Best regards Janko > Better to act in an environment that forms a cycle of individual liberty and reward. Create a market for change where people can work for reward. Pride is the dominant incentive in young markets. Incentive markets originate from pride in the hope to establish a market for financial reward. > > "Stalemate"? That means that there is a gatekeeper blocking change or destroying incentives. What stops a Linux developer from evolving code? Obviously the cost of getting Microsoft to change their code would be a disincentive. Smalltalk is between those extremes, but with fewer incentives to overcome the cost-of-change. To me, Smalltalk development is about rapid evolution. Years ago I stopped caring about releasing code though gatekeepers. I expect you'll find many people have already done really great things but are not sharing them. That is a market opportunity for someone smart enough to develop it. > > Paul Baumann > > > > -----Original Message----- > From: vwnc-bounces(a)cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] On Behalf Of Janko MivÅ¡ek > Sent: Thursday, March 11, 2010 6:15 AM > To: Squeak; Pharo-project(a)lists.gforge.inria.fr; GNU Smalltalk; GemStone Seaside beta discussion; 'VWNC' > Subject: [vwnc] GSoC idea: Brainstorming portal for better community decision process > > Dear Smalltalkers, > > Becasue we have quite some problems in a community with seeking a consensus on important questions, from organization ones and on, I came to idea to build a tool for help. And a GSoC project can be an ideal opportunity to build such a tool. What do you think? > > Here is a description: > > Brainstorming portal for better community decision process ========================================================== > > Create a web portal for brainstorming sessions/meetings to get ideas and answers to important questions in Smalltalk community. Portal should allow on-line to: > > 1. brainstorm the ideas > 2. vote to get-out the best ideas > 3. seek consensus > 4. analyze - report > > On-line session/meeting should look like a Skype session together with a brainstorming portal, from collecting ideas to a final decision proposal. Example of such session can be a Squeak Oversight Board meeting or planning session for a new Smalltalk project. Or some broader session in the community, like on a question how to organize better. > > Some important concepts: > > * anonymity of idea proposers > * associations: proposers see the ideas of anonymous others to > facilitate an association for proposing an even better idea > * seeking consensus to avoid 51/49% decisions but to come closer to > 100% agreement on important ideas. > > Technical details > > * a web application for gathering brainstormed ideas in real-time > (using Ajax and Comet technology). > * voting system with appropriate algorithms > * analytics with on-line graphs and reports on paper/PDF > * installation on a publicly available hosting server > > Benefits to the Student > > * getting insight into group dynamics of Smalltalk community and in > general > * gaining knowledge of modern web technologies in Smalltalk and in > general > > Benefits to the Community > > Better community decision process by getting the best ideas from the members while on the other side avoiding stalemates so frequent in Smalltalk community those days > > > Best regards > Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

March 12, 2010

[Pharo-project] Fwd: [squeak-dev] image overload

by StÃ©phane Ducasse

Interesting idea. Stef Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: March 12, 2010 6:59:20 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org>, Pharo Development <pharo-project(a)lists.gforge.inria.fr>, vwnc NC <vwnc(a)cs.uiuc.edu> > Subject: [squeak-dev] image overload > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Hi All, > > I'm sure Im opening an old topic but anyway, as I was riding the train to work today I saw a shop called "Audio Images" and it struck me how overloaded the term image is, and how poor a term for the contents of the image file Smalltalk image is. What's in the image is a snapshot of... almost the entire system (minus platform-specific virtual machine and possibly minus sources). So Smalltalk system file would be a far better term and stsys a more unique file extension (and according to Wikipedia STS is unused too). I can imagine that changing form image would be hugely expensive in documentation terms (docs, websites, workspaces, etc, etc). But I can at least dream of a better term. > > P.S. I know, wasting one's time worrying about names. Almost as bad as worrying about colours > > "And the wheel," said the Captain, "What about this wheel thingy? It sounds a terribly interesting project." > "Ah," said the marketing girl, "Well, we're having a little difficulty there." > "Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? It's the single simplest machine in the entire Universe!" > The marketing girl soured him with a look. > "Alright, Mr. Wiseguy," she said, "if you're so clever, you tell us what colour it should be." >

March 12, 2010

Re: [Pharo-project] Collection

by StÃ©phane Ducasse

Thanks for the suggestions :) > >> Hi guys >> >> tristan is a new student here and he would like to work on collection optimization and implementation. >> I would like the get some ideas from you. >> - are there some collections that would be cool to improve? >> - are there some collections that would be cool to have and that we do not have yet? >> If you have any idea related to optimizations let me know. > > I will get bashed but: [1] no not us :) You remember I forced you to give a talk on what we could learn from Java :) > What would be cool for Seaside IMHO: > - Multi Value Dictionaries, e.g. for request parameters > - Some kind of thread safe map with atomic operations [2], e.g. for > session store > > [1] http://code.google.com/p/google-collections/ > [2] > http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentMap.ht… > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 12, 2010

Re: [Pharo-project] Class comments are in the .sources ?

by StÃ©phane Ducasse

:) We know you start to work the mega huge OO M :) Stef On Mar 12, 2010, at 1:06 PM, Marcus Denker wrote: > > On Mar 11, 2010, at 11:21 AM, StÃ©phane Ducasse wrote: > >> This is not bad or good. A lot of the design decision where taken for extremely small machines (80k loom) >> Now marcus would say that he wants everything in memory. :) > > I would that my 13inch *laptop* has 4GB RAM *today* and that research should be about inventing the Future... > > :-) > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 12, 2010

Re: [Pharo-project] Collection

by Igor Stasenko

On 11 March 2010 15:24, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi guys > > tristan is a new student here and he would like to work on collection optimization and implementation. > I would like the get some ideas from you. > Â Â Â Â - are there some collections that would be cool to improve? > Â Â Â Â - are there some collections that would be cool to have and that we do not have yet? > If you have any idea related to optimizations let me know. > I'd say that it is strange choice, because collections , apart of having big protocols don't really interesting piece of code from an optimization side, because most of things there already implemented quite good. Reimplementing them using traits - that's would be cool. > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 12, 2010

Re: [Pharo-project] [vwnc] image overload

by Eliot Miranda

On Fri, Mar 12, 2010 at 10:51 AM, Bruce Boyer <bruce.boyer(a)alumni.uci.edu>wrote: > This is rather a sensitive area with me at the moment, as I'm working on > indexing docs. I've had to resort to using "image" and "graphical image" to > try to distinguish these two, but "image" remains unclear to anyone who > doesn't already know. > > I could guess that the term "snapshot" came first, as a methaphorical > attempt to describe what saving that thing is, and "image" is what snapshots > give (or pictures or something even worse for that thing). But, it's only a > guess. > Right. That's why I don't like either snapshot or image. What are these snapshots or images of? They are intentionally abstract terms and are unhelpful. Yes, snapshot is much better, but still hopelessly abstract. > If a really good term were proferred, the documentation cost will be > amortized over a long period of time, so not a worry. Getting it accepted > by smalltalkers will be the harder problem. > > I'm not sure, though, that "system file" is right. The file part is just > an artifact of saving the state of the system, providing a way to preserving > it for a restart. > But I see a snapshot file are more than just a memory dump. It /is/ the entire Smalltalk system, class library, potentially compiler, debugger, tools. It is in a format that requires the virtual machine to run it, but it is in fact the Smalltalk system in quiescent form. It is not a memory dump. It is only a dump of the Smalltalk object heap, not the entire memory space. It is more than just a way of saving the state. It is also a way of moving that state and resuming it on a different system. Once you have the virtual machine key you can unlock the image, uh, system, but everything you need to program the system (beyond execution display and input devices) is there. Is there a recognizable term for the state of memory at a moment? > Cognitive scientists might have something, though I'm sure it would be > hugely debated whether there is any such thing. > I forget... > > Waste of time? Perhaps. But, beats indexing :) > > Bruce > > ----- Original Message ----- > *From:* Eliot Miranda <eliot.miranda(a)gmail.com> > *To:* The general-purpose Squeak developers list<squeak-dev(a)lists.squeakfoundation.org>; Pharo > Development <pharo-project(a)lists.gforge.inria.fr> ; vwnc NC<vwnc(a)cs.uiuc.edu> > *Sent:* Friday, March 12, 2010 9:59 AM > *Subject:* [vwnc] image overload > > Hi All, > > I'm sure Im opening an old topic but anyway, as I was riding the train > to work today I saw a shop called "Audio Images" and it struck me how > overloaded the term image is, and how poor a term for the contents of the > image file Smalltalk image is. What's in the image is a snapshot of... > almost the entire system (minus platform-specific virtual machine and > possibly minus sources). So Smalltalk system file would be a far better > term and stsys a more unique file extension (and according to Wikipedia STS > is unused too). I can imagine that changing form image would be hugely > expensive in documentation terms (docs, websites, workspaces, etc, etc). > But I can at least dream of a better term. > > P.S. I know, wasting one's time worrying about names. Almost as bad as > worrying about colours > > "And the wheel," said the Captain, "What about this wheel thingy? It sounds > a terribly interesting project." > "Ah," said the marketing girl, "Well, we're having a little difficulty > there." > "Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? > It's the single simplest machine in the entire Universe!" > The marketing girl soured him with a look. > "Alright, Mr. Wiseguy," she said, "if you're so clever, you tell us what > colour it should be." > > ------------------------------ > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >

March 12, 2010

Re: [Pharo-project] [Esug-list] Smalltalk app demo for GSoC

by Stan Shepherd

Ok, thanks. Tallman and I it is then. ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1590904.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 12, 2010

Re: [Pharo-project] [squeak-dev] image overload

by K. K. Subramaniam

On Friday 12 March 2010 11:29:20 pm Eliot Miranda wrote: > I'm sure Im opening an old topic but anyway, as I was riding the train > to work today I saw a shop called "Audio Images" and it struck me how > overloaded the term image is, and how poor a term for the contents of the > image file Smalltalk image is. What's in the image is a snapshot of... > almost the entire system (minus platform-specific virtual machine and > possibly minus sources). So Smalltalk system file would be a far better > term and stsys a more unique file extension (and according to Wikipedia STS > is unused too). If ever we change the image format, we should also change its name and extension. The first time people hear the term, they think of 'picture'. I suppose the term image is a Mac hangover :-). I prefer "bit bag" (*.bag) or "bag of bits" (*.bob). BTW, sts is already taken (Microsoft Visual C) Subbu

March 12, 2010

Re: [Pharo-project] [Esug-list] Smalltalk app demo for GSoC

by Lukas Renggli

> I am happy to volunteer, to to co-mentor with Tallman. I would however > recommend eg Lukas instead of me, for ready access to a lot of the > tacit knowledge about the stack. I am a bit busy writing my PhD. We can discuss in the list through. Lukas > > ...Stan > > On 12 March 2010 08:36, Mariano Martinez Peck [via Smalltalk] > <[hidden email]> wrote: >> Stan I am lost...do you volunteer to be the mentor of this project ? >> >> Tallman can be co-mentor if you want. >> >> PLease, let me know as soon as possible >> >> cheers >> >> mariano >> >> On Thu, Mar 11, 2010 at 11:49 PM, Stan Shepherd <[hidden email]> wrote: >>> >>> Mariano, the proposals are related in wanting to show the stack fully >>> integrated. The healthcare application wouldn't have the second benefit >>> that >>> it could be set up ready to roll for a web business. I think that would >>> be >>> a >>> key deliverable of the process I had in mind. It sounds like SmallPOS >>> would >>> be a closer fit from that point of view. So I'd prefer to keep them >>> separate; an attempt to do both projects as one would probably be too >>> large >>> to get either part done. >>> >>> Cheers, Â ...Stan >>> >>> -- >>> View this message in context: >>> >>> http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589873.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ________________________________ >> View message @ >> >> http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1590257.html >> To unsubscribe from Re: [Esug-list] Smalltalk app demo for GSoC, click >> here. >> > > ________________________________ > View this message in context: Re: [Esug-list] Smalltalk app demo for GSoC > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

March 12, 2010

[Pharo-project] image overload

by Eliot Miranda

Hi All, I'm sure Im opening an old topic but anyway, as I was riding the train to work today I saw a shop called "Audio Images" and it struck me how overloaded the term image is, and how poor a term for the contents of the image file Smalltalk image is. What's in the image is a snapshot of... almost the entire system (minus platform-specific virtual machine and possibly minus sources). So Smalltalk system file would be a far better term and stsys a more unique file extension (and according to Wikipedia STS is unused too). I can imagine that changing form image would be hugely expensive in documentation terms (docs, websites, workspaces, etc, etc). But I can at least dream of a better term. P.S. I know, wasting one's time worrying about names. Almost as bad as worrying about colours "And the wheel," said the Captain, "What about this wheel thingy? It sounds a terribly interesting project." "Ah," said the marketing girl, "Well, we're having a little difficulty there." "Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? It's the single simplest machine in the entire Universe!" The marketing girl soured him with a look. "Alright, Mr. Wiseguy," she said, "if you're so clever, you tell us what colour it should be."

March 12, 2010