- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

by Camillo Bruni

its here: http://smalltalkhub.com/mc/dkh/metacello/main => you forgot the /main part On 2013-06-23, at 21:32, "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> wrote: > When I use the following url: > > http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz > > I get: > > /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found > > > instead of my package downloaded ... the mcz file used to be there and it does show up in the listing for > > http://smalltalkhub.com/mc/dkh/metacello/main > > the repository ... In fact none of the packages in the metacello repository are accessible... > > Part of the site must down? > > > Dale > >

June 23, 2013

Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

by Dale K. Henrichs

When I use the following url: http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz I get: /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found instead of my package downloaded ... the mcz file used to be there and it does show up in the listing for http://smalltalkhub.com/mc/dkh/metacello/main the repository ... In fact none of the packages in the metacello repository are accessible... Part of the site must down? Dale

June 23, 2013

Re: [Pharo-dev] Object >> #is:

by Camillo Bruni

On 2013-06-23, at 21:25, Tudor Girba <tudor(a)tudorgirba.com> wrote: > If we want to have an Object>>is:, why not: > > Object>>is: aSymbol > ^ aSymbol = self class name > > ? > > Like this, I do not have to override it unless I need to rely on a > different mechanism. exactly, that is everybody's immediate reaction, except for the method's author ;)..

June 23, 2013

Re: [Pharo-dev] Object >> #is:

by Tudor Girba

If we want to have an Object>>is:, why not: Object>>is: aSymbol ^ aSymbol = self class name ? Like this, I do not have to override it unless I need to rely on a different mechanism. Cheers, Doru On Sun, Jun 23, 2013 at 8:18 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2013-06-23, at 19:19, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Except that if an object both is: this and is: that, from two different > > packages, this will lead to an override. > > from which package? #is: doesn't seem to be used in general > > > 2013/6/23 Sven Van Caekenberghe <sven(a)stfx.eu> > > > >> > >> On 23 Jun 2013, at 18:14, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> > >>> can we remove that, or is this still in use? > >> > >> Hmm, no senders, no implementors, but the idea is not bad: it could > >> replace a lot of methods. And it bears the signature of some illustrious > >> hackersâ¦ > >> > >> Sven > >> > > > -- www.tudorgirba.com "Every thing has its own flow"

June 23, 2013

Re: [Pharo-dev] why so many processes are running at startup time?

by Sven Van Caekenberghe

Camillo, Let's hope you found the problem, make sure to double check with the team over there. I added https://pharo.fogbugz.com/f/cases/10998/Add-ReleaseTest-testUnknownProcesses but this might be hard to make work in practice. Sven On 23 Jun 2013, at 14:47, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I propose to enable again that on image startup the timer scheduling process is restarted. > > https://pharo.fogbugz.com/default.asp?10994 > https://pharo.fogbugz.com/default.asp?10545 > > I am not fully sure of the implications, but it used to be there before and I have less troubles when it is enabled ;) > > On 2013-06-20, at 10:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> I think we should for now just kill them when building the image, I will check. >> >> On Jun 20, 2013, at 9:56 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >>> Hello, >>> >>> These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. >>> Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. >>> We will fix that within a few days. >>> >>> As a workaround, you can just kill these processes in your image for now ... >>> >>> Thanks for reporting the issue, >>> >>> >>> >>> >>> 2013/6/20 NISHIHARA Satoshi <goonsh(a)gmail.com> >>> There are 30 over processes are running at startup, Pharo-20607.image. >>> >>> <NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png> >>> >>> regards. >>> >>> -- >>> -- >>> "NISHIHARA Satoshi" >>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >>> >>> >>> >>> -- >>> ClÃ©ment BÃ©ra >>> Mate Virtual Machine Engineer >>> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> > >

June 23, 2013

Re: [Pharo-dev] Object >> #is:

by Camillo Bruni

On 2013-06-23, at 19:19, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Except that if an object both is: this and is: that, from two different > packages, this will lead to an override. from which package? #is: doesn't seem to be used in general > 2013/6/23 Sven Van Caekenberghe <sven(a)stfx.eu> > >> >> On 23 Jun 2013, at 18:14, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> can we remove that, or is this still in use? >> >> Hmm, no senders, no implementors, but the idea is not bad: it could >> replace a lot of methods. And it bears the signature of some illustrious >> hackersâ¦ >> >> Sven >>

June 23, 2013

Re: [Pharo-dev] First shot on acceptance tests for the VM

by Tudor Girba

+1 Doru On Sat, Jun 22, 2013 at 9:28 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Very nice! > > Another thing we need to look at at some point is to make different VM > build for each major version. > > The idea is that there is a dedicated build of the VM for "Pharo3", which > would be frozen with the release, > and then we start with a VM build for "Pharo4". > > I even want them to have the major version number is the binary, so that > it is easy to install "Pharo3" in Parallel > to "Pharo4". > > With this we free ourselves from needed the VM to be at the same time > forward *and* backward compatible. > And we make sure that the VM that people use for the stable release does > not change. > > Marcus > > On Jun 21, 2013, at 5:08 PM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi! > > We were discussing over here about it, so I decided to finally start > something on the front of an acceptance test for our VM. > > The core idea is to stress the VM to test its stability and find bugs and > regressions. > > So I created the ci job in [1] which does: > - use latest vm > - use 2.0 latest image > - loads seaside and moose on it > - runs all tests > > Right now it runs on 6 different slaves, getting different results on > each, which we should take care about :). > > Also there are some things on it that should be improved easily: > - once 2.0 summer is released this job should use that version instead of > the "latest" 2.0 > - right now we are loading the development version of moose because moose > 4.8 is not released (but will be soon :) > > And of course, now we have them, we can improve them (and make them run > because not all of them do :D). > > Guille > > [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/ > > > -- www.tudorgirba.com "Every thing has its own flow"

June 23, 2013

Re: [Pharo-dev] First shot on acceptance tests for the VM

by Tudor Girba

Excellent! Doru On Fri, Jun 21, 2013 at 5:08 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi! > > We were discussing over here about it, so I decided to finally start > something on the front of an acceptance test for our VM. > > The core idea is to stress the VM to test its stability and find bugs and > regressions. > > So I created the ci job in [1] which does: > - use latest vm > - use 2.0 latest image > - loads seaside and moose on it > - runs all tests > > Right now it runs on 6 different slaves, getting different results on > each, which we should take care about :). > > Also there are some things on it that should be improved easily: > - once 2.0 summer is released this job should use that version instead of > the "latest" 2.0 > - right now we are loading the development version of moose because moose > 4.8 is not released (but will be soon :) > > And of course, now we have them, we can improve them (and make them run > because not all of them do :D). > > Guille > > [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/ > -- www.tudorgirba.com "Every thing has its own flow"

June 23, 2013

Re: [Pharo-dev] StartupPreference bug?

by StÃ©phane Ducasse

apparently with the latest image it works StartupLoader default executeAtomicItems: { StartupAction name: 'Basic settings' code: [ ^MAuthor fullName: 'MarianoMartinezPeck'.^MDebugger alwaysOpenFullDebugger: true ]. }. so this was probably a problem with the block printing code. Stef On Jun 23, 2013, at 7:30 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > | items | > items := OrderedCollection new. > items add: (StartupAction > name: 'Basic settings' > code: [ > Author fullName: 'MarianoMartinezPeck'. > Debugger alwaysOpenFullDebugger: true.]). > StartupLoader default > addAtStartupInPreferenceVersionFolder: items > named: 'basicSettings.st'. > > generates > > more basicSettings.st > StartupLoader default executeAtomicItems: { > StartupAction name: 'Basic settings' code: [...]. > }. > > > Stef >

June 23, 2013

Re: [Pharo-dev] First shot on acceptance tests for the VM

by Guillermo Polito

On Sat, Jun 22, 2013 at 9:28 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Very nice! > > Another thing we need to look at at some point is to make different VM > build for each major version. > Then we have to branch vm sources on release :) > > The idea is that there is a dedicated build of the VM for "Pharo3", which > would be frozen with the release, > and then we start with a VM build for "Pharo4". > > I even want them to have the major version number is the binary, so that > it is easy to install "Pharo3" in Parallel > to "Pharo4". > > With this we free ourselves from needed the VM to be at the same time > forward *and* backward compatible. > And we make sure that the VM that people use for the stable release does > not change. > > Marcus > > On Jun 21, 2013, at 5:08 PM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi! > > We were discussing over here about it, so I decided to finally start > something on the front of an acceptance test for our VM. > > The core idea is to stress the VM to test its stability and find bugs and > regressions. > > So I created the ci job in [1] which does: > - use latest vm > - use 2.0 latest image > - loads seaside and moose on it > - runs all tests > > Right now it runs on 6 different slaves, getting different results on > each, which we should take care about :). > > Also there are some things on it that should be improved easily: > - once 2.0 summer is released this job should use that version instead of > the "latest" 2.0 > - right now we are loading the development version of moose because moose > 4.8 is not released (but will be soon :) > > And of course, now we have them, we can improve them (and make them run > because not all of them do :D). > > Guille > > [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/ > > >

June 23, 2013