February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Which ConfigurationOfPharo should use in Pharo 1.2 ?

by Dale Henrichs

On Feb 4, 2011, at 6:01 AM, Guillermo Polito wrote: > > Should we remove invalid and unused versions? Good question. I think the first rule of thumb is to never remove a version from a configuration. Once you have published a configuration you don't know if someone else has referenced a published version in their configuration and if you remove the version you will break their configuration. Removing a configuration version is the moral equivalent of deleting an mcz file from a repository...it only hurts the other folks that depend upon the file. Sooo, it follows that a) if you don't think any is using the version and b) you don't mind if you break someone else's configuration then you can go ahead and remove the version...in the case of an emergency, the removed version can be restored from and older version of the configuration mcz file ... Dale

Feb. 4, 2011

Re: [Pharo-project] Which ConfigurationOfPharo should use in Pharo 1.2 ?

by Marcus Denker

On Feb 4, 2011, at 2:53 PM, GermÃ¡n Arduino wrote: > I tried the 2 latest Beta and fail, also the 1.1 version fail. > > Which ConfigurationOfPharo I should use with Pharo 1.2 ? > > Deprecation raiseWarning: false. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. ((Smalltalk at: #ConfigurationOfPharo) project lastVersion) perform: #silently: with: true; perform: #load. You can always download the latest image here: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastSuccessfulBuild/… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 4, 2011

Re: [Pharo-project] Which ConfigurationOfPharo should use in Pharo 1.2 ?

by Guillermo Polito

Dale, Is there a place where I can read how to configure the symbolic versions? Thx! Guille :) On Fri, Feb 4, 2011 at 11:29 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > ConfigurationOfPharo should have a #stable symbolic version defined that > specifies the version that should be used in 1.2, 1.1, and 1.0 ... then one > just loads the #stable version: > > (ConfigurationOfPharo project version: #stable) load > > and you'll get the right version loaded for the platform version ... even > though the version is under development I think it is valid to specify a > #stable symbolic version for Pharo1.2, just so folks don't have to ask this > question over and over again ... Don't let the name 'stable' scare you ... > > The intent is that the #stable symbolic version specifies the version that > should be loaded .... the developer decides which versions are #stable for > each platform version and when a new version becomes "the version to use" > the developer updates the specification. > > The users of a configuration shouldn't have to think ... remember in the > past the recommended pattern was: > > ConfigurationOfPharo project latestVersion load > > and that worked fine until Pharo1.1 and Pharo1.2 were introduced. The > expression: > > (ConfigurationOfPharo project version: #stable) load > > is intended to replace the use of #latestVersion because it makes it > possible to explicitly specify the "latest version" on a platform by > platform and platform version basis... > > Sorry if I appear to be ranting ... I'm just trying to get the message > out:) > > Dale > > On Feb 4, 2011, at 6:01 AM, Guillermo Polito wrote: > > I'm Using '1.2-beta2'. > > Should we remove invalid and unused versions? I'll add a few comments at > lunch time ;) > > On Fri, Feb 4, 2011 at 10:53 AM, GermÃ¡n Arduino <garduino(a)gmail.com > <mailto:garduino@gmail.com>> wrote: > I tried the 2 latest Beta and fail, also the 1.1 version fail. > > Which ConfigurationOfPharo I should use with Pharo 1.2 ? > > Cheers. > > > > >

Feb. 4, 2011

Re: [Pharo-project] Hudson build for Seaside too?

by Marcus Denker

> On Feb 3, 2011, at 5:05 PM, Torsten Bergmann wrote: > >> OK - we have the hudson build for Pharo Core, Pharo, Moose, ... >> >> Since Pharo is the reference platform for Seaside >> wouldnt it make sense to run a hudson build for >> Seaside too: >> >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfSeaside30'; >> load. >> >> ((Smalltalk at: #ConfigurationOfSeaside30) project latestVersion) load. >> Hudson now build a Seaside image and runs all tests after the Full image 1.2 build: https://pharo-ic.lille.inria.fr/hudson/job/Seaside%20on%20Pharo%201.2/ TODO: 1.3, after fixing the Full 1.3 build. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 4, 2011

Re: [Pharo-project] Which ConfigurationOfPharo should use in Pharo 1.2 ?

by Dale Henrichs

ConfigurationOfPharo should have a #stable symbolic version defined that specifies the version that should be used in 1.2, 1.1, and 1.0 ... then one just loads the #stable version: (ConfigurationOfPharo project version: #stable) load and you'll get the right version loaded for the platform version ... even though the version is under development I think it is valid to specify a #stable symbolic version for Pharo1.2, just so folks don't have to ask this question over and over again ... Don't let the name 'stable' scare you ... The intent is that the #stable symbolic version specifies the version that should be loaded .... the developer decides which versions are #stable for each platform version and when a new version becomes "the version to use" the developer updates the specification. The users of a configuration shouldn't have to think ... remember in the past the recommended pattern was: ConfigurationOfPharo project latestVersion load and that worked fine until Pharo1.1 and Pharo1.2 were introduced. The expression: (ConfigurationOfPharo project version: #stable) load is intended to replace the use of #latestVersion because it makes it possible to explicitly specify the "latest version" on a platform by platform and platform version basis... Sorry if I appear to be ranting ... I'm just trying to get the message out:) Dale On Feb 4, 2011, at 6:01 AM, Guillermo Polito wrote: I'm Using '1.2-beta2'. Should we remove invalid and unused versions? I'll add a few comments at lunch time ;) On Fri, Feb 4, 2011 at 10:53 AM, GermÃ¡n Arduino <garduino(a)gmail.com<mailto:garduino@gmail.com>> wrote: I tried the 2 latest Beta and fail, also the 1.1 version fail. Which ConfigurationOfPharo I should use with Pharo 1.2 ? Cheers.

Feb. 4, 2011

Re: [Pharo-project] Metacello issue on Linux

by Igor Stasenko

On 4 February 2011 14:21, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Igor, > > I don't have a PharoCore1.3....what's the name of the mcz file that is being written? > > I would guess that monticello is trying to make a copy of the file in the package-cache when there is already an existing copy ... > > Do you happen to be using the package-cache as your source repository? > We tracked down this bug. It is related to retrieving entries of directory on linux. For some unknown reason 'self allFileNames' in: MCCacheRepository>>basicStoreVersion: aVersion (aVersion isCacheable and: [self allFileNames includes: aVersion fileName]) ifFalse: [super basicStoreVersion: aVersion] answers an empty collection. And all it does is just queries the package-cache dir for its entries. What is strange that after i evaluated the (FileDirectory default / 'package-cache' )entries and then re-evaluated same thing in method above, it worked, and retrieved the entries for package-cache dir. The VM i using is: Smalltalk vmVersion 'Squeak4.1 of 17 April 2010 [latest update: #9957]' (half hour later) i suspected that this is because i mounted mac-os host system directory in my linux virtual machine filesystem, and there is something not ok with. After moving image to 'linux' server file system dir, everything works ok... So, it appears that the bug in virtualbox filesystem :)) Sorry for false alarm :) > Dale -- Best regards, Igor Stasenko AKA sig.

Feb. 4, 2011

Re: [Pharo-project] Which ConfigurationOfPharo should use in Pharo 1.2 ?

by Guillermo Polito

I'm Using '1.2-beta2'. Should we remove invalid and unused versions? I'll add a few comments at lunch time ;) On Fri, Feb 4, 2011 at 10:53 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > I tried the 2 latest Beta and fail, also the 1.1 version fail. > > Which ConfigurationOfPharo I should use with Pharo 1.2 ? > > Cheers. > >

Feb. 4, 2011

[Pharo-project] Which ConfigurationOfPharo should use in Pharo 1.2 ?

by GermÃ¡n Arduino

I tried the 2 latest Beta and fail, also the 1.1 version fail. Which ConfigurationOfPharo I should use with Pharo 1.2 ? Cheers.

Feb. 4, 2011

Re: [Pharo-project] Network training

by Noury Bouraqadi

On 4 fÃ©vr. 2011, at 12:38, jannik.laval wrote: > > On Feb 4, 2011, at 09:48 , Igor Stasenko wrote: > >> On 4 February 2011 09:19, Laval Jannik <jannik.laval(a)gmail.com> wrote: >>> but how can i find these ip address in pharo? >>> >>> >> perhaps by writing new primitive :) >> > Is there one already existing ? > I don't think so. An alternative might be to use an Ocean-like approach and call OS features directly through some FFI. > Now, another thing, the method: NetNameResolver>>isConnected. > Inside there is this code: > > === > isConnected > "Dirty, but avoids fixing the plugin bug" > [NetNameResolver addressForName: 'www.esug.org'.] on: NameLookupFailure do: [:ex| ^false]. > ^true > === > > The comment is clear... is the plugin bug fixed ? > No. Luc and I decided that it does not worth it struggling with the plugin. This is why we initiated the Ocean project (plugin-free networking) available on SqueakSource. We made interesting (though slow) progress so far. Currently we have a complete library for TCP client socket. For the server socket to be usable we need multithreading Alien which is not available yet. Hope Eliot will have time to work on this soon or may be we'll get NativeBoost working on all major platforms (Go Igore!!!). Instead of remaining stalled or hacking some temporary solution, we changed a bit our strategy in order to have (hopefully) support for TCP sockets ready for Pharo 1.3. Our idea is that the limitations of networking problem have 2 origins: The poor library and the plugin. We decided to put all our effort on the library and having it work with the plugin. We are re-writing it fully with tests. Our design is independent of the low-level network support (Bridge pattern). So, we can (didn't test yet) be able to work either with the plugin or with any external networking library, through Alien or other FFI. Once we'll be done with the library, we'll tackle the plugin issue. The Ocean is wide, we have to row a lot ;-) Noury

Feb. 4, 2011

Re: [Pharo-project] thinking about a community model of funding

by GermÃ¡n Arduino

hahaha, We need a little laughter too, is not necessary to work with a frown :) 2011/2/4 Igor Stasenko <siguctua(a)gmail.com>: > On 4 February 2011 14:13, Geert Claes <geert.wl.claes(a)gmail.com> wrote: >> >> A bit of a laugh, it's Friday after all :) >> > > There's better photos > http://www.google.com/images?q=stephane+ducasse&biw=2560&bih=1248 > > like this one: > > http://t0.gstatic.com/images?q=tbn:ANd9GcQ0Yjzjbrwnaq8Y0fyu1rY8VCqEEhhRZEl9… > >> http://forum.world.st/file/n3260143/PharoBoardAppeal2.png >> >> -- >> View this message in context: http://forum.world.st/thinking-about-a-community-model-of-funding-tp3259753… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 4, 2011