- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo-2.0-Tests Â» 32,win - Build # 141 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 21, 2012

Re: [Pharo-project] Fastest utf-8 encoder contest

by Igor Stasenko

On 21 June 2012 16:59, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Btw, if you want to optimize for shorter-encodings, couldn't you do > asm > Â Â cmp: asm EAX with: 16r80; > Â Â jl: oneByte; > Â Â cmp: asm EAX with: 16r800; > Â Â jl: twoBytes; > Â Â cmp: asm EAX with:16r1000; > Â Â jl: threeBytes; > Â Â label: fourBytes; > Â Â ... > Â Â jmp end; > Â Â label: threeBytes; > Â Â ... > Â Â jmp end; > Â Â label: twoBytes; > Â Â ... > Â Â jmp: end; > Â Â label: oneByte; > > Â Â label: end > > ie only one cmp/jmp for 1-byte chars (1 less jump than current), > and n cmp/2 jmp's for n > 1. > Haha, nice trick. > Or do the conditional jumps relying on last instruction stall enough that it > doesn't really matter? > Can't say.. benchmarks should demonstrate that, but guess 1 less jump speedup will be at the level of noise. I'm not even sure that doing 4-byte aligned memory writes will get over noise level :) > Cheers, > Henry > -- Best regards, Igor Stasenko.

June 21, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,win - Build # 140 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 21, 2012

[Pharo-project] SimplifiedChineseEnvironment>>leadingChar

by Hilaire Fernandes

Hello, I am curious to know what is the right fix to this issue when the locale is chinese: http://code.google.com/p/pharo/issues/detail?id=6117 Thanks Hilaire -- Dr. Geo -- http://www.drgeo.eu

June 21, 2012

Re: [Pharo-project] Fastest utf-8 encoder contest

by Henrik Sperre Johansen

Btw, if you want to optimize for shorter-encodings, couldn't you do asm cmp: asm EAX with: 16r80; jl: oneByte; cmp: asm EAX with: 16r800; jl: twoBytes; cmp: asm EAX with:16r1000; jl: threeBytes; label: fourBytes; ... jmp end; label: threeBytes; ... jmp end; label: twoBytes; ... jmp: end; label: oneByte; label: end ie only one cmp/jmp for 1-byte chars (1 less jump than current), and n cmp/2 jmp's for n > 1. Or do the conditional jumps relying on last instruction stall enough that it doesn't really matter? Cheers, Henry On 13.06.2012 04:44, Igor Stasenko wrote: > Hi, hardcore hackers. > please take a look at the code and tell if it can be improved. > > The AsmJit snippet below transforms an unicode integer value > to 1..4-byte sequence of utf-8 > > then the outer piece of code (which is not yet written) will > accumulate the results of this snippet > to do a memory-aligned (4byte) writes.. > like that, if 4 unicode characters can be encoded into 4 utf-8 bytes > (which mostly the case for latin-1 char range), then there will be > 4 memory reads (to read four 32-bit unicode values) but only single > memory write (to write four 8-bit utf-8 encoded values). > > The idea is to make utf-8 encoding speed close to memory copying speed :) > > convertUnicode: asm > " > input: > - EAX 32-bit unicode value to convert > > output: > - EAX - utf-8 encoded character (in little-endian byte order) max 4 bytes > - EDX - number of encoded bytes > " > | moreThanOne moreThanTwo moreThanThree end | > > moreThanOne := asm uniqueLabelName: 'moreThanOne'. > moreThanTwo := asm uniqueLabelName: 'moreThanTwo'. > moreThanThree := asm uniqueLabelName: 'moreThanThree'. > end := asm uniqueLabelName: 'end'. > > asm > cmp: asm EAX with: 16r7F; > jg: moreThanOne; > "one byte" > mov: 1 to: asm EDX; > jmp: end; > label: moreThanOne; > cmp: asm EAX with: 16r7FF; > jg: moreThanTwo; > "two bytes 80 .. 7FF" > " AH AL " > "00000aaa aabbbbbb" > > "110aaaaa 10bbbbbb > AL AH (little endian order) > " > shr: asm EAX with: 2; > shl: asm AL with: 2; > or: asm AX with: 2r1100000010000000; > xchg: asm AL with: asm AH; > mov: 2 to: asm EDX; > jmp: end; > label: moreThanTwo; > cmp: asm EAX with: 16rFFFF; > jg: moreThanThree; > "three bytes 800 ... FFFF" > " AH AL " > "aaaabbbb bbcccccc" > " => 1110aaaa 10bbbbbb 10cccccc" > shl: asm EAX with: 4; > shr: asm AX with: 2; > shr: asm AL with: 2; > " EAX = ...aaaa xxbbbbbb xxcccccc " > or: asm EAX with: 2r111000001000000010000000; "16rE08080" > shl: asm EAX with: 8; > bswap: asm EAX; > mov: 3 to: asm EDX; > jmp: end; > "four bytes 1000 ... 10FFFF" > " AH AL " > "000aaabb bbbbcccc ccdddddd" > "=> 11110aaa 10bbbbbb 10cccccc 10dddddd" > mov: asm EAX to: asm EDX; > shl: asm EAX with: 4; > shr: asm AX with: 2; > shr: asm AL with: 2; > " EAX = 0000000a aabbbbbb xxcccccc xxdddddd " > and: asm EAX with: 16r3F3F3F; > bswap: asm EAX; > shr: asm EDX with: 18; "6*3" > or: asm DL with: 16r11110000; > mov: asm DL to: asm AL; > mov: 4 to: asm EDX; > label: end > >

June 21, 2012

[Pharo-project] [update 2.0] #20150

by Esteban Lorenzano

20150 ----- Issue 6113: jenkins pharo tests for windows http://code.google.com/p/pharo/issues/detail?id=6113 (not working yet... but close)

June 21, 2012

Re: [Pharo-project] [Pharo-users] Spec version 1.0

by Sven Van Caekenberghe

On 21 Jun 2012, at 11:29, Benjamin wrote: > [1] http://hal.inria.fr/docs/00/70/80/67/PDF/SpecTechReport.pdf Hmm, documentation, lovely! Thx, Sven

June 21, 2012

Re: [Pharo-project] Opal ?

by Goubier Thierry

Le 21/06/2012 16:01, Marcus Denker a Ã©crit : > > On Jun 21, 2012, at 3:36 PM, Goubier Thierry wrote: >>> >>> It seem the final objective is to send something to Esug ? >> >> If I make it in time, yes. Ok, it seems I shouldn't try the RecompileTests then? > No, I don't use them right now... > >> So far, I have only the IRDecompilerTests which are failing. > > That is the one that depends on PetitParser (experiment, not needed will be done after > the rest works). > > State of things: > > 1) Backend. > > BC->IR->BC seem ok. > > - IRComparer new compareImage > shows 16 differences, mostly pop-combining and unused code after return skipped, seems good. > (this compares #abstractSymbolic on the bytecode level) > > - IRComparer new compareImageFrameSize > 10 methods have smaller framesize , 2 a larger one. > This needs to be checked. > > 2) AST to IR > AST-IR-BC > - OCRecompiler new inspect; recompileImage > shows 10 problems. 2 are undeclareds, one is related to primitive errors (which > is not yet supported). Rest are wrong stack depth on jump targets in the backend. > - CompilerComparer new compare: Morph > (this compares #abstractSymbolic on the bytecode level) > ==> 39 differences, need to be analyzed (same for the whole image). Ok, this is where I may see things. To insert things in the AST, I can subclass the RBProgramNodeVisitor ? > 3) Missing: IR->AST, mapping BC to text offset needs to be checked, and then integration > into the system. Error handling, things like that. > > On the good side, > > OCRecompiler new doInstallMethods; recompileImage > > seems to work. (did not yet run too many tests, first the rest of the problems need to be > fixed). > > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > > Thanks! Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 21, 2012

Re: [Pharo-project] New System Progress Bar

by Schwab,Wilhelm K

Events are preferable to exceptions for updating the bar. Exceptions should be reserved for things that are exceptional :) Event registrations should be weak so that one *can* set and forget, but one should also be able to explicitly unregister if desired/needed. I will also take this opportunity to re-assert that weak collections should be inherently thread-safe and self-repairing. Pharo's weaklings do not measure up to Dolphin's in these areas. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Thursday, June 21, 2012 10:14 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] New System Progress Bar To help explain the changes, here's a snippet from the fix to "Issue 6099: Deprecate #value: for system progress (was red cross during updates)" (http://code.google.com/p/pharo/issues/detail?id=6099) The API (see SystemProgressItemMorph) is not set in stone, but it's already much less confusing than the old pseudo-class implementation. Ultimately, I'd like to move to announcements instead of exceptions to signal progress, and decouple the progress model/view - maybe just [un]registering the progress morph to enable/disable. The slice in the inbox for this issue should fix the "red cross during updates" problem... MOTIVATION: The old system progress worked like this (for example)... SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar value: x. bar value: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. * The work block ([ :bar | ... ] above) would accept one argument * That argument (:bar above) would be a block, that would act as a pseudo-class. Depending on what was passed to #value:, it would perform different functions. Two are illustrated above: - #value: aNumber; where aNumber is between the min and max of the progress range -> Set the bar's current progress mark to that position. For example, 'bar value: 50' above would show the operation half complete - #value: aString -> Set the label of the progress morph to aString This was very confusing, so we created a real class, SystemProgressItemMorph, which now gets passed to the work block, and has a real API. So, for example, the following becomes: SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar current: x. bar label: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. As you can see, '#value: newValue' has become '#current: newValue', and '#value: newLabel' has become '#label: newLabel'. One wrinkle is that some users were passing a nil-like block instead of the the pseudo-class to suppress the system progress bar. For example: informUserDuring: aBlock aBlock value: [:string | ]. Above, [:string | ] would now cause a DNU when sent, for example, #current:, which obviously blocks don't understand. So, these cases were changed like so: informUserDuring: aBlock aBlock value: DummySystemProgressItem new. Where DummySystemProgressItem simply ignores all messages without signaling an error -- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

Re: [Pharo-project] badDirectoryPath

by Esteban Lorenzano

that was changed not much time ago, and... while I don't remember exactly while it was like that, I remember there was a good reason for that On Jun 21, 2012, at 4:16 PM, Sean P. DeNigris wrote: > lookupDirectory: fullPath filename: fileName > <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> > ^ #badDirectoryPath > > Why are we returning #badDirectoryPath instead of signaling an exception, > maybe FileDoesNotExist? > > -- > View this message in context: http://forum.world.st/badDirectoryPath-tp4635913.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 21, 2012