- Pharo-dev - lists.pharo.org

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

by Tudor Girba

That is unclear to me, too. I thought that the Pharo repo is only for the code from the Pharo image, but I now see that we have other projects, like TxText, there as well. So, what is the preferred way? Cheers, Doru On Sat, Apr 18, 2015 at 8:13 AM, stepharo <stepharo(a)free.fr> wrote: > Just a meta remark why extras and not Pharo? > > Le 17/4/15 12:58, Alain Plantec via Pharo-dev a Ã©crit : > > > -- www.tudorgirba.com "Every thing has its own flow"

April 18, 2015

Re: [Pharo-dev] Bloc CI?

by Tudor Girba

Sure. Doru On Sat, Apr 18, 2015 at 8:15 AM, stepharo <stepharo(a)free.fr> wrote: > hi guys > > I would like to update the CI to point to the new location. > What do you think? > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

April 18, 2015

Re: [Pharo-dev] [ANN] Pharo 4.0 is released!

by Laszlo Zsolt Kiss

Thank you for all of the devs!

April 18, 2015

Re: [Pharo-dev] [Vm-dev] NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

by Esteban Lorenzano

Hi, Soâ¦ âmultithreadâ is a complicated issue. Pharo as most Smalltalks is designed thinking is as monolithic so if you are trying to make the image to work in different processesâ¦ it will not be easy at all :) Time ago Eliot did a prototype (more than a prototype in fact, but still far from âproduction readyâ) to have Threaded FFI and Iâm quite sure this is the way to go, at least as a 1st milestone. I already have a process building this experimental VM: https://ci.inria.fr/pharo/view/VM/job/CogMTVM/ <https://ci.inria.fr/pharo/view/VM/job/CogMTVM/> (No idea why windows build failed last two timesâ¦ this can be a random fail). I do not remember exactly the changes needed in the image to take advantage of itâ¦ it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of thisâ¦ no idea where it is now (if is already incorporated in latest FFI, which we have). Then, after thisâ¦ I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but Iâm just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this betterâ¦ I will let Eliot to explain better). TL;DR: Start for the CogMTVM, is the way to go. cheers, Esteban > On 17 Apr 2015, at 09:06, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Hi, > > I've tried to build a pharovm with multithread support. I changed the config in the > pharo generator.image to use the cogmt config and was able to build a vm. > But this vm crashes on startup. (windows7) > > Is this the right way and did anyone got this to work (windows or linux)? > > And can this work to make NB callbacks working for multithreaded libraries. > > (I made some simple bindings for the gstreamer lib with NB, this works > for simple calls (create element/change state). But I guess this won't work > for any gstreamer function that requests a callback that may b e called from > a different thread) > > Would this be the right way to do: > - build a vm with MT support > - guard the NB callback entry/leave code with the ownVM()/disownVM() call. > > Or is there more to do. > > Thanks in advance > > > nicolai > >

April 18, 2015

Re: [Pharo-dev] New Cog VMs available

by stepharo

I saw this item in the list Subversion -> Git Subversion is the current repository for generated Cog VM sources. This is seen as less desirable than a git repository for integration with CI. Moving Cog from subversion to git may seem straight-forward but needs to be done with tact to help people over the transition. I'm sure that esteban can help on this one. Stef

April 18, 2015

Re: [Pharo-dev] New Cog VMs available

by stepharo

>>> ... 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. That's cool. > 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. I'm happy too. BTW Kevin is making progress on the decompiler. So we have young guys learning around too. > > > 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 18, 2015

Re: [Pharo-dev] New Cog VMs available

by stepharo

Clement you will have to explain that to mere mortals :) BTW I was thinking that you should get in touch with Nicolai Hesse about MT :) Stef Le 18/4/15 02:15, ClÃ©ment Bera a Ã©crit : > > > 2015-04-17 13:35 GMT-07:00 Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > > > > On Fri, Apr 17, 2015 at 3:41 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@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%. > > > I think you made a typo. > > * This should speed up #== in the case where the answer was true, > which theoretically is in 50% of the cases, but in practice we've not > profiled it. > > 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. > > > It will make a difference on some benchmarks where we saw the overhead > of #== due to forwarding pointers checks. > > And Ryan has a really good understanding too. I really enjoy the > abstraction he made over the send logic. > And Tim has the ARM backend almost working too (it's a week of work to > have it working as far as I understood). > > > > 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 18, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50002 Home: https://github.com/pharo-project/pharo-core

April 18, 2015

[pharo-project/pharo-core] 840599: 50002

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 840599b9caff31c85c3160582e3c388d4ff5b239 https://github.com/pharo-project/pharo-core/commit/840599b9caff31c85c316058… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-18 (Sat, 18 Apr 2015) Changed paths: M FreeType.package/FreeTypeFont.class/instance/displaying/displayLineGlyphOn_from_to_.st M FreeType.package/FreeTypeFont.class/instance/displaying/displayString_on_from_to_at_kern_baselineY_.st M FreeType.package/FreeTypeFont.class/instance/glyph lookup/glyphOf_destDepth_colorValue_subpixelPosition_.st M FreeType.package/FreeTypeSettings.class/instance/accessing/subPixelAntiAliasing.st A FreeType.package/FreeTypeSettings.class/instance/accessing/useSubPixelAntiAliasing.st M FreeType.package/extension/BitBlt/instance/installFreeTypeFont_foregroundColor_backgroundColor_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script610.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script611.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50001.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50002.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50002 15358 FreeTypeFont uses the wrong combination rule if subPixelAntiAliasing is disabled https://pharo.fogbugz.com/f/cases/15358 http://files.pharo.org/image/50/50002.zip

April 18, 2015

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

by stepharo

Indeed launcher is a better name. Le 18/4/15 06:56, Ben Coman a Ã©crit : > > This is where calling PharoLauncher "Pharo" is confusing. There is > Pharo 0.2.4 and also Pharo 4.0. What is a newcomer to think? > Cheers -ben > > On 17/04/2015 11:58 pm, "Damien Cassou" <damien.cassou(a)inria.fr > <mailto:damien.cassou@inria.fr>> wrote: > > > > ----- Mail original ----- > > De: "Sean P. DeNigris" <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> > > Ã: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@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 <http://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 18, 2015