- Pharo-dev - lists.pharo.org

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? 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. >> >

April 17, 2015

Re: [Pharo-dev] pharo home page tagline

by kilon alios

I just point them to my own Pharo website which I think it gives a more clear picture what Pharo is all about , but hey , I am biased :) http://thekilon.wix.com/pharo-about On Fri, Apr 17, 2015 at 6:58 AM, Ben Coman <btc(a)openinworld.com> wrote: > On reddit I see some questions regarding the "IDE and OS rolled into one" > tagline on the pharo homepage. Of course it makes sense to me, but I can > see how it might not be clear to others, who might even think "I don't need > that, I already have an OS." I think the tagline would be strong enough > without it - less is more. > > cheers -ben >

April 17, 2015

Re: [Pharo-dev] Is Pharo Launcher Ready?

by stepharo

Le 16/4/15 14:14, Dale Henrichs a Ã©crit : > Thanks Damien, I will give it a go when I get a chance ... because it > broke about 2 months ago and my mail to this list went unanswered, > I've since removed it from my scripts (in an emergency no less, > because the scripts were failing) and I have become a bit gunshy about > relying on something that drops from support without warning .... > Believe me I did not want to learn about `ldd` and the 12.04 pharo > dependencies, but I had no choice:( > > I would like to be able to depend upon the zero conf scripts, because > they are very convenient, but I am still hazy on the policy towards > older releases and zero conf. > > It would be very convenient if the scripts worked "forever" for the > old releases (pharo3.0 will be old in a year:) they don't need to be > kept up to date with respect to the latest vm, but should be frozen at > the last stable vm for that platform/release ... if that were true > then I would be comfortable leaning heavily on zero conf for the > installation/update scripts...if not... Yes I agree with you. now we have reached a stable point where we can avoid to have latest vm creeping in old scripts. If I understood correctly what esteban told me. > > Dale > > On 4/16/15 1:52 AM, Damien Cassou wrote: >> Dale Henrichs <dale.henrichs(a)gemtalksystems.com> writes: >> >>> On 4/13/15 10:01 AM, Sean P. DeNigris wrote: >>>> IIUC we are planning on making Pharo Launcher the default download. >>> Not sure whether this is the right thread or not... >>> >>> Keep in mind that the last time I tried to use the Pharo Launcher (a >>> couple of months ago) on ubunutu12.04 the Ubuntu packaged failed to be >>> found and I had to abandon my use of Pharo Launcher since >>> Ubuntu12.04 is >>> still in common use ... >> I think Ubuntu 12.04 is supported now. See >> https://launchpad.net/~pharo/+archive/ubuntu/stable?field.series_filter=pre… >> >> >> > > >

April 17, 2015

Re: [Pharo-dev] OpenBuildService

by stepharo

Le 17/4/15 08:12, Sean P. DeNigris a Ã©crit : > After hearing Esteban mention it, I investigated http://openbuildservice.org/ > and it seems really exciting. IIUC, we can create one Fedora-style packag > Spec file, and have Pharo built on just about all distributions. that would be really awesome. Thanks for trying and pushing in that direction. > There is > even a community server (https://build.opensuse.org/) I've set up an > account there for test purposes and started playing. The initial results are > at https://github.com/pharo-project/pharo-openbuildservice. I also wrote > some notes at > https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/OpenBuil…. > I've gotten through the build process and I'm stuck on the installation > step. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/OpenBuildService-tp4820143.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 17, 2015

communicating pharo 4.0

by Tudor Girba

Hi, In case you were wondering about the details behind the visualization that came with the Pharo 4.0 announcement, here is a more detailed explanation: http://www.humane-assessment.com/blog/communicating-pharo-4-0 Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

April 17, 2015

Re: [Pharo-dev] GTSpotter and example previews

by Tudor Girba

Unfortunately, I do not know why some pieces of text render wrongly when transformed in a Form, but I would like to find it out if someone knows :) Doru On Fri, Apr 17, 2015 at 10:57 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-17 10:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> It's in the release because it is useful :). >> >> Indeed, some previews related to fonts do not render well, but you get >> the same problem in the Inspector. But, most previews are not that bad. See >> for example: >> [image: Inline image 1] >> >> But, there is another point. This mechanism allows people to hook their >> examples in the basic spotter. For example, Roassal examples can be found >> there. >> > > Indeed, for this example it looks really good (and is useful). > > I was afraid all examples, rendering some UI-Component, would look so ugly. > How it comes the other examples doesn't look like this one? > > > > > >> >> Cheers, >> Doru >> >> >> >> On Fri, Apr 17, 2015 at 12:48 AM, Nicolai Hess <nicolaihess(a)web.de> >> wrote: >> >>> Why is this in the release? >>> >>> GTSpotter now shows the result of gtExamples in the preview. >>> This looks so ugly. >>> (for example browse the "Examples" cateogry for GLMCompositeBrick) >>> >>> If new features aren't mentioned anywhere, it is pretty difficult >>> to test or to review them. >>> >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

April 17, 2015

Re: [Pharo-dev] GTSpotter and example previews

by Nicolai Hess

2015-04-17 11:13 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Speaking of examples, what is the point of having the "play" button on the > class side examples, when they are not actually usable examples? Is it > related to a different discussion about (gt)examples in another thread? > Yes, and we tried to clean this up. Are there still examples with a play button that don't work ? (All Classside>>#exampleXXX method should have a working play button. The gtExample methods used by the inspector and spotter should have been renamed to use a #SOMEOTHERWORDexample method name.) > > But the forms (and their api) do look nice compared to spec/moprhic. I > wonder how this could be merged. (After all Brick seems to be based on > Morphs and Spec is above Morphs.) > > Peter > > On Fri, Apr 17, 2015 at 10:57 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-04-17 10:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >>> Hi, >>> >>> It's in the release because it is useful :). >>> >>> Indeed, some previews related to fonts do not render well, but you get >>> the same problem in the Inspector. But, most previews are not that bad. See >>> for example: >>> [image: Inline image 1] >>> >>> But, there is another point. This mechanism allows people to hook their >>> examples in the basic spotter. For example, Roassal examples can be found >>> there. >>> >> >> Indeed, for this example it looks really good (and is useful). >> >> I was afraid all examples, rendering some UI-Component, would look so >> ugly. >> How it comes the other examples doesn't look like this one? >> >> >> >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Fri, Apr 17, 2015 at 12:48 AM, Nicolai Hess <nicolaihess(a)web.de> >>> wrote: >>> >>>> Why is this in the release? >>>> >>>> GTSpotter now shows the result of gtExamples in the preview. >>>> This looks so ugly. >>>> (for example browse the "Examples" cateogry for GLMCompositeBrick) >>>> >>>> If new features aren't mentioned anywhere, it is pretty difficult >>>> to test or to review them. >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >

April 17, 2015

Re: [Pharo-dev] GTSpotter and example previews

by Peter UhnÃ¡k

Speaking of examples, what is the point of having the "play" button on the class side examples, when they are not actually usable examples? Is it related to a different discussion about (gt)examples in another thread? But the forms (and their api) do look nice compared to spec/moprhic. I wonder how this could be merged. (After all Brick seems to be based on Morphs and Spec is above Morphs.) Peter On Fri, Apr 17, 2015 at 10:57 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-17 10:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> It's in the release because it is useful :). >> >> Indeed, some previews related to fonts do not render well, but you get >> the same problem in the Inspector. But, most previews are not that bad. See >> for example: >> [image: Inline image 1] >> >> But, there is another point. This mechanism allows people to hook their >> examples in the basic spotter. For example, Roassal examples can be found >> there. >> > > Indeed, for this example it looks really good (and is useful). > > I was afraid all examples, rendering some UI-Component, would look so ugly. > How it comes the other examples doesn't look like this one? > > > > > >> >> Cheers, >> Doru >> >> >> >> On Fri, Apr 17, 2015 at 12:48 AM, Nicolai Hess <nicolaihess(a)web.de> >> wrote: >> >>> Why is this in the release? >>> >>> GTSpotter now shows the result of gtExamples in the preview. >>> This looks so ugly. >>> (for example browse the "Examples" cateogry for GLMCompositeBrick) >>> >>> If new features aren't mentioned anywhere, it is pretty difficult >>> to test or to review them. >>> >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

April 17, 2015

Re: [Pharo-dev] GTSpotter and example previews

by Nicolai Hess

2015-04-17 10:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > It's in the release because it is useful :). > > Indeed, some previews related to fonts do not render well, but you get the > same problem in the Inspector. But, most previews are not that bad. See for > example: > [image: Inline image 1] > > But, there is another point. This mechanism allows people to hook their > examples in the basic spotter. For example, Roassal examples can be found > there. > Indeed, for this example it looks really good (and is useful). I was afraid all examples, rendering some UI-Component, would look so ugly. How it comes the other examples doesn't look like this one? > > Cheers, > Doru > > > > On Fri, Apr 17, 2015 at 12:48 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Why is this in the release? >> >> GTSpotter now shows the result of gtExamples in the preview. >> This looks so ugly. >> (for example browse the "Examples" cateogry for GLMCompositeBrick) >> >> If new features aren't mentioned anywhere, it is pretty difficult >> to test or to review them. >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

April 17, 2015

Re: [Pharo-dev] New User Question on Reddit

by Markus Fritsche

Hello Sean, I will be able to update the PPA on the weekend. Kind regards, Markus On 2015-04-17 00:58, Sean P. DeNigris wrote: > https://news.ycombinator.com/item?id=9390760 > > I installed this for Ubuntu 12.04. When I fired it up, it requested I > choose > and build a source file (different from Pharo 3). Then when it started, > it > said, "Pharo cannot locate the source file named > /usr/lib/pharo-vm/PharoV40.sources. > Any ideas what to do? > TIA, Steve

April 17, 2015