On 26 February 2013 18:12, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> 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?

It doesn't. It has nothing to do with anything other than the thread
from which this thread spawned mentioned it :)

>>>> 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 ...

Surprisingly enough, I dislike Coral syntax! Mainly because it's
gratuitously different from GNU Smalltalk's. Eventually I'll get
around to implementing GNU Smalltalk syntax, which only has one really
ugly part, and that's that class variables are implicitly defined.

> 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?

Well as it turns out MC has an excellent chunk format reader - thanks
for pointing me to MCStReader and MCDependencySorter.

I _do_ want to make developing outside the image a lot easier. To be
precise: I want to be able to choose how much in-image work I'd like
to do.

I'd like to swizzle my source in a nice syntax that groups things
better/more coarsely than one-method-per-file and looks better than
chunk format. That would let me use GitHub the way it's meant to be
used. I'd like to develop the source in-image if I feel like it, or
hack on it in Emacs if that's quicker.

I do very much want to move towards building images up rather than
trying to extract them from my development environment.

frank

> - Bert -
>
>
>