<crystal-gh>
[crystal] ysbaddaden opened pull request #4236: Configurable DNS resolvers (master...std-addrinfos-dns-resolvers) https://git.io/vSRp8
bjz_ has joined #crystal-lang
bjz has quit [Ping timeout: 260 seconds]
fryguy9 has quit [Quit: Leaving.]
fryguy9 has joined #crystal-lang
bjz has joined #crystal-lang
bjz_ has quit [Ping timeout: 240 seconds]
Qchmqs has quit [Ping timeout: 240 seconds]
Qchmqs has joined #crystal-lang
fryguy9 has quit [Quit: Leaving.]
fryguy9 has joined #crystal-lang
sz0 has joined #crystal-lang
Qchmqs has quit [Ping timeout: 260 seconds]
Qchmqs has joined #crystal-lang
olek_poz has quit [Ping timeout: 260 seconds]
fryguy9 has quit [Quit: Leaving.]
fryguy9 has joined #crystal-lang
fryguy9 has quit [Quit: Leaving.]
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
snsei has joined #crystal-lang
mark_66 has quit [Remote host closed the connection]
snsei has quit [Ping timeout: 260 seconds]
<FromGitter>
<raydf> Thanks @crisward, i solved the problem with the case statement, in reality the code i uploaded is valid but the compiler was giving me another error related to will-pg PG::Numeric type when converting to JSON::Any.
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
fryguy9 has quit [Quit: Leaving.]
fryguy9 has joined #crystal-lang
olek_poz has joined #crystal-lang
snsei has quit [Ping timeout: 264 seconds]
<jokke>
hi
<jokke>
does HTTP::Server allow persistent connections?
<jokke>
i just checked tcpdump on the port my test server was listening on and even though my client (a ruby app) uses HTTPClient which reuses connections i saw packets from a lot of different ports
<jokke>
this wasn't the case when i used a ruby rack server
<RX14>
pretty much the entire scope of expansion on the framework is in the utilities it provides
<jokke>
RX14: i don't quite understand why tcpdump shows so many different ports when running against the crystal server
<jokke>
i checked, that keep-alive is set
<RX14>
well, is keep-alive working?
<jokke>
well, apparently not
<RX14>
add a puts to the client's TCP connect() call
<jokke>
but it is with webrick for example
<jokke>
the client is ruby
<jokke>
HTTPClient
<RX14>
...so I assume it's in C
<RX14>
great
<RX14>
that's something I want to achieve with crane, being able to jump into the stdlib and compiler almost seamlessly with an editor and change and debug stuff
<jokke>
mmh
<RX14>
fluidity of debugging and modifications across projects is something i'd love with shards/crane
<jokke>
but i kind of doubt that it's a client problem since it worked with a webrick/thin
<RX14>
yeah...
<jokke>
also if i spawn 10k clients and hammer the server the server tells me too many open files
<jokke>
hm
<RX14>
i think I know why...
<jokke>
but that might be alright
<jokke>
10k open files might be too much
<jokke>
oh no
<jokke>
it should be one socket
<jokke>
since HTTPClient _should_ do connection pooling
<RX14>
yeah I know why it's failing
<jokke>
you do?
<RX14>
yeah
<jokke>
weeeell?
Yxhuvud has quit [Read error: Connection reset by peer]
<jokke>
please enlighten me :)
<RX14>
i have no idea why the specs don't fail though
<jokke>
oh really a crystal problem?
<RX14>
obviously lol
<jokke>
i always assume i'm doing something wrong first ;)
<FromGitter>
<chuckremes> Nevermind… found it in the source. It looks like `spawn` calls `Fiber.new` internally and also enqueues the newly generated fiber onto the scheduler queue.
<RX14>
yup
<RX14>
don't use Fiber yourself
<RX14>
it's got loads of gotchas and is an internal class
<FromGitter>
<chuckremes> But I should be able to use `Fiber.yield` and `Fiber.resume`, yes?
<FromGitter>
<chuckremes> I ask because I want to spike out a proof-of-concept `celluloid`-style library for crystal as a learning exercise.
<FromGitter>
<chuckremes> I just want to make simple `Futures`.
<RX14>
crystal already has futures
<RX14>
they're just not well advertised and actually will probably be redone
<FromGitter>
<chuckremes> Okay, I’m not privy to the secret classes. I’m looking at the online docs and the gitbook. Neither mentions futures or anything similar.
<FromGitter>
<chuckremes> presumably the “toplevel” names are the equivalent of Ruby’s `Kernel` namespace?
<RX14>
i would guess so?
<RX14>
i havent used ruby for...
<RX14>
years
<FromGitter>
<chuckremes> Well, I’m very new to crystal… just a few days. I like what I see so far.
<RX14>
a celuloid-style lib would be interesting to see
<RX14>
i'm not quite sure what celluloid brings to crystal
<FromGitter>
<chuckremes> I need to experiment to see if there is enough metaprogramming capability to pull it off.
<RX14>
i'd hazard a guess and say yes
<RX14>
and i'd be 90% sure there is
<RX14>
DCell would be the most interesting one to replicate
<FromGitter>
<chuckremes> I have no intention of porting all of celluloid. However, I do think it’s useful to have objects that proxy access to an actor or future. Celluloid brings nice syntax to it.
<RX14>
Celluloid::IO is obviated by evented IO in the stdlib
<FromGitter>
<chuckremes> Ah yes, well this would be an early experiment to verify that working on DCell or ECell is worthwhile.
<RX14>
yeah there have been talks of actor frameworks before
<RX14>
and we've generally agreed that it'd be nice for someone to take a stab at it
<RX14>
but nobody had the time atr the time
<FromGitter>
<chuckremes> haha, I bet.
<FromGitter>
<chuckremes> while exposing fibers and schedulers is nice for the implementer, most programmers don’t want to have to juggle fibers, channels, and all of the other primitives. A slightly higher-level lib is useful in that regard.
<FromGitter>
<chuckremes> gonna work on this today
<RX14>
well, fibers and channels really aren't all that primitive
<RX14>
they're surprisingly easy to use in most situations
fryguy9 has quit [Quit: Leaving.]
<FromGitter>
<chuckremes> sure, but they are an implementation detail. They should be tucked away where they can’t be seen (for most code).
<FromGitter>
<chuckremes> that’s IMO, of course.
<RX14>
...no
<RX14>
not at all
<FromGitter>
<sdogruyol> They are simple enough
<FromGitter>
<sdogruyol> Just like go
<RX14>
they're high-level constructs that people use all the time to build applications
<RX14>
you can go higher level but fibers and channels are really not hard or need a lot of boilerplate to use
<RX14>
actors and futures would complement them
<FromGitter>
<chuckremes> All right… don’t want to argue. IMO, I prefer to not use fibers & channels directly. I want my objects to run things asynchronously for me and return the results when I ask for it. I like straight up, no frills imperative programming. But I’m old fashioned.
<RX14>
buffered fibers are essentially queues...
<RX14>
the future wrapper makes code smaller in a few usecases
<RX14>
but I find mysel almost never using them actually
<RX14>
you might not want to argue but it's a fact that the concurrency boilerplate for using raw channels and fibers is almost non-existant in most cases
<FromGitter>
<chuckremes> Sure, but I don’t want to see it AT ALL.
<RX14>
but you have to replace it with something
<RX14>
and if that something is essentially the same or offers little to no improvement why use it?
<RX14>
thats what i'm saying
<RX14>
you can have a go but "I don't want to see it" is just closing your mind
<RX14>
finding a better solution starts with understanding the current one
<RX14>
and it seems to be that you don't
<FromGitter>
<chuckremes> I don’t understand you. Why so argumentative?
<FromGitter>
<chuckremes> And no need to be insulting either.
<RX14>
because I want to help you, and dismissing fibers and channels as "primitives to be hidden away" in't a good starting point
<FromGitter>
<chuckremes> I haven’t dismissed anything.
<FromGitter>
<chuckremes> I, meaning ME, don’t want to see the concurrency “gears” at work. I want a library to do it for me.
<RX14>
i didn't mean to sound insulting, sorry
<FromGitter>
<chuckremes> And I’ll write that library (or try to spike one)
<FromGitter>
<chuckremes> Ok
<FromGitter>
<chuckremes> Listen, I’m not trying to impose my view of the world on crystal.
<RX14>
but what i'm trying to say is that they're not gears
<FromGitter>
<chuckremes> I want to learn about it and spike a project or two to get to know it better.
<RX14>
and that just like go, most programs will use fibers and channels directly instead of delegating to a library
<FromGitter>
<chuckremes> I fwhat I create is useful, then great. If not, it will sink like a million other hobby projects.
<FromGitter>
<chuckremes> That’s cool. It isn’t a style that I like. Doesn’t make it wrong or right… it just is how I like it.
<FromGitter>
<chuckremes> Ok, we’ve taken enough time on this topic. I’ll be back with questions later.
<FromGitter>
<chuckremes> Thanks for your pointers so far. Very helpful.
<RX14>
no problem
<RX14>
creating a library is a good way to learn about fibers and channels
fryguy9 has joined #crystal-lang
<jokke>
RX14: sorry, had to run. Sure it's the commit?
<RX14>
jokke, i'm not sure at all
<jokke>
hm
<jokke>
i can try finding out
<RX14>
bisect from 0.17.0
<jokke>
yeah
<jokke>
but building takes ages :P
<RX14>
you don't been to build
<RX14>
it's a stdlib change
<RX14>
well you need to build
<RX14>
actually you do need to build the compiler
<RX14>
damn
<jokke>
yay
<RX14>
but not for every revision
<jokke>
i'll try checking out the parent commit
<RX14>
and actually not if you use crenv
<RX14>
because you just need to do this
<RX14>
checkout commit, find latest tag, install that crystal version, compile test executable, run tests
<RX14>
if you can automate that in a bash script you can bisect super fast
<jokke>
mhm worth a try
<RX14>
plus, compiling the compiler takes 37s
<jokke>
yah
<RX14>
but as you narrown down into the exact crystal version the regression happened in
<RX14>
you don't need to recompile
<RX14>
because it's only a stdlib change
fryguy9 has quit [Quit: Leaving.]
<BlaXpirit>
also time should not be a worry because you can just leave it running?
<RX14>
i can't find a good way to repeat strings in bash
<RX14>
shame
<jokke>
xargs?
<RX14>
would xargs help?
<jokke>
well depending on what you want to do
<jokke>
abyways
<FromGitter>
<drosehn> repeat strings in what sense?
<jokke>
*anyways
<jokke>
it's definately crystal
<jokke>
different port every time
<RX14>
don't check the port
<jokke>
why?
<RX14>
curl -v will tell you whether it reconencted or not
<jokke>
oh
<jokke>
ok
<RX14>
* Connection #0 to host google.com left intact
<RX14>
* Found bundle for host google.com: 0x137f730 [can pipeline]
<RX14>
* Connected to google.com (216.58.204.46) port 443 (#0)
<RX14>
* Re-using existing connection! (#0) with host google.com
<jokke>
* Re-using existing connection! (#0) with host localhost
<jokke>
ok
<RX14>
huh...
<jokke>
so not an issue there
<RX14>
thats weird
<jokke>
weird that tcpdump shows different ports each time
<RX14>
yeah...
<RX14>
that doesn't make sense
<jokke>
yeah
<jokke>
maybe some kernel-internal multiplexing shizzle
<RX14>
i don't think so...
<RX14>
well in tcpdump you should be able to see whether a new TCP connection was made
<RX14>
it should show TCP handshakes
<jokke>
waaah never mind
<FromGitter>
<drosehn> repeating strings in bash: `STR=. CNT=0 ; while test $CNT -lt 10 ; do printf "%s" "$STR"; CNT=$((CNT+1)) ; done ; printf "\n"`
<jokke>
the line broke and i misread
<jokke>
it's the same source port
<jokke>
so it's ruby
<jokke>
not crystal
<jokke>
and not curl :)
<RX14>
jokke, but...
<jokke>
hm?
<RX14>
ruby works with a ruby server right
<RX14>
or what?
<jokke>
yeah that's the weird part
<jokke>
lol ok
<RX14>
so something is still broken
<jokke>
ah jeez fucking linebreaks
gloscombe has quit [Remote host closed the connection]
* jhass
steals all of jokke's linebreaks
<jhass>
there, tell me if it's better now
<jokke>
i should mention that i'm using HTTPClient in combination with Celluloid
<jokke>
which is a scary combo
<jhass>
ah good old messy celluloid
<jokke>
but i need to find out if the combo is in fact able to reuse connections
<jhass>
what if the answer is no?
<jokke>
jhass: then we have to drop ruby
<jhass>
are you searching for something that is able to do a lot of requests?
<jokke>
and use something shitty like node
<jhass>
typhoeus surely does reuse connections
<jokke>
jhass: background: we have a tcp server that's maintaining a few thousand seperate tcp connections, receives some data from them and forwards them to a rest api. It would be very bad if we would have to spawn a new socket for each http request to the api since it's https
<jokke>
celluloid would be nice since we could spawn one actor per tcp connection
fryguy9 has joined #crystal-lang
<jhass>
mh, so you want to reuse + multiple connections to the same origin nonetheless I guess
<jokke>
but all actors should reuse the same http(s) connection to the rest api
<FromGitter>
<domgetter> Is monkeypatching as "frowned upon" here as it is in Rubyland?
<jhass>
same levels I'd say, you should have a strong reason but if you can provide it it's totally fine
<FromGitter>
<domgetter> jhass: thanks, Ill pull these out into library calls then
fryguy9 has quit [Client Quit]
<jhass>
I like to stub out missing stdlib features while working a project and then working on upstreaming them once I know they're what I need
<FromGitter>
<zatherz> is there any project that I could look at?
<Papierkorb>
zatherz, maybe Cinch, a irc bot lib in ruby
<RX14>
don't use cinch as a base please
<RX14>
i think it's pretty terrible API
<RX14>
but for a list of features it's nice
<RX14>
because it's bloated lol
<FromGitter>
<drosehn> Hmm. What's the way to have `crystal` reformat a source file?
<FromGitter>
<zatherz> `crystal tool format file`
<FromGitter>
<drosehn> Ah, under `tool`. of course.
<FromGitter>
<zatherz> I like the sublime 3 crystal plugin because it does that automatically on save
<FromGitter>
<ltran> omg so cool =D
<FromGitter>
<ltran> was wondering if there was something similar to Go’s fmt :D
<FromGitter>
<zatherz> but yeah, I don't know how to keep it type safe but at the same time have a nice API for plugins that depend on other plugins' functionality
<jhass>
I guess you could have some macro voodo that spits out a named tuple in the form of {plugin_name: PluginType, ...}
<Papierkorb>
zatherz, hard to tell without more input. However, the gist is to have a module which defines the interface for the host program to the plugin. Like `received_message(sender, message)`. If you need dependencies, I'd have the providing plugin offer an interface (module, abstract class, ...) for other plugins. Then you have a PluginManager class, which can be asked to give all plugins implementing that interface. The plugin then gets a list
<Papierkorb>
(or just the first match), and has a type safe way of communicating with the other plugin
<Papierkorb>
zatherz, as shameless self promotion, you can also use the `cute` shard for program-local notifications, like receiving a message
<FromGitter>
<zatherz> the dependency part is the only thing that gives me problems
<FromGitter>
<zatherz> commands in my bot are implemented by a plugin
<Papierkorb>
zatherz, more specific to chat bots, it's great to have a Message class which has a #reply method. a plugin can then simply do `message.reply "Okay!"`
<FromGitter>
<zatherz> all plugins that want to use commands have to `include CorePlugin::CommandPlugin`, the thing is I want to separate some commands (like the plugin list or an `eval`) into a CoreCommandsPlugin
<FromGitter>
<zatherz> `eval` specifically needs to use the parsing functionality of the core plugin
<FromGitter>
<zatherz> maybe I should separate that part of the plugin
<FromGitter>
<zatherz> into a CommandExecutor class or something like that
<FromGitter>
<zatherz> then both CorePlugin and CoreCommandsPlugin would have an instance of that
<FromGitter>
<zatherz> removing the need to refer to the loaded core plugin
<FromGitter>
<jwoertink> I'm trying to create a simple matrix, but I keep getting Index out of bounds
<FromGitter>
<zatherz> I thought you wanted a general purpose mutable matrix that automatically grows lol
ga2mer has joined #crystal-lang
ga2mer has quit [Client Quit]
<FromGitter>
<drosehn> Okay, I need a sanity check before I post an issue: if `low_value` and `high_value` start out as `nil`, then the loop construct of `until low_value && high_value` should have the exact same behavior as `while low_value.nil? || high_value.nil?`. True?
<FromGitter>
<zatherz> well, the second is multitudes more readable
<FromGitter>
<zatherz> but it doesn't matter in terms of the issue
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<FromGitter>
<drosehn> This is cut down from a larger program. The larger program had one of those `printf`s. I changed it, and then duplicated the line to show the difference between the start and the end of the loop.
<FromGitter>
<drosehn> Er, the larger program had one `printf` in the loop, although the `printf` was printing something else for unrelated reasons. It didn't have *this* `printf`!
<FromGitter>
<drosehn> huh. I didn't think to try that!
<FromGitter>
<zatherz> the less expanded form `while !(low_value && high_value)`
<FromGitter>
<zatherz> can also be used to reproduce this
Virviil has quit [Remote host closed the connection]
<FromGitter>
<zatherz> so, basically, `while !(low_value && high_value)` produces a different result than `while !low_value || !high_value`
<FromGitter>
<zatherz> you can reproduce this issue here without an infinite loop - the `a` at the end of the first loop is 2, but at the beginning of the first loop is nil
<FromGitter>
<drosehn> Yeah, I just tried your code in a playground, and realized it was an infinite loop. :smile: