On 11/8/16 7:09 AM, Thierry Goubier wrote:
Hi Dale,
2016-11-08 2:03 GMT+01:00 Dale Henrichs
<dale.henri...@gemtalksystems.com
<mailto:dale.henri...@gemtalksystems.com>>:
[ snip ... ]
yes I think this is the area where a Metallo Project Browser comes
into play. The technology for committing the dirty packages in a a
ConfigurationOf has been around for quite awhile, but a tool that
unifies the "multi-package" commit for ConfigurationOf and
BaselineOf hasn't popped out of the wood work ...
I'm having some issues with the scripting approach of Metacello, for
that. Just manipulating a baseline in the Metacello registry (locking
it) seems to be like writing a compiler code generation item: write a
Metacello script ;) (Metacello>>#lock contains interesting code).
I think I agree:) ... that is why i am talking about a tool ...
developers shouldn't have to pass around workspaces to load and
manipulate projects .. a project tool can partially automate the
process, but I believe that there needs to be a "load spec" object that
can be passed around and massaged by code instead of requiring a user to
edit a Smalltalk workspace ... it's what I do in tODE ... the only times
I have to write Smalltalk load scripts is when I work in Pharo :)
I will repeat that I don't think Pharo should do exactly what I've done
with tODE, but a Metacello Project Browser and some sort of "load spec"
object that is shared amongst a cluster of images is something that
needs to be seriously considered ...
What is a bit annoying, really, is this talk of rewriting
everything where some of the pieces (the project browsing you're
talkin about, for example) is already there in the image, just
not exposed.
Well I am annoyed as well .. I would say that perhaps we are in
screaming agreement ... I've said that I don't think it's a lot of
work to do the project-centric tool. but a project-centric tool
that encompasses both ConfigurationOf and BaselineOf will expose
the features that "are already there"
I'm trying to code a little something for that... stay tuned for
a screenshot soon.
Cool:)
And here it is! I'm still fighting with the Metacello lock / unlock thing.
Images intégrées 1
If Pharo was more really modular in configurations and baselines, then
I would see more things into the registry and I could group packages
based on that (instead of having to prepare a ad-hoc classification
for my my browser).
Yes this is headed in the right direction ... I am in Argentina this
week so it isn't easy for me to do much collaboration, but I would love
to help you with your lock problem next week ... For example ... you do
not want to directly expose the Metacello registry as there are "hybrid
projects" where a ConfigurationOf causes a BaselineOf to be loaded, so
the BaselineOf needs to take precedence (I have code for resolving this)
and I strongly suggest that the Project Browser not be built-into the
Class Browser, but be a separate tool like the CataLogBrowser ... but
this is just a suggestion --- a separate tool dedicated only to loaded
Projects and unloaded Projects of interest allows one to get a very
quick overview of what is in the project or not and when version skew
pops up, one can easily see the affected projects ... embedding this
kind of information in the code browser can make it hard to get the
overview and if you choose to live with version skew can be annoying to
ignore .... again these are just my thoughts ..
Regardless I think you are definitely headed in the right direction and
it isn't all that much work ... yet:)
Dale
