[Pharo-project] Hello everyone!
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.
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. 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/9/9 Adrian Lienhard <adi@netstyle.ch>:
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 :) 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Sep 9, 2008, at 17:43 , Igor Stasenko wrote:
2008/9/9 Adrian Lienhard <adi@netstyle.ch>:
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. 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/9/9 Adrian Lienhard <adi@netstyle.ch>:
On Sep 9, 2008, at 17:43 , Igor Stasenko wrote:
2008/9/9 Adrian Lienhard <adi@netstyle.ch>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor for the concurrency may be something good would be to start writing another library. instead of fixing the current one. I know that when we rewrite with get a lot of bugs but at least prototyping something would be useful. I'm really nul in concurrent programming but I know it should be good. Stef On Sep 9, 2008, at 9:41 AM, Adrian Lienhard wrote:
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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sep 9, 2008, at 5:43 PM, Igor Stasenko wrote:
2008/9/9 Adrian Lienhard <adi@netstyle.ch>:
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 :) 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.
yes this is what marcus will do.
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).
I think that what adrian wanted to say is that this is stupid not to integrate well freetype just because we cannot recompile the vm.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sep 9, 2008, at 6:49 PM, Adrian Lienhard wrote:
On Sep 9, 2008, at 17:43 , Igor Stasenko wrote:
2008/9/9 Adrian Lienhard <adi@netstyle.ch>:
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.
Yes we need that.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. :)
so how can we progress on this front. Bryce proposed to build a vm for linux or windows. I imagine that john could help for the mac one. Else we can also try. Mathieu recompiles his vm regularly Stef
2008/9/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Igor
for the concurrency may be something good would be to start writing another library. instead of fixing the current one. I know that when we rewrite with get a lot of bugs but at least prototyping something would be useful. I'm really nul in concurrent programming but I know it should be good.
Well, that's is really tough task, but quite interesting. If we're free to change VM to make better support of atomic operations, like task switching, semaphore signaling etc etc, then it is really worth to do. But first , i'd like to hear a request for features from people. I having own vision, but want to hear your opinion , also maybe i don't see the whole picture, so please provide any info or issues you want to be fixed or features you want to be added or replace old ones.
Stef
-- Best regards, Igor Stasenko AKA sig.
2008/9/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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. :)
so how can we progress on this front. Bryce proposed to build a vm for linux or windows. I imagine that john could help for the mac one. Else we can also try. Mathieu recompiles his vm regularly
Well, as i said, putting FreeType into VM is simple thing. But maintaining a code base or regular basis is completely different thing. I'm not sure i have enough spare time to do this now. First, because i'm busy with Hydra VM. Second , I think you are aware, that Cog & Hydra will merge in future. Before this happens, i have little interest in supporting old-fashioned VMs :) I planning to do a major refactoring in Hydra, after which , an Interpreter/ObjectMemory can be simulated in image. But this will have a major impact on backward compatibility. But for minor changes, like in some plugins, it not hurts a lot. I think that, if you planning to maintain own VM, then i'll advice to split VMMaker package on two separate parts: - VM core - all plugins Because VM is a big code bloat , which is hard to manipulate with. Also, it would be good to have a common code repository, and separate tracker of bugs and fixes for VM/plugins, so it will make an integration easier for all interesting parties.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Well, as i said, putting FreeType into VM is simple thing. But maintaining a code base or regular basis is completely different thing. I'm not sure i have enough spare time to do this now. First, because i'm busy with Hydra VM. Second , I think you are aware, that Cog & Hydra will merge in future. Before this happens, i have little interest in supporting old-fashioned VMs :)
I planning to do a major refactoring in Hydra, after which , an Interpreter/ObjectMemory can be simulated in image. But this will have a major impact on backward compatibility.
But for minor changes, like in some plugins, it not hurts a lot. I think that, if you planning to maintain own VM, then i'll advice to split VMMaker package on two separate parts: - VM core - all plugins
Because VM is a big code bloat , which is hard to manipulate with.
Also, it would be good to have a common code repository, and separate tracker of bugs and fixes for VM/plugins, so it will make an integration easier for all interesting parties.
could you push this idea to the VM maintainers or start to do it? We are talking abut that since years. I still do not understand I thought that the svn of the vm code was such common code repository?
2008/9/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Well, as i said, putting FreeType into VM is simple thing. But maintaining a code base or regular basis is completely different thing. I'm not sure i have enough spare time to do this now. First, because i'm busy with Hydra VM. Second , I think you are aware, that Cog & Hydra will merge in future. Before this happens, i have little interest in supporting old-fashioned VMs :)
I planning to do a major refactoring in Hydra, after which , an Interpreter/ObjectMemory can be simulated in image. But this will have a major impact on backward compatibility.
But for minor changes, like in some plugins, it not hurts a lot. I think that, if you planning to maintain own VM, then i'll advice to split VMMaker package on two separate parts: - VM core - all plugins
Because VM is a big code bloat , which is hard to manipulate with.
Also, it would be good to have a common code repository, and separate tracker of bugs and fixes for VM/plugins, so it will make an integration easier for all interesting parties.
could you push this idea to the VM maintainers or start to do it?
yes i could, but do you think that i have a chance to be heard and my point to be accepted? :)
We are talking abut that since years. I still do not understand I thought that the svn of the vm code was such common code repository?
I tried to raise this topic on board meeting, concerning status of VM-dev group and the answer was like: - we already have things set up, and each maintainer know/doing things well. I'm not sure about current status, but i keep feeling that VM maintainers efforts dissipating due to lack of communication/collaboration. Maybe it is because i'm relatively new, and missing info about how things was set up long ago, before i came in, maybe people really collaborate behind the scenes, i don't know. What i really sure about, is that , it will not hurt to call for a status (re)clarification to know who doing what and how things working.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
yes i could, but do you think that i have a chance to be heard and my point to be accepted? :)
We are talking abut that since years. I still do not understand I thought that the svn of the vm code was such common code repository?
I tried to raise this topic on board meeting, concerning status of VM-dev group and the answer was like: - we already have things set up, and each maintainer know/doing things well. I'm not sure about current status, but i keep feeling that VM maintainers efforts dissipating due to lack of communication/collaboration.
No this is a question of power.... :)
Maybe it is because i'm relatively new, and missing info about how things was set up long ago, before i came in, maybe people really collaborate behind the scenes, i don't know.
:)
What i really sure about, is that , it will not hurt to call for a status (re)clarification to know who doing what and how things working.
Yes please do. I would suggest to really work with eliot and get such a structure started. for Cog and hydra first and agglomerate slowly the rest This is years that mike is suggesting to have a real repository for VMs Stef
Igor, Do you have a mailing list on Hydra? I think it is important to initiate the creation of a community around this idea. You may use googlecode for that. Cheers, Alexandre On 10 Sep 2008, at 10:44, Igor Stasenko wrote:
2008/9/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Well, as i said, putting FreeType into VM is simple thing. But maintaining a code base or regular basis is completely different thing. I'm not sure i have enough spare time to do this now. First, because i'm busy with Hydra VM. Second , I think you are aware, that Cog & Hydra will merge in future. Before this happens, i have little interest in supporting old-fashioned VMs :)
I planning to do a major refactoring in Hydra, after which , an Interpreter/ObjectMemory can be simulated in image. But this will have a major impact on backward compatibility.
But for minor changes, like in some plugins, it not hurts a lot. I think that, if you planning to maintain own VM, then i'll advice to split VMMaker package on two separate parts: - VM core - all plugins
Because VM is a big code bloat , which is hard to manipulate with.
Also, it would be good to have a common code repository, and separate tracker of bugs and fixes for VM/plugins, so it will make an integration easier for all interesting parties.
could you push this idea to the VM maintainers or start to do it?
yes i could, but do you think that i have a chance to be heard and my point to be accepted? :)
We are talking abut that since years. I still do not understand I thought that the svn of the vm code was such common code repository?
I tried to raise this topic on board meeting, concerning status of VM-dev group and the answer was like: - we already have things set up, and each maintainer know/doing things well. I'm not sure about current status, but i keep feeling that VM maintainers efforts dissipating due to lack of communication/collaboration. Maybe it is because i'm relatively new, and missing info about how things was set up long ago, before i came in, maybe people really collaborate behind the scenes, i don't know. What i really sure about, is that , it will not hurt to call for a status (re)clarification to know who doing what and how things working.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2008/9/10 Alexandre Bergel <alexandre@bergel.eu>:
Igor,
Do you have a mailing list on Hydra? I think it is important to initiate the creation of a community around this idea. You may use googlecode for that.
there is not much activity in this area, worth creating new mailing list. Currently, i using squeak-dev or vm-dev mailing list for news & announcements. I asked community, maybe it is OT, but nobody complained about it, instead they want it there. :)
Cheers, Alexandre
On 10 Sep 2008, at 10:44, Igor Stasenko wrote:
2008/9/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Well, as i said, putting FreeType into VM is simple thing. But maintaining a code base or regular basis is completely different thing. I'm not sure i have enough spare time to do this now. First, because i'm busy with Hydra VM. Second , I think you are aware, that Cog & Hydra will merge in future. Before this happens, i have little interest in supporting old-fashioned VMs :)
I planning to do a major refactoring in Hydra, after which , an Interpreter/ObjectMemory can be simulated in image. But this will have a major impact on backward compatibility.
But for minor changes, like in some plugins, it not hurts a lot. I think that, if you planning to maintain own VM, then i'll advice to split VMMaker package on two separate parts: - VM core - all plugins
Because VM is a big code bloat , which is hard to manipulate with.
Also, it would be good to have a common code repository, and separate tracker of bugs and fixes for VM/plugins, so it will make an integration easier for all interesting parties.
could you push this idea to the VM maintainers or start to do it?
yes i could, but do you think that i have a chance to be heard and my point to be accepted? :)
We are talking abut that since years. I still do not understand I thought that the svn of the vm code was such common code repository?
I tried to raise this topic on board meeting, concerning status of VM-dev group and the answer was like: - we already have things set up, and each maintainer know/doing things well. I'm not sure about current status, but i keep feeling that VM maintainers efforts dissipating due to lack of communication/collaboration. Maybe it is because i'm relatively new, and missing info about how things was set up long ago, before i came in, maybe people really collaborate behind the scenes, i don't know. What i really sure about, is that , it will not hurt to call for a status (re)clarification to know who doing what and how things working.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
yes keep it there we have too much mailing-lists So can you do a unix/windows VM with the freeType pluging? Stef On Sep 11, 2008, at 12:03 AM, Igor Stasenko wrote:
2008/9/10 Alexandre Bergel <alexandre@bergel.eu>:
Igor,
Do you have a mailing list on Hydra? I think it is important to initiate the creation of a community around this idea. You may use googlecode for that.
there is not much activity in this area, worth creating new mailing list. Currently, i using squeak-dev or vm-dev mailing list for news & announcements. I asked community, maybe it is OT, but nobody complained about it, instead they want it there. :)
Cheers, Alexandre
On 10 Sep 2008, at 10:44, Igor Stasenko wrote:
2008/9/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Well, as i said, putting FreeType into VM is simple thing. But maintaining a code base or regular basis is completely different thing. I'm not sure i have enough spare time to do this now. First, because i'm busy with Hydra VM. Second , I think you are aware, that Cog & Hydra will merge in future. Before this happens, i have little interest in supporting old-fashioned VMs :)
I planning to do a major refactoring in Hydra, after which , an Interpreter/ObjectMemory can be simulated in image. But this will have a major impact on backward compatibility.
But for minor changes, like in some plugins, it not hurts a lot. I think that, if you planning to maintain own VM, then i'll advice to split VMMaker package on two separate parts: - VM core - all plugins
Because VM is a big code bloat , which is hard to manipulate with.
Also, it would be good to have a common code repository, and separate tracker of bugs and fixes for VM/plugins, so it will make an integration easier for all interesting parties.
could you push this idea to the VM maintainers or start to do it?
yes i could, but do you think that i have a chance to be heard and my point to be accepted? :)
We are talking abut that since years. I still do not understand I thought that the svn of the vm code was such common code repository?
I tried to raise this topic on board meeting, concerning status of VM-dev group and the answer was like: - we already have things set up, and each maintainer know/doing things well. I'm not sure about current status, but i keep feeling that VM maintainers efforts dissipating due to lack of communication/collaboration. Maybe it is because i'm relatively new, and missing info about how things was set up long ago, before i came in, maybe people really collaborate behind the scenes, i don't know. What i really sure about, is that , it will not hurt to call for a status (re)clarification to know who doing what and how things working.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/9/11 Stéphane Ducasse <stephane.ducasse@inria.fr>:
yes keep it there we have too much mailing-lists
So can you do a unix/windows VM with the freeType pluging?
Sure i can, just give me details which/where i should take VMMaker & platform sources & plugin.
Stef
On Sep 11, 2008, at 12:03 AM, Igor Stasenko wrote:
2008/9/10 Alexandre Bergel <alexandre@bergel.eu>:
Igor,
Do you have a mailing list on Hydra? I think it is important to initiate the creation of a community around this idea. You may use googlecode for that.
there is not much activity in this area, worth creating new mailing list. Currently, i using squeak-dev or vm-dev mailing list for news & announcements. I asked community, maybe it is OT, but nobody complained about it, instead they want it there. :)
Cheers, Alexandre
On 10 Sep 2008, at 10:44, Igor Stasenko wrote:
2008/9/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Well, as i said, putting FreeType into VM is simple thing. But maintaining a code base or regular basis is completely different thing. I'm not sure i have enough spare time to do this now. First, because i'm busy with Hydra VM. Second , I think you are aware, that Cog & Hydra will merge in future. Before this happens, i have little interest in supporting old-fashioned VMs :)
I planning to do a major refactoring in Hydra, after which , an Interpreter/ObjectMemory can be simulated in image. But this will have a major impact on backward compatibility.
But for minor changes, like in some plugins, it not hurts a lot. I think that, if you planning to maintain own VM, then i'll advice to split VMMaker package on two separate parts: - VM core - all plugins
Because VM is a big code bloat , which is hard to manipulate with.
Also, it would be good to have a common code repository, and separate tracker of bugs and fixes for VM/plugins, so it will make an integration easier for all interesting parties.
could you push this idea to the VM maintainers or start to do it?
yes i could, but do you think that i have a chance to be heard and my point to be accepted? :)
We are talking abut that since years. I still do not understand I thought that the svn of the vm code was such common code repository?
I tried to raise this topic on board meeting, concerning status of VM-dev group and the answer was like: - we already have things set up, and each maintainer know/doing things well. I'm not sure about current status, but i keep feeling that VM maintainers efforts dissipating due to lack of communication/collaboration. Maybe it is because i'm relatively new, and missing info about how things was set up long ago, before i came in, maybe people really collaborate behind the scenes, i don't know. What i really sure about, is that , it will not hurt to call for a status (re)clarification to know who doing what and how things working.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I'm confused you do not use VMMaker for Hydra?
yes keep it there we have too much mailing-lists
So can you do a unix/windows VM with the freeType pluging?
Sure i can, just give me details which/where i should take VMMaker & platform sources & plugin.
I thought that all this information was in the VM repository. Stef
2008/9/11 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I'm confused you do not use VMMaker for Hydra?
yes keep it there we have too much mailing-lists
So can you do a unix/windows VM with the freeType pluging?
Sure i can, just give me details which/where i should take VMMaker & platform sources & plugin.
I thought that all this information was in the VM repository.
Can you point me to that VM repository? VMMaker are available on: - squeakmap, - http://www.squeaksource.com/VMMaker.html - http://source.squeakfoundation.org (now is empty ,strange) The VM sources, are available on squeakvm.org SVN. Is this places correct? Also, where i can get freetype plugin and its platform sources?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Hi, "Igor Stasenko" <siguctua@gmail.com> wrote in message news:4a5f5f320809111213v2eec6200te2dcab47f03f6a58@mail.gmail.com...
2008/9/11 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I'm confused you do not use VMMaker for Hydra?
yes keep it there we have too much mailing-lists
So can you do a unix/windows VM with the freeType pluging?
Sure i can, just give me details which/where i should take VMMaker & platform sources & plugin.
I thought that all this information was in the VM repository.
Can you point me to that VM repository?
VMMaker are available on: - squeakmap, - http://www.squeaksource.com/VMMaker.html - http://source.squeakfoundation.org (now is empty ,strange)
The VM sources, are available on squeakvm.org SVN. Is this places correct?
For windows, you can use the source release from Squeak.org... http://www.squeakvm.org/win32/release/SqueakVM-Win32-3.10.7-src.zip Not sure about Linux.
Also, where i can get freetype plugin and its platform sources?
http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz is the latest, but you might have to use an earlier version from the same repository - e.g. http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz For a long time, I have used the FT2Plugins that ship with Sophie. I think that we will need to get platform sources, makefiles etc. from the Sophie developers. The Windows ft2plugin.dll dynamically links to freetype6.dll . Once again we may need the Sophie developers help if we want to rebuild freetype6.dll (to move to a later version of Freetype, for example). You can find the freetype6.dll in http://dev.sophieproject.org/downloads/releases/Sophie1.0.3.zip , or alternatively in my plugins installer sar (zip) file http://map.squeak.org/accountbyid/46dcf6af-067d-43e3-9fc9-d7010e067153/files... The source for FreeType itself is on sourceforge - http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3121 The freetype6.dll was built from version 2.2.1 of FreeType. The Linux FT2Plugin dynamically links to the libfreetype.so.6 library that ships with most (all?) linux distributions. The bitblt modifications are currently in a changeset that should be installed after installing vmmaker - you can get it here... http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBltS... (In a few days time this url will no longer work as I am changing ISP - so I have also attached it to this post) I know that this is all quite complicated and confusing, and it may take some time to get all the pieces of the puzzle in place. Thank you for your interest and help. Cheers, Andy
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/9/12 Andrew Tween <amtween@hotmail.com>:
Hi, "Igor Stasenko" <siguctua@gmail.com> wrote in message news:4a5f5f320809111213v2eec6200te2dcab47f03f6a58@mail.gmail.com...
2008/9/11 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I'm confused you do not use VMMaker for Hydra?
yes keep it there we have too much mailing-lists
So can you do a unix/windows VM with the freeType pluging?
Sure i can, just give me details which/where i should take VMMaker & platform sources & plugin.
I thought that all this information was in the VM repository.
Can you point me to that VM repository?
VMMaker are available on: - squeakmap, - http://www.squeaksource.com/VMMaker.html - http://source.squeakfoundation.org (now is empty ,strange)
The VM sources, are available on squeakvm.org SVN. Is this places correct?
For windows, you can use the source release from Squeak.org... http://www.squeakvm.org/win32/release/SqueakVM-Win32-3.10.7-src.zip
Not sure about Linux.
Also, where i can get freetype plugin and its platform sources?
http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz is the latest, but you might have to use an earlier version from the same repository - e.g. http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz
For a long time, I have used the FT2Plugins that ship with Sophie. I think that we will need to get platform sources, makefiles etc. from the Sophie developers.
The Windows ft2plugin.dll dynamically links to freetype6.dll . Once again we may need the Sophie developers help if we want to rebuild freetype6.dll (to move to a later version of Freetype, for example).
You can find the freetype6.dll in http://dev.sophieproject.org/downloads/releases/Sophie1.0.3.zip , or alternatively in my plugins installer sar (zip) file http://map.squeak.org/accountbyid/46dcf6af-067d-43e3-9fc9-d7010e067153/files...
The source for FreeType itself is on sourceforge - http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3121 The freetype6.dll was built from version 2.2.1 of FreeType.
The Linux FT2Plugin dynamically links to the libfreetype.so.6 library that ships with most (all?) linux distributions.
The bitblt modifications are currently in a changeset that should be installed after installing vmmaker - you can get it here... http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBltS... (In a few days time this url will no longer work as I am changing ISP - so I have also attached it to this post)
I know that this is all quite complicated and confusing, and it may take some time to get all the pieces of the puzzle in place. Thank you for your interest and help.
No, it is not complicated. You described the picture quite understandable. So, we have everything, except F2P plugin platform sources. Any idea, who i should contact with, to get them? -- Best regards, Igor Stasenko AKA sig.
No, it is not complicated. You described the picture quite understandable. So, we have everything, except F2P plugin platform sources. Any idea, who i should contact with, to get them?
For sophie contact mike and john m.rueger@acm.org and johnmci@smalltalkconsulting.com
participants (5)
-
Adrian Lienhard -
Alexandre Bergel -
Andrew Tween -
Igor Stasenko -
Stéphane Ducasse