- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

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(a)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(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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

On Sep 9, 2008, at 5:43 PM, Igor Stasenko wrote: > 2008/9/9 Adrian Lienhard <adi(a)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(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. 9, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

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(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 >

Sept. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by StÃ©phane Ducasse

to reply to your question: - if this is changeset with some coherent set of fixes, create an entry on the issue (else pslit the cs) - send an email here "saying guys please review" - when this is done, we can push changes via changeset really fast now in pharo we worked with marcus to minimize the time it can take us when **we** perform a changes or apply a change in the latest release (versus merging package published on an old versions) - we are missing an scp connection calls to get nearly a push one button to release a new version Stef On Sep 9, 2008, at 12:11 PM, Noury Bouraqadi wrote: > Hi, > > SqueakSource is down again :-( > Attached a monticello package with a serie of bugfixes and > enhancements tested on pharo-dev of sept: > > *Bug Fixes > -Transcript printing and self evaluating > -Smalltalk printing and self evaluating > -Instance Variable should never start by a capital > > *Enhancemnts > -Monticello Package renaming > -Prefix replacement for classes in a Monticello package > > Regards, > Noury > ------------------------------------------------------------------ > Dr. Noury Bouraqadi - Enseignant/Chercheur > Responsable de l'enseignement de l'informatique > ARMINES - Ecole des Mines de Douai - Dept. I.A. > http://vst.ensm-douai.fr/noury > > European Smalltalk Users Group Board > http://www.esug.org > ------------------------------------------------------------------ > > > <FixesAndEnh-Noury. > 1.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by StÃ©phane Ducasse

:) For me this was not http://downWhenWeReallyNeedItAndThisSunday :) Stef >>>> >> http://downforeveryoneorjustme.com/ >> > well the squeaksource is often > http://downforeveryoneincludingme.com/ > :)

Sept. 9, 2008

Re: [Pharo-project] Wiki page rename

by StÃ©phane Ducasse

>> > The only option I guess is to checkout svn and move the file to > the new name. > > Norbert > > P.S.: Back from vacation and trying to find time to do some pharo > stuff I know the feeling (3 kids * 3 schools * wife = teacher * new team * new secretary * new deadlines * house with roof with holes) But this is cool message to my hears. Thanks! We are reorganizing ourselves and we would like to have - etoy out - polymorph in - free type in for the first release and a lot of little fixes of course. Stef

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: > > On Sep 9, 2008, at 17:43 , Igor Stasenko wrote: > >> 2008/9/9 Adrian Lienhard <adi(a)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(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 > > > _______________________________________________ > 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. 9, 2008

Re: [Pharo-project] Hello everyone!

by Adrian Lienhard

On Sep 9, 2008, at 17:43 , Igor Stasenko wrote: > 2008/9/9 Adrian Lienhard <adi(a)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(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. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by Igor Stasenko

2008/9/9 Serge Stinckwich <serge.stinckwich(a)doesnotunderstand.org>: > 2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: >> >> On Sep 9, 2008, at 12:11 , Noury Bouraqadi wrote: >> >>> Hi, >>> >>> SqueakSource is down again :-( > > > When a site seems to be down, you can check with : > http://downforeveryoneorjustme.com/ > well the squeaksource is often http://downforeveryoneincludingme.com/ :) > -- > Serge Stinckwich > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://blog.doesnotunderstand.org/ > > _______________________________________________ > 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. 9, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 Adrian Lienhard <adi(a)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(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.

Sept. 9, 2008