[Glass] Another metacello loading puzzle: xml

[Dale Henrichs via Glass]

Iwan,

Sorry I got involved in some internal development work that needed to 
get done pronto and now I've got a bit of breathing room:)

Thanks for putting all of the information up on github.

Now I need to get my bearings a bit ... the transcript that you put up 
on github fails with:

   DataStream does not understand #'writeWordLike:'

and it looks like you are running with a pure fetch load and you are 
doing of fetch of the not only GLASS/GsDevKit, but your entire application.

a) I would like to see the stack from #'writeWordLike:'. This method is 
not in the current GemStone code base, and may never have been.

b) it seems that you are in the process of fetching Seaside at this 
point ...

My first thought is that the way you want to structure your load is to 
first get the basic GLASS classes bootstrapped into the image and then 
load the rest of your application.  So that you would have two load 
phases and two cache repositories. the first load phase bootstraps 
GLASS/GsDevKit.

My second thought is that I've recently been working on getting 
GsDevKit/GLASS to be bootstrapped using only git repositories (i.e., no 
network) and this script[2] (within the context of GsDevKit_home) does 
just that. It should be straightforward to adapt the script to a 
non-GsDevKit_home

So if you are struggling with getting the networkless load to work it 
may make sense for you to use the bootstrapGsDevKit script ... and then 
work on getting all of the other monticello-based projects that you are 
using up on github, so that your entire application load can be done 
without hitting the network ...

If you take this route then we can ignore the #'writeWordLike:' and also 
ignore the cacheRepository:/repositoryOverrides issues.

I am headed in this direction anyway and would be willing to spend time 
helping you get the remaining monticello-based projects moved to github...

As a side note. My current work is not on the master branch yet, because 
the bootstrapGsDevKit is still a bit rough and I have yet to solve the 
upgrade requiring method recompilation problem...but if you are coming 
from a 3.3 or later upgrade will not be an immediate issue.

I highly recommend to the bootstrapGsDevKit approach, but if you don't 
want to take that route, then you should try splitting your load into 
two phases 1) fetch and load GLASS 2) fetch and load your application.

I'm sure you will have a few more questions and we might as well stay on 
this list for the time being, since I think this information is 
generally useful.

Dale

[1] 
https://github.com/finworks/BaselineOfWonkaRuntime/blob/master/logs/transcript.2018-01-01.log#L996

[2] 
https://github.com/GsDevKit/GsDevKit_home/blob/issue_200/bin/bootstrapGsDevKit

On 1/1/18 1:02 AM, Iwan Vosloo via Glass wrote:
> Hi Dale,
>
> Sorry, the new year crept up on me (skeleton staff need to multitask).
>
> Hope you have a good one!
>
> On 27/12/2017 21:55, Dale Henrichs via Glass wrote:
> >
> > Sooooo, please provide me with the set of Metacello load scripts that
> > you use to load your application without involving any caching at all
> > ... and the Transcript output for the full load. This will allow me to
> > understand when and where the http repositories get hit as well as
> > whether or not github repos with zip file downloads are involved or not
> > (my suspicion is that things might not work as expected when gthub
> > downloads are involved --- a use case for which I have not tests) ...
> > rather than guess, I'd rather know ...
>
> Extracting all our scripts is very tricky because they rely on a 
> particular setup, managed by ruby and chef.
>
> I have extracted the BaselineOfWonkaRuntime package though[1], which 
> contains all the relevant smalltalk bits, and I added a bash shell 
> script that invokes that smalltalk code via topaz just like our ruby 
> scripts do. It also contains a copy of the transcript it currently 
> yields [2].
>
> What is missing is other stuff our scripts do before invoking the 
> smalltalk, like fixing up monticello packages so they dont have 
> non-ascii chars in their metadata.
>
> I have been trying to just play with this outside of our scripts 
> because I'd want to remove most of the code there and basically just 
> rely on Metacello and GsUpgrader to get the same job done.
>
> Ideally, I'd love to get something like the snippet below to work:
>
> On 27/12/2017 21:55, Dale Henrichs via Glass wrote:
> > So I would like to start over ... I still believe that you should be
> > doing something like the following:
> >
> >    | version repo |
> >    repo := MCDirectoryRepository new.
> >    repo directory: FileDirectory on: '<path to directory>'.
> >    Metacello new
> >      configuration: 'XXX';
> >      version: '1.0';
> >      cacheRepository: repo;
> >      fetch.
> >    Metacello new
> >      configuration: 'XXX';
> >      version: '1.0';
> >      repositoryOverrides: (OrderedCollection with: repo);
> >      load
> >
> > But it sounds like you don't have a single master configuration or
> > baseline to do your loads ... right?
>
> No, we do have a single baseline (BaselineOfWonkaRuntime).
>
> Your code snippet above confuses me somewhat though... because 
> according to the docs [3]:
>
> a) I should be able to just pass a string to cacheRepository:
> b) I should specify cacheRepository: to the second call as well
>
> Although I have not played with repositoryOverrides: outside of our 
> scripts, it looked like that is what is needed to truly force it to 
> read the local repo when it loads the BaselineOf/ConfigurationOfs 
> themselves. But, I limited my experiments to just get what is in [3] 
> to work as a first step.
>
>
> I feel bad about spamming the list so perhaps chat in the git repo? 
> The git repository is public.
>
>
> [1] https://github.com/finworks/BaselineOfWonkaRuntime
>
> [2] 
> https://github.com/finworks/BaselineOfWonkaRuntime/blob/master/logs/transcript.2018-01-01.log
>
> [3] 
> https://github.com/Metacello/metacello/blob/master/docs/MetacelloScriptingAPI.md#fetching
>
> Regards
> Iwan
>
>
>