2008/9/9 Adrian Lienhard <[EMAIL PROTECTED]>: > > On Sep 9, 2008, at 17:43 , Igor Stasenko wrote: > >> 2008/9/9 Adrian Lienhard <[EMAIL PROTECTED]>: >>> >>> Welcome, Igor! >>> >>> Would you also be interested to help maintain the VM? Recently on this >>> list >>> we've discussed whether it would make sense to have our own Pharo VM. For >>> instance, to have the Freetype Plugin by default, but maybe also for >>> larger >>> improvements like the ones that come from Eliot. >>> >> >> Making a Freetype plugin to be compiled as internal one is not a good >> reason to start VM branch :) > > Can you elaborate on why not? The background is that we really want to have > better fonts. One possibility is the Freetype work of Andrew Tween, which > needs the FT2Plugin and the modified BitBlt plugin for subpixel antialiasing > to work well. And this solution makes only sense if people can download a VM > for their platform that includes this support by default. >
Well, BitBlt code is , thanks God, platform independent. So you can easily backport changes into any VMMaker package. As for FT2Plugin , as long as it works well and maintained by its developer , i don't see any problem with it. I can build VM for win32, and (maybe) for Linux. But i can't do this for Macs, since i don't have one :) For maintaining a healthy VM , one need to setup all 3 platforms to be able to build & test VM on it. Otherwise its not makes any sense, because once we have multiple maintainers, the process starts to be complicated and will require much more time investments & coordination to ensure that some fix or improvement will be delivered fast on all platforms well tested and polished. :) > Adrian > >> And Eliot's improvements and his work will sooner or later lead to new >> , better thing, which then could replace current VM. >> So, i think it would be better to help Eliot with this process by >> proposing/discussing changes instead of developing separate branch. >> Of course, making own branch will give you freedom in directions where >> to go, like dropping compatibility, removing unwanted things etc etc. >> But then, the farther you go with it, merging changes will be harder >> and harder (if possible at all). >>> >>> From this point, i think that its better to keep one VM and work together >>> on it. >> >> It would be easier to maintain things, if VM were written completely >> in single language (smalltalk or C), but currently this is not so >> elegant. And putting groundbreaking changes in smalltalk part most >> probably will lead to changes in C part, which is very rigid part of >> VM and most hard maintain , because a single structural change can >> lead to multiple changes in code for separate platforms. And then you >> need to test them, on at least all major platforms, not speaking about >> different ports to minor ones. This is a really complicated and you >> can lost there forever :) >> >> >>> Cheers, >>> Adrian >>> >>> On Sep 9, 2008, at 05:05 , Igor Stasenko wrote: >>> >>>> I just subscribed and want to say hello to this list. :) >>>> >>>> At ESUG we discussed with Stephane and Markus some things in Squeak >>>> (and consequently in Pharo), which really need an overlook and better >>>> implementation. >>>> Stephane asked me, to think about overlooking Processes and >>>> concurrency in its current state. >>>> First, i must say that it is very fragile part of system because most >>>> things written w/o concurrency in mind. Last year i seen many issues >>>> related to concurrency: Semaphore , Delay, Process, Scheduler. Some of >>>> them resolved, some of them resolved in an ugly and hackish way - >>>> mostly as workarounds of lacking critical VM primitives which should >>>> guarantee atomicity for different purposes, and some of them is not >>>> resolved at all. >>>> >>>> Some things, which i noted and which i like/not like, can be found in >>>> squeak-dev list. But i will repeat them here, in single place: >>>> - Process should assume that it is running in ideal environment (e.g. >>>> in parallel to another processes w/o any preemption). Every bit of >>>> code, which requires synchronization should be based/take into account >>>> this assumption. >>>> >>>> a process should have three discrete states: >>>> - suspended - when initially created. >>>> - running - when you invoke resume. >>>> - terminated - when process no longer running and can't be resumed. >>>> >>>> It is wrong to consider a process which waiting on semaphore signal as >>>> suspended process. >>>> (see http://bugs.squeak.org/view.php?id=6822). >>>> Process which waits on semaphore is actually performing an action, >>>> while , by definition, a suspended process can't perform any action. >>>> >>>> Concerning process termination, it is also a can of worms to deal with: >>>> >>>> - process termination means stop doing anything in requested process, >>>> but this going into conflict with exception handling mechanism. >>>> The conflict comes from two things like #ensure: and #ifCurtailed: . >>>> Such mechanisms used to ensure that some code will have chance to run >>>> under any circumstances, regardless of the state of computation. It is >>>> interesting, where such code should run? In a process which initiated >>>> a terminate request, or in process which needs to be terminated by >>>> request. Most valid, of course - to run them in a terminating process. >>>> The problem, however, how to achieve that. >>>> >>>> Someone suggested to throw an exception, like >>>> ProcessTerminateException to indicate that the given process is going >>>> to be terminated. >>>> Such thing is also going into conflict with different points of view: >>>> a Process termination is usual functionality, provided for use, so why >>>> it should be considered as exceptional? >>>> >>>> Maybe, to solve the conflicts, and avoid using exceptions in an >>>> arguable way, it would be better to add support of process termination >>>> notification. So, each time process is going to terminate, it can >>>> notify all interesting parties of such event. >>>> Then, instead of using #ensure: to free critical system resources, one >>>> could use notification. >>>> >>>> As you can see, there is more questions than answers :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
