- Pharo-dev - lists.pharo.org

live coding conference

by Ben Coman

Given that we promote ourselves as a Live Coding environment, anyone near Denmark want to check out if this aligns with our interests... Call for position papers and performances as part of Critical Alternatives, 5th Decennial Aarhus Conference, 18 August 2015, Aarhus University, Denmark. http://www.livecodenetwork.org/live-coding-alternatives/ cheers -ben

April 17, 2015

Re: [Pharo-dev] Versioning Jenkins Logic

by Damien Cassou

Sean P. DeNigris <sean(a)clipperadams.com> writes: > Right now, the https://ci.inria.fr/pharo/view/4.0-VM/job/PharoVM-CentOs6 > Jenkins job has the following shell script embedded in Jenkins. As you can > see, there is quite a bit of logic there. Wouldn't it be better to put this > type of thing under SCM? If so, I'm happy to do it, but where would be the > best place? Is there an existing location that could fit? https://github.com/pharo-project/pharo-ci/tree/master/ci-jobs/pharo/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 17, 2015

Re: [Pharo-dev] pharo home page tagline

by Ben Coman

Actually, another less-is-more improvement would be to change "Pharo The immersive programming experience" to just "Pharo immersive programming" (btw with the exclusion of capital letters from the tagline) cheers -ben On Fri, Apr 17, 2015 at 11: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

pharo home page tagline

by Ben Coman

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] Launcher Mac CI -> Broken Executable

by Sean P. DeNigris

Also, what significance does the version number have, since it stays static as the build evolves? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Launcher-Mac-CI-Broken-Executable-tp4820123p4820125.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 17, 2015

Launcher Mac CI -> Broken Executable

by Sean P. DeNigris

"Pharo" is damaged and can't be opened. You should move it to the Trash. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Launcher-Mac-CI-Broken-Executable-tp4820123.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 17, 2015

Re: [Pharo-dev] Pharo Image Freeze

by Gaurav Singh

Thanks, Will look into it :) On Fri, Apr 17, 2015 at 7:20 AM, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > Like Peter said, there's the CMD-. shortcut to break infinite loops. > > And if that doesn't work and the image crashes, you still typically don't > lose a lot of work. Don't forget, that every time you save (accept) a > single method, that change is written to the .changes file. Even if you > haven't saved the image before it crashes, you can use the > 'World > Tools... > Recover lost changes' tool to recover a lot of your > work. (Since you've been contributing to the UPBE book, take a look at the > 'How to get your code back' section in the Environment chapter :) ). > > > On Thu, Apr 16, 2015 at 7:58 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> There is a shortcut "alt + . (dot)" (maybe ctrl/cmd depending on >> platform), that will break the current execution and show the debugger >> (which you can then close) - useful if you have infinite loops and so forth. >> >> Peter >> >> On Fri, Apr 17, 2015 at 1:51 AM, Gaurav Singh <grvanm.coder(a)gmail.com> >> wrote: >> >>> Is there any way to get back the Pharo image working when it freezes >>> without closing the Pharo image because many times the work isn't saved and >>> then it costs a lot restarting the pharo image? >>> >> >> >

April 17, 2015

Re: [Pharo-dev] Pharo Image Freeze

by Dmitri Zagidulin

Like Peter said, there's the CMD-. shortcut to break infinite loops. And if that doesn't work and the image crashes, you still typically don't lose a lot of work. Don't forget, that every time you save (accept) a single method, that change is written to the .changes file. Even if you haven't saved the image before it crashes, you can use the 'World > Tools... > Recover lost changes' tool to recover a lot of your work. (Since you've been contributing to the UPBE book, take a look at the 'How to get your code back' section in the Environment chapter :) ). On Thu, Apr 16, 2015 at 7:58 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > There is a shortcut "alt + . (dot)" (maybe ctrl/cmd depending on > platform), that will break the current execution and show the debugger > (which you can then close) - useful if you have infinite loops and so forth. > > Peter > > On Fri, Apr 17, 2015 at 1:51 AM, Gaurav Singh <grvanm.coder(a)gmail.com> > wrote: > >> Is there any way to get back the Pharo image working when it freezes >> without closing the Pharo image because many times the work isn't saved and >> then it costs a lot restarting the pharo image? >> > >

April 17, 2015

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

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. > > > 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] New Cog VMs available

by Sean P. DeNigris

Eliot Miranda-2 wrote > ... Wow! That seems like a /lot/ of fixes... thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Cog-VMs-available-tp4820107p4820113.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 17, 2015