- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] class variable slots?

by stepharo

Le 26/11/14 21:10, Marcus Denker a Ã©crit : > >> On 26 Nov 2014, at 19:36, Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Tudor, >> >> On Wed, Nov 26, 2014 at 6:02 AM, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >> As far as I see, the class variables are not slots. Is that correct? >> >> >> That's right. They're associations in class pools, and are visible >> in the instance-side and class-side methods of the class and all its >> subclasses. See Class>>bindingOf: and Class's inst var classPool. >> Shared pools are similar. A shared pool stores its variables in its >> class pool, but other classes can have its class vars in scope by >> including the shared pool in its pool dictionaries. >> >> If not, how do I get the slots? >> >> >> Well, just for clarity (at least I hope it'll bring clarity). One >> can access the variables via >> >> MyClass classPool associations >> >> Note that these are entirely different from class instance variables, >> which are inst var slots in the class object. These hold things like >> the class's superclass, its method dictionary, etc. But one can add >> inst vars to one's own class. There are many examples of this. >> Since these slots are per-class every class gets its own copy of the >> slot, and because these are inst vars, they are only in scope in >> class-side methods of the defining class and subclasses. >> > > One we did for Pharo4 is to use the Associations of Globals to model > these variables as meta-objects (in the same spirit as the Slot objects). > > Thos means that > -> there is an Api to get them > -> they have an API to read /write > > This is just âsugarâ on what the associations did already: > > global := SmalltalkImage classVariableNamed: #CompilerClass. > global read. > global class > ==> ClassVariable but I do not get why a class variable is accessed as a global. To me it looks plain wrong. A class variable is like a shared variable between classes. In Clos it was the same as an instance variable but with a class scope. So could not we make that nicer. I really find terrible and an attack against modularity to have them managed that way. Why the compiler instead of going to Smalltalk the global namespace cannot ask the class that declares it? Even if we would have modules I do not see why a class var should be a module global because it is not what it is. I think that the original implementation is not aligned with the semantics. > Then, I added that the Compiler actually delegates code generation for > read and write > to these meta-objects, meaning you can subclass them and add special > kinds of Globals > with special semantics (just like Slot Subclasses). This could be used > for e.g.active globals > that announce when changed. > > But the real use-case for this is putting meta-links on these globals. > > e.g. add a class TT with class var T and a method that reads it. > > > |link | > link := MetaLink new > metaObject: Halt; > selector: #now. > > (TT classVariableNamed: #T) link: link. > > TT new readT > -> halt. > > This means that we can out break-points on class variables (as opposed > to a single read or write). > > This all needs a bit more work to be really usableâ¦ > > Marcus > > > >

Nov. 27, 2014

Re: [Pharo-dev] [Vm-dev] Re: NativeBoost

by Eliot Miranda

Hi Esteban, On Tue, Nov 25, 2014 at 11:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 25 Nov 2014, at 20:27, Markus Fritsche <mfritsche(a)reauktion.de> wrote: > > > > On Tue, Nov 25, 2014 at 5:06 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Please enlighten me as well. I also do not yet understand the idea of >> this unification layer. >> > > "Unification layer" is just a name. IMO Ronie is doing something much > more useful. He is architecting the marshalling layer of the FFI so that > it can > - be portable > - work in both the Cog JIT and the Interpreter > This is effectively an abstract instruction set for executing low-level > machine intsructions. It can be used for FFI call-out marshalling, but it > can also be used for low-level code generation, and we are using it in > Sista. COnsequently Ronie's "Low code" as it is properly called can be an > integral component to both a high-quality FFI and a fast VM. > > For me this is a useful substrate for an FFI that can be high quality. > But note that it is only one component. The other components are > - an image-level ABI compiler whose job it is to generate the correct > marshalling code for different platforms. The FFI for processors such as > IA64/x86-64 is complex, and a compiler is the only performant way to > generate correct marshalling code > - callback machinery. I have already designed and implemented this in the > context of Alien. The architecture is portable; it can function correctly > on x86-64 and ARM, not just x86. > > >> So far we have >> 1. FFI -> not maintained very well, no callbacks >> > > This is simply false. The FFI was in active use at Qwaq where Cog was > first implemented. I have continued to maintain and enhance it, > reimplementing it so that it is a pure Smalltalk plugin with no assembler > support code, so that it is reentrant. Recently Doug McPherson has > implemented the ARM version alongside my original x86 version. > > > yep, Iâm aware and I was trying to have time to bring those changes into > Pharo. Hopefully soon. > > > >> 2. Alien -> should provide the callbacks, hard to find a predefined >> package/VM combination >> > > Every Cog VM supports Alien callbacks. The Alien package Alien-eem.24 at > http://www.squeaksource.com/Alien "jsut works", at least in Squeak. Try > it. > > > > it works. > We have ConfigurationOfOldAlien that loads all required (Is a bad name I > choose because there was your sources and a fork from Luc and there were > not in sync, so I took your sources and made a Configuration for them :P) > > > >> 3. NativeBoost was supposed to be the better one, was based on AsmJit >> and replace 1. and 2. >> > > I disagree. NativeBoost has not been designed with portability in mind, > nor has it been designed with interpretive VMs in mind. Further Igor made > no attempt to work with me in providing the support he needs from Cog to > integrate NativeBoost when I visited Rmod early this year. > > > According to my knowledge it was the goal to continue with NB, integrate >> it (which is done) >> and move it forward as the single solution for external calls and >> callbacks. >> >> So why do we need another layer (and mixed approach with still old FFI) >> instead of working >> on bringing NB to the other platforms as well and work on a good >> NativeBoost. Wasn't there >> already work for AsmJit for ARM? >> > > We have a functional FFI at the moment, FFI + Alien for callbacks. This > is in industrial use, both at Terf (nee Qwaq) and Cadence. We have > NativeBoost that does not work on ARM. We have Ronie's work on low code > that fits both with a well-architected FFI and with Sista. > > I am frustrated that there is no coherence in our work here. I have a > clear understanding of what architecture can work, a clear vision, and yet > other than Ronie, all I see is FUD ("Alien doesn't work", "FFI doesn't > work", "Alien callbacks don't work"; all false). I wish this wasn't the > case. I do not have time right now to work on all of Spur, Spur 64, Sista > and find time to architect the FFI. But I know how this stuff works (I've > implemented what works now) and as the leads VM architect isn't it right > that the community try and work with me rather than without me? > > > Honestly, Iâm quite frustrated too. > And I cannot agree with you more. > thanks, Esteban. I find this extremely reassuring. > But hopefully we will start to work on this problem and remove all > discordances soon (I know in all other VM aspects we already did it and now > we work aligned, so we can do this for FFI tooâ¦ in fact last month I wanted > to work on it but then other work became more urgent). > > Esteban > > > >> Thx >> T. >> >> > Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr >> > Von: "Markus Fritsche" <mfritsche(a)reauktion.de> >> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> > Betreff: Re: [Pharo-dev] NativeBoost >> > >> > On 2014-11-24 23:34, Esteban Lorenzano wrote: >> > >> > > now, since the most common use of NB is for FFI, and NB is not present >> > > in all platforms, we are working (Ronie, in this case) in a âunified >> > > FFIâ, which will provide a common abstraction layer for several FFI >> > > frameworks (NB, OldFFI, Alienâ¦). With that, we can choose which one >> > > of the frameworks we use depending on the situation (but ideally, we >> > > will maintain just one, the one that fits better in Pharo). >> > >> > I feel that providing a common abstraction layer on top of the various >> > approaches to interface to C/ C++ libraries won't be useful and should >> > be considered a waste of resources. From what I understood from the >> > documentation, NativeBoost seems to be the most complete interface >> > technology yet. I would rather (as in: If I was capable) try to get >> > NativeBoost into Squeak and add the functionality missing that still >> > justifies the existence of FFI and Alien than creating an abstraction >> > layer that can't cope with the differences in the tools (which was the >> > reason for their first creation despite the available ones). >> > >> > I tried to play around with FFI and creating plugins in Squeak and >> > failed (I didn't try very hard though). NativeBoost was the first thing >> > I was able to wrap a DLL myself and understand how to do it. The only >> > thing that I wasn't able to wrap my mind around was finalization, but >> > that is also due to the fact that I couldn't find understandable (read: >> > understandable to me) documentation about the underlying concept in >> > Pharo. >> > >> > (OT: Finalization and concurrency probably is more about the concept >> > rather than the implementation in Pharo?) >> > >> > This is a piece of opinion. We all know, that unfortunately, one doesn't >> > have to have knowledge to have an opinion, so if my opinion is wrong due >> > to lack of knowledge, please ignore it. >> > >> > Best regards, >> > Markus >> > >> > >> > >> >> > > > -- > best, > Eliot > > > > -- best, Eliot

Nov. 26, 2014

Re: [Pharo-dev] [Vm-dev] [commit][3152] Make sure to compile the SmallFloat64 primitives.

by Eliot Miranda

Hi Ben, On Wed, Nov 26, 2014 at 2:27 PM, Ben Coman <btc(a)openinworld.com> wrote: > > commits(a)squeakvm.org wrote: > >> Revision: 3152 >> Author: eliot >> Date: 2014-11-26 11:57:25 -0800 (Wed, 26 Nov 2014) >> Log Message: >> ----------- >> Make sure to compile the SmallFloat64 primitives. >> >> boxedFloat comment: 'My instances hold 64-bit Floats in heap >> objects. This is the only representation on 32-bit systems. But on 64-bit >> systems SmallFloat64 holds a subset of the full 64-bit double-precision >> range in immediate objects.' >> stamp: 'eem 11/25/2014 7:54'. >> smallFloat comment: 'My instances represent 64-bit Floats whose >> exponent fits in 8 bits as immediate objects. This representation is only >> available on 64-bit systems, not 32-bit systems.' >> >> > So are SmallFloats converted to BoxedFloats on the fly when an image is > moved from a 64-bit host to a 32-bit host ? > No; there is no automatic conversion between 32-bit and 64-bit images. 64-bit Spur images will only be runnable on 64-bit machines. There are scripts that convert 32-bit non-Spur images to 32-bit Spur images and from 32-bit Spur images to 64-bit Spur images, and it would be easy to add a script that converted from a 64-bit Spur image to a 32-bit Spur image. But none of these conversions will be provided "automatically" (e.g. as a side-effect of starting up an image), although they may be wrapped up in tools. Currently the conversion time from 32-bit non-Spur to 32-bit Spur on a fast laptop is 5 minutes, and IIRC conversion from 32-bit Spur to 64-bit Spur takes a couple of minutes. So I don't think one will ever want this to happen automatically. Further, I hope and expect that we're moving to/have already moved to a construction-oriented image build process where one will take a pre-prepared base image of the appropriate pointer width and run scripts to load packages into them. So I expect the main use of the Spur 32-bit to 64-bit bootstrap is in preparing base release images. btw, Does that comment need updating... didn't you go with SmallDouble, > BoxedDouble? > No. Bert suggested (IIRC) ImmediateFloat64 and BoxedFloat64 and I went with SmallFloat64 and BoxedFloat64 for two reasons. SmallFloat64 because I like the symmetry with SmallInteger, and because this name scheme gracefully admits SmallFloat32, BoxedFloat32 and BoxedFloat80 if ever there was the energy to add them. -- best, Eliot

Nov. 26, 2014

Re: [Pharo-dev] class variable slots?

by Marcus Denker

> On 26 Nov 2014, at 19:36, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Tudor, > > On Wed, Nov 26, 2014 at 6:02 AM, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > Hi, > > As far as I see, the class variables are not slots. Is that correct? > > That's right. They're associations in class pools, and are visible in the instance-side and class-side methods of the class and all its subclasses. See Class>>bindingOf: and Class's inst var classPool. Shared pools are similar. A shared pool stores its variables in its class pool, but other classes can have its class vars in scope by including the shared pool in its pool dictionaries. > > If not, how do I get the slots? > > Well, just for clarity (at least I hope it'll bring clarity). One can access the variables via > > MyClass classPool associations > > Note that these are entirely different from class instance variables, which are inst var slots in the class object. These hold things like the class's superclass, its method dictionary, etc. But one can add inst vars to one's own class. There are many examples of this. Since these slots are per-class every class gets its own copy of the slot, and because these are inst vars, they are only in scope in class-side methods of the defining class and subclasses. > One we did for Pharo4 is to use the Associations of Globals to model these variables as meta-objects (in the same spirit as the Slot objects). Thos means that -> there is an Api to get them -> they have an API to read /write This is just âsugarâ on what the associations did already: global := SmalltalkImage classVariableNamed: #CompilerClass. global read. global class ==> ClassVariable Then, I added that the Compiler actually delegates code generation for read and write to these meta-objects, meaning you can subclass them and add special kinds of Globals with special semantics (just like Slot Subclasses). This could be used for e.g.active globals that announce when changed. But the real use-case for this is putting meta-links on these globals. e.g. add a class TT with class var T and a method that reads it. |link | link := MetaLink new metaObject: Halt; selector: #now. (TT classVariableNamed: #T) link: link. TT new readT -> halt. This means that we can out break-points on class variables (as opposed to a single read or write). This all needs a bit more work to be really usableâ¦ Marcus

Nov. 26, 2014

Re: [Pharo-dev] class variable slots?

by Eliot Miranda

Hi Tudor, On Wed, Nov 26, 2014 at 6:02 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > As far as I see, the class variables are not slots. Is that correct? > That's right. They're associations in class pools, and are visible in the instance-side and class-side methods of the class and all its subclasses. See Class>>bindingOf: and Class's inst var classPool. Shared pools are similar. A shared pool stores its variables in its class pool, but other classes can have its class vars in scope by including the shared pool in its pool dictionaries. > If not, how do I get the slots? > Well, just for clarity (at least I hope it'll bring clarity). One can access the variables via MyClass classPool associations Note that these are entirely different from class instance variables, which are inst var slots in the class object. These hold things like the class's superclass, its method dictionary, etc. But one can add inst vars to one's own class. There are many examples of this. Since these slots are per-class every class gets its own copy of the slot, and because these are inst vars, they are only in scope in class-side methods of the defining class and subclasses. HTH > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- best, Eliot

Nov. 26, 2014

IdentitySet>>collect:

by Eliot Miranda

Hi All, IdentitySet>>collect: answers a Set, not an IdentitySet. Anyone else agree this is a serious bug? Anyone else disagree? WTF?? (IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] a Set(1.0 2 3) -- best, Eliot

Nov. 26, 2014

Re: [Pharo-dev] Stream instead of string concatenation

by Ben Coman

Yuriy Tymchuk wrote: > Hi everyone! > > There is a Lint rule that suggests to use stream instead of strings concatenation. What is the most common way, to create a string this way, because the only thing I can come up with is: > > String streamContents: [ :stream | > stream > nextPutAll: 'Hello'; > nextPut: $ ; > nextPutAll: 'Worldâ] > > But Iâm not sure if it is the preferred solution. > > Cheers > Uko > This is typical advise, but previous discussion found it to be not necessarily true. https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg08162.html Perhaps the rule should be ammended/deleted. cheers -ben

Nov. 26, 2014

Re: [Pharo-dev] Stream instead of string concatenation

by Max Leske

> On 26.11.2014, at 17:18, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi everyone! > > There is a Lint rule that suggests to use stream instead of strings concatenation. What is the most common way, to create a string this way, because the only thing I can come up with is: > > String streamContents: [ :stream | > stream > nextPutAll: 'Hello'; > nextPut: $ ; > nextPutAll: 'Worldâ] > > But Iâm not sure if it is the preferred solution. Yes, thatâs what I do. With one addition: The default size for such a stream is 100, so if I know that my collection is going to be significantly larger / smaller I initialize the collection directly: String new: 400 streamContents [: â¦. And for everyone who hasnât yet discovered it: #streamContents is implemented on SequenceableCollection! That means you can do the same thing with arrays, orderedCollections etc. Streaming is awesome :) > > Cheers > Uko

Nov. 26, 2014

Re: [Pharo-dev] Stream instead of string concatenation

by Luc Fabresse

Hi Uko, 2014-11-26 17:18 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi everyone! > > There is a Lint rule that suggests to use stream instead of strings > concatenation. What is the most common way, to create a string this way, > because the only thing I can come up with is: > > String streamContents: [ :stream | > stream > nextPutAll: 'Hello'; > nextPut: $ ; > nextPutAll: 'Worldâ] > > But Iâm not sure if it is the preferred solution. > Yes, I use this too. and I use << instead of #nextPutAll: Cheers, Luc > > Cheers > Uko >

Nov. 26, 2014

Stream instead of string concatenation

by Yuriy Tymchuk

Hi everyone! There is a Lint rule that suggests to use stream instead of strings concatenation. What is the most common way, to create a string this way, because the only thing I can come up with is: String streamContents: [ :stream | stream nextPutAll: 'Hello'; nextPut: $ ; nextPutAll: 'Worldâ] But Iâm not sure if it is the preferred solution. Cheers Uko

Nov. 26, 2014