-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Squeak #17
Conversation
This introduces two platform-specific packages for each, Pharo and Squeak. Compatibility changes for tests: - Use 'as: Dictionary' instead of 'asDictionary' - Use Random integers instead of UUIDs (they seem to behave different in Squeak) - Ignore order when comparing serialized strings - Skip Pharo-specific filesystem test
4d89729
to
13687e7
Compare
self assert: (self serialize: collection) sorted equals: '{true:1,[#foo]:2}' sorted. "(ignore order)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a lovely hack
Fabio, Thank you. This is a pretty large commit, I'll need some time to process it and to see how I merge it. I also want these changes back to regular MC and I have to figure out have to best do this. Sven |
No problem, take your time. And let me know if you need any help or clarification. |
*bump* |
Hi, I did try to study the change set (the big one), but it is soo large and complex that I am not able to judge it properly. I even used it in a discussion about the pro & cons of git(hub) to make the point that merging is always hard, and the reaction was 'never accept such a huge change set' ;-) So I have a problem evaluating the changes. I also think that 100% portability will be quite hard (there are some serious differences between Pharo and Squeak). Furthermore, STON is fundamental to Pharo (it is a standard part of the image and used in critical subsystems). STON is partially developed inside Pharo without any portability consideration (understandable given its importance). Splitting packages is counter productive in that respect. Obviously I still think it is important that a reasonable Squeak port of STON exists, is used and maintained. I want to help make that real. But I do not know how to proceed. Maybe the best route would be to do it like Gemstone, not really one code base, but a regular port with hard overrides. I will try to sync the main SS3 repo to the changes that happened in Pharo and then re-export to github. I am open to suggestions. Sven |
A quick note: the current implementation no longer uses Traits which should make porting easier. |
@svenvc Thank you for letting us know! |
What is the status of this today? Would it make sense to give this fniephaus-patch-3 branch a try in a recent Squeak? |
STON has evolved since the patch was written, so I doubt it is directly useable. It should be doable to port to Squeak, I just can't do this myself. |
@shingarov I think my branch should still work in a recent Squeak. It's unfortunate that we didn't merge this PR. smalltalkCI is using its own fork of STON, so I'm closing this for now. |
This introduces two platform-specific packages for each, Pharo and Squeak.
Compatibility changes for tests:
as: Dictionary
instead ofasDictionary
UUID
s (they seem to behave different in Squeak)Also, Travis CI is instructed to test the STON code in the repository rather than from ss3.gemstone.com which is why I added a dedicated
BaselineOfSton
.This PR closes #12.