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

Re: [Pharo-project] Issue 2704 in pharo: Tests for broken withNoLineLongerThan: behavior.
by pharo＠googlecode.com March 26, 2011

March 26, 2011

Comment #6 on issue 2704 by elpochod...(a)gmail.com: Tests for broken withNoLineLongerThan: behavior. http://code.google.com/p/pharo/issues/detail?id=2704 I have another implementation for this method, which I think may be a bit cleaner (and also passes all tests) withNoLineLongerThan: maxWidth "Answer a string with the same content as receiver, but rewrapped so that no line has more characters than the given number" | res size left right limit next | size := self size. maxWidth isNumber not | (maxWidth < 1) ifTrue: [self error: 'too narrow']. ^self class new: size * (maxWidth + 1) // maxWidth "provision for supplementary line breaks" streamContents: [ :stream | right := 1. [right <= size] whileTrue: [ left := self indexOfAnyOf: CSNonSeparators startingAt: right ifAbsent: [ ^stream next: size - left + 1 putAll: self startingAt: left; contents ]. limit := left + maxWidth - 1. (limit >= size) ifTrue: [ ^stream next: size - left + 1 putAll: self startingAt: left; contents ]. next := left. [ next - 1 <= limit ] whileTrue: [ right := next. next := self indexOfAnyOf: CSSeparators startingAt: next + 1 ifAbsent: [ (next = left) ifTrue: [ limit + 1] ifFalse: [ limit+2 ] ]. (CSLineEnders includes: (self at: right)) ifTrue: [ next := limit+2]. ]. stream next: right - left putAll: self startingAt: left. (right <= size) ifTrue: [ stream cr ]. ] ].

1 4

[Pharo-project] "Does Committing Code to an Open Source Project Mean Committing Career Suicide?"
by csrabak＠bol.com.br March 25, 2011

March 25, 2011

Hi Folks, In the interminable stream of conflicting information I've received this link: http://www.softwarequalityconnection.com/2011/02/does-committing-code-to-an… I will not say that the author's resume (shown in the page linked) increase my level of credibility on her posting, but given the popularity of the site from where it was posted, and IMNHO echoes a kind of FUD typically seen w.r.t. Open Source I thought you would like to get to know about. If any of the concerns described in the article should be considered correct, perhaps we should have the letters we sign for participating updated with the appropriate provisos? Regards, -- Cesar Rabak

4 4

Re: [Pharo-project] Pharo 1.2 red again
by Marcus Denker March 25, 2011

March 25, 2011

On Mar 23, 2011, at 12:52 PM, Torsten Bergmann wrote: > Pharo 1.2 is red again! > > DuplicatedVariableError: stylingActive is already defined in Workspace > > https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ We really need to make sure that the config does not load code if we don't explicitly say so. So what code was changed? Why was it loaded? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

7 15

[Pharo-project] [update 1.3] #13110
by StÃ©phane Ducasse March 25, 2011

March 25, 2011

13110 ----- - Issue 3881: Problem with Inst var refs.... Thanks Benjamin van Ryseghem. - Issue 3879: Wipe out positional arguments cruft from compiler. Thanks Igor Stasenko. - Issue 3859: Pluggin control. Thanks Igor Stasenko. - Issue 3715: Workspace shouting after switching between shout/unshout. Thanks Benjamin van Ryseghem. - Cleaning MCPackageManager. - Fixing some as yet unclassified categories. Stef and igor happy integrating and chatting about life :)

3 3

[Pharo-project] pharo closures
by Toon Verwaest March 25, 2011

March 25, 2011

I've just been working the whole day on the OPAL decompiler, getting it almost to run (already works for various methods). Now ... could someone please explain to me why the current implementation of closures isn't a terribly bad idea? I can see why it would pay off for Lisp programmers to have closures that run like the Pharo closures, since it has O(1) access performance. However, this performance boost only starts paying off once you have at least more than 4 levels of nested closures, something which, unlike in LISP, almost never happens in Pharo. Or at least shouldn't happen (if it does, it's probably ok to punish the people by giving them slower performance). This implementation is pretty hard to understand, and it makes decompilation semi-impossible unless you make very strong assumptions about how the bytecodes are used. This then again reduces the reusability of the new bytecodes and probably of the decompiler once people start actually using the pushNewArray: bytecodes. You might save a teeny tiny bit of memory by having stuff garbage collected when it's not needed anymore ... but I doubt that the whole design is based on that? Especially since it just penalizes the performance in almost all possible ways for standard methods. And it even wastes memory in general cases. I don't get it. But probably I'm missing something? cheers, Toon

7 18

Re: [Pharo-project] Remove #class as a Compiler optimization
by Marcus Denker March 25, 2011

March 25, 2011

On Mar 25, 2011, at 7:09 PM, Toon Verwaest wrote: > >>> What do you think? >> >> I am for... for the JIT is is a monomorphic send to a primitive, so the IC will be very effective >> and should take care that the lookup is actually almost never done. (and the lookup is the >> only thing the #class bytecode saves, as the target method is a primitive). > I think that programmers should have the illusion that the VM interacts with the system through message sends. By being able to overwrite this particular message you break this illusion. Why that? I think exactly the opposite is true. If I write self class I think that I send #class to self. But in the current system I do not. If #class is not send, one can never ever do proxies that work for real. A proxy can never stand in for an object as #class always answers "Proxy", even though it should not. Or for a Future it will say "Future". > The VM will just fetch the real class; but the user doesn't get access to it anymore. Telling the system that this particular message shouldn't be overwritten is probably a good thing. > One should take care, but a system that just does not allow things like this *even if you take care* is bad. > If you want to overwrite the method class, maybe your tools should send another message than class in the first place? > So what if it's not a tool? It might be domain code that really does self class == something as part of execution. Now I want ot use a proxy here, but I can not. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Issue 2848 in pharo: Deprecate String>>asUrl
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Updates: Status: FixProposed Comment #4 on issue 2848 by marcus.d...(a)gmail.com: Deprecate String>>asUrl http://code.google.com/p/pharo/issues/detail?id=2848 (No comment was entered for this change.)

1 1

[Pharo-project] Issue 3718 in pharo: Color class>>wheel: should be (back) on class side
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: New Owner: ---- New issue 3718 by jbth...(a)gmail.com: Color class>>wheel: should be (back) on class side http://code.google.com/p/pharo/issues/detail?id=3718 Color class>>wheel: has been erroneously moved to the instance side. It has no function on instances, but rather constructs and returns an Array of Color instances -- clearly a class-side method. It does not pass its own self-test in the comment now. Please put it back on class-side. (Indeed, half the current senders are still messaging the class. The other 5 or 6 senders send #red or #new for no reason, and should message the class).

1 6

[Pharo-project] Issue 3850 in pharo: remove HTTPServerDirectory PseudoFileStream
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3850 by marcus.d...(a)gmail.com: remove HTTPServerDirectory PseudoFileStream http://code.google.com/p/pharo/issues/detail?id=3850 After Issue 3638 is closed, we can remove PseudoFileStream and HTTPServerDirectory (not used anymore). Attachments: CleanHttpServerDirectory.1.cs 194 bytes

1 2

[Pharo-project] Issue 3875 in pharo: Merge minor NumberParser refactorings from Squeak
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: Accepted Owner: nicolas....(a)gmail.com Labels: Type-Squeak New issue 3875 by nicolas....(a)gmail.com: Merge minor NumberParser refactorings from Squeak http://code.google.com/p/pharo/issues/detail?id=3875 There are three changed methods: 1) using peekSignIsMinus gives a chance to subclasses to parse a leading + 2) using ifNil: is faster than isNil ifTrue: (with current Compiler) 3) skip: -1 in an error case so as to insert the error message at the right place

1 2