[Glass] SyntaxError: Invalid character '\u65533'

[Dale Henrichs via Glass]

On 03/13/2015 03:57 PM, Johan Brichau via Glass wrote:
> Dale,
>
>> Frankly, these types of problems are why I am advocating a move towards github and git ...
>>
>> If at the time that Dario started this project github was available and the GLASS, Seaside and Pier, etc. projects were managed by git, Dario would have cloned ALL of the external projects he was using and it would never have been necessary to try to invent the "magical Pier3.0/Seaside3.0 load expression" because all of the code would have been there unchanged by anyone else on disk and ready to load …
> I noticed the package I published was never put into a ConfigurationOfZinc and I am a bit surprised because my own ConfigurationOfNextPlan just references Zinc 1.1, so either my memory is flawed (not improbable) or the history of the ConfigurationOfZinc was rewritten (not improbable either :) because I surely had that bugfix in our project.
Yeah, there's a bit of a "wild west" thing going on with configurations 
in the .mcz world ... Metacello was in evolution itself in those days 
and decisions  made and features added to address immediate and critical 
needs ... but sometimes a distributed system can be TOO distributed and 
folks doing production work need to be able to have a firm handle on the 
things that go into making their product ...
>
> Anyway… I agree with what you say but the real difficulty comes a while into a project when you need to upgrade the dependencies. A new Seaside, a new Zinc, a new GLASS… and they all might or might not work when upgrading just one of them. And you just might not want to upgrade all of them. imho, a ConfigurationOf is (or should be) declaring these things and the version wildcards you added to Metacello (in support of more semantic versioning) are a part of getting that puzzle right. I still have to battle with the version wildcards in a real project but I hope to do so soon. I’m sorry that thread just spun into the background for me but I think I will explore it in the context of Seaside, Zinc and GLASS1.
I really think that the real solution to this problem is to have local 
git clones of the projects ... When you are looking into upgrading to a 
new version of Seaside or Zinc or GLASS, you can take your project into 
a sandbox where you load the github project(s) of interest (using the 
tag wildcards presumably) and work through any infant mortality problems 
you run into and then and only then do you use a pull request to 
introduce new code into development that eventually makes it's way into 
production ...

The GsDevKit/tODE work that I am doing (well documenting) right now is 
aimed at making the management of the transitioning from git clone to 
github and back as straightforward as possible ...

>
>> Johan, I am very glad that you recognized the problem ... (so you were using Zinc 1.1 back then?:) and I am very glad that Dario is able to move forward (and go to bed:) ….
> Yes, Zinc 1.1 was used in production but not as a server! I only used the ZnClient. And this was 2011… and I replaced it with the github-based Zinc project in 2012… :)
> I’ve been using Zinc as a server in development with Seaside 3.1+ and Zinc 2.4.3 (from gsdevkit) only.
That probably explains a lot ... like I said I think that zinc got 
sucked into this equation because TopFeeder requires Zinc ... with all 
of the new features that I have added to the Metacello scripting API,. I 
haven't added a feature to IGNORE a required project :)
>
>> I know that advocating the use of git and github is senseless without providing real support and I am hoping to be able to provide that support real soon now, if I don't get tangled in another web of projects competing for my time…
> We are very grateful for what’s there already too. I just upgraded a GLASS1 image from last september to the latest version and it works nicely.
> I think there’s just so many different options and possibilities to get to the same point: different Metacello loading scripts, different load error handlers (onConflict, onUpgrade, …), repository cloning, repository overriddes, …). I am using all of them in some place or another and I think I am still looking for the best practice in many cases.
>
When you mention onConflict, onUpgrade, etc. I want to reiterate that 
with local git clones, none of these fancy filter methods are needed for 
"self defense" in production loads ... the rule is that you load from 
the local git repositories ... end of story ... you are in control of 
the local git repos and only the changes that you and your developers 
make are available and you local development process controls how those 
changes are propagated from dev to production ...

The fancy filters are only needed when you are in your sandbox and 
deciding which bits and pieces of the outside world you want to let into 
your production repos ... once you've figure out the SHAs of the 
projects that you want to use, you do a git merge into your development 
branch and you are off to the races ...

If there are mcz-based projects that are used with GemStone, then the 
port of that project should be done in a github/git repo .... You can 
use Metacello locks on configuration-based projects, but you are 
beholden to the vagaries of the mcz repository status and internet 
connectivity if you use .mcz files and I think the proper solution is to 
move them to git so that local repos can be maintained ...

Dale