- Pharo-dev - lists.pharo.org

[Pharo-project] Following context execution
by StÃ©phane Ducasse Jan. 31, 2012

Jan. 31, 2012

Hi I would like to write some tests about MethodContext and BlockClosure activation. To start I wanted to write a simple invocation and step in from context to context. I could manually annotate the code with thisContext and store the resulting contexts somewhere. But does anybody has some magic information so that I can reuse the debugger logic? Stef

2 3

[Pharo-project] Help with markdown is coming...
by Igor Stasenko Jan. 31, 2012

Jan. 31, 2012

a bit messy, because Camillo is a bad guy! ;) -- Best regards, Igor Stasenko.

2 1

Re: [Pharo-project] PseudoContext?
by Marcus Denker Jan. 30, 2012

Jan. 30, 2012

On Jan 29, 2012, at 6:02 PM, StÃ©phane Ducasse wrote: > Hi > > I have the impression that PseudoContext is not used anymore. At least compact class array and special object array > do not use it anymore. So what is the use for this class? > I think it was only used by Ian's original Jitter... which means 10 years unused. We should remove it. Marcus -- Marcus Denker -- http://marcusdenker.de

5 9

[Pharo-project] Fwd: [vwnc] Smalltalk for small projects only?
by Janko MivÅ¡ek Jan. 30, 2012

Jan. 30, 2012

-------- Prvotno sporoÄilo -------- Zadeva: Re: [vwnc] Smalltalk for small projects only? Datum: Mon, 30 Jan 2012 19:27:31 +0000 Od: Niall Ross <niallfr(a)btinternet.com> Dear Janko, (tried to send this to Pharo and squeak mailing lists as well as well as vwnc and you - got a hiccough; trying again just to vwnc and you). The largest Smalltalk project I've experienced was Kapital. They were approaching 70 developers in 4 locations in 2005 and IIUC are larger now. They use an in-house process based on Envy. Frequent rebuilding of images is forced by aging of Envy repositories, properly committed stuff being copied over. Thus developers are obliged to use correct process or lose code. I described the process briefly in a secondary talk (not my main one) at ESUG 2004, and Jan Monclair gave more recent info at ESUG 2008 and ESUG 2009 (see my reports on the ESUG website). A developer I knew there had practical experience of a rival's attempt to replicate their achievement in Java, using comparable resources, that crashed and burned. I've worked in two teams of 15 - 20 developers (one on a single site, one at two sites), each of which were verifiably matching systems maintained by ~100 developers in rivals. These were both in the insurance domain. In one of these, Envy-based, each developer rebuilt their image each day - the process took quite a few minutes but was valuable. In the other, images were eternal (yes, I do mean that!); it would take a long time to describe their process and even longer to convince readers that, contrary to what I at first thought and what most of you will think, it was a viable development process. All the other Smalltalk teams I've worked in, prior to coming to Cincom, were in single figures and used Store or Envy. One of them was verifiably rivalling a sytem of 10s of people in another language. Conclusions: 1) As your Smalltalk project gets large, you will need to put process and tools in place on top of what Envy, or Store, or, as Dale says, Monticello and Metacello, give you out-of-the-box at the moment. (It is news to me if Java projects of 200 people do not find the same, but I defer to those with more - which means any - experience of being in a 200-person Java project to correct me if that is not so - or is less so in some important respect.) It would be good if Smalltalk projects that find themselves growing into this area could get a tool/add-on that conveyed existing experience and solutions instead of having to re-roll their own superstructure on existing tools. (In Cincom, we are attempting to use our own development-process and build-process-improvement work to achieve this.) 2) Combining Kapital experience with the ratio one can justify between 'Smalltalk developers needed to do' and 'Java developers needed to do', persuades me that there is no limit on the complexity of problem Smalltalk can attack relative to its rivals. 3) I agree with Dale that making the minumum image smaller is the way to go. (Again, we wish to do this in VW; as always, such efforts progress slowly in background while we meet immediate requirements.) Yours faithfully Niall Ross -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

1 0

Re: [Pharo-project] [update 1.4] #14298
by Marcus Denker Jan. 30, 2012

Jan. 30, 2012

On Jan 30, 2012, at 4:52 PM, StÃ©phane Ducasse wrote: > > On Jan 30, 2012, at 1:31 PM, Camillo Bruni wrote: > >> I'll check again :) >> >> sorry I was unaware of the side-effects :D Works now... I added Camillo's fix as a changeset to the stream as 14299. Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] [update 1.4] #14298
by Marcus Denker Jan. 30, 2012

Jan. 30, 2012

On Jan 29, 2012, at 10:01 PM, Benjamin wrote: > It seems there is a problem with Metacello which take down half of Jenkins projects ... > > > I got this error: "'retry with alternate repository failed: ''FileExistsException: ''''/Users/benjamin/Images/Pharo 1.4/Pharo-1.4 2/package-cache/Metacello-Base-DaleHenrichs.19.mcz'''''''" > This needs to be reverted: http://code.google.com/p/pharo/issues/detail?id=5222 So a .cs that either fixes it or reverts the change would help... I can look at reverting it the evening. Marcus -- Marcus Denker -- http://marcusdenker.de

4 5

[Pharo-project] small display in the image with condensed changes
by Pavel Krivanek Jan. 30, 2012

Jan. 30, 2012

Hi, I tried the latest image with condensed changes from the CI server (https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4%20condense…) and when I open the image, it has very small display size, something like 12x12 pixels. The standard 1.4 image has normal display extent. Can you confirm that on other systems and VMs? Btw. Stef or Marcus, can you separe ThreadSafeTranscript to a standalone package. There was enough messages about Pharo-Kernel job failures :-) Cheers, -- Pavel

2 1

[Pharo-project] NonInteractiveUIManager
by Sven Van Caekenberghe Jan. 30, 2012

Jan. 30, 2012

When making syntax errors in a startup script you get SubclassResponsibility: a NonInteractiveUIManager had the subclass responsibility to implement #syntaxErrorNotificationDefaultAction: Would it not be a better idea to just handle and print the syntax error ? Sven

3 3

Re: [Pharo-project] Collection new
by Marcus Denker Jan. 30, 2012

Jan. 30, 2012

On Jan 30, 2012, at 4:35 PM, Marcus Denker wrote: > > On Jan 30, 2012, at 4:30 PM, Andrew P. Black wrote: > >> Hmm, is this really right? I'm used to seeing "Error in printString ..." >> > > Wasn't that a bug we already fixed? In 1.4 I can do Collection new and I get the subclass responsibility... > And I thought we back-ported the fix to 1.3, too. > > Need to check... Ah, the One-Click is 13315, but there is a #13320... We should update the download. (which includes fixing the jenkins build, for the VM, too). Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] Collection new
by Marcus Denker Jan. 30, 2012

Jan. 30, 2012

On Jan 30, 2012, at 4:30 PM, Andrew P. Black wrote: > Hmm, is this really right? I'm used to seeing "Error in printString ..." > Wasn't that a bug we already fixed? In 1.4 I can do Collection new and I get the subclass responsibility... And I thought we back-ported the fix to 1.3, too. Need to check... > > On 30 Jan 2012, at 11:12 , Milan Mimica wrote: > >> >> >> On 30 January 2012 19:31, Andrew P. Black <black(a)cs.pdx.edu> wrote: >> >> But I don't understand the root cause. Printing eventually sends do:, which is self subclassResponsibility. Why don't we get a clean failure? >> >> Andrew >> >> When an error occurs during error handling (which includes printing) it is not a clean failure. Emergency evaluator pops up in that case. >> > > -- Marcus Denker -- http://marcusdenker.de

1 0