July 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Operating Smalltalkhub from Pharo

by Damien Cassou

https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/? There is an undocumented REST API that the Amber client uses. On Sun, Jul 27, 2014 at 2:23 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I wonder if there is a way to operate smalltalkhub from pharo. What would > interest me is to browser smalltalkhub from pharo and do anything I can do > from the website with pharo. > > I am new with these things so I assume Zinc would be useful here , no ? > > is there any docs for smalltalkhub api ? > > Anyone tried something similar before ? > > I tried to load Smalltalkub configuration but it looks like that the config > does not define neither a stable or a developement version . -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Norbert Hartl

Am 28.07.2014 um 11:51 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > But it _is_ more work than having it as a local subpart of some larger project. Slightly ;) Who does not properly package and document his own stuff? Wait â¦. the original author seems to be a Kent Beck. Anyone knows him? :) Norbert

July 28, 2014

Re: [Pharo-dev] Configuration readonly archives

by Stephan Eggermont

Stef wrote >I agree. This is why I also think that released should point to version >and not symbolic version. I strongly disagree. A configuration should only change when there is a meaningful change. Changes in dependencies that do not change relevant behavior should not propagate. We achieve that by using #'releasex.x' style versioning. Changes that are not supposed to change observable behavior and bug fixes get new numbered versions within the release. #development versions are updated in place. In Moose we did not encounter a situation where a month-old numbered version configuration was still loadable in the latest Pharo. There is a use case for snapshots of exact versions. They don't belong in configurations. Focussing improvements in Versioner on releasing more often numbered versions is counter productive. It just generates more work to keep configurations working. I have been fixing lots of configurations on ci, and nearly all problems have to do with not using #'releasex.x' style symbolic versioning. There are two problems: - Configurations using numbered versions. They break as soon as a dependent project changes functionality or does a bug fix, often as a result of underlying code in Pharo changing. - Configurations using #stable, where the dependent project does a new release. Now Seaside, Grease and Magritte have switched to this style of versioning, the number of problems has reduced drastically. Stephan

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Sven Van Caekenberghe

On 28 Jul 2014, at 11:45, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 28.07.2014 um 11:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 28 Jul 2014, at 11:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >>> On 28 Jul 2014, at 11:15, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> >>>> >>>> On 21 Jul 2014, at 3:34 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>>> >>>>> On 21 Jul 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>>> >>>>>> On 21/7/14 08:46, Torsten Bergmann wrote: >>>>>>> DALI >>>>>>> http://ss3.gemstone.com/ss/DALi.html >>>>>>> >>>>>>> VOYAGE >>>>>>> http://smalltalkhub.com/#!/~estebanlm/Voyage >>>>>> >>>>>> I do not know if there are back ends for something else than mongo in Voyage. >>>>> >>>>> certainly not for GOODS :) >>>>> actually we have just âin memoryâ and âmongoâ (in memory works fine when deploying on gemstone, for example) >>>>> I always want to add more backends but wellâ¦ time, time, timeâ¦ >>>>> >>>>> Esteban >>>> >>>> Iâm intending to add one for Riak, in an unspecified amount of time, depending on my other workloadâ¦ >>>> Iâd like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first. >> >> It would be good to have a ProtoBuffers implementation that is separate. >> The same goes for the BSON implementation hidden in StHub. >> > The BSON code should be loadable without MongoTalk. It is separate packages. Or do you mean a separate repository would be better? With separate I mean: being managed, documented, advertised, tested and used as such, it is more a mindset than how this is exactly done. Someone needs it for something new, point them to the right place and they are off. Protocols are (should be) ideal building blocks. But it _is_ more work than having it as a local subpart of some larger project. > IMHO it would be sufficient to find it but smalltalkhub isn't helpful in this respect. > > Norbert > >>>> The progress so far is I got the PB serializer almost done (sidetracked by wanting an NB-based UTF8 converter to make it more performant), but I havenât started the PB message parser yet, nor the actual Riak backend. >>> >>> I was intending to add Riak support too :) >>> Do you want access to the repo, so we keep all together? (and then I can check and maybe collaborate) >>> and btw, are you using/checking Phriak? >>> >>> Esteban >>> >>>> >>>> Cheers, >>>> Henry

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Norbert Hartl

Am 28.07.2014 um 11:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 28 Jul 2014, at 11:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 28 Jul 2014, at 11:15, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> >>> On 21 Jul 2014, at 3:34 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> >>>> On 21 Jul 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: >>>> >>>>> >>>>> On 21/7/14 08:46, Torsten Bergmann wrote: >>>>>> DALI >>>>>> http://ss3.gemstone.com/ss/DALi.html >>>>>> >>>>>> VOYAGE >>>>>> http://smalltalkhub.com/#!/~estebanlm/Voyage >>>>> >>>>> I do not know if there are back ends for something else than mongo in Voyage. >>>> >>>> certainly not for GOODS :) >>>> actually we have just âin memoryâ and âmongoâ (in memory works fine when deploying on gemstone, for example) >>>> I always want to add more backends but wellâ¦ time, time, timeâ¦ >>>> >>>> Esteban >>> >>> Iâm intending to add one for Riak, in an unspecified amount of time, depending on my other workloadâ¦ >>> Iâd like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first. > > It would be good to have a ProtoBuffers implementation that is separate. > The same goes for the BSON implementation hidden in StHub. > The BSON code should be loadable without MongoTalk. It is separate packages. Or do you mean a separate repository would be better? IMHO it would be sufficient to find it but smalltalkhub isn't helpful in this respect. Norbert >>> The progress so far is I got the PB serializer almost done (sidetracked by wanting an NB-based UTF8 converter to make it more performant), but I havenât started the PB message parser yet, nor the actual Riak backend. >> >> I was intending to add Riak support too :) >> Do you want access to the repo, so we keep all together? (and then I can check and maybe collaborate) >> and btw, are you using/checking Phriak? >> >> Esteban >> >>> >>> Cheers, >>> Henry

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Norbert Hartl

Am 28.07.2014 um 11:15 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 21 Jul 2014, at 3:34 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 21 Jul 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: >> >>> >>> On 21/7/14 08:46, Torsten Bergmann wrote: >>>> DALI >>>> http://ss3.gemstone.com/ss/DALi.html >>>> >>>> VOYAGE >>>> http://smalltalkhub.com/#!/~estebanlm/Voyage >>> >>> I do not know if there are back ends for something else than mongo in Voyage. >> >> certainly not for GOODS :) >> actually we have just âin memoryâ and âmongoâ (in memory works fine when deploying on gemstone, for example) >> I always want to add more backends but wellâ¦ time, time, timeâ¦ >> >> Esteban > > Iâm intending to add one for Riak, in an unspecified amount of time, depending on my other workloadâ¦ > Iâd like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first. > The progress so far is I got the PB serializer almost done (sidetracked by wanting an NB-based UTF8 converter to make it more performant), but I havenât started the PB message parser yet, nor the actual Riak backend. > Isn't there an implementation from GÃ¶ran Krampe for ProtoBuf? Maybe that is already complete in some sense. Having a Riak backend for voyage would be great. But then there should be some notion to control indices, right? In MongoTalk and Voyage there is nothing like an index. For Mongo indices are separate from the data. In Riak they are not (really) because I think it only works performant if secondary indices are written (being meta/header data) when the data is written. Any opinion on this? Norbert

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Sven Van Caekenberghe

On 28 Jul 2014, at 11:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 28 Jul 2014, at 11:15, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 21 Jul 2014, at 3:34 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >>> On 21 Jul 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: >>> >>>> >>>> On 21/7/14 08:46, Torsten Bergmann wrote: >>>>> DALI >>>>> http://ss3.gemstone.com/ss/DALi.html >>>>> >>>>> VOYAGE >>>>> http://smalltalkhub.com/#!/~estebanlm/Voyage >>>> >>>> I do not know if there are back ends for something else than mongo in Voyage. >>> >>> certainly not for GOODS :) >>> actually we have just âin memoryâ and âmongoâ (in memory works fine when deploying on gemstone, for example) >>> I always want to add more backends but wellâ¦ time, time, timeâ¦ >>> >>> Esteban >> >> Iâm intending to add one for Riak, in an unspecified amount of time, depending on my other workloadâ¦ >> Iâd like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first. It would be good to have a ProtoBuffers implementation that is separate. The same goes for the BSON implementation hidden in StHub. >> The progress so far is I got the PB serializer almost done (sidetracked by wanting an NB-based UTF8 converter to make it more performant), but I havenât started the PB message parser yet, nor the actual Riak backend. > > I was intending to add Riak support too :) > Do you want access to the repo, so we keep all together? (and then I can check and maybe collaborate) > and btw, are you using/checking Phriak? > > Esteban > >> >> Cheers, >> Henry

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Esteban Lorenzano

On 28 Jul 2014, at 11:15, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 21 Jul 2014, at 3:34 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 21 Jul 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: >> >>> >>> On 21/7/14 08:46, Torsten Bergmann wrote: >>>> DALI >>>> http://ss3.gemstone.com/ss/DALi.html >>>> >>>> VOYAGE >>>> http://smalltalkhub.com/#!/~estebanlm/Voyage >>> >>> I do not know if there are back ends for something else than mongo in Voyage. >> >> certainly not for GOODS :) >> actually we have just âin memoryâ and âmongoâ (in memory works fine when deploying on gemstone, for example) >> I always want to add more backends but wellâ¦ time, time, timeâ¦ >> >> Esteban > > Iâm intending to add one for Riak, in an unspecified amount of time, depending on my other workloadâ¦ > Iâd like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first. > The progress so far is I got the PB serializer almost done (sidetracked by wanting an NB-based UTF8 converter to make it more performant), but I havenât started the PB message parser yet, nor the actual Riak backend. I was intending to add Riak support too :) Do you want access to the repo, so we keep all together? (and then I can check and maybe collaborate) and btw, are you using/checking Phriak? Esteban > > Cheers, > Henry

July 28, 2014

Re: [Pharo-dev] Configuration readonly archives

by Stephan Eggermont

Hi FranÃ§ois It sounds like you need snapshots. That has nothing to do with Metacello. Stephan

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Henrik Johansen

On 21 Jul 2014, at 3:34 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 21 Jul 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: > >> >> On 21/7/14 08:46, Torsten Bergmann wrote: >>> DALI >>> http://ss3.gemstone.com/ss/DALi.html >>> >>> VOYAGE >>> http://smalltalkhub.com/#!/~estebanlm/Voyage >> >> I do not know if there are back ends for something else than mongo in Voyage. > > certainly not for GOODS :) > actually we have just âin memoryâ and âmongoâ (in memory works fine when deploying on gemstone, for example) > I always want to add more backends but wellâ¦ time, time, timeâ¦ > > Esteban Iâm intending to add one for Riak, in an unspecified amount of time, depending on my other workloadâ¦ Iâd like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first. The progress so far is I got the PB serializer almost done (sidetracked by wanting an NB-based UTF8 converter to make it more performant), but I havenât started the PB message parser yet, nor the actual Riak backend. Cheers, Henry

July 28, 2014