- Pharo-dev - lists.pharo.org

Fwd: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: September 13, 2008 11:28:56 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Igor Stasenko <siguctua(a)gmail.com>, Michael Rueger <michael(a)impara.de > > > Subject: Re: [Pharo-project] Re: Building VM Freetype > Reply-To: johnmci(a)smalltalkconsulting.com > > Ok, first we statically loaded any *.dll into the freetype plugin > because we found earlier versions of os-x didn't have > the required version of freetype needed to support what we were > doing, also it was a complete mess on the linux side > with regard to what you would find there if you dynamically loaded > the plugin. > > the freetype plugin source code I have was loaded from http://source.impara.de/freetype > > I see the FT2Constants seems to be shared between the freetype base > package and the plugin package, so it appears you > need to load the base in order for the plugin to load. I'm not sure > anyone noticed this since you need to load the base in order > to test the plugin in any case. > > > On Sep 13, 2008, at 8:59 AM, StÃ©phane Ducasse wrote: > >> >> >> Begin forwarded message: >> >>> From: "Igor Stasenko" <siguctua(a)gmail.com> >>> Date: September 13, 2008 8:24:36 AM CEDT >>> To: "An open mailing list to discuss any topics related to an open- >>> source Smalltalk" <pharo-project(a)lists.gforge.inria.fr> >>> Subject: Re: [Pharo-project] Re: Building VM Freetype >>> Reply-To: An open mailing list to discuss any topics related to an >>> open-source Smalltalk <pharo-project(a)lists.gforge.inria.fr> >>> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I hope other will answer but I thought that we could have a pluggin >>>> and bundle in the deployed packages. >>>> The idea for pharo is to have a similar setup than seaside a one >>>> click app >>>> so the >>>> vm and its plugin would be there (but may be the plugin should >>>> not be in the >>>> image). >>> >>> Plugin is built-in in the VM. But freetype library is coming as >>> separate dynamic library. >>> Is this ok? >>> >>> There can be another option, but it would require to change the >>> plugin >>> code - to not link VM with import lib, but to load freetype.dll on >>> demand. The plugin can simply check if this .dll available and start >>> using it, or if not - fail to initialize, telling the system that >>> plugin functionality is not available. >>> >>>> >>>> Mike or john? On sophie how did you manage that the freetype >>>> bundle could >>>> not be present? >>>> >>> >>> Actually, to build a plugin, you need just headers + freetype.def >>> file >>> which then can be used to >>> create the imports library from it. >>> Building a freetype.dll can be completely separate process. >>> >>> I can remove dependency from freetype.lib, and leave only a >>> freetype.def and create import lib by own, when making VM. >>> But this is not safe, because now you must guarantee that you using >>> correct .dll. (well, you need to guarantee it in either case). >>> >>>> If I remember correctly some people on squeak have been >>>> recompiling it for >>>> 64 bits >>>> >>>>> I done with it. >>>>> The resulting VM will not start without freetype.dll. >>>>> Should i link it statically? But then you should hone their >>>>> license >>>>> stuff... >>>>> >>>>> Also, building freetype on windoze impossible using gnutools which >>>>> used for building VM. >>>>> It's make simply can't understand some things, which i assume >>>>> appear >>>>> in later make versions. >>>>> So, i building freetype using my msys/mingw environment, and then >>>>> simply producing >>>>> - freetype.lib (imports library) >>>>> - freetype.dll >>>>> >>>>> or maybe, i wrong, maybe it can be built using gnutools, but this >>>>> would require too much voodoo dancing. >>>>> it would be cool to make it cleanly build w/o manual work, but >>>>> i'm not >>>>> high expert in makefiles black voodoo. >>>>> >>>>> Okay, who wants the VM? And where i can put the stuff + >>>>> instructions + >>>>> blablabla? >>>> >>>> You can use the code google page for that. >>>> >>>> Stef >>>>> >>>>> >>>>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>>>> >>>>>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>>>>> >>>>>>> As always, things not working out of the box. >>>>>>> >>>>>>> - VM builds from unzipped VM sources OK >>>>>>> - but for building with VMMaker generated sources, had to fix >>>>>>> 'gnuify' >>>>>>> file to make a clean build >>>>>>> >>>>>>> i dreaming to build vm straight from squeak, without horrid >>>>>>> makefiles. >>>>>>> I heard that Keith did a 'Bob' tool which can be used as a >>>>>>> kind of >>>>>>> make utility. >>>>>>> But i think, to fully replace makefiles, it needs an >>>>>>> OSProcessPlugin >>>>>>> to be able to interact with OS/shell. >>>>>>> >>>>>> >>>>>> Next step, tried to load freetype plugin.... >>>>>> http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz >>>>>> http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz >>>>>> >>>>>> and guess what? YES! It can't be loaded! :) >>>>>> >>>>>> MC complains about following: >>>>>> >>>>>> This package depends on the following classes: >>>>>> FT2Constants >>>>>> >>>>>> The FT2Constants is the pool dictionary used by plugin. But not >>>>>> defined within package. >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> <fonts.jpg>_______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > >

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

On Sep 13, 2008, at 10:25 AM, Michael Rueger wrote: > Igor Stasenko wrote: >> ohh... a small correction. >> Not #hasDisplay, but #hasDisplays. >> Which is conceptually VERY important! > > And Ffenestri provides support for that. We actually have something > running (sort of ;-) ) that opens multiple native windows based on > ffenestri. > > I'm all for factoring out the input and display stuff into plugins, > ffenestri is IMHO a good base for that. You can still use bitblt or > balloon for display, so you don't necessarily have to rely on > external libraries as GTK does. So this is good. > > > IIRC the newer VMs already delay opening the window and only do it > on first access, so a first step in the right direction. > > But this, again, raises the question of VM building ;-) yes! > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> this sounds interesting. >> But I think that this is important to still be able to not rely on >> external >> libraries when you want. >> so what is the exact difference between having it for free or >> optional >> - ? that you need to implement the primitive on platform >> where you do >> not need? >> - ? that the system is not layered in consequence? > > I think both. Having it 'for free' leads developers to think that they > can use it anytime, anywhere, like in String>>showProgressBar. Which > from my POV is complete stupidity. And now just check different > mailing lists and count complains about unable to getting rid of such > 'free' uses, like asking for user input or showing warnings in > headless image :) sure this is something that we should fix from an infrastructural point of view using a notification system. At the end we should not that PopUpMenu everywhere but only in one place in the Plafform code. > I don't want it 'for free', but instead, i want that language should > ask for it, and then, if VM could provide it - start using it. > Instead of having 'position & size & fullscreen flag' hanging around > in VM -obviously, with good design, this should be completely at > language side. > >> Did you check the work made around "ffnestraria" ? > > Surely, this could be taken as a initial base for new plugin. > But, as it reads on http://wiki.squeak.org/squeak/3862 : > > This architecture is for the lowest levels of the system, the virtual > machine and dungeon levels of the image. NO support yet exists for > Morphic since there is a vast amount of code and class cleanup needed. Yes I think that we should go slowly but removing a lot of morphic cruft will help. > > Tweak has been our sole higher level target thus far since it is > somewhat less broken, not to mention the target of our main project > remit. > > Since Pharo now actively adressing different Morphic issues, it would > be good for those who doing it (hello Gary) to keep this idea in mind. Yes > On embedded systems you don't have a 'window', you just have a > display. But on PCs, operating system can provide you many windows , > which can play role as displays. What is bad, that at language side > you don't have a notion about this, as well as it don't have notion > whether keys/mouse are present or not. > I think this should be represented by concrete classes, which can > answer things like: > - hasKeyboard(s) > - hasMouse(s) > - hasDisplay > - hasWindowing > > for instance, on windoze, you can use a real display using two > approached: > - one can prefer using a display (which covers a whole area of > screen), and should be allowed to control its resolution (if > possible). > - another one can rather use windowing and treat separate native > windows as separate displays. > >> Then what is important is to have good more then proof of concepts. >> This is sometimes that we would be interested in. >> >> Stef >> > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/13 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: >> >> ohh... a small correction. >> Not #hasDisplay, but #hasDisplays. >> >> Which is conceptually VERY important! > > And Ffenestri provides support for that. We actually have something running > (sort of ;-) ) that opens multiple native windows based on ffenestri. > > I'm all for factoring out the input and display stuff into plugins, > ffenestri is IMHO a good base for that. You can still use bitblt or balloon > for display, so you don't necessarily have to rely on external libraries as > GTK does. > Right, a good factored code should rely on a basic OS functionality provided. There is no need in extra dependencies on that. > IIRC the newer VMs already delay opening the window and only do it on first > access, so a first step in the right direction. > Yeah, but i would prefer to receive a direct instruction from language side to open window/display. And if any code tries to talk or draw things w/o asking anyone if it possible at all, then it should be beaten by exceptions. > But this, again, raises the question of VM building ;-) > Well, i think most of work is on language side, not in VM. First we should consider a model, which can be employed to represent an abstract layer for display and user input. Then, based on it, we can determine a set of primitives required to support such model. > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Michael Rueger

Igor Stasenko wrote: > ohh... a small correction. > Not #hasDisplay, but #hasDisplays. > > Which is conceptually VERY important! And Ffenestri provides support for that. We actually have something running (sort of ;-) ) that opens multiple native windows based on ffenestri. I'm all for factoring out the input and display stuff into plugins, ffenestri is IMHO a good base for that. You can still use bitblt or balloon for display, so you don't necessarily have to rely on external libraries as GTK does. IIRC the newer VMs already delay opening the window and only do it on first access, so a first step in the right direction. But this, again, raises the question of VM building ;-) Michael

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Alexandre Bergel

Hi Igor, I like your idea very much. This is what a modular should be. This is exactly the way Squeak-GTK is taking. I am waiting for Gwenael to have a version that runs on MacOSX... Cheers, Alexandre On 13 Sep 2008, at 08:58, Igor Stasenko wrote: > Hello, > > i'd like to discuss with you this quite radical idea. > I , in particular, not happy that windowing in squeak VM is mandatory. > Sure, you can run VM with -headless (or whatever), but this actually > not solving anything, since > VM still in much of control, how to deal with squeak window and how to > manage messages etc. > > What i would like to see, is to completely detach windowing > functionality into a separate VM plugin, making sure that: > a) VM can be built w/o this plugin > b) a language side is in total control to decide whether create and > use window & display or not. > > This would require to deprecate some of 'blue book' primitives, which > coming as built-in VM features , such as: > - displayBits & friends > - fullDisplayUpdate > - keyboard & mouse event handling > > The point is, that squeak grew out on many platforms and embedded > devices. Some of them don't have a usual input devices, like keyboard > & mouse, so it is completely pointless to require VM to support I/O > with these devices as mandatory option. > Same for display. I would be happy to have full control at language > side whether i need display or not , instead of having it 'for free' > from a start and then using workarounds to not show/use it using > command line (while language side still thinks its present). > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by Alexandre Bergel

>> Plugin is built-in in the VM. But freetype library is coming as >> separate dynamic library. >> Is this ok? >> >> There can be another option, but it would require to change the >> plugin >> code - to not link VM with import lib, but to load freetype.dll on >> demand. The plugin can simply check if this .dll available and start >> using it, or if not - fail to initialize, telling the system that >> plugin functionality is not available. > > I'm convinced that I'm not an expert here. I have the impression > that the second > option is better, May be we should wait for other feedback on the > idea. I do not think Pharo's users will mind to use a different VM or add a .dll beside their VM. Feel free to chose the simplest way for you, and do not hesitate to ask for feedback. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

ohh... a small correction. Not #hasDisplay, but #hasDisplays. Which is conceptually VERY important! -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this sounds interesting. > But I think that this is important to still be able to not rely on external > libraries when you want. > so what is the exact difference between having it for free or optional > - ? that you need to implement the primitive on platform where you do > not need? > - ? that the system is not layered in consequence? I think both. Having it 'for free' leads developers to think that they can use it anytime, anywhere, like in String>>showProgressBar. Which from my POV is complete stupidity. And now just check different mailing lists and count complains about unable to getting rid of such 'free' uses, like asking for user input or showing warnings in headless image :) I don't want it 'for free', but instead, i want that language should ask for it, and then, if VM could provide it - start using it. Instead of having 'position & size & fullscreen flag' hanging around in VM -obviously, with good design, this should be completely at language side. > Did you check the work made around "ffnestraria" ? Surely, this could be taken as a initial base for new plugin. But, as it reads on http://wiki.squeak.org/squeak/3862 : This architecture is for the lowest levels of the system, the virtual machine and dungeon levels of the image. NO support yet exists for Morphic since there is a vast amount of code and class cleanup needed. Tweak has been our sole higher level target thus far since it is somewhat less broken, not to mention the target of our main project remit. Since Pharo now actively adressing different Morphic issues, it would be good for those who doing it (hello Gary) to keep this idea in mind. On embedded systems you don't have a 'window', you just have a display. But on PCs, operating system can provide you many windows , which can play role as displays. What is bad, that at language side you don't have a notion about this, as well as it don't have notion whether keys/mouse are present or not. I think this should be represented by concrete classes, which can answer things like: - hasKeyboard(s) - hasMouse(s) - hasDisplay - hasWindowing for instance, on windoze, you can use a real display using two approached: - one can prefer using a display (which covers a whole area of screen), and should be allowed to control its resolution (if possible). - another one can rather use windowing and treat separate native windows as separate displays. > Then what is important is to have good more then proof of concepts. > This is sometimes that we would be interested in. > > Stef > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

done I added you as admin. You will see that the interface is crap but... Stef On Sep 13, 2008, at 9:06 AM, Igor Stasenko wrote: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Sorry that you refer to just instruction. >> Then I would suggest that you register to the fgorge.inria.fr >> use team ADAM when creating yur account >> once you have done that I will add you to the pharo project >> then we will be able to use the svn and >> the uploads >> > done. > login: sig >> Stef >> >> >> On Sep 13, 2008, at 8:36 AM, Igor Stasenko wrote: >> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>>>> Okay, who wants the VM? And where i can put the stuff + >>>>> instructions + >>>>> blablabla? >>>> >>>> You can use the code google page for that. >>> >>> Can you be more specific? >>> After reading through http://code.google.com/p/pharo/ >>> can't find any directions, where i can put a pre-built VM, or do any >>> upload. I doubt that pharo inbox at squeaksource is appropriate >>> place >>> for VM binaries. >>> >>>> >>>> Stef >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 13, 2008