November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Old ClassBuilder remove!

by Nicolas Cellier

(true pointersTo collect: #class as: Set) intersection: (false pointersTo collect: #class as: Set) et voila 2013/11/22 Stephan Eggermont <stephan(a)stack.nl> > Nicolas wrote: > >It has to be more simple than thatâ¦ > > Probably. I donât do this often enough. > > >Why not searching for allReferences to true and false, and gather the > class of referents? > > How is that going to give me the values of the instVars? > > >This would also remove the limitation of first 10 instancesâ¦ > > Taking a look at all instances just takes a bit longer... > > Iâm open to suggestions. > > Stephan > > > >

Nov. 22, 2013

How to use Opal for parsing peace of code?

by Juraj Kubelka

Hi! I am interested how to use Opal for parsing peace of code. I have supposed to use something like this: | root node1 node2 | root := OpalCompiler new source: 'Color blue yourself'; useFaultyForParsing: true; parse. root doSemanticAnalysis. node1 := root bestNodeFor: (2 to: 2). node2 := root bestNodeFor: (7 to: 7). But node1 is a RBMethodNode, and node2 is a RBVariableNode. Does it matter if source for OpalCompiler is peace of code or method source? Thank you, Jura

Nov. 22, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Chris Muller

> Just two examples: > - Morphic uses a dictionary to allow extensions to add attributes to the > base class. This is closed-world-based-assumption thinking because I have to > know in advance what parts will be extended by someone else. This should be > easily changeable with slots given that slots are manipulate-able at runtime > (ideally). Since I have several classes that inherit from a superclass that provides a property-dictionary, I'm interested to better understand what you mean by needing to know in advance what parts will be extended by someone else?

Nov. 22, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Chris Muller

How does this affect serialization / materialization engines like Fuel? On Thu, Nov 21, 2013 at 7:24 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: > > any links why newcomers like me should be impressed ? Whats the advantages ? > > > That's just cleaning. The old class builder was an incredibly complex piece > of code that is now replaced with the Slot class builder. > The later is based on slots and is much more understandable and thus much > easier to maintain. > It's been integrated some time ago thanks to Martin. > > Slots are the work of Toon and Camillo and enables a lot of useful features: > http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… > They are based on the reification of class layouts (variable,weak,fixed and > co) and instance variables (slots). > Slots are an abstraction added on top of low-level class "fields". > It means that one will be able to create a customized slot class that define > the logic to read and write a slot: > > Object subclass: #MyClass > slots: { x => MyFancySlot } > category: 'Playground' > > Then when a method read or writes x, the logic you defined in MyFancySlot is > executed. > All that still need to be absorbed by Opal so it's not available right now > but it will (Pharo 4)! > > > > > > On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Triple impressive! This is another sample of an apparently tiny change >> that actually has deep impact on the future of our beloved environment. >> >> Ladies and gentlemen, I know you are busy, but please take the time to >> acknowledge it :) >> >> Doru >> >> >> >> >> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> >> wrote: >>> >>> wow, impressive! >>> >>> >>> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>>> >>>> Hi, >>>> >>>> Yesterday Camille did the change to finally remove the old class >>>> builder! >>>> (just a removal + a small change to NativeBoost to use the new class >>>> builder to create anonymous classes). >>>> >>>> This means >>>> - 1000 Loc of completely un-understandable code removed. >>>> - we now 100% run on the new class builder from the Slot >>>> Project. >>>> >>>> Next on the list (not all for Pharo3): >>>> >>>> - remove PackageInfo >>>> - old Browser + CodeHolder hierarchy >>>> - PseudoClass&Co â> Ring >>>> - old AST+Compiler (this in Pharo4) >>>> >>>> We already did (all in Pharo3): >>>> -> remove URI >>>> -> deprecated Url for ZnUrl >>>> -> removed HTTPSocket facade >>>> -> MIMEType retired for ZnMimeType >>>> -> old Debugger is removed >>>> -> Class categories are replaced by Protocols >>>> >>>> I am quite sure that these cleanups will enable us to build a lot of >>>> very interesting things >>>> in the future. >>>> >>>> Marcus >>> >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > >

Nov. 22, 2013

Re: [Pharo-dev] Graphic System Arquitecture Question

by StÃ©phane Ducasse

On Nov 22, 2013, at 6:57 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hello, > > I want to know about the Pharo graphic system architecture, I whould like to know if there's some documentation explaining his inner works. > > For NBOpenGL and Roassal 3D in particular, I'm having some flickering, which I think is related to the way that the OpenGL framebuffer is transferred into a pharo window. > > In NBOpenGL, rendering is done in a offscreen FBO, whose content is transferred into main memory y blitted into a pharo window. The pharo window of course must be blitted or renderer into the screen, which means anothere transfer into the GPU. In other words, we are a GPU->CPU->GPU memory roundtrip. Yes and igor would love to have the time to avoid this and only use and share one memory > > The consequences of this are the lost of performance, the lost of double-buffering and which is more important, the lost v-sync. The lack of v-sync is seen in the way of tearing, which is more appreciated when moving on the X-axis in a 3d view, such as in the Roassal3D example in R3Example>>city. > > I have heard that in pharo 3, all of the graphics are being moving into Athens, a new graphics, for which I donr't know where's the documentation. There is a simple tutorial example. May be check on the Athens repo or on the mailing-list (I have to run now) > I believe that athens is a vector graphics API, exact API. the idea is to have different back end. One that is the default one (balloon), one with cairo and probably some others in the future. > which several backends as cairo, which also has an opengl backend. I would like to share that OpenGL context to avoid that round-trip if possible, or use a native window for the OpenGL stuff, but to that I need to know how pharo graphics are done. You should have a look at the VM code and the graphics primitive. VM guys will tell you where you can find the latest version of VMMaker for Pharo. > > Greetings, > Ronie Salgado

Nov. 22, 2013

Re: [Pharo-dev] is this ok?

by ClÃ©ment Bera

Well this had been here for a while. I discovered it because it was triggered :). But it is very rare that this is triggered. Now when I look into the latest Pharo 3, this halt is not present. So I guess Andrei fixed it when we switched to the new debugger. 2013/11/22 Esteban Lorenzano <estebanlm(a)gmail.com> > in the debugger: > > stepToSendOrReturn > "Simulate the execution of bytecodes until either sending a message or > returning a value to the receiver (that is, until switching contexts)." > > | context | > [ self willSend or: [ self willReturn or: [ self willStore ] ] ] > whileFalse: [ > context := self step. > context == self ifFalse: [ > self halt. "<========================= THIS" > "Caused by mustBeBoolean handling" > ^context ]] > > > so... the halt is ok there? > > cheers, > Esteban >

Nov. 22, 2013

Graphic System Arquitecture Question

by Ronie Salgado

Hello, I want to know about the Pharo graphic system architecture, I whould like to know if there's some documentation explaining his inner works. For NBOpenGL and Roassal 3D in particular, I'm having some flickering, which I think is related to the way that the OpenGL framebuffer is transferred into a pharo window. In NBOpenGL, rendering is done in a offscreen FBO, whose content is transferred into main memory y blitted into a pharo window. The pharo window of course must be blitted or renderer into the screen, which means anothere transfer into the GPU. In other words, we are a GPU->CPU->GPU memory roundtrip. The consequences of this are the lost of performance, the lost of double-buffering and which is more important, the lost v-sync. The lack of v-sync is seen in the way of tearing, which is more appreciated when moving on the X-axis in a 3d view, such as in the Roassal3D example in R3Example>>city. I have heard that in pharo 3, all of the graphics are being moving into Athens, a new graphics, for which I donr't know where's the documentation. I believe that athens is a vector graphics API, which several backends as cairo, which also has an opengl backend. I would like to share that OpenGL context to avoid that round-trip if possible, or use a native window for the OpenGL stuff, but to that I need to know how pharo graphics are done. Greetings, Ronie Salgado

Nov. 22, 2013

is this ok?

by Esteban Lorenzano

in the debugger: stepToSendOrReturn "Simulate the execution of bytecodes until either sending a message or returning a value to the receiver (that is, until switching contexts)." | context | [ self willSend or: [ self willReturn or: [ self willStore ] ] ] whileFalse: [ context := self step. context == self ifFalse: [ self halt. "<========================= THIS" "Caused by mustBeBoolean handling" ^context ]] so... the halt is ok there? cheers, Esteban

Nov. 22, 2013

Re: [Pharo-dev] "Should not happen" in Slot

by Camillo Bruni

Yes, that seems to be a nasty bug. It is currently under investigation ;) On 2013-11-22, at 16:53, Torsten Bergmann <astares(a)gmx.de> wrote: > We can mark methods with pragmas - but there is no way for classes. > > Adding a new instance variable "annotations" to ClassDescription > in Pharo 30#30590 leads to an error "Should not happen" (in Slots code). > > Any help appreciated... > > Thx > T. >

Nov. 22, 2013

"Should not happen" in Slot

by Torsten Bergmann

We can mark methods with pragmas - but there is no way for classes. Adding a new instance variable "annotations" to ClassDescription in Pharo 30#30590 leads to an error "Should not happen" (in Slots code). Any help appreciated... Thx T.

Nov. 22, 2013