October 2013 - Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=li… 4 regressions found. Manifest.Tests.SmalllintManifestCheckerTest.testCriticsOf Manifest.Tests.SmalllintManifestCheckerTest.testIsFalsePositive Manifest.Tests.SmalllintManifestCheckerTest.testIsToDo Manifest.Tests.SmalllintManifestCheckerTest.testToDoOf

Oct. 3, 2013

[update 3.0] #30444

by Marcus Denker

30444 ----- 11762 update #cleanUpForProduction https://pharo.fogbugz.com/f/cases/11762 11764 unload Refactoring-Spelling https://pharo.fogbugz.com/f/cases/11764 11763 clean up Refactoring-Critics-Unused https://pharo.fogbugz.com/f/cases/11763 11761 class StrikeFontFixer is undocumented and the only users not called https://pharo.fogbugz.com/f/cases/11761 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1288.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Fonts-MarcusDenker.8…

Oct. 3, 2013

[update 3.0] #30444

by Marcus Denker

30444 ----- 11762 update #cleanUpForProduction https://pharo.fogbugz.com/f/cases/11762 11764 unload Refactoring-Spelling https://pharo.fogbugz.com/f/cases/11764 11763 clean up Refactoring-Critics-Unused https://pharo.fogbugz.com/f/cases/11763 11761 class StrikeFontFixer is undocumented and the only users not called https://pharo.fogbugz.com/f/cases/11761 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1288.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Fonts-MarcusDenker.8…

Oct. 3, 2013

Re: [Pharo-dev] Monticello requiring network access to save a package in a local repository?

by Esteban Lorenzano

yep :) you could transform the hack into a nice preference, you know... I would be happy to integrate that :) Esteban ps: for those who doesn't know it, I showed Phil how I cheat Pharo3 to load Pharo2 configurations, which is... just to override #metacelloPlatformAttributes :) That way I can easily test packages from Ph2 into Ph3 (Btw, so far, everything I tested works, with the unique exception of FFI/Alien). Then we thought that a preference "threat this image as compatible with Pharo2" would be cool, to easy the migration of packages :) On Oct 3, 2013, at 8:12 PM, phil(a)highoctane.be wrote: > I for sure can. > > So, this is gone in 3.0 and if I do the "magic trick" you showed us during the Hangout, all we be fine, right? > > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Pharo Consortium Member - http://consortium.pharo.org/ > Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller > > > > > On Thu, Oct 3, 2013 at 7:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yes. Also the name repetition is a) very improbably anyway and 2) nobody cares (or at lease, MC does not cares) > > the only problem that could happen is in the remote case where you could want to join repositories previously separated. > We think we can live with that potential problem :) > > Esteban > > On Oct 3, 2013, at 6:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > We were fed up about that and we made sure that we can work off line (and not checking all the repositories on earth) in 3.0 with esteban > > > > On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases. > >> > >> We once thought about making this check optional (and a setting). > >> > >> One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried. > >> > >> On 03 Oct 2013, at 15:58, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> > >>> Hello, > >>> > >>> Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access. > >>> > >>> Why is it so? > >>> > >>> I was working without network access and this bite me. > >>> > >>> I was able to get out of trouble with my Phone as an access point. > >>> > >>> But for some scenarios (w/ security and no external network access) this is really a pain. > >>> > >>> Also, the fact that I had to do a Cmd-. to get out of this is annyoying. > >>> > >>> Clues? > >>> > >>> Phil > >> > >> > > > > > > >

Oct. 3, 2013

Re: [Pharo-dev] Monticello requiring network access to save a package in a local repository?

by phil＠highoctane.be

I for sure can. So, this is gone in 3.0 and if I do the "magic trick" you showed us during the Hangout, all we be fine, right? --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Thu, Oct 3, 2013 at 7:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > yes. Also the name repetition is a) very improbably anyway and 2) nobody > cares (or at lease, MC does not cares) > > the only problem that could happen is in the remote case where you could > want to join repositories previously separated. > We think we can live with that potential problem :) > > Esteban > > On Oct 3, 2013, at 6:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > We were fed up about that and we made sure that we can work off line > (and not checking all the repositories on earth) in 3.0 with esteban > > > > On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> Yes, that is what Monticello does on a save: check for potential name > conflicts in all linked repositories. It is just the way it is. It is not a > 100% foolproof way to guarantee uniqueness, but it will help in certain > cases. > >> > >> We once thought about making this check optional (and a setting). > >> > >> One way out might be to remove all but the package-cache from the > repositories linked to your package, but I haven't tried. > >> > >> On 03 Oct 2013, at 15:58, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > >> > >>> Hello, > >>> > >>> Monticello goes fetching a unique number in the previous version of a > given package on Smallatkhub and that means requiring network access. > >>> > >>> Why is it so? > >>> > >>> I was working without network access and this bite me. > >>> > >>> I was able to get out of trouble with my Phone as an access point. > >>> > >>> But for some scenarios (w/ security and no external network access) > this is really a pain. > >>> > >>> Also, the fact that I had to do a Cmd-. to get out of this is > annyoying. > >>> > >>> Clues? > >>> > >>> Phil > >> > >> > > > > > > >

Oct. 3, 2013

Re: [Pharo-dev] Monticello requiring network access to save a package in a local repository?

by Camillo Bruni

That cannot happen on smalltalkhub. duplicated version names are not accepted. There are 16 projects on source.squeak.org, that should have a low probability to happen again... On 2013-10-03, at 19:46, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Beware, I got bitten recently on Squeak-trunk and I have overriden an > existing package by publishing twice with same name... > This is because the Squeak version does silently ignore if there was a > previous version in the package-cache. > And because source.squeak.org just accepts to override... > > > > 2013/10/3 Esteban Lorenzano <estebanlm(a)gmail.com> > >> yes. Also the name repetition is a) very improbably anyway and 2) nobody >> cares (or at lease, MC does not cares) >> >> the only problem that could happen is in the remote case where you could >> want to join repositories previously separated. >> We think we can live with that potential problem :) >> >> Esteban >> >> On Oct 3, 2013, at 6:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >>> We were fed up about that and we made sure that we can work off line >> (and not checking all the repositories on earth) in 3.0 with esteban >>> >>> On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> Yes, that is what Monticello does on a save: check for potential name >> conflicts in all linked repositories. It is just the way it is. It is not a >> 100% foolproof way to guarantee uniqueness, but it will help in certain >> cases. >>>> >>>> We once thought about making this check optional (and a setting). >>>> >>>> One way out might be to remove all but the package-cache from the >> repositories linked to your package, but I haven't tried. >>>> >>>> On 03 Oct 2013, at 15:58, "phil(a)highoctane.be" <phil(a)highoctane.be> >> wrote: >>>> >>>>> Hello, >>>>> >>>>> Monticello goes fetching a unique number in the previous version of a >> given package on Smallatkhub and that means requiring network access. >>>>> >>>>> Why is it so? >>>>> >>>>> I was working without network access and this bite me. >>>>> >>>>> I was able to get out of trouble with my Phone as an access point. >>>>> >>>>> But for some scenarios (w/ security and no external network access) >> this is really a pain. >>>>> >>>>> Also, the fact that I had to do a Cmd-. to get out of this is >> annyoying. >>>>> >>>>> Clues? >>>>> >>>>> Phil >>>> >>>> >>> >>> >> >> >>

Oct. 3, 2013

Re: [Pharo-dev] Monticello requiring network access to save a package in a local repository?

by Nicolas Cellier

Beware, I got bitten recently on Squeak-trunk and I have overriden an existing package by publishing twice with same name... This is because the Squeak version does silently ignore if there was a previous version in the package-cache. And because source.squeak.org just accepts to override... 2013/10/3 Esteban Lorenzano <estebanlm(a)gmail.com> > yes. Also the name repetition is a) very improbably anyway and 2) nobody > cares (or at lease, MC does not cares) > > the only problem that could happen is in the remote case where you could > want to join repositories previously separated. > We think we can live with that potential problem :) > > Esteban > > On Oct 3, 2013, at 6:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > We were fed up about that and we made sure that we can work off line > (and not checking all the repositories on earth) in 3.0 with esteban > > > > On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> Yes, that is what Monticello does on a save: check for potential name > conflicts in all linked repositories. It is just the way it is. It is not a > 100% foolproof way to guarantee uniqueness, but it will help in certain > cases. > >> > >> We once thought about making this check optional (and a setting). > >> > >> One way out might be to remove all but the package-cache from the > repositories linked to your package, but I haven't tried. > >> > >> On 03 Oct 2013, at 15:58, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > >> > >>> Hello, > >>> > >>> Monticello goes fetching a unique number in the previous version of a > given package on Smallatkhub and that means requiring network access. > >>> > >>> Why is it so? > >>> > >>> I was working without network access and this bite me. > >>> > >>> I was able to get out of trouble with my Phone as an access point. > >>> > >>> But for some scenarios (w/ security and no external network access) > this is really a pain. > >>> > >>> Also, the fact that I had to do a Cmd-. to get out of this is > annyoying. > >>> > >>> Clues? > >>> > >>> Phil > >> > >> > > > > > > >

Oct. 3, 2013

Re: [Pharo-dev] Monticello requiring network access to save a package in a local repository?

by Esteban Lorenzano

yes. Also the name repetition is a) very improbably anyway and 2) nobody cares (or at lease, MC does not cares) the only problem that could happen is in the remote case where you could want to join repositories previously separated. We think we can live with that potential problem :) Esteban On Oct 3, 2013, at 6:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > We were fed up about that and we made sure that we can work off line (and not checking all the repositories on earth) in 3.0 with esteban > > On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases. >> >> We once thought about making this check optional (and a setting). >> >> One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried. >> >> On 03 Oct 2013, at 15:58, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Hello, >>> >>> Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access. >>> >>> Why is it so? >>> >>> I was working without network access and this bite me. >>> >>> I was able to get out of trouble with my Phone as an access point. >>> >>> But for some scenarios (w/ security and no external network access) this is really a pain. >>> >>> Also, the fact that I had to do a Cmd-. to get out of this is annyoying. >>> >>> Clues? >>> >>> Phil >> >> > >

Oct. 3, 2013

Re: [Pharo-dev] [update 3.0] #30443

by Marcus Denker

On Oct 3, 2013, at 5:15 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30443 > ----- > > 11757 NautilusMCBindings misses a reset method > https://pharo.fogbugz.com/f/cases/11757 > Now the image is 3MB Smallerâ¦ (and yes, cleaning up is just a workaround) Marcus

Oct. 3, 2013

Re: [Pharo-dev] StackVM on RaspberryPi

by Esteban Lorenzano

On Oct 3, 2013, at 5:37 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > Using Nick's process for compiling the vm I reintroduce a process to compile StackVM on Rasp. > So we have a StackVM compiling process on Rasp, with a simple CMakeConfiguration class and a simple install script for Rasp. > Next step is to recompile from Rasp. very cool, thanks! > > One question remain: > Where are / what is the working configuration for fastBitBlt (for arm)? > Mindlessly add all sources files seems do not work (the FAST_PATH macro seems not called). fast path sources are included in current vm sources (in github), but not taken into account for build the VM (bah, just the general parts, not the ones that should increase bitblt performance). If you want to look at them, they are in Cross/Plugins/BitBltPlugin there are a lot of those .s files that you love some much :D Esteban > > > Best Regards > Dr Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > >

Oct. 3, 2013