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

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

by Serge Stinckwich

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/ -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

Sept. 9, 2008

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

by Adrian Lienhard

On Sep 9, 2008, at 12:11 , Noury Bouraqadi wrote: > Hi, > > SqueakSource is down again :-( Hi Noury, it works fine for me right now Adrian

Sept. 9, 2008

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

by Noury Bouraqadi

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

Sept. 9, 2008

Re: [Pharo-project] Wiki page rename

by Norbert Hartl

On Sun, 2008-08-31 at 14:02 -0400, Bill Schwab wrote: > Hello, > > Anybody know how to rename a page on the Wiki? Is it as crude as > add/copy/delete? Hopefully there is a better way?? > 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 > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > > _______________________________________________ > 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 Adrian Lienhard

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

Sept. 9, 2008

[Pharo-project] Hello everyone!

by Igor Stasenko

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.

Sept. 9, 2008

Re: [Pharo-project] SCriptLoader>>InstallingInstaller

by StÃ©phane Ducasse

Ok I see This was fixed in the latest scriptloader. stef On Sep 7, 2008, at 3:54 PM, Luc Fabresse wrote: > I think it should be 'InstallerAll-md.1' (http://www.squeaksource.com/Installer/InstallerAll-md.1.mcz > ) > There is one more '.' in the code. > > #Luc > > > 2008/9/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > why? > > stef > > On Sep 7, 2008, at 11:17 AM, Hilaire Fernandes wrote: > > With the lateset update. > > There is something uncorrect in the package name I guess ? > > SCriptLoader>>InstallingInstaller > [...] > fileToLoad := files > detect: [:aFile | aFile beginsWith: > 'InstallerAll.-md.1'] > ifNone: []. > > -- > http://blog.ofset.org/hilaire > > _______________________________________________ > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 7, 2008

Re: [Pharo-project] SCriptLoader>>InstallingInstaller

by Luc Fabresse

I think it should be 'InstallerAll-md.1' ( http://www.squeaksource.com/Installer/InstallerAll-md.1.mcz)There is one more '.' in the code. #Luc 2008/9/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > why? > > stef > > On Sep 7, 2008, at 11:17 AM, Hilaire Fernandes wrote: > > With the lateset update. >> >> There is something uncorrect in the package name I guess ? >> >> SCriptLoader>>InstallingInstaller >> [...] >> fileToLoad := files >> detect: [:aFile | aFile beginsWith: >> 'InstallerAll.-md.1'] >> ifNone: []. >> >> -- >> http://blog.ofset.org/hilaire >> >> _______________________________________________ >> 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. 7, 2008

Re: [Pharo-project] SCriptLoader>>InstallingInstaller

by StÃ©phane Ducasse

why? stef On Sep 7, 2008, at 11:17 AM, Hilaire Fernandes wrote: > With the lateset update. > > There is something uncorrect in the package name I guess ? > > SCriptLoader>>InstallingInstaller > [...] > fileToLoad := files > detect: [:aFile | aFile beginsWith: 'InstallerAll.-md.1'] > ifNone: []. > > -- > http://blog.ofset.org/hilaire > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 7, 2008

[Pharo-project] SCriptLoader>>InstallingInstaller

by Hilaire Fernandes

With the lateset update. There is something uncorrect in the package name I guess ? SCriptLoader>>InstallingInstaller [...] fileToLoad := files detect: [:aFile | aFile beginsWith: 'InstallerAll.-md.1'] ifNone: []. -- http://blog.ofset.org/hilaire

Sept. 7, 2008