Synchronize with Zinc 2.4.3 #11
Conversation
jbrichau: Merge remote-tracking branch 'svenc/master'
… so both pharo20 package and pharo10 packages can co-exist in same git repo
|
Hi Dale, I merged the pull request. Thanks for the effort(s). As you know I am willing to make changes upstream to help with the port, within certain limits. The github/filetree approach to Smalltalk source code management is not (yet) part of my daily workflow and I don't think I will have enough time to dive into it. If you help me where necessary, we will be able to work together. In the latest Zn, ZdcSocketStream (a brother of ZdcSecureSocketStream) became the default, bypassing the old SocketStream. I believe that Paul did his own SocketStream for Gemstone, right ? I think ZdcSocketStream could form a better, more common basis. Just an idea. Regards, Sven On 03 Jul 2013, at 23:37, Dale Henrichs [email protected] wrote:
|
|
Sven, Thanks for the effort! I understand that git/github isn't part of your workflow. Until there is better in-image tool support it shouldn't be. Definitely feel free to ask me questions about using github ... I'm not an expert but I've been using it for Smalltalk for a year and half now, so there are certain patterns that I've very familiar with.. I'm happy that you've put your repository up on github though, since that makes it very clear who the author is... For GLASS/GemStone I am going to move all development to git/github and am working to provide git/github in tODE which will replace GemTools (as soon as I'm satisfied with the tools support:). Regarding changes to help with the port, once we've ported 2.4.3, I will be able to look at the diffs and identify any areas that would make future maintenance easier ... Frankly, I'm interested in creating platform-specific branches in git (as we've done for Zinc) as opposed to the standard monticello pattern of isolating platform-specific behavior in Platform packages. I think that Platform packages take away from the ability to be able to write code that leverages specific features of a particular platform which in turn makes it hard for non-core developers to contribute since they need to know about the Platform packages, etc. With platform-specific branches the platform-specific changes are made in-place and git is leveraged to manage the changes. With that said, in a message on the glass mailing list[1], @ktreis mentioned a couple of changes that he made for the port: I haven't looked at Ken's changes (especially in light of the fact that he was working against an older version than 2.3.2), but adding a an entry in ZnConstants for maximumNumberOfDictionaryEntries would be useful to Ken (if it is still relevant). I will take a close look at ZdcSocketStream ... the SpSocket code that we're currently using (that @pdebruic based his SocketStream work on) is pretty long in tooth and deserves to be upgraded. Seriously when we get caught up to date with our port, I intend to make Zinc a part of the GLASS base. It's a real joy to be able to leverage your work for GLASS and I appreciate the fact that you put up with my curmugdeonly ways:) [1] http://forum.world.st/Glass-Zinc-and-REST-on-3-1-0-X-tp4696681p4696923.html |
|
Dale, On 05 Jul 2013, at 02:25, Dale Henrichs [email protected] wrote:
Currently I maintain more than one repo for each of my projects using monticello copy (the button). It would not bother me to export regulary to filetree/github. In fact that was my intention. BUT (maybe these issues are solved now):
Sven |
|
Sorry for the late reply, I was on vacation yesterday:) ----- Original Message ----- | From: "Sven Van Caekenberghe" [email protected] | Dale, | On 05 Jul 2013, at 02:25, Dale Henrichs [email protected] | > I understand that git/github isn't part of your workflow. Until | Currently I maintain more than one repo for each of my projects using | It would not bother me to export regulary to filetree/github. In fact | BUT (maybe these issues are solved now): | 1) whenever I did a copy to a filetree repo, it took over from the Are you referring to the fact that there were some overrides of Monticello methods? I'm pretty sure that FileTree stays within it's package boundaries now... | 2) I need to be able to compare a filetree MC version with an All of the Monticello meta data is preserved in the FileTree repositories so you can compare a package in FileTree with packages in other repos ... the main thing about FileTree is that you only have a single package version available in the repository. If you happen to have an mcz repository with the common ancestor of the two packages you can add that repsository to your package's repository group so the browser tool can find it ... This is exactly the area where more work is needed before FileTree can become an every day repository for folks (other than those familier with git). Thierry Groubier is actually addressing this problem head on for Pharo2.0 and Pharo2.0[1] as he is adding in-image tooling for working with ancestral versions by using the history available in the git data base...The next release of FileTree for Pharo2.0/Pharo3.0 will contain Thierry's work. Dale [1] https://github.com/ThierryGoubier/filetree/tree/gitfiletree/repository |
|
----- Original Message ----- | From: "Dale K. Henrichs" [email protected] | Sorry for the late reply, I was on vacation yesterday:) | ----- Original Message ----- | | From: "Sven Van Caekenberghe" [email protected] | | 1) whenever I did a copy to a filetree repo, it took over from the | Are you referring to the fact that there were some overrides of Nope packages are still getting dirtied ... will fix that in 1.0.4 ... not sure that you're referring to dirty packages though... Dale |
|
On 05 Jul 2013, at 02:25, Dale Henrichs [email protected] wrote:
ZnTooManyDictionaryEntries is signalled when ZnMultiValueDictionary receives too many entries. This protects the server's resources. All this is part of Zinc-Resource-Meta-Core, a small independent package containing mainly ZnMimeType, that is a dependancy for Zinc itself. ZnConstants is 'higher up'. But you are right: there should be some mechanism (interface) to change this constant. Sven |
Sven,
I took the liberty of copying the packages that comprise Zinc 2.4.3 up to the glassdb fork of zinc.
In pulling the packages up to github I created a pharo1x branch for the Zinc-Patch-HTTPSocket-SvenVanCaekenberghe.1 package since pharo-2.0 uses a different version of the same package. Besides the fact that I only want to store a single version of any package in the git repository it makes managing the monticello files easier if all the pharo1.0 code is identified by a monticello branch ...
I also added a BaselineOfZincHTTPComponents which is how you manage configurations in a git repository.
Finally i added TravisCI support which is basically a .travis.yml file and a travisCI.st test driver file. With those files (and a TravisCI account). Builds are automatically run against each push/pull request for a repository. For example, here's the build results for the commit leading up to this pull request. For your code base, I've got builds run against Pharo-1.3, Pharo-1.4 and Pharo-2.0 ... travis ci support for Pharo-3.0 is in the works ...
Anyway, shortly we will begin the work of porting Zinc 2.4.3 to GemStone.... It took awhile, but we just finished up the port of Zinc 2.3.2 to GemStone...
Dale