On 1/27/16 6:24 AM, Sven Van Caekenberghe wrote:
Dale,
That looks like something very interesting and worth considering.
Thanks for the interest Sven!
How easy is it to load tODE in a current (4.x 5.x) Pharo image ? I assume there is
a Metacello configuration ;-) Is it possible to experiment with it in Pharo,
independent from Gemstone ? I did not see it in the Catalog Browser (our current
point & click installer).
As it stands right now, tODE is not loadable/functional in Pharo ... In
my earlier tODE work, I implemented it in both Pharo and GemStone, but
this current version of tODE started out life as a remote development
environment for GemStone with emphasis on the remote aspect --- so a
significant chunk of tODE is devoted to managing windows running in a
Pharo image while executing all of the functionality in GemStone ...
With that said, I have architected tODE to isolate the basic tool
functionality from the GUI/command line and the model has evolved to the
point where all tools (both GUI and CommandLine --- yes there are
bash-like command mappings for all GUI functionality) share the same
basic algorithms behind a smalltalk api --- so developers can easily tap
into the functionality behind every GUI window/tODE shell command.
If you want to experiment today, you'll have to do that in GemStone with
GsDevKit_home[1]
[1] https://github.com/GsDevKit/GsDevKit_home
Making tODE easily loadable would, IMHO, be the first step to a broader
adaption of your work (in one form or another). The next step would be a
getting started tutorial.
Haha, I am bandwidth limited myself and as tODE and GsDevKit_home are
still works in progress (quite functional, but still evolving:) I do not
have the cycles to worry about getting tODE to work in Pharo.... I've
got my hands full with tODE and GemStone ...
Sooo at the end of the day, I would be willing to work with folks in
porting the interesting bits of tODE to Pharo, but "interesting bits" is
in the eye of the beholder and in this case I am not the beholder ...
I think it's more important to share some of the structural (on disk)
and architectural (in-image) lessons that I've learned about working
with tODE, git and Metacello ...
For example a "Project Browser" is a critical tool that needs to exist
... I've started sharing some of the implementation details with Thierry
already ... I would recommend that the "project browser" be implemented
in a set of classes totally independent of the GUI --- let the menu
items and functionality expressed in the "Project Browser" drive a
smalltalk api that can be called from a variety endpoints beyond the
initial "project browser" implementation (take the approach that
developers will want to incorporate all of the functionality in the
"project browser" in their own GT tool) so every menu item and every
meaningful click should call this "smalltalk api) and very little
"business logic" should be present in the GUI itself ...
The details of the functionality of the tool will depend upon the set of
work flows that will be supported and on this point I do have 4 years of
experience to bring to bear on this matter, but I want to share
information and opinions rather than dictate functionality: that is the
job of the tool builder:)
Since there seems to be interest, I intend to write a series of posts
describing the disk architecture and workflows used in GsDevKit_home for
incorporating git (or any other disk-based SCM) into smalltalk dev
environments ...
Dale
