sz0 has quit [Quit: Connection closed for inactivity]
return0e has quit [Remote host closed the connection]
return0e has joined #crystal-lang
<FromGitter>
<Blacksmoke16> no
<FromGitter>
<Blacksmoke16> @jwoertink since that happens at compile time while method happens at runtime
<FromGitter>
<franciscoadasme> hey everyone, is there a way to raise from a macro showing the location that produced the error (like when raising a regular exception)?, I was testing some ideas and found out that raising in a macro just prints "Error in line 1: <error message>"... am I missing something?
ma_ has joined #crystal-lang
szut has joined #crystal-lang
robacarp has quit [Ping timeout: 240 seconds]
chemist69 has quit [Ping timeout: 250 seconds]
chemist69 has joined #crystal-lang
moei has joined #crystal-lang
ma_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
robacarp has joined #crystal-lang
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Remote host closed the connection]
<FromGitter>
<jtianling> But I think it should be right
<FromGitter>
<jtianling> It could infer the type of instance variable '@name' of Employee from Person's initialize
<FromGitter>
<bew> Did you read the error? :P show me why it should be right
<FromGitter>
<jtianling> in main.cr:3: Can't infer the type of instance variable '@name' of Employee ⏎ ⏎ The type of a instance variable, if not declared explicitly with ⏎ `@name : Type`, is inferred from assignments to it across ⏎ the whole program. [https://gitter.im/crystal-lang/crystal?at=5c91e82152c7a91455c455d8]
<FromGitter>
<bew> @jtianling note that the problem exists with Person only https://carc.in/#/r/6j4q
<oprypin>
nice
<FromGitter>
<bew> @jwoertink you wanted to access the argument, or its type?
<FromGitter>
<jtianling> Thanks, I misunderstand it, but we can't infer @name 's type from "@name = name + "NO!"" the code?
<FromGitter>
<jtianling> when name is surely a string too.
<oprypin>
jtianling: it is possible to infer but the language enforces straightforward assignments for instance variables
<FromGitter>
<bew> Theorically you could change the + method to return something else than a string, and the compiler doesn't want to check eeeeverything
<oprypin>
otherwise there might be large-scale reprecussions from mistakes elsewhere in a program. and it improves compile times i think
<jokke>
mainly i want to have readable stack traces in production
<FromGitter>
<jwoertink> Does it still segfault if you remove the `--release`?
<FromGitter>
<jwoertink> Thanks @Blacksmoke16 That's what I assumed, just checking if I missed something
<jokke>
hm, just a sec
<FromGitter>
<Blacksmoke16> np
<jokke>
is -Drelease the same thing as --release?
<jokke>
i have a macro that only loads stuff when flag(:release) is false
<jokke>
oh ok it builds with -Drelease and --debug
<jokke>
but yeah. i guess that's not optimized
<jokke>
this is alpine and 0.27.0 btw
<FromGitter>
<jwoertink> I'm not sure what the `-D` flag does. It sucks it won't be optimized, but that at least lets you debug in production for a short bit if you needed
<jokke>
we use sentry
<jokke>
and it'd be great so see stack traces
<FromGitter>
<straight-shoota> `--Drelease` only sets the `release` flag, but doesn't actually compile in release mode
<jokke>
yeah
<jokke>
trying with official crystal docker image
<FromGitter>
<straight-shoota> Maybe it's related to #7558?
<FromGitter>
<jwoertink> I'm using bugsnag in production and get full stack traces
<FromGitter>
<jwoertink> and I don't have a debug flag set
<FromGitter>
<jwoertink> sometimes it has useful info, and sometimes it doesn't though
<jokke>
yup also fails on official docker image
<jokke>
jwoertink really?
<jokke>
jwoertink but do you have the --release flag set?
<jokke>
straight-shoota i think it's exactly that issue
<jokke>
i'm glad that it's so easily reproducable
<jokke>
`echo | crystal eval --release --debug`
<jokke>
is anyone here @rooster on github?
<jokke>
sorry @r00ster91
<jokke>
asterite: care to elaborate?
<jokke>
i saw you responding to the issue
<FromGitter>
<jreinert> Hm @asterite?
<jokke>
not sure how these mentions work across irc and gitter
ua has quit [Quit: Leaving]
<FromGitter>
<jwoertink> I have this method that throws a compile-time error, and I'd like to display the line number of where that method was called
<FromGitter>
<jwoertink> I've seen these things `#<loc:push>(#<loc:"foo.cr",1,10> 1 )#<loc:pop>.to_s` before... is that how I'd do that? And if so, is there docs on how to use this?
<FromGitter>
<jwoertink> I saw that in the ecr specs, but I'm not really sure how to read that line
ua has joined #crystal-lang
<FromGitter>
<jwoertink> oh, looks like `__LINE__` gives me what I wanted. Not sure how consistent that is, but I'll try that for now
<FromGitter>
<jwoertink> but if anyone has a better way, (or if that is the best way), let me know
<FromGitter>
<jwoertink> oh.. nope. That doesn't work. Just a coincidence that it worked the first time lol
<FromGitter>
<jwoertink> like here it says line 4 from `__LINE__`, but do I have access to that actual line that's in the stack trace there?
<FromGitter>
<jwoertink> or can I use that `#<loc` thing to customize what that says?
<FromGitter>
<straight-shoota> The error message already says "Error in line 19"
<FromGitter>
<jwoertink> I get that, but I want access to that in my custom message
<FromGitter>
<straight-shoota> Okay. So `__LINE__` is a special constant. In general, it refers to the *current* line. But when used as default value of an argument, it refers to the calling line.
<FromGitter>
<jwoertink> so is this `#<loc` thing not usable in this case?
<FromGitter>
<jwoertink> I don't really understand what it is. I was under the impression that it was for setting what the line number was in an exception
<FromGitter>
<jwoertink> The thing I wanted to do is I have access to `@type` which tells me the class where the error happened, but I don't have the line number that it happened on
<FromGitter>
<jwoertink> Instead, the line number I get is something irrelevant to the developer because it points back to the framework internals
<FromGitter>
<straight-shoota> The loc pragma is used to map code generated by a macro to the original macro code.
<FromGitter>
<jwoertink> pragma! I knew there was a word for that
<FromGitter>
<straight-shoota> You can use `__LINE__` to pass the location of a call site. But it's a bit difficult for compile time errors, because you can only pass it to macros.
<FromGitter>
<jwoertink> ah, yeah.. That's what I want, but I'm in a method and not a macro... Sounds like I have to do with out it
<FromGitter>
<jwoertink> thanks for the tip
<FromGitter>
<straight-shoota> Yeah, for methods this is only available at runtime.
<FromGitter>
<straight-shoota> You can't trace the caller of a method at compile time. A method would only be instantiated once even if called in different locations.
<FromGitter>
<maiha> According to the commit log, overflow is implemented in master branch but it does not work. Do you have any information? ⏎ `Int32::MAX + 1 # => -2147483648` ⏎ (using compiled compiler: a few minute ago, Crystal 0.28.0-dev [a17a656] (2019-03-20))
<FromGitter>
<r00ster91> you need to use the preview_overflow flag
<FromGitter>
<r00ster91> compile with `-D preview_overflow`
<FromGitter>
<maiha> Cool! thanks!
<FromGitter>
<r00ster91> you're welcome
<FromGitter>
<maiha> Oh, it has been enabled by default `Makefile`. hmm, weird. ⏎ `./bin/crystal build -D preview_overflow -D compiler_rt ...`
lucasb has quit [Ping timeout: 252 seconds]
lvmbdv has quit [Ping timeout: 246 seconds]
ma_ has joined #crystal-lang
lvmbdv has joined #crystal-lang
<FromGitter>
<johnjansen> hi all, im back … several releases later ...
<FromGitter>
<jwoertink> Is it weird to anyone else that `Time::MonthSpan` doesn't inherit from `Time::Span`?
laaron has joined #crystal-lang
laaron has quit [Remote host closed the connection]
<FromGitter>
<jwoertink> I want to specify a year in seconds `60 * 60 * 24 * 365`. I can't do `1.year.to_i`, so I have to do `Time::Span.new(365, 0, 0, 0).total_seconds`. Feels like the math way is easier to read and shorter.