19:32 <FromGitter> <moe:busyloop.net> Error shard name (pool) has ambiguous sources: 'git: https://github.com/j8r/pool.cr.git' and 'git: https://github.com/ysbaddaden/pool.git'.

19:32 <FromGitter> <moe:busyloop.net> :(

19:33 <FromGitter> <Blacksmoke16> rip

19:33 <FromGitter> <Blacksmoke16> would have to use shards override i think, or just use whichever you already have a dep on

19:33 <FromGitter> <moe:busyloop.net> hmm i can rename one with shards override?

19:33 <FromGitter> <moe:busyloop.net> was gonna fork

19:34 <FromGitter> <moe:busyloop.net> the j8r one is in my shard.yml, the other one is a dep of some shard i use (don't even know which)

19:35 <FromGitter> <Blacksmoke16> i never remember if override can fix this or not

19:35 <FromGitter> <Blacksmoke16> but its unfortunate because they share the same namespace too, so id just use the one thats a dep

19:37 <FromGitter> <moe:busyloop.net> meh yea, the classes clash

19:37 <FromGitter> <moe:busyloop.net> gonna fork j8r

19:37 <FromGitter> <Blacksmoke16> hows that going to help?

19:37 <FromGitter> <moe:busyloop.net> then i can rename it to BetterPool

19:37 <FromGitter> <Blacksmoke16> hehe fair enough :P

19:45 <FromGitter> <jrei:matrix.org> That's a pros and cons of Crystal: no "import x as Y"

19:49 <FromGitter> <moe:busyloop.net> j8r (https://matrix.to/#/@jrei:matrix.org): i don't think you'll call it a pro anymore after you've renamed your shard :P

19:50 <FromGitter> <jrei:matrix.org> The advantage is simplicity, for little apps at least

19:52 <FromGitter> <moe:busyloop.net> yea it's probably not a big deal in general. but means generic names really need to be avoided for competing impls. at least one popular shard (redis) depends on the other pool. that makes yours a tough choice under the current name.

19:53 <FromGitter> <jrei:matrix.org> I don't think so

19:54 <FromGitter> <jrei:matrix.org> If one forks a library, and a dep use the older version, a clash will happen too

19:55 <FromGitter> <jrei:matrix.org> For me, ideally we should name however we think fits best

19:58 <FromGitter> <jrei:matrix.org> IMO a library should be one namespace (i.e. class/module), which can then be eventually changed somehow through the language (import as) or even in shard.yml

20:00 <FromGitter> <Blacksmoke16> also could help to group shards by author

20:00 <FromGitter> <Blacksmoke16> `j8r/pool` and `ysbaddaden/pool` instead of just `pool/`

20:01 <FromGitter> <moe:busyloop.net> yup. atm the `pool:` name in the yml doesn't seem to have any effect. if i change it i just get: `Error shard name (pool) doesn't match dependency name (j8r_pool)`

20:01 <FromGitter> <Blacksmoke16> that has to match the `name` property within `shard.yml`

20:02 <FromGitter> <moe:busyloop.net> if that name could be used to convince shards to store it in a different folder. and then crystal would let me import like above. and also magically wrap the class as `J8r::Pool`...

20:02 <FromGitter> <jrei:matrix.org> Another option is to use git submodules or subtree, and then modify the name

20:03 <FromGitter> <jrei:matrix.org> Even J8r::Pool one could have the same name in gitlab and have a pool library (or a fork of mine) 😁

20:03 <FromGitter> <jrei:matrix.org> It should be user-modifiable

20:04 <FromGitter> <moe:busyloop.net> `Github::Com::J8r::Pool` :P

20:04 <FromGitter> <jrei:matrix.org> Or my name could be Array or Hash - then it may not compile or mess with the API docs

20:05 <FromGitter> <jrei:matrix.org> Sounds more and more like Java's

20:06 <FromGitter> <moe:busyloop.net> well, your shard will sound like java anyway, as you have to rename to JPool until this is fixed :p

20:07 <FromGitter> <moe:busyloop.net> i'll just fork for now, but i'm probably not the last to bump into this :/

20:07 <FromGitter> <jrei:matrix.org> If I where you I'd use git subtree

20:08 <FromGitter> <Blacksmoke16> still not going to solve it, as part of the problem is the class name itself conflicts

20:08 <FromGitter> <jrei:matrix.org> And commit to change the name

20:08 <FromGitter> <jrei:matrix.org> Maybe another option is to have a post install that sed the name, lol?

20:09 <FromGitter> <moe:busyloop.net> yea... why not replace a small pain with an ongoing agony

20:09 <FromGitter> <moe:busyloop.net> i've just decided i won't even fork but just copy paste into my src/ ;)

20:09 <FromGitter> <jrei:matrix.org> That's good too

20:10 <FromGitter> <jrei:matrix.org> In fact this lib is so small, it can be vendored

20:10 <FromGitter> <jrei:matrix.org> Unlikely to change also

20:10 <FromGitter> <moe:busyloop.net> yeh but it's still sad nobody can easily use it. it's better then the other impl.

20:11 <FromGitter> <Blacksmoke16> to be clear, its only an issue because another shard you have is using the same name

20:11 <FromGitter> <jrei:matrix.org> Then maybe make the dependency you use use my Pool haha

20:11 <FromGitter> <Blacksmoke16> if you install only his pool shard, it would be fine

20:12 <FromGitter> <Blacksmoke16> or figure out what dep uses the other and make a PR to switch out the implementation

20:13 <FromGitter> <moe:busyloop.net> right, but i wouldn't be surprised if many people who'd be interested in his shard will be in the same boat with me of having conflicting shards in their deps

20:13 <FromGitter> <moe:busyloop.net> i already figured it out, it's `redis` shard

20:13 <FromGitter> <Blacksmoke16> 👍

20:14 <FromGitter> <moe:busyloop.net> but i'm not looking to start a shards-war, i think one of them should just rename until the problem can be addressed in shards itself ;)

21:44 <miketheman> 👋

21:49 <miketheman> Been thinking about JSON::Any recently, and was trying to find some modern examples of how to implement a deconstruction of a JSON input (file, string, etc) to explicit types, when the structure is unpredictable/unknown (otherwise Serializable might work, I think) - all in the name of building up an AST for a parser/lexer to handle.

21:49 <miketheman> It's probably some combination of a JSON::PullParser, but I can't seem to find any good examples.

21:49 <miketheman> If anyone has some pointers for me to read, would much appreciate it!

22:06 <FromGitter> <Blacksmoke16> if the structure is unknown then you kinda have to use `JSON::Any`

22:10 <FromGitter> <Blacksmoke16> even if you use a pull parser to know that the current value is a integer, you dont really have a good way to store all the parsed data in, which is where `JSON::Any` comes into play

22:19 <FromGitter> <Blacksmoke16> related: https://forum.crystal-lang.org/t/have-an-alternative-to-json-parse-that-works-on-dynamic-structures-but-statically-types-the-values/583

22:53 <miketheman> Thanks - that's helpful! Don't know why I didn't find this thread earlier.

22:53 <miketheman> I guess even having a parser that can take a `JSON::Any` and do something `if unknown_input.as_a do visit(unknown_input.as_a) end` (pseudo code), then I could test the input for each type I'm looking to support, and write a bunch of `visit(some_input : <type>)` overloads - would that work? I haven't seen anything like that yet.

23:47 <FromGitter> <Blacksmoke16> Hmm

23:47 <FromGitter> <Blacksmoke16> Might be able to just do like data.raw

23:49 <FromGitter> <Blacksmoke16> Which returns the raw value, which I'm pretty sure your overloads could take it from there