<FromGitter>
<aisrael> Isn’t that exactly what the `#to_json` method is supposed to do?
maattdd_ has joined #crystal-lang
maattdd_ has quit [Ping timeout: 256 seconds]
<FromGitter>
<vonKingsley> I was hoping at first, but after checking the code I see that the to_json that is in JSON.mapping is on a instance level and only outputs a previously parsed string that may have been modified through the instance variables
maattdd_ has joined #crystal-lang
<FromGitter>
<aisrael> Oh—so you meant get the mapping itself as a JSON document, with empty values? Like that?
<FromGitter>
<vonKingsley> yeah thats what I was hoping for, I'm just being lazy. I have a configuration class that parses a json file to get config values, i was looking to see if there was an easy way to take my mappings and create a default config
<FromGitter>
<vonKingsley> thanks @bew that looks pretty slick, after reviewing the code I have some ideas on how i can achieve this. i'll play around a bit more and see what I can come up with.
data-navigator has joined #crystal-lang
qard has joined #crystal-lang
vivus has quit [Quit: Leaving]
<FromGitter>
<aisrael> If I pass in a `&block` to a method, and then store the block (to be called later), how do I tell the compiler that I will be calling the block `with self yield`? That is, how do I let the compiler know the type of the default receiver of the block? ⏎ ⏎ See https://carc.in/#/r/3mq1
<FromGitter>
<aisrael> Alternatively, how do I call a `Proc` (the captured block) explicitly and specify the default receiver? `block.call(a)` makes `a` the first argument, not the receiver
<FromGitter>
<bew> you can't
<FromGitter>
<bew> you can't change the receiver of a proc
<FromGitter>
<bew> and when you capture a block as a proc with `def foo(&captured_block); end` you can't change the receiver..
<FromGitter>
<bew> The syntax `with ... yield` works only with non-captured blocks
<FromGitter>
<bew> what's your usecase?
<FromGitter>
<aisrael> Pretty much what’s in the code snippet. I’d like to capture a block (in a class level `self.captures_block` method), then later on call the block passing the actual instance as the receiver
<FromGitter>
<aisrael> I’m also trying using `|cmd|` as a block parameter, but now am getting some other compiler error about “block passed expecting 0” or some such
rohitpaulk has quit [Ping timeout: 240 seconds]
yaewa has quit [Quit: Leaving...]
<FromGitter>
<aisrael> (Ok, I got the `|cmd|` as block parameter working, just needed `&block : Command ->)`)
<FromGitter>
<aisrael> Ahh.. I must’ve missed that :D
<FromGitter>
<bew> ;)
<FromGitter>
<aisrael> I’ll probably reconsider Admiral if I get into anything more complex than what I have now. But then again, I’m patterning it after the `kubectl` and `docker` CLI so not sure how far Admiral can get here, either
<FromGitter>
<bew> I've been looking for a good cli builder too some time ago, and wanted docker/git, and was thinking about making my own too.. But Admiral seems to handle pretty much everything I want. Make sure to check https://github.com/psykube/psykube (a big project using admrial for CLI)
<RX14>
admiral is far too magic for my taste
<RX14>
too many classes and too few methods with blocks
<RX14>
and far far too many macros
<FromGitter>
<bew> true too, but I absolutely wanted to use classes for commands & subcommands, and not have too many blocks like some other does. So it's a good fit for me
<RX14>
well I much prefer blocks to classes in this usecase
<RX14>
I should make my own option parser...
<FromGitter>
<bew> \o/
<RX14>
nah lol
<RX14>
the stdlib parser is perfect
<RX14>
well not realy
<RX14>
it's most of the way there
<RX14>
it just needs a sane way to handle subcommands
<FromGitter>
<bew> yeah, which IIRC asterite doesn't want in the stdlib :/
<RX14>
it doesn't need to be fancy or overengineered
<RX14>
it just needs an option to just return the unparsed array
<RX14>
so what you'd do is have an optionparses for the global options
<RX14>
it'd consume them firast
<RX14>
then you *know* the top of the argv is the subcommand
<RX14>
you pop that into a case
<RX14>
then optionparser the rest
<RX14>
all it takes is a small patch
<RX14>
not reinventing everything
<FromGitter>
<bew> sure, nobody ever PR'd that though
<FromGitter>
<aisrael> I had the same sentiments about macros and “magic” in admiral. Oh, and I remember now I wanted to support both `--flag=value` and `--flag value` Ended up just writing my own `OptionPullParser`. Didn’t take too much effort.
hightower3 has joined #crystal-lang
<FromGitter>
<anicholson> speaking of macros, I assume (given the presence of `Crystal::Macros::Block`) that it's possible to pass a macro to a block, a la: ⏎ ⏎ ```my_macro do ⏎ ... ⏎ end``` ⏎ ⏎ But I'm not sure how I would express that in the macro definition… [https://gitter.im/crystal-lang/crystal?at=5a90d984e4ff28713abc7415]
hightower2 has quit [Ping timeout: 264 seconds]
<codenoid>
hi, is struct just like a class (but use stack memory) ?
<FromGitter>
<anicholson> yup
<FromGitter>
<aisrael> IIRC you can’t `extend` a `Struct` unless it’s `abstract`
<FromGitter>
<anicholson> @aisrael do you mean inherit?
<codenoid>
"The best thing to do is to only use structs with immutable objects" because what ?
<FromGitter>
<bew> @anicholson either use `{{yield}}` to paste the block, or use `&block` in the macro and use the macro variable `block` (it's a `Crystal::Macros::Block`)
<FromGitter>
<anicholson> @bew champion! 💯
<FromGitter>
<aisrael> @anicholson I meant, you can’t `struct Foo < AnotherStruct` yeah. Wrong keyword
<codenoid>
ok
<FromGitter>
<anicholson> @aisrael yup. Anyone who's done C will understand why that is :)
<codenoid>
yeah, i came from html language
<FromGitter>
<aisrael> I’m a PowerPoint and Excel warrior myself, mostly
<FromGitter>
<anicholson> @codenoid do you know what "stack memory" means?
<FromGitter>
<anicholson> nice. So you don't want to inherit from structs, because then it's inefficient. If a `struct B `inherits from `struct A` and added extra fields, anywhere an A was expected, the program would have to allocate enough memory to fit a `B` in - because passing a `B` would be valid
data-navigator has quit [Ping timeout: 260 seconds]
<codenoid>
i've never use inherit, cuz i still doesn't need that, but thanks for sharing
<FromGitter>
<anicholson> <3
devil_tux has quit [Ping timeout: 264 seconds]
duane has joined #crystal-lang
<FromGitter>
<anicholson> Q: is there a way to use `crystal tool expand` over an entire file?
<codenoid>
omg, named tuple is 122.66× faster than hash
<FromGitter>
<anicholson> that's not super-surprising to me :) it's a big number though!
<FromGitter>
<bew> @anicholson don't think there is a way no, I'd love to have that too
<FromGitter>
<aisrael> Cause `NamedTuple` is ‘evaluated’ at compile time, vs. at run-time for `Hash`?
<FromGitter>
<anicholson> There's all sorts of guarantees a compiler can make about `NamedTuple` that it can't about a Hash: its size & shape, for example (`NamedTuple`s won't ever have new keys, for example)
<FromGitter>
<anicholson> so it doesn't have to use a hashtable underneath for storage - it could do an anonymous struct, for example
<FromGitter>
<anicholson> that's already going to be immensely faster than a Hash, that could be any size, needs to handle data reorganising itself, etc. etc.
duane has quit [Ping timeout: 240 seconds]
codenoid has quit [Quit: i sleep in my keyboard]
qard has quit [Quit: qard]
alex`` has joined #crystal-lang
qard has joined #crystal-lang
<watzon>
Does anyone know of a good way of sorting hashes? Crystal's Hash doesn't have a sort method like Ruby's does
<RX14>
you use #{__DIR__} to create the correct relative path
<lvmbdv>
is the makefile not meant for cross-compilation?
<RX14>
no
<lvmbdv>
thanks
<lvmbdv>
you are a cool dude RX14
<lvmbdv>
i follow you on twitter
devil_tux has quit [Ping timeout: 252 seconds]
duane has joined #crystal-lang
<FromGitter>
<philfine> Can I do a binding with C where I pass an object together with a callback, and once the callback is called I can access the object
<FromGitter>
<philfine> The callback is called from C, but the object is a Crystal object
<FromGitter>
<philfine> Basically, the C function takes a void * and I wonder if I can pass a crystal object through that object. C side will never touch it
<oprypin>
philfine, yes, you can do that
<oprypin>
are you going to keep a reference to that object to keep it alive?
dragonkh has quit [Ping timeout: 248 seconds]
<FromGitter>
<philfine> @oprypin Can you point me out to the documentation page ?
<FromGitter>
<philfine> Found it, missed the callback part from the bindings
devil_tux has joined #crystal-lang
baweaver is now known as baweaver_away
baweaver_away is now known as baweaver
<FromGitter>
<faultyserver> is there a clean way to evaluate an alternate condition only when the value is `nil` (not `false`)?
<FromGitter>
<faultyserver> but that feels *really* bad
ua_ has joined #crystal-lang
ua has quit [Ping timeout: 240 seconds]
Nik736 has joined #crystal-lang
<Nik736>
Hi guys, I am completely confused regarding SecureRandom / Random::Secure... I simply want to generate a uuid like with Ruby SecureRandom.uuid ... how to achieve this in crystal? Thanks
<oprypin>
Nik736, well doesnt Random::Secure.uuid work?
<Nik736>
No, I think its UUID.random now
<oprypin>
k
<Nik736>
for whatever reason, anyone want to shed some light why this was changed? thanks
<Nik736>
but shouldn't I be able to just use Random::Secure.uuid than?
<oprypin>
Nik736, apparently not anymore
<oprypin>
UUID is a concept of its own; there
<oprypin>
UUID is a concept of its own; there is no reason that anything that could be random should be a method of Random
<Nik736>
I can see your point, but from the outside it looks more messy now than it was before but I don't want to complain so I am just taking it as it is :P Thanks for your help
<oprypin>
Nik736, how do you define messy? when it's not what you're used to because something else did it this way?
<oprypin>
an arbitrary collection of things that might be wanted randomized
<Nik736>
ye, this is why I liked it, all in one place and you know where you need to search, now it's all over the place
<Nik736>
but I see your point and it was changed for a reason so I will take it as it is, no problem
<oprypin>
whatever you say
<Nik736>
my opinion is not important anyways
<oprypin>
Nik736, the main reason is the unification of implementations
<oprypin>
all the things you could do with SecureRandom, now you can do with any RNG, and all the things that you could do with any RNG, now you can do with Random::Secure
<oprypin>
shuffle an array securely? why not. get a random integer in range in a secure manner? why not