2015-04-08 9:19 GMT+02:00 Martin Bähr <mba...@email.archlab.tuwien.ac.at>:
> Excerpts from Peter Uhnák's message of 2015-04-08 08:47:15 +0200: > > > I thnk that rather than focus on the disk format which I hardly ever > > > actually look at > > i think the disk format is crucial for interoperability with other tools, > such > as github webinterface, or external editors to work on things like > pictures or data. > (which is not yet supported (i have an idea how support could look like > though)) > Open subject... I think there are a few ideas floating around, and maybe a need to see a vision around that. i don't mind file-per-method though, it helps to make the diff-stat more > readable, showing which methods have been changed, added or removed... > > > ... that folks should be looking at tools support (like > > > Thierry) ... this is where the real work needs to happen ... good > tools can > > > hide the disk fomat completely so why does the disk format matter ... > > I am personally not really a fan of this; I've been using git for a while > > and I am perfectly content with using command line on the disk (maybe I'm > > rare breed); I have yet to see a GUI/tool that would come even close to > the > > power of command line, but I've been using Linux for a long time. > > except for displaying the history graph. can't beat gitk or other gui > tools for that. > having a smalltalk version of that graph would really be great! > +1 I saw Martin Dias tools for Epicea during PharoDays, and he has that visualisation in his history browser. I wanted to reuse it, but for now I'm more like chasing bugs and coping with the increased use for gitfiletree. > > > As I've > > said to Thierry some time ago in different thread, I would be interested > in > > idea of having everything on disk side and Pharo would only somehow > refresh > > it's content (just like a Java IDE / text editor would). > > can't you already do that, except that you need to manually update the > image by > loading/adopting the current state from the repo? > There is a bit more behind that. At the moment, if you reopen / refresh a repository inspector, you'll get that update. If you browse from the repository, you'll get a 'original' style browser on the stored code, but dead (can't edit). A vision would be to have normal editing over the repository -- then we could have repository state tracking (and reuse the IDE browser code instead of cloning it inside MC). But there is a conflict with smalltalk vision of live coding: you need a far deeper connection of the repository and the Pharo image, and this is clearly not how CMS are designed... git and fossil and the likes are managing dead files, which is a concept which is clearly older than the beginnings of Smalltalk, and it shows. For me, anything clearly Smalltalk-ish in that approach would require a close integration of the image and a versionning Object persistent storage (which would be smalltalk-only in access to, for example, guarantee syntax correctness). Thierry > greetings, martin. > > -- > eKita - the online platform for your entire academic > life > -- > chief engineer > eKita.co > pike programmer pike.lysator.liu.se caudium.net > societyserver.org > secretary > beijinglug.org > mentor > fossasia.org > foresight developer foresightlinux.org > realss.com > unix sysadmin > Martin Bähr working in china > http://societyserver.org/mbaehr/ > >
