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

OpenBuildService
by Sean P. DeNigris April 20, 2015

April 20, 2015

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

3 3

New Platform All-in-one Downloads
by Sean P. DeNigris April 20, 2015

April 20, 2015

These have VM + image like the standard Mac/Windows zips - GNU/Linux clib < 2.15 - http://files.pharo.org/platform/Pharo4.0-linux-oldLibC.zip - CentOS - http://files.pharo.org/platform/Pharo4.0-centos.zip ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Platform-All-in-one-Downloads-tp4820688.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

1 0

Bug in SmalltalkHub?
by Jan Vrany April 20, 2015

April 20, 2015

Hi, (Esteban), I'm trying to upload couple .mcz to Smalltalk hub using following script: ==== for f in $(cd mc && ls *.mcz); do echo -n "Uploading $f..." curl --user JanVrany:<my password here> --upload-file mc/$f http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main/$f; echo done === and I'm getting following output: === Uploading CalipeL-S-Benchmarks-Game-JanVrany.ee1fd4a6e836.20150420125300.mcz...receiver of "asTimeStamp" is nil Uploading CalipeL-S-Benchmarks-Micro-JanVrany.ee1fd4a6e836.20150420125300.mcz...receiver of "asTimeStamp" is nil Uploading CalipeL-S-Core-JanVrany.ee1fd4a6e836.20150420125300.mcz...receiver of "asTimeStamp" is nil Uploading CalipeL-S-Tests-JanVrany.ee1fd4a6e836.20150420125300.mcz...receiver of "asTimeStamp" is nil === The .mcz load into Pharo image just fine. The last time I did this was Dec 2014 and it worked like a charm. Is it a bug? If not, how can I upload a new .mcz to SmalltalkHub? I can provide .mczs for debugging. Best, Jan

1 0

moved Rubric and Bloc to Pharo from PharoExtras
by Andrei Chis April 20, 2015

April 20, 2015

Hi, I moved Rubric and Bloc to Pharo, deleted the projects from PharoExtras and updated the Moose configurations. If you give me access to the CI build for Bloc I can also updated it. Cheers, Andrei

2 2

Pharo 4.0 - display
by recursive68＠gmail.com April 19, 2015

April 19, 2015

Hi, I've had a play with Pharo 4.0 on a OSX and it looks great. There is one thing I've noticed, whenever I open a new window such as System Browser or Playground in the environment and then move it or close it, it's leaving an outline of each position of the window, if I move a window it's leaving a trail of outlines. Any ideas ? Thanks

6 5

Pharo 4.0 - display
by recursive68＠gmail.com April 19, 2015

April 19, 2015

It was the main/primary Pharo 4.0 download for Mac OSX from the main pharo site. It's on a MAC with Retina display. Thanks

1 0

New Cog VMs available
by Eliot Miranda April 19, 2015

April 19, 2015

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

7 17

Re: [Pharo-dev] Rubric and Bloc are now in PharoExtras
by Andrei Chis April 18, 2015

April 18, 2015

I can do the move tomorrow and also update the ci job if you give me the right permission on jenkins. Cheers, Andrei On Sat, Apr 18, 2015 at 10:40 PM, Alain Plantec via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Alain Plantec <alain.plantec(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Date: Sat, 18 Apr 2015 22:37:19 +0200 > Subject: Re: [Pharo-dev] Rubric and Bloc are now in PharoExtras > ok, but I canât do it now. For 5 days, the only (limited) internet > connection I can > have is through my phone. > Cheers > Alain > > On 18 Apr 2015, at 21:09, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Ok. Let's move them then. > > Could you do it? > > Cheers, > Doru > > > > On Sat, Apr 18, 2015 at 7:07 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> I guess I interpreted Extras as projects that are not right now in code. >> We should move then Rubric and Bloc to Pharo. >> >> Cheers, >> Andrei >> >> On Sat, Apr 18, 2015 at 6:57 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> >>> >>> Le 18/4/15 13:01, Tudor Girba a Ã©crit : >>> >>> 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? >>> >>> >>> I always thought that Extras was projects that would not be in the core. >>> Now bloc should at the end be in the core. >>> >>> 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" >>> >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > >

1 0

NativeBoost / Callbacks and Multithreading
by Nicolai Hess April 18, 2015

April 18, 2015

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

6 5

Re: [Pharo-dev] Rubric and Bloc are now in PharoExtras
by stepharo April 18, 2015

April 18, 2015

4 5