ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Fund Crystal's development: | GH: | Docs: | Gitter:
ejjfunky has joined #crystal-lang
wolfshappen has joined #crystal-lang
wolfshappen_ has joined #crystal-lang
wolfshappen has quit [Ping timeout: 256 seconds]
wolfshappen_ has quit [Ping timeout: 256 seconds]
wolfshappen has joined #crystal-lang
waleee has quit [Ping timeout: 272 seconds]
ur5us has joined #crystal-lang
[RMS] has quit [Ping timeout: 256 seconds]
fifr has quit [Ping timeout: 272 seconds]
fifr has joined #crystal-lang
Starfoxxes has quit [Ping timeout: 240 seconds]
Starfoxxes has joined #crystal-lang
ur5us has quit [Ping timeout: 240 seconds]
Starfoxxes has quit [Ping timeout: 240 seconds]
avane has quit [Quit: o/]
waleee has joined #crystal-lang
yxhuvud has quit [Quit: No Ping reply in 180 seconds.]
yxhuvud has joined #crystal-lang
avane has joined #crystal-lang
fifr has quit [Ping timeout: 256 seconds]
Starfoxxes has joined #crystal-lang
[R] has joined #crystal-lang
waleee has quit [Ping timeout: 252 seconds]
fifr has joined #crystal-lang
fifr has quit [Ping timeout: 256 seconds]
fifr has joined #crystal-lang
fifr has quit [Ping timeout: 256 seconds]
fifr has joined #crystal-lang
fifr has quit [Ping timeout: 256 seconds]
fifr has joined #crystal-lang
waleee has joined #crystal-lang
notzmv has quit [Ping timeout: 240 seconds]
ejjfunky has quit [Read error: Connection reset by peer]
<FromGitter> <> Error shard name (pool) has ambiguous sources: 'git:' and 'git:'.
<FromGitter> <> :(
<FromGitter> <Blacksmoke16> rip
<FromGitter> <Blacksmoke16> would have to use shards override i think, or just use whichever you already have a dep on
<FromGitter> <> hmm i can rename one with shards override?
<FromGitter> <> was gonna fork
<FromGitter> <> the j8r one is in my shard.yml, the other one is a dep of some shard i use (don't even know which)
<FromGitter> <Blacksmoke16> i never remember if override can fix this or not
<FromGitter> <Blacksmoke16> but its unfortunate because they share the same namespace too, so id just use the one thats a dep
<FromGitter> <> meh yea, the classes clash
<FromGitter> <> gonna fork j8r
<FromGitter> <Blacksmoke16> hows that going to help?
<FromGitter> <> then i can rename it to BetterPool
<FromGitter> <Blacksmoke16> hehe fair enough :P
<FromGitter> <> That's a pros and cons of Crystal: no "import x as Y"
* FromGitter * Blacksmoke16 still would love ES6 import system instead of global requires
<FromGitter> <> j8r ( i don't think you'll call it a pro anymore after you've renamed your shard :P
* FromGitter * was just about to write a github isue
<FromGitter> <> The advantage is simplicity, for little apps at least
<FromGitter> <> 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.
<FromGitter> <> I don't think so
<FromGitter> <> If one forks a library, and a dep use the older version, a clash will happen too
<FromGitter> <> For me, ideally we should name however we think fits best
<FromGitter> <> 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
<FromGitter> <Blacksmoke16> also could help to group shards by author
<FromGitter> <Blacksmoke16> `j8r/pool` and `ysbaddaden/pool` instead of just `pool/`
<FromGitter> <> 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)`
<FromGitter> <Blacksmoke16> that has to match the `name` property within `shard.yml`
<FromGitter> <> 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`...
<FromGitter> <> Another option is to use git submodules or subtree, and then modify the name
<FromGitter> <> Even J8r::Pool one could have the same name in gitlab and have a pool library (or a fork of mine) 😁
<FromGitter> <> It should be user-modifiable
<FromGitter> <> `Github::Com::J8r::Pool` :P
<FromGitter> <> Or my name could be Array or Hash - then it may not compile or mess with the API docs
<FromGitter> <> Sounds more and more like Java's
<FromGitter> <> well, your shard will sound like java anyway, as you have to rename to JPool until this is fixed :p
<FromGitter> <> i'll just fork for now, but i'm probably not the last to bump into this :/
<FromGitter> <> If I where you I'd use git subtree
<FromGitter> <Blacksmoke16> still not going to solve it, as part of the problem is the class name itself conflicts
<FromGitter> <> And commit to change the name
<FromGitter> <> Maybe another option is to have a post install that sed the name, lol?
<FromGitter> <> yea... why not replace a small pain with an ongoing agony
<FromGitter> <> i've just decided i won't even fork but just copy paste into my src/ ;)
<FromGitter> <> That's good too
<FromGitter> <> In fact this lib is so small, it can be vendored
<FromGitter> <> Unlikely to change also
<FromGitter> <> yeh but it's still sad nobody can easily use it. it's better then the other impl.
<FromGitter> <Blacksmoke16> to be clear, its only an issue because another shard you have is using the same name
<FromGitter> <> Then maybe make the dependency you use use my Pool haha
<FromGitter> <Blacksmoke16> if you install only his pool shard, it would be fine
<FromGitter> <Blacksmoke16> or figure out what dep uses the other and make a PR to switch out the implementation
<FromGitter> <> 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
<FromGitter> <> i already figured it out, it's `redis` shard
<FromGitter> <Blacksmoke16> 👍
<FromGitter> <> 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 ;)
ur5us has joined #crystal-lang
notzmv has joined #crystal-lang
miketheman has joined #crystal-lang
<miketheman> 👋
<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.
<miketheman> It's probably some combination of a JSON::PullParser, but I can't seem to find any good examples.
<miketheman> If anyone has some pointers for me to read, would much appreciate it!
<FromGitter> <Blacksmoke16> if the structure is unknown then you kinda have to use `JSON::Any`
<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
notzmv has quit [Ping timeout: 268 seconds]
<miketheman> Thanks - that's helpful! Don't know why I didn't find this thread earlier.
<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.
ur5us has quit [Ping timeout: 256 seconds]
ur5us has joined #crystal-lang
<FromGitter> <Blacksmoke16> Hmm
<FromGitter> <Blacksmoke16> Might be able to just do like data.raw
<FromGitter> <Blacksmoke16> Which returns the raw value, which I'm pretty sure your overloads could take it from there