December 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] SMTPClient uses local address

by Sean P. DeNigris

SMTPClient>>initiateSession ... self sendCommand: ... NetNameResolver localHostName. ... This results in the local address (e.g. 10.0.0.5) being used, which sometimes gets kicked back by the mail server with: 550-"JunkMail rejected - ool-182daabe.dyn.optonline.net (10.0.0.5) -- View this message in context: http://forum.world.st/SMTPClient-uses-local-address-tp4178445p4178445.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 94 - AnnouncementSet

by StÃ©phane Ducasse

I'm a group of announcements. I can be used to register action to a group of announcement instead of enumerating them one by one. On Dec 9, 2011, at 10:46 PM, sean(a)clipperadams.com wrote: > 93 classes done > 802 classes remaining > Continuing in Announcements... > > Today: AnnouncementSet > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! >

Dec. 9, 2011

Re: [Pharo-project] MenuMorph instances

by StÃ©phane Ducasse

> "MenuMorph allInstances" returns an array of 27 in my personal 1.3 image, and > 5 in a fresh 1.3 rc. Are they cached? orphaned? Not that I know. Stef

Dec. 9, 2011

[Pharo-project] [COTDC] 94 - AnnouncementSet

by sean＠clipperadams.com

93 classes done 802 classes remaining Continuing in Announcements... Today: AnnouncementSet Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 9, 2011

Re: [Pharo-project] Exception Handling in the Moose Distribution Image

by StÃ©phane Ducasse

Yes it was the problem with the Stream basicNew. In 1.4 latest version it works. On Dec 9, 2011, at 4:24 PM, Mircea Filip Lungu wrote: > Hi guys, > > This is a bug report I got from one of my students and replicated by myself: > > In the Moose 4.6 image downloaded from moosetechnology.org, if I > execute the following code > > | c | > c := Collection new. > c add: 1. > > the image seems to freeze, although what I would expect is that > SubclassResponsibility > exception to be raised. This has been observed on Windows and Mac. > > Do you know about this? > > Thanks, > M. > > -- > Dr. Mircea Lungu > Researcher > Software Composition Group > University of Bern > > > -- > Dr. Mircea Lungu > Researcher > Software Composition Group > University of Bern >

Dec. 9, 2011

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Schwab,Wilhelm K

Ok, but I have never failed to be impressed by how much trouble even green threads can cause. Meaning no disrespect, if I had a repeatable failure scenario, I would make the switch to a mutex just in case. If for no other reason, Semaphore>>critical: makes assumptions about what is and is not interruptible. I don't have to so much as play dumb here (it comes naturally at the vm level), but I can't help wondering about the validity of the assumptions, the correctness of the code, and all the more so given our move to Cog. Is there a reason *not* to use Mutex in such situations? We have multiple users telling us there is a problem. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] Sent: Friday, December 09, 2011 1:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] How to resurrect an unrepsonsive image? On 09.12.2011 16:59, Schwab,Wilhelm K wrote: > I would be very curious about what happens if you replace the socket-related mutual exclusion semaphores with mutexes. For the semaphore in question here, there is no recursion going on in any of the critical sections. So the answer to that would be absolutely nothing. Cheers, Henry

Dec. 9, 2011

[Pharo-project] MenuMorph instances

by Sean P. DeNigris

"MenuMorph allInstances" returns an array of 27 in my personal 1.3 image, and 5 in a fresh 1.3 rc. Are they cached? orphaned? -- View this message in context: http://forum.world.st/MenuMorph-instances-tp4178039p4178039.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2011

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Henrik Sperre Johansen

On 09.12.2011 16:59, Schwab,Wilhelm K wrote: > I would be very curious about what happens if you replace the socket-related mutual exclusion semaphores with mutexes. For the semaphore in question here, there is no recursion going on in any of the critical sections. So the answer to that would be absolutely nothing. Cheers, Henry

Dec. 9, 2011

Re: [Pharo-project] GUI Testing Library

by Sean P. DeNigris

Sean P. DeNigris wrote > > I will open an issue Issue 5077: UI simulation from BDDExtensions project http://code.google.com/p/pharo/issues/detail?id=5077 -- View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4177726.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2011

Re: [Pharo-project] RB AST Rewriter to eliminate/consoliate temporary variables?

by Lukas Renggli

>>> But in this simple example, I could remove t2 and use t1 instead. >> >> No, "o1 foo", "o2 bar: t1", "o3 bar: t1" could have side-effects that >> influence what "o1 foo" returns. No tool on the world (without >> additional knowledge) can safely replace "t2" with "t1". > > It is about the slot, not about the value. This is a perfectly legal transformation: > > | t1 | > t1 := o1 foo. > o2 bar: t1. > o3 bar: t1. > > t1 := o1 foo. > o2 bar: t1. > o3 bar: t1. > > That is the same what register allocators do. t1, as a slot, is not going to be read anymore, thus, the slot can be used to hold another temporary value. Luckily Smalltalk is not a register machine. Even if your example looks perfectly linear, the order in which the statements are executed is pretty much unpredictable (think of exceptions, continuations, reflection, ...). > Well, anyway, I just hope that I can work around the frame size limitations when I encounter them in real code. The NewCompiler had a visitor that would overflow excess literals into arrays. You could theoretically do the same for excess temps. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 9, 2011