Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Justin Fay
    @justinfay
    I also think you could do without the python-dateutil dependency as timezones should always be UTC
    anupsv
    @anupsv
    I'll look into it, i've not yet made it compatible to py3
    anupsv
    @anupsv
    Should'nt be that hard, will look into it this weekend
    Tony Arcieri
    @tarcieri
    For anyone curious about JavaScript: TC39 is discussing adding 64-bit signed and unsigned integers to JavaScript
    which should be supported by transpilers soon
    Tony Arcieri
    @tarcieri
    I am going to hold off on implementing the JavaScript version until that's available
    anupsv
    @anupsv
    yep makes sense
    tony, are u gonna add the new formats to the spec?
    Tony Arcieri
    @tarcieri
    yes, I think specing floats is the main thing that's immediately relevant
    Geofrey Ernest
    @gernest
    Umh! I have a question.
    For a typed language like Go. How does tjson fit in?
    I know, I can generate tyson from Go types. But it is not possible to generate Go types from tjson at runtime.
    Tony Arcieri
    @tarcieri
    @gernest I am only starting to learn Go, but in Rust you can assert the types are what you are expecting, and if not return an error
    all of that is largely accomplished through things like macros and trait derivation though
    I know the Go JSON library does something sort of analagous with... metadata on map members or something to that effect?
    regardless, in a statically typed language the whole "self-describing" aspect doesn't work out as well, but at the same time it should also cut down on the boilerplate you need to extract richer types from a JSON document
    Geofrey Ernest
    @gernest
    @tarcieri I see
    But that still doesn’t explain much. As if the field is an int64 then your decoded value must me int64 . Although I realize now, the valuew can be verified further like the base64 string.
    Tony Arcieri
    @tarcieri
    yeah, and decoding an int64 will also handle the string->int64 conversion for you
    Geofrey Ernest
    @gernest
    But don’t ypou think it is overboard to have a string of int64?
    Tony Arcieri
    @tarcieri
    Note that when such software is used, numbers that are integers and are in the range [-(2^53)+1, (2^53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.
    JSON does not guarantee interoperable support for 64-bit numbers
    this is true of both JavaScript and, I believe, Go, both of which convert all JSON numbers to doubles
    Geofrey Ernest
    @gernest
    True. Go convert all numbers to int64
    I am working on a generator. That generate decoder/encoder methods of go structs.
    So, I thought I can add tyson support too. This generates the code before compiling.
    I analysed the case of decoding tjson data. And It bugs me a little , since you can store int values to int field. If the tjson data has a sting field specified to be an int, at runtime it becomes harder to get the API right!
    Tony Arcieri
    @tarcieri
    I'm not sure what your concern is? int64 should decode as int64
    it's serialized as a JSON string to avoid losing precision
    Geofrey Ernest
    @gernest
    I see! I think I have some idea about how to proceed with the API. But I can clarify what I meant by example!
    consider this is th structure
    type Number struct{
       Double int64
    }
    it can be serialized to {“Double”:12345}
    easily
    Geofrey Ernest
    @gernest
    That can go both ways, serializing and deserializing.
    On the other hand, {“Double:i”:”12345"}
    doesn’t look right.
    correct me if I’m wrong!
    Geofrey Ernest
    @gernest
    And another thing, I can’t find any details on int64 on the spec!
    @gernest and yes, that serialization is correct
    here's a real-world example of integer precision problems in JSON: https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake
    Tony Arcieri
    @tarcieri
    solving this problem has been the toughest part of producing a JavaScript implementation, and at this point, I think I'm basically going to wait for TC39 to start specing int64/uint64 support in JavaScript, which should be in the next few months
    that should hopefully make its way into transpilers shortly thereafter, and there will finally be an interoperable solution
    Geofrey Ernest
    @gernest
    Okay! Thanks.
    anupsv
    @anupsv
    Hey tony, any plans for a test with JS ?
    Tony Arcieri
    @tarcieri
    well, if anyone is still paying attention this, I've just made a bunch of updates
    several changes to the spec: "b" for boolean, with binary data now "d"
    and there is now a JavaScript (actually TypeScript) implementation of the latest version of the spec: https://github.com/tjson/tjson-js