FT2Plugin stops working with latest version

>
> 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 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 <[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.
>

>  
> On 5 October 2011 17:18, David T. Lewis <[hidden email]> 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
>

>
>
> On Wed, Oct 05, 2011 at 05:22:40PM +0200, Igor Stasenko wrote:
>>
>> On 5 October 2011 17:18, David T. Lewis <[hidden email]> 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.
>

>  
> On 6 October 2011 04:19, David T. Lewis <[hidden email]> wrote:
> >
> >
> > On Wed, Oct 05, 2011 at 05:22:40PM +0200, Igor Stasenko wrote:
> >>
> >> On 5 October 2011 17:18, David T. Lewis <[hidden email]> 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, 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 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?
>

>
> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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.

> On Thu, Oct 06, 2011 at 05:00:12AM +0300, Igor Stasenko wrote:
> >  
> > On 6 October 2011 04:19, David T. Lewis <[hidden email]> wrote:
> > >
> > >
> > > On Wed, Oct 05, 2011 at 05:22:40PM +0200, Igor Stasenko wrote:
> > >>
> > >> On 5 October 2011 17:18, David T. Lewis <[hidden email]> 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.
>

>
> On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
>>
>> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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?).
>

>  
> On 7 October 2011 01:39, David T. Lewis <[hidden email]> wrote:
> >
> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
> >>
> >> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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?

>
> On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
>>
>> On 7 October 2011 01:39, David T. Lewis <[hidden email]> wrote:
>> >
>> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
>> >>
>> >> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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!).
>

>  
> On 7 October 2011 16:18, David T. Lewis <[hidden email]> wrote:
> >
> > On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
> >>
> >> On 7 October 2011 01:39, David T. Lewis <[hidden email]> wrote:
> >> >
> >> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
> >> >>
> >> >> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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.
>

>
> On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
>>
>> On 7 October 2011 16:18, David T. Lewis <[hidden email]> wrote:
>> >
>> > On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
>> >>
>> >> On 7 October 2011 01:39, David T. Lewis <[hidden email]> wrote:
>> >> >
>> >> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
>> >> >>
>> >> >> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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.
>

>
> On 7 October 2011 21:07, David T. Lewis <[hidden email]> wrote:
> >
> > On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
> >>
> >> On 7 October 2011 16:18, David T. Lewis <[hidden email]> wrote:
> >> >
> >> > On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
> >> >>
> >> >> On 7 October 2011 01:39, David T. Lewis <[hidden email]> wrote:
> >> >> >
> >> >> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
> >> >> >>
> >> >> >> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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.

>  
> On Fri, Oct 07, 2011 at 10:22:02PM +0200, Igor Stasenko wrote:
> >
> > On 7 October 2011 21:07, David T. Lewis <[hidden email]> wrote:
> > >
> > > On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
> > >>
> > >> On 7 October 2011 16:18, David T. Lewis <[hidden email]> wrote:
> > >> >
> > >> > On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
> > >> >>
> > >> >> On 7 October 2011 01:39, David T. Lewis <[hidden email]> wrote:
> > >> >> >
> > >> >> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
> > >> >> >>
> > >> >> >> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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.
>

>
> 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 <[hidden email]> wrote:
>> > >
>> > > On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
>> > >>
>> > >> On 7 October 2011 16:18, David T. Lewis <[hidden email]> wrote:
>> > >> >
>> > >> > On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
>> > >> >>
>> > >> >> On 7 October 2011 01:39, David T. Lewis <[hidden email]> wrote:
>> > >> >> >
>> > >> >> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
>> > >> >> >>
>> > >> >> >> On 6 October 2011 14:11, David T. Lewis <[hidden email]> 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.
>