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

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by George Herolyants

2010/1/22 Mariano Martinez Peck <marianopeck(a)gmail.com>: > But you are using OB, aren't you ? Sorry for the late reply. Yes, I'm using OB.

Jan. 24, 2010

Re: [Pharo-project] Pharo dev image rc2 thoughts

by StÃ©phane Ducasse

On Jan 24, 2010, at 8:53 AM, Miguel Enrique CobÃ¡ Martinez wrote: > First that anything, thanks to Mariano for all the effort put in order > to release a 1.0 version of Pharo. And to all the contributors also. + 200 :) > > As part of incorporating Metacello to my projects, I have gain a little > more insight in the working of it. For that I have been studying the > existing configurations. I even contributed a pair to the repository. > Tonight I was building a Pharo image using the ConfigurationOfPharo. > > The announce said nothing but the inner workings of the dev image > creations changed, although the result is exactly (with a lot of fixes > included) the same that the rc1 image created with Metacello. The > changes are this: > > - in rc1, it was only necessary ConfigurationOfPharo to build a complete > Pharo dev image. That is ConfigurationOfPharo included > ImageForDevelopers. > > - in rc2, ConfigurationOfPharo isn't enough to build a dev image (I > noticed this tonight because I used ConfigurationOfPharo alone to build > an image but in the end I didn't get autocompetition), it is also > necessary to run a second script to load ImageForDevelopers and install > it. This is all done in the installScript.st script included in the > pharo rc2 dev image. > > As I said before, the results are the same, but before all was done in > the ConfigurationOfPharo and now requires two steps. > > Now to the point. I understand that the separation of concerns is good, > because ImageForDevelopers is already a separated and tested package > that shouldn't be inside ConfigurationOfPharo. > > - Shouldn't be necessary to create a ConfigurationOfImageForDevelopers > and in this configuration reference ConfigurationOfPharo and then the > installScript for the dev image use *only* > ConfigurationOfImageForDevelopers? > > - It appears that Dale will announce project preload/postload doIts next > monday. If that happens, shouldn't be better to incorporate the code > from DEVImageCreator as preload/postload do its to the > ConfigurationOfPharo? probably even if I do not have enough experience with metacello > > It appears to me that DEVImageCreator is a mixture of different things, > both preference tuning (setDefaultPreferences, setFonts) image fixing > (addPreferenceCategories, cleanOpenMenu) and image building stuff > (writeListOfPackages, showWelcomeWorkspaces). > > Maybe the image fixing stuff should be a change incorporated to the > PharoCore image, and the preference tuning should be a postload do it > for the ConfigurationOfImageForDevelopers, and the image building stuff > should be in the install script. > > This way, if someone wants to build a image for developers (but without > the list of packages, or welcome workspaces) it only has to use > ConfigurationOfImageForDevelopers. probably > > Also, maybe after all this refactoring, the > ConfigurationOfImageForDevelopers isn't necessary because all can be > incorporated to the ConfigurationOfPharo as preload/postload do its. > That is fine. > > Also, the image for developers has stuff for squeak. This refactoring > would permit to separate them in preload/postload for each platform, in > a cleaner way. > > As I said at beginning, this is only thoughts, and the current result > image is the same as the one produced by the previous configuration, but > maybe, with more time and less pressure, this refactoring and cleaning > could be made. > > Of course, I will try to do this and contribute the code as my time > permits, but if someone can do it sooner, the better for all of us. > > Thanks again for the hard 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. 24, 2010

[Pharo-project] Traits for Javascript

by StÃ©phane Ducasse

Just in case some people doubt again about the interest of traits in world outside Smalltalk after perl, scala,.... This is why in the future we will have to restart moving and have a look at immutability bit, ephemeron, process isolation, ... > Copyright (C) 2010 Google Inc. > > Seems to be kind of officially proposed as to be added to EcmaScript (the standard of JavaScript) by Google. > > The other stuff is cool, too: > > http://code.google.com/p/es-lab/ > > OMeta and Membranes. The last one is important from a security perspective. We should closely study it. > > > Marcus > > >> Stef >> >> On Jan 23, 2010, at 8:19 PM, Marcus Denker wrote: >> >>> http://code.google.com/p/es-lab/wiki/Traits >>> >>> >>> They cite: >>> >>> â¢ [1] "Traits: Composable units of Behavior" (Scharli et. al, ECOOP 2003) (paper) >>> â¢ [2] "Adding State and Visibility Control to Traits using Lexical Nesting" (Van Cutsem et. al, ECOOP 2009) (paper) >>> â¢ [3] Horizontal Reuse for PHP: 'traits' vs 'grafts' >>> >>> [3] is the work of Stefan Marr, who is now doing a Phd with Theo on a MultiCore VM. >>> >>> Marcus >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD.

Jan. 24, 2010

[Pharo-project] Pharo dev image rc2 thoughts

by Miguel Enrique CobÃ¡ Martinez

First that anything, thanks to Mariano for all the effort put in order to release a 1.0 version of Pharo. And to all the contributors also. As part of incorporating Metacello to my projects, I have gain a little more insight in the working of it. For that I have been studying the existing configurations. I even contributed a pair to the repository. Tonight I was building a Pharo image using the ConfigurationOfPharo. The announce said nothing but the inner workings of the dev image creations changed, although the result is exactly (with a lot of fixes included) the same that the rc1 image created with Metacello. The changes are this: - in rc1, it was only necessary ConfigurationOfPharo to build a complete Pharo dev image. That is ConfigurationOfPharo included ImageForDevelopers. - in rc2, ConfigurationOfPharo isn't enough to build a dev image (I noticed this tonight because I used ConfigurationOfPharo alone to build an image but in the end I didn't get autocompetition), it is also necessary to run a second script to load ImageForDevelopers and install it. This is all done in the installScript.st script included in the pharo rc2 dev image. As I said before, the results are the same, but before all was done in the ConfigurationOfPharo and now requires two steps. Now to the point. I understand that the separation of concerns is good, because ImageForDevelopers is already a separated and tested package that shouldn't be inside ConfigurationOfPharo. - Shouldn't be necessary to create a ConfigurationOfImageForDevelopers and in this configuration reference ConfigurationOfPharo and then the installScript for the dev image use *only* ConfigurationOfImageForDevelopers? - It appears that Dale will announce project preload/postload doIts next monday. If that happens, shouldn't be better to incorporate the code from DEVImageCreator as preload/postload do its to the ConfigurationOfPharo? It appears to me that DEVImageCreator is a mixture of different things, both preference tuning (setDefaultPreferences, setFonts) image fixing (addPreferenceCategories, cleanOpenMenu) and image building stuff (writeListOfPackages, showWelcomeWorkspaces). Maybe the image fixing stuff should be a change incorporated to the PharoCore image, and the preference tuning should be a postload do it for the ConfigurationOfImageForDevelopers, and the image building stuff should be in the install script. This way, if someone wants to build a image for developers (but without the list of packages, or welcome workspaces) it only has to use ConfigurationOfImageForDevelopers. Also, maybe after all this refactoring, the ConfigurationOfImageForDevelopers isn't necessary because all can be incorporated to the ConfigurationOfPharo as preload/postload do its. That is fine. Also, the image for developers has stuff for squeak. This refactoring would permit to separate them in preload/postload for each platform, in a cleaner way. As I said at beginning, this is only thoughts, and the current result image is the same as the one produced by the previous configuration, but maybe, with more time and less pressure, this refactoring and cleaning could be made. Of course, I will try to do this and contribute the code as my time permits, but if someone can do it sooner, the better for all of us. Thanks again for the hard work -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 24, 2010

Re: [Pharo-project] Deadlock detection for testcases

by Stefan Marr

Hi: On 23 Jan 2010, at 01:03, Adrian Kuhn wrote: > Lukas Renggli <renggli@...> writes: > > Please don't add this to TestCase. Sometimes I want to keep my >> debuggers open. Also this slows running lots of tests considerably >> down. >> >> I suggest that you create your own subclass of TestCase and override >> runCase as such: >> >> runCase >> [ super runCase ] >> valueWithin: self expectedMaxRuntime >> onTimeout: [ self failWithTimeout ] > > +1, being able to debug your tests is a must have. > > Please note that is also > > TAssertable >> #should:notTakeMoreThan: > TAssertable >> #should:notTakeMoreThanMilliseconds: > TestMatcher >> #runWithin: Thanks, have now my own subclass which does runCase self should: [super runCase] notTakeMoreThan: self expectedMaxRuntime And it works fine :) Best Stefan > > If you dont use akuhn/SUnit the first two methods are in TestCase and the > third requires Phexample. > > cheers, > AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

Jan. 23, 2010

[Pharo-project] Monticello diff between chosen revisions is broken

by Stefan Marr

Hi: In the current dev image (10508), Monticello is broken with respect to showing the differences of between chosen revisions. However, that seems to be broken already in 10496. (and maybe earlier) To reproduce: 1. Open Monticello Browser 2. Select a repo 3. click open 4. Select a revision, not the latest one 5. Click diff 6. chose an ancestor from the list Now you got a window 'Version: ...5' Saying (Diff against ...2) Here I would expect the changes button to open a window showing the changes between the chosen revisions, but it always diffs against the latest version. Best Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

Jan. 23, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 23-01-2010 a las 12:38 -0500, David T. Lewis escribiÃ³: > There is also SmalltalkImage current listBuiltinModules, which lists the > modules that are compiled into the VM executable, as opposed to "external" > modules that are in shared libraries (.dll or .so files). > > The available plugins are those that appear in #listBuiltinModules, plus > any external plugins that the VM can find in shared libraries. If you > look at #listBuiltinModules plus the shared libraries you have in your > installation, that will tell you the available plugins. > > The #listLoadedModules are the plugins (internal and external) that > your image has actually used since you last restarted it, so you have > to actually do something in Smalltalk that uses a plugin before it will > show up in #listLoadedModules. > > When you inspect the list of loaded modules, you will notice either '(i)' > or '(e)' to indicate whether the loaded module is an internal plugin > or and external plugin. For example, 'BitBltPlugin 20 January 2010 (i)' > indicates that the BitBltPlugin was loaded from a module that was compiled > into the VM executable, and 'UnixOSProcessPlugin 20 January 2010 (e)' > indicates a module that was loaded from an external shared library. Thanks for the info. In my machine: SmalltalkImage current listBuiltinModules: #('ADPCMCodecPlugin 26 August 2009 (i)' 'AsynchFilePlugin 26 August 2009 (i)' 'BMPReadWriterPlugin 26 August 2009 (i)' 'B2DPlugin 26 August 2009 (i)' 'BitBltPlugin 26 August 2009 (i)' 'CroquetPlugin 26 August 2009 (i)' 'DSAPrims 26 August 2009 (i)' 'ZipPlugin 26 August 2009 (i)' 'DropPlugin 26 August 2009 (i)' 'FFTPlugin 26 August 2009 (i)' 'FilePlugin 26 August 2009 (i)' 'FloatArrayPlugin 26 August 2009 (i)' 'FloatMathPlugin 26 August 2009 (i)' 'GeniePlugin v2.0 26 August 2009 (i)' 'JPEGReadWriter2Plugin 26 August 2009 (i)' 'JPEGReaderPlugin 26 August 2009 (i)' 'JoystickTabletPlugin 26 August 2009 (i)' 'Klatt 26 August 2009 (i)' 'LargeIntegers v1.5 26 August 2009 (i)' 'LocalePlugin 26 August 2009 (i)' 'Matrix2x3Plugin 26 August 2009 (i)' 'MiscPrimitivePlugin 26 August 2009 (i)' 'RePlugin 26 August 2009 (i)' 'SecurityPlugin 26 August 2009 (i)' 'SerialPlugin 26 August 2009 (i)' 'SocketPlugin 26 August 2009 (i)' 'SoundCodecPrims 26 August 2009 (i)' 'SoundGenerationPlugin 26 August 2009 (i)' 'SoundPlugin 26 August 2009 (i)' 'StarSqueakPlugin 26 August 2009 (i)' 'SurfacePlugin Sep 16 2009 (i)') > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 23, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Adrian Lienhard

Maybe it would be better to add these definitions to a wiki page or to the website. Like this we can add new ones and update existing ones independent of releases. In the welcome workspace you could then just point to the URL that contains the current list. There is already a related wiki page: http://code.google.com/p/pharo/wiki/PackagesTestedInPharo Cheers, Adrian On Jan 22, 2010, at 17:58 , Mariano Martinez Peck wrote: > Don't forget Magma. There is a ConfigurationOfMagma already in >> MetacelloRepository. >> >> > Yes...there are a lot of projects..I even didn't put SqueakDBX/GlorpDBX. I > guess that in a future we will have Loader to do this... > > I don't know. Do you think we should also include Magma? I put the projects > I though were most used. > > > >>> Do you think that with this we are able to close issue1479 ? >>> - Background with Pharo picture. This was a joke. It looked nice :) >>> I promise I don't put it again if you don't like. To remove it >>> evaluate: >>> World color: Color white. >>> - Enable the preference fastDragWindowForMorphic. Sorry, but it most >>> computers this works REALLY slow. If you want them back, just disable >>> it. >> >> +1 >> >> I generally use: >> Preferences enable: #fastDragWindowForMorphic. >> Preferences disable: #windowAnimation. >> Preferences enable: #updateSavesFile. >> Preferences disable: #windowAnimation. >> >> > Well....that's why they are called Preferences :) > I will check them and see if they make sense. > Thanks!! > > >> >>> - When installing Seaside now doesn't ask for user and password >>> ( admin/seaside ). In addition, the Seaside Control Panel is only >>> isntalled if OB is installed. This means that yu can install it in >>> core or dev. Thanks Dale! >>> - Disable of System Update for Dev images as it is not working >>> properly. >> >> Isn't working? In the image from your link, the preference is working >> correctly. >> >>> >>> >>> The link is: >>> >> https://gforge.inria.fr/frs/download.php/25397/Pharo1.0-10508-rc2dev10.01.2… >>> >>> Cheers >>> >>> Mariano >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> 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. 23, 2010

Re: [Pharo-project] NetNameResolver strikes back 11177 => 1852 1853 :(

by Schwab,Wilhelm K

Stef, I am convinced that not all accesses to ipv6 primitives are protected by #useOldNetwork. See the NetNameResolver thread from July 2009. 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 23, 2010 4:49 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NetNameResolver strikes back 11177 => 1852 1853 :( thanks I still have the impression that all the access to netnameresolver are not using the old access... Stef On Jan 23, 2010, at 9:40 AM, Levente Uzonyi wrote: > Try this: > > bag := Bag new. > (MCHttpRepository > location: 'http://www.squeaksource.com/Pharo' > user: '' password: '') allFileNames do:[:fname| > (fname endsWith: '.mcz') ifTrue:[ > bag add: ((fname copyAfterLast: $-) copyUpTo: $.)]]. > bag sortedCounts. > > > Levente > > On Sat, 23 Jan 2010, StÃ©phane Ducasse wrote: > >> bag := Bag new. >> (MCHttpRepository >> location: 'http://www.squeaksource.org/pharo' >> user: '' password: '') allFileNames do:[:fname| >> (fname endsWith: '.mcz') ifTrue:[ >> bag add: ((fname copyAfterLast: $-) copyUpTo: $.)]]. >> bag sortedCounts. >> >> -> NetNameResolver primitive failed. >> >> Stef >> >> _______________________________________________ >> 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. 23, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by laurent laffont

Thanks for this info. **** In squeak vm: SmalltalkImage current listBuiltinModules #('ADPCMCodecPlugin 26 August 2009 (i)' 'AsynchFilePlugin 26 August 2009 (i)' 'BMPReadWriterPlugin 26 August 2009 (i)' 'B2DPlugin 26 August 2009 (i)' 'BitBltPlugin 26 August 2009 (i)' 'CroquetPlugin 26 August 2009 (i)' 'DSAPrims 26 August 2009 (i)' 'ZipPlugin 26 August 2009 (i)' 'DropPlugin 26 August 2009 (i)' 'FFTPlugin 26 August 2009 (i)' 'FilePlugin 26 August 2009 (i)' 'FloatArrayPlugin 26 August 2009 (i)' 'FloatMathPlugin 26 August 2009 (i)' 'GeniePlugin v2.0 26 August 2009 (i)' 'JPEGReadWriter2Plugin 26 August 2009 (i)' 'JPEGReaderPlugin 26 August 2009 (i)' 'JoystickTabletPlugin 26 August 2009 (i)' 'Klatt 26 August 2009 (i)' 'LargeIntegers v1.5 26 August 2009 (i)' 'LocalePlugin 26 August 2009 (i)' 'Matrix2x3Plugin 26 August 2009 (i)' 'MiscPrimitivePlugin 26 August 2009 (i)' 'RePlugin 26 August 2009 (i)' 'SecurityPlugin 26 August 2009 (i)' 'SerialPlugin 26 August 2009 (i)' 'SocketPlugin 26 August 2009 (i)' 'SoundCodecPrims 26 August 2009 (i)' 'SoundGenerationPlugin 26 August 2009 (i)' 'SoundPlugin 26 August 2009 (i)' 'StarSqueakPlugin 26 August 2009 (i)' 'SurfacePlugin Sep 16 2009 (i)') SmalltalkImage current listLoadedModules #('LargeIntegers v1.5 26 August 2009 (i)' 'B2DPlugin 26 August 2009 (i)' 'BitBltPlugin 26 August 2009 (i)' 'SecurityPlugin 26 August 2009 (i)' 'FilePlugin 26 August 2009 (i)' 'MiscPrimitivePlugin 26 August 2009 (i)') ***** Exupery vm SmalltalkImage current listBuiltinModules #('ExuperyPlugin 27 February 2009 (i)') SmalltalkImage current listLoadedModules #('LargeIntegers v1.5 27 February 2009 (e)' 'FT2Plugin 27 February 2009 (e)' 'B2DPlugin 27 February 2009 (e)' 'BitBltPlugin 8 April 2009 (e)' 'SecurityPlugin 27 February 2009 (e)' 'FilePlugin 27 February 2009 (e)' 'MiscPrimitivePlugin 27 February 2009 (e)' And in exupery: Laurent On Sat, Jan 23, 2010 at 6:38 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Sat, Jan 23, 2010 at 09:51:51AM -0600, Miguel Enrique Cob? Martinez > wrote: > > El s??b, 23-01-2010 a las 15:17 +0100, Mariano Martinez Peck escribi??: > > > > > > 2010/1/23 laurent laffont <laurent.laffont(a)gmail.com> > > > I lack knowledge :( > > > > > > me too :) Don't worry. We are all trying to do our best. > > > > > > how can I enable / disable a plugin ? > > > > > > I don't know if this is possible. Maybe in some Linux/Mac distros > > > maybe how can just delete the files, but in Windows for example, I > > > think they are build inside the vm... > > > > > > What can I check more precisely ? > > > > > > > > > > > > I think with this: " SmalltalkImage current listLoadedModules" > > > > I my squeakvm: > > > > 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 > > Debian GNU/Linux Squeeze amd64 > > > > gives: > > > > #('LargeIntegers v1.5 26 August 2009 (i)' 'B2DPlugin 26 August 2009 > > (i)' 'BitBltPlugin 26 August 2009 (i)' 'SecurityPlugin 26 August 2009 > > (i)' 'FilePlugin 26 August 2009 (i)' 'MiscPrimitivePlugin 26 August 2009 > > (i)') > > There is also SmalltalkImage current listBuiltinModules, which lists the > modules that are compiled into the VM executable, as opposed to "external" > modules that are in shared libraries (.dll or .so files). > > The available plugins are those that appear in #listBuiltinModules, plus > any external plugins that the VM can find in shared libraries. If you > look at #listBuiltinModules plus the shared libraries you have in your > installation, that will tell you the available plugins. > > The #listLoadedModules are the plugins (internal and external) that > your image has actually used since you last restarted it, so you have > to actually do something in Smalltalk that uses a plugin before it will > show up in #listLoadedModules. > > When you inspect the list of loaded modules, you will notice either '(i)' > or '(e)' to indicate whether the loaded module is an internal plugin > or and external plugin. For example, 'BitBltPlugin 20 January 2010 (i)' > indicates that the BitBltPlugin was loaded from a module that was compiled > into the VM executable, and 'UnixOSProcessPlugin 20 January 2010 (e)' > indicates a module that was loaded from an external shared library. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 23, 2010