January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

2010/1/9 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > Hi Mariano, > > good job. Some feedback. > > The installScript has unused variables and your proxy settings exposed. > Maybe this should be deleted from the final build. > > hahahahah I knew I was going to forget about that :( Thanks. Some bash guru that help me to automatize this? I would like something that automatically removes that from the file if it is found. Can you help me Miguel ? > Shouldn't be this a RC 2? because there is a new build process and has > nothing to do with the RC1? > > I thought about putting it RC2, actually, I was going to do that. But as the PharoCore was named rc1, I din't want to name it rc2 because maybe it was confusing. I am not sure, thus. What do you think ? > Also, the changes files, shouldn't be compressed for each RC and for the > final release? > Excellent point. Do you rather to Smalltalk >> condenseChanges ? It can be perfectly added. Right now, we are doing all this: MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. Smalltalk removeEmptyMessageCategories. Utilities cleanseOtherworldlySteppers. Undeclared removeUnreferencedKeys. Categorizer sortAllCategories. Symbol compactSymbolTable. Smalltalk at: #ReleaseBuilderDeveloper ifPresent: [:builder | builder new fixObsoleteReferences]. RequiredSelectors initialize. ProvidedSelectors initialize. LocalSends initialize. Smalltalk organization removeEmptyCategories. SystemBrowser removeObsolete. TheWorldMenu removeObsolete. AppRegistry removeObsolete. Set rehashAllSets. Smalltalk cleanOutUndeclared. Smalltalk garbageCollect. Do you think something else should be addded? Maybe we can reuse ScriptLoader cleanings ? > Also, the packages.txt file talks about PharoCore1.0 (#10505). Has > someone thought about the name shown in System->About: > > PharoCore1.0rc1 > Latest update: #10505 > > Because this is not a PharoCore image. Shouldn't this read something > like > > Pharo 1.0 Dev image. > Based on PharoCore1.0rc1 > Latest update: #10505 > > Yes, that's true. I agree. At least it was not "my falt" as it was already like that. But I am agree we should change that. However, I don't know how to do it. Maybe something related to SystemVersion? Any help ? > What about the disabling of software updates in the Pharo dev/web > images? Will this be implemented or a careful update stream will be made > in order to not break a dev image with overrides (real difficult I > think). > > Maybe. But in addition, sometimes there are bugs that updating just fix them. I am not sure if I want to disable. I rather warn people about it. Do you know if we break some overrrides doing an update? > Maybe all this setup can be put in a post-script in the > ConfigurationOfPharo class. > It is. We have pre and post do its. So, no problem :) > > That's all for now. I'm going to use this image to work the following > days. > Cheers and keep the good work. > > Thanks Miguel for the excellent feedback. Let's hope to build better images! Mariano > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 9, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Miguel Enrique CobÃ¡ Martinez

Hi Mariano, good job. Some feedback. The installScript has unused variables and your proxy settings exposed. Maybe this should be deleted from the final build. Shouldn't be this a RC 2? because there is a new build process and has nothing to do with the RC1? Also, the changes files, shouldn't be compressed for each RC and for the final release? Also, the packages.txt file talks about PharoCore1.0 (#10505). Has someone thought about the name shown in System->About: PharoCore1.0rc1 Latest update: #10505 Because this is not a PharoCore image. Shouldn't this read something like Pharo 1.0 Dev image. Based on PharoCore1.0rc1 Latest update: #10505 What about the disabling of software updates in the Pharo dev/web images? Will this be implemented or a careful update stream will be made in order to not break a dev image with overrides (real difficult I think). Maybe all this setup can be put in a post-script in the ConfigurationOfPharo class. That's all for now. I'm going to use this image to work the following days. Cheers and keep the good work. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 9, 2010

[Pharo-project] [update 1.1] #11149

by Marcus Denker

11149 ----- Issue 1761: Unloadable-reloadable Services-Base + DeprecatedPreferences packages, last step

Jan. 9, 2010

[Pharo-project] [update 1.1] #11148

by Marcus Denker

11148 ----- Issue 1761: Unloadable-reloadable Services-Base + DeprecatedPreferences packages (reload dirty packages from removal) Issue 1593: Packages: strange MC packages in need of cleanup (not yes all)

Jan. 9, 2010

[Pharo-project] [update 1.1] #11147

by Marcus Denker

11147 ----- Issue 1761: Unloadable-reloadable Services-Base + DeprecatedPreferences packages (part 1 - 3) ... some packages are dirty. This will be fixed next, together with part 4 and a cleanup of packages that are defined wrongly. Marcus

Jan. 9, 2010

Re: [Pharo-project] Problems saving the image on SIGTERM

by Damien Pollet

On Sat, Jan 9, 2010 at 18:53, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Fri, Jan 08, 2010 at 05:51:51PM +0100, Damien Pollet wrote: >> Hi, >> >> Chaff is a tiny class to intercept the SIGTERM signal and save the >> image http://www.squeaksource.com/Chaff.html >> >> Several problems: >> >> - OSProcess accessor forwardSigTern will only work once. Once the VM >> has registered a handler for a given signal, it can't clean it up or >> register another semaphore, until the image restarts. > > Not so. The plugin allows you to reset a signal handler to its default > value for exactly this reason. This is the method comment in > UnixOSProcessPlugin (the part that runs in the VM): > > forwardSignal: sigNum toSemaphoreAt: semaphoreIndex > Â Â Â Â "Set a signal handler in the VM which will signal a Smalltalk semaphore at > Â Â Â Â semaphoreIndex whenever an external signal sigNum is received. Answer the > Â Â Â Â prior value of the signal handler. If semaphoreIndex is zero, the handler is > Â Â Â Â unregistered, and the VM returns to its default behavior for handling that > Â Â Â Â signal. A handler must be unregistered before it can be registered again. > > Â Â Â Â The Smalltalk semaphore is expected to be kept at the same index location > Â Â Â Â indefinitely during the lifetime of a Squeak session. If that is not the case, the > Â Â Â Â handler must be unregistered prior to unregistering the Smalltalk semaphore." > > Thus in UnixOSProcessAccessor you have #forwardSigInt to set a handler, > and #restoreSigInt to restore the signal handler to its default. After > it has been restored you can set it again. > >> - If I have a process waiting on the semaphore, but the image quits >> for a different reason, I guess when it restarts, the process will >> still be there but the semaphore will be invalid??? what's a good way to >> handle that ? > > The semaphore will be valid but will receive no signals from the VM. > When you restart the image, you will need to set your signal handlers > at that time. Most likely you will want to just start a new process, > perhaps in a #startUp: method. Thanks ! -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 9, 2010

Re: [Pharo-project] OSProcess

by Schwab,Wilhelm K

Carlos, all, Is Alien ready for real use? I am getting closer to being able to produce a Pharo version of my GSL wrapper and was today reminded of the fairly extensive use of callbacks in the library - that makes sense, because much of it is algorithms that need to accept user-provided code. My reading suggess that Alien is the way to go. Is it? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, January 09, 2010 12:49 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess Thanks, please can you provide pointers on how to launch a external process with Alien? Regards, Carlos ----- Original Message ----- From: "David T. Lewis" <lewis(a)mail.msen.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, January 09, 2010 2:26 PM Subject: Re: [Pharo-project] OSProcess > Yes, OSProcess is designed to work on Windows also. However, the > functionality > is limited on Windows and the plugin is not distributed with the Windows > VM, so > for most people this is not a practical solution. FFI is another > alternative. > > Dave > > On Sat, Jan 09, 2010 at 10:53:30AM -0500, Schwab,Wilhelm K wrote: >> Carlos, >> >> OSProcess appears to be _designed_ to run on Windows (lots of code for >> same), but I am not aware that it works there. The existing gnuplot >> package uses OSProcess on Linux/Mac and ProcessWrapper on Windows, and I >> have done the same thing when I need to run on Windows. >> >> I have seen no evidence that ProcessWrapper works other than on Windows; >> if you find that it does, please make noise about that. I *think* I like >> it better than OSProcess, but I do a lot more relevant work on Linux >> where I can't use ProcessWrapper. >> >> Bill >> >> >> >> ________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos >> Crosetti >> Sent: Friday, January 08, 2010 9:46 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] OSProcess >> >> >> Hi, is rhe OSProcess designed to call out an external program from a >> Windows vm? >> >> Regards, Carlos > >> _______________________________________________ >> 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

Jan. 9, 2010

Re: [Pharo-project] OSProcess

by David T. Lewis

Apologies, I was referring to the traditional FFI and forgot about the change to Alien. I'm sure it can be done similarly, perhaps someone else can give an example. Otherwise perhaps ProcessWrapper as Bill Schwab suggested. Dave On Sat, Jan 09, 2010 at 02:48:37PM -0300, Carlos Crosetti wrote: > Thanks, please can you provide pointers on how to launch a external process > with Alien? > > Regards, Carlos > ----- Original Message ----- > From: "David T. Lewis" <lewis(a)mail.msen.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, January 09, 2010 2:26 PM > Subject: Re: [Pharo-project] OSProcess > > > > Yes, OSProcess is designed to work on Windows also. However, the > > functionality > > is limited on Windows and the plugin is not distributed with the Windows > > VM, so > > for most people this is not a practical solution. FFI is another > > alternative. > > > > Dave > > > > On Sat, Jan 09, 2010 at 10:53:30AM -0500, Schwab,Wilhelm K wrote: > >> Carlos, > >> > >> OSProcess appears to be _designed_ to run on Windows (lots of code for > >> same), but I am not aware that it works there. The existing gnuplot > >> package uses OSProcess on Linux/Mac and ProcessWrapper on Windows, and I > >> have done the same thing when I need to run on Windows. > >> > >> I have seen no evidence that ProcessWrapper works other than on Windows; > >> if you find that it does, please make noise about that. I *think* I like > >> it better than OSProcess, but I do a lot more relevant work on Linux > >> where I can't use ProcessWrapper. > >> > >> Bill > >> > >> > >> > >> ________________________________ > >> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos > >> Crosetti > >> Sent: Friday, January 08, 2010 9:46 PM > >> To: pharo-project(a)lists.gforge.inria.fr > >> Subject: [Pharo-project] OSProcess > >> > >> > >> Hi, is rhe OSProcess designed to call out an external program from a > >> Windows vm? > >> > >> Regards, Carlos > > > >> _______________________________________________ > >> 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

Jan. 9, 2010

Re: [Pharo-project] Morphic (for gary :) and others)

by Schwab,Wilhelm K

Stef, As long as you're not giving up, I approve :) Cuis has set objectives, and absent Pharo, Squeak would be back to business as usual with shocking speed. Let's not try it. There no doubt are areas in which performance can be improved. One thing that has stuck with me for a while is that a prominent Squeaker (don't recall who) once was bragging about Squeak's graphics and the fact that all parameters are always passed on each call. True or not, then or now, I don't really know. My point is simply that there could be horrible penalties for extra parameters on the stack and changing any device contexts[*] for every call (worst case). Gary, does any of the above ring true? If so, is there anything we can/should do about it? Whatever the cause, I recently had the opportunity to put a very large number of items into a tree. It was something that I did in Dolphin, fully expecting to have to break up the data set for performance reasons, but was *very* surprised to see that Dolphin tolerated it well. Pharo pretty much drops to its knees on the same data. It might be my fault, but it would be nice to see comparable performance. As a related aside, I recently noticed mention of removing the world menu from Squeak. That is something we will eventually need to do if we want to get away from having a single main window and emulated shells inside it. Remove the desktop, and there is nowhere to click to get the menu. Bill [*] sorry, recovering Windows programmer. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Saturday, January 09, 2010 5:21 AM To: Pharo-project(a)lists.gforge.inria.fr Development Subject: [Pharo-project] Morphic (for gary :) and others) Gary and others I really think that we should do an audit of Morphic. In 1.1 we are going already faster but I'm sure that there is plenty of space for improvements. I see several actions - checking squeak toolbuilder enhancements and using it for the tools - checking CUIS - juan did an excellent job remocving a lot of unnecessary code - juan optimize scrollbar - juan did a new texteditor morph - removing/cleaning extra widgets Pluggable/nonpluggable plague. - integrating better polymorph into the widgets layer. What do you think? _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 9, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Henrik Sperre Johansen

AFAICT from searching a few of the files, the events all have names ending in past tense... Last example I found regarding window events was in the 2008sm05 file, where there's a reference to closeRequested:. For those actions allowing a veto, the naming convention thus seems to send off an (action)Requested before the action itself. I was unable to find the discussion mentioned in a reasonable amount of time. Cheers, Henry On 09.01.2010 17:15, Schwab,Wilhelm K wrote: > Stef, > > It will be challenging to find the relevant discussion, though it is probably captured in Ian Bartholomew's news archives. IIRC, the fine points were about tense, just like here. > > When does digging into that archive turn into reverse engineering? It is a public forum, and the archives of the group have long been on Ian's site in plain view to all. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Saturday, January 09, 2010 7:08 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus > > what was the words they used? > > Stef > > On Jan 8, 2010, at 11:37 PM, Schwab,Wilhelm K wrote: > > >> Another possibility is to leave off the tense. What we should avoid is WindowMoved while there is still an opportunity to veto it; WindowMove would be (mercifully) neutral. I hesitate to mention that Object Arts went through a high-profile change on this some time back, and had very good reasons for their choices. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Henrik Sperre Johansen >> Sent: Friday, January 08, 2010 4:26 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Notifications of windows >> opening/closing/focus >> >> On 08.01.2010 21:37, Gary Chambers wrote: >> >>> If "after the fact" I'd vote for the "ed" suffix too. Make it match >>> what is/has happening/happened. >>> As a side note, WindowClosing is common to give a potential veto >>> chance (i.e. deny close). Should also be a WindowClosed if it does get that far... >>> >>> Regards, Gary >>> >>> >> I suggest having both ...ing/...ed versions of close, move and resize, and ...ed for the rest, at least for now. >> >> Cheers, >> Henry >> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Jan. 9, 2010