<FromGitter>
<fgimian> @silasb Very interested in bindings to libssh2. I'm still rather new to Crystal, but will take a look and see if I can suggest any way to write this binding.
<FromGitter>
<fgimian> are you aware of the existing ssh2-cr library too, maybe that can serve as a reference or a single point of collaboration
<FromGitter>
<fgimian> suppose I'm in this scenario where I don't know what types of data the user will pass in
<FromGitter>
<fgimian> Crystal doesn't like converting an empty namedtuple to a hash (fair enough too), but ... what's a pumpkin to do?
<FromGitter>
<fgimian> I was looking forward to the static typing, but it does sometimes hurt my brain (e.g. now)
<FromGitter>
<fgimian> π
<oprypin>
fgimian, i would recommend against doing this conversion and ask the user to just add { } inside the call
<oprypin>
if you insist, you can add `def doit(); {} of Symbol => String; end`
<FromGitter>
<fgimian> I see what you mean yeah
<oprypin>
in addition to `def doit(**data); data.to_h; end`
<FromGitter>
<fgimian> gotcha, good point!
<FromGitter>
<fgimian> thanks a lot!!!
<FromGitter>
<fgimian> I think I'm going to avoid the double splats all together as you said
<FromGitter>
<fgimian> and just ask the user to pass a named argument named `data` which is already a hash
<FromGitter>
<fgimian> the data argument can have a default value of `[] of Symbol => String`
<FromGitter>
<fgimian> think this is the most elegant way to go about it
<FromGitter>
<fgimian> overloading doesn't work, because `(**data)` can also be ZERO arguments so the compiler actually uses that and it all gets hairy
<FromGitter>
<fgimian> interestingly Python uses a mutable hash for its double splats
<FromGitter>
<fgimian> tricky bit now will be that, I will need to set the type of the `data` argument, which is where it gets hard again, since each action calling this method could return anything, strings, nils, bools, arrays of strings .etc
<FromGitter>
<fgimian> ok overloading helps me
<FromGitter>
<fgimian> π
<FromGitter>
<fgimian> that'll do
akaiiro has quit [Ping timeout: 256 seconds]
That_Guy_Anon has joined #crystal-lang
alex`` has joined #crystal-lang
<FromGitter>
<fgimian> i used macros in the end π
<FromGitter>
<fgimian> I'm going to ask another silly question, and this will likely be my last for the day
<FromGitter>
<fgimian> I'm writing a tool whereby I have a plugin system, and the main runner will run certain plugins depending on what the user requests to do. Now each plugin returns a NamedTuple with a member called `data` that's a Hash of data that relate to the plugin. Of course, this data can be anything, any types, any keys, .etc.
<FromGitter>
<fgimian> As the tool runs these plugins, I would like to collect the result from each plugin into an array, but of course, this is where it gets very tricky.
<FromGitter>
<fgimian> e.g. something like this
<FromGitter>
<fgimian> now as far as I can tell, this is simply not possible in a statically typed language like this
<FromGitter>
<fgimian> and I would have to resort to using an approach similar to the YAML or JSON libraries in the stdlib
<FromGitter>
<fgimian> are there any other ways that I can deal with this?
<FromGitter>
<fgimian> I could probably use a struct for it in fact
<FromGitter>
<fgimian> but the idea of using inheritance seems to be the trick
<FromGitter>
<fgimian> this way you can create your array from the base class / abstract class
<FromGitter>
<manveru> seems good :D
<FromGitter>
<fgimian> yea! if you find a better way, please let me know
<FromGitter>
<fgimian> and I'll do the same
<FromGitter>
<fgimian> of course, we can use the `record` macro as a basis and create a macro that makes it easy to define a struct type in one line that indicates the fields and their types
<FromGitter>
<fgimian> have you used `record` before?
<FromGitter>
<fgimian> it's just a shorthand for creating a struct
<FromGitter>
<manveru> no, haven't really seen it yet
<FromGitter>
<manveru> gotta head out now... cu man
<FromGitter>
<fgimian> take care bud
<FromGitter>
<j8r> @codenoid you can compile Crystal statically for ARM64 (I do it for a project).
<FromGitter>
<j8r> To do so i use qemu and docker running Alpine Linux
<FromGitter>
<j8r> @fgimian please don't use symbols in Hashes :| , why you do this? There are already named tuples that use them.
<FromGitter>
<j8r> Can you use only a namedtuple of named tuples etc? This can solver your type issue
<FromGitter>
<fgimian> thanks @j8r, unfortunately NamedTuples wouldn't do for my use case as each plugin could return a NamedTuple with diferent fields, and this makes it a pain for the caller to obtain data from the result
<FromGitter>
<fgimian> The reason I used symbols was because I found Hashes to work better for my use case and the docs say that NamedTuples are like immutable Hashes with Symbols as their keys
<FromGitter>
<fgimian> perhaps the docs need to reflect that Symbols should not be used? Most people coming from Ruby will go straight to them.
<FromGitter>
<fgimian> The best solution I've found is using a hierarchy of Data structs, this works perfectly for me and gives me the flexibility I need.
<FromGitter>
<fgimian> I'm using a modified version of the `record` macro, I'll share my solution shortly
That_Guy_Anon has quit [Remote host closed the connection]
jfontan has joined #crystal-lang
jerryskye has joined #crystal-lang
<jerryskye>
hello everyone! I've just installed crystal with homebrew and it looks like it depends on llvm version 5, but i tried running a simple crystal program and it works fine with newest llvm version. Is there a reason that the homebrew formula has llvm@5 listed as dependency instead of just llvm?
<jerryskye>
pls ping me, thank you π
<FromGitter>
<S-YOU> Because it does not work with llvm6 or above?
<jerryskye>
but I ran crystal with llvm 6 and it worked fine for me. but as I said it was a very simple program, I ran this sample code from https://crystal-lang.org/
<FromGitter>
<S-YOU> Fine because it may not really using it, I guess.
<jerryskye>
yeah you're right, thanks for your help ;)
<FromGitter>
<S-YOU> Also brew is maintained by brew team I guess, not by Crystal developers.
<jerryskye>
yes, of course
<FromGitter>
<fredski02> is there here working on support for windows?
<FromGitter>
<vladfaust> Just a quick question - does Crystal work on ARM flawlessly?
akaiiro has joined #crystal-lang
greengriminal has joined #crystal-lang
<FromGitter>
<j8r> AFAIK yes
<FromGitter>
<j8r> But for now you can only compile it statically for ARM64
akaiiro has quit [Ping timeout: 276 seconds]
<FromGitter>
<vladfaust> I'm sorry, what limits does this imply? I'm not familiar with "static compilation" concept. Will it work on Scaleway ARM64 cloud?
alex`` has quit [Quit: WeeChat 2.1]
alex`` has joined #crystal-lang
alex`` has quit [Client Quit]
alex`` has joined #crystal-lang
<FromGitter>
<vladfaust> I got it, it links to libs
<FromGitter>
<vladfaust> That means that it could only be built on the machine itself, right?
<FromGitter>
<vladfaust> I'd consider using `struct` or `NamedTuple` for readability
<FromGitter>
<drujensen> have you considered a structure or class instead of a hash? Then you could add a constructor that takes the query results and sets the typed values.
<FromGitter>
<Daggerron> @drujensen You mean specify the type in the constructor ?
<FromGitter>
<Daggerron> @vladfaust Nice tip thx !
sherjilozair has quit [Quit: Leaving...]
pippin has joined #crystal-lang
<FromGitter>
<drujensen> that and each property will be typed so you can take advantage of it
<FromGitter>
<drujensen> avoid runtime errors
<FromGitter>
<eliasjpr> We need to have the `Teeplate ` shard updated β Specs are failing because `lib/teeplate/src/lib/file_tree/macros/directory.cr:33: undefined method 'stat' for File:Class` β `::Teeplate::StringData.new("#{rel}", io.to_s, #{File.stat(abs).perm})`
<FromGitter>
<eliasjpr> Nvm it has been updated :)
<FromGitter>
<GuskiS> Hello. How can I run some yarn command from crystal? Looking into Process module, but can't seem to figure it out(not even sure it is right place to look)
<FromGitter>
<j8r> @faustinoaq They are cheap, but they have increased the pricing of the x86-64 VPS to 2.99 to 3.99 for 2GB of RAM, and included one of 1.99 for 1GB
p0p0pr37 has quit [Read error: Connection reset by peer]
p0p0pr37 has joined #crystal-lang
GoldenBear has joined #crystal-lang
<FromGitter>
<fridgerator> looks like their only in Amsterdam and France
<FromGitter>
<fridgerator> they're*
Groogy has quit [Quit: WeeChat 2.1]
<FromGitter>
<HCLarsen> You guys got rid of Time::Kind in 0.25.0?
<FromGitter>
<fridgerator> yeah, was replaced with Time::Location I think ?!?
akaiiro has quit [Remote host closed the connection]
wontruefree has quit [Quit: bye]
<FromGitter>
<HCLarsen> Yeah, reading the documentation now. I think it's an improvement. I just have to change my ongoing project.
<FromGitter>
<eliasjpr> I have been thinking of forking, to extend and maintain it with @paulcsmith since we are using this shard heavily to support Capybara like testing for Amber and Lucky frameworks
<FromGitter>
<eliasjpr> Quick question should `JSON::Type` (Crystal 0.24.1) be replaced with `JSON::Any::Type` (Crystal v0.25.0) for the migration to work smoothly? I have seen a lot of code changes from `JSON::Type` to `JSON::Any` and it kinda does not make sense since `JSON::Any` its is own type
<FromGitter>
<stronny> No, it probably wouldn't work, I've hit this
<FromGitter>
<eliasjpr> So all you methods needs to pass now an instance of JSON::Any, and not a String, or Nil or etc..
<FromGitter>
<stronny> That's why I'm sceptical that a simple migration is possible
<FromGitter>
<eliasjpr> From the example above this method call would work `some_method(nil)` since is a valid type in the union
<FromGitter>
<stronny> You have choices. You can use JSON::Any and cast to `.raw` as needed, or you can still use the union, just keep in mind that it's a new union now
<FromGitter>
<stronny> You can always wrap your `nil` into `JSON::Any.new(nil)` though
<FromGitter>
<eliasjpr> Thats what I was thinking I can continue using the union. Now if I parse the JSON upfront I can expect a JSON::Any
<FromGitter>
<eliasjpr> So I think the migration should be to support both types
<FromGitter>
<eliasjpr> `def some_method(json : JSON::Any | JSON::Any::Type)` for methods define with `def some_method(json : JSON::Type)`
<FromGitter>
<eliasjpr> I think that would make things backward compatible
<FromGitter>
<stronny> If that's what you want, but I wouldn't do that. I would rather define overloads, not handle unions of `JSON::Any::Type` and `JSON::Any` simultaneously
<FromGitter>
<eliasjpr> Β―\_(γ)_/Β―
<FromGitter>
<eliasjpr> Good point @stronny I always forget about overloads
<FromGitter>
<stronny> still, you have to keep in mind that the backwords compatibility will not be possible, the old union has gone away =)
<FromGitter>
<eliasjpr> It looks the same union
<FromGitter>
<eliasjpr> whats the Difference
<FromGitter>
<eliasjpr> It is just in a different location
<FromGitter>
<stronny> it was `Array(JSON::Type)` before, it's `Array(JSON::Any)` now
<FromGitter>
<stronny> not `Array(JSON::Any::Type)`
<FromGitter>
<eliasjpr> Good catch
<FromGitter>
<stronny> that wasn't mine! I was also completely surprised
<FromGitter>
<stronny> well, my code exploded
<FromGitter>
<stronny> good luck! =)
<FromGitter>
<eliasjpr> a lot of shards a bleeding today
<FromGitter>
<eliasjpr> An upgrade guide would have been nice, maybe I miss it
<FromGitter>
<eliasjpr> Is there any blog out there explaining the changes, I mean I saw the JSON and YAML prs with these changes, but I lost track of them
<FromGitter>
<stronny> At least it deserved an explicit mention, definitely
<FromGitter>
<eliasjpr> Yes, I guess that sine is not `v1` is βfineβ
<FromGitter>
<stronny> I understand the reasons behind this, so I'm not angry
<FromGitter>
<eliasjpr> Mee too
<FromGitter>
<stronny> Come to think of it, my new code is probably even better
<FromGitter>
<eliasjpr> But I think the method overload and supporting both types is the better way to upgrade. I would like to hear from the team wht they think. @RX14 Whats your take?
<FromGitter>
<stronny> It's your choice of course, however since stdlib is already incompatible, I would drop the old api as well
zachk has joined #crystal-lang
zachk has joined #crystal-lang
<FromGitter>
<HCLarsen> Wow. Some serious breaking changes in that update.