I wanted to experiment a plugin and need to register a couple of classes that some primitive will test/instantiate. The ugly way is to pollute specialObjectArray... But #recreateSpecialObjectsArray recommend using addGCRoot() Fine, I'd like to try.
What I'd like to do is register my couple of classes in a primRegister() primitive (once for all or at each image startup, or at each snapshot, whatever...) Then to later use the registered classes in primDoSomething().
I can see ObjectMemory>>addGCRoot: but unfortunately, absolutely no sender of it to serve as an example... I even don't know how to access the objectMemory from within a SmartSyntaxInterpreterPlugin ? I can only see a interpreterProxy and
Then how to retrieve my registered objects? they are store in the extraRoots at some index, but that index is not returned by addGCRoot:... Anyway, the index could change thanks to removeGCRoot:, so I'm stuck here... I must be missing something... Or maybe addGCRoot: is just here to prevent an Object to be garbage collected but does not really offer a registering service...
If you know about any documentation/example hanging around or have some clues I'll be happy that you share them !
Last note, I'm in a VMMaker oscog flavour...
Nicolas
addGCRoot() takes a pointer to some memory location, where root object will be stored.
sqInt * mem;
mem = malloc(4); *mem = someOop; addGCRoot(mem);
now, to read a reference to 'someObject' at any place you can just do
someOop = *mem.
often you may want to register multiple objects for use. you can , of course, use addGCRoot() per each of them, or, just use an array to store unlimited number of objects as roots (that way you don't risk overflowing extra roots table, as well as can manage that array at image side, and at cost of extra indirection).
If you want a working example you can look at NBExtraRootsRegistry implementation, which is part of NativeBoost, how i using it.
On 23 December 2012 21:34, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I wanted to experiment a plugin and need to register a couple of classes that some primitive will test/instantiate. The ugly way is to pollute specialObjectArray... But #recreateSpecialObjectsArray recommend using addGCRoot() Fine, I'd like to try.
What I'd like to do is register my couple of classes in a primRegister() primitive (once for all or at each image startup, or at each snapshot, whatever...) Then to later use the registered classes in primDoSomething().
I can see ObjectMemory>>addGCRoot: but unfortunately, absolutely no sender of it to serve as an example... I even don't know how to access the objectMemory from within a SmartSyntaxInterpreterPlugin ? I can only see a interpreterProxy and
Then how to retrieve my registered objects? they are store in the extraRoots at some index, but that index is not returned by addGCRoot:... Anyway, the index could change thanks to removeGCRoot:, so I'm stuck here... I must be missing something... Or maybe addGCRoot: is just here to prevent an Object to be garbage collected but does not really offer a registering service...
If you know about any documentation/example hanging around or have some clues I'll be happy that you share them !
Last note, I'm in a VMMaker oscog flavour...
Nicolas
Ah OK, thanks, I get it... Two questions remain:
1) how to access addGCroot: from within a SmartSyntaxInterpreterPlugin ? 2) when do you need to register (re-register)? - once at image startup ? - after each snapshot ?
I think I'll have a look at NativeBoost indeed...
Nicolas
2012/12/23 Igor Stasenko siguctua@gmail.com:
addGCRoot() takes a pointer to some memory location, where root object will be stored.
sqInt * mem;
mem = malloc(4); *mem = someOop; addGCRoot(mem);
now, to read a reference to 'someObject' at any place you can just do
someOop = *mem.
often you may want to register multiple objects for use. you can , of course, use addGCRoot() per each of them, or, just use an array to store unlimited number of objects as roots (that way you don't risk overflowing extra roots table, as well as can manage that array at image side, and at cost of extra indirection).
If you want a working example you can look at NBExtraRootsRegistry implementation, which is part of NativeBoost, how i using it.
On 23 December 2012 21:34, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I wanted to experiment a plugin and need to register a couple of classes that some primitive will test/instantiate. The ugly way is to pollute specialObjectArray... But #recreateSpecialObjectsArray recommend using addGCRoot() Fine, I'd like to try.
What I'd like to do is register my couple of classes in a primRegister() primitive (once for all or at each image startup, or at each snapshot, whatever...) Then to later use the registered classes in primDoSomething().
I can see ObjectMemory>>addGCRoot: but unfortunately, absolutely no sender of it to serve as an example... I even don't know how to access the objectMemory from within a SmartSyntaxInterpreterPlugin ? I can only see a interpreterProxy and
Then how to retrieve my registered objects? they are store in the extraRoots at some index, but that index is not returned by addGCRoot:... Anyway, the index could change thanks to removeGCRoot:, so I'm stuck here... I must be missing something... Or maybe addGCRoot: is just here to prevent an Object to be garbage collected but does not really offer a registering service...
If you know about any documentation/example hanging around or have some clues I'll be happy that you share them !
Last note, I'm in a VMMaker oscog flavour...
Nicolas
-- Best regards, Igor Stasenko.
On 23 December 2012 22:25, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah OK, thanks, I get it... Two questions remain:
- how to access addGCroot: from within a SmartSyntaxInterpreterPlugin ?
interpreterProxy addGCroot: ...
- when do you need to register (re-register)?
- once at image startup ?
yes,at image boot time. when session changes.
- after each snapshot ?
not here
I think I'll have a look at NativeBoost indeed...
Nicolas
2012/12/23 Igor Stasenko siguctua@gmail.com:
addGCRoot() takes a pointer to some memory location, where root object will be stored.
sqInt * mem;
mem = malloc(4); *mem = someOop; addGCRoot(mem);
now, to read a reference to 'someObject' at any place you can just do
someOop = *mem.
often you may want to register multiple objects for use. you can , of course, use addGCRoot() per each of them, or, just use an array to store unlimited number of objects as roots (that way you don't risk overflowing extra roots table, as well as can manage that array at image side, and at cost of extra indirection).
If you want a working example you can look at NBExtraRootsRegistry implementation, which is part of NativeBoost, how i using it.
On 23 December 2012 21:34, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I wanted to experiment a plugin and need to register a couple of classes that some primitive will test/instantiate. The ugly way is to pollute specialObjectArray... But #recreateSpecialObjectsArray recommend using addGCRoot() Fine, I'd like to try.
What I'd like to do is register my couple of classes in a primRegister() primitive (once for all or at each image startup, or at each snapshot, whatever...) Then to later use the registered classes in primDoSomething().
I can see ObjectMemory>>addGCRoot: but unfortunately, absolutely no sender of it to serve as an example... I even don't know how to access the objectMemory from within a SmartSyntaxInterpreterPlugin ? I can only see a interpreterProxy and
Then how to retrieve my registered objects? they are store in the extraRoots at some index, but that index is not returned by addGCRoot:... Anyway, the index could change thanks to removeGCRoot:, so I'm stuck here... I must be missing something... Or maybe addGCRoot: is just here to prevent an Object to be garbage collected but does not really offer a registering service...
If you know about any documentation/example hanging around or have some clues I'll be happy that you share them !
Last note, I'm in a VMMaker oscog flavour...
Nicolas
-- Best regards, Igor Stasenko.
2012/12/23 Igor Stasenko siguctua@gmail.com:
On 23 December 2012 22:25, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah OK, thanks, I get it... Two questions remain:
- how to access addGCroot: from within a SmartSyntaxInterpreterPlugin ?
interpreterProxy addGCroot: ...
Hmm, in NB you used a different strategy... First, you defined a NBInterpreterProxy to perform a simpleCall to addGCRoot() after registering this function in class method #proxyFunctionsData unless it is from #CogProxyFunctionsData (why two?) Then, no plugin calls addGCRoot: directly. Instead you defined a primAddGCRoot: in order to use it from within the image. That's a bit too much for a helpful simple example.
I fail to see how this easily transpose to a vanilla VMMaker and it's native InterpreterProxy. I think I'll have to hack InterpreterProxy to give access to addGCRoot: unless there is more magic I missed in the code generator...
Nicolas
- when do you need to register (re-register)?
- once at image startup ?
yes,at image boot time. when session changes.
- after each snapshot ?
not here
There is no stupid question ;) well more or less...
I think I'll have a look at NativeBoost indeed...
Nicolas
2012/12/23 Igor Stasenko siguctua@gmail.com:
addGCRoot() takes a pointer to some memory location, where root object will be stored.
sqInt * mem;
mem = malloc(4); *mem = someOop; addGCRoot(mem);
now, to read a reference to 'someObject' at any place you can just do
someOop = *mem.
often you may want to register multiple objects for use. you can , of course, use addGCRoot() per each of them, or, just use an array to store unlimited number of objects as roots (that way you don't risk overflowing extra roots table, as well as can manage that array at image side, and at cost of extra indirection).
If you want a working example you can look at NBExtraRootsRegistry implementation, which is part of NativeBoost, how i using it.
On 23 December 2012 21:34, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I wanted to experiment a plugin and need to register a couple of classes that some primitive will test/instantiate. The ugly way is to pollute specialObjectArray... But #recreateSpecialObjectsArray recommend using addGCRoot() Fine, I'd like to try.
What I'd like to do is register my couple of classes in a primRegister() primitive (once for all or at each image startup, or at each snapshot, whatever...) Then to later use the registered classes in primDoSomething().
I can see ObjectMemory>>addGCRoot: but unfortunately, absolutely no sender of it to serve as an example... I even don't know how to access the objectMemory from within a SmartSyntaxInterpreterPlugin ? I can only see a interpreterProxy and
Then how to retrieve my registered objects? they are store in the extraRoots at some index, but that index is not returned by addGCRoot:... Anyway, the index could change thanks to removeGCRoot:, so I'm stuck here... I must be missing something... Or maybe addGCRoot: is just here to prevent an Object to be garbage collected but does not really offer a registering service...
If you know about any documentation/example hanging around or have some clues I'll be happy that you share them !
Last note, I'm in a VMMaker oscog flavour...
Nicolas
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Mon, Dec 24, 2012 at 12:05:46AM +0100, Nicolas Cellier wrote:
2012/12/23 Igor Stasenko siguctua@gmail.com:
On 23 December 2012 22:25, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah OK, thanks, I get it... Two questions remain:
- how to access addGCroot: from within a SmartSyntaxInterpreterPlugin ?
interpreterProxy addGCroot: ...
Hmm, in NB you used a different strategy... First, you defined a NBInterpreterProxy to perform a simpleCall to addGCRoot() after registering this function in class method #proxyFunctionsData unless it is from #CogProxyFunctionsData (why two?) Then, no plugin calls addGCRoot: directly. Instead you defined a primAddGCRoot: in order to use it from within the image. That's a bit too much for a helpful simple example.
I fail to see how this easily transpose to a vanilla VMMaker and it's native InterpreterProxy. I think I'll have to hack InterpreterProxy to give access to addGCRoot: unless there is more magic I missed in the code generator...
It is already defined in the InterpreterProxy, so in principle 'interpreterProxy addGCroot: ... ' should work from a plugin. However, I do not see any actual examples of this being used in any plugins in my image. I have a hard time figuring out how to use something like this without a working example, so maybe someone can provide a pointer to a plugin that is currently using this mechanism?
Dave
On 24 December 2012 00:28, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Dec 24, 2012 at 12:05:46AM +0100, Nicolas Cellier wrote:
2012/12/23 Igor Stasenko siguctua@gmail.com:
On 23 December 2012 22:25, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah OK, thanks, I get it... Two questions remain:
- how to access addGCroot: from within a SmartSyntaxInterpreterPlugin ?
interpreterProxy addGCroot: ...
Hmm, in NB you used a different strategy... First, you defined a NBInterpreterProxy to perform a simpleCall to addGCRoot() after registering this function in class method #proxyFunctionsData unless it is from #CogProxyFunctionsData (why two?) Then, no plugin calls addGCRoot: directly. Instead you defined a primAddGCRoot: in order to use it from within the image. That's a bit too much for a helpful simple example.
I fail to see how this easily transpose to a vanilla VMMaker and it's native InterpreterProxy. I think I'll have to hack InterpreterProxy to give access to addGCRoot: unless there is more magic I missed in the code generator...
It is already defined in the InterpreterProxy, so in principle 'interpreterProxy addGCroot: ... ' should work from a plugin. However, I do not see any actual examples of this being used in any plugins in my image. I have a hard time figuring out how to use something like this without a working example, so maybe someone can provide a pointer to a plugin that is currently using this mechanism?
Dave
Here example for you guys.
On Mon, Dec 24, 2012 at 01:12:07AM +0100, Igor Stasenko wrote:
On 24 December 2012 00:28, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Dec 24, 2012 at 12:05:46AM +0100, Nicolas Cellier wrote:
2012/12/23 Igor Stasenko siguctua@gmail.com:
On 23 December 2012 22:25, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah OK, thanks, I get it... Two questions remain:
- how to access addGCroot: from within a SmartSyntaxInterpreterPlugin ?
interpreterProxy addGCroot: ...
Hmm, in NB you used a different strategy... First, you defined a NBInterpreterProxy to perform a simpleCall to addGCRoot() after registering this function in class method #proxyFunctionsData unless it is from #CogProxyFunctionsData (why two?) Then, no plugin calls addGCRoot: directly. Instead you defined a primAddGCRoot: in order to use it from within the image. That's a bit too much for a helpful simple example.
I fail to see how this easily transpose to a vanilla VMMaker and it's native InterpreterProxy. I think I'll have to hack InterpreterProxy to give access to addGCRoot: unless there is more magic I missed in the code generator...
It is already defined in the InterpreterProxy, so in principle 'interpreterProxy addGCroot: ... ' should work from a plugin. However, I do not see any actual examples of this being used in any plugins in my image. I have a hard time figuring out how to use something like this without a working example, so maybe someone can provide a pointer to a plugin that is currently using this mechanism?
Dave
Here example for you guys.
Thank you :)
Dave
-- Best regards, Igor Stasenko.
On 24 December 2012 00:05, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2012/12/23 Igor Stasenko siguctua@gmail.com:
On 23 December 2012 22:25, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah OK, thanks, I get it... Two questions remain:
- how to access addGCroot: from within a SmartSyntaxInterpreterPlugin ?
interpreterProxy addGCroot: ...
Hmm, in NB you used a different strategy... First, you defined a NBInterpreterProxy to perform a simpleCall to addGCRoot() after registering this function in class method #proxyFunctionsData unless it is from #CogProxyFunctionsData (why two?)
Because first implementation of NB was before Cog , it worked on Squeak/Stack VM:) And NBInterpreterProxy is exactly interface which VM provides for plugins: a table of function pointers.
Then, no plugin calls addGCRoot: directly.
Instead you defined a primAddGCRoot: in order to use it from within the image.
This method i a primitive, which code makes a call to that function. There's no magic, no "plugin" , nothing. Just pure function call. Everything implemented in smalltalk.
That's a bit too much for a helpful simple example.
I fail to see how this easily transpose to a vanilla VMMaker and it's native InterpreterProxy.
Directly :)
there's two things: - registering object(s) at given name (at:put:) - generating code to read an object at run time (emitOopAt:generator:)
i using only single root object - just a simple array. and NBExtraRootsRegistry maintaining that array size/elements, by giving a more convenient interface for outside (at:/at:put:/emitOopAt:generator:)
Like that, i can register any object under known name and access it later at run time.
For instance , #emitFetchClass:generator: is used for generating code to create instances of any class i wanna use in primitive(s) - (#createInstanceOf:size:), as well as for testing whether incoming argument(s) is correct/valid by doing class membership test. (verifyClassOf: is: generator: ).
I know it can be hard to see through generated code spahetti. But the logic there is very simple :)
I think I'll have to hack InterpreterProxy to give access to addGCRoot: unless there is more magic I missed in the code generator...
You don't need to hack anything , because it is already there. Just write interpeterProxy addGCRoot: in slang code and you done.
Nicolas
- when do you need to register (re-register)?
- once at image startup ?
yes,at image boot time. when session changes.
- after each snapshot ?
not here
There is no stupid question ;) well more or less...
I think I'll have a look at NativeBoost indeed...
Nicolas
2012/12/23 Igor Stasenko siguctua@gmail.com:
addGCRoot() takes a pointer to some memory location, where root object will be stored.
sqInt * mem;
mem = malloc(4); *mem = someOop; addGCRoot(mem);
now, to read a reference to 'someObject' at any place you can just do
someOop = *mem.
often you may want to register multiple objects for use. you can , of course, use addGCRoot() per each of them, or, just use an array to store unlimited number of objects as roots (that way you don't risk overflowing extra roots table, as well as can manage that array at image side, and at cost of extra indirection).
If you want a working example you can look at NBExtraRootsRegistry implementation, which is part of NativeBoost, how i using it.
On 23 December 2012 21:34, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I wanted to experiment a plugin and need to register a couple of classes that some primitive will test/instantiate. The ugly way is to pollute specialObjectArray... But #recreateSpecialObjectsArray recommend using addGCRoot() Fine, I'd like to try.
What I'd like to do is register my couple of classes in a primRegister() primitive (once for all or at each image startup, or at each snapshot, whatever...) Then to later use the registered classes in primDoSomething().
I can see ObjectMemory>>addGCRoot: but unfortunately, absolutely no sender of it to serve as an example... I even don't know how to access the objectMemory from within a SmartSyntaxInterpreterPlugin ? I can only see a interpreterProxy and
Then how to retrieve my registered objects? they are store in the extraRoots at some index, but that index is not returned by addGCRoot:... Anyway, the index could change thanks to removeGCRoot:, so I'm stuck here... I must be missing something... Or maybe addGCRoot: is just here to prevent an Object to be garbage collected but does not really offer a registering service...
If you know about any documentation/example hanging around or have some clues I'll be happy that you share them !
Last note, I'm in a VMMaker oscog flavour...
Nicolas
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
vm-dev@lists.squeakfoundation.org