July 2014 - Pharo-dev - lists.pharo.org

Again on #definesClass: and #includesClass:

by Yuriy Tymchuk

In environments we have two methods: #definesClass: and #includesClass:. They make sense for package environments, as one of them may include a class as it defines extension methods for it, but itâs not defining the class itself. Now #includesClass: is redefined in all environments, but #definesClass: is not redefined anywhere except for package environment. So for example ClassEnvironment says that it defines every class that itâs asked about. Should we redefine that method in each environment? I would say yes, but Iâm not familiar with RBâ¦Stuff philosophy. What do you think? Cheers. Uko

July 3, 2014

[Roassal3D] R3GridLayout, which one?

by Roberto Minelli

Hi, I was trying Roassal3D and I need the simplest (and only!) grid layout that places elements on the XY plane. Looking at both examples and class hierarchies it seems that the R3XYGridLayout should do, but as soon as you add an #height (I am expecting the height to go along the Z axis) to the R3CubeShape you got amazingly interesting results. I also tried adding #depth and #width, I cannot understand how it works. :S Hereâs the code =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | view elements | view := R3View new. view camera translateUp: 5. view camera rotateRight: 80. numEls := 5. elements := OrderedCollection new. (1 to: numEls) do: [ :id | | el cube | cube := R3CubeShape new. cube height: id. el := cube element. elements add: el. view add: el ]. (R3XYGridLayout new) gap: 0; on: elements. view addInteraction: R3MKControl. view open. view =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Any help? Thanks a lot, R

July 3, 2014

Re: [Pharo-dev] PillarHub

by Goubier Thierry

Le 03/07/2014 05:38, mikefilonov a Ã©crit : > Hi everyone, > > Thanks! I think Alexey will be really happy to read this thread when he is > back to university in a month :) Congratulations! > As for versioning yes we plan to implement it. I think it should be easy as > Monticello implement it so it should be possible to reuse. I need to see the > code though. > > Also Damien gave a great idea to add a configuration for a hub to sync it's > content to GitHub so cloud could be used for backup/versioning. I think it > is a perfect solution but I don't see yet how it can be implemented. Is any > one knows classes to talk to github? If it can go through Monticello, then you can use GitFileTree or FileTree + Git + OSProcess. Look into the GitFileTree code to see how you can clone from a github repository and do push / pull. If it's not Monticello, but pillar files saved to disk, the same code/approach can be used. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 3, 2014

Re: [Pharo-dev] busy monkey

by Marcus Denker

On 03 Jul 2014, at 09:06, Nicolai Hess <nicolaihess(a)web.de> wrote: > Do we have problems with issue validation? Yes, it aborts with a DNU. I added a bug tracker entry for it but I have not yet found the time to look at it. (this has to do with the MethodContext / Context cleanup jn combination with Fuel, I guess.) > There are some issues at fogbugz with stay status: > "Resolved (Monkey is Checking)". > > > nicolai

July 3, 2014

busy monkey

by Nicolai Hess

Do we have problems with issue validation? There are some issues at fogbugz with stay status: "Resolved (Monkey is Checking)". nicolai

July 3, 2014

Re: [Pharo-dev] issue with Nautilus?

by Nicolai Hess

Can you attach or send me the .st file you filed in. 2014-07-02 17:09 GMT+02:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: > Iâve opened this: > > https://pharo.fogbugz.com/f/cases/13456/Nautilus-showing-methods-that-are-n… > > quite strange. First time I see something like that > > > > > sebastian <https://about.me/sebastianconcept> > > o/ > > blog: http://sebastianconcept.com > LinkedIn: http://www.linkedin.com/in/sebastiansastre > github: https://github.com/sebastianconcept > > > > > >

July 3, 2014

Re: [Pharo-dev] Pharo running with spur (work in process)

by Tudor Girba

Fantastic. Thanks for all the effort to everyone involved! Doru On Wed, Jul 2, 2014 at 4:13 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Iâve been working on prepare Pharo to run with the new Spur VMâ¦ and > finally this week Guille and I sit together and make a huge advance :) > here a screenshot of pharo 4 running with spur: > > for more information, same image before migration, with a regular cogvm > gives this numbers: '1297023432 bytecodes/sec; 161029354 sends/secâ, so > that means that the tiny benchmarks run at 166% the speed of the old vmâ¦ > Of course this is just one benchmark, but Iâm very impressed :) > > Now, it is still not usable but Iâm confident I can put a jenkins job to > work very soon :) > > Esteban > > ps: before you start asking: Spur WILL NOT be available for Pharo3, it > will be part of Pharo4. > > > > -- www.tudorgirba.com "Every thing has its own flow"

July 3, 2014

New Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3029/. I've taken down the 3021 and 3024 VMs as their LargeIntegers code was badly broken. That's fixed now. The major changes are that Spur now correctly handles forwarding in primitives invoked from machine code, and that sends to Characters have the expected performance. CogVM binaries as per VMMaker.oscog-eem.797/r3029 Fix mixup of old & young spaces in primitiveVMParameter, and comment some new parameters. Fix return types for positive[64/32]BitValueOf:. positive32BitValueOf: must answer a usqInt, positive64BitValueOf: must answer a usqLong. Use positiveMachineIntegerValueOf: to decode arg in primitiveNewWithArg and ensure positiveMachineIntegerValueOf: is inlined there-in. Spur: Fix inline cache for Characters in Spur. Existing code failed all machine code sends to characters, creating PICs at those send sites which failed back to the interpreter. Implement forwarder following on primitive failure for all primitive calls from machine code. Allow the JIT to not compile primitiveDoNamedPrimitiveWithArgs to avoid any potential complications. Have spur's fetchClassOfNonImm: answer nilObj for forwarders to avoid assert fails. Fix assert fails in updateStateOfSpouseContextForFrame:WithSP: and elsewhere with forwarders. Add read barriers to primitiveSuspend and synchronousSignal:'s myList access, because the process list manipulation routines do no checking. Add assert checks for forwarders in the process list manipulation routines. Fix StackInterpreter>>actuallyFollowNecessaryForwardingInMethod:literalCount: so that it no longer corrupts the methodClassAssociation. Rewrite all the semaphore installing primitives to fail if the semaphore arg is neither a semaphore or nil instead of assuming if its not a semaphore it must be nil, so as to fail and retry when semaphores are forwarded (as they are when Semaphore is redefined). Implement isSemaphoreOop:/Obj: in the object memories to abstract away the code. Base Spur's on the class index of splObj: ClassSemaphore, avoiding the table lookup to derive the class. Make checkForEventsMayContextSwitch: treat all its semaphores consistently. These changes allow Cog Spur to redefine Process and/or Semaphore and not hang. Fix sign and overflow issues in instantiating larger objects and determining the size of large instances. Fix some freeChunk accesses that used fetchPointer:ofObject:. Make sure forwarders have accurate slot counts, bumping it to 1 if it was zero. Plugins: Fix LargeIntegersPlugin>>isNormalized: for forwarders, no longer assuming that if its arg isn't a SmallInteger it must be a large integer. Squash an assert fail in lengthOf:format: on forwarders by using numSlotsOfAny:. Fix the shift for divide issues in the LargeIntegersPlugin. Change the SmartSyntaxPluginCodeGenerator to generate code that ifdefs out the remapOop:in: rigmarole on Spur. Windows: Set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header of the Windows executables to allow e.g. Spur to allocate more than 2Gb. Slang: Rip out the UseRightShiftForDivide optimization. It gets unsigned division wrong, and C compilers can and will optimize this correctly themselves. -- best, Eliot

July 3, 2014

Re: [Pharo-dev] PillarHub

by mikefilonov

Hi everyone, Thanks! I think Alexey will be really happy to read this thread when he is back to university in a month :) As for versioning yes we plan to implement it. I think it should be easy as Monticello implement it so it should be possible to reuse. I need to see the code though. Also Damien gave a great idea to add a configuration for a hub to sync it's content to GitHub so cloud could be used for backup/versioning. I think it is a perfect solution but I don't see yet how it can be implemented. Is any one knows classes to talk to github? Thanks for a feedback guys! Any suggestions on future plans for PillarHub are welcomed. -- View this message in context: http://forum.world.st/PillarHub-tp4766012p4766256.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 3, 2014

Re: [Pharo-dev] Pharo running with spur (work in process)

by kilon alios

For me its 99 milliseconds with my iMac (Pharo 3) which is a 3.2 Intel Core i5 and 8GB 1600Mhz DDR3 Ram. Very impressive stuff. On Wed, Jul 2, 2014 at 10:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Wed, Jul 2, 2014 at 11:43 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> 0.00000000549181 seconds per message is just insanely low number . This >> is not even in the realm of nanoseconds. Is this number real ? Because I >> am very skeptical that one can get this kind of performance from a dynamic >> language even with a JIT VM. >> > > Here's a measurement on my 2.2GHz Mac Book Pro Core i7: > > | r | {[r := 34 benchFib] timeToRun. r} #(140 18454929) > > benchFib is nfib that adds one for each call, so the answer is the number > of calls necessary to compute the answer. > > benchFib ^self < 2 ifTrue: [1] ifFalse: [(self-1) benchFib + (self-2) > benchFib + 1] > > So that's 18 million calls in 140 milliseconds, or about 132 calls per > microsecond. That's indeed in the realm of nanoseconds, 13.2 nsecs per > call. > > > >> >> On Wed, Jul 2, 2014 at 9:08 PM, Camille Teruel <camille.teruel(a)gmail.com> >> wrote: >> >>> >>> A spur image :) awesome !! >>> Thanks Esteban & Guille! >>> I'll start adapting the new class builder to Spur next wednesday when I >>> come back from holidays. >>> >>> On 2 juil. 2014, at 16:13, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>> > Hi, >>> > >>> > Iâve been working on prepare Pharo to run with the new Spur VMâ¦ and >>> finally this week Guille and I sit together and make a huge advance :) >>> > here a screenshot of pharo 4 running with spur: >>> > <Screen Shot 2014-07-02 at 15.58.17.png> >>> > for more information, same image before migration, with a regular >>> cogvm gives this numbers: '1297023432 bytecodes/sec; 161029354 sends/secâ, >>> so that means that the tiny benchmarks run at 166% the speed of the old vmâ¦ >>> > Of course this is just one benchmark, but Iâm very impressed :) >>> > >>> > Now, it is still not usable but Iâm confident I can put a jenkins job >>> to work very soon :) >>> > >>> > Esteban >>> > >>> > ps: before you start asking: Spur WILL NOT be available for Pharo3, it >>> will be part of Pharo4. >>> > >>> > >>> > >>> >>> >>> >> > > > -- > best, > Eliot >

July 2, 2014