Status of Alien FFI
Locked
123
123
 
|
2009/9/20 Schwab,Wilhelm K <[hidden email]>:
> Sig, > > The term "bus factor" arose from legitimate concerns to be sure, but let's not start predicting Pharo's downfall just yet. At the rate things are progressing, it will become a formidable system. With a sound foundation, innovation will be possible without sweeping change to the system itself. If at some point it falls into the wrong hands, one could always branch off from a stable release and be happy for a very long time. I do not agree. No matter how well , sound, formiddable the system are. There are always a chance that you miss something, and someone will find something better. The risks i outlined in previous post is not related to the quality of software, these risks are lying in social plane, rather than technical. If you need a stable, countinuously progressing system, first thing you need is a stable community with clear vision what goals are. But when community grows exponentially, and if it happens that at some point you got a weak leadership, wrong things start happening. Just because the probability of it is higher than before :) > > Who is asking for backward-compatibility? Is it the Squeak community, or Pharo users? > Ask the same question after 5-10 years :) > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko > Sent: Sunday, September 20, 2009 1:44 PM > To: [hidden email] > Subject: Re: [Pharo-project] Status of Alien FFI > > 2009/9/20 Marcus Denker <[hidden email]>: >> >> On 20.09.2009, at 13:49, Stéphane Ducasse wrote: >> >>> They probably moved while we got stuck. >> >> It's like with money: there is an "inflation" of constant progression. >> Everthing gets better slowly but constantly. >> Over 10 years, this results in quite some progress. >> >> Especially as you get the effect of "compound interest": By making >> something a little bit better, the next step of making it again a >> little bit better gets a little bit easier. >> >> As with compound interest, the effect is non-linear and completely >> against human intuition. >> >>> This is all the story behind pharo: moving again. >> >> What one needs to ask is always: How great could a system be over time >> if one would just do the next trivial, tiny, small step? And that over >> 10 years? With Squeak, this was impossible. Every small improvement >> was directly criticised as beeing "not good enough" and thus not >> worthwile for Squeak. With that attitude you go nowhere. As was proven >> in 10 years with Squeak. >> >> Of course, you should not *just* do tiny improvements. But it's like >> investing: there >> might be the chance to buy some pre-ipo stock cheap in the future. >> Does that mean >> that I put the money under the bed for no interest, or do I invest it >> for some tiny percentage e.g in a money-market account the meantime? >> With Squeak, the community decided that doing nothing was the right >> thing. >> >> Marcus >> > > (wearing a devil's advocate hat) > > I fear that Pharo, at some day could repeat the fate of Squeak. > At version 2.0, 3.0 or whatever, you will lose interest (for whatever > reason) in supporting it and > step down from leading the project, as well as other current developers. > The people who will lead it next will have a bit less authority to change anything, and there already will be a certain 'backwards compatibility' pressure from community. > Also, much more people will not feel so confident in new leaders comparing to you, simply because they could not know much about them, or because they are not founders etc etc. > In this situation, if someone will raise a hand, and say - lets throw out X, and replace it with Y, because its better, will have a high chances to be burned out. > > (wearing off a devil's advocate hat) > > I hope that there are a good strategy behind activities in Pharo, to not let the progress slowdown. > And if not, then it is right time to think about it. > >> >> -- >> Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science >> Department (DCC) - University of Chile >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Sig,
If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko Sent: Sunday, September 20, 2009 2:32 PM To: [hidden email] Subject: Re: [Pharo-project] Status of Alien FFI 2009/9/20 Schwab,Wilhelm K <[hidden email]>: > Sig, > > The term "bus factor" arose from legitimate concerns to be sure, but let's not start predicting Pharo's downfall just yet. At the rate things are progressing, it will become a formidable system. With a sound foundation, innovation will be possible without sweeping change to the system itself. If at some point it falls into the wrong hands, one could always branch off from a stable release and be happy for a very long time. I do not agree. No matter how well , sound, formiddable the system are. There are always a chance that you miss something, and someone will find something better. The risks i outlined in previous post is not related to the quality of software, these risks are lying in social plane, rather than technical. If you need a stable, countinuously progressing system, first thing you need is a stable community with clear vision what goals are. But when community grows exponentially, and if it happens that at some point you got a weak leadership, wrong things start happening. Just because the probability of it is higher than before :) > > Who is asking for backward-compatibility? Is it the Squeak community, or Pharo users? > Ask the same question after 5-10 years :) > Bill > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Igor > Stasenko > Sent: Sunday, September 20, 2009 1:44 PM > To: [hidden email] > Subject: Re: [Pharo-project] Status of Alien FFI > > 2009/9/20 Marcus Denker <[hidden email]>: >> >> On 20.09.2009, at 13:49, Stéphane Ducasse wrote: >> >>> They probably moved while we got stuck. >> >> It's like with money: there is an "inflation" of constant progression. >> Everthing gets better slowly but constantly. >> Over 10 years, this results in quite some progress. >> >> Especially as you get the effect of "compound interest": By making >> something a little bit better, the next step of making it again a >> little bit better gets a little bit easier. >> >> As with compound interest, the effect is non-linear and completely >> against human intuition. >> >>> This is all the story behind pharo: moving again. >> >> What one needs to ask is always: How great could a system be over >> time if one would just do the next trivial, tiny, small step? And >> that over 10 years? With Squeak, this was impossible. Every small >> improvement was directly criticised as beeing "not good enough" and >> thus not worthwile for Squeak. With that attitude you go nowhere. As >> was proven in 10 years with Squeak. >> >> Of course, you should not *just* do tiny improvements. But it's like >> investing: there >> might be the chance to buy some pre-ipo stock cheap in the future. >> Does that mean >> that I put the money under the bed for no interest, or do I invest it >> for some tiny percentage e.g in a money-market account the meantime? >> With Squeak, the community decided that doing nothing was the right >> thing. >> >> Marcus >> > > (wearing a devil's advocate hat) > > I fear that Pharo, at some day could repeat the fate of Squeak. > At version 2.0, 3.0 or whatever, you will lose interest (for whatever > reason) in supporting it and > step down from leading the project, as well as other current developers. > The people who will lead it next will have a bit less authority to change anything, and there already will be a certain 'backwards compatibility' pressure from community. > Also, much more people will not feel so confident in new leaders comparing to you, simply because they could not know much about them, or because they are not founders etc etc. > In this situation, if someone will raise a hand, and say - lets throw out X, and replace it with Y, because its better, will have a high chances to be burned out. > > (wearing off a devil's advocate hat) > > I hope that there are a good strategy behind activities in Pharo, to not let the progress slowdown. > And if not, then it is right time to think about it. > >> >> -- >> Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science >> Department (DCC) - University of Chile >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Schwab,Wilhelm K wrote:
> Sig, > > If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. > > Bill > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... Lawson _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Good luck. For my time and money, fool me once, shame on you, ...
Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Lawson English Sent: Sunday, September 20, 2009 7:13 PM To: [hidden email] Subject: Re: [Pharo-project] Status of Alien FFI Schwab,Wilhelm K wrote: > Sig, > > If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. > > Bill > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... Lawson _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Not meant as a promotion of C# 4, just an observation about MS marketing
power and R&D resources... The C# 4.0 IDE gives you scripting language prototyping capabilities roughly equivalent to Python's, at least according to the MS promo videos. Lawson Schwab,Wilhelm K wrote: > Good luck. For my time and money, fool me once, shame on you, ... > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Lawson English > Sent: Sunday, September 20, 2009 7:13 PM > To: [hidden email] > Subject: Re: [Pharo-project] Status of Alien FFI > > Schwab,Wilhelm K wrote: > >> Sig, >> >> If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. >> >> Bill >> >> >> > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... > > > Lawson > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
To add some OT and concerns about Lua & really cool stuff, see this video
http://vimeo.com/5254161 it looks like right now we (smalltalkers and 3D game-devs, who are certaintly ones who are on a bleeding edge of technology) are living in different dimensions, and both of us know little about each other.. what i find really frustrating. The guy who narrating the video, came to conclusion, that its cool to be able to simply copy the code snippet & run it on different host/project without recompiling C++ stuff, also mentioned that operating on entity level (by scripting particular object(s)) makes life much easier, especially when project complexity grows and grows bigger.. I just wonder , if Lua is so good for him, what would he say, when discover the smalltalk, and especially its environment, which inherently allows to work with objects in real time without edit-recompile-run cycle. :) 2009/9/21 Schwab,Wilhelm K <[hidden email]>: > Good luck. For my time and money, fool me once, shame on you, ... > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Lawson English > Sent: Sunday, September 20, 2009 7:13 PM > To: [hidden email] > Subject: Re: [Pharo-project] Status of Alien FFI > > Schwab,Wilhelm K wrote: >> Sig, >> >> If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. >> >> Bill >> >> > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... > > > Lawson > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Ken Treis
Hi Ken, sorry for the delayed reply. (i was away in summer school)
What i did , in my OpenGl binding that uses Alien is to reify the data types. For example, i created the class GLEnnum ( subclass of Alien). You have to re-implement the method #dataSize, so you can just do e := GLEnum false. GLEnum>>false | f | f := self new. f value: 0. ^ f GLEnum>>#dataSize ^ self unsignedLongSize Alien>>#unsignedLongSize ^ 4 Johan is going to add better abstractions to import definitions to Alien, i did it by "hand" (which didn't take much though). Saludos, Fernando Il giorno Sep 16, 2009, alle ore 8:37 PM, Ken Treis ha scritto: > * I'm creating a partial Alien library for GemStone so that I can > use the CairoGraphics package in both Pharo and GLASS. But on > x86-64, there there's a size difference between a pointer/long and > an integer. It'd be nice to have some more explicit APIs on Alien, > so I could say "Alien newCInteger" or "Alien newCLong" and have the > platform return me the proper size Alien. Even without the platform > size differences, it seems awkward to use "Alien newC: 4" everywhere > I want an integer, "Alien newC: 8" where I want a double, etc. > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by LawsonEnglish
I can only speak for myself here, but if Python were enough, I'd have switched already. So either we are to believe that Pharo will grow too big for its own good, or M$ will glossy-ad us out of existence. Let's just build what we want and let the other half do their own thing.
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Lawson English Sent: Sunday, September 20, 2009 9:28 PM To: [hidden email] Subject: Re: [Pharo-project] Status of Alien FFI Not meant as a promotion of C# 4, just an observation about MS marketing power and R&D resources... The C# 4.0 IDE gives you scripting language prototyping capabilities roughly equivalent to Python's, at least according to the MS promo videos. Lawson Schwab,Wilhelm K wrote: > Good luck. For my time and money, fool me once, shame on you, ... > > Bill > > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of > Lawson English > Sent: Sunday, September 20, 2009 7:13 PM > To: [hidden email] > Subject: Re: [Pharo-project] Status of Alien FFI > > Schwab,Wilhelm K wrote: > >> Sig, >> >> If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. >> >> Bill >> >> >> > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... > > > Lawson > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
I hope I'll remember to watch it later, but this type of thing has been going on for a long time. I remember a friend of mine getting excited about a thing called Actor. There was this weird thing called Smalltalk, and these guys (Whitewater Group??) came along and "fixed" it by giving it C syntax. Not meaning to bash my friend; just pointing out how long people have been trying to take part of Smalltalk without really understanding the bulk of it.
To be fair, look no further than Croquet for some blame here. They insisted on making an immersive 3D system rather than factoring it to provide whatever level the user might want. Maybe later we can start up a group to pull their retained mode framework into Pharo to serve simulation and gaming projects. Let's leave Tweak behind though. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko Sent: Sunday, September 20, 2009 9:30 PM To: [hidden email] Subject: Re: [Pharo-project] Status of Alien FFI To add some OT and concerns about Lua & really cool stuff, see this video http://vimeo.com/5254161 it looks like right now we (smalltalkers and 3D game-devs, who are certaintly ones who are on a bleeding edge of technology) are living in different dimensions, and both of us know little about each other.. what i find really frustrating. The guy who narrating the video, came to conclusion, that its cool to be able to simply copy the code snippet & run it on different host/project without recompiling C++ stuff, also mentioned that operating on entity level (by scripting particular object(s)) makes life much easier, especially when project complexity grows and grows bigger.. I just wonder , if Lua is so good for him, what would he say, when discover the smalltalk, and especially its environment, which inherently allows to work with objects in real time without edit-recompile-run cycle. :) 2009/9/21 Schwab,Wilhelm K <[hidden email]>: > Good luck. For my time and money, fool me once, shame on you, ... > > Bill > > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of > Lawson English > Sent: Sunday, September 20, 2009 7:13 PM > To: [hidden email] > Subject: Re: [Pharo-project] Status of Alien FFI > > Schwab,Wilhelm K wrote: >> Sig, >> >> If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. >> >> Bill >> >> > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... > > > Lawson > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Fernando olivero
I hit a similar problem with ODBC on 64 bit systems. One caution though: we can't completely lose control of the size when fixing this. One might need to read something written by a 32 bit system on a 64 bit one. Just as with int and DWORD, there needs to be a way to ask for the proper size for the platform or for a specific width. I once saw a system (then thinking 16/32 bit) where they had the platform and fixed types backwards, but that's another story ~:(
Bill Saludos, Fernando Il giorno Sep 16, 2009, alle ore 8:37 PM, Ken Treis ha scritto: > * I'm creating a partial Alien library for GemStone so that I can use > the CairoGraphics package in both Pharo and GLASS. But on x86-64, > there there's a size difference between a pointer/long and an integer. > It'd be nice to have some more explicit APIs on Alien, so I could say > "Alien newCInteger" or "Alien newCLong" and have the platform return > me the proper size Alien. Even without the platform size differences, > it seems awkward to use "Alien newC: 4" everywhere I want an integer, > "Alien newC: 8" where I want a double, etc. > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Ken Treis
Eliot, Johan, Fernando, et. al.: On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote: Hi Ken,
I also added Alien>>signedIntAt:/put: and unsignedIntAt:/put:. Right now these assume you're on an IA32 architecture (heck, that's the name of the plugin). But at least they hide that detail from the CairoGraphics package, which can simply use `Alien sizeofInt` in offset calculations and `Alien sizeofPointer` when data structures don't align nicely on 8-byte boundaries. Other changes in this version: * Class-side convenience callout helpers on AlienLibrary (e.g. int:with:, void:withArguments:, etc). These defer their actual behavior to primitives on the singleton instance, but provide for (IMHO) cleaner invocation from other objects. * Flush the list of loaded libraries at image startup, like the original Alien package did, instead of doing it at image shutdown as later versions do. This lets you save the image without dropping all of your libraries and invalidating external references. * A couple of accessors on AlienWeakTable that let you find a registered object by tag (analogous to Dictionary>>keyAtValue:), remove by tag, and return a strong reference to everything that the table currently holds weakly. The Cairo package uses these when handles are explicitly released and when flushing handles at image startup. I'm lobbying for inclusion of all of these in the trunk, but I'll be glad to defer to the better judgement of the package maintainers if my code is determined to be wrong/misguided. At this point this all works for me, and works well enough that I can load CairoGraphics and my "alien lite" in GemStone, and the various pointers, data offsets, etc. are right for Linux/x86_64. [1] I know there were some accessors for a few types already, but it seemed odd to have implementors for both signedLongSize and unsignedLongSize since the size doesn't depend on the sign-edness. I liked the C-like use of sizeofLong, sizeofPointer, etc but am willing to defer to somebody else's judgement on these method names. -- Ken Treis Miriam Technologies, Inc.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I'll note the most modern squeak VM's return wordSize, this might be
helpful somewhere. wordSize "Answer the size (in bytes) of an object pointer." "Smalltalk wordSize" ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4] On 2009-09-22, at 4:16 PM, Ken Treis wrote: > Eliot, Johan, Fernando, et. al.: > > On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote: > >> Hi Ken, >> >> On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis <[hidden email]> >> wrote: >> Perhaps there would need to be new primitives for the basic size of >> each relevant C type? I'm anxious to hear what Eliot might have to >> say about this since he's got about 2000x more experience with this >> than I do. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, Sep 22, 2009 at 04:47:56PM -0700, John M McIntosh wrote:
> > On 2009-09-22, at 4:16 PM, Ken Treis wrote: > > > Eliot, Johan, Fernando, et. al.: > > > > On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote: > > > >> Hi Ken, > >> > >> On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis <[hidden email]> > >> wrote: > >> Perhaps there would need to be new primitives for the basic size of > >> each relevant C type? I'm anxious to hear what Eliot might have to > >> say about this since he's got about 2000x more experience with this > >> than I do. > > I'll note the most modern squeak VM's return wordSize, this might be > helpful somewhere. > > wordSize > "Answer the size (in bytes) of an object pointer." > "Smalltalk wordSize" > > ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4] Actually, this is just the size of an object "pointer" in the object memory (i.e. BytesPerWord in ObjectMemory), which is independent of the size of a C pointer. So you would need new primitives to get at the underlying machine data types. The implementations are trivial if you are writing a plugin anyway, for example see #primitiveSizeOfPointer and #primitiveSizeOfInt in OSProcessPlugin. The "pointer" terminology referring to words the object memory is needlessly confusing, I guess we should clean that up one of these days. Dave _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Please David :)
cleaning cleaning improving....letting people grow their understanding and create new things.... > The "pointer" terminology referring to words the object memory is > needlessly > confusing, I guess we should clean that up one of these days. > > Dave > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |