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

Re: [Pharo-project] OSProcess

by StÃ©phane Ducasse

On Jan 9, 2010, at 7:43 PM, Schwab,Wilhelm K wrote: > 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? I know fernando uses it intensively for opengl calls on mac. > > 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 > > _______________________________________________ > 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 Mariano Martinez Peck

2010/1/9 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Gofer seaside28 load > > I didn't say that. I said: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside28'; load. (Smalltalk at: #ConfigurationOfSeaside28) load And I also said I was not sure of this is working. Cheers Mariano > does not work. What is the correct way to install Seaside - I can't do > much w/o it. > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Mariano > Martinez Peck > *Sent:* Saturday, January 09, 2010 3:01 PM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] [BetaTesting] [ANN] > Pharo1.0-10505-rc1dev10.01.1 > > > > 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 > > > > _______________________________________________ > 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 StÃ©phane Ducasse

On Jan 9, 2010, at 6:26 PM, David T. Lewis wrote: > 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. do you know why? Because this would be cool. > 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

Jan. 9, 2010

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

by StÃ©phane Ducasse

> Stef, > > As long as you're not giving up, I approve :) I decided now that I will not and you can believe me. Last day I was discussing with some colleagues of mine about all kinds of news about pharo (web site, companies....) and oen the them told: "and we all that you were depressed" and he was right. > Cuis has set objectives, and absent Pharo, Squeak would be back to business as usual with shocking speed. Let's not try it. We can learn from it and this is what is the most interesting part. > > 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. Yes. > 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. Yes now I'm quite sure you do not want to have the same as in squeak. It is the old worldMenuBar > > 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 > > _______________________________________________ > 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] [ANN] Hudson continuous integration server support

by Mariano Martinez Peck

Cool. I commited the bash scripts files to: https://scm.gforge.inria.fr/svn/pharo/BuildImages cheers mariano On Sat, Jan 9, 2010 at 9:53 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > mariano this is public on the web site :) > on forge page of the pharo project at inria. > https://gforge.inria.fr/scm/?group_id=1299 > Normal svn > > svn checkout svn://scm.gforge.inria.fr/svn/pharo > svn checkout --username login https://scm.gforge.inria.fr/svn/pharo > > :) > > On Jan 9, 2010, at 5:02 PM, Mariano Martinez Peck wrote: > > > > > > > On Sat, Jan 9, 2010 at 4:54 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > we could host that using the pharo svn account at inria gforge > > > > > > Stef: would you mind sending me in a private email all the information > about Pharo SVN ? > > > > I refactor (support for Mac OS, cleanup squeak stuff and old stuff ) > Damien's bash scripts to build images and I want to start to version them. > > > > Cheers > > > > Mariano > > > > Stef > > > > On Jan 9, 2010, at 3:31 PM, Lukas Renggli wrote: > > > > >>> So here's a new idea. Keep the package-cache from the previous build, > > >>> and make sure the build image can make use of it -- I'm not sure of > the > > >>> Gofer/Monticello details. > > >> > > >> Yeah, Gofer would benefit from the package cache. As far as I know > > >> Hudson however cleans the workspace with every new build. I don't know > > >> how the package cache could be saved over. > > > > > > I do keep a global package-cache now, we'll see tomorrow if the builds > > > are faster. > > > > > > I've departed quite a bit from the scripts of Yanni. I generalize > > > everything into a single script that can then be parametrized from > > > Hudson. I have everything in a private Git repository. How can I > > > contribute it back? > > > > > > Lukas > > > > > > > > > > > > > > >> > > >> Lukas > > >> > > >> -- > > >> Lukas Renggli > > >> http://www.lukas-renggli.ch > > >> > > > > > > > > > > > > -- > > > Lukas Renggli > > > http://www.lukas-renggli.ch > > > > > > _______________________________________________ > > > 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

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

by Schwab,Wilhelm K

Gofer seaside28 load does not work. What is the correct way to install Seaside - I can't do much w/o it. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Saturday, January 09, 2010 3:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1 2010/1/9 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com<mailto:miguel.coba@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<mailto:Pharo-project@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 StÃ©phane Ducasse

On Jan 9, 2010, at 8:39 PM, Miguel Enrique CobÃ¡ Martinez wrote: > 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? yes rc2 mariano pharo-rc2 is not a problem > Also, the changes files, shouldn't be compressed for each RC and for the > final release? Yes probably. > 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 This is on the todo of marcus to come up with a HUGE list of actions we did in pharo 1.0 :) in a better way than the update cryptic log. > 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). Yeap another interesting point. May be disabling is the easiest solution :) > 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 > > > _______________________________________________ > 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] [ANN] Hudson continuous integration server support

by StÃ©phane Ducasse

mariano this is public on the web site :) on forge page of the pharo project at inria. https://gforge.inria.fr/scm/?group_id=1299 Normal svn svn checkout svn://scm.gforge.inria.fr/svn/pharo svn checkout --username login https://scm.gforge.inria.fr/svn/pharo :) On Jan 9, 2010, at 5:02 PM, Mariano Martinez Peck wrote: > > > On Sat, Jan 9, 2010 at 4:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > we could host that using the pharo svn account at inria gforge > > > Stef: would you mind sending me in a private email all the information about Pharo SVN ? > > I refactor (support for Mac OS, cleanup squeak stuff and old stuff ) Damien's bash scripts to build images and I want to start to version them. > > Cheers > > Mariano > > Stef > > On Jan 9, 2010, at 3:31 PM, Lukas Renggli wrote: > > >>> So here's a new idea. Keep the package-cache from the previous build, > >>> and make sure the build image can make use of it -- I'm not sure of the > >>> Gofer/Monticello details. > >> > >> Yeah, Gofer would benefit from the package cache. As far as I know > >> Hudson however cleans the workspace with every new build. I don't know > >> how the package cache could be saved over. > > > > I do keep a global package-cache now, we'll see tomorrow if the builds > > are faster. > > > > I've departed quite a bit from the scripts of Yanni. I generalize > > everything into a single script that can then be parametrized from > > Hudson. I have everything in a private Git repository. How can I > > contribute it back? > > > > Lukas > > > > > > > > > >> > >> Lukas > >> > >> -- > >> Lukas Renggli > >> http://www.lukas-renggli.ch > >> > > > > > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > 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] [ANN] Hudson continuous integration server support

by Danie Roux

On Sat, Jan 9, 2010 at 7:09 PM, Lukas Renggli wrote: > Ok, grab it with: > > Â git clone git://github.com/renggli/builder.git Awesome, thanks! For those new to github, this is the entry point, with a rendered README: http://github.com/renggli/builder -- Danie Roux *shuffle* Adore Unix - http://danieroux.com

Jan. 9, 2010

[Pharo-project] [ANN 1.1] prebuilt 1.1Core#11149

by Marcus Denker

http://gforge.inria.fr/frs/download.php/25158/PharoCore-1.1-11149-UNSTABLE.…

Jan. 9, 2010