September 2008 - Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

About package renaming Noury lukas told me that it was quite difficult to rename a package in MC. Last week I got a huge problem because I used the rename functionality of the browser of david and it crew up my system So did you tried your reanme behavior with dependency and the rest. Stef > 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. 10, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

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

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/10 StÃ©phane Ducasse <stephane.ducasse(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

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

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 StÃ©phane Ducasse <stephane.ducasse(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 StÃ©phane Ducasse <stephane.ducasse(a)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.

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

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

Sept. 9, 2008

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