- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] ReloadByMonticello job green again

by Camillo Bruni

I like this progress!! very nice work. On 2013-10-03, at 18:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Excellent I will use it to continue my modular quest. > > Now I should propose a configuration for > Keymapping > Nautilus > Ring > â¦ > and a couple of others > > then I want to start to work on the package sturcture and configuration of the pharo image. > > Stef > > On Oct 3, 2013, at 4:01 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi, >> >> we are again able to load the Morphic and tools to the shrinked image. >> . >> https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… >> >> Cheers, >> -- Pavel >> > >

Oct. 3, 2013

Re: [Pharo-dev] ReloadByMonticello job green again

by StÃ©phane Ducasse

Excellent I will use it to continue my modular quest. Now I should propose a configuration for Keymapping Nautilus Ring â¦ and a couple of others then I want to start to work on the package sturcture and configuration of the pharo image. Stef On Oct 3, 2013, at 4:01 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > we are again able to load the Morphic and tools to the shrinked image. > . > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… > > Cheers, > -- Pavel >

Oct. 3, 2013

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

by StÃ©phane Ducasse

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

StackVM on RaspberryPi

by Jean Baptiste Arnaud

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. 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). Best Regards Dr Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Oct. 3, 2013

Re: [Pharo-dev] ReloadByMonticello job green again

by Marcus Denker

On Oct 3, 2013, at 4:01 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > we are again able to load the Morphic and tools to the shrinked image. > . > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… > Very nice! Marcus

Oct. 3, 2013