<FromGitter>
<piedoom> oh, awesome! Thanks - I totally missed that :p
<FromGitter>
<piedoom> hm, does it work with objects more than one level deep? I can do `MyObj.from_json(result, root: "response")` and `MyObj.from_json(result, root: "meta")`, but `MyObj.from_json(result, root: "user")` results in "json key not found: user" (and I'm 100% that key exists)
pawnbox has joined #crystal-lang
Oliphaunte has joined #crystal-lang
pawnbox has quit [Ping timeout: 264 seconds]
Oliphaunte has quit [Ping timeout: 272 seconds]
<FromGitter>
<mverzilli> uhm, you're right, I was assuming "response.user" would work
<FromGitter>
<piedoom> is that a bug or intended behaviour? (or am I just doing something wrong)
<FromGitter>
<mverzilli> I don't think it's a bug, it's more likely that I imagined a feature :P
<FromGitter>
<mverzilli> you can definitely do it with JSON::PullParser, I just don't know if there's a handier way
<FromGitter>
<piedoom> how might I do it with PullParser? There doesn't seem to be any documentation for it at the moment.
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/viKAy
<crystal-gh>
crystal/master 9bd2294 Ary Borenszweig: Compiler: always show nil reason in errors
<FromGitter>
<mverzilli> I was trying this but I must be doing something really dumb because it's printing EOF
<FromGitter>
<piedoom> Do you have any suggestions on making the `pull.on_key` more generic and moving it into a function that accepts a JSON string and an array of keys in the order they should be accessed? I tried making it recursive, but I'm sure theres a more efficient way without having to create a new PullParser object each time
<FromGitter>
<raydf> <Liosha>, i don't use a light theme so i would not be able to maintain it. If you want to make a fork i could help you out with tips to change it.
<FromGitter>
<piedoom> And @raydf Asterite helped me with a solution thats much more specific (#3313), but jq seems like a great general fix. Thanks, I'll keep it in mind!
<FromGitter>
<crisward> @BlaXpirit not relentless enough, crystal is by far the best thing I've discovered this year. A fast language I actually want to learn... Imagine what it'll do when you take the alpha badge off.
<BlaXpirit>
crisward, oh i mean the PR of Go is relentless. of course this does not apply to Crystal
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
bjz has quit [Ping timeout: 240 seconds]
bjz_ has joined #crystal-lang
soveran has quit [Remote host closed the connection]
soveran has joined #crystal-lang
trapped has quit [Read error: Connection reset by peer]
Philpax has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
<crystal-gh>
[crystal] asterite pushed 2 new commits to master: https://git.io/vi6K9
<crystal-gh>
crystal/master 5eeb2ba Ary Borenszweig: Fixed #3315; Float64 literal without decimal loses suffix as macro arg
<crystal-gh>
crystal/master 79e8215 Ary Borenszweig: Fixed #3316: 'Not' ASTNode does not respect precedence when rendered
<FromGitter>
<jwoertink> Basically, when you run fez from a homebrew installation, it looks for a file, and it says it doesn't exist. If you install fez from github, then it works fine
<FromGitter>
<jwoertink> My thought was that homebrew downloads the files to `/private/tmp/fez-xxx`, and then after install, that directory is wiped away
<FromGitter>
<jwoertink> however, all the other files are still copied over
<FromGitter>
<jwoertink> Could have anything to do with the fact that the other ones are inside of the `{% for name, path in Fez::Template::FILES %}` macros type deals?
<RX14>
@jwoertink __DIR__ is the directory of the file when it's built
<RX14>
you want to handle this a different way
<FromGitter>
<jwoertink> Can you give me an example?
<RX14>
of what?
<FromGitter>
<jwoertink> `__DIR__` is the directory of the `bin/fez`?
<RX14>
no
<RX14>
the directory of the file when it's built
<RX14>
basically it's never safe to expect __FILE__ or __DIR__ to actually exist
<RX14>
they're mainly of use to macros, or for compiling in the name or path of a crystal path for debugging
<RX14>
they never change
<FromGitter>
<jwoertink> Ok. I'm still unclear as to *what* directory `__DIR__` is referring to then if it's not the directory `src/fez/application.cr` is in....
<RX14>
it is the directory it's in
ebraga has joined #crystal-lang
<RX14>
when it's compiled
<RX14>
your .cr files no longer exist, only the binary remains
<FromGitter>
<jwoertink> oh, you're saying the `main_script.cr` no longer exists in templates because it's all inside the binary
<RX14>
you need to place those files somewhere as part of your install process
<RX14>
and pass where they are to fex
<RX14>
fez*
<FromGitter>
<jwoertink> Ah, ok. Would it be better to just throw those in a maco like the others ones?
<RX14>
possibly
<FromGitter>
<jwoertink> If you were writing this, would you do it within a macro, or just copy the files out to another directory as part of the install?
<RX14>
you should be able to use a MAIN_SCRIPT_SOURCE = <-'ENDOFTEMPLATE'
<RX14>
i would prefer to embed them into the executable, but it may not be possible
<RX14>
it's not really possible for binary
<RX14>
but these are source files so it should work
<FromGitter>
<jwoertink> I guess the other thing I could do is just use a heredoc block, and then just write the files from that string instead of copying files
<RX14>
thats was what I suggested
<RX14>
except placing them in a heredoc using a macro
<FromGitter>
<jwoertink> oh, is that what `MAIN_SCRIPT_SOURCE = <-'ENDOFTEMPLATE'` is?
<RX14>
yes...
<FromGitter>
<jwoertink> lol. ok
<RX14>
it's actually <<-'ENDOFTEMPLATE'
<FromGitter>
<jwoertink> yeah, that's what I would use. I didn't know if your example was some other thing hahah
<FromGitter>
<jwoertink> :D
<FromGitter>
<jwoertink> Sweet, this gets my brain moving again! Thanks!
<RX14>
no i just misremembered the syntax
<FromGitter>
<jwoertink> Any idea why it would still work when installed from github?
<RX14>
because you didn't move or delete the source?
<FromGitter>
<jwoertink> that's what I was assuming, but wasn't sure
<FromGitter>
<jwoertink> I guess I could test that theory by cloning the repo, building from source, then deleting the source
<RX14>
i'm not entirely sure you understand what the problem is here
<RX14>
it's not a theory it's a fact
<FromGitter>
<jwoertink> I really don't hahah
<RX14>
ok
<RX14>
for homebrew:
<RX14>
it checks out the source into a temp dir
<FromGitter>
<jwoertink> right
<RX14>
your template is now at /tmp/homebrew-dir/src/templates/main_script.cr
<RX14>
your source file is now at /tmp/homebrew-dir/src/fez/application.cr
<RX14>
homebrew invokes the crystal compiler
<RX14>
__DIR__ is /tmp/homebrew-dir/src/fez/ because thats where the source file is
<RX14>
the binary result is then copied out, but __DIR__ is still the same
<RX14>
this isn't ruby, you don't need the source files to exist to run
<RX14>
homebrew then deletes /tmp/homebrew-dir
<RX14>
and the main_script.cr file you have referenced is gone
<RX14>
but __DIR__ doesn't change
<RX14>
so you get an error
<RX14>
get it?
<FromGitter>
<jwoertink> ahh... yeah, that's a ton more clear
<FromGitter>
<jwoertink> I appreciate the explanation
<RX14>
np
soveran has quit [Remote host closed the connection]
qard has joined #crystal-lang
ponga has quit [Quit: Connection closed for inactivity]
qard has quit [Read error: Connection reset by peer]
qard has joined #crystal-lang
ebraga has quit [Quit: leaving]
ebraga has joined #crystal-lang
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
ebraga has quit [Quit: leaving]
Oliphaunte has joined #crystal-lang
ebraga has joined #crystal-lang
soveran has quit [Remote host closed the connection]
Renich has joined #crystal-lang
Renich has quit [Quit: leaving]
ebraga has quit [Ping timeout: 240 seconds]
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
soveran has quit [Ping timeout: 248 seconds]
_jungh4ns has joined #crystal-lang
ebraga has joined #crystal-lang
soveran has joined #crystal-lang
coderobe has joined #crystal-lang
<FromGitter>
<jwoertink> I saw a commit to the language that mentioned a `forall` syntax for free variables. What is a "free variable"?
<FromGitter>
<jwoertink> nope, but I'll read through it. Thanks
<BlaXpirit>
it's a pretty bad change, i don't know why people reacted positively
<FromGitter>
<jwoertink> I wish there was a different way to specify these things instead of single letters. `T` for generic is really confusing to me.
soveran has quit [Remote host closed the connection]
CompanionCube has quit [Ping timeout: 248 seconds]
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
CompanionCube has joined #crystal-lang
soveran has quit [Ping timeout: 240 seconds]
Ven_ has joined #crystal-lang
Ven_ has quit [Ping timeout: 240 seconds]
Ven_ has joined #crystal-lang
Ven_ has quit [Ping timeout: 248 seconds]
Ven_ has joined #crystal-lang
Ven_ has quit [Ping timeout: 250 seconds]
<asterite>
I usually wait for homebrew to merge my PR of the next version until I announce it, but in between everything is set-up: the tag, the docs, binaries for linux, etc.
<FromGitter>
<piedoom> if I'm using the `from_json` method to create an instance, how can I pass parameters (json) to a superclass?
Ven_ has joined #crystal-lang
Oliphaunte has quit [Remote host closed the connection]
<RX14>
ugh, I hate how I always manage to type random words into the topic bar on hexchat
bjz has joined #crystal-lang
Oliphaunte has joined #crystal-lang
soveran has joined #crystal-lang
Ven_ has quit [Ping timeout: 248 seconds]
Oliphaunte has quit [Remote host closed the connection]
Ven_ has joined #crystal-lang
<tilpner>
Uhh, how do you use Logger? Do you pass the thing around to every place that could use logging?
soveran has quit [Ping timeout: 240 seconds]
<RX14>
i guess you're meant to use a constant
<RX14>
but I like the way java does it
<RX14>
there's a standardized logging interface
<RX14>
and different loggers per class
<RX14>
and libraries actually log
<RX14>
which is really nice
<RX14>
unlike everywhere else where logging seems to be only done by the application itself
<tilpner>
Huh, I didn't know constants aren't... constant (as in immutable). Rust also solved this okay.
<tilpner>
Constants = globals without reassignment?
<RX14>
yes
<RX14>
basically
<RX14>
crystal can't enforce deep immutability
<RX14>
i don't know how rust does
<tilpner>
Oh, that's good. I tried to use $log at first. :D
<RX14>
globals don't exist any more
<tilpner>
Rust uses a facade that all code can use, and the application can then decide which logging backend to use, which also applies to all the libraries.
<RX14>
i meant the immutable globals
<RX14>
lol
<tilpner>
Yeah, of course.
<tilpner>
Thanks! :)
<bjz>
well Rust can enforce immutability - that's a core part of the type system
<bjz>
knowing what has the right to mutate what
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<RX14>
i guess it knows which method calls are mutating too