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

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

by Guillermo Polito

I think we should use the PharoInbox only for issues of things that are part of the core. If not it will be easily polluted. What do you think? Guille El vie., 17 de abr. de 2015 a la(s) 1:54 p. m., Sean P. DeNigris < sean(a)clipperadams.com> escribiÃ³: > Thank you!!! Quick question. What is our procedure about contributing to > projects which we own but are not part of Core? Should we commit to the > inbox or directly to the project repo? At the moment, I'm thinking of > non-controversial things like fixing comment typos... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Rubric-and-Bloc-are-now-in-PharoExtras-tp4820182p4820… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 17, 2015

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

by Sean P. DeNigris

Thank you!!! Quick question. What is our procedure about contributing to projects which we own but are not part of Core? Should we commit to the inbox or directly to the project repo? At the moment, I'm thinking of non-controversial things like fixing comment typos... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Rubric-and-Bloc-are-now-in-PharoExtras-tp4820182p4820… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 17, 2015

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

by stepharo

I will be teaching at Lviv but esteban or marcus should be available. Le 16/4/15 23:02, phil(a)highoctane.be a Ã©crit : > > > stef > > what about next tuesday? > > phil > > Le 16 avr. 2015 22:44, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> a Ã©crit : > > yes phil tell us. > > Stef > > Le 16/4/15 12:11, phil(a)highoctane.be <mailto:phil@highoctane.be> a > Ã©crit : >> >> >> Le 16 avr. 2015 11:56, "Tudor Girba" <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> a Ã©crit : >> > >> > Great job! >> > >> > Thank you everyone for the contributions, support and trust. >> >> One more out of the door. >> That's great. >> >> Anyone interested in doing a podcast episode on this releasr? >> Chime in. >> >> Phil >> >> > >> > Cheers, >> > Doru >> > >> > >> > On Thu, Apr 16, 2015 at 11:29 AM, Esteban Lorenzano >> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> >> >> >> Please spread widely. >> >> Sorry for multiple posts. >> >> >> >> (this post can be see here: >> 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 >> >> >> >> >> > >> > >> > >> > -- >> > www.tudorgirba.com <http://www.tudorgirba.com> >> > >> > "Every thing has its own flow" >> >

April 17, 2015

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

by Tudor Girba

Thanks Alain! Doru On Fri, Apr 17, 2015 at 12:56 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: Fri, 17 Apr 2015 12:56:26 +0200 > Subject: Rubric and Bloc are now in PharoExtras > Hello all, > Please update your configurations. > Cheers > Alain > > > > -- www.tudorgirba.com "Every thing has its own flow"

April 17, 2015

Rubric and Bloc are now in PharoExtras

by Alain Plantec

Hello all, Please update your configurations. Cheers Alain

April 17, 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? 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