April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Ugly textrendering (vertical label)

by Nicolai Hess

2014-12-10 21:03 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > Someone knows, why the text on the completion morph is so ugly? > For example, this text > > Morph ne > > will open a completion window for "Morph class". This name > is a vertical label on the left. > > The text looks ugly when we are using a FT font. > > Can we do anything to make this look better ? > > I know that (smooth) text rendering is difficult for arbitrary rotated > forms, but > this rotation around n*90 degree works with StrikeFont. > > > nicolai > > Ah, finally -> 15358 <https://pharo.fogbugz.com/default.asp?15358> FreeTypeFont uses the wrong combination rule if subPixelAntiAliasing is disabled TransformationMorph disables subPixelAntiAliasing if the transformation scales and/or rotates. But FreeTypeFont only checks this value to select the glyph, and still uses the subPixelAntialiasing bitblt combination rule for rendering the string.

April 17, 2015

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3312. These VMs /do/ fix the regression introduced in r3308. Again apologies. CogVM binaries as per VMMaker.oscog-eem.1207/r3312 Head slap! Fix the copy-paste error that caused the regression in VMMaker.oscog-eem.1160/3308. -- best, Eliot

April 17, 2015

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

On Fri, Apr 17, 2015 at 3:41 AM, stepharo <stepharo(a)free.fr> wrote: > > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3311/. > > These should fix the regression introduced by the map changes in 3308. > They certainly fix the two crashes I've looked at, one an update of a > squeak trunk image and the other the startup of recent Newspeak images. > Apologies for the inconvenience. > > > Well, this is embarrassing as usual but I'm still seeing crashes in the > image update. So I'll have to look deeper. At least the Newspeak fix was > real, but it didn't fix everything. > > > :) > Hi eliot > How can we help? > Would it make sense to have some more ci jobs for testing the VM? > Yes, that always helps. But we have to accept that that means a) these CI jobs will detect failures caused by regressions etc b) we need to mark builds as "bleeding edge" "last known good" etc, and set these pointers b) I have yet to set up. But yesterday and today a wonderful thing has happened. ClÃ©ment has understood the core optimization and code generation structures in the JIT as well as I do and is now both improving the code quality and implementing more aggressive optimizations. This is /so/ satisfying. You know how good ClÃ©ment is. His input is so strong. I am /very/ happy. For example, ClÃ©ment is currently modifying #== in the Spur JIT so that the code checks for forwarders only if #== is false, and that if #== is false and either object is a forwarder, it/them is/are followed and the #== retried. This should speed up #== by 50%. It won't make much difference at the macro level but this is a non-trivial optimization to write and so now we have two people who really understand the core optimizing JIT and I can now happily run in front of a bus. > Stef > > > > CogVM binaries as per VMMaker.oscog-eem.1204/r3311 > > Cogits: > > Fix regression in map machinery due to adding AnnotationExtension scheme. > findMapLocationForMcpc:inMethod: must not be confused by IsDisplacementX2N > bytes. This is likely the cause of the recent crashes with r3308 and > earlier. > > Introduce marryFrameCopiesTemps and use it to > not copy temps in Spur context creation trampolines. > > Change initial usage counts to keep more recently jitted methods around > for > longer, and do *not* throw away PICs in freeOlderMethodsForCompaction, so > that > there's a better chance of Sista finding send and branch data for the > tripping > method. > > extendedPushBytecode /does/ need a frame. > > Don't save the header in a scratch register unless > it is useful to do so in the Spur at:[put:] primitives. > > Fix slip in genGetNumBytesOf:into:. And notice that > genGetFormatOf:into:baseHeaderIntoScratch: et al can use byte access > to get at format, as intended in the Spur header design. > > Fix unlinking dynamic super sends. > > Reduce false positives in access control violation reporting by marking > the > super send we actually use as privileged. Remove unused Newspeak bytecodes. > > Internal: > > Fix code generation bug surfaced by inline primitives. On x86 movb > N(%reg),%rl > can only store into al, bl, cl & dl, whereas movzbl can store into any > reg. On > ARM move byte also zero-extends. So change definition of MoveMbrR to > always > zero-extend, use movzbl on x86 and remove all the MoveCq: 0 R: used to > zero the > bits of the target of a MoveMb:r:R:. And now that we have > genGetNumSlotsOf:into:, use it. > > Fix a slip in genTrinaryInlinePrimitive:, meet constraint that the > target must > be in ReceiverResultReg, and do a better job of register allocation > there-in. > > Do dead code elimination for the branch following an inlined comparison > (this > is done in genBinaryInlineComparison:opFalse:destReg: copying the scheme in > genSpecialSelectorEqualsEquals). > > Do register allocation in the right place in genUnaryInlinePrimitive:. > > Fix overflow slot access in genGetNumSlotsOf:into: et al. > > Fix several slips in inline primitive generation: Object>>at:put: needs > to > include a store check. Some register allocation code was wrong. Some > results > needed converting to SmallIntegers and recording results as pushed on the > sim > stack. > > Change callPrimitiveBytecode to genCallPrimitiveBytecode in the Cogit. > remove the misnomer genConvertIntegerToSmallIntegerInScratchReg: > > Type of AbstractInstruction opcode must be unsigned now that we have > more than 128 opcodes (XCHGRR pushed things over the top). > > Lay the groundwork for 32-bit intra-zone jumps and calls on ARM by > introducing > CallFull and JumpFull (and rewrites thereof) that are expected to span the > full > address space, leaving Call/JumpLong to span merely the 16mb code zone. > On x86 > CallFull and JumpFull simply default to Call/JumpLong. > > Replace bytecode trapIfNotInstanceOf by jumpIfNotInstanceOfOrPop. > > Rewrote the JIT logic for traps to be able to write trap trampolines > calls at > the end of the cogMethod. > > Refactor the slot store and store check machinery to take an inFrame: > argument > and hence deal with the store check in genInnerPrimitiveAtPut: on ARM. > > Fix limitation with MoveRXbrR; can only do movb from > %al through %dl, so swap with %eax around movb. > > Fix mistake with genGetNumBytesOf:into: by refactoring > genGetFormatOf:into:baseHeaderIntoScratch: into > genGetBits:ofFormatByteOf:into:baseHeaderIntoScratch: > and hence fetching and subtracting only odd bits of format. > > Correct the in-line primitive SmallInteger comparisons; CmpXR is > confusing ;-) > > Fix var op var unsafe byte at:. Result must be converted to > SmallInteger. > > Correct the generated Slang for the new register allocation code by > adding a > read-before-written pass to C generation that initializes variables > read-before-written with 0 (the C equivalent of nil). > > fix a bug where sometimes register allocation was marking > ReceiverResultReg as > dead whereas it was still alive. > > Added some abstraction over register allocation. This is now used in > inline > primitives. > > > > -- best, Eliot

April 17, 2015

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

On 16 Apr 2015, at 17:39, Eliot Miranda wrote: > > On 16 Apr 2015, at 16:50, Eliot Miranda wrote: > >> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3311/. >> >> These should fix the regression introduced by the map changes in 3308. They certainly fix the two crashes I've looked at, one an update of a squeak trunk image and the other the startup of recent Newspeak images. Apologies for the inconvenience. > > Well, this is embarrassing as usual but I'm still seeing crashes in the image update. So I'll have to look deeper. At least the Newspeak fix was real, but it didn't fix everything. And I have finally found it. A stupid copy paste error which caused the failure to mark references to classes in linked sends. Fixed VMs should be available in an hour or two. Again apologies. >> >> >> CogVM binaries as per VMMaker.oscog-eem.1204/r3311 >> >> Cogits: >> >> Fix regression in map machinery due to adding AnnotationExtension scheme. >> findMapLocationForMcpc:inMethod: must not be confused by IsDisplacementX2N >> bytes. This is likely the cause of the recent crashes with r3308 and earlier. >> >> Introduce marryFrameCopiesTemps and use it to >> not copy temps in Spur context creation trampolines. >> >> Change initial usage counts to keep more recently jitted methods around for >> longer, and do *not* throw away PICs in freeOlderMethodsForCompaction, so that >> there's a better chance of Sista finding send and branch data for the tripping >> method. >> >> extendedPushBytecode /does/ need a frame. >> >> Don't save the header in a scratch register unless >> it is useful to do so in the Spur at:[put:] primitives. >> >> Fix slip in genGetNumBytesOf:into:. And notice that >> genGetFormatOf:into:baseHeaderIntoScratch: et al can use byte access >> to get at format, as intended in the Spur header design. >> >> Fix unlinking dynamic super sends. >> >> Reduce false positives in access control violation reporting by marking the >> super send we actually use as privileged. Remove unused Newspeak bytecodes. >> >> Internal: >> >> Fix code generation bug surfaced by inline primitives. On x86 movb N(%reg),%rl >> can only store into al, bl, cl & dl, whereas movzbl can store into any reg. On >> ARM move byte also zero-extends. So change definition of MoveMbrR to always >> zero-extend, use movzbl on x86 and remove all the MoveCq: 0 R: used to zero the >> bits of the target of a MoveMb:r:R:. And now that we have >> genGetNumSlotsOf:into:, use it. >> >> Fix a slip in genTrinaryInlinePrimitive:, meet constraint that the target must >> be in ReceiverResultReg, and do a better job of register allocation there-in. >> >> Do dead code elimination for the branch following an inlined comparison (this >> is done in genBinaryInlineComparison:opFalse:destReg: copying the scheme in >> genSpecialSelectorEqualsEquals). >> >> Do register allocation in the right place in genUnaryInlinePrimitive:. >> >> Fix overflow slot access in genGetNumSlotsOf:into: et al. >> >> Fix several slips in inline primitive generation: Object>>at:put: needs to >> include a store check. Some register allocation code was wrong. Some results >> needed converting to SmallIntegers and recording results as pushed on the sim >> stack. >> >> Change callPrimitiveBytecode to genCallPrimitiveBytecode in the Cogit. >> remove the misnomer genConvertIntegerToSmallIntegerInScratchReg: >> >> Type of AbstractInstruction opcode must be unsigned now that we have >> more than 128 opcodes (XCHGRR pushed things over the top). >> >> Lay the groundwork for 32-bit intra-zone jumps and calls on ARM by introducing >> CallFull and JumpFull (and rewrites thereof) that are expected to span the full >> address space, leaving Call/JumpLong to span merely the 16mb code zone. On x86 >> CallFull and JumpFull simply default to Call/JumpLong. >> >> Replace bytecode trapIfNotInstanceOf by jumpIfNotInstanceOfOrPop. >> >> Rewrote the JIT logic for traps to be able to write trap trampolines calls at >> the end of the cogMethod. >> >> Refactor the slot store and store check machinery to take an inFrame: argument >> and hence deal with the store check in genInnerPrimitiveAtPut: on ARM. >> >> Fix limitation with MoveRXbrR; can only do movb from >> %al through %dl, so swap with %eax around movb. >> >> Fix mistake with genGetNumBytesOf:into: by refactoring >> genGetFormatOf:into:baseHeaderIntoScratch: into >> genGetBits:ofFormatByteOf:into:baseHeaderIntoScratch: >> and hence fetching and subtracting only odd bits of format. >> >> Correct the in-line primitive SmallInteger comparisons; CmpXR is confusing ;-) >> >> Fix var op var unsafe byte at:. Result must be converted to SmallInteger. >> >> Correct the generated Slang for the new register allocation code by adding a >> read-before-written pass to C generation that initializes variables >> read-before-written with 0 (the C equivalent of nil). >> >> fix a bug where sometimes register allocation was marking ReceiverResultReg as >> dead whereas it was still alive. >> >> Added some abstraction over register allocation. This is now used in inline >> primitives. >> >

April 17, 2015

Re: [Pharo-dev] Launcher Mac CI -> Broken Executable

by Sean P. DeNigris

Damien Cassou-2 wrote > The Pharo_0.2.6.dmg seems to work fine for me <http://forum.world.st/file/n4820289/Screenshot_2015-04-17_14.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/Launcher-Mac-CI-Broken-Executable-tp4820123p4820289.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 17, 2015

Re: [Pharo-dev] PharoLauncher and Pharo 5.0

by Jan BlizniÄenko

Hello Thank you, I decided to try it, so I downloaded Windows version - pharo_installer-0.2.6.exe . In settings, there used to be option to switch off categories of image sources/templates, like hide Pharo 2 category, but this option seems to be missing now. And one more thing ... GUI has some weird colors (well, I think it is actually missing colors). Screenshot: https://monosnap.com/file/Fs6rfZTlstzqkKzyReRnPUVa28FVZe.png However, this one is not today's change, because this morning I tried updating launcher (to find out whether it supports Pharo 5 :) ) and colors were already like this. Jan Torsten Bergmann wrote > Hi Damien, > > I added a 0.2.5 version to PharoLauncher now including > Pharo 5.0. Also Pharo 4.0 was switched from beta to stable. > Locally it works and I can download a Pharo 5.0. > Please review. > > I'm also not able to trigger the CI job: > https://ci.inria.fr/pharo/view/Launcher > Can you run the build? > > Thx > T. -- View this message in context: http://forum.world.st/PharoLauncher-and-Pharo-5-0-tp4820240p4820277.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 17, 2015

Re: [Pharo-dev] Rubric and Bloc are now in PharoExtras

by Alain Plantec

> On 17 Apr 2015, at 13:40, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Thank you!!! Quick question. What is our procedure about contributing to > projects which we own but are not part of Core? Should we commit to the > inbox or directly to the project repo? At the moment, I'm thinking of > non-controversial things like fixing comment typosâ¦ super, maybe wait that I make a pass because some of them are obsolete. Thanks Alain > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Rubric-and-Bloc-are-now-in-PharoExtras-tp4820182p4820… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 17, 2015

Re: [Pharo-dev] Launcher Mac CI -> Broken Executable

by Damien Cassou

----- Mail original ----- > De: "Sean P. DeNigris" <sean(a)clipperadams.com> > Ã: pharo-dev(a)lists.pharo.org > EnvoyÃ©: Vendredi 17 Avril 2015 07:35:31 > Objet: Re: [Pharo-dev] Launcher Mac CI -> Broken Executable > > Sean P. DeNigris wrote > > "Pharo" is damaged and can't be opened. You should move it to the Trash. > > All broken back to build #24 from Feb 25th. It was very tedious to find that > out, since the builds all claim to produce Pharo_0.2.4 The Pharo_0.2.6.dmg seems to work fine for me. It looks like files.pharo.org does not contain the file yet. Please use: https://ci.inria.fr/pharo/view/all/job/Launcher-Mac/44/artifact/Pharo_0.2.6…

April 17, 2015

Re: [Pharo-dev] PharoLauncher and Pharo 5.0

by Peter UhnÃ¡k

Thanks! I was about to ask about this. :) Also could there be an option to reuse parameters provided to the pharo(launcher) image? I always have to manually rewrite PhLimage>>launch: to fix encoding. ^OSProcess command: vmCommand , ' --textenc UTF-8 "' , imagePath, '"'. Peter On Fri, Apr 17, 2015 at 4:39 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Damien, > > I added a 0.2.5 version to PharoLauncher now including > Pharo 5.0. Also Pharo 4.0 was switched from beta to stable. > Locally it works and I can download a Pharo 5.0. > Please review. > > I'm also not able to trigger the CI job: > https://ci.inria.fr/pharo/view/Launcher > Can you run the build? > > Thx > T. > >

April 17, 2015

PharoLauncher and Pharo 5.0

by Torsten Bergmann

Hi Damien, I added a 0.2.5 version to PharoLauncher now including Pharo 5.0. Also Pharo 4.0 was switched from beta to stable. Locally it works and I can download a Pharo 5.0. Please review. I'm also not able to trigger the CI job: https://ci.inria.fr/pharo/view/Launcher Can you run the build? Thx T.

April 17, 2015