<FromGitter>
<drujensen> remove the Java dependency
laaron has joined #crystal-lang
<FromGitter>
<watzon> For sure :) that's why I made it. Java is super heavy, especially when you're trying to run in docker containers. This should be much, much faster and less resource intensive.
<FromGitter>
<drujensen> awesome!
<FromGitter>
<watzon> If there's anything needed or not working issue reports are definitely welcome for features and bugs. We are already using this at NeuraLegion and it works :)
<FromGitter>
<drujensen> Definitely look into this. 👍
<FromGitter>
<watzon> @mavu what does your `shard.yml` look like?
<FromGitter>
<watzon> Should work now
<FromGitter>
<rogerwelin_gitlab> Hi all! Question about how to best handle JSON in Crystal. Coming from Go I'm really used to unpack the json into a struct. I trying to do the same thing in Crystal but don't really know how to achieve it or if it's best practice. I have this json mapping: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ However I'm left wondering how to "re-pack" this to a struct. For simple json it's not an issue,
<FromGitter>
<absolutejam_gitlab> What is wrong with the example you posted @rogerwelin_gitlab ?
<FromGitter>
<watzon> As far as your question though I'm confused. What do you mean "re-pack a struct"
<FromGitter>
<absolutejam_gitlab> You'll end up with an array of `Node` objects
<FromGitter>
<absolutejam_gitlab> or does that not actually work?
<FromGitter>
<watzon> It should, as log as `resp.body` is a JSON array of objects that match Node's JSON.mapping
<FromGitter>
<absolutejam_gitlab> I'd also say to rename `Nodes` to `Node`
<FromGitter>
<absolutejam_gitlab> But that's pedantic
<FromGitter>
<rogerwelin_gitlab> @absolutejam_gitlab @watzon ⏎ aah, of course the from_json does what I want it to do, eg. getting the array of Node type that I wanted. No need to turn it into a struct. Sorry misinterpreted how json worked in Crystal =)
<FromGitter>
<absolutejam_gitlab> I've heard Go has one of the best json implementations (for a static lang) - Opinions?
<FromGitter>
<absolutejam_gitlab> I've not done much Go
<FromGitter>
<watzon> It's one of the only things I like about Go tbh
<FromGitter>
<watzon> They did a very good job of (de)serialization
<FromGitter>
<rogerwelin_gitlab> yeah, I think it's really good, quite intuitive to work with. Also this json to struct tool is very handy: https://mholt.github.io/json-to-go/. Would be nice to have something in Crystal to auto produce json.mapping from a json blob
<FromGitter>
<watzon> I actually do have something like that
<FromGitter>
<absolutejam_gitlab> That and the inbuilt OAuth2 covered my use cases
<FromGitter>
<kniknoo> I really like the * and ** separation concepts. It feels like there are explicit parameter zones now.
devil_tu1 has joined #crystal-lang
devil_tux has quit [Ping timeout: 245 seconds]
<FromGitter>
<absolutejam_gitlab> But don't they also introduce the ability to specify a parameter that's never used?
<FromGitter>
<absolutejam_gitlab> So if you had a typo in your parameter name, or accidentally added in an additional param, you now lose the validation provided by a more concise method signature
<FromGitter>
<absolutejam_gitlab> Which is precisely an issue I've fought with for the last 30 minutes haha
<FromGitter>
<Blacksmoke16> depends on what you're trying to do
<FromGitter>
<Blacksmoke16> they're helpful when you dont know what the args will be
<FromGitter>
<naqvis> That’s not problem with them, but its responsibility on developers on how they design their code. Splats are used to receive variable number of arguments or what they called `variadic` in other languages. For sure one can either use or abuse their usage 😆
<FromGitter>
<absolutejam_gitlab> I agree, but it can make the method signature less concise is all
<FromGitter>
<absolutejam_gitlab> And since `crystal docs` doesn't document params, it makes it even more reliable on explicit documentation and examples
<FromGitter>
<absolutejam_gitlab> I wish you could prefix a parameter with a comment like you can with properties
<FromGitter>
<absolutejam_gitlab> or perhaps a comment block with each of the parameters
devil_tu1 has quit [Ping timeout: 244 seconds]
<FromGitter>
<naqvis> comment block is what other languages uses, so I believe we can do the same when documenting function
<FromGitter>
<naqvis> at least those will be visible in docs generated
<FromGitter>
<Blacksmoke16> hes saying that requires you to manually do it, vs doing something like
<FromGitter>
<absolutejam_gitlab> Probably with a bit more style
<FromGitter>
<naqvis> yeah, I got his point, and I was also trying to say that other languages uses the block comment where one has to manually provide the documentation
<FromGitter>
<absolutejam_gitlab> I guess you can do what I Just posted above, but I mean, there's no common convention or extra formatting
<FromGitter>
<Blacksmoke16> make a PR 😉
<FromGitter>
<absolutejam_gitlab> I'd like to eventually, but that's some metaprogramming shit I wouldn't get my head around just yet
<FromGitter>
<naqvis> agree
<FromGitter>
<naqvis> we should have something like JavaDocs states
<FromGitter>
<absolutejam_gitlab> probably an RFC is a good start though
<FromGitter>
<absolutejam_gitlab> get it agreed upon
<FromGitter>
<Blacksmoke16> runs after `from_json`
<FromGitter>
<absolutejam_gitlab> is that part of the JSON module thing?
<FromGitter>
<Blacksmoke16> yes
<FromGitter>
<Blacksmoke16> er
<FromGitter>
<absolutejam_gitlab> sweet, ty
<FromGitter>
<Blacksmoke16> no
<FromGitter>
<Blacksmoke16> its part of `JSON::Serializable`
<FromGitter>
<absolutejam_gitlab> But that's implemented because of `JSON.mapping`?
<FromGitter>
<Blacksmoke16> they're separate implementations
<FromGitter>
<absolutejam_gitlab> So, I need to add something extra for that to happen?
<FromGitter>
<tenebrousedge> @meltheadorable I don't think you can redefine what a string literal is, if that's the question
<FromGitter>
<Blacksmoke16> easiest solution would be to just migrate to using the serializable mixin instead of the json.mapping
ht_ has joined #crystal-lang
<FromGitter>
<naqvis> My understanding of Melody question is, can we use encoding other than default `UTF8`.
laaron- has quit [Remote host closed the connection]
laaron has joined #crystal-lang
fyber has joined #crystal-lang
duane has joined #crystal-lang
<FromGitter>
<meltheadorable> @tenebrousedge not for literals, but i also didn’t realize that crystal treated strings as exclusively UTF-8, ruby lets you set both the underlying byte representation for a string and which encoding to interpret the underlying byte representation as, i foolishly assumed crystal was treating strings more as the abstract type and could allow converting between differently encoded ones in a similar way
<FromGitter>
... somehow, which is my bad, that changes the questions it makes sense to ask
<FromGitter>
<meltheadorable> it looks like the answer to my question is “no” based on looking at that
<FromGitter>
<tenebrousedge> I'm not sure what sort of interface you'd like to use
<FromGitter>
<meltheadorable> context — i often deal with sequences of bytes that are strings but not in any known/defined encoding, i’d love to be able to create a class or whatever that you can use with strings to convert from/to these custom-defined encodings, which is something ruby doesn’t let you do easily, like, I can’t specify my custom encoding type and then tell ruby to use that encoding to convert the string, and
<FromGitter>
... it’s pretty hard to represent byte literals in a way that would define the mapping to do in application layer code, it’d be nice to be able to use the string encoding facilities in crystal to define new encodings, but it looks like crystal might be using an external library to source the encodings it knows about & there’d be no way ... [https://gitter.im/crystal-lang/crystal?at=5d4af05dd835f428ec458d5a]
<FromGitter>
<tenebrousedge> it does use an external library, but it would also be possible to override `String#encode`
<FromGitter>
<meltheadorable> yeah, but not in a useful way
<FromGitter>
<tenebrousedge> what encoding are you working with?
<FromGitter>
<meltheadorable> a lot of totally unique ones — i toy around with ROM hacking which for folks who don’t know is basically just messing with the cartridges and save files of old video games, and most games each defined their own byte <-> string representation, it’d be great if i could treat these like actual string encodings though instead of like, constructing hashes and then manually processing bytes to convert
<FromGitter>
... back and forth between UTF-8 for displaying and taking input vs. what I read/write back in binary form
<FromGitter>
<meltheadorable> even if that’s what’s going on under the hood, it’d be great to be able to hide that more as an implementation detail and make the parts actually dealing with the strings a little more understandable
<FromGitter>
<meltheadorable> not a huge deal, crystal is just already a lot cleaner for dealing with bytes than ruby is, it’d be nice to also be better for handling conversions between strings and bytes with custom encodings
<FromGitter>
<meltheadorable> i’m not sure what would have to change to make that possible though
<FromGitter>
<naqvis> @meltheadorable what about `String#new` (https://crystal-lang.org/api/master/String.html#new(bytes:Bytes,encoding:String,invalid:Symbol?=nil):String-class-method) with `encoding` param and Slice?
<FromGitter>
<naqvis> since you have the `Bytes` and you know the encoding, then you can still make that as String
<FromGitter>
<meltheadorable> @naqvis they aren’t “real” encodings, that’s what I’m saying — I’d need the ability to define a new encoding so that I could pass that in as a param to handle the conversion
<FromGitter>
<tenebrousedge> so you can check the args and call `super` for ones you don't want to handle
<FromGitter>
<kinxer> @meltheadorable This sounds like a prime opportunity for a shard.
<FromGitter>
<naqvis> Then I guess you will have to implement methods like `String#to_utf16`, `String#from_utf16` and do the encoding conversions there
<FromGitter>
<meltheadorable> i’m not sure how it’d be implemented/able as a shard
<FromGitter>
<naqvis> implement `to/from` methods and do monkey patching? that will ensure those encoding conversions methods are available on `String`. Just one thought to keep the ball rolling 😆
<FromGitter>
<meltheadorable> `to_from` methods wouldn’t be workable, there’d need to be some kind of encoder/decoder interface
<FromGitter>
<tenebrousedge> a module/shard would presumably have its own module for methods, and then re-open `String` and add the interface to call the module methods
<FromGitter>
<kinxer> You could monkey-patch `String` with `String#encode(encoding : CustomEnc::Encoding)` and `String#decode(encoding : CustomEnc::Encoding)`, where `CustomEnc::Encoding` is a class you've written. As monkey-patching goes, that should be pretty safe, too, since Crystal's type safety should prevent any collision with other shards or `String` patches.
<FromGitter>
<kinxer> I was trying to come up with an example, but I realized I don't know enough about string encoding conversion as a problem.
<FromGitter>
<meltheadorable> Yeah, i’d have to think really hard about what would make sense and I haven’t yet
<FromGitter>
<meltheadorable> idk what my ideal interface would look like
<FromGitter>
<kinxer> Do you want compile-time encoding definitions or runtime encoding definitions?
<FromGitter>
<meltheadorable> not sure
<FromGitter>
<meltheadorable> no wait, compile time is fine/preferable
<FromGitter>
<meltheadorable> those are known by then
<FromGitter>
<meltheadorable> i might for one of my projects eventually need runtime ones but that can be built as app-level functionality, it makes sense in those scenarios to do that
<FromGitter>
<meltheadorable> (for example, a lot of hex editors will allow you to import character tables that provide a byte -> character map it can use to preview and allow you to edit text content more easily, that would need to be runtime, but it’s fair to build a runtime layer for that, there’s cases where i’d need this compile time too)
<FromGitter>
<meltheadorable> I wonder what it would take to make this manageable at a language level, I think to do this right, a shard would need to override some private/protected stuff pretty deep in the encoding guts for IO, there may be a way to surface an abstraction that would allow Iconv to just be one implementation for IO encoders, might have to play with this a little this weekend
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
ukd1 has joined #crystal-lang
ukd1 has quit [Client Quit]
ukd1 has joined #crystal-lang
duane has quit [Ping timeout: 246 seconds]
Nekka has quit [Read error: Connection reset by peer]
<FromGitter>
<absolutejam_gitlab> So, `OAuth2::Client.get_access_token_using_authorization_code` returns a `OAuth2::AccessToken`
Nekka has joined #crystal-lang
MasterdonX has quit [Ping timeout: 245 seconds]
<FromGitter>
<absolutejam_gitlab> And this has a property `expires_in`
<FromGitter>
<absolutejam_gitlab> But I want to track the actual time it expires and add a `expired?` method. I have a custom class that has these properties atm, and i'm going OAuth2::AccessToken -> json -> new class to get this info
<FromGitter>
<absolutejam_gitlab> What's the best way?
<FromGitter>
<absolutejam_gitlab> I guess I can re-open the class right? And add these?
<FromGitter>
<absolutejam_gitlab> I forgot about that
<FromGitter>
<jwoertink> Does crystal 0.30 ship with shards 0.9.0?
<FromGitter>
<jwoertink> I just upgraded, but my shards version is still the same. Or is that supposed to be a different update process?
<mps_>
jwoertink: shards is separate package from crystal
<FromGitter>
<jwoertink> right, but when I installed earlier versions through home brew, it also installed shards
<FromGitter>
<jwoertink> I never had to install shards separately
<FromGitter>
<jwoertink> but crystal 0.29 was released on jun 6th, and shards 0.9 on june 12th. I assumed upgrading to crystal 0.30 would also updated shards, but I guess that's not the case?
<FromGitter>
<jwoertink> maybe it was supposed to be, and just missed?
<mps_>
not for now, afaik
<mps_>
I upgrade them separately as they released
<FromGitter>
<jwoertink> ah. Ok
<FromGitter>
<jwoertink> Anyone here using crystal with `asdf`?
<FromGitter>
<jwoertink> I'm wondering if there's a way to tell it to use crystal with a different version of llvm
<FromGitter>
<jwoertink> mine is using `6.0.1` right now
duane has quit [Ping timeout: 245 seconds]
duane has joined #crystal-lang
laaron has quit [Remote host closed the connection]
laaron- has joined #crystal-lang
laaron has joined #crystal-lang
laaron- has quit [Ping timeout: 260 seconds]
laaron has quit [Remote host closed the connection]
sorcus has quit [Ping timeout: 264 seconds]
laaron has joined #crystal-lang
<FromGitter>
<denolfe> I use asdf, but I've never played around with different llvm versions. Mine says 4.0.0
<FromGitter>
<denolfe> Worth noting that my `shards` is in-fact using the one that was installed with asdf
Nekka_ has joined #crystal-lang
ukd1_ has joined #crystal-lang
ukd1 has quit [Ping timeout: 248 seconds]
Nekka has quit [Ping timeout: 244 seconds]
Nekka_ is now known as Nekka
alex`` has quit [Ping timeout: 258 seconds]
lucasb has quit [Quit: Connection closed for inactivity]