On 04/08/2015 01:11 AM, Thierry Goubier wrote:
2015-04-08 8:47 GMT+02:00 Peter Uhnák <i.uh...@gmail.com
<mailto:i.uh...@gmail.com>>:
I thnk that rather than focus on the disk format which I
hardly ever actually look at ... 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.
Agreed and this is in that spirit I did GitFileTree. Dale went a bit
further and even integrated the git command line access inside
smalltalk via CommandShell... so that you get the best of both worlds
without leaving your beloved Smalltalk :)
Actually it is not quite CommandShell based ... the shell is tODE shell,
where Smalltalk is the scripting language. The tODE git commands are
implemented by parsing the command line args, resolving options and args
to objects, and then calling a Smalltalk git command API that eventually
does make shell calls (sometimes multiple git commands are folded into a
single tODE git command ... thus making it possible to ultimately switch
out the actual `git calls` and use something FFI-based, like libgit2...
This approach also makes it quite feasible to write fairly complicated
Smalltalk scripts that call the smalltalk git command api directly,
bypassing the command line interface altogether ...
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). But that may be a lot o work so I can only
dream about it, as nobody has time for that (me included).
Well, as I said elsewhere, Smalltalk doesn't work like that: code has
to be lived in the image for most tools to work properly... it doesn't
really have an "editor of file" mindset, but an "object inspector"
mindset.
What we're looking at in another thread is how to emulate that live
object approach over dead files, and, thinking of it, I'm not sure we
will succeed well.
In short, what you want may never work properly because it is not how
it should be conceptualized.
In tODE I regularly drop off live objects to the file system using STON
... The tODE shell which allows you to navigate an object-based
directory also allows you to mount the nodes from the file system and
when traversing the file system recognizes STON files and presents
objects to you instead of the dead files:)
I haven't tried taking this approach all the way to source files ... but????
Dale
