[Glass] SyntaxError: Invalid character '\u65533'
Locked
12
12
Re: [Glass] SyntaxError: Invalid character '\u65533'
 
|
Dario,
Loading Zinc from that repository is going to give you a very very old version of Zinc that only works in Pharo. You should load the one I sent you. Loading 2.4.3 or 2.4.3.1 is fine. It’s all mentioned in the README and the script for loading should work. However, I think it’s best that you either load everything from scratch, or that you make sure to remove all loaded code from the wrong version of Zinc. Not sure if this is going to fix this problem, but I am sure it’s not a good idea to have that version of Zinc your image. Do you actually need it in Gemstone? Because this could never have worked. If you are not using it, don’t load it. Johan
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
Johan, in the incriminated tODE environment result load: Zinc-Gemstone (Zinc-Gemstone-PaulDeBruicker.14) Zinc-GemstonePreliminary (Zinc-GemstonePreliminary-PaulDeBruicker.2) * Zinc-HTTP (Zinc-HTTP-SvenVanCaekenberghe.162)
My applications is based on Seaside. I don't know if Zinc packages are required for it. Thanks, Dario
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
You are probably not using Zinc in Gemstone when you are using FastCGI.
We can quickly check if the issue I mention is the culprit: load the Zinc-Gemstone-JohanBrichau.16 package from the http://seaside.gemtalksystems.com/ss/ZincHTTPComponents/ repository. If you check out the version history in that repo, you will see that this is a fix for such a kind of bug I experienced when Zinc-Gemstone-PaulDeBruicker.14 was loaded. If the error disappears after loading that package, we are sure. But… this is a very old version of Zinc and if you intend to use it, please load the more recent port I mentioned. Johan
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
In reply to this post by GLASS mailing list
Johan,
That sounds plausible to me .... There are the Ansi*Stream classes that should be compatible with the Pharo streams, but if there are subclasses of ReadStream they need to be changed to subclasses of AnsiReadStream ... Dale On 03/13/2015 01:18 PM, Johan Brichau
wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
In reply to this post by GLASS mailing list
Johan,
I've had nothing but trouble trying to the the recent versions of Zinc to work with the old versions of Seaside ... Dario is working with GemStone 3.0 and there are quite a few changes in the zinc adaptors ... i think... Dale On 03/13/2015 01:36 PM, Johan Brichau
wrote:
Dario, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
In reply to this post by GLASS mailing list
Dario,
If you try loading a new version of Zinc you might just introduce a whole new set of problems .... you use FastCGI, so the version of Zinc loaded is immaterial and probably has nothing to do with the root cause of this problem ... Zinc comes in because one of the Pier addOns has a hard dependency on zinc and that particular addon is part of the default group that is loaded by Pier addons ... I picked an older version of Zinc that appeared to be relatively benign (in truth it almost works) to satisfy the pier addon ... Dale On 03/13/2015 02:18 PM, Johan Brichau
via Glass wrote:
You are probably not using Zinc in Gemstone when you are using FastCGI. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
It’s correct that using the Zinc ports on github will not work when you want to use it as a server (with the seaside adaptors).
However, there is some code in that particular package that overwrites String>>new:streamContents: with the bug that I describe and which made me hit exactly the same issue with bad characters on the webpage. So, at the very least, load the package I mention. If the problem does not go away, we have at least excluded this. Johan
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
I should add: you do not have to use Zinc for the bug to appear because it’s an overwrite of a method included in the Zinc package that causes this bad behavior in unrelated parts of the system.
Johan
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
In reply to this post by GLASS mailing list
Johan,
Thanks, i was very worried because I have to deliver the application. Now i can sleep this night. Ciao, Dario
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
In reply to this post by GLASS mailing list
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 ... 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:) .... 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... Dale On 03/13/2015 02:50 PM, Johan Brichau
wrote:
It’s correct that using the Zinc ports on github will not work when you want to use it as a server (with the seaside adaptors). _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
In reply to this post by GLASS mailing list
Ciao folks,
thanks for the helps. Now i need to understand how setup the packages. I can consider right this setup after load Zinc-Gemstone-JohanBrichau.16 ? Or it's best recreate the tODE 3.1.0.6 environment and load Zinc 2.4.3 or 2.4.3.1 Ciao, Dario
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
Dario,
As Dale mentioned, loading the more recent versions of Zinc might lead to other issues, but basically these are the constraints I am aware of: If you are using Zinc as a server, don’t do it because it does not work with Seaside 3.0.x If you are using Zinc as a client, you can try (I am using those versions as well, together with Seaside 3.0.x in an image) But I suspect you are not even using Zinc in Gemstone. So, if possible (when it’s not loaded automatically by another project as a dependency), don’t even load Zinc. Johan
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
In reply to this post by GLASS mailing list
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. 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. > 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. > 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. But it’s getting late on this side of the ocean, so I will stop rambling on for now :) Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
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 _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SyntaxError: Invalid character '\u65533'
|
|
In reply to this post by GLASS mailing list
Dario,
I think the best solution to getting rid of the Zinc 1.1 is to crate a custom load expression for pier addOns to exclude top feeder (assuming that you don't depend upon top feeder) .... I think top feeder is the only project with an explicit dependency ... if there are others we can exclude them as well ... I am a fan of making the smallest set of changes necessary and I think that we can control which addons are loaded by customizing the load expression ... Presumably we will have a day or two to catch our breath before we dive into this again:) Dale On 03/13/2015 03:41 PM, Dario Trussardi
via Glass wrote:
Ciao folks, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |