- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] rethinking the print it action in Pharo

by Tudor Girba

It will certainly be one of the next steps :) Doru On Mon, Jul 28, 2014 at 10:40 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > So, > > when do we do the syntax errors in the same way? > > Thierry > > Le 28/07/2014 01:33, Tudor Girba a Ã©crit : > > Hi, > > In the course of revamping the Pharo environment, we stumbled across the > print it action and we (Andrei and I) decided to rethink it. > [image: Inline image 1] > > You can find more details here: > http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo > > Let us know what you think. > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

July 28, 2014

Re: [Pharo-dev] rethinking the print it action in Pharo

by Thierry Goubier

So, when do we do the syntax errors in the same way? Thierry Le 28/07/2014 01:33, Tudor Girba a Ã©crit : > Hi, > > In the course of revamping the Pharo environment, we stumbled across > the print it action and we (Andrei and I) decided to rethink it. > Inline image 1 > > You can find more details here: > http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo > > Let us know what you think. > > Cheers, > Doru > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

July 28, 2014

Re: [Pharo-dev] Configuration readonly archives

by stepharo

Salut Francois > We've been bitten a few times at Ta MÃ¨re by the problem of changing > metacello configuration. I agree. This is why I also think that released should point to version and not symbolic version. What I do is that we can use versionner to release more often configurations pointing to the versions. Christophe will continue to improve it. > At the moment, we rely on the policy of "you should never change a > Metacello version once it has been published". Of course this is > fragile and we've ended up with different code loaded in different > environment while we were expecting stuff to be identical. > > Has anyone already tempted to centralize configurations/package in a > read-only place (S3? Azure Storage?). Something like RubyGems or > similar. It may be completely stupid to have centralised system but > I'm not satisfied with the infastructure supporting our configurations. > > Am I the only one having this problem? How do you handle it? We are discussing in the team - I was thinking that each project/package should have its own configuration saved in his repo. -- then the developer may choose to publish it to a central place. - other are telling to me that other language have a central place. This is ok too. I would like to have a catalog of frozen versions per pharo version. Now this is two years that we request an engineering to build a project validator and a catalog but we failed. Stef

July 28, 2014

Configuration readonly archives

by FranÃ§ois Stephany

We've been bitten a few times at Ta MÃ¨re by the problem of changing metacello configuration. At the moment, we rely on the policy of "you should never change a Metacello version once it has been published". Of course this is fragile and we've ended up with different code loaded in different environment while we were expecting stuff to be identical. Has anyone already tempted to centralize configurations/package in a read-only place (S3? Azure Storage?). Something like RubyGems or similar. It may be completely stupid to have centralised system but I'm not satisfied with the infastructure supporting our configurations. Am I the only one having this problem? How do you handle it?

July 28, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40130 Home: https://github.com/pharo-project/pharo-core

July 28, 2014