November 2015 - Pharo-users

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 30/11/15 12:34, Dimitris Chloupis wrote: > let me give you the thinking of someone that comes from another language > > "What is this ? Ah Pharo > What features it has ? Ah thats some nice cool features, live coding > looks sweet > How about version control ? Hmm no its too weak and their website for > hosting repos is problematic in many cases > Maybe I could use git which I am familiar with ? Ah yes.... but wait > there are many limitations > How about big repos that git excels at ? Nope it crashes Pharo VM. > Maybe I could use X because I'm familiar with is the proper argument if is not taken too far. Interface with the external world without a forceful coupling to X1 should be the approach. > > Things get popular not because they have nicely designed APIs, they > become popular and rightly so and wisely so because they work. Simple > as that. > Considering that several things work in a particular domain (data bases, DVCS, etc) that seems reductive. > I hope at last version control is addressed seriously because its a > real pity Pharo not to be able to use git when there are toy languages > like brainfuck that interface better with it or other version control > system. > > I am not against the idea of an abstraction API for Version Control , > great idea do that, but first let get things working properly so we > dont get people scratching their heads on git merges or people > struggling to find out why sthub is down once again. > With that approach we should get Oracle intimately coupled with Pharo before having Garage or any DB related advance. In fact I'm using NBSQLite for *my* own purposes and needs, but I don't plan it to be the default in the language/environment. May be because pharo goes beyond the language and has and integrated experience, we think in how we can make it smoother for other people, like frameworks which integrate git or sqlite by default, but a proper balance to not enforce my particular tastes over others should be kept also. So I would advice tightly integration for "apps" (Scratch, grafoscopio) and loose one for frameworks/environments (Aida, Seaside, and pharo itself). Cheers, Offray

Nov. 30, 2015

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

by Dimitris Chloupis

just for the usual note, thats my personal opinion and in no way try to discourage people just offer a different perspective to this. I always welcome any effort to improve pharo in any way, even for ways I dont care about so much. So keep up the amazing work you guys are doing with Pharo. On Mon, Nov 30, 2015 at 7:34 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > let me give you the thinking of someone that comes from another language > > "What is this ? Ah Pharo > What features it has ? Ah thats some nice cool features, live coding looks > sweet > How about version control ? Hmm no its too weak and their website for > hosting repos is problematic in many cases > Maybe I could use git which I am familiar with ? Ah yes.... but wait there > are many limitations > How about big repos that git excels at ? Nope it crashes Pharo VM. > > Hmm.. ok Pharo looks like nice toy .... will go back to my language of > choice and use it from time to time for foolish experiments. Notice one > thing here, the user never cares about the flexibility of the API. Bottom > line its not about git, or mecurial, or svn. Its about giving something > that the user can use and right now when it comes to version control Pharo > is light years behind. > > Things get popular not because they have nicely designed APIs, they become > popular and rightly so and wisely so because they work. Simple as that. > > I hope at last version control is addressed seriously because its a real > pity Pharo not to be able to use git when there are toy languages like > brainfuck that interface better with it or other version control system. > > I am not against the idea of an abstraction API for Version Control , > great idea do that, but first let get things working properly so we dont > get people scratching their heads on git merges or people struggling to > find out why sthub is down once again. > > On Mon, Nov 30, 2015 at 7:07 PM EuanM <euanmee(a)gmail.com> wrote: > >> We want a system of small objects with loose-coupling, and simple webs >> of message-sends. This allows us power, flexibility, maintainability >> *and* the opportunity to accommodate new requirements. >> >> We always need to bear this in mind. Build for the inevitable changes >> of environment and changes of requirement. You Ain't Gonna Need it >> (YAGNI) is often true, but well-factored code is *always* good. >> >> On 30 November 2015 at 17:02, EuanM <euanmee(a)gmail.com> wrote: >> > Well, personally, I far prefer Mercurial. Which also dethroned SVN. >> > >> > Mercurial has all the power of Git, while providing a more usable API. >> > My mind works like a Smalltalker's, not like Linus's. >> > >> > It's true, some of the more abstruse functions of git require a longer >> > chain of user actions in Mercurial in order to achieve the same end. >> > But typically, the more common functions are more memorable in >> > Mercurial than in git, and my typical use-cases for a DSCM system are >> > less involved than that of the Linux core. >> > >> > On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >> And there lies the trap. >> >> >> >> If you end up making something that works with everything, you will >> create >> >> something that just works with everything instead of something that >> works >> >> very well with one thing. Right now Git is by very far the undisputed >> king >> >> of version control and has completely dethroned SVN. >> >> >> >> Ironically the things that make git integration in pharo so hard is >> all the >> >> thing that are there to decouple it from git , like filetree metadata >> , or >> >> continuous support for mcz and monticello. >> >> >> >> In the end you cant have your cake and eat it too. We will have to >> choose >> >> between very good integration with git or average / mediocre >> integration >> >> with multiple backends. >> >> >> >> On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo(a)free.fr> wrote: >> >>> >> >>> What I would like for Pharo is to avoid to be bound to a given >> back-end >> >>> for its versionning. >> >>> This master is a step in the right direction >> >>> >> >>> >> >>> >> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_… >> >>> >> >>> Stef >> >>> >> >>> >> >> >> >>

Nov. 30, 2015

Re: [Pharo-users] How fuel deals with circular reference ?

by Dimitris Chloupis

ah very nice client you had :) Thank you Mariano very much will take a deep look into it and I am sure will be back with more questions, its fascinating. On Mon, Nov 30, 2015 at 7:54 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > On Mon, Nov 30, 2015 at 2:42 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> ah this is very good news for me thanks. I really like Fuel, well done >> guys, looks very well designed. >> >> Yeah feature wise I dont care about something advanced, If I need >> something much more advanced I will use a proper database. >> >> I am slightly surprised that none or at least AFAIK has not create a >> lightweight database API based on Fuel . Something similar to SQLite. >> >> https://www.sqlite.org/ >> >> > Well, we did and my client agree to open source it: > http://smalltalkhub.com/#!/~Debris/DebrisDB > So...you could either try that or SimplePersistentcy. > > About scale, I guess I can brake things to multiple files. >> > > That's what we do in our application. Not necessary as for performance but > also as for domain logic. We have advisorDB, clientsDB, securitiesDB, etc, > which are all logic app-dependent databases. And then all these logic > databases are stored (somehow) into real databases. > > >> On other thread someone mention that STON is a good choice for version >> control but that is not a problem for me either since Git can handle binary >> files like fuel files too. >> >> On Mon, Nov 30, 2015 at 4:49 PM Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis < >>> kilon.alios(a)gmail.com> wrote: >>> >>>> Yes I have read the docs on how to use Fuel on how to use it and how to >>>> exclude things I dont want to be stored in fuel file, I was just curious. >>>> As a matter of fact I like deep copies. >>>> >>>> Is it ok to use Fuel to make my own , super light, database ? Just a >>>> way to manage and port my objects between images. Nothing very >>>> sophisticated. >>>> >>> >>> Yes, we did this for Quuve application when it runs (for development) >>> under Pharo. Of course, it will only work up to certain scale (since every >>> commit will serialize the whole database) and you do not have ACID, nor DB >>> users, no security, nor any other features of a real DB. >>> >>> You may want to take a look to simple persistence to save some of your >>> development time since it has a Fuel backend: >>> http://smalltalkhub.com/#!/~TorstenBergmann/SimplePersistence >>> >>> >>>> On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck < >>>> marianopeck(a)gmail.com> wrote: >>>> >>>>> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis < >>>>> kilon.alios(a)gmail.com> wrote: >>>>> >>>>>> I have a class A that has an instance variable the references an >>>>>> instance of Class B , but also Class B has an instance variable the >>>>>> references an instance of Class A. Basically its a GUI that references its >>>>>> model and the same model referencing the same instance of GUI. >>>>>> >>>>>> >>>>> Dimitris, >>>>> >>>>> Fuel solves the circular references in the traditional way, that is, >>>>> while traversing the graph, after processing each objects it stores it in a >>>>> IdentityDictionary. Then, for each object to be processed, it first checks >>>>> if the dictionary already includes that object. If true, then it has >>>>> already been processed. If not, then lets process/traverse. >>>>> >>>>> >>>>> >>>>>> How Fuel deals with such scenario because I saw that it created an >>>>>> output of 1.5 mbs for several instances of my model class ? Is there any >>>>>> danger of having such circular references or it does not matter because >>>>>> afterall they are just pointers ? >>>>>> >>>>> >>>>> As Sven said, you need to be careful because you cannot be sure >>>>> exactly all what Fuel can reach from a certain graph. If the graph was >>>>> serialized into a 1.5mb then it has nothing to do to the fact of having >>>>> circular references. It's simply the fact of the graph that ended up >>>>> traversed. >>>>> >>>>> There are some tools inside Fuel to know what has been >>>>> "traversed/processed" and that will next be serialized. This may help you >>>>> realize that you are including in the graph things you don't want. We have >>>>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging >>>>> but I am not sure if that's a bit outdated. Give it a try and if not ask. >>>>> The ideally is to at least get the list of classes and instances that are >>>>> being serialized. That's quite a help in a first place. >>>>> >>>>> Finally, if you found parts of the graph that you didn't want to >>>>> serialize, then you can use different Fuel hooks to solve that >>>>> (substitutions, ignoring certain intsVars, etc etc). >>>>> >>>>> Best, >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 30, 2015

Re: [Pharo-users] How fuel deals with circular reference ?

by Mariano Martinez Peck

On Mon, Nov 30, 2015 at 2:42 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > ah this is very good news for me thanks. I really like Fuel, well done > guys, looks very well designed. > > Yeah feature wise I dont care about something advanced, If I need > something much more advanced I will use a proper database. > > I am slightly surprised that none or at least AFAIK has not create a > lightweight database API based on Fuel . Something similar to SQLite. > > https://www.sqlite.org/ > > Well, we did and my client agree to open source it: http://smalltalkhub.com/#!/~Debris/DebrisDB So...you could either try that or SimplePersistentcy. About scale, I guess I can brake things to multiple files. > That's what we do in our application. Not necessary as for performance but also as for domain logic. We have advisorDB, clientsDB, securitiesDB, etc, which are all logic app-dependent databases. And then all these logic databases are stored (somehow) into real databases. > On other thread someone mention that STON is a good choice for version > control but that is not a problem for me either since Git can handle binary > files like fuel files too. > > On Mon, Nov 30, 2015 at 4:49 PM Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis < >> kilon.alios(a)gmail.com> wrote: >> >>> Yes I have read the docs on how to use Fuel on how to use it and how to >>> exclude things I dont want to be stored in fuel file, I was just curious. >>> As a matter of fact I like deep copies. >>> >>> Is it ok to use Fuel to make my own , super light, database ? Just a way >>> to manage and port my objects between images. Nothing very sophisticated. >>> >> >> Yes, we did this for Quuve application when it runs (for development) >> under Pharo. Of course, it will only work up to certain scale (since every >> commit will serialize the whole database) and you do not have ACID, nor DB >> users, no security, nor any other features of a real DB. >> >> You may want to take a look to simple persistence to save some of your >> development time since it has a Fuel backend: >> http://smalltalkhub.com/#!/~TorstenBergmann/SimplePersistence >> >> >>> On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis < >>>> kilon.alios(a)gmail.com> wrote: >>>> >>>>> I have a class A that has an instance variable the references an >>>>> instance of Class B , but also Class B has an instance variable the >>>>> references an instance of Class A. Basically its a GUI that references its >>>>> model and the same model referencing the same instance of GUI. >>>>> >>>>> >>>> Dimitris, >>>> >>>> Fuel solves the circular references in the traditional way, that is, >>>> while traversing the graph, after processing each objects it stores it in a >>>> IdentityDictionary. Then, for each object to be processed, it first checks >>>> if the dictionary already includes that object. If true, then it has >>>> already been processed. If not, then lets process/traverse. >>>> >>>> >>>> >>>>> How Fuel deals with such scenario because I saw that it created an >>>>> output of 1.5 mbs for several instances of my model class ? Is there any >>>>> danger of having such circular references or it does not matter because >>>>> afterall they are just pointers ? >>>>> >>>> >>>> As Sven said, you need to be careful because you cannot be sure exactly >>>> all what Fuel can reach from a certain graph. If the graph was serialized >>>> into a 1.5mb then it has nothing to do to the fact of having circular >>>> references. It's simply the fact of the graph that ended up traversed. >>>> >>>> There are some tools inside Fuel to know what has been >>>> "traversed/processed" and that will next be serialized. This may help you >>>> realize that you are including in the graph things you don't want. We have >>>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging >>>> but I am not sure if that's a bit outdated. Give it a try and if not ask. >>>> The ideally is to at least get the list of classes and instances that are >>>> being serialized. That's quite a help in a first place. >>>> >>>> Finally, if you found parts of the graph that you didn't want to >>>> serialize, then you can use different Fuel hooks to solve that >>>> (substitutions, ignoring certain intsVars, etc etc). >>>> >>>> Best, >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > -- Mariano http://marianopeck.wordpress.com

Nov. 30, 2015

Re: [Pharo-users] How fuel deals with circular reference ?

by Dimitris Chloupis

ah this is very good news for me thanks. I really like Fuel, well done guys, looks very well designed. Yeah feature wise I dont care about something advanced, If I need something much more advanced I will use a proper database. I am slightly surprised that none or at least AFAIK has not create a lightweight database API based on Fuel . Something similar to SQLite. https://www.sqlite.org/ About scale, I guess I can brake things to multiple files. On other thread someone mention that STON is a good choice for version control but that is not a problem for me either since Git can handle binary files like fuel files too. On Mon, Nov 30, 2015 at 4:49 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis <kilon.alios(a)gmail.com > > wrote: > >> Yes I have read the docs on how to use Fuel on how to use it and how to >> exclude things I dont want to be stored in fuel file, I was just curious. >> As a matter of fact I like deep copies. >> >> Is it ok to use Fuel to make my own , super light, database ? Just a way >> to manage and port my objects between images. Nothing very sophisticated. >> > > Yes, we did this for Quuve application when it runs (for development) > under Pharo. Of course, it will only work up to certain scale (since every > commit will serialize the whole database) and you do not have ACID, nor DB > users, no security, nor any other features of a real DB. > > You may want to take a look to simple persistence to save some of your > development time since it has a Fuel backend: > http://smalltalkhub.com/#!/~TorstenBergmann/SimplePersistence > > >> On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis < >>> kilon.alios(a)gmail.com> wrote: >>> >>>> I have a class A that has an instance variable the references an >>>> instance of Class B , but also Class B has an instance variable the >>>> references an instance of Class A. Basically its a GUI that references its >>>> model and the same model referencing the same instance of GUI. >>>> >>>> >>> Dimitris, >>> >>> Fuel solves the circular references in the traditional way, that is, >>> while traversing the graph, after processing each objects it stores it in a >>> IdentityDictionary. Then, for each object to be processed, it first checks >>> if the dictionary already includes that object. If true, then it has >>> already been processed. If not, then lets process/traverse. >>> >>> >>> >>>> How Fuel deals with such scenario because I saw that it created an >>>> output of 1.5 mbs for several instances of my model class ? Is there any >>>> danger of having such circular references or it does not matter because >>>> afterall they are just pointers ? >>>> >>> >>> As Sven said, you need to be careful because you cannot be sure exactly >>> all what Fuel can reach from a certain graph. If the graph was serialized >>> into a 1.5mb then it has nothing to do to the fact of having circular >>> references. It's simply the fact of the graph that ended up traversed. >>> >>> There are some tools inside Fuel to know what has been >>> "traversed/processed" and that will next be serialized. This may help you >>> realize that you are including in the graph things you don't want. We have >>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging >>> but I am not sure if that's a bit outdated. Give it a try and if not ask. >>> The ideally is to at least get the list of classes and instances that are >>> being serialized. That's quite a help in a first place. >>> >>> Finally, if you found parts of the graph that you didn't want to >>> serialize, then you can use different Fuel hooks to solve that >>> (substitutions, ignoring certain intsVars, etc etc). >>> >>> Best, >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 30, 2015

Re: [Pharo-users] Sharing data between images

by Dimitris Chloupis

you wanna version control your STON files ? sound reasonable. On Mon, Nov 30, 2015 at 6:56 PM Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > Hi, > > I'm using STON, precisely for its textual nature, because for > collaborative writing it would be nice to have a diff friendly storage > format. Still I haven't had the time to make my ston grafoscopio > notebooks diff friendly when long lines appear (they're treated by > fossil as binaries) but seems not to difficult to do (is mostly about > having time to play with it). > > Cheers, > > Offray > > On 29/11/15 10:56, Sven Van Caekenberghe wrote: > > Fuel is binary, faster and store more special kinds of objects. STON is > textual, you can read and edit it, better suited for model objects. > > > >> On 29 Nov 2015, at 16:35, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > >> > >> Hi, > >> > >> have a look at Fuel, Itâs included in the image. See > http://files.pharo.org/books/enterprisepharo/book/Fuel/Fuel.html for more > info. > >> > >>> On Nov 29, 2015, at 11:57, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >>> > >>> Just wondering what my options are about sharing data between images, > should I use Ston ? A database ? something else ? > >>> > >>> I would prefer options that have as few dependencies as possible and > something that does not require from my users to install external stuff. > >>> > >>> For now Ston looks like a good option but I am very new to all this so > I would welcome any advice from the pharo experts. > >> > >> > >> ---> Save our in-boxes! http://emailcharter.org <--- > >> > >> Johan Fabry - http://pleiad.cl/~jfabry > >> PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile > >> > > > > > > >

Nov. 30, 2015

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

by Dimitris Chloupis

let me give you the thinking of someone that comes from another language "What is this ? Ah Pharo What features it has ? Ah thats some nice cool features, live coding looks sweet How about version control ? Hmm no its too weak and their website for hosting repos is problematic in many cases Maybe I could use git which I am familiar with ? Ah yes.... but wait there are many limitations How about big repos that git excels at ? Nope it crashes Pharo VM. Hmm.. ok Pharo looks like nice toy .... will go back to my language of choice and use it from time to time for foolish experiments. Notice one thing here, the user never cares about the flexibility of the API. Bottom line its not about git, or mecurial, or svn. Its about giving something that the user can use and right now when it comes to version control Pharo is light years behind. Things get popular not because they have nicely designed APIs, they become popular and rightly so and wisely so because they work. Simple as that. I hope at last version control is addressed seriously because its a real pity Pharo not to be able to use git when there are toy languages like brainfuck that interface better with it or other version control system. I am not against the idea of an abstraction API for Version Control , great idea do that, but first let get things working properly so we dont get people scratching their heads on git merges or people struggling to find out why sthub is down once again. On Mon, Nov 30, 2015 at 7:07 PM EuanM <euanmee(a)gmail.com> wrote: > We want a system of small objects with loose-coupling, and simple webs > of message-sends. This allows us power, flexibility, maintainability > *and* the opportunity to accommodate new requirements. > > We always need to bear this in mind. Build for the inevitable changes > of environment and changes of requirement. You Ain't Gonna Need it > (YAGNI) is often true, but well-factored code is *always* good. > > On 30 November 2015 at 17:02, EuanM <euanmee(a)gmail.com> wrote: > > Well, personally, I far prefer Mercurial. Which also dethroned SVN. > > > > Mercurial has all the power of Git, while providing a more usable API. > > My mind works like a Smalltalker's, not like Linus's. > > > > It's true, some of the more abstruse functions of git require a longer > > chain of user actions in Mercurial in order to achieve the same end. > > But typically, the more common functions are more memorable in > > Mercurial than in git, and my typical use-cases for a DSCM system are > > less involved than that of the Linux core. > > > > On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> And there lies the trap. > >> > >> If you end up making something that works with everything, you will > create > >> something that just works with everything instead of something that > works > >> very well with one thing. Right now Git is by very far the undisputed > king > >> of version control and has completely dethroned SVN. > >> > >> Ironically the things that make git integration in pharo so hard is all > the > >> thing that are there to decouple it from git , like filetree metadata , > or > >> continuous support for mcz and monticello. > >> > >> In the end you cant have your cake and eat it too. We will have to > choose > >> between very good integration with git or average / mediocre integration > >> with multiple backends. > >> > >> On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo(a)free.fr> wrote: > >>> > >>> What I would like for Pharo is to avoid to be bound to a given back-end > >>> for its versionning. > >>> This master is a step in the right direction > >>> > >>> > >>> > http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_… > >>> > >>> Stef > >>> > >>> > >> > >

Nov. 30, 2015

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

by EuanM

We want a system of small objects with loose-coupling, and simple webs of message-sends. This allows us power, flexibility, maintainability *and* the opportunity to accommodate new requirements. We always need to bear this in mind. Build for the inevitable changes of environment and changes of requirement. You Ain't Gonna Need it (YAGNI) is often true, but well-factored code is *always* good. On 30 November 2015 at 17:02, EuanM <euanmee(a)gmail.com> wrote: > Well, personally, I far prefer Mercurial. Which also dethroned SVN. > > Mercurial has all the power of Git, while providing a more usable API. > My mind works like a Smalltalker's, not like Linus's. > > It's true, some of the more abstruse functions of git require a longer > chain of user actions in Mercurial in order to achieve the same end. > But typically, the more common functions are more memorable in > Mercurial than in git, and my typical use-cases for a DSCM system are > less involved than that of the Linux core. > > On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> And there lies the trap. >> >> If you end up making something that works with everything, you will create >> something that just works with everything instead of something that works >> very well with one thing. Right now Git is by very far the undisputed king >> of version control and has completely dethroned SVN. >> >> Ironically the things that make git integration in pharo so hard is all the >> thing that are there to decouple it from git , like filetree metadata , or >> continuous support for mcz and monticello. >> >> In the end you cant have your cake and eat it too. We will have to choose >> between very good integration with git or average / mediocre integration >> with multiple backends. >> >> On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo(a)free.fr> wrote: >>> >>> What I would like for Pharo is to avoid to be bound to a given back-end >>> for its versionning. >>> This master is a step in the right direction >>> >>> >>> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_… >>> >>> Stef >>> >>> >>

Nov. 30, 2015

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

by EuanM

Well, personally, I far prefer Mercurial. Which also dethroned SVN. Mercurial has all the power of Git, while providing a more usable API. My mind works like a Smalltalker's, not like Linus's. It's true, some of the more abstruse functions of git require a longer chain of user actions in Mercurial in order to achieve the same end. But typically, the more common functions are more memorable in Mercurial than in git, and my typical use-cases for a DSCM system are less involved than that of the Linux core. On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > And there lies the trap. > > If you end up making something that works with everything, you will create > something that just works with everything instead of something that works > very well with one thing. Right now Git is by very far the undisputed king > of version control and has completely dethroned SVN. > > Ironically the things that make git integration in pharo so hard is all the > thing that are there to decouple it from git , like filetree metadata , or > continuous support for mcz and monticello. > > In the end you cant have your cake and eat it too. We will have to choose > between very good integration with git or average / mediocre integration > with multiple backends. > > On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo(a)free.fr> wrote: >> >> What I would like for Pharo is to avoid to be bound to a given back-end >> for its versionning. >> This master is a step in the right direction >> >> >> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_… >> >> Stef >> >> >

Nov. 30, 2015

Re: [Pharo-users] Sharing data between images

by Offray Vladimir Luna CÃ¡rdenas

Hi, I'm using STON, precisely for its textual nature, because for collaborative writing it would be nice to have a diff friendly storage format. Still I haven't had the time to make my ston grafoscopio notebooks diff friendly when long lines appear (they're treated by fossil as binaries) but seems not to difficult to do (is mostly about having time to play with it). Cheers, Offray On 29/11/15 10:56, Sven Van Caekenberghe wrote: > Fuel is binary, faster and store more special kinds of objects. STON is textual, you can read and edit it, better suited for model objects. > >> On 29 Nov 2015, at 16:35, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> >> Hi, >> >> have a look at Fuel, Itâs included in the image. See http://files.pharo.org/books/enterprisepharo/book/Fuel/Fuel.html for more info. >> >>> On Nov 29, 2015, at 11:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>> >>> Just wondering what my options are about sharing data between images, should I use Ston ? A database ? something else ? >>> >>> I would prefer options that have as few dependencies as possible and something that does not require from my users to install external stuff. >>> >>> For now Ston looks like a good option but I am very new to all this so I would welcome any advice from the pharo experts. >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile >> > >

Nov. 30, 2015