08:43 <FromGitter> <paulocoghi> Hello Crystal community! ⏎ ⏎ On `Time` api, is it possible to directly read the `Int64` for seconds from epoch and `Int32` for nanoseconds?

10:32 <straight-shoota> Not really. You can access the ivar as `time.@seconds` but that's not a public API.

10:33 <straight-shoota> I proposed exposing a method for that, but it was not accepted: https://github.com/crystal-lang/crystal/pull/6661 You might leave your use case there, maybe it can be considered

10:33 <straight-shoota> Time#nanosecond exposes the nanosecond component directly, though

11:23 <FromGitter> <paulocoghi> My use case is to create unique timestamps which include nano seconds to avoid collision when creating millions of timestamps per second

11:25 <FromGitter> <paulocoghi> They will be use in a database similar to couchdb/pouchdb where the timestamp allows offline insertions on different nodes, with collision-free synchronizations after the creation

12:57 <yxhuvud> birthday paradox means you have no guarantee of uniqueness though.

12:58 <FromGitter> <paulocoghi> I will read about it right now! Thanks!

12:59 <yxhuvud> or well, it wouldn't be good enough for uniqueness guarantee anyhow, but birthday paradox mean you will have duplicates *often*.

13:04 <FromGitter> <paulocoghi> Now I understand what you mean. In my understanding, the statistical chance of collision when working with nanosecond resolution is only considerable when passing the 999 million insertions per second, which would be more than one insertion per nanosecond

13:04 <FromGitter> <paulocoghi> But it seems that my thinking may be an ingenuous one xD

13:24 <FromGitter> <Blacksmoke16> Wouldn't it be better to use UUIDs ⏎ ?

14:27 <FromGitter> <christopherzimmerman> Yes, if he generated 1 billion records a second for a hundred years, with sufficient entropy he’d have a 50% chance of seeing a collision.

14:49 <FromGitter> <paulocoghi> xD

15:09 <FromGitter> <paulocoghi> Researching a bit, the fastest UUID library I could find by now is WUID (https://github.com/edwingeng/wuid), where it's possible to generate from 100M to 200M id's per second. Also, it's only capable of such speed because it's not fully UUID compliant (the fastest fully compliant library I found provides around 20M id's per second) ⏎ ⏎ If the first mentioned library is the world's fastest, using UUID

15:09 <FromGitter> ... would not help to ensure reliability over 1 billion records a second, since the approach is slower by itself than the desired threshold

15:11 <FromGitter> <Blacksmoke16> do you really need over 1b records a second?

15:12 <FromGitter> <paulocoghi> I do not need. Maybe a user of our database from the future xD xD

15:13 <FromGitter> <paulocoghi> With the current constraints, I believe our database will not be able to surpass the 1M creations per second on the near future :)

16:08 <FromGitter> <christopherzimmerman> Is your database going to be able to handle constant inserts of 1B records a second?

16:09 <FromGitter> <christopherzimmerman> That seems like it's going to be a far more limiting factor than generating UUIDs.

17:05 <FromGitter> <paulocoghi> > Is your database going to be able to handle constant inserts of 1B records a second? ⏎ ⏎ No

17:05 <FromGitter> <paulocoghi> > That seems like it's going to be a far more limiting factor than generating UUIDs. ⏎ ⏎ You are right

17:28 <riza> @paulocoghi - I haven't yet seen a port of this to crystal, but the twitter snowflake ID generation system is a robust, scaleable, distributed ID generation system that you might find interesting. Quick google popped up a bunch of results, eg https://github.com/RobThree/IdGen

17:33 <riza> we used a sql-native varient of snowflake at one company a few years back and it was both completely unnecessary and wonderfully capable

18:05 <FromGitter> <paulocoghi> Thanks, @riza! IdGen is really interesting, timestamp-based *but* more solid than my idea :)

18:24 <riza> in my memory the timestamp rolls over every millisecond, so each server generating IDs has 10+12 bits of entropy for every milli

18:25 <riza> well, the 10 bits is usually some combination of fixed server_id and region identifier and such

18:26 <riza> <timestamp in millis><server id><12 bit sequencial>, and the sequencial resets at every milli

20:07 <FromGitter> <shomodj> There is also this https://github.com/rs/xid

21:04 <Guest95> hello

21:05 <Guest95> I'm dumping a hash to JSON, and some of the values (like "   ") are written as "\"   \"" - is there a way to avoid this?

21:05 <FromGitter> <Blacksmoke16> i.e. like `{"foo":"Bar \" \" Baz"}`?

21:06 <Guest95> yes, something like that

21:06 <FromGitter> <Blacksmoke16> those are required, otherwise it would be invalid JSON since the `"` would conflict with the opening/closing string `"`

21:06 <Guest95> but the original value is "   " - why can't the JSON output be "    " ?

21:07 <Guest95> I mean, the quotes are not part of the value right?

21:07 <Guest95> inner quotes, sure - but not terminal ones

21:07 <FromGitter> <Blacksmoke16> you mean like `pp " ".to_json`?

21:07 <Guest95> I don't know what pp is

21:08 <Guest95> the value of the string is "   " (3 spaces) and the output is "\"   \"'

21:08 <FromGitter> <Blacksmoke16> `"\" \""` is what it outputs

21:08 <Guest95> yes, that

21:09 <FromGitter> <Blacksmoke16> how are you printing/looking at it? because in this context you see the `\"` because its enclosed in another set of quotes

21:09 <FromGitter> <Blacksmoke16> whereas if you just did `puts` you wouldn't see it

21:10 <Guest95> I'm writing specs to validate my JSON and the value doesn't correspond to what I read

21:10 <Guest95> because of the extra \"

21:10 <FromGitter> <Blacksmoke16> try doing like `my_obj.to_json.should eq %({"foo": " "})`

21:11 <FromGitter> <Blacksmoke16> if you have a playground link example that would be super helpful as well

21:12 <Guest95> what if the two values are variables?

21:12 <Guest95> `expected_label.should eq(operands)`

21:12 <Guest95> Expected: "\"   \""

21:12 <Guest95>             got: "   "

21:13 <FromGitter> <Blacksmoke16> how are you setting the value of `operands`?

21:13 <Guest95> `operands = instruction["operands_summary"].as_s`

21:13 <FromGitter> <Blacksmoke16> er `expected_label`

21:13 <Guest95> `expected_label = build_label(state, decoded_instruction)`

21:14 <Guest95> here's `build_label` https://carc.in/#/r/c8hp

21:14 <FromGitter> <Blacksmoke16> are you maybe comparing the raw JSON string to the JSON string's value?

21:14 <Guest95> is that what `.as_s` does?

21:15 <Guest95> this is my spec https://carc.in/#/r/c8hq

21:15 <FromGitter> <Blacksmoke16> if `operands_summary` is a json string yea

21:15 <Guest95> hmm ok

21:16 <FromGitter> <Blacksmoke16> https://carc.in/#/r/c8hs

21:17 <Guest95> ok, makes sense

21:17 <Guest95> thanks

21:17 <FromGitter> <Blacksmoke16> https://carc.in/#/r/c8ht

21:17 <FromGitter> <Blacksmoke16> 👍

21:18 <Guest95> yeah, but in my case the JSON is part of the string I'm comparing

21:18 <FromGitter> <Blacksmoke16> `" ".to_json != " "`

21:19 <FromGitter> <Blacksmoke16> but `" ".to_json == %(" ")` and `" ".to_json == "\" \""`

21:22 <FromGitter> <Blacksmoke16> so might just need to update the expected string to be the expected *json* string, not the json string's value i that makes sense

21:22 <FromGitter> <Blacksmoke16> if that*

21:26 <Guest95> so `operands` can contain a JSON string or something like "L00,#0a [FALSE] cbb1" so fixed it for now with `operands = JSON.parse(operands) rescue operands`

21:26 <Guest95> thanks for the pointer!

21:27 <FromGitter> <Blacksmoke16> mm that feels like a hack

21:27 <Guest95> it is :D

21:27 <Guest95> I can do it better, but for now I'm unblocked

21:27 <FromGitter> <Blacksmoke16> 👍 fair enough

21:27 <Guest95> it's possible to know if it's text or not

21:33 <Guest95> ok, so failing again with a certain output https://carc.in/#/r/c8hy

21:33 <Guest95> isn't a single \" within quotes allowed?

21:34 <FromGitter> <Blacksmoke16> thats not valid json

21:34 <Guest95> so there's no way to encode a single " within a string

21:34 <Guest95> hmm I think I'll use base64 for strings

21:34 <Guest95> since they have weird characters inside

21:34 <FromGitter> <Blacksmoke16> hmm, there *should* be a way

21:34 <FromGitter> <Blacksmoke16> sec

21:37 <Guest95> hmm, ```{

21:37 <Guest95>     "value": "\"Tomorrow never yet"

21:37 <Guest95> }``` is valid JSON

21:42 <FromGitter> <Blacksmoke16> `JSON.parse "\"\\\"Tomorrow never yet\""` is the proper way to handle this

21:43 <FromGitter> <Blacksmoke16> outer most `"` represent the JSON string itself

21:43 <FromGitter> <Blacksmoke16> inner `\"` represent the raw string value of the JSON string

21:43 <FromGitter> <Blacksmoke16> `\\\"` represents an escaped `"` within the raw JSON string's value

21:43 <FromGitter> <Blacksmoke16> and will output `"Tomorrow never yet`

21:43 <Guest95>  damn, good to know thanks

21:44 <Guest95> I think I'll just b64 the strings - seems easier

21:44 <FromGitter> <Blacksmoke16> mmk