<FromGitter>
<erdnaxeli:cervoi.se> I once opened an issue to extend this discriminator macro, but actually everything you want to add is very specific to what you do. I would just recommend to copy past the macro in your code and edit it.
_ht has joined #crystal-lang
<FromGitter>
<erdnaxeli:cervoi.se> My version can discriminate on multiple fields + can use nested fields + has a default type when nothing matches
<FromGitter>
<Daniel-Worrall> Do you have a copy of it online?
<FromGitter>
<mattrberry> Out of curiosity, if I have this program ⏎ ⏎ ```arr = [1, 2, 3, 4] ⏎ a, b, c, d = arr.map &.+ 1``` ⏎ ⏎ Is there any chance at all that the result of the `arr.map` *won't* end up on the heap, and that this is optimized in some way? [https://gitter.im/crystal-lang/crystal?at=6001434881c55b09c70c1719]
<FromGitter>
<mattrberry> Really, I just don't want to stick a new array on the heap. If this *does* put an array on the heap, I'll just do it by hand because I only have 4 elements in my case anyway
<FromGitter>
<mattrberry> Actually, if this will end up on the heap, I could just use a staticarray instead
<FromGitter>
<Daniel-Worrall> ty, I'll have a look
hightower3 has joined #crystal-lang
ua has joined #crystal-lang
<FromGitter>
<asterite> Matthew Berry: the answer is no. The language doesn't do those optimizations and it's actually pretty hard to do that
<hightower3>
watzon looks pretty good, yes
<hightower3>
(mkdocstrings-crystal)
hightower3 has quit [Ping timeout: 265 seconds]
hightower2 has joined #crystal-lang
hightower2 has quit [Ping timeout: 240 seconds]
hightower2 has joined #crystal-lang
<hightower2>
Hey what's crystal's behavior re. chained properties? Like, if I need to call 5 different methods on self.something.something_else, will listing them in a row somehow optimize it, or it will be faster if I do x = self.something.something_else, and then call those 5 methods on 'x' ?
<raz>
did you try benchmarking it? i'd be surprised if there was a measurable difference between the two
<FromGitter>
<asterite> Shouldn't make a difference
<hightower2>
great, thank you
<yxhuvud>
I mean, there *could* be a difference if for example the middle result end up allocating like mad or so.
psydroid has left #crystal-lang ["User left"]
<hightower2>
right, right. No it's just property lookup
postmodern has joined #crystal-lang
<postmodern>
can `libraries:` in the shard.yml specify multiple version constraints for a library (ex: >= 1.2.0, < 1.7.0)
<FromGitter>
<Blacksmoke16> id imagine. that section isnt really used for anything other than providing info to the user reading it
<FromGitter>
<Blacksmoke16> used for anything that automated*
Volk has joined #crystal-lang
<postmodern>
good to know, thanks
duane has joined #crystal-lang
<straight-shoota>
postmodern, I would interpret version restrictions for library the same way as other version restrictions, thus you can combine them
<straight-shoota>
even if that's not explicit in the spec
<FromGitter>
<wyhaines> *rubs eyes* ⏎ ⏎ Question for y'all. Let's say that I have two fibers. I want one of them to wake up and do something every N seconds, but I don't want to stick some `if Time.local > timeout...` case in a tight loop in order to figure out when to have the first fiber yield. Does the fiber scheduler give me a way to do it?
<FromGitter>
<Blacksmoke16> loop do with sleep?
<FromGitter>
<wyhaines> The thing is that the first fiber isn't doing io operations. It's doing a CPU intensive task. So the second fiber never actually gets yielded to.
<FromGitter>
<wyhaines> So....it's more tricksy. :)
<FromGitter>
<jrei:matrix.org> that's strange... if there is CPU/IO room, the other fiber should execute
<FromGitter>
<naqvis> in that case you should be using MT mode
<straight-shoota>
you should just occasionally yield the work fiber
<FromGitter>
<wyhaines> With full threads, this is simple, since the OS takes care of it. With fibers inside of Crystal, though, I haven't figured out how to make it work.
<FromGitter>
<naqvis> as default is single threaded
<straight-shoota>
Fiber.yield every now and then
<straight-shoota>
or sleep 0
<straight-shoota>
effectively the same
<FromGitter>
<wyhaines> @straight-shoota That's the point. I want to yield every N seconds.
<straight-shoota>
sleep 0 if Time.monotonic > last_timer + n.seconds
<straight-shoota>
or rather Time.monotonic > next_timer
<FromGitter>
<naqvis> i believe kirk point is scheduler should be able to yield at specific intervals for cpu intensive tasks, thus giving others fibers a chance to breathe
<straight-shoota>
there's no way to do that
<straight-shoota>
you probably shouldn't have to deal with this timer stuff in the work fiber, though
<FromGitter>
<wyhaines> So, to use Ruby as an example. I can have two threads. One of them can be in a loop that does something, and then sleeps N. The other can do whatever it wants, in a tight CPU bound loop. ⏎ ⏎ So far as I can tell, with Crystal, if I have two fibers, I have to incur the (sizeable) cost of checking Time.monotonic on ever iteration of the tight loop in order to determine when N seconds have passed in order
<FromGitter>
... to yield. Right?
<straight-shoota>
just have it yield it between some loops
<straight-shoota>
if no other fiber is ready, it will just continue
<FromGitter>
<naqvis> Kirk you are mixing Threads with Fibers
<FromGitter>
<naqvis> to use multiple threads, you should be using the MT mode, or else its just a single threaded app
<straight-shoota>
> I have to incur the (sizeable) cost of checking Time.monotonic on ever iteration of the tight loop in order to determine when N seconds have passed in order
<straight-shoota>
definitely not
<FromGitter>
<wyhaines> Actually, that is a relevant question. If I use MT mode, will it work differently? I assumed that it would still work basically the same, except that the fibers might be in different threads, and hence on different cores.
<FromGitter>
<jrei:matrix.org> @wyhaines: does the task you do N times depends on state shared with the main fiber?
<FromGitter>
<jrei:matrix.org> If no, you can just do multi-process
<straight-shoota>
you don't need multiple processes
<FromGitter>
<jrei:matrix.org> Yes of course, but will be more efficient and possibly simpler
<straight-shoota>
@wyhaines Yes, with MT you can have a fiber with a tight loop and it will just block one thread
<straight-shoota>
other fibers can execute on other threads
<FromGitter>
<wyhaines> OK. I think something that you said, @straight-shoota , changed a faulty assumption in my head. Just a second.... :)
<FromGitter>
<wyhaines> OK, calling Fiber.yield on every iteration is SUPER slow. I mean, it works, but the cost is huge. It does work, though. Now, with MT mode....
<straight-shoota>
how long is one iteration?
<straight-shoota>
you don't need to yield on every single one
<straight-shoota>
just every nth would do
<FromGitter>
<wyhaines> @straight-shoota Yeah, that was my original solution. I yielded every 10000000 iterations. ⏎ ⏎ Running with MT mode does the job without that, though, which I didn't realize that it would do. I was thinking of it with incorrect semantics. I learned something today. Alles is goed! Everything is good!
ua has quit [Ping timeout: 264 seconds]
ua has joined #crystal-lang
<hightower2>
0.36 :-)
<yxhuvud>
even with MT enabled you can create as many threads as you have and then hog them though, so the problem can reappear even with it
<oprypin>
straight-shoota: i can't do css obviously lol. anyone can just go ahead and suggest a style. both for general inclusion and individually
<oprypin>
straight-shoota: the links are indeed a problem but it's not something you'd miss because a loud warning gets output
<oprypin>
just a bug that i don't have an idea of solving. basically only first of a set of overloads gets linked properly
<oprypin>
have an idea *yet* that is
<FromGitter>
<watzon> Anyone know how to go about adding new LLVM intrinsics? When I try to compile code with this `fun fshr32 = "llvm.fshr.i32"(a : Int32, b : Int32, c : Int32) : Int32` in LibIntrinsics I get an undefined symbol error for `_llvm.fshr.i3`