<BlaXpirit>
forget it. just have to drop it out of the module
<BlaXpirit>
this is so painful
mlitwiniuk has joined #crystal-lang
_jungh4ns has joined #crystal-lang
<BlaXpirit>
first of all I don't want this macro to be public at all but I also don't want to copy paste it into every file of my project
<BlaXpirit>
that's why I put it into a module to make it slightly less visible
<jhass>
if you want something changed open an issue and make your case
<jhass>
complaining here and then working around it won't change anything
<BlaXpirit>
it would be a big change and need to be well thought out
<BlaXpirit>
i just can't believe nobody else had this problem
<BlaXpirit>
especially with how it's popular to separate projects into tiny files
<jhass>
I don't think it would be a big change at this point
<jhass>
but it doesn't invalidate my point anyway
<jhass>
look how I just made us get rid of ifdf
<jhass>
*ifdef
<jhass>
now is the time for the big changes, not the workarounds
<jhass>
"this all sucks! Look I'll do this ugly thing instead!" is just quite annoying tbh
<BlaXpirit>
if I see a good way to improve something, I say it. and even then I miss many problematic aspects
<BlaXpirit>
here we're looking at a complete rework of what 'private' does
<txdv>
Hey girls
<BlaXpirit>
AND also a change for the way macros work inside a module
<BlaXpirit>
only after those 2 changes could I continue work without workarounds.
<jhass>
I'm not saying don't do workarounds, I'm saying contribute back so you'll eventually can get rid of them
<jhass>
changing how @type behaves when used in a macro called on a namespace is perfectly reasonable
<jhass>
we're in the process of shaping the language still, every feedback is incredible valuable, if provided in a constructive manner at a place where we can have a constructive discussion
<txdv>
so github
<jhass>
and if all it does is bring out "no we keep the current behavior and here's why", that's perfectly fine and valuable
<jhass>
ys
<jhass>
yes
<txdv>
open an issue on github and make your point clear
<jhass>
exactly
<txdv>
"I want jhass to be a keyword because he deserves it" is not a good suggestion
[spoiler] has joined #crystal-lang
Philpax has quit [Quit: Leaving]
Philpax has joined #crystal-lang
ozra_ has joined #crystal-lang
paulcsmith_ has joined #crystal-lang
snsei has joined #crystal-lang
sdogruyol has joined #crystal-lang
<sdogruyol>
what’s required to make HTTP::Server listen on unix sockets like Unicorn e.g
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
jokke has quit [Quit: WeeChat 1.5]
jokke has joined #crystal-lang
mark_66 has quit [Quit: Leaving.]
<sdogruyol>
which will receive a unix socket instead of a port
<jhass>
yeah
<jhass>
wait, we got a UNIXServer, so that of course
snsei has quit [Ping timeout: 260 seconds]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
pawnbox has quit [Ping timeout: 264 seconds]
pawnbox has joined #crystal-lang
<paulcsmith_>
Hey everyone! I've been playing around with Crystal and really like it so far! Nice work.
<paulcsmith_>
One question about Fibers: If I needed to send an email in the background, but it didn't need to be retried on failure, would it be reasonable to send that by `spawn`ing a fiber and sending the email within it?
<paulcsmith_>
How does it handle fialure? Will the fiber just close? Do I need to tell the fiber to close/shut down once the email is sent?
bjz_ has joined #crystal-lang
bjz has quit [Ping timeout: 260 seconds]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
<sdogruyol>
paulcsmith_: nice question
<sdogruyol>
when the fiber yields it’ll finish
<sdogruyol>
unless it’s left in a limbo (like no timeout or whatsoever)
acetoxy has quit [Quit: leaving]
<jhass>
paulcsmith_: yes, it'll just exit, not take the main fiber with it or so. Note that your fiber won't be run until your currently active fiber blocks on something
<paulcsmith_>
Ah that makes sense. Thank you! jhass so does that mean if I sent say, 10 emails at the same time with 10 different fibers, it would run the first email, and then the second? Or would using the HTTP::Client to send to Mandrill be smart enough to release the fiber while it's waiting for a response so that the second email could start sending?
<jhass>
the latter
<paulcsmith_>
Thanks for the responses BTW :) I've worked with Elixir and OTP so this is a bit of a different paradigm :)
<jhass>
since the HTTP request will very likely block on IO other fibers will get a chance to start theirs
<paulcsmith_>
That makes sense. Very cool! And is there a way to automatically a block if it fails? I'd guess not and I didn't see anything in the docs
<jhass>
the hardest part is to not exit your main fiber until all your emails are sent
<jhass>
though if that's in say the context of a HTTP server that should be no issue as the main fiber is blocked by its loop forever
<jhass>
not sure what you mean with "automatically a block if it fails"
<paulcsmith_>
Must be Friday :) I meant "automatically retry"
<jhass>
oh, no
<paulcsmith_>
Ah ok, not a biggy, but worth a shot :)
<jhass>
you'll have that to do that by hand by rescuing any exceptions
snsei has joined #crystal-lang
<jhass>
*have to
<paulcsmith_>
So when you say the hardest part is not to exit main fiber, that would apply to something where I had a simple program that looped through and spawned some fibers to send a bunch of emails and then the program "finished" before the fibers actually finished sending their emails? But with an HTTP server the server is always up so that's not an issue. Is that roughly what you mean?
<jhass>
yes
<paulcsmith_>
Awesome that makes a lot of sense. I really appreciate the help
<jhass>
usually you would solve this by sharing a channel with each fiber, keep track how many you spawn and receive that many times in the main fiber from the channel
<paulcsmith_>
That makes perfect sense. Very cool.
<jhass>
(and send to the channel at the end of each spawned fiber of course)
<paulcsmith_>
What happens if you have an HTTP server and one of the request fails? I would guess that the main fiber does not go down, but how does that work
<jhass>
HTTP::Server spawns a new fiber for each request already
<jhass>
so any exception inside the request already never bubbles up to the main fiber
<jhass>
but I recently also made it rescue (and print) all uncatched exceptions
<paulcsmith_>
Hmm, so if I created a new fiber for sending an email from within an HTTP request, is it tied to the "main" fiber or to the request fiber? I think I wouldn't want a failure in the request to take down the email fiber
<jhass>
neither
<jhass>
fibers aren't tied together in any way
<jhass>
process termination is just tied to the main fiber's termination
<paulcsmith_>
Oh I see. I thought fibers were linked to the main fiber, or maybe the fiber that spawned it. That makes sense though
<jhass>
basically crystals default main function runs calls exit(2) at its end
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/voean
<crystal-gh>
crystal/master 5c49190 Ary Borenszweig: JSON: fix incorrect raw string for object with string value
<jhass>
s/runs//
<paulcsmith_>
jhass Ok this makes a lot of sense. The pieces are coming together now :) Still not totally clear on when I would need to use a channel over just spawning a fiber, but I'll play around with those a bit more and see what I can figure out. Luckily the docs are pretty good. Especially for such a young language
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/voeaH
<crystal-gh>
crystal/master 86a90e1 Ary Borenszweig: Macros: allow iterating a TypeNode whose type is a tuple
<jhass>
paulcsmith_: yeah that takes some time to click, especially since there's more than problem category you can solve with them
<jhass>
*one
<jhass>
which simply is communication between fibers for one and some degree of control/scheduling for the other
<paulcsmith_>
Yeah that makes sense. Very cool. Excited to explore a bit more. What I'm really loving is the static type checking combined with type inference. The speed is also a nice plus :D
<crystal-gh>
[crystal] asterite opened pull request #2736: Add Union type (master...feature/union) https://git.io/voePV
snsei_ has joined #crystal-lang
snsei has quit [Ping timeout: 240 seconds]
dhk has joined #crystal-lang
paulcsmith_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dhk has quit [Ping timeout: 264 seconds]
<crystal-gh>
[crystal] MaloJaffre opened pull request #2737: completion: change `build` to `compile` (master...patch-2) https://git.io/voeyZ
<asterite>
BlaXpirit: first, the `{{@type}}` thing is indeed something to consider. Maybe we'd like a distinction between the type where the macro is defined, and the scope where it's invoked
<crystal-gh>
[crystal] jhass pushed 1 new commit to master: https://git.io/voey6
<crystal-gh>
crystal/master 51733de Malo Jaffré: completion: change `build` to `compile` (#2737)
<BlaXpirit>
asterite, the way it seems to work now is @type means call scope when macro is at the top level, and otherwise the macro's parent. that's what i don't like
snsei_ has quit [Remote host closed the connection]
<jhass>
yes, whatever it resolves to, it should do so consistently
<BlaXpirit>
asterite, I don't get it..?
<BlaXpirit>
i've seen that but what's the relevance?
<asterite>
and Joe Armstrong (creator of Erlang) seems to think the same way
<asterite>
Mmm... no relevance with the issue, but you always say good things about async/await, and there's a huge problem with it
<BlaXpirit>
oh sure
<BlaXpirit>
that's because it's kludged on top of old languages that just aren't suited for it
<asterite>
Mmm... but it splits all your functions in two worlds, always
<BlaXpirit>
hm if you think about it, it may be possible to turn any async-await function into a normal function if you really want
<BlaXpirit>
at the compiler level
<asterite>
Maybe, I don't know much about async/await so I can't tell. I don't know if in the blog post the author comes to the same conclusion
<BlaXpirit>
asterite, honestly I think the author is confused, especially at the conclusion. what Go did is equivalent to the most basic OS-level threading, in that it still has all the same problems. just arguably slightly faster. my answer is https://glyph.twistedmatrix.com/2014/02/unyielding.html
<asterite>
I read it, but no, Go lets you not worry about managing callback and using `async` and `await` where you need it. Go frees your mind from that part. Then you use channels to communicate data and problem solved, no data races.
<asterite>
You do have mutexes if channels are too much for simple things
<BlaXpirit>
asterite, well then that's the thing. the only innovative thing Go did is popularize "channels". all of this has always been possible, just that it's very limiting. and sure enough, limiting the usage limits the possible errors
<BlaXpirit>
channel = thread-safe queue, goroutines = thread pool with userspace scheduling
<asterite>
jhass: was DeBot the project you had trouble with? I'll try to fix make it work with 0.17.0, where should I start?
<jhass>
asterite: yes
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/voeHU
<asterite>
I don't know, doesn't work today... maybe a bug in osx
<jhass>
let me see
<asterite>
not sure I did the correct thing with Config, I define it with some defaults for all plugins, then some can override that... it does JSON.mapping twice, but seems to work (all have a channels property)
mlitwiniuk has quit [Ping timeout: 244 seconds]
<jhass>
I'll see
<jhass>
using a second generic for PluginContainer somehow never occurred to me, so that's promising