<spuun>
How does previous_def work? Will it inline the old definition, or will it actually be a call to a shadowed version of the method?
<spuun>
Seems like it's a chain of method calls.
renich has joined #crystal-lang
<renich>
0/
<renich>
shardbox.org is down. Is Sharpshoota around?
<renich>
It's not down... the cert expired.
<renich>
straight-shoota: sorry, got mixed with your nick, hehe. shardbox.org needs it's cert renewed.
<jhass[m]>
straight-shoota: ^
<jhass[m]>
he's working with the argentinians though, might be some time until he wakes up ;)
<renich>
jhass[m]: yeah, I figured. I'm going to sleep as well. 03:36 here. ;D
renich has quit [Quit: Leaving]
taupiqueur has joined #crystal-lang
ua_ has quit [Ping timeout: 256 seconds]
ua_ has joined #crystal-lang
waleee has joined #crystal-lang
taupiqueur has quit [Quit: taupiqueur]
ejjfunky has quit [Ping timeout: 256 seconds]
Guest70931 has joined #crystal-lang
Flipez5 has joined #crystal-lang
[RMS] has joined #crystal-lang
Flipez has quit [*.net *.split]
mookie has quit [*.net *.split]
[R] has quit [*.net *.split]
mattt2 has quit [*.net *.split]
Flipez5 is now known as Flipez
mattt2 has joined #crystal-lang
waleee has quit [Ping timeout: 256 seconds]
ejjfunky has joined #crystal-lang
ngp has quit [Quit: connection reset by purr]
waleee has joined #crystal-lang
notzmv has quit [Ping timeout: 240 seconds]
<FromGitter>
<domgetter> Is it possible to tell the compiler to make .o files that are used by future compile calls?
<FromGitter>
<domgetter> Like in the same fashion that gcc can take a list of .o files
<FromGitter>
<oprypin:matrix.org> @domgetter: what's your goal? to get these files or to get the compiler to reuse them?
<FromGitter>
<oprypin:matrix.org> .o files in Crystal language are almost never manually reusable. they *are* definitely part of the compilation process. ⏎ ⏎ .o files in C language are reusable and indeed possible to add to linking, even via Crystal syntax
<FromGitter>
<domgetter> My ultimate goal is to not have to recompile all parts of the program any time anything changes, through the use of make or something similar, as this is taking longer than I'd like.
<FromGitter>
<domgetter> ".o files in C language are reusable and indeed possible to add to linking, even via Crystal syntax" Is it possible for the crystal compiler to create a .o file that behaves like this?
<riza>
@domgetter how long are your compile times?
<FromGitter>
<domgetter> for about 6000 lines of code
<FromGitter>
<domgetter> broken up across ~20 classes
<FromGitter>
<domgetter> On an i7 4790K 4GHz
<FromGitter>
<domgetter> So not like some potato laptop or anything
<riza>
yeah I prefer the carrot laptops anyway ;-)
<riza>
17s can feel like a lot, I get that.
<riza>
Does the stdlib or shards libray provide code that I can use to extract information from a shard.yml file?
<FromGitter>
<Blacksmoke16> like its name/version or?
taupiqueur has joined #crystal-lang
<riza>
I'm actually looking to inspect the version of a specific dependency
<riza>
right now i have to hard code it in some accessory scripting and I'd like to just sub out a `crystal -e 'parse shardfile'` type one-line
<FromGitter>
<Blacksmoke16> what are you using it for?
notzmv has joined #crystal-lang
<FromGitter>
<domgetter> So just to confirm, there is no `gcc -c` equivalent for the crystal compiler?
<FromGitter>
<Blacksmoke16> id doubt it
<FromGitter>
<Blacksmoke16> but dont quote me
ejjfunky has quit [Ping timeout: 245 seconds]
taupiqueur has quit [Ping timeout: 252 seconds]
taupiqueur has joined #crystal-lang
ur5us has joined #crystal-lang
taupiqueur_ has joined #crystal-lang
taupiqueur has quit [Ping timeout: 250 seconds]
<yxhuvud>
Eh, the 4790 was released in 2014. So I'd classify that as a potato level machine.
<yxhuvud>
domgetter: No.
ur5us has quit [Ping timeout: 250 seconds]
taupiqueur has joined #crystal-lang
taupiqueur_ has quit [Ping timeout: 250 seconds]
<FromGitter>
<domgetter> Your classification notwithstanding, 350 LOC/s seems unacceptable for some code that isn't using any compiler macros or anything dynamic like that. It loads some XML files and BMPs and converts to a different output format for a video game engine. The runtime of the code is great, but the compile time makes no sense to me.
<FromGitter>
<Blacksmoke16> tis one of the cons of crystal
<FromGitter>
<RespiteSage> As I understand it, one of the "problems" is that the compiler has to determine that the code doesn't do anything special, particularly as it relates to typing.
<FromGitter>
<RespiteSage> So it doesn't take a long time because of that code specifically *is* but rather because of what that code *could be*.
<FromGitter>
<RespiteSage> *because of what that code
taupiqueur_ has joined #crystal-lang
taupiqueur has quit [Ping timeout: 256 seconds]
<FromGitter>
<domgetter> In the stats breakdown, all the time is spent in codegen and linking
<FromGitter>
<domgetter> Seems like the type checking part of the work is blown through pretty quickly
<FromGitter>
<domgetter> unless it does some of the "figure out what code isn't needed" stuff during codegen
<FromGitter>
<Blacksmoke16> codegen is llvm afaik
ur5us has joined #crystal-lang
<FromGitter>
<domgetter> Yeah in the release build, 32 of the 44 seconds are spent in "Codegen (bc+obj)" and 8s on linking
<FromGitter>
<RespiteSage> Huh. I guess I understood it wrong, then.