Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
cheers, Esteban
On Mon, Sep 19, 2011 at 09:45:25AM -0300, Esteban Lorenzano wrote:
Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
Hi Esteban,
You are missing the code generation patch, which is in VMMaker-oscog-dtl.124. This has not yet been merged into the main oscog branch, so you will need to merge it yourself before building the Freetype plugin.
The changes are here: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009328.htm...
And background is in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.htm...
Dave
applied... now I have errors on FT2Plugin.c (it calls BytesPerWorld... and it does not exist....) what I'm missing? :( (I'm feeling sooooo dumb today...)
cheers, Esteban
El 19/09/2011, a las 3:50p.m., David T. Lewis escribió:
On Mon, Sep 19, 2011 at 09:45:25AM -0300, Esteban Lorenzano wrote:
Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
Hi Esteban,
You are missing the code generation patch, which is in VMMaker-oscog-dtl.124. This has not yet been merged into the main oscog branch, so you will need to merge it yourself before building the Freetype plugin.
The changes are here: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009328.htm...
And background is in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.htm...
Dave
Is that a typo somewhere, BytesPerWorld instead of BytesPerWord? Ken
At 5:12 PM -0300 9/19/11, Esteban Lorenzano apparently wrote:
applied... now I have errors on FT2Plugin.c (it calls BytesPerWorld... and it does not exist....) what I'm missing? :( (I'm feeling sooooo dumb today...)
cheers, Esteban
El 19/09/2011, a las 3:50p.m., David T. Lewis escribió:
On Mon, Sep 19, 2011 at 09:45:25AM -0300, Esteban Lorenzano wrote:
Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
Hi Esteban,
You are missing the code generation patch, which is in VMMaker-oscog-dtl.124. This has not yet been merged into the main oscog branch, so you will need to merge it yourself before building the Freetype plugin.
The changes are here: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009328.htm...
And background is in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.htm...
Dave
oh, no... sorry... the typo was mine (in this mail) The error happens with BytesPerWord :P
El 19/09/2011, a las 5:20p.m., Ken G. Brown escribió:
Is that a typo somewhere, BytesPerWorld instead of BytesPerWord? Ken
At 5:12 PM -0300 9/19/11, Esteban Lorenzano apparently wrote:
applied... now I have errors on FT2Plugin.c (it calls BytesPerWorld... and it does not exist....) what I'm missing? :( (I'm feeling sooooo dumb today...)
cheers, Esteban
El 19/09/2011, a las 3:50p.m., David T. Lewis escribió:
On Mon, Sep 19, 2011 at 09:45:25AM -0300, Esteban Lorenzano wrote:
Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
Hi Esteban,
You are missing the code generation patch, which is in VMMaker-oscog-dtl.124. This has not yet been merged into the main oscog branch, so you will need to merge it yourself before building the Freetype plugin.
The changes are here: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009328.htm...
And background is in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.htm...
Dave
I am away so I cannot look at the code right now, but in the oscog VMMaker you should still have BytesPerWord implemented as a class variable (or pool variable?), and this would be a C macro in the generated code. In the plugin, we use "self bytesPerWord" rather than a reference to the BytesPerWord class variable (because BytesPerWord does not exist in the trunk 32/64 bit code generation).
In VMMaker trunk, "self bytesPerWord" is translated to the C macro "BYTES_PER_WORD". In oscog VMMaker, it is translated to "BytesPerWord" which also happens to be a C macro. This works on both branches of VMMaker.
If this is not working for you, let me know the specific VMMaker and FT2Plugin MCZs that you have loaded, and I will try to reproduce this when I get home (about 8 hours from now).
Dave
On Mon, Sep 19, 2011 at 05:12:56PM -0300, Esteban Lorenzano wrote:
applied... now I have errors on FT2Plugin.c (it calls BytesPerWorld... and it does not exist....) what I'm missing? :( (I'm feeling sooooo dumb today...)
cheers, Esteban
El 19/09/2011, a las 3:50p.m., David T. Lewis escribi?:
On Mon, Sep 19, 2011 at 09:45:25AM -0300, Esteban Lorenzano wrote:
Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
Hi Esteban,
You are missing the code generation patch, which is in VMMaker-oscog-dtl.124. This has not yet been merged into the main oscog branch, so you will need to merge it yourself before building the Freetype plugin.
The changes are here: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009328.htm...
And background is in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.htm...
Dave
hi, I'm coming back with this issue (yep... no time last couple of weeks, but this one is a lot better :) I still can not compile FT2Plugin with the last changes, adding:
#bytesPerWord #generateBytesPerWord:on:indent: #baseHeaderSize #generateBaseHeaderSize:on:indent:
..etc...
you know, real problem is that #generateBytesPerWord:on:indent: generates a plain "BytesPerWord"... but BytesPerWord is not defined anywhere... so I assume there is something I'm missing, but I don't know why.
In other things, I'm determined to produce a beta release this week. As far as I know, I just need to solve some minor issues:
1) this FT2Plugin issue 2) externalize OSProcess (yes... I don´t like to have it as an internal plugin) 3) a stupid issue with localization strings (just used on open images)
and I don't think anything else :) so... if you help me with this issue... you will make me very happy :D
cheers, Esteban
El 19/09/2011, a las 5:27p.m., David T. Lewis escribió:
I am away so I cannot look at the code right now, but in the oscog VMMaker you should still have BytesPerWord implemented as a class variable (or pool variable?), and this would be a C macro in the generated code. In the plugin, we use "self bytesPerWord" rather than a reference to the BytesPerWord class variable (because BytesPerWord does not exist in the trunk 32/64 bit code generation).
In VMMaker trunk, "self bytesPerWord" is translated to the C macro "BYTES_PER_WORD". In oscog VMMaker, it is translated to "BytesPerWord" which also happens to be a C macro. This works on both branches of VMMaker.
If this is not working for you, let me know the specific VMMaker and FT2Plugin MCZs that you have loaded, and I will try to reproduce this when I get home (about 8 hours from now).
Dave
On Mon, Sep 19, 2011 at 05:12:56PM -0300, Esteban Lorenzano wrote:
applied... now I have errors on FT2Plugin.c (it calls BytesPerWorld... and it does not exist....) what I'm missing? :( (I'm feeling sooooo dumb today...)
cheers, Esteban
El 19/09/2011, a las 3:50p.m., David T. Lewis escribi?:
On Mon, Sep 19, 2011 at 09:45:25AM -0300, Esteban Lorenzano wrote:
Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
Hi Esteban,
You are missing the code generation patch, which is in VMMaker-oscog-dtl.124. This has not yet been merged into the main oscog branch, so you will need to merge it yourself before building the Freetype plugin.
The changes are here: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009328.htm...
And background is in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.htm...
Dave
Hi Esteban,
On Mon, Oct 03, 2011 at 11:54:58AM -0300, Esteban Lorenzano wrote:
hi, I'm coming back with this issue (yep... no time last couple of weeks, but this one is a lot better :) I still can not compile FT2Plugin with the last changes, adding:
#bytesPerWord #generateBytesPerWord:on:indent: #baseHeaderSize #generateBaseHeaderSize:on:indent:
..etc...
you know, real problem is that #generateBytesPerWord:on:indent: generates a plain "BytesPerWord"... but BytesPerWord is not defined anywhere... so I assume there is something I'm missing, but I don't know why.
In other things, I'm determined to produce a beta release this week. As far as I know, I just need to solve some minor issues:
- this FT2Plugin issue
I am away and cannot look at this right now, but when I last built a Cog VM to test this I was using the configure / make procedure (not the CMake procedure) and it seemed to be working, but maybe I was confused or maybe there is there is some difference related to the build procedure. Sorry, I am only guessing, and I'll try to look at it again in a couple of days.
- externalize OSProcess (yes... I don?t like to have it as an internal plugin)
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
Dave
- a stupid issue with localization strings (just used on open images)
and I don't think anything else :) so... if you help me with this issue... you will make me very happy :D
cheers, Esteban
El 19/09/2011, a las 5:27p.m., David T. Lewis escribi?:
I am away so I cannot look at the code right now, but in the oscog VMMaker you should still have BytesPerWord implemented as a class variable (or pool variable?), and this would be a C macro in the generated code. In the plugin, we use "self bytesPerWord" rather than a reference to the BytesPerWord class variable (because BytesPerWord does not exist in the trunk 32/64 bit code generation).
In VMMaker trunk, "self bytesPerWord" is translated to the C macro "BYTES_PER_WORD". In oscog VMMaker, it is translated to "BytesPerWord" which also happens to be a C macro. This works on both branches of VMMaker.
If this is not working for you, let me know the specific VMMaker and FT2Plugin MCZs that you have loaded, and I will try to reproduce this when I get home (about 8 hours from now).
Dave
On Mon, Sep 19, 2011 at 05:12:56PM -0300, Esteban Lorenzano wrote:
applied... now I have errors on FT2Plugin.c (it calls BytesPerWorld... and it does not exist....) what I'm missing? :( (I'm feeling sooooo dumb today...)
cheers, Esteban
El 19/09/2011, a las 3:50p.m., David T. Lewis escribi?:
On Mon, Sep 19, 2011 at 09:45:25AM -0300, Esteban Lorenzano wrote:
Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
Hi Esteban,
You are missing the code generation patch, which is in VMMaker-oscog-dtl.124. This has not yet been merged into the main oscog branch, so you will need to merge it yourself before building the Freetype plugin.
The changes are here: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009328.htm...
And background is in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.htm...
Dave
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
Hi Esteban,
On Mon, Oct 03, 2011 at 11:54:58AM -0300, Esteban Lorenzano wrote:
hi, I'm coming back with this issue (yep... no time last couple of weeks, but this one is a lot better :) I still can not compile FT2Plugin with the last changes, adding:
#bytesPerWord #generateBytesPerWord:on:indent: #baseHeaderSize #generateBaseHeaderSize:on:indent:
..etc...
you know, real problem is that #generateBytesPerWord:on:indent: generates a plain "BytesPerWord"... but BytesPerWord is not defined anywhere... so I assume there is something I'm missing, but I don't know why.
In other things, I'm determined to produce a beta release this week. As far as I know, I just need to solve some minor issues:
- this FT2Plugin issue
I am away and cannot look at this right now, but when I last built a Cog VM to test this I was using the configure / make procedure (not the CMake procedure) and it seemed to be working, but maybe I was confused or maybe there is there is some difference related to the build procedure. Sorry, I am only guessing, and I'll try to look at it again in a couple of days.
- externalize OSProcess (yes... I don?t like to have it as an internal plugin)
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
Dave
- a stupid issue with localization strings (just used on open images)
and I don't think anything else :) so... if you help me with this issue... you will make me very happy :D
cheers, Esteban
El 19/09/2011, a las 5:27p.m., David T. Lewis escribi?:
I am away so I cannot look at the code right now, but in the oscog VMMaker you should still have BytesPerWord implemented as a class variable (or pool variable?), and this would be a C macro in the generated code. In the plugin, we use "self bytesPerWord" rather than a reference to the BytesPerWord class variable (because BytesPerWord does not exist in the trunk 32/64 bit code generation).
In VMMaker trunk, "self bytesPerWord" is translated to the C macro "BYTES_PER_WORD". In oscog VMMaker, it is translated to "BytesPerWord" which also happens to be a C macro. This works on both branches of VMMaker.
If this is not working for you, let me know the specific VMMaker and FT2Plugin MCZs that you have loaded, and I will try to reproduce this when I get home (about 8 hours from now).
Dave
On Mon, Sep 19, 2011 at 05:12:56PM -0300, Esteban Lorenzano wrote:
applied... now I have errors on FT2Plugin.c (it calls BytesPerWorld... and it does not exist....) what I'm missing? :( (I'm feeling sooooo dumb today...)
cheers, Esteban
El 19/09/2011, a las 3:50p.m., David T. Lewis escribi?:
On Mon, Sep 19, 2011 at 09:45:25AM -0300, Esteban Lorenzano wrote:
Hi, I'm trying to build freetype plugin with latest version (Freetype-Plugin-dtl.63), and it is not working... and using Igor's version (61) it is working fine... unique change between 61 and 63 is:
bytesPerWord "Answer the size of an object pointer in bytes."
^BytesPerWord
...so... something is wrong with that change... or with my attempts to understand it :P maybe I'm missing some initialization?
Hi Esteban,
You are missing the code generation patch, which is in VMMaker-oscog-dtl.124. This has not yet been merged into the main oscog branch, so you will need to merge it yourself before building the Freetype plugin.
The changes are here: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009328.htm...
And background is in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.htm...
Dave
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Oct 03, 2011 at 11:54:58AM -0300, Esteban Lorenzano wrote:
- externalize OSProcess (yes... I don?t like to have it as an internal plugin)
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
I do not recall for sure, but is there a hackish linking flag for this that works on Cocoa?
Dave
Hi, yes... by default the compilation flag "visibility" in mac is set to "hidden". Easiest way to allow OSProcessPlugin to be built as external is to change that... but I still don't know if that is the correct way to do it ;)
cheers, Esteban
El 04/10/2011, a las 11:57a.m., David T. Lewis escribió:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Oct 03, 2011 at 11:54:58AM -0300, Esteban Lorenzano wrote:
- externalize OSProcess (yes... I don?t like to have it as an internal plugin)
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
I do not recall for sure, but is there a hackish linking flag for this that works on Cocoa?
Dave
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
1) Setting a compiler flag to instruct it to make globals visible does not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
2) In order for the definitions to be visible for both a standard interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
3) The argument vector and environment vector are Unix constructs. Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
Dave
On 5 October 2011 14:15, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
- Setting a compiler flag to instruct it to make globals visible does
not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
- In order for the definitions to be visible for both a standard
interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
- The argument vector and environment vector are Unix constructs.
Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
I have a strong opinion, that modules (and plugins) should access only those symbols, which are explicitly exported by module(s) they using, and not rely on something granted for free (implicitly visible via linker/compiler flags). Because if we don't care, then why do we need things like InterpreterProxy at all, if any plugin could just link directly to any VM function/variable in order to use it? Apparently, such approach violates the module encapsulation, because you no longer make sure that some symbols of your module is private and should not be accessed by others.
Also, may i ask, why OSProcess needs those vectors at all? Maybe a better solution would be to just avoid using them? I think, that it should be a responsibility of main module to expose those vectors, if it wants to, but not by a plugin. Because it again, violating the encapsulation principles.
Dave
On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
On 5 October 2011 14:15, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
- Setting a compiler flag to instruct it to make globals visible does
not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
- In order for the definitions to be visible for both a standard
interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
- The argument vector and environment vector are Unix constructs.
Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
I have a strong opinion, that modules (and plugins) should access only those symbols, which are explicitly exported by module(s) they using, and not rely on something granted for free (implicitly visible via linker/compiler flags). Because if we don't care, then why do we need things like InterpreterProxy at all, if any plugin could just link directly to any VM function/variable in order to use it? Apparently, such approach violates the module encapsulation, because you no longer make sure that some symbols of your module is private and should not be accessed by others.
If no one else speaks up, then your strong opinion will outvote my weak opinion.
Also, may i ask, why OSProcess needs those vectors at all? Maybe a better solution would be to just avoid using them? I think, that it should be a responsibility of main module to expose those vectors, if it wants to, but not by a plugin. Because it again, violating the encapsulation principles.
OSProcess is full of stuff that I put in just because I felt like doing it. To be honest, I never expected it to be widely used by other people. And I certainly was not attempting to rise to any high standards of software purity ;) Having said that, I do think that it is important to avoid putting platform-dependent things into the VM and image. What I choose to put into my own plugin or my own project is my business (and the development of OSProcess was an example of that), but I do not think it is good for "features" in OSProcess to creep into the core system.
Dave
well... my opinion:
1) I more or less agree with Igor: I don't think to expose everything to every plugin around is good. But I can be wrong... this is just an opinion and is *against* the smalltalk principles, in particular the "absolute openess, so you can make your system as you want"... the problems is that if we open everything, in mid time it will be hard to maintain... so... we have a problem here. 2) I do not like OSProcess plugin living inside the vm, as an internal plugin, just because "why not others, then"? also... if you want to break the API (by using whatever you want...), you just need to make your plugin "internal", and that's it... no more restrictions... and the same problem for maintaining in the future. 3) I think best solution is to re-think which functions are going to be visible... I agree with Dave we need to expose argv (and argc)... why? because I can think on plugins who need some "configuration".
So, my two cents, in short term: I would expose argc and argv through exported functions and adapt OSProcess plugin to use it (I think that's the only problem with OSProcess... maybe some other functions.
best, Esteban
pd: Dave, please, please... if you have 5', can you see the BytesPerWord problem?
El 05/10/2011, a las 11:41a.m., David T. Lewis escribió:
On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
On 5 October 2011 14:15, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
- Setting a compiler flag to instruct it to make globals visible does
not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
- In order for the definitions to be visible for both a standard
interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
- The argument vector and environment vector are Unix constructs.
Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
I have a strong opinion, that modules (and plugins) should access only those symbols, which are explicitly exported by module(s) they using, and not rely on something granted for free (implicitly visible via linker/compiler flags). Because if we don't care, then why do we need things like InterpreterProxy at all, if any plugin could just link directly to any VM function/variable in order to use it? Apparently, such approach violates the module encapsulation, because you no longer make sure that some symbols of your module is private and should not be accessed by others.
If no one else speaks up, then your strong opinion will outvote my weak opinion.
Also, may i ask, why OSProcess needs those vectors at all? Maybe a better solution would be to just avoid using them? I think, that it should be a responsibility of main module to expose those vectors, if it wants to, but not by a plugin. Because it again, violating the encapsulation principles.
OSProcess is full of stuff that I put in just because I felt like doing it. To be honest, I never expected it to be widely used by other people. And I certainly was not attempting to rise to any high standards of software purity ;) Having said that, I do think that it is important to avoid putting platform-dependent things into the VM and image. What I choose to put into my own plugin or my own project is my business (and the development of OSProcess was an example of that), but I do not think it is good for "features" in OSProcess to creep into the core system.
Dave
On Wed, Oct 05, 2011 at 11:52:49AM -0300, Esteban Lorenzano wrote:
pd: Dave, please, please... if you have 5', can you see the BytesPerWord problem?
I am traveling a lot right now but I will try. I looked at it a briefly a couple of days ago and got myself confused :/
Igor, perhaps you can confirm - when you build a Cog VM with FreeTypePlugin, and when the plugin source code is using BytesPerWord (defined elsewhere, I don't remember where at the moment), you were able to get a working FreeTypePlugin, right? So if the code generator is producing "BytesPerWord" in the plugin source, it should be working? Sorry for my confusion, but I did not have time to retrace my earlier steps from building a Cog VM to test compiling the plugin, so I can't check this right now (and maybe I made a mistake when I was looking at it earlier).
Thanks a lot, Dave
On 5 October 2011 17:18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 11:52:49AM -0300, Esteban Lorenzano wrote:
pd: Dave, please, please... if you have 5', can you see the BytesPerWord problem?
I am traveling a lot right now but I will try. I looked at it a briefly a couple of days ago and got myself confused :/
Igor, perhaps you can confirm - when you build a Cog VM with FreeTypePlugin, and when the plugin source code is using BytesPerWord (defined elsewhere, I don't remember where at the moment), you were able to get a working FreeTypePlugin, right? So if the code generator is producing "BytesPerWord" in the plugin source, it should be working? Sorry for my confusion, but I did not have time to retrace my earlier steps from building a Cog VM to test compiling the plugin, so I can't check this right now (and maybe I made a mistake when I was looking at it earlier).
Everything was working before you added the change for bytesPerWord method :D I don't know what is the problem right now, (i thought we're fixed it after discussing few weeks ago..) because i am not working on VM builds right now. So, Esteban, it is your call :D
Thanks a lot, Dave
On Wed, Oct 05, 2011 at 05:22:40PM +0200, Igor Stasenko wrote:
On 5 October 2011 17:18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 11:52:49AM -0300, Esteban Lorenzano wrote:
pd: Dave, please, please... if you have 5', can you see the BytesPerWord problem?
I am traveling a lot right now but I will try. I looked at it a briefly a couple of days ago and got myself confused :/
Igor, perhaps you can confirm - when you build a Cog VM with FreeTypePlugin, and when the plugin source code is using BytesPerWord (defined elsewhere, I don't remember where at the moment), you were able to get a working FreeTypePlugin, right? So if the code generator is producing "BytesPerWord" in the plugin source, it should be working? Sorry for my confusion, but I did not have time to retrace my earlier steps from building a Cog VM to test compiling the plugin, so I can't check this right now (and maybe I made a mistake when I was looking at it earlier).
Everything was working before you added the change for bytesPerWord method :D I don't know what is the problem right now, (i thought we're fixed it after discussing few weeks ago..) because i am not working on VM builds right now. So, Esteban, it is your call :D
OK, back to Esteban's original question about getting FreetypePlugin working.
I said earlier that I had built and tested a FreetypePlugin on Cog, but this is wrong. The plugin compiled successfully, and in loaded into my Squeak image when I tried it (based on 'Smalltalk listLoadedModules'), so I thought that it was working. However, the build process that I used was the the original unix/config/configure process, and this apparently is not working correctly for FreetypePlugin (the actual FT2Plugin.c code is not included in the build).
Therefore - I cannot confirm that this works on Cog. All I can say for sure is that the code generator changes that I provided produce the "BytesPerWord" output that would normally be used in the oscog branch, which would be the same as the code that apparently originally worked when Igor built a Cog VM prior to these changes.
Igor, whenever you next build some VMs, can you please check and see if the FreetypePlugin is running correctly (not just loading, but actually doing something)? If so, there must be something different in your build procedure compared to what Esteban is doing.
Thanks, Dave
On 6 October 2011 04:19, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:22:40PM +0200, Igor Stasenko wrote:
On 5 October 2011 17:18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 11:52:49AM -0300, Esteban Lorenzano wrote:
pd: Dave, please, please... if you have 5', can you see the BytesPerWord problem?
I am traveling a lot right now but I will try. I looked at it a briefly a couple of days ago and got myself confused :/
Igor, perhaps you can confirm - when you build a Cog VM with FreeTypePlugin, and when the plugin source code is using BytesPerWord (defined elsewhere, I don't remember where at the moment), you were able to get a working FreeTypePlugin, right? So if the code generator is producing "BytesPerWord" in the plugin source, it should be working? Sorry for my confusion, but I did not have time to retrace my earlier steps from building a Cog VM to test compiling the plugin, so I can't check this right now (and maybe I made a mistake when I was looking at it earlier).
Everything was working before you added the change for bytesPerWord method :D I don't know what is the problem right now, (i thought we're fixed it after discussing few weeks ago..) because i am not working on VM builds right now. So, Esteban, it is your call :D
OK, back to Esteban's original question about getting FreetypePlugin working.
I said earlier that I had built and tested a FreetypePlugin on Cog, but this is wrong. The plugin compiled successfully, and in loaded into my Squeak image when I tried it (based on 'Smalltalk listLoadedModules'), so I thought that it was working. However, the build process that I used was the the original unix/config/configure process, and this apparently is not working correctly for FreetypePlugin (the actual FT2Plugin.c code is not included in the build).
Therefore - I cannot confirm that this works on Cog. All I can say for sure is that the code generator changes that I provided produce the "BytesPerWord" output that would normally be used in the oscog branch, which would be the same as the code that apparently originally worked when Igor built a Cog VM prior to these changes.
Igor, whenever you next build some VMs, can you please check and see if the FreetypePlugin is running correctly (not just loading, but actually doing something)? If so, there must be something different in your build procedure compared to what Esteban is doing.
I had error reports that build is broken on jenkins server , and the problem is undefined bytes-per-word thingy. If you look at
https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Carbon/9/console
linking C shared library /Users/hudson/jenkins/workspace/Cog-Mac-Carbon/cog/results/CogVM.app/Contents/Resources/libFT2Plugin.dylib Undefined symbols: "_bytesPerWord", referenced from: _ftHandleValueFromReceiver in FT2Plugin.c.o _primitiveLoadGlyphSlotFromFace in FT2Plugin.c.o ld: symbol(s) not found
so, its not about that plugin is built but buggy, but its not even built correctly now :)
Concerning bugs in plugin: i didn't checked it thoughoutly, but i remember one problem i had recently: i tried to play with font outline data, and VM was crashed at my attempt of doing that.
Since font rendering doesn't using that code, the bug is not "critical", but if it there, it would be nice to fix it, because outline data is useful for rendering glyphs using various fancy effects etc, as well as passing outline data directly to shader(s), so rendering them could be done on GPU instead of CPU.
Thanks, Dave
On Thu, Oct 06, 2011 at 05:00:12AM +0300, Igor Stasenko wrote:
On 6 October 2011 04:19, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:22:40PM +0200, Igor Stasenko wrote:
On 5 October 2011 17:18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 11:52:49AM -0300, Esteban Lorenzano wrote:
pd: Dave, please, please... if you have 5', can you see the BytesPerWord problem?
I am traveling a lot right now but I will try. I looked at it a briefly a couple of days ago and got myself confused :/
Igor, perhaps you can confirm - when you build a Cog VM with FreeTypePlugin, and when the plugin source code is using BytesPerWord (defined elsewhere, I don't remember where at the moment), you were able to get a working FreeTypePlugin, right? So if the code generator is producing "BytesPerWord" in the plugin source, it should be working? Sorry for my confusion, but I did not have time to retrace my earlier steps from building a Cog VM to test compiling the plugin, so I can't check this right now (and maybe I made a mistake when I was looking at it earlier).
Everything was working before you added the change for bytesPerWord method :D I don't know what is the problem right now, (i thought we're fixed it after discussing few weeks ago..) because i am not working on VM builds right now. So, Esteban, it is your call :D
OK, back to Esteban's original question about getting FreetypePlugin working.
I said earlier that I had built and tested a FreetypePlugin on Cog, but this is wrong. The plugin compiled successfully, and in loaded into my Squeak image when I tried it (based on 'Smalltalk listLoadedModules'), so I thought that it was working. However, the build process that I used was the the original unix/config/configure process, and this apparently is not working correctly for FreetypePlugin (the actual FT2Plugin.c code is not included in the build).
Therefore - I cannot confirm that this works on Cog. All I can say for sure is that the code generator changes that I provided produce the "BytesPerWord" output that would normally be used in the oscog branch, which would be the same as the code that apparently originally worked when Igor built a Cog VM prior to these changes.
Igor, whenever you next build some VMs, can you please check and see if the FreetypePlugin is running correctly (not just loading, but actually doing something)? If so, there must be something different in your build procedure compared to what Esteban is doing.
I had error reports that build is broken on jenkins server , and the problem is undefined bytes-per-word thingy. If you look at
https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Carbon/9/console
linking C shared library /Users/hudson/jenkins/workspace/Cog-Mac-Carbon/cog/results/CogVM.app/Contents/Resources/libFT2Plugin.dylib Undefined symbols: "_bytesPerWord", referenced from: _ftHandleValueFromReceiver in FT2Plugin.c.o _primitiveLoadGlyphSlotFromFace in FT2Plugin.c.o ld: symbol(s) not found
This just means that the image that did the code generation did not have the code generator patch for BytesPerWord, so of course it will not work. The "self bytesPerWord" in Smalltalk needs to be translated as "BytesPerWord" for Cog. But the question is whether the BytesPerWord macro is defined for plugins in the oscog branch. I suspect that the answer is no, and that is why Esteban cannot get the plugin to work.
But now I think I see the problem. The BytesPerWord macro is generated by CCodeGenerator>>emitCConstantsOn: which eliminates all unused constants before generating them as macros in the C source for FreeTypePlugin. When we use "self bytesPerWord", the BytesPerWord variable is not directly referenced by the plugin, and therefore the macro does not get generated in FreetypePlugin.c. So we need a way to convince CCodeGenerator not to treat BytesPerWord as unreferenced.
So that is the problem ... just need to think of a solution now.
Dave
On Wed, Oct 05, 2011 at 11:23:03PM -0400, David T. Lewis wrote:
On Thu, Oct 06, 2011 at 05:00:12AM +0300, Igor Stasenko wrote:
On 6 October 2011 04:19, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:22:40PM +0200, Igor Stasenko wrote:
On 5 October 2011 17:18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 11:52:49AM -0300, Esteban Lorenzano wrote:
pd: Dave, please, please... if you have 5', can you see the BytesPerWord problem?
I am traveling a lot right now but I will try. I looked at it a briefly a couple of days ago and got myself confused :/
Igor, perhaps you can confirm - when you build a Cog VM with FreeTypePlugin, and when the plugin source code is using BytesPerWord (defined elsewhere, I don't remember where at the moment), you were able to get a working FreeTypePlugin, right? So if the code generator is producing "BytesPerWord" in the plugin source, it should be working? Sorry for my confusion, but I did not have time to retrace my earlier steps from building a Cog VM to test compiling the plugin, so I can't check this right now (and maybe I made a mistake when I was looking at it earlier).
Everything was working before you added the change for bytesPerWord method :D I don't know what is the problem right now, (i thought we're fixed it after discussing few weeks ago..) because i am not working on VM builds right now. So, Esteban, it is your call :D
OK, back to Esteban's original question about getting FreetypePlugin working.
I said earlier that I had built and tested a FreetypePlugin on Cog, but this is wrong. The plugin compiled successfully, and in loaded into my Squeak image when I tried it (based on 'Smalltalk listLoadedModules'), so I thought that it was working. However, the build process that I used was the the original unix/config/configure process, and this apparently is not working correctly for FreetypePlugin (the actual FT2Plugin.c code is not included in the build).
Therefore - I cannot confirm that this works on Cog. All I can say for sure is that the code generator changes that I provided produce the "BytesPerWord" output that would normally be used in the oscog branch, which would be the same as the code that apparently originally worked when Igor built a Cog VM prior to these changes.
Igor, whenever you next build some VMs, can you please check and see if the FreetypePlugin is running correctly (not just loading, but actually doing something)? If so, there must be something different in your build procedure compared to what Esteban is doing.
I had error reports that build is broken on jenkins server , and the problem is undefined bytes-per-word thingy. If you look at
https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Carbon/9/console
linking C shared library /Users/hudson/jenkins/workspace/Cog-Mac-Carbon/cog/results/CogVM.app/Contents/Resources/libFT2Plugin.dylib Undefined symbols: "_bytesPerWord", referenced from: _ftHandleValueFromReceiver in FT2Plugin.c.o _primitiveLoadGlyphSlotFromFace in FT2Plugin.c.o ld: symbol(s) not found
This just means that the image that did the code generation did not have the code generator patch for BytesPerWord, so of course it will not work. The "self bytesPerWord" in Smalltalk needs to be translated as "BytesPerWord" for Cog. But the question is whether the BytesPerWord macro is defined for plugins in the oscog branch. I suspect that the answer is no, and that is why Esteban cannot get the plugin to work.
But now I think I see the problem. The BytesPerWord macro is generated by CCodeGenerator>>emitCConstantsOn: which eliminates all unused constants before generating them as macros in the C source for FreeTypePlugin. When we use "self bytesPerWord", the BytesPerWord variable is not directly referenced by the plugin, and therefore the macro does not get generated in FreetypePlugin.c. So we need a way to convince CCodeGenerator not to treat BytesPerWord as unreferenced.
So that is the problem ... just need to think of a solution now.
I just posted VMMaker-oscog-dtl.125, which contains a one-line patch that appears to address the problem of BytesPerWord not being defined in FreeTypePlugin.
Dave
On 5 October 2011 16:41, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
On 5 October 2011 14:15, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
- Setting a compiler flag to instruct it to make globals visible does
not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
- In order for the definitions to be visible for both a standard
interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
- The argument vector and environment vector are Unix constructs.
Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
I have a strong opinion, that modules (and plugins) should access only those symbols, which are explicitly exported by module(s) they using, and not rely on something granted for free (implicitly visible via linker/compiler flags). Because if we don't care, then why do we need things like InterpreterProxy at all, if any plugin could just link directly to any VM function/variable in order to use it? Apparently, such approach violates the module encapsulation, because you no longer make sure that some symbols of your module is private and should not be accessed by others.
If no one else speaks up, then your strong opinion will outvote my weak opinion.
Also, may i ask, why OSProcess needs those vectors at all? Maybe a better solution would be to just avoid using them? I think, that it should be a responsibility of main module to expose those vectors, if it wants to, but not by a plugin. Because it again, violating the encapsulation principles.
OSProcess is full of stuff that I put in just because I felt like doing it. To be honest, I never expected it to be widely used by other people. And I certainly was not attempting to rise to any high standards of software purity ;) Having said that, I do think that it is important to avoid putting platform-dependent things into the VM and image. What I choose to put into my own plugin or my own project is my business (and the development of OSProcess was an example of that), but I do not think it is good for "features" in OSProcess to creep into the core system.
I understand the situation around plugin, Dave.
Yes, it is platform dependent. You can compile main module with different entry point (non POSIX), where you don't have access to argv/argc variables at all. For instance windows WinMain() function does not have them. But my point was more about who should take care about exposing those symbols, not about whether all platforms should support this API or not.
So, the point is, that since argc/argv stuff are coming from main module, then main module should care about exposing (or not) these symbols, not the third-party plugin.
Dave
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... {"","stWindow", &stWindow}, {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
On 5 October 2011 17:13, Igor Stasenko siguctua@gmail.com wrote:
On 5 October 2011 16:41, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
On 5 October 2011 14:15, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote:
I think there was an issue on some of the Mac platforms that required a compiler flag to force the compiler to make global variables visible (for the environment vector, etc). Is that the problem here? I do not have a Mac, but I'll try to help figure this out if I can.
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
- Setting a compiler flag to instruct it to make globals visible does
not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
- In order for the definitions to be visible for both a standard
interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
- The argument vector and environment vector are Unix constructs.
Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
I have a strong opinion, that modules (and plugins) should access only those symbols, which are explicitly exported by module(s) they using, and not rely on something granted for free (implicitly visible via linker/compiler flags). Because if we don't care, then why do we need things like InterpreterProxy at all, if any plugin could just link directly to any VM function/variable in order to use it? Apparently, such approach violates the module encapsulation, because you no longer make sure that some symbols of your module is private and should not be accessed by others.
If no one else speaks up, then your strong opinion will outvote my weak opinion.
Also, may i ask, why OSProcess needs those vectors at all? Maybe a better solution would be to just avoid using them? I think, that it should be a responsibility of main module to expose those vectors, if it wants to, but not by a plugin. Because it again, violating the encapsulation principles.
OSProcess is full of stuff that I put in just because I felt like doing it. To be honest, I never expected it to be widely used by other people. And I certainly was not attempting to rise to any high standards of software purity ;) Having said that, I do think that it is important to avoid putting platform-dependent things into the VM and image. What I choose to put into my own plugin or my own project is my business (and the development of OSProcess was an example of that), but I do not think it is good for "features" in OSProcess to creep into the core system.
I understand the situation around plugin, Dave.
Yes, it is platform dependent. You can compile main module with different entry point (non POSIX), where you don't have access to argv/argc variables at all. For instance windows WinMain() function does not have them. But my point was more about who should take care about exposing those symbols, not about whether all platforms should support this API or not.
So, the point is, that since argc/argv stuff are coming from main module, then main module should care about exposing (or not) these symbols, not the third-party plugin.
Dave
-- Best regards, Igor Stasenko.
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... {"","stWindow", &stWindow}, {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
I have no objection at all, this sounds like a good idea to me :)
I need to ask though, is ioLoadFunction() the one that you added for module security (some time in the last year or so I think)? That function crashes on 64 bit, so we would need to sort that out (sorry I can't look at source right now).
Dave
On 5 October 2011 17:13, Igor Stasenko siguctua@gmail.com wrote:
On 5 October 2011 16:41, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
On 5 October 2011 14:15, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote: > > I think there was an issue on some of the Mac platforms that required > a compiler flag to force the compiler to make global variables visible > (for the environment vector, etc). Is that the problem here? I do not > have a Mac, but I'll try to help figure this out if I can. >
If i remember correctly, a Cocoa VM using different entry point for main() function. or have some other differencies, so you cannot just pass argc, argv around, but you have to prepare them.
If you remember, i proposed to make an API for exposing these variables, so then not only OSProcess could access them but any other plugin, without need of hackish linking flags, which lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
- Setting a compiler flag to instruct it to make globals visible does
not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
- In order for the definitions to be visible for both a standard
interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
- The argument vector and environment vector are Unix constructs.
Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
I have a strong opinion, that modules (and plugins) should access only those symbols, which are explicitly exported by module(s) they using, and not rely on something granted for free (implicitly visible via linker/compiler flags). Because if we don't care, then why do we need things like InterpreterProxy at all, if any plugin could just link directly to any VM function/variable in order to use it? Apparently, such approach violates the module encapsulation, because you no longer make sure that some symbols of your module is private and should not be accessed by others.
If no one else speaks up, then your strong opinion will outvote my weak opinion.
Also, may i ask, why OSProcess needs those vectors at all? Maybe a better solution would be to just avoid using them? I think, that it should be a responsibility of main module to expose those vectors, if it wants to, but not by a plugin. Because it again, violating the encapsulation principles.
OSProcess is full of stuff that I put in just because I felt like doing it. To be honest, I never expected it to be widely used by other people. And I certainly was not attempting to rise to any high standards of software purity ;) Having said that, I do think that it is important to avoid putting platform-dependent things into the VM and image. What I choose to put into my own plugin or my own project is my business (and the development of OSProcess was an example of that), but I do not think it is good for "features" in OSProcess to creep into the core system.
I understand the situation around plugin, Dave.
Yes, it is platform dependent. You can compile main module with different entry point (non POSIX), where you don't have access to argv/argc variables at all. For instance windows WinMain() function does not have them. But my point was more about who should take care about exposing those symbols, not about whether all platforms should support this API or not.
So, the point is, that since argc/argv stuff are coming from main module, then main module should care about exposing (or not) these symbols, not the third-party plugin.
Dave
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 5 October 2011 21:10, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... {"","stWindow", &stWindow}, {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
I have no objection at all, this sounds like a good idea to me :)
I need to ask though, is ioLoadFunction() the one that you added for module security (some time in the last year or so I think)? That function crashes on 64 bit, so we would need to sort that out (sorry I can't look at source right now).
No, this function was there for ages, and it is use by various plugins like bitblt for interoperability between plugins. I changed the module loading mechanism to prevent loading new modules once image invokes a special primitive - disableModuleLoading. But other than that, i didn't changed anything.
Dave
On 5 October 2011 17:13, Igor Stasenko siguctua@gmail.com wrote:
On 5 October 2011 16:41, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
On 5 October 2011 14:15, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote: > > On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote: > > > > I think there was an issue on some of the Mac platforms that required > > a compiler flag to force the compiler to make global variables visible > > (for the environment vector, etc). Is that the problem here? I do not > > have a Mac, but I'll try to help figure this out if I can. > > > > If i remember correctly, a Cocoa VM using different entry point for > main() function. > or have some other differencies, so you cannot just pass argc, argv > around, but you have to prepare them. > > If you remember, i proposed to make an API for exposing these > variables, so then not only OSProcess could access them > but any other plugin, without need of hackish linking flags, which > lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
- Setting a compiler flag to instruct it to make globals visible does
not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
- In order for the definitions to be visible for both a standard
interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
- The argument vector and environment vector are Unix constructs.
Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
I have a strong opinion, that modules (and plugins) should access only those symbols, which are explicitly exported by module(s) they using, and not rely on something granted for free (implicitly visible via linker/compiler flags). Because if we don't care, then why do we need things like InterpreterProxy at all, if any plugin could just link directly to any VM function/variable in order to use it? Apparently, such approach violates the module encapsulation, because you no longer make sure that some symbols of your module is private and should not be accessed by others.
If no one else speaks up, then your strong opinion will outvote my weak opinion.
Also, may i ask, why OSProcess needs those vectors at all? Maybe a better solution would be to just avoid using them? I think, that it should be a responsibility of main module to expose those vectors, if it wants to, but not by a plugin. Because it again, violating the encapsulation principles.
OSProcess is full of stuff that I put in just because I felt like doing it. To be honest, I never expected it to be widely used by other people. And I certainly was not attempting to rise to any high standards of software purity ;) Having said that, I do think that it is important to avoid putting platform-dependent things into the VM and image. What I choose to put into my own plugin or my own project is my business (and the development of OSProcess was an example of that), but I do not think it is good for "features" in OSProcess to creep into the core system.
I understand the situation around plugin, Dave.
Yes, it is platform dependent. You can compile main module with different entry point (non POSIX), where you don't have access to argv/argc variables at all. For instance windows WinMain() function does not have them. But my point was more about who should take care about exposing those symbols, not about whether all platforms should support this API or not.
So, the point is, that since argc/argv stuff are coming from main module, then main module should care about exposing (or not) these symbols, not the third-party plugin.
Dave
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... {"","stWindow", &stWindow}, {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
To check my understanding, do you mean #ioLoadFunction:From: as implemented in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module, and load functions that answer the argvec and envvec from that module?
Dave
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... {"","stWindow", &stWindow}, {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
To check my understanding, do you mean #ioLoadFunction:From: as implemented in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module, and load functions that answer the argvec and envvec from that module?
Right. It is already treated as a module, so it is not new.
Dave
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... ?? {"","stWindow", &stWindow}, ?? {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
To check my understanding, do you mean #ioLoadFunction:From: as implemented in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module, and load functions that answer the argvec and envvec from that module?
Right. It is already treated as a module, so it is not new.
Thanks, I understand now.
I'll try this with OSPP when I get a chance. Meanwhile, if you want to take the lead on this issue to get the exported functions added to platforms code, that would be good.
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Dave
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... ?? {"","stWindow", &stWindow}, ?? {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
To check my understanding, do you mean #ioLoadFunction:From: as implemented in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module, and load functions that answer the argvec and envvec from that module?
Right. It is already treated as a module, so it is not new.
Thanks, I understand now.
I'll try this with OSPP when I get a chance. Meanwhile, if you want to take the lead on this issue to get the exported functions added to platforms code, that would be good.
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Why? Why keeping workarounds? You can introduce this logic right now in OSPP, without waiting updates to VM sources, since there are no any requirements to change VM code to be compatible. If those symbols are not exported by VM module, then plugin should behave as if platform have no support for this functionality, which is pretty fair (as you already told - some platforms/build configurations could simply not provide it). Its fine. You fail primitive etc, and it is perfectly ok as to me. As soon as newer VMs will start exporting those symbols, an updated OSPP will be available to provide corresponding functionality.
Does that makes sense?
Dave
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... ?? {"","stWindow", &stWindow}, ?? {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
To check my understanding, do you mean #ioLoadFunction:From: as implemented in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module, and load functions that answer the argvec and envvec from that module?
Right. It is already treated as a module, so it is not new.
Thanks, I understand now.
I'll try this with OSPP when I get a chance. Meanwhile, if you want to take the lead on this issue to get the exported functions added to platforms code, that would be good.
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You can introduce this logic right now in OSPP, without waiting updates to VM sources, since there are no any requirements to change VM code to be compatible. If those symbols are not exported by VM module, then plugin should behave as if platform have no support for this functionality, which is pretty fair (as you already told - some platforms/build configurations could simply not provide it). Its fine.
I will give it a try as soon as I have a chance (but I am traveling, so maybe not this weekend).
You fail primitive etc, and it is perfectly ok as to me. As soon as newer VMs will start exporting those symbols, an updated OSPP will be available to provide corresponding functionality.
It might be OK with you, but it is *not* OK with me.
Does that makes sense?
Yes, and thanks very much for your patience in explaining the export mechanism (sorry I was so dense before!).
Thanks, Dave
On 7 October 2011 16:18, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... ?? {"","stWindow", &stWindow}, ?? {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
To check my understanding, do you mean #ioLoadFunction:From: as implemented in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module, and load functions that answer the argvec and envvec from that module?
Right. It is already treated as a module, so it is not new.
Thanks, I understand now.
I'll try this with OSPP when I get a chance. Meanwhile, if you want to take the lead on this issue to get the exported functions added to platforms code, that would be good.
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You lost me here. VM is evolving, things keep changing. Can you tell me any of the reason for keeping a freshly-built plugin to be compatible with 10-years old VMs? One could always use older version(s) of plugin which works with that VMs.. so, what is the problem?
Can you explain me , what is the benefits from staying compatible with dusty systems which, most probably, are used by 1% of users (if any)?
IMO, the purpose of plugin subsystem should be to serve as a way to customize the VM(s) for various kinds of distributions, but not as a way to ensure that something which was working 10 years ago, will keep working today without any changes.
You can introduce this logic right now in OSPP, without waiting updates to VM sources, since there are no any requirements to change VM code to be compatible. If those symbols are not exported by VM module, then plugin should behave as if platform have no support for this functionality, which is pretty fair (as you already told - some platforms/build configurations could simply not provide it). Its fine.
I will give it a try as soon as I have a chance (but I am traveling, so maybe not this weekend).
You fail primitive etc, and it is perfectly ok as to me. As soon as newer VMs will start exporting those symbols, an updated OSPP will be available to provide corresponding functionality.
It might be OK with you, but it is *not* OK with me.
Does that makes sense?
Yes, and thanks very much for your patience in explaining the export mechanism (sorry I was so dense before!).
You were not even close to testing my patience. Actually by saying "does it makes sense" i meant "does it sounds like a plan"? :)
Thanks, Dave
On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
On 7 October 2011 16:18, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You lost me here. VM is evolving, things keep changing. Can you tell me any of the reason for keeping a freshly-built plugin to be compatible with 10-years old VMs? One could always use older version(s) of plugin which works with that VMs.. so, what is the problem?
Can you explain me , what is the benefits from staying compatible with dusty systems which, most probably, are used by 1% of users (if any)?
IMO, the purpose of plugin subsystem should be to serve as a way to customize the VM(s) for various kinds of distributions, but not as a way to ensure that something which was working 10 years ago, will keep working today without any changes.
It's about modularity. I maintain the three plugins for OSProcess as separate packages independent of any version of VMMaker. As with any such problem, maintaining the integrity os interfaces is the key to success.
I also care about the people who might use these packages, and often I do not even know who they are. If someone in Japan or China or a researcher at a university wants to build a VM with whatever flavor of Squeak or VMMaker, I want my packages to work without problems.
I also am lazy. I find that a little time and effort making sure the interfaces work saves a lot of my time later on. If I don't break something, I don't have to waste time later on explaining why it does not work. That is the same reason I write lots of tests and comments. It just saves a lot of time and excuses later on.
That is the approach I have taken, and it has worked well for me so far.
Dave
On 7 October 2011 21:07, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
On 7 October 2011 16:18, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You lost me here. VM is evolving, things keep changing. Can you tell me any of the reason for keeping a freshly-built plugin to be compatible with 10-years old VMs? One could always use older version(s) of plugin which works with that VMs.. so, what is the problem?
Can you explain me , what is the benefits from staying compatible with dusty systems which, most probably, are used by 1% of users (if any)?
IMO, the purpose of plugin subsystem should be to serve as a way to customize the VM(s) for various kinds of distributions, but not as a way to ensure that something which was working 10 years ago, will keep working today without any changes.
It's about modularity. I maintain the three plugins for OSProcess as separate packages independent of any version of VMMaker. As with any such problem, maintaining the integrity os interfaces is the key to success.
The things which i proposing leaving you less to maintain. I do not see any conflict there.
I also care about the people who might use these packages, and often I do not even know who they are. If someone in Japan or China or a researcher at a university wants to build a VM with whatever flavor of Squeak or VMMaker, I want my packages to work without problems.
To my observations, this kind of "modularity" never worked without paying attention (testing & fixing) every time to new stuff which goes out. Every time something got broken, every update has some roughness we have to overcome.
Remember the numerous reports about OSProcess not working here and there, FFI here and there, Freetype and so on. As to me the experience actually showing completely opposite: using modules as a solution for compatibility are largely failing.
I also am lazy. I find that a little time and effort making sure the interfaces work saves a lot of my time later on. If I don't break something, I don't have to waste time later on explaining why it does not work. That is the same reason I write lots of tests and comments. It just saves a lot of time and excuses later on.
Dont wanna go into deep philosophical discussion, just wanna say that changing and improving are not synonyms to breaking. :)
That is the approach I have taken, and it has worked well for me so far.
But it doesn't works. Otherwise there will be no point for current discussion. Isn't?
Clever hacks, not matter how clever they are are still remain hacks. My proposal is to remove them order to have more consistent interaction between OSP and VM. I consider the current model having flaws, which needs to be fixed. And if fixing the flaw meaning to break it, yes lets break it. You cannot break something which was already broken before.
Dave
On Fri, Oct 07, 2011 at 10:22:02PM +0200, Igor Stasenko wrote:
On 7 October 2011 21:07, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
On 7 October 2011 16:18, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote: > > On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You lost me here. VM is evolving, things keep changing. Can you tell me any of the reason for keeping a freshly-built plugin to be compatible with 10-years old VMs? One could always use older version(s) of plugin which works with that VMs.. so, what is the problem?
Can you explain me , what is the benefits from staying compatible with dusty systems which, most probably, are used by 1% of users (if any)?
IMO, the purpose of plugin subsystem should be to serve as a way to customize the VM(s) for various kinds of distributions, but not as a way to ensure that something which was working 10 years ago, will keep working today without any changes.
It's about modularity. I maintain the three plugins for OSProcess as separate packages independent of any version of VMMaker. As with any such problem, maintaining the integrity os interfaces is the key to success.
The things which i proposing leaving you less to maintain. I do not see any conflict there.
I also care about the people who might use these packages, and often I do not even know who they are. ??If someone in Japan or China or a researcher at a university wants to build a VM with whatever flavor of Squeak or VMMaker, I want my packages to work without problems.
To my observations, this kind of "modularity" never worked without paying attention (testing & fixing) every time to new stuff which goes out. Every time something got broken, every update has some roughness we have to overcome.
Remember the numerous reports about OSProcess not working here and there, FFI here and there, Freetype and so on. As to me the experience actually showing completely opposite: using modules as a solution for compatibility are largely failing.
I also am lazy. I find that a little time and effort making sure the interfaces work saves a lot of my time later on. If I don't break something, I don't have to waste time later on explaining why it does not work. That is the same reason I write lots of tests and comments. It just saves a lot of time and excuses later on.
Dont wanna go into deep philosophical discussion, just wanna say that changing and improving are not synonyms to breaking. :)
That is the approach I have taken, and it has worked well for me so far.
But it doesn't works. Otherwise there will be no point for current discussion. Isn't?
Clever hacks, not matter how clever they are are still remain hacks. My proposal is to remove them order to have more consistent interaction between OSP and VM. I consider the current model having flaws, which needs to be fixed. And if fixing the flaw meaning to break it, yes lets break it. You cannot break something which was already broken before.
If you feel that this is important, then please go ahead and work on it. As long as the changes do not break things for other people (e.g. the standard interpreter VM), you have my personal commitment to add whatever may be necessary in OSPP. But I will not break compatibility for other VM projects, that is my only point.
Please proceed.
Dave
On Sun, Oct 09, 2011 at 10:05:12AM -0400, David T. Lewis wrote:
On Fri, Oct 07, 2011 at 10:22:02PM +0200, Igor Stasenko wrote:
On 7 October 2011 21:07, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
On 7 October 2011 16:18, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote: > > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote: >> >> On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote: > > I need to ensure that OSPP runs on trunk as well as oscog branches, > which means that updates to all those branches would be best. But > I suspect it may be possible to adopt a strategy of loading with > ioLoadFunction, and if this fails, try a direct reference to the > global variable (though I don't know if Carbon will allow this?). >
Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You lost me here. VM is evolving, things keep changing. Can you tell me any of the reason for keeping a freshly-built plugin to be compatible with 10-years old VMs? One could always use older version(s) of plugin which works with that VMs.. so, what is the problem?
Can you explain me , what is the benefits from staying compatible with dusty systems which, most probably, are used by 1% of users (if any)?
IMO, the purpose of plugin subsystem should be to serve as a way to customize the VM(s) for various kinds of distributions, but not as a way to ensure that something which was working 10 years ago, will keep working today without any changes.
It's about modularity. I maintain the three plugins for OSProcess as separate packages independent of any version of VMMaker. As with any such problem, maintaining the integrity os interfaces is the key to success.
The things which i proposing leaving you less to maintain. I do not see any conflict there.
I also care about the people who might use these packages, and often I do not even know who they are. ??If someone in Japan or China or a researcher at a university wants to build a VM with whatever flavor of Squeak or VMMaker, I want my packages to work without problems.
To my observations, this kind of "modularity" never worked without paying attention (testing & fixing) every time to new stuff which goes out. Every time something got broken, every update has some roughness we have to overcome.
Remember the numerous reports about OSProcess not working here and there, FFI here and there, Freetype and so on. As to me the experience actually showing completely opposite: using modules as a solution for compatibility are largely failing.
I also am lazy. I find that a little time and effort making sure the interfaces work saves a lot of my time later on. If I don't break something, I don't have to waste time later on explaining why it does not work. That is the same reason I write lots of tests and comments. It just saves a lot of time and excuses later on.
Dont wanna go into deep philosophical discussion, just wanna say that changing and improving are not synonyms to breaking. :)
That is the approach I have taken, and it has worked well for me so far.
But it doesn't works. Otherwise there will be no point for current discussion. Isn't?
Clever hacks, not matter how clever they are are still remain hacks. My proposal is to remove them order to have more consistent interaction between OSP and VM. I consider the current model having flaws, which needs to be fixed. And if fixing the flaw meaning to break it, yes lets break it. You cannot break something which was already broken before.
If you feel that this is important, then please go ahead and work on it. As long as the changes do not break things for other people (e.g. the standard interpreter VM), you have my personal commitment to add whatever may be necessary in OSPP. But I will not break compatibility for other VM projects, that is my only point.
Please proceed.
Hi Igor,
I added the necessary support to OSPP in VMConstruction-Plugins-OSProcessPlugin-dtl.31, and tested it on Linux with standard interpreter VM. All works as expected, so if you want to give it a try, the functions that must be exported are:
char **ioGetEnvVec(void); char **ioGetArgVec(void); int ioGetArgCount(void);
I don't have a Mac, so I'll leave it to you (or Esteban) to add the hooks in the platforms support code.
The OSPP code will use the global variables when exported functions are not available, and it is possible that this will cause problems with unreferenced variables on Carbon. I have no way of testing this, so if you try it and find problems please let me know.
HTH, Dave
On 10 October 2011 15:39, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Oct 09, 2011 at 10:05:12AM -0400, David T. Lewis wrote:
On Fri, Oct 07, 2011 at 10:22:02PM +0200, Igor Stasenko wrote:
On 7 October 2011 21:07, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
On 7 October 2011 16:18, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote: > > On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote: > > > > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote: > >> > >> On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote: > > > > I need to ensure that OSPP runs on trunk as well as oscog branches, > > which means that updates to all those branches would be best. But > > I suspect it may be possible to adopt a strategy of loading with > > ioLoadFunction, and if this fails, try a direct reference to the > > global variable (though I don't know if Carbon will allow this?). > > > > > Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You lost me here. VM is evolving, things keep changing. Can you tell me any of the reason for keeping a freshly-built plugin to be compatible with 10-years old VMs? One could always use older version(s) of plugin which works with that VMs.. so, what is the problem?
Can you explain me , what is the benefits from staying compatible with dusty systems which, most probably, are used by 1% of users (if any)?
IMO, the purpose of plugin subsystem should be to serve as a way to customize the VM(s) for various kinds of distributions, but not as a way to ensure that something which was working 10 years ago, will keep working today without any changes.
It's about modularity. I maintain the three plugins for OSProcess as separate packages independent of any version of VMMaker. As with any such problem, maintaining the integrity os interfaces is the key to success.
The things which i proposing leaving you less to maintain. I do not see any conflict there.
I also care about the people who might use these packages, and often I do not even know who they are. ??If someone in Japan or China or a researcher at a university wants to build a VM with whatever flavor of Squeak or VMMaker, I want my packages to work without problems.
To my observations, this kind of "modularity" never worked without paying attention (testing & fixing) every time to new stuff which goes out. Every time something got broken, every update has some roughness we have to overcome.
Remember the numerous reports about OSProcess not working here and there, FFI here and there, Freetype and so on. As to me the experience actually showing completely opposite: using modules as a solution for compatibility are largely failing.
I also am lazy. I find that a little time and effort making sure the interfaces work saves a lot of my time later on. If I don't break something, I don't have to waste time later on explaining why it does not work. That is the same reason I write lots of tests and comments. It just saves a lot of time and excuses later on.
Dont wanna go into deep philosophical discussion, just wanna say that changing and improving are not synonyms to breaking. :)
That is the approach I have taken, and it has worked well for me so far.
But it doesn't works. Otherwise there will be no point for current discussion. Isn't?
Clever hacks, not matter how clever they are are still remain hacks. My proposal is to remove them order to have more consistent interaction between OSP and VM. I consider the current model having flaws, which needs to be fixed. And if fixing the flaw meaning to break it, yes lets break it. You cannot break something which was already broken before.
If you feel that this is important, then please go ahead and work on it. As long as the changes do not break things for other people (e.g. the standard interpreter VM), you have my personal commitment to add whatever may be necessary in OSPP. But I will not break compatibility for other VM projects, that is my only point.
Please proceed.
Hi Igor,
I added the necessary support to OSPP in VMConstruction-Plugins-OSProcessPlugin-dtl.31, and tested it on Linux with standard interpreter VM. All works as expected, so if you want to give it a try, the functions that must be exported are:
char **ioGetEnvVec(void); char **ioGetArgVec(void); int ioGetArgCount(void);
I don't have a Mac, so I'll leave it to you (or Esteban) to add the hooks in the platforms support code.
The OSPP code will use the global variables when exported functions are not available, and it is possible that this will cause problems with unreferenced variables on Carbon. I have no way of testing this, so if you try it and find problems please let me know.
Thanks, Dave. I added it to issue tracker to not forget. http://code.google.com/p/cog/issues/detail?id=63
HTH, Dave
But dave :) OSProcess is important just because we need interoperatibilty with the OS.
Stef
OSProcess is full of stuff that I put in just because I felt like doing it. To be honest, I never expected it to be widely used by other people. And I certainly was not attempting to rise to any high standards of software purity ;) Having said that, I do think that it is important to avoid putting platform-dependent things into the VM and image. What I choose to put into my own plugin or my own project is my business (and the development of OSProcess was an example of that), but I do not think it is good for "features" in OSProcess to creep into the core system.
Dave
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Esteban Lorenzano -
Igor Stasenko -
Ken G. Brown -
stephane ducasse