<FromGitter>
<jwoertink> Is there any sort of performance hit by having larger unions?
<FromGitter>
<fridgerator> I hope not, lol
<FromGitter>
<jwoertink> haha
<FromGitter>
<jwoertink> I wasn't sure, but I was just thinking about it. I have these large unions all over my code and was curious if that made a difference or not
olek_poz has joined #crystal-lang
olbat has quit [Ping timeout: 240 seconds]
olek_poz has quit [Ping timeout: 252 seconds]
<FromGitter>
<schoening> I assume there is more if/elseif logic the bigger the unions get?
<FromGitter>
<bew> I also don't that you'll get any performance penalty, but if you have big types in your union, the variable will use the same amount of memory that's necessary to store the biggest type of the union
<FromGitter>
<bew> think*
<FromGitter>
<sdogruyol> @elorest yeah, i've also compiled like that
<FromGitter>
<bew> what exactly is a Metaclass in the compiler ?
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bjz has joined #crystal-lang
Qchmqs has quit [Ping timeout: 240 seconds]
zipR4ND has quit [Ping timeout: 240 seconds]
Qchmqs has joined #crystal-lang
cyberarm has quit [Ping timeout: 256 seconds]
_bowser_ has quit [Ping timeout: 240 seconds]
cyberarm has joined #crystal-lang
greengriminal has joined #crystal-lang
zipR4ND has joined #crystal-lang
greengriminal has quit [Quit: Leaving]
<RX14>
@jwoertink there's a performance hit because using a larger union increases the number of possible method implementations which can be dispatched to at any point. handling this increases code which means more instructions to execute (and less icache efficiency).
<RX14>
so yes there is a performance penalty to large unions, especially when they have disparate types in
<RX14>
but don't bother optimizing it, it'll be premature
<RX14>
well, in most places
<FromGitter>
<bew> oh...
zipR4ND has quit [Ping timeout: 252 seconds]
<crystal-gh>
[crystal] bcardiff opened pull request #4271: Restore default value of Colorize.enabled. Add Colorize.on_tty_only! (master...fix/colorize/tty-detection-on-demand) https://git.io/vSX32
z64 has quit [Quit: WeeChat 1.6]
zipR4ND has joined #crystal-lang
<crystal-gh>
[crystal] MakeNowJust opened pull request #4272: Tool: refactor context/expand/implementation in point of traversaling typed defs (master...fix/crystal-tool/refactor-type-processor) https://git.io/vSXB8
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
zipR4ND has quit [Ping timeout: 240 seconds]
_whitelogger has joined #crystal-lang
zipR4ND has joined #crystal-lang
<FromGitter>
<jwoertink> Thanks @mjago for the explanation and link. That's good to know @RX14. I've always had a problem with premature optimizing. The doctors say I'd grow out of out when I got older
<FromGitter>
<jwoertink> :joy:
bjz has joined #crystal-lang
McSoFake has joined #crystal-lang
<vegai>
OpenBSD 6.1 just came out
<vegai>
I've seen some talk about continuous integration that would support and build binaries for many different operating systems
<vegai>
Julien Portalier, I think, was doing that work
<vegai>
something like that would be needed for distros that go with Musl instead of glibc
<vegai>
like Alpine Linux
<FromGitter>
<bew> wow nice news!
<RX14>
vegai, I'm the one working on CI
<RX14>
for crystal
Qchmqs has quit [Ping timeout: 240 seconds]
<vegai>
RX14: ah, cool :)
<vegai>
how's it going?
<RX14>
it's currently x86_64 only (on AWS)
mark_66 has quit [Remote host closed the connection]
<RX14>
and only on linux/glibc
<RX14>
but it'll get there
<RX14>
32-bit (linux32) support will be next
<RX14>
well actually the next thing is to get it working at all on 1 target
<RX14>
but after that it'll be 32bit linux then we'll have to see
<RX14>
I might be able to get alpine working in an AMI
<RX14>
I might end up doing in in a chroot
<vegai>
any hope for the more fringy systems like BSDs?
<RX14>
as for the BSDs, if it works on AWS it'll be done there
<RX14>
if not, donate boxen
<vegai>
mm :)
<RX14>
it'll be nightly though, instead of on every commit
<vegai>
how does it work? I don't quite understand how Crystal can be bootstrapped
<txdv>
why not?
<RX14>
vegai, can you clarify what you mean by "bootstrapped"
<vegai>
how do you build crystal without crystal?
<RX14>
vegai, the same way you build gcc
<RX14>
with gcc
<RX14>
you don't build gcc without a C compiler
<RX14>
there was an original C compiler way back that wasn't written in C
<RX14>
but since then it's just been signed copies of the C compiler building the next C compiler
<RX14>
same with crystal
<RX14>
you download a precompiled crystal compiler than build the next crystal with it
<vegai>
right... so if your system doesn't yet have a precompiled crystal, you crosscompile?
<crystal-gh>
crystal/master 976437a Guilherme Bernal: WebSocket: Add support for receiving binary messages
<crystal-gh>
[crystal] Sija opened pull request #4274: Fix small stuffs (master...fix-small-stuff) https://git.io/vS1fX
<FromGitter>
<chuckremes> Anyone have a clue why extend isn’t overriding `new` in my `Foo` class? Also, the `extend` hook isn’t printing anything even though the `ClassMethods` module was definitely loaded (otherwise `Foo.foo` would fail which it doesn’t).
<FromGitter>
<chuckremes> I posted this (similar) question to the mailing list but no takers so far. I suspect most are hanging out on irc & gitter these days.
<crystal-gh>
[crystal] Sija closed pull request #4274: Fix small stuffs (master...fix-small-stuff) https://git.io/vS1fX
<crystal-gh>
[crystal] Sija opened pull request #4275: Fix small stuffs (master...small-stuff-fixes) https://git.io/vS1IX
<FromGitter>
<chuckremes> So I figured out why the extend hook didn’t fire… it was in the wrong place. That macro needs to be in the module/class that is being extended, not the class/module that is doing the extend.
<FromGitter>
<chuckremes> Sort of figured out the original question… with the extend macro in the right place I can now redefine (and add overloaded) `def self.new(…)` methods which can be run from `Foo`. However, I can’t do a generic `def self.new(*args)` method signature to capture all possible ways of calling `Foo.new()`. I’ll keep poking at this. Ideas welcome.
<FromGitter>
<g33kidd> I assume that's the same for client.run, possibly. What approach could I take in dealing with blocking code? What should I be reading in the docs?
<FromGitter>
<tjgillies> just put one of them in a spawn block
<FromGitter>
<tjgillies> the Kemal.run in this case
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<kodo[m]>
spawn { Kemal.run }
bjz has joined #crystal-lang
<FromGitter>
<g33kidd> Oh snap, thanks! I tried it earlier before, but I was adding spawn {} on client.run and kemal.run so maybe I was using it wrong there.
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bjz has joined #crystal-lang
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bjz has joined #crystal-lang
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]