[squeak-dev] FileTree etc. (was: Finding class references)

Bert Freudenberg bert at freudenbergs.de
Tue Feb 26 18:12:44 UTC 2013


On 2013-02-26, at 18:19, Frank Shearar <frank.shearar at gmail.com> wrote:

> On 26 February 2013 15:53, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> On 2013-02-26, at 16:00, Frank Shearar <frank.shearar at gmail.com> wrote:
>> 
>>> On 26 February 2013 07:21, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>> :)
>>>> 
>>>> I'm working on an InstallerGitHub that will pull in WebClient as
>>>> needed
>> 
>> WebClient is on Github? What about this:
>> 
>> http://www.squeaksource.com/WebClient.html
> 
> No, this thing will pull in WebClient the way SMLoader does when you
> first open up SqueakMap.

How does a github installer help with that?

>>> So I have something that will happily load chunk-format files:
>>> 
>>> (Installer github user: 'frankshearar' repository: 'Zippers' commitId:
>>> 'master') install
>>> 
>>> pulls a zipball down from github, unzips it and loads all the *.st
>>> files in that repository.
>>> 
>>> Except that I neglected to consider the small detail that since
>>> RootContext subclasses ZipperContext, I must first load (the file
>>> containing) ZipperContext before I load (the file containing)
>>> RootContext, since class initialization will otherwise fail.
>>> 
>>> Which leaves me in a mild pickle. I can either resolve the load order
>>> problem manually - GNU Smalltalk does this, with a package.xml file
>>> containing the load order (among other things), or I can try identify
>>> class names in each file and load the files in a topologically sorted
>>> fashion.
>>> 
>>> The former is brain-dead but requires people to write a package.xml
>>> file. The latter is perhaps easier to use but rather more difficult to
>>> implement... and possibly fragile.
>>> 
>>> Thoughts?
>> 
>> Well, doing the topo sorting automatically sounds good. You may be able to employ MCStReader and MCDependencySorter for that. But then, why not use MC in the first place?
>> 
>> I'm surprised you're not using the MC FileTree package format, which would let Monticello do all its loading magic. See e.g.
>> 
>> https://github.com/bertfreudenberg/gezira/tree/master/bindings/squeak
> 
> I've used Filetree. I understand why Dale wrote it the way it does -
> mapping the smallest unit of code to a file. I understand the benefits
> of doing so - no inter-method merge issues, tracking history of a
> single method. And I still don't want to use it because it breaks
> using GitHub's interface to look at code.
> 
> What I'm trying to find is the sweet spot between using a version
> control system on the file system (git, in particular) and working in
> the image. In particular, I don't want to HAVE TO work in the image,
> which I do with Monticello and Filetree (because it's an MC back end).
> 
> I _do_ use Filetree - https://github.com/frankshearar/Control for
> instance - but I'm convinced there must be a better way.
> 
> frank


Agreed, it's not nice to look at. But neither is chunk format. Maybe you should give the Coral syntax a try ...

OTOH that seems useful mostly if you actually switch over to coding externally, building images fresh every time. So it only needs to support installing code, not updating code in the image (which would e.g. require removing older methods, too). For maintaining images collaboratively, we haven't found anything better than Monticello, yet. That's why a Monticello backend is still desirable. IIRC FileTree can actually handle various directory formats, maybe one that does not split each method into a file would be the solution?

- Bert -




More information about the Squeak-dev mailing list