- Pharo-dev - lists.pharo.org

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

Bloc ci has been updated
by stepharo April 18, 2015

April 18, 2015

1 0

[ANN] Pharo 4.0 is released!
by Esteban Lorenzano April 18, 2015

April 18, 2015

Please spread widely. Sorry for multiple posts. (this post can be see here: http://pharo.org/news/pharo-4.0-released <http://pharo.org/news/pharo-4.0-released>) Dear World, Pharo 4.0 (http://www.pharo.org) is here. Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. Many things have changed in Pharo. Here are some highlights: - Inspector/Playground/Spotter are new moldable development tools for inspecting, coding and searching objects. - Slots model instance variables as first class entities and enable meta-programming on this level. - ShoreLine reporter introduces a way to report system errors and collect statistics, that we will use for future improvements - Dark theme. These are just the more prominent highlights, but the details are just as important. We have closed 1697 issues in Pharo 4. Take a moment to go through a more detailed recount of the progress: https://github.com/pharo-project/ChangeLogs/blob/master/Pharo40ChangeLogs.md Pharo is improving on many fronts, but one of the most prominent changes is the addition of moldable tools for inspection and search. These tools provide extension mechanisms that allow every object to define ways in which it can be understood effectively. To provide an idea of the impact of the already existing extensions, the map below shows the Pharo classes grouped in packages, highlighting in red those parts of the system that have at least one such custom view coming with the main distribution. The spread of these extensions shows that moldability is powerful mechanism that can be used in many contexts. Remember that Pharo is your platform. We thank all the contributors of this release: Clara Allende, Jean-Baptiste Arnaud, Jean-Christophe Bach, Philippe Back, Clement Bera, Alexandre Bergel, Torsten Bergmann, Vincent Blondeau, Noury Bouraqadi, Santiago Bragagnolo, Johan Brichau, Sven Van Caekenberghe, Damien Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Andrei Chis, Ben Coman, Bernardo Contreras, Tommaso Dal Sasso, Jan Van De Sandt, Christophe Demarey, Sean DeNigris, Marcus Denker, Martin Dias, Stephane Ducasse, Stephan Eggermont, Luc Fabresse, Johan Fabry, Hilaire Fernandes, Jerome Garcia, Tudor Girba, Thierry Goubier, Jigyasa Grover, Kris Gybels, Norbert Hartl, Dale Henrichs, Pablo Herrero, Nicolai Hess, Pavel Krivanek, Juraj Kubelka, Jan Kurs, Laurent Laffont, Jannik Laval, Kevin Lanvin, Max Leske, David Lewis, Diego Lont, Esteban Lorenzano, Tim Mackinnon, Attila Magyar, Esteban Maringolo, Stefan Marr, Max Mattone, Martin Mc Clure, Eliot Miranda, Alain Plantec, Guillermo Polito, Damien Pollet, Stefan Reichhart, Mark Rizun, Udo Schneider, Ignacio Sniechowski, Henrik Sperre Johansen, Igor Stasenko, Aliaksei Syrel, Ciprian Teodorov, Camille Teruel, Sebastian Tleye, Yuriy Tymchuk, Peter Uhnak, Andres Valloud, Sven Van Caekenberghe, Thomas Vincent, Jan Vrany, Martin Walk, Richard Wettel, Dmitri Zagidulin And all those who contributed indirectly, by reporting bugs, participating in discussion threads, providing feedback... Pharo 4.0 is another big step. And, the best is yet to come. Enjoy! The Pharo Team

18 24