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

[Pharo-project] Namespaces for Squeak

by Torsten Bergmann

FYI: see http://www.squeaksource.com/Names.html MIT License -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

March 27, 2009

[Pharo-project] Better documenting and consistency

by StÃ©phane Ducasse

Hi all today I wanted to finish my ThreadSafeTrasncript so I started to code buildWith: aBuilder "(self buildWith: MorphicToolBuilder new) openInWorld" ^self new buildWith: aBuilder and open open "self open" ^ (self buildWith: MorphicToolBuilder new) openInWorld and I realised that I do not know what open should return. Should it return the window or the model. I could not figure out I tried to understand what buildWith: should return but it was totally unclear Having better comment than buildWith: aBuilder ^self subclassResponsibility is needed if we want to continue to bash Java people. So what do we do? Stef

March 27, 2009

Re: [Pharo-project] why can't I file out a package?

by Keith Hodges

Michael Rueger wrote: > On Thu, Mar 26, 2009 at 11:21 PM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > >> I can file out a class, but not a package it seems. Should this be an >> issue, or am I missing something? >> > > In general there seems to be the notion in MC that there is no easy > way to file out things. What I would have liked to have while working > on the unicode release is the ability to file out changes between > packages. > > Santa? ;-) > > Michael > > If you mean like a diff package.... repository menu in the MC browser has an option. If you want this as a source you will have to open the ..mcd file Keith

March 26, 2009

Re: [Pharo-project] why can't I file out a package?

by Oscar Nierstrasz

Yeah, of course I have the fileout hiding inside my mcz file in the package-cache, but santa should help out here. Anyway, thanks for confirming the fail. - on On 26 Mar 2009, at 23:25, Michael Rueger wrote: > On Thu, Mar 26, 2009 at 11:21 PM, Oscar Nierstrasz > <oscar(a)iam.unibe.ch> wrote: >> >> I can file out a class, but not a package it seems. Should this be an >> issue, or am I missing something? > > In general there seems to be the notion in MC that there is no easy > way to file out things. What I would have liked to have while working > on the unicode release is the ability to file out changes between > packages. > > Santa? ;-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2009

Re: [Pharo-project] why can't I file out a package?

by Michael Rueger

On Thu, Mar 26, 2009 at 11:21 PM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > > I can file out a class, but not a package it seems. Should this be an > issue, or am I missing something? In general there seems to be the notion in MC that there is no easy way to file out things. What I would have liked to have while working on the unicode release is the ability to file out changes between packages. Santa? ;-) Michael

March 26, 2009

[Pharo-project] why can't I file out a package?

by Oscar Nierstrasz

I can file out a class, but not a package it seems. Should this be an issue, or am I missing something? - on

March 26, 2009

Re: [Pharo-project] call for mcm support in Squeaksource

by Mariano Martinez Peck

On Thu, Mar 26, 2009 at 1:40 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > MCM = monticello configuration maps (you can open a Monticello > > Configurations browser from the world menu) > > > > But the more interesting question is who is Santa and will he > > find the time to update squeaksource? ;) > I don't know, but perhaps this is "fixed" in new Monticello 1.6 and sourcetalk. I would love to have this working on pharo :) I see it's in milestone 3 o 4 I don't remember. Cheers, Mariano > > I have some ideas :) > > stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 26, 2009

Re: [Pharo-project] call for mcm support in Squeaksource

by StÃ©phane Ducasse

> MCM = monticello configuration maps (you can open a Monticello > Configurations browser from the world menu) > > But the more interesting question is who is Santa and will he > find the time to update squeaksource? ;) I have some ideas :) stef

March 26, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?

by Schwab,Wilhelm K

Sig, That's an interesting view of it, but I generally see it differently. "Good" threads are independent. They do things that are either truly separate tasks, or work on something lengthy and "report back" when it is finished. Being heavily rooted in engineering mechanics and having become something of an amateur grease monkey (hopefully one who knows his limits), I often visualize threads as gears with the stack pointer as a timing mark near the edge. The critical sections come into play only when the teeth might collide. It is a flawed analogy, but keeps me grounded. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Wednesday, March 25, 2009 7:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today? 2009/3/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > To call threaded code incomprehensible is to ignore many appropriate uses of them. Â The presumption is that software is thrown together and then made to work, rather than engineered to work correctly from the bottom up. Â Rather than focusing to exclusion on the non-determinism of threading, the author should also consider the independence of the individual threads; threads that do one thing and do it well can be far simpler than code that chops lengthy processes into small chunks that can be executed in sequence. > > At the risk of sounding prematurely curmudgeonly, I have used both approaches over time (using slicing when threads were not available to me). Â I would much rather face an over-protected (hence deadlocking) multi-threaded program than try to sort out a single-threaded switch statement from hell that tries to do the same job. Â Of course, I come at this with a Smalltalk bias, where finding the deadlock is often as simple as following a stack trace to an offending critical section. Â Dirty writes are a bear in any language, but my general approach is "don't make that mistake." Â It works for me. > Been there did that.. i especially run to a problem with deadlocking, ended up with coding a classes which enforcing the right order of entering the critical sections i.e. you can't enter the critical section B, if you previously not entered into critical section A. This works, of course, but not an elegant neither scalable.. because it leads to the point where you can simply have a single global critical section to be protected from all contention cases :) > Bill > > --- > Wilhelm K. Schwab, Ph.D. > bschwab AT anest DOT ufl DOT edu > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Michael van der Gulik > Sent: Wednesday, March 25, 2009 4:39 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today? > > On 3/26/09, Markus Fritsche <fritsche.markus(a)gmx.net> wrote: >> Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> | array sum1 sum2 | >>> sum1 := 0. sum2 := 0. >>> array := Array new: 10. >>> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: >>> 10) ] ] fork. >>> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: >>> 10) ] ] fork. >>> 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ]. >> >> Something I came across leately: Threads are evil - >> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > They're not evil, just mischievous. > > I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming. > > "This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash." > > heh. True. > > Gulik. > > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2009

Re: [Pharo-project] Plugins overview

by Mariano Martinez Peck

On Thu, Mar 26, 2009 at 12:12 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Torsten Bergmann wrote: > > StÃ©phane Ducasse wrote: > >> If you want that I try it tell me where I can find it. > >> Then another question is > >> what is the fallback if people do not have the plugin (I mean > >> something else than getting a primitive failed). > > > > > > Dear Santa, > > > > it would be nice to have a page on the pharo-project website > > with an overview and downloadable precompiled versions of all the > > plugins available. > I think this is ok. But I would also add a text that explains the mandatory or recommended plugins for a Pharo imagen. For example, TrueType. In addition, we can post the script that let the user know if he has or not those plugins. Moreover, we can put the links of this plugins (as torsten said. What do you think? > > Dear Torsten, > > is on its way. > > Santa (aka Michael who was supposed to start this two weeks ago) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 26, 2009