May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Questionn
by Marcus Denker May 1, 2012

May 1, 2012

On May 1, 2012, at 11:27 AM, Francisco Garau wrote: > Thanks Camilo - I've tried your image with the latest CogVM for Mac and it's usable. > > I understand this is work in progress, are you planning to change Object>>instVarAt: with a new primitive? or will that be handled on the image side? > Objects continue to have offset ivars... everything is mapped on those. So #instVarAt: just stays as it is. > Apart from the change in the class declaration, do you think that any of the existing code will have to be changed? > > What's the biggest advantage of having slots? -> Objects describing the layout of a class, simplifying a lot of thing -> Objects describing instance variables, available for reasoning about and e.g annotating. And of course, you can subclass Slot and do special ones... there are examples in the paper. Virtual slots, type check slots, Bit Slot, Property Slot.... http://hal.inria.fr/docs/00/64/17/16/PDF/Verw11b-OOSPLA11-FlexibleObjectLay… > (and will we also have slots for temp vars?) > > Object subclass: #Rectangle > layout: PointerLayout > slots: { > #origin => Slot. > #corner => Slot. > } > classSlots: {} > globals: '' > category: #'Graphics-Primitives' > > Display boundingBox instVarAt: #origin > instVarAt: can not take a symbol, just an integer. And it will return what it finds at the position. In the case of simple slots, there is a 1:1 mapping to iVars and therefore no change. See section 4.1 Primitive Slots "Primitive slots are metaobjects that simply bind an instance variable to a field index." Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 2.0] #20033
by Marcus Denker May 1, 2012

May 1, 2012

20033 ----- Issue 5703: Failing tests related to SystemNavigation http://code.google.com/p/pharo/issues/detail?id=5703 Issue 5694: Failing tests related to RPackage http://code.google.com/p/pharo/issues/detail?id=5694 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Pharo and the rest of the ecosystem
by StÃ©phane Ducasse May 1, 2012

May 1, 2012

Hi guys May I ask you why you talk about CUIS and Spoon/Pharo? If you want to work with these systems we do not have any problems. We are working on Pharo since 2008. We deliver regularly, we are concerned with making sure that you can do business with Pharo. And we will continue. WE want to invent and build OUR future. We are spending a lot of time on making the system better. - Fuel - Athens - OPAL - Ghost - Nautilus - Ring - NativeBoost - Zinc - HUGE amount of fixes - Working on a core - Writing a lot of documentation (yes guys) to name a few. We are pushing like hell and getting there. We spent time building our vision and step by step building it. We are getting there. :) Now I do not see the points related to spoon and cuis. I do not understand what is the point. If people wants to collaborate with us this is ok now we do not count on that for our future. You do not have to reply. Just think about what you want to build and your future. Everybody make choices and is free. Stef

12 16

[Pharo-project] Late binding class names
by Sean P. DeNigris May 1, 2012

May 1, 2012

How would I hook into the system, let's say during the execution of one particular method (and whatever methods it calls recursively), and substitute one Class for another, without effecting the rest of the system? For example: myMethod "Until I return, use MyOtherClass instead of MyClass, but only in this thread" MyClass doSomething. ThirdClass doSomethingElse. ThirdClass>>doSomethingElse "This use of MyClass will also be replaced with MyOtherClass" MyClass doAnotherThing. Thanks. Sean -- View this message in context: http://forum.world.st/Late-binding-class-names-tp4575026p4575026.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 5