<jhass>
xdougx: I have no experience in that regard. I'd assume most time is spent in the database queries?
kostya has joined #crystal-lang
<xdougx>
jhass: i think so, is between 0.006 and 0.06 the required time to process select, insert and update
pawnbox has quit [Ping timeout: 256 seconds]
<xdougx>
jhass: started a process 25 minutos ago already processed 82000 rows
<xdougx>
jhass: i think is going to last 1 hour
dylanmei has quit [Quit: ZZZzzz…]
<jhass>
if you have some memory to spend, usually minimizing the amount of roundtrips can do wonders
<jhass>
like do a single select to read everything, do a single insert (you can insert multiple rows with a single one), maybe even aggregate the update's where possible
alanwillms has joined #crystal-lang
pawnbox_ has quit [Ping timeout: 260 seconds]
pawnbox has joined #crystal-lang
nakilon has joined #crystal-lang
nakilon has quit [Ping timeout: 246 seconds]
Renich has joined #crystal-lang
<xdougx>
jhass: wish i could do it, but is needed to run each row time, maybe run from the start to middle and middle+1 to end
<jhass>
concurrent reads over multiple connections can help to speed things up, concurrent writes to the same table not so much
<jhass>
not sure how much locking is done on conflict free updates these days
<xdougx>
jhass: i see, it could be a probleman
kgadek has quit [Quit: gone sleep]
matp has quit [Remote host closed the connection]
<xdougx>
type is a reserved word?
zz_Cidan is now known as Cidan
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #crystal-lang
<jhass>
xdougx: yup, type is similar to alias
<jhass>
except that you can't cast between the two or whatever the difference was
<xdougx>
jhass: but if i use @type = 'my type', will it be a probleman?
<jhass>
best bet for finding things is github search with language:crystal, http://crystalshards.herokuapp.com/ is basically a frontend for that
pawnbox has quit [Remote host closed the connection]
<McDougal>
jhass: thanks, when do you feel this will be version 1.0?
<jhass>
I don't know
<jhass>
maybe somewhere in 2017
<jhass>
that doesn't mean it's not usable beforehand
<McDougal>
I'm doing rails mostly but looking at go and elixir at the moment which brought me to crystal. I tried crystal and had a pretty smooth experience
<McDougal>
I think a microwebframework is probably usable today
elia has joined #crystal-lang
zz_Cidan is now known as Cidan
<jhass>
the edges are not polished yet, but yeah, artanis is fairly usable
<asterite>
jhass: I don't understand, what concurrency issues?
<jhass>
I mean the threaded scheduler and all the thread safety issues that will arise from it
<asterite>
But that can be done in the standard library without breaking existing code
<jhass>
this is about prioritizing effort
<asterite>
And you can already do it in single thread mode. Node.js works like that and it's pretty popular and fast
<asterite>
Well, if we focus now on the concurrency and later change the language, all code breaks
<asterite>
If we change it now, less code will break
<jhass>
asterite: I'd suggest you start reading logs here again. People ask for it once or twice a week minimum
<asterite>
So I can't imagine why you would prefer to break code later than sooner
<jhass>
it would be a _giant_ selling point
<asterite>
That's the point: we don't sell the language
<sdogruyol>
jhass +1
<asterite>
We don't want to do something quick and dirty so that everyone will start using the language only to find out it's broken
<jhass>
well, I also hope that these issues might eventually be solved with less explicitness if given a bit more time
<jhass>
solving them now swiftly through explicitness will reduce 30% of the appeal of the language
<jhass>
I still hope for procs to become less explicit but all recent changes favor explicitness
<asterite>
Well, if somebody finds an algorithm that will scale that way, we are open for suggestions
<jhass>
which will be even harder to integrate when you change the language design now to favor explicitness
<jhass>
finding solid concurrency primitives might even allow to parallelize parts of the type inference, idk
<asterite>
Imagine a project that depends on 10, 20 or more libraries, like typical projects. Would you prefer to wait 30 seconds but keep things implicit every time you compile, or add a bunch of trivial type annotations and compile that in 1 second?
<asterite>
The problem is that right now such project doesn't exist, but it will
<jhass>
ever heard of premature optimization?
<jhass>
anyway, I don't want to fight over this, now you know my opinion, that's all I can give
<asterite>
It's not premature, the compiler already takes 5 seconds for type inference
<asterite>
And that's just 40 thousands lines of code
<asterite>
At work we have an app with 200k lines, and that without counting gems
<asterite>
Thanks. We definitely appreciate your opinion. But if we don't tackle this now the worry will remain. The threaded scheduler and so on are solved problems, it's just a matter of time. The language needs a lot more thought
<jhass>
interesting, if it's a solved problem you would've have somebody willing to spend time implementing it. Just saying.
<asterite>
Let's not fight :-)
<sdogruyol>
have to admit that was tough to watch :P
<McDougal>
sdogruyol: thanks ref kernal. So session handling & html template options available?
<sdogruyol>
agree on not fighting
* CompanionCube
would prefer as few type annotations as possible
<sdogruyol>
McDougal: not yet
<McDougal>
sdogruyol: Gotcha, so we have to bide our time for a little bit
<sdogruyol>
McDougal: yeah the thing is that lots of stuff are missing but improving :)
<McDougal>
sdogruyol: It looks v promising though, the concurrency story will be interesting as a comparison with elixir/erlang
<sdogruyol>
McDougal: yeah it'll be :)
<CompanionCube>
hm
<CompanionCube>
is it not possible to let the user decide if they want to make the trade-off?
<sdogruyol>
CompanionCube: how could you achieve something like that?
<CompanionCube>
sdogruyol, just an idea
<sdogruyol>
CompanionCube: yeah sounds OK but is there any example for that?
<CompanionCube>
sdogruyol, hm. I can't seem to think of one :(
Renich has quit [Quit: leaving]
Renich has joined #crystal-lang
<CompanionCube>
You *could* have it as some command-line flag but how it'd be implemented I have no idea
elia has quit [Ping timeout: 240 seconds]
elia has joined #crystal-lang
Renich has quit [Ping timeout: 244 seconds]
jwaldrip has joined #crystal-lang
Renich has joined #crystal-lang
sdogruyol has quit [Read error: Connection reset by peer]
sdogruyol has joined #crystal-lang
<xdougx>
jhass: if im inside a module ::Const will get the toplevel contant?
<crystal-gh>
[crystal] rosylilly opened pull request #1825: Allow plus and hyphen in markdown list (master...allow-plus-and-hyphen-in-markdown-list) http://git.io/vWPty
trapped has joined #crystal-lang
trapped has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<jokke>
jhass: am i blind or is there really no docs whatsoever for fibers and concurrency in general?
<jhass>
you're not blind
<jokke>
i'm trying to spawn two fibers and wait for them to finish
<jhass>
use a channel
<jhass>
receive twice
<jokke>
mh ok
<jokke>
so channel receive blocks?
<jhass>
yes
<jhass>
note unless you do IO inside them that's pointless atm
<jokke>
i would also need a channel which doesn't block :/
<jokke>
yeah i'm doing io
<jhass>
a buffered channel doesn't block on send unless full and doesn't block on receive unless empty
<jokke>
yeah i need it not to block even if it's empty
<jhass>
and then?
<jokke>
return nil
<jhass>
why?
<jokke>
i'm doing stuff periodically in this one fiber. it should receive stuff from a channel if there is anything new and then do stuff with it
<jokke>
if there's nothing new it should just continue doing what it's doing
<jhass>
use two separate coroutines
<jokke>
fibers aren't coroutines?
<jhass>
they are
<jhass>
the little bits asterite & waj mentioned indicate they consider Fiber an internal so I try to establish the general term
<jokke>
ok
<jokke>
anyway
<jokke>
i have two spawns
<jokke>
so i have two coroutines
<jokke>
one of which feeds the channel and one of which consumes it
<jokke>
seems that i can't even check if a channel is empty
<jhass>
I don't see the issue yet
<jokke>
oh i can
<jhass>
but so far it doesn't sound like you should