[Glass] Another metacello loading puzzle: xml

Mon Jan 22 16:26:22 PST 2018

On 01/22/2018 07:40 AM, Iwan Vosloo via Glass wrote:
> Hi Dale,
>
> Thank you. I could spend more time on this today.
>
> On 17/01/2018 17:43, Dale Henrichs via Glass wrote:
>> I see that you are using a filetree cache now, which is clever, but 
>> because .mcz files does not have a consistent file/package naming 
>> convention, when the Sport package is converted to filtree, which 
>> _does_ have an enforced package naming convention it runs into the 
>> consistency check error for filetree:( Between the "corrupt" .mcz 
>> files and improperly named .mcz files you are caught between a rock 
>> and a hard place.
>
> Yes, you're right - I sit on the one hand with the character encoding 
> in some mcz's that won't be supported on gemstone, and then the naming 
> of Sport which is not allowed by filetree.
>
>>
>> Now it turns out I've already moved Sport to a github project[1] and 
>> the github project for Sport does not have this inconsistency[2]. It 
>> looks like I renamed the Sport3.010.v3 package to Sport.v3 and you 
>> might be able to pull off the same trick by renaming the package in 
>> the hyper project[1] and whatever ConfigurationOf that references it 
>> - but this is wandering into complicated territory that is only 
>> becoming a problem because you are trying to use a filetree cache ... 
>> If this is the very last problem, then it might be worth it ...
>
> I suspect this is indeed the last remaining issue, so I tried using 
> your Sport from github. The only thing I am aware of that relies on 
> Sport is GLASS itself. Since we have a local clone of the master 
> branch of the github glassdb/glass repository, I edited its baseline 
> to include a baseline:
>
>   baseline: 'Sport'
>      with: [ spec repository: 'github://GsDevKit/Sport:master/src'  ];
>
> ... instead of the package it currently pulls from 
> http://seaside.gemtalksystems.com/ss/hyper
>
> In its #gs3.x section, I commented out the package it defined:
>
> "  package: 'Sport' with: [ spec file: 'Sport3.010.v3-jupiter.33' ];"
>
> Having done this, on my extracted version on GitHub, I have managed to 
> get it to load overNetwork and NOT overNetwork.
>
> I wasn't sure that commenting out the package above was the right 
> thing to do. Perhaps you can advise?
replacing the package named Sport with a project named Sport is the 
right solution ...
>
> I suppose I could also use GsDevKit/GsDevkit, but am a little wary of 
> doing that just yet, because (a) according to its readme it is 
> experimental and 
It _is_ still experimental, but it is also very close to being ready for 
use ... I have to figure out how to deal with git clones that have the 
same names but are of different versions before declaring it ready for 
use...
> (b) I don't know how using it will work when I load it into a stone 
> that has an older version loaded from glassdb/glass. 
It is pretty much the same code base ... all of the glass/gsdevkit tests 
pass and I mentioned I've been using personally for development for a 
month or so and haven't hit any major issues (and fixed the minor ones I 
_have_hit_ --- for all intents and purposes the packages are the same 
with a few minor exceptions so it should work seamlessly ...
> If you think I should rather switch, and have solutions to my worries 
> here, I'd love to know.
I always hate to force folks to switch their production systems, but 
when things are "broken" how much time should be invested in patching 
the broken system versus investing in upgrading the production system to 
a more recent approach ...

It seems that you are getting close to patching your system and I'd 
rather wait a month or so before finishing up GsDevKit/GsDevKit work
>
> Anyways, I am still having trouble when I put all this stuff back into 
> our project... a problem I had before also. If the above solution 
> solves the basic loading issues, and I can get it to load in our 
> project I would prefer to stick to this route for now and wait to see 
> how your future plans turn out.
Yeah we're awfully close to having you back in business, it seems ...
>
> That decision depends on whether I can get it to load when everything 
> is copied back into our project. Something that is supposed to work, 
> but for some reason just does not. I would appreciate it if you have 
> any insights in to this issue....just maybe its not a big deal??? The 
> transcript and stack for this is on pastbin [1]
>
So you are referring to the following MNU?:

    a MessageNotUnderstood occurred (error 2010), a GRGemStonePlatform
    does not understand  #'bindingOf:'

according to your log you are using:

    --transcript--'Fetched -> Grease-Core-JohanBrichau.94 ---
    filetree:///home/wonka/development/wonka/3rdparty/gemstone/grease/repository
    [00a7df6:HEAD] ---
    filetree:///home/wonka/development/wonka/3rdparty/gemstone/grease/repository'

a git SHA of 00a7df6

In a fresh build of Seaside3.2 my image is using

    Grease-Core (Grease-Core-topa.109)
                   6973d2b [master]
    filetree:///export/acrux4/users/dhenrich/bugs/47418/GsDevKit_home/shared/repos/Grease/repository

and the method GRPlatform>>bindingOf: itself was committed 2.5 years ago

    commit 94ca45afcd1b00f7d320496adbaade48bdbf7ccf
    Author: Johan Brichau <johan at yesplan.be>
    Date:   Sun Jul 12 15:21:23 2015 +0200

         sync with smalltalkhub

while the version of Grease you are using is from 3 years ago:

    commit 00a7df6f5c3e83d01d97dcb2785c2bd502e5e6ad
    Merge: 27ae1e2 ed57cb0
    Author: Johan Brichau <johan at yesplan.be>
    Date:   Sat Nov 8 13:31:43 2014 +0100

         Merge pull request #7 from GsDevKit/dev-1.1.12

         Dev 1.1.12

So it looks like you need to update to a later version of Grease at a 
minimum or use an older version of Seaside --- from the transcript you 
are using the latest version of Seaside, so you really should be using 
the latest version of "everything", but I don't know what version of 
Seaisde your application was written against ... and the Seaside version 
should be your driving factor for moving on from here ...

Dale
>
> [1] https://pastebin.com/Jp3kxUAR
>
>
> Thank you
> - Iwan
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20180122/5ac05625/attachment.html>