<FromGitter>
<bew> Jenz: you can read the stdlib source code, and read about how fibers work for example, or in the compiler about what is generated for a struct/class/etc...
<FromGitter>
<bew> About LibNode: I noticed that too, and opened an issue about it. Also, I did an implementation for such a node (not really finished..). I should probably send a pr about it some day
lvmbdv has quit [Quit: Leaving.]
alex`` has quit [Ping timeout: 248 seconds]
bthesorceror has joined #crystal-lang
bthesorceror has quit [Quit: leaving]
jeet has quit [Ping timeout: 268 seconds]
jeet has joined #crystal-lang
<FromGitter>
<rishavs> @sam0x17 👏
akaiiro has quit [Remote host closed the connection]
alex`` has joined #crystal-lang
braidn[m] has quit [Ping timeout: 256 seconds]
byteflame has quit [Ping timeout: 245 seconds]
kp666[m] has quit [Ping timeout: 240 seconds]
cptaffe has quit [Ping timeout: 260 seconds]
kixune[m] has quit [Ping timeout: 255 seconds]
Renich has quit [Ping timeout: 256 seconds]
olbat[m] has quit [Ping timeout: 276 seconds]
fifr[m] has quit [Ping timeout: 276 seconds]
Totoro has quit [Ping timeout: 240 seconds]
Totoro has joined #crystal-lang
snsei_ has joined #crystal-lang
Yxhuvud has quit [Read error: Connection reset by peer]
Yxhuvud has joined #crystal-lang
olbat[m] has joined #crystal-lang
jeet has quit [Ping timeout: 256 seconds]
jeet has joined #crystal-lang
DTZUZO has quit [Ping timeout: 248 seconds]
fifr[m] has joined #crystal-lang
kp666[m] has joined #crystal-lang
Renich has joined #crystal-lang
braidn[m] has joined #crystal-lang
byteflame has joined #crystal-lang
cptaffe has joined #crystal-lang
kixune[m] has joined #crystal-lang
<crystal-gh>
[crystal] ysbaddaden closed pull request #6295: Fix: rebind while condition variables after while body (master...bug/6158-while-rebind-cond-var-after-body) https://git.io/f4NSD
<FromGitter>
<mjago> Would explicitly typing the entire compiler be an instant improvement on every compilation?
<lvmbdv>
i am not that versed in the crystal compiler but i would assume it would cut back some of the type inferrence overhead in compile time, yeah
<FromGitter>
<mjago> Thats what I figured
<FromGitter>
<j8r> not everything can be explicitly typed, some methods plays with the type inference
<RX14>
@mjago no
<RX14>
it wouldnt help at all
<RX14>
you *can't* type anything in crystal except for instance vars and calass vars
<RX14>
you can only have type restrictions
<RX14>
they don't help the compiler at all, they're just there at the end of compilation to check what the compiler already inferred
<RX14>
it's purely for the humans
<RX14>
to assert the type that the compiler inferred
<RX14>
and to document the code
<FromGitter>
<mjago> RX14: 👍
<RX14>
of course the exception being ivars and cvars which are already forced to be explicitly typed
<RX14>
changing it so that type restrictions *do* help is something we need to look into
<RX14>
and it's something I feel we have to look into before 1.0
<FromGitter>
<mjago> I'm playing with parts of the compiler and noticed how much is inferred
<FromGitter>
<vlazar> Anyone on OSX noticed slowdown with db access in 0.25? I tried to benchmark the same code with 0.24.2 and 0.25.0/0.25.1 and 0.25.0 is suspiciously too slow. I'm using crystal-mysql, basically requesting a lot of rows from DB and pushing the results into array.
<FromGitter>
<mjago> @vlazar Is it just the db connection? I thought on Linux crystal-sqlite seemed to be a bit slower connecting to the db?
<FromGitter>
<vlazar> I'm reducing the example to share benchmark.
jeet has quit [Ping timeout: 276 seconds]
jeet has joined #crystal-lang
DTZUZO has joined #crystal-lang
<crystal-gh>
[crystal] asterite opened pull request #6300: Fix formatting of `{ {1}.foo, ...}` (master...bug/6299-formatter-space-after-tuple) https://git.io/fuvCw
<FromGitter>
<asterite> @mjago no, it would make no difference at all
<FromGitter>
<MrSorcus> > *<Groogy>* tere's probably a very pretty way to do it but here to show you the idea: https://play.crystal-lang.org/#/r/4fkl ⏎ ⏎ Cool. Thank you 😄
<Groogy>
np
<FromGitter>
<codenoid> i can't install crystal on openbsd
snsei_ has quit []
<FromGitter>
<vlazar> OK, here is reduced example with benchmark showing the same code using crystal-mysql is somehow got ~16x times slower on OSX when compiled with Crystal 0.25.0 or 0.25.1 versus Crystal 0.24.2 https://github.com/vlazar/crystal-mysql-benchmark Can someone with OSX check is it's not my local env issue?
<FromGitter>
<vlazar> Oh and BTW it doesn't matter is I use crystal-mysql 0.4.0 or 0.5.0 with Crystal 0.25
<oprypin>
vlazar, welp all that's left to do is to bisect it
<oprypin>
go to crystal directory, make your program output one number (duration in µs), `git bisect start && git bisect good 0.24.2 && git bisect bad 0.25.0 && git bisect run bash -c 'make clean; make || exit 125; bin/crystal build --release test.cr || exit 125; (( $(./test) < 4000 ))'`
<FromGitter>
<vlazar> @oprypin Lol... I guess I could try. Would this melt down my laptop?
<oprypin>
laptop? probably
<oprypin>
vlazar, maybe i can try instead
<FromGitter>
<vlazar> @mjago those are huge numbers! :D seriously though I've tried with sqlite and numbers are the same for Crystal 0.24.2 and 0.25.0/0.25.1 ⏎ ⏎ ```$ ./benchmark_sqlite ⏎ select id from numbers 4.25k (235.16µs) (± 1.78%) fastest``` [https://gitter.im/crystal-lang/crystal?at=5b37b1303d8f71623d519a76]
<FromGitter>
<vlazar> So the issue is definitely with crystal-mysql
<FromGitter>
<vlazar> @oprypin Are you on OSX or Linux? I haven't tried crystal-mysql on Linux, mayme the issue is not specific to OSX
<oprypin>
im on linux
<FromGitter>
<vlazar> can you please just try to run benchmark?
<oprypin>
k
<oprypin>
Crystal 0.25.0 (2018-06-12) select id from numbers 264.78 ( 3.78ms) (± 3.03%) 249280 B/op fastest
<oprypin>
select id from numbers 2.48k (403.46µs) (± 2.68%) fastest
<oprypin>
Crystal 0.24.2 (2018-03-19)
<oprypin>
uh sorry for messy format
<FromGitter>
<vlazar> np
<oprypin>
vlazar, so any idea about how i can turn the output into machine readable?
<FromGitter>
<vlazar> from Benchmark.ips?
<FromGitter>
<vlazar> no idea, need to read API
<oprypin>
yeah
<FromGitter>
<vlazar> you just need 1 number?
<oprypin>
yeah
<oprypin>
result = Benchmark.ips ... ; result.items[0].mean
<crystal-gh>
[crystal] asterite opened pull request #6301: Remove File.each_line method that returns an iterator (master...refactor/6087-remove-file-each-line) https://git.io/fzaOr
<FromGitter>
<vlazar> @RX14 why it's not an issue with crystal-sqlite3?
<oprypin>
bash is insane tho, i wish there was a sane flexible glue language
<RX14>
because sqlite doesnt use sockets
<RX14>
we regressed performance for all sockets apart from HTTP
<FromGitter>
<vlazar> I've been playing with some ideas for improving TFB when noticed this... it's good PR with 0.25 is not merged yet :) I'll wait for 0.26 and Kemal 0.24 then :)
<Groogy>
wat 0.26 already?
<oprypin>
there was no indication of that
<crystal-gh>
[crystal] asterite opened pull request #6302: Fix compiler bug when casting to uninstantiated generic type (master...bug/5927-cast-to-array) https://git.io/fzSHW
<FromGitter>
<sdogruyol> nope
wontruefree has joined #crystal-lang
<Groogy>
oh it was a joke
<Groogy>
now I get it
<FromGitter>
<asterite> Why read buffering causes this behaviour? I can't see the relationship between that and the incorrect behaviour of urandom.
<FromGitter>
<asterite> We really need a general benchmark suit for the standard library so this kind of performance regressions can be avoided...
<oprypin>
asterite, well you're not allowed to buffer cryptographically random data, for security reasons
<FromGitter>
<vlazar> I was thinking just about that + maybe for most popular shards like Kemal, Amber, etc.
<Yxhuvud>
@rx14: will the urandom behave correctly if that line is removed or will that need separate changes?
<RX14>
yes it'll behave correctly
<Yxhuvud>
hmm, the issue is with calling fork, as the buffers isn't cleared, right?
<oprypin>
that's one of the less obvious issues down the line
<oprypin>
why are there both circle and travis testing linux?
<FromGitter>
<vlazar> @RX14 removing this one line doesn't seem to work, `make std_spec` stuck
DTZUZO has quit [Ping timeout: 240 seconds]
<FromGitter>
<asterite> Socket sync is true by default in Ruby, which makes sense (no need to call flush). The solution should really be to have a way to turn read buffering off, independently of write buffering. So maybe even splitting split into write_buffering and read_buffering properties
lvmbdv has quit [Quit: Leaving.]
<FromGitter>
<asterite> Or maybe socket should buffer by default, and it should be documented that you need to flush... And then reading should flush if there's anything in the buffer. I don't know.
<RX14>
no
<RX14>
sockets should have write buffering
<RX14>
and people should call flush
<oprypin>
thats a bit radical
<Yxhuvud>
is it configurable?
rohitpaulk has joined #crystal-lang
benharri has quit [Quit: not here right now...]
<oprypin>
socket write should not be buffered by default. separate configurability is good.
benharri has joined #crystal-lang
<oprypin>
currently, as i understand, read and write buffering are tied
<RX14>
how is that radical oprypin ?
<oprypin>
i'm not aware of any other implementation that has it off by default
<oprypin>
i mean on - buffering by default
<oprypin>
and, like, it can be extremely misleading. imagine all those questions
<oprypin>
i sent something to socket but the other side is not receiving! oh noes!
<RX14>
they'll learn
<oprypin>
pls no
<RX14>
nah it should just flush when you read
<RX14>
that makes sense
<oprypin>
no it doesnt
<oprypin>
not everyone knows that protocols should have an ack
<oprypin>
u send something and thats it, why would you read
<RX14>
they'll learn
<RX14>
well they'll learn every 8k anyway
<oprypin>
nobody will agree with you anyway so nothing to worry
<RX14>
unfortunately
<FromGitter>
<asterite> This is simple
<FromGitter>
<asterite> It was working well
<FromGitter>
<asterite> There was a tiny problem with urandom
<FromGitter>
<asterite> That should have been fixed instead, not drastically change the behavior of all IOs
rohitpaulk has quit [Quit: Ping timeout (120 seconds)]
<RX14>
well read buffering is purely perf not behaviour
<FromGitter>
<asterite> So in this case, the old behavior should have been preserved, and a way to disable buffer reading for urandom should have been put
<RX14>
so it's not the end of the world
greengriminal has quit [Quit: This computer has gone to sleep]
<RX14>
we'll just make it configurable per read/write buffering
<FromGitter>
<asterite> Yes, that seems like a good idea. And just disable it for urandom and we are done
<RX14>
yes
<FromGitter>
<asterite> Maybe even keep sync, preserving the old behavior. Then add read_buffering, use that for urandom and release a bugfix release. Then for 0.26.0 rename sync to write buffering (or just keep it like that)
<crystal-gh>
[crystal] asterite opened pull request #6304: Let IO#sync only affect writes, introduce `IO#read_buffering?` and use it in urandom (master...bug/6303-io-sync-buffered-read) https://git.io/f2L4X
<FromGitter>
<funny-falcon> I have another concern about writting: ⏎ Golang has nice property of os.File and net.Conn that `Write(buffer)` writes whole buffer without interleaving with other writers (they uses mutex for writers serialization). Though it is a bit inconsistent with their own writes to buffered wrappers, and other Writers, it is quite useful sometimes. ⏎ Crystal at the moment will allow writers to interleave due to
<FromGitter>
... the way `write_syscall_helper` is made. ⏎ Certainly, it is useful only for asynchronous protocol implementations, and only for novices. But I've had one fellow who doesn't regard unavoidable complexity. [https://gitter.im/crystal-lang/crystal?at=5b37e40233b0282df4f55c1b]
rohitpaulk has quit [Ping timeout: 256 seconds]
<RX14>
the issue there of course is performance
<RX14>
given the rarity of IO operations, and how often in crystal that write ops *aren't* atomic, is it worth it for the general case?
<RX14>
I'd rather have a wrapper IO which wraps an IO and syncs the read/write calls
<Yxhuvud>
@funny-falcon: I suppose the easiest way to get an atomic writer would be to push for #6078 . writev being atomic is a big part of why it exists.
<Yxhuvud>
(or well, why writev exists, the reasons behind that request seems different)
rocx has joined #crystal-lang
<crystal-gh>
[crystal] Sija opened pull request #6305: Add repology badge to README.md [ci skip] (master...add-repology-badge-to-readme) https://git.io/faCMf
<rocx>
a class can only have a single superclass, right?
<crystal-gh>
[crystal] asterite closed pull request #6302: Fix compiler bug when casting to uninstantiated generic type (master...bug/5927-cast-to-array) https://git.io/fzSHW
<oprypin>
yes
<rocx>
then how would one do the equivalent of java's interfaces or rust's traits?
<rocx>
i know there are abstract types but then there's only single inheritance. would it just involve a redoing of my code architecture to make it work?
akaiiro has joined #crystal-lang
<RX14>
rocx, abstract methods in modules
wontruefree has joined #crystal-lang
<RX14>
modules are like mixins
<RX14>
if they happen to have only bastract methods in, they're like java's interfaces
<RX14>
(ish)
<rocx>
ah. think i'm seeing it... probably.
wontruef_ has joined #crystal-lang
<rocx>
say, if i'm designing a game and there are mulitple things that can hold an inventory (chests, players, rooms), then i could just `include Container` in those classes and then chests, et al are considered Container+?
<RX14>
well yeah
<RX14>
you can restrict on container
<RX14>
and have container-typed ivars
wontruefree has quit [Ping timeout: 245 seconds]
akaiiro has quit [Ping timeout: 256 seconds]
<rocx>
ivars?
wontruef_ has quit [Quit: bye]
<RX14>
instance variables
akaiiro has joined #crystal-lang
akaiiro has quit [Ping timeout: 245 seconds]
* rocx
unfortunately is in a java education so "ivar" is a new one.
<RX14>
rocx, ivar is basically just a java property
<RX14>
but you can't have public properties in crystal
<RX14>
you have to use getter/setter methods
<RX14>
it's just their syntax is the same of properties
<rocx>
like a static variable basically.
<RX14>
no
<RX14>
just a private property
<rocx>
no wait instance. static are class variables.
<RX14>
yes
<FromGitter>
<tatey> Hello. Would someone be able to help me understand nested before_each and after_each setup blocks in Spec? https://gist.github.com/tatey/18beb68b8c0e000d93c14f88cd37e9f8. I'm expecting that if I nest context/describes and call before_each that it will only be called for specs in that context.
<RX14>
no, that doesn't work
<RX14>
before_each and after_each don't have very many usecases
<FromGitter>
<tatey> Yeah. I noticed it was on `Spec` which made me think it probably doesn't work like that, but just wanted to validate my thinking.
<RX14>
you're expected to compose helper methods inside the spec
<FromGitter>
<tatey> Right, OK.
<RX14>
for example with_tempfile
<RX14>
or with_db do |db|
<RX14>
and the helper might roll back your transaction
<FromGitter>
<tatey> My use case is calling Kemal.setup. I kind of only want it to happen when I am actually testing Kemal endpoints.
<RX14>
stuff like that
<RX14>
not too familiar with kemal, sorry
<FromGitter>
<tatey> Yeah, OK. That's put me in the right direction. I've seen some other code bases do stuff like that.
<FromGitter>
<tatey> That's fine. You've helped heaps. Thank you :-)