Skip to content
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

with recent NeoJSON work, should probably take a different approach to handling Unicode String encoding #6

Closed
dalehenrich opened this issue Nov 26, 2014 · 7 comments

Comments

@dalehenrich
Copy link
Member

NeoJSON work ...

@dalehenrich
Copy link
Member Author

needs to be done pre-3.3 release and use encodeAsUTF8intoString instead of encodeAsUtf8 as String

@dalehenrich
Copy link
Member Author

Looks like the method STONReaderTests>>testJsonString was changed for GemStone ... so this one is likely to be the canary in the gold mine ... Also this test is familiar from NeoJSON where I added additional tests to cover the Unicode16 and Unicode32 examples .... needed for STON tests as well ... and critical for getting unicode handling right.

dalehenrich added a commit that referenced this issue Jun 24, 2015
…is issue so that the changes can be cherry-picked into the common branch
dalehenrich added a commit that referenced this issue Jun 24, 2015
@dalehenrich
Copy link
Member Author

As I have evolved the STON object serialization for tODE, I am now interested in refactoring the STON work into three segments:

  • old-style STON (v0.5 and v0.9) supports which means handicapped handling of multi-byte characters
  • old-style GemStone/tODE support (v0.5.1) where UTF8 encoding is supplied at individual string level and codePoints over 126 are escaped
  • new-style GemStone/TODE support (v0.9.*) where UTF8 encoding is done for the entire STON string, no character escaping is necessary (UTF8uses 8-bit ASCII characters), if escaped characters are encountered, assumption is made that STON was encoded using old-style GemStone/tODE (v0.5.1)
  • new-style STON (utf8) support where UTF8 encoding is done for the entire STON string, no character escaping is used and on decode escaped codePoints signal an error ...
  • support both pharo and gemstone on the gemstone branch ...

dalehenrich added a commit that referenced this issue Jun 26, 2015
…on options:

  - classic (utf8 challenged)
  - utf8-friendly
  - GemStone/tODE v0.5.1
  - GemStone/tODE v0.9.*

Consolidating the Pharo/GemStone packages in the gemstone branch.
dalehenrich added a commit that referenced this issue Jun 26, 2015
dalehenrich added a commit to dalehenrich/tode that referenced this issue Jun 26, 2015
dalehenrich added a commit that referenced this issue Jun 26, 2015
dalehenrich added a commit that referenced this issue Jun 27, 2015
…ode strings (Unicode16 and Unicode32 examples) and a bit of cross materialization (051 serializer -> 091 marterializer)
@dalehenrich
Copy link
Member Author

Implementation covering the 4 different serialization schemes .. now need to revisit STON api to access the different schemes ... (don't break tODE:) .... convert object serializers first)

@dalehenrich
Copy link
Member Author

get test results: https://travis-ci.org/GsDevKit/ston/builds/68563919

@dalehenrich
Copy link
Member Author

get test results (again) https://travis-ci.org/GsDevKit/ston/builds/68845525

dalehenrich added a commit that referenced this issue Jun 29, 2015
…l implementation ... GemStone-specific mods are now present in STON051*, STON091*, and STONutf8* classes ... Modify tests to accomodate svenvc#11
@dalehenrich
Copy link
Member Author

tests green

dalehenrich added a commit that referenced this issue Jun 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant