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