FT2Plugin stops working with latest version

>
> 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?

>
> 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.html
>
> And background is in this thread:
>  http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.html
>
> 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.html
>>
>> And background is in this thread:
>>  http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.html
>>
>> 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.html
> >
> > And background is in this thread:
> >  http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.html
> >
> > 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.html
>>>
>>> And background is in this thread:
>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.html
>>>
>>> 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.html
>>>
>>> And background is in this thread:
>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.html
>>>
>>> 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

> 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.html
> >>>
> >>> And background is in this thread:
> >>> http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.html
> >>>
> >>> 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:
>>
>> 1) 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.
>
>> 2) 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
>
>
>> 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.html
>> >>>
>> >>> And background is in this thread:
>> >>> http://lists.squeakfoundation.org/pipermail/vm-dev/2011-September/009291.html
>> >>>
>> >>> Dave
>> >>>
>

> On 4 October 2011 14:17, David T. Lewis <[hidden email]> wrote:
> > On Mon, Oct 03, 2011 at 11:54:58AM -0300, Esteban Lorenzano wrote:
> >
> >> 2) 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.

>
> On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
>> On 4 October 2011 14:17, David T. Lewis <[hidden email]> wrote:
>>> On Mon, Oct 03, 2011 at 11:54:58AM -0300, Esteban Lorenzano wrote:
>>>
>>>> 2) 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 4 October 2011 14:17, David T. Lewis <[hidden email]> 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.

>
> On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
>>
>> On 4 October 2011 14:17, David T. Lewis <[hidden email]> 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?
>

>  
> On 5 October 2011 14:15, David T. Lewis <[hidden email]> wrote:
> >
> > On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
> >>
> >> On 4 October 2011 14:17, David T. Lewis <[hidden email]> 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?
> >
>
> 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.

>
> On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
>>
>> On 5 October 2011 14:15, David T. Lewis <[hidden email]> wrote:
>>>
>>> On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
>>>>
>>>> On 4 October 2011 14:17, David T. Lewis <[hidden email]> 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?
>>>
>>
>> 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 04:15:20PM +0200, Igor Stasenko wrote:
>>
>> On 5 October 2011 14:15, David T. Lewis <[hidden email]> wrote:
>> >
>> > On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
>> >>
>> >> On 4 October 2011 14:17, David T. Lewis <[hidden email]> 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?
>> >
>>
>> 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.
>

> On 5 October 2011 16:41, David T. Lewis <[hidden email]> wrote:
>>
>> On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
>>>
>>> On 5 October 2011 14:15, David T. Lewis <[hidden email]> wrote:
>>> >
>>> > On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
>>> >>
>>> >> On 4 October 2011 14:17, David T. Lewis <[hidden email]> 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?
>>> >
>>>
>>> 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 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).
>

>  
> 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 <[hidden email]> wrote:
> > On 5 October 2011 16:41, David T. Lewis <[hidden email]> wrote:
> >>
> >> On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
> >>>
> >>> On 5 October 2011 14:15, David T. Lewis <[hidden email]> wrote:
> >>> >
> >>> > On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
> >>> >>
> >>> >> On 4 October 2011 14:17, David T. Lewis <[hidden email]> 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?
> >>> >
> >>>
> >>> 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.