- Pharo-dev - lists.pharo.org

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

March 26, 2011

13112 ----- - Issue 2704: Tests for broken withNoLineLongerThan: behavior. Thanks Nicolas Cellier and Andreas Raab. - Issue 3864: [Failing Test] 1.3 ImageSegmentTestExport. - Issue 3341: use #= for integer comparison instead of #==. Kernel Part. - Less overrides in the system: around 100 left. :( Thanks you all. I feel that we are getting to the point where we will really move forward. Stef

1 0

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

March 26, 2011

On Mar 25, 2011, at 5:46 PM, Camillo Bruni wrote: >> > > Arguing with absolute values is a bit dangerous: > > But it makes > 13ms / 17ms * 100% = 76% => 25% speed improvement! in COG > 50ms / 60ms * 100% = 83% => 17% faster > > So the impact is still quite big. But indeed I would be in favor of a normal message send... > And are you sure that your Doit is actually JITed in Cog? 1) always take the overhead of the loop into acount. Especially if it is a large percentage, it can make you "slowdown" seem very small even though it is huge. e.g. the overhead of the loop in your case should be *very* high. 90% of the execution time? 2) always make sure that you actually JIT. -> put it in a normal method in a class -> execute it at least 2 times Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 3

[Pharo-project] Issue 3864 in pharo: [Failing Test] 1.3 ImageSegmentTestExport
by pharo＠googlecode.com March 26, 2011

March 26, 2011

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3864 by marcus.d...(a)gmail.com: [Failing Test] 1.3 ImageSegmentTestExport http://code.google.com/p/pharo/issues/detail?id=3864 >>> Tests.System.ImageSegmentTestExport.testObsoleteFake37ClassesRefs >>> 0.167 139 >>> Tests.System.ImageSegmentTestExport.testSymbolsDuplicated 0.423 139 >>> Tests.System.ImageSegmentTestExport.testSaveClassAndNotTheMetaclass >>> 0.193 139 >>> Tests.System.ImageSegmentTestExport.testUniqueObjects 0.291 139 >>> Tests.System.ImageSegmentTestExport.testSaveAndLoadImageSegmentToDiskWithoutGC >>> >>> 0.22 139 >>> Tests.System.ImageSegmentTestExport.testSaveClassAndAlsoTheMetaclass >>> 0.112 139 >>> Tests.System.ImageSegmentTestExport.testStatesInExport 0.219 139 >>> Tests.System.ImageSegmentTestExport.testSegmentWordArraySize 0.093 139 >>> Tests.System.ImageSegmentTestExport.testSymbols 0.223 139 >>> Tests.System.ImageSegmentTestExport.testSaveAndLoadImageSegmentToDiskWithGC >>> >>> 0.22 139

1 2

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