<FromGitter>
<jwoertink> The issue I'm running in to right now is when I hit ^C, it goes to the next line, but doesn't "puts" anything. Once I run a command like `1 + 1` then it will run the trap block
<FromGitter>
<jwoertink> I'm not sure why the trap block isn't executed immediately once ^C is pressed. Maybe there's a config somewhere I have to set?
danielpclark has quit [Ping timeout: 252 seconds]
onec has joined #crystal-lang
danielpclark has joined #crystal-lang
voldz1tic3n has joined #crystal-lang
mgarciaisaia has quit [Quit: Leaving.]
matp has quit [Remote host closed the connection]
matp has joined #crystal-lang
matp has quit [Remote host closed the connection]
matp has joined #crystal-lang
bazaar has quit [Ping timeout: 245 seconds]
bazaar has joined #crystal-lang
voldz1tic3n has quit [Ping timeout: 258 seconds]
aemadrid_ has joined #crystal-lang
hmans_ has joined #crystal-lang
mroth_ has joined #crystal-lang
Liothen- has joined #crystal-lang
pabs_ has joined #crystal-lang
aemadrid has quit [Ping timeout: 240 seconds]
mroth has quit [Ping timeout: 240 seconds]
hmans has quit [Ping timeout: 240 seconds]
Liothen has quit [Ping timeout: 240 seconds]
pabs has quit [Ping timeout: 240 seconds]
hmans_ is now known as hmans
aemadrid_ is now known as aemadrid
Liothen- is now known as Liothen
mroth_ is now known as mroth
voldz1tic3n has joined #crystal-lang
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
voldz1tic3n has quit [Ping timeout: 258 seconds]
mark_66 has joined #crystal-lang
voldz1tic3n has joined #crystal-lang
bazaar has quit [Ping timeout: 255 seconds]
bazaar has joined #crystal-lang
soveran has quit [Remote host closed the connection]
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
voldz1tic3n has quit [Ping timeout: 252 seconds]
A124 has quit [Ping timeout: 240 seconds]
A124 has joined #crystal-lang
gloscombe has joined #crystal-lang
bjz has joined #crystal-lang
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 268 seconds]
Raimondii is now known as Raimondi
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
literal_ is now known as literal
bew78 has joined #crystal-lang
bjz has joined #crystal-lang
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vDuzr
<crystal-gh>
crystal/master ecda856 Ary Borenszweig: Compiler: always resolve T in main code as non-virtual. Fixes #3989
<FromGitter>
<luislavena> @jwoertink maybe the event loop is halted waiting for input, which might be why the Ctrl+C event isn't triggered right away
<Yxhuvud>
I've run into some cases when the default quit handler isn't triggered right away as well, and as far as I know, that didn't involve the event loop.
<Yxhuvud>
ie I wasn't using any fibers/IO/whatever.
<FromGitter>
<luislavena> @Yxhuvud everything in crystal involves the event loop. waiting for IO, sending to IO.
<FromGitter>
<luislavena> if you add code to catch INT but then do a tight loop (with no sleep, Fiber.yield or anything) it will never trigger the block associated with the signal
<FromGitter>
<luislavena> same goes for a call to a C library that halts the crystal program.
<Yxhuvud>
I guess that situation will be greatly improved once we get support for running several fibers on different thread.
danielpclark has quit [Ping timeout: 255 seconds]
<FromGitter>
<luislavena> Yup, but still you need to be aware not to clog the event loop (ala: be more friendly) :D
<FromGitter>
<sdogruyol> sup all
onec has quit [Remote host closed the connection]
onec has joined #crystal-lang
<Yxhuvud>
not much. trying to get some motivation to actually do something before I start on my new gig on monday
<FromGitter>
<sdogruyol> @Yxhuvud congrats on your new gig
onec has quit [Ping timeout: 240 seconds]
<Yxhuvud>
thanks. The previous gig moved to India x_x. Thankfully the job situation for rubyists is pretty ok here in stockholm
danielpclark has joined #crystal-lang
<FromGitter>
<sdogruyol> @Yxhuvud where you from?
<Yxhuvud>
I grew up some 35km outside Stockholm, so I'm native.
<FromGitter>
<sdogruyol> @yxhuvud that's cool
<Yxhuvud>
But now I really need some more coffee, before I implement a hello-world port of the hash changes of ruby 2.4, but for crystal.
bazaar has quit [Ping timeout: 240 seconds]
bazaar has joined #crystal-lang
bjz has joined #crystal-lang
bjz_ has quit [Ping timeout: 255 seconds]
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
splitty_ has quit [Quit: Leaving]
sz0 has quit [Quit: Connection closed for inactivity]
Raimondi has quit [Quit: WeeChat 1.6-dev]
Raimondi has joined #crystal-lang
splitty_ has joined #crystal-lang
voldz1tic3n has joined #crystal-lang
mgarciaisaia has joined #crystal-lang
Svenskunganka has joined #crystal-lang
voldz1tic3n has quit [Ping timeout: 252 seconds]
voldz1tic3n has joined #crystal-lang
Svenskunganka has left #crystal-lang [#crystal-lang]
Svenskunganka has joined #crystal-lang
mark_66 has quit [Remote host closed the connection]
jokke has quit [Ping timeout: 255 seconds]
jokke has joined #crystal-lang
voldz1tic3n has quit [Ping timeout: 240 seconds]
jokke has quit [Ping timeout: 256 seconds]
jokke has joined #crystal-lang
<crystal-gh>
[crystal] matiasgarciaisaia closed pull request #2147: Add man page to crystal (master...feature/man-page) https://git.io/vDzBh
<Papierkorb>
Anyone got a idea how to debug a TCPSocket (which was #accept'ed from a TCPServer) not receiving packets? I suspect a bug in crystal. Symptoms: 1) Does not accept the connection at all (Client keeps saying "connecting..") or 2) No packet is received from client or 3) Later packet is not received from client. After a packet has not been received, the connection is "dead", but a disconnection is correctly 'found'.
<Papierkorb>
The code uses Fibers for concurrency (accept fiber + a fiber for each connection), the first byte (which is the command byte) is read using TCPSocket#read_byte
* Papierkorb
brb 20min
voldz1tic3n has joined #crystal-lang
<crystal-gh>
[crystal] bcardiff closed pull request #3961: Fix `Enum#to_s` to wrap flag enums with parens (master...fix/enum/to_s_wrap_multiple_flags) https://git.io/vDLsz
<crystal-gh>
[crystal] bcardiff closed pull request #4005: Fix Enum#to_s for flag enums to join with pipe (master...fix/enum/pipe-to-s) https://git.io/vDCrI
<FromGitter>
<jwoertink> in this line here, I know this gets hit every time ^C is pressed
<RX14>
ok
<RX14>
well i'm guessing crystal-icr IS io-bound
<FromGitter>
<jwoertink> This is where I would return to the event loop?
<RX14>
try it?
<FromGitter>
<jwoertink> is the `Fiber.yield` what returns to the event loop?
<FromGitter>
<drosehn> Huh. I connected here just after reading the latest comments on the issue about documenting `Signal`. It sounds as if the `printf` I did in the example program actually helped that to work better, even though I really shouldn't have been doing any I/O in a signal handler?
<RX14>
IO is fine in signal handler in crystal, because crystal "signal handlers" aren't implemented in real signal handlers
<RX14>
the actual signal handler only pushes some info to a pipe
danielpclark has joined #crystal-lang
<RX14>
which crystal picks up and executes the user-specified signal handler in the normal crystal environment
<FromGitter>
<drosehn> Ah, good. Someone else pointed out that there are a very limited number of routines which are safe to call in signal handlers, and when talking about the C/Unix API that is a true statement. I thought he was pointing out that I shouldn't have done the `printf` (and quite frankly, I expected that he was correct to point that out).
<RX14>
nope, crystal makes it safe
<RX14>
the problem is that crystal's fibers are cooperative
<RX14>
once the signal handler fires, the code is only actually run once the fiber that 8was* running before the signal handler yields
<RX14>
(unless it was in the event loop when the signal handler ran)
<RX14>
learning about fibers would really help here I think
<RX14>
fibers are really not heard to suss out in crystal because they're implemented in crystal + 30 lines of asm
<FromGitter>
<drosehn> Yeah, I'm sure that's an important topic that I need to learn. I haven't had the time to yet, and I haven't used anything like fibers in the other languages I use. (or if I did, I didn't know it!)
<FromGitter>
<jwoertink> Yeah, I know nothing about fibers, signals, event loops.....
<FromGitter>
<jwoertink> why the hell am I even programming! >_<
<FromGitter>
<jwoertink> anyway, putting a `Fiber.yield` in that method didn't do anything
<FromGitter>
<jwoertink> I wonder if that makes a difference
<Svenskunganka>
There was a great video I saw explaining the event loop in V8, let's see if I can find it.
<RX14>
V8's quite different though
<RX14>
i guess it explains event loops
<RX14>
ok, i'll try explaining it
<RX14>
first we intorduce the concept of fibers
<RX14>
fibers are essentially stacks
<RX14>
every fiber is just a stack
<RX14>
and there's a Fiber object
<RX14>
which contains that stack
<FromGitter>
<drosehn> I've done `signal()` level programming in C (where it is very messy), and I've worked with event loops in NeXTSTEP and MacOS programming (where all the details are nicely hidden away from the programmer). Nothing fiber-ish. Nothing with threads in any language.
<RX14>
if you have a Fiber object you can call Fiber#resume
<RX14>
and it'll save your current stack, and switch to the new one
<RX14>
if the fiber you call #resume on has a reference to the old fiber
<RX14>
it can call #resume on that and switch back
<RX14>
from this we can switch around really leightweight threads cooperatively
<RX14>
the cool thing crystal's stdlib does is bind a library called libevent2
<RX14>
with libevent2, you can ask the library, "hey, run this callback when this file descriptor is ready to read"
<RX14>
same applies for write
<RX14>
and you can even ask it to run a callback in a few seconds
<RX14>
just like nodejs but your options are much mroe limited
<FromGitter>
<jwoertink> ah, interesting
<RX14>
so, the IO::FileDescriptr class (from which File, TCPSocket etc. inherit from)
<RX14>
uses this library and the fiber mechanism
<RX14>
it sets the file descriptor as nonblocking
<RX14>
you call LibC.read() on the FD
<RX14>
because it's nonblocking the syscall returns EAGAIN (iirc)
<RX14>
and then the class does a couple things:
<RX14>
it registers a callback with libevent2 which will resume the current fiber, and then it yields to the scheduler
<RX14>
(the scheduler is just a list of fibers waiting to be run)
<RX14>
so the scheduler picks the next thing on the list and starts executing that
<RX14>
once the list is empty, the fallback option is to run libevent2's eventloop
<RX14>
which will run until a callback needs to be fired
<RX14>
that callback will resume the waiting fiber
<RX14>
and it will loop back and try LibC.read again
<RX14>
a similar thing happens for read, writes and sleeps
<RX14>
it sounds as if the event loop is very rarely reached though, only if there's nothing to do right?
<Svenskunganka>
Yeah
<RX14>
but the magic is that blocking on IO is 90% of what webapps do
<RX14>
so it works great for them
<RX14>
unfortunately it breaks down for some other workloads which aren't so IO-heavy
<RX14>
that's when you need to manually use Fiber#yield
<RX14>
Scheduler#yield, sorry
<RX14>
if you're doing IO, Scheduler#yield is pointless because the IO is doing it already
<FromGitter>
<jwoertink> Scheduler#yield is what tells the scheduler to use the next fiber in the list?
<RX14>
yes
<FromGitter>
<jwoertink> holy shit I think I'm learning something....
<RX14>
you can read it yourself:
<RX14>
oh
<RX14>
i was wrong
<RX14>
it WAS Fiber.yield
<FromGitter>
<jwoertink> lol
<RX14>
what fiber.yield does is exactly this:
<RX14>
sleep(0)
<RX14>
the sleep implementation will register a callback in libevent2 to fire asap
<RX14>
then it will tell the scheduler to run the next fiber available
<RX14>
and so it will work through the scheduler list until we're in the event loop again and then start running the current fiber again
<RX14>
now the event loop will run IO callbacks before sleep callbacks I assume
<RX14>
which means that it will run IO callbacks too (i.e. run the callback already registered for the Signal pipe)
<RX14>
and that callback will resume the signal fiber
soveran has quit [Remote host closed the connection]
<RX14>
which will read 1 entry from the signal pipe and then run the handler in it's fiber
<RX14>
i'd highly recommend reading unbuffered_read in IO::FileDescriptor
<RX14>
questions are appreciated :)
<FromGitter>
<jwoertink> Ok. trying to soak all this in.
<RX14>
but the key thing is that it's all cooperative
<RX14>
a fiber will keep running forever until something tells the scheduler to call Fiber#resume on the next fiber in the list
<FromGitter>
<jwoertink> The unbuffered_read method looks like it's in `IO::Buffered`
<FromGitter>
<jwoertink> I appreciate you taking the time to explain all this!
<FromGitter>
<jwoertink> Definitely outside my comfort zone, but all stuff that I really need to learn
<FromGitter>
<jwoertink> Makes me so mad that I spent so much money on a programming degree that never covered stuff like this. Stupid college :angry:
<Svenskunganka>
I found the video, but I'm not sure how much it differs from the crystal event loop, so take it with a grain of salt: https://www.youtube.com/watch?v=8aGhZQkoFbQ
<FromGitter>
<jwoertink> sweet! Thanks for the video
<RX14>
@jwoertink this is quite specific stuff, i'm not sure why a CS degree would cover it
<RX14>
maybe event loops
<RX14>
and callbacks
<RX14>
and obviously what the stack is enough to understand what Fiber#resume does
<FromGitter>
<jwoertink> haha. Yeah. They covered HTML, CSS, VisualBasic syntax and I can make one hell of a UML diagram :joy:
<RX14>
no computer/CPU architecture?
<Svenskunganka>
@jwoertink Haha I understand your frustration, being self-taught and completely skipped low-level stuff has turned out to be quite the mistake. I'm trying to make up for it now though.
<FromGitter>
<jwoertink> nope,
<FromGitter>
<jwoertink> but my degree did require that I take a history of rome and greek mythology classes
<FromGitter>
<jwoertink> oh, and US history was definitely required
<FromGitter>
<jwoertink> you know, the important stuff. lol
<FromGitter>
<jwoertink> I did have to take a "how to use a computer" class. It explained what a mouse was, and monitor. Broke down how computers are put together, but if it wasn't about Windows XP, then it didn't get taught
Svenskunganka has quit [Quit: leaving]
<RX14>
thats weird, stacks and simple CPU architectures are part of my A-level course, which is essentially highschool i guess
<RX14>
it's not the same in the UK so it's a weird comparison but still
Svenskunganka has joined #crystal-lang
<FromGitter>
<jwoertink> I went in to computers late. My first degree was music performance, so I missed out on all the high school courses that talked about that cool stuff.
<RX14>
ah I see
<RX14>
i find it quite useful knowing the lower level how a CPU works to get an idea of how to optimize code but i'm afraid i'll have to give the wishy-washy "i picked it up as I went along" answer to how I learned all of it
<FromGitter>
<drosehn> I work at RPI (in Troy New York), which is pretty focused on science and engineering. And yet I'd have to say our Comp Sci program doesn't really create good programmers. There are plenty of comp-sci courses to take, but the students who become good programmers are the ones who push themselves to do that.
<FromGitter>
<drosehn> I think it's hard to become a good programmer until your forced to support some significant program which has a real user base. Without that, the only measure of the code is "am I happy at how my code works?".
<RX14>
i'll agree on that
<RX14>
the only reason i'm a good programmer is because I build things for my friends and other people essentially for free
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
sardaukar has joined #crystal-lang
sardaukar has quit [Client Quit]
<Yxhuvud>
also the field is increasingly fracturing so that even if someone is great at one thing, it doesn't necessarily mean anything in different areas.
<Svenskunganka>
@Papierkorb that's cool! Is it a WoW private server?
<Papierkorb>
Svenskunganka: Well yeah the beginning on a mmorpg server which happens to speak the WoW logon (and next, the realm/world) protocol
<Papierkorb>
Not sure yet if I'll really put it on Github. The framework part, which I want to be a somewhat generic mmorpg thing, shouldn't be an issue. Maybe with a small WoW part as example, enough to logon and jump around but not enough to really play the game or so. Didn't really think about that yet
<Svenskunganka>
Nice! Didn't know you could do that, but then again I haven't played WoW in like, a century
<Papierkorb>
I never really played WoW either :) .. okay I did play on a private server a bit, but only for a month. I'm just really interested in game servers for some reason. Eitherway, you'd feel right at home, that thing targets WoW 1.12.1, or "classic WoW"
<Svenskunganka>
Oooh that's neat.
<Svenskunganka>
Blizzard takes down anything that has to do with private servers though right?
<Svenskunganka>
iirc they're pretty strict about it
<Papierkorb>
Not the software, no, you can find two popular wow server projects on GitHub
<Papierkorb>
The instances, yeah they don't like it much :)
<Svenskunganka>
Ah I see
<Papierkorb>
Many public servers are running from Russia though, and they don't really seem to care about whatever paper blizzard sends their way
<Svenskunganka>
Yeah typical Russia :P
<Svenskunganka>
But Blizzard is a bit over the top when it comes to copyright
<Svenskunganka>
They've tried poking legally at Dota 2 since Valve decided to remake the popular custom gamemode from Warcraft 3
<Papierkorb>
Well Blizzard never innovated, but they polished everything to large extents. That's what their brand is known for and that's what they're defending when people create those servers, as they fear it could damage their pretty good reputation in that regard
<Papierkorb>
There was a really popular server `Nostalrius` shut down some months ago with >10k active concurrent players. However, those guys really tried their best and did really well in terms of quality assurance, so good that blizz flew the team into their HQ to discuss if Blizz could offer a classic version of their own
<Svenskunganka>
Oh really? Why did they have to shut down?
<Papierkorb>
Their canned that idea though as they said it'd be too expensive to produce a modern and a classic WoW at the same time. Judging from the numbers of active players though, even if only every 2nd would be willing to pay Blizz, they'd have a pretty large playerbase already
<Papierkorb>
The nostalrius guys? Their wow realm servers. The team didn't want to have trouble nor cause trouble for Blizz, they were pretty understanding from what I can tell as an outside spectator
<Svenskunganka>
Oh yeah I think I heard something about that. A former Blizzard employee even vouched for them right?
<Papierkorb>
Possibly yes, it really came as a surprise and hopes were high
balduin has joined #crystal-lang
<Papierkorb>
I only played official WoW once, that was last year, you can play for free till lvl20. Well, it was boring. you just leveled so fast, and all the professions and stuff were obsolete as you didn't need it at all. Nostalrius aimed to replicate the game from back then, and tbh I've never so much enjoyed wandering in the woods searching for plants to make herbs while idle-talking on Skype.
<Papierkorb>
Eitherway, the project (Yes, I call it "sheep") aims to teach about how to build a mmo game server, not to replicate the whole game. And as there are already plenty solutions out there for this unmaintained, decade old version of the game, I don't see much ethical issues with that
<Svenskunganka>
Nice, it's a cool project indeed. Shoot me a msg if you plan to put up the source, would love to read it!
<Papierkorb>
Svenskunganka: k, will do in that case :)
<FromGitter>
<stevensonmt> In ruby I can do `Array.reduce(:*)` to get the product of each member of the array. I can't seem to find an equivalent expression in crystal. What am I missing?