dbackeus has quit [Remote host closed the connection]
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: http://git.io/vO9Am
<crystal-gh>
crystal/master 3992520 Ary Borenszweig: Fixed #1024: incorrect error message when top-level method is invoked with wrong args from inside a type
dbackeus has joined #crystal-lang
<BlaXpirit>
on Ubuntu I can't use XML. /usr/lib/x86_64-linux-gnu/libxml2.so.2 is not found by -lxml2
nopc0de has joined #crystal-lang
willl has joined #crystal-lang
zamith has quit [Ping timeout: 240 seconds]
<travis-ci>
manastech/crystal#3992520 (master - Fixed #1024: incorrect error message when top-level method is invoked with wrong args from inside a type): The build passed. https://travis-ci.org/manastech/crystal/builds/74403247
<BlaXpirit>
well, it worked with libxml2-dev
<nopc0de>
Hey, silly question, what do you guys mean with "bootstrapped"? Does it mean it can compile itself?
<crystal-gh>
[crystal] BlaXpirit opened pull request #1113: Fix typos in XML node inspect (master...fix-xml-typos) http://git.io/vOHI4
<BlaXpirit>
nopc0de, yes
<BlaXpirit>
well boostrapping doesn't mean "compiles itself", but it only makes sense for compilers implemented in the language itself
<nopc0de>
Ok I see. What does that have to do with Windows support?
<nopc0de>
Oh wait I think I see it
<BlaXpirit>
nopc0de, to compile crystal on windows, one needs to compile crystal for windows
<nopc0de>
Yeah, I follow.
waj has quit [Quit: waj]
havenwood has joined #crystal-lang
michelboaventura has joined #crystal-lang
<crystal-gh>
[crystal] asterite pushed 2 new commits to master: http://git.io/vOHsW
<crystal-gh>
crystal/master d468e67 Ary Borenszweig: Fixed #1112: improved error message when writing `->{ |arg| ... }`, showing the correct syntax for proc literals.
<crystal-gh>
crystal/master d96ca20 Ary Borenszweig: On "wrong number of arguments" show all overloads anyway
<crystal-gh>
[crystal] asterite closed pull request #1113: Fix typos in XML node inspect (master...fix-xml-typos) http://git.io/vOHI4
<asterite>
BlaXpirit: I thought that too many times. I think ifdef came before macros, but it could be {% if defined ... %} because it's a compile-time check. But maybe it's something some common and useful in libs that it will remain like that
<travis-ci>
manastech/crystal#d468e67 (master - Fixed #1112: improved error message when writing `->{ |arg| ... }`, showing the correct syntax for proc literals.): The build passed. https://travis-ci.org/manastech/crystal/builds/74409767
Mercurial_ has joined #crystal-lang
<Mercurial_>
Hi, I have an issue
michelboaventura has quit [Remote host closed the connection]
<Mercurial_>
I'm trying to parse JSON
<Mercurial_>
and read from the Hash
<Mercurial_>
but it's not working
<crystal-gh>
[crystal] asterite closed pull request #1068: Escaped '<' and '>' characters during the creation of documentation (master...fix-html-doc) http://git.io/vOLYr
leafybasil has quit [Remote host closed the connection]
ssvb has joined #crystal-lang
jamie_ca has joined #crystal-lang
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: http://git.io/vOQya
<crystal-gh>
crystal/master 0e0f3fa Ary Borenszweig: Run inherited hooks *before* class body. Fixes #1109. Fixes #911.
waj_ has joined #crystal-lang
<jamie_ca>
so, I'm a total Crystal newbie (with ~10y ruby experience), porting some ruby code and getting totally confused by a compilation error, trying to update an array value and being told I have an array of Fibers when I swear I've never done anything with Fibers yet?
<BlaXpirit>
jamie_ca, well, [] of Array is wrong, im pretty sure
<BlaXpirit>
nopc0de, at the very least u should be able to generate them yourself
<BlaXpirit>
jamie_ca, try [] of Array(UInt32) and get back to us
<jamie_ca>
oooooh... BlaXpirit I think you're totally right
<jamie_ca>
yeah, that's totally it
<BlaXpirit>
jamie_ca, and the reason it says something about fibers is maybe Array(Fiber) has a different []= than other arrays? i have no idea
<jhass>
jamie_ca: what you say if of Array is every possible subtype of Array(T), and since the stdlib creates an Array(Fiber) somewhere that's simply the first you ran into that didn't match
luislavena has quit [Remote host closed the connection]
<jamie_ca>
BlaXpirit: also, @array = [program] looks like it's smart enough to infer the correct type
<nopc0de>
BlaXpirit you mean like... using wget?
<jamie_ca>
jhass: gotcha.. makes sense
<BlaXpirit>
nopc0de, it's just empty arrays that u need to specify the type
<BlaXpirit>
[] is not enough info on what type there will be :P
<BlaXpirit>
nopc0de, no, i mean generate
<jhass>
jamie_ca: though the error message is a bit confusing indeed, feel free to open a report about that
<nopc0de>
BlaXpirit from?
<jamie_ca>
nah, it's making more sense now compared to 11pm last night
<BlaXpirit>
nopc0de, download source code and `make doc`
<sdogruyol>
wish we had public_instance_methods :(
<nopc0de>
thanks BlaXpirit
<sdogruyol>
is there a way to get the current instance methods of self context?
<BlaXpirit>
sdogruyol, i don't understand
<jhass>
>> class Foo; def foo; {{@type.methods}}; end; end; Foo.new.foo
<sdogruyol>
jhass: well i'll try to create a macro for that issue
Mercurial_ has quit [Client Quit]
<jamie_ca>
Nice. ported ~140 loc in an hour and a bit, including time spent reading docs and figuring out a replacement for ruby's String#unpack to read a raw array of UInt32 from a binary file
<jamie_ca>
very cpu heavy, 5x faster than ruby, 5x slower than go
<jamie_ca>
but _so_ much more familiar and nice to work with than go
<jhass>
jamie_ca: compiled with --release yet?
<jamie_ca>
oh, crystal has that too?
<jhass>
yes
<jhass>
crystal build --release foo.cr
<jamie_ca>
I did that with rust a few days ago, --release was almost a 10x speedup
<BlaXpirit>
ooh boy let's see how fast it is
<jamie_ca>
holy crap
<jamie_ca>
I'm doing ICFP Contest this weekend, was considering rust on account of it's less annoying to debug than go
<jamie_ca>
then got reminded of Crystal via HN
<BlaXpirit>
jamie_ca, so how fast is it?
<sdogruyol>
jhass: --release by default always :P
<BlaXpirit>
sdogruyol, that is not a good approach
<BlaXpirit>
it brings nothing new to the table and is nowhere close to fastest
<BlaXpirit>
just 100% money
<nopc0de>
They have a cute mascot
<sdogruyol>
go makes me feel like a dummy
<sdogruyol>
i like to tinker when programming lol
<BlaXpirit>
well at least they have stdlib documentation :|
<jamie_ca>
yeah, go treating unused requires as a build error is stupidly painful while developing
<jamie_ca>
especially when it's just a require for puts debugging
<sdogruyol>
jamie_ca: rust is much more better
<jamie_ca>
BlaXpirit: ruby 2900s, crystal 106s, go 82s, rust 40s
<jamie_ca>
but somehow crystal is able to use 135% of a cpu, so it finished in 91s wall time vs 99s of go
<jamie_ca>
yup, probably never using go again :P
<sdogruyol>
jamie_ca: crystal has channels too
<sdogruyol>
but it's pretty naive right now :P
<sdogruyol>
only utilizing single thread
<jamie_ca>
sdogruyol: my code is pure single-threaded, I'm not doing anything special
<jamie_ca>
and I wouldn't expect it to be able to benefit from multithreading either
<jamie_ca>
but there it is
<jhass>
well, one thread for IO one for whatever else
<sdogruyol>
jamie_ca: i recently wrote a http benchmark tool like ab in crystal and it's pretty fast..but channels not utilizing all cores is limiting the max rps :S
<jamie_ca>
;)
<jhass>
I do wonder if there are some tricks left that would get the crystal version closer to rust :P
<nopc0de>
BlaXpirit The make doc result doesn't seem to be very complete...
<BlaXpirit>
nopc0de, i dunno, looks like an exact copy to me
<jamie_ca>
jhass: well, in my use case, Rust is only using 6s of system time, vs 17s in crystal, and thats prob because I'm reading the whole file in at once in rust, whereas crystal I'm doing a goofy (file.read_byte || 0).to_u32 loop to assemble _u32 one byte at a time
<nopc0de>
Yeah its the API docs
<nopc0de>
not crystal-lang.org/docs
<jamie_ca>
File.read blows up because it's not a valid UTF8 string :(
<BlaXpirit>
oooh sorry, nopc0de
<jhass>
ah, mh, there should be a away to slurp into a Slice nonetheless
<jamie_ca>
if I could figure a better way around that, that gets wall time to 1.5x rust speed, which is a penalty I'm _more_ than happy to take for the friendlier syntax
<jhass>
jamie_ca: I suspect there's also a way to use Slice#[](start, count) to get new 4 byte Slice's and cast the underlying .pointer to Pointer(UInt32) and obtain its .value or something
<jamie_ca>
BlaXpirit: I actually have no idea. It's a bytecode VM, running a benchmark I have no knowledge of the guts.. it's entirely it's creating a lot of Array(UInt32) and tossing them. It's highly likely that it's just doing a lot of integer math though, and bouncing the ints between arrays
<jhass>
the .map does create an intermediate array, yeah
<jhass>
that's another obvious one
<jamie_ca>
jhass: oh, I'm almost certain that my initial array is not the source of the trouble ;)
<jamie_ca>
jhass: sure, it's at https://github.com/jamie/icfp2006, code in crystal/um.cr, should be able to just run it and it'll execute ./sandmark.umz by default
<dbackeus>
using the method_missing macro, say I want to catch all methods with a certain prefix but would like all other calls to result in the normal "undefined local variable or method", can I make that happen somehow?
<jhass>
oh I see what you mean, not even build data is slow, executing the loaded data is
<jamie_ca>
yeah
<jamie_ca>
which is to be expected, the benchmark is designed to stress the VM implementation
<asterite>
Maybe it's the GC. Right now we use boehm, which is conservative, but talking with Jeff (from Julia) he told us that they originally used boehm too and one day he decided to write a super simple mark-and-sweep GC and it worked much faster. So that's something we will also improve with time
<BlaXpirit>
with crsfml i had some trouble where my program would consume a ton of memory
<BlaXpirit>
it on eventually stopped growing
<BlaXpirit>
only*
<asterite>
jamie_ca: instead of [v] * 10 you can do Array.new(10, v). That's one allocation versus at least two
<asterite>
(and one of the reasons why Array#* wasn't in the standard library, it probably just always slows things down)
<asterite>
But with that I get 59s vs 47s in rust
<jhass>
I think @register can be a UInt32[8]
sdogruyol has quit [Remote host closed the connection]
Mercurial_ has joined #crystal-lang
nahtnam has joined #crystal-lang
<jamie_ca>
asterite: that helps me, but not as much as you... I'm still at 83s wall time vs 48
<crystal-gh>
[crystal] jalyna opened pull request #1116: Add permutation method for array (master...add-permutation) http://git.io/vO5qH
<crystal-gh>
[crystal] bcardiff pushed 1 new commit to master: http://git.io/vO5sG
<crystal-gh>
crystal/master 6c42520 Brian J. Cardiff: add gh-pages branch to travis whitelist
<asterite>
Yes, I can't find any other difference to improve this. There's the possible GC improvement, and also the thing that arrays are always notified to the GC as "pointers might be here", but if an array contains numbers it should probably be reported as "no pointers here for sure". The second thing is easier to do than the first one
<asterite>
(and since this program has lots of arrays of numbers and the GC has to scan that, maybe with that optimization the times will improve, but I don't know)
NeverDie has quit [Quit: I'm off to sleep. ZZZzzz…]
<jhass>
I simply don't have enough free ram to run the crystal version :/
<jamie_ca>
jhass: only caps out at 5.87gb for me O_o
<asterite>
With rust I reach 2gb, with crystal it goes to 5.84g, I wonder why...
<jamie_ca>
rust hits 2gb, go hits 11.62gb
<jamie_ca>
and all of them lag slightly whenever it allocates a new batch of ram
<jhass>
well, I only have 8G and my open stuff easily eats 3 of it already...
<jamie_ca>
OSX is doing some work compressing memory, but I've definitely got more swap allocated now than I did 10 minutes ago :P
<jhass>
also slow HDD so swapping important stuff like the DE stalls the system ;)
waj_ has joined #crystal-lang
<asterite>
the main difference is rust is when you do vec![], it doesn't allocate anything until you actually want to put data in there
<asterite>
jamie_ca: you think that's the difference? (the thing you said about a new batch of ram)
waj has quit [Ping timeout: 244 seconds]
waj_ is now known as waj
<jamie_ca>
asterite: I actually have no idea. hell, my slowdowns (and extra system execution time) might just be stalls while OSX compacts ram
<jamie_ca>
is a mystery, but I'm not trying to run anything latency-sensitive so I can probably ignore it for now
dbackeus has joined #crystal-lang
<jamie_ca>
lol
<jamie_ca>
dear self, if you're trying optimizations in a new file, when you build um-tiny.cr you should also run um-tiny, not um.
strcmp1 has quit [Quit: Leaving]
<asterite>
:)
luislavena has quit []
waj_ has joined #crystal-lang
waj has quit [Ping timeout: 240 seconds]
waj_ is now known as waj
dbackeus has quit [Remote host closed the connection]
dbackeus has joined #crystal-lang
<asterite>
jamie_ca: well, I was able to get it down to 3.8g with some simple changes. Rust does a much better memory management for arrays. I saw that at the end of the program most of the arrays end up empty. In the case of Rust I think they free the memory when they clear them, but we are merely setting the length to zero
<asterite>
I guess there are many more things we can improve. I think we'll use your program a lot :-)
<jamie_ca>
:)
<jamie_ca>
hey, happy to accidentally help
mcgain has joined #crystal-lang
dbackeus has quit [Ping timeout: 240 seconds]
leafybasil has joined #crystal-lang
waj_ has joined #crystal-lang
waj has quit [Ping timeout: 260 seconds]
waj_ is now known as waj
strcmp1 has joined #crystal-lang
ponga has joined #crystal-lang
zamith has joined #crystal-lang
jwaldrip has joined #crystal-lang
<jwaldrip>
So is there a good resource for external libraries in crystal. I.e. SQL?
<BlaXpirit>
curated gives no chance for new projects
dbackeus has joined #crystal-lang
mcgain has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<ozra>
jamie_ca: BlaXpirit Saw above you did a bench and allocated a bunch of Array(Int). I think Crystal uses `GC_malloc()` for all allocations which is a suuuper-waste. If Array checked if type is non-pointer, and simply used GC_malloc_atomic() instead, it could yield some speedups. I tried digging around a bit, but there's to little docs on the internals and I didn't have the time to finish the change. Anyone? - should be viable?
<BlaXpirit>
ozra, actually asterite mentioned something like that
<BlaXpirit>
[:00:43] <asterite> Yes, I can't find any other difference to improve this. There's the possible GC improvement, and also the thing that arrays are always notified to the GC as "pointers might be here", but if an array contains numbers it should probably be reported as "no pointers here for sure". The second thing is easier to do than the first one
<ozra>
Aha, ok, I just glanced quickly through the history. Is it in the works of getting changed? It should be really simple.
<ozra>
Ah. Neat. Exactly that I was hacking on..
<ozra>
It should actually give quite a good boost.
<willl_>
you can figure it out if you do --emit llvm-ir on a program that is just something like "Pointer(Char).malloc(8675309_u64)" and then look for 8675309
<ozra>
willl_: Thanks - hmmm. BlaXpirit: The "problematic" program (slower than rust) mentioned earlier, was there some link to source for it? I thought I'd patch the compiler locally and compare speed...
willl_ has quit [Quit: Page closed]
<BlaXpirit>
ozra, repository was linked
<BlaXpirit>
[:08:48] <jamie_ca> jhass: sure, it's at https://github.com/jamie/icfp2006, code in crystal/um.cr, should be able to just run it and it'll execute ./sandmark.umz by default
dbackeus has quit [Remote host closed the connection]
<ozra>
Ah, thanks, feel like a wheelchair retard for not searching, sorry!
<BlaXpirit>
jhass, not if it's recommended in official docs
<sardaukar>
I would like to have do/while :D
<BlaXpirit>
besides, opposition against it is subjective
<sardaukar>
but OK
<jhass>
BlaXpirit: that's easily fixed
<BlaXpirit>
i like that do-while loop exists
<BlaXpirit>
and i think this could be classified as a bug
<sardaukar>
BlaXpirit: should I file an issue?
<jhass>
yes, not worth fixing since we really should remove it, the alternative I showed is as performant
<sardaukar>
jhass: your construct works, but is verbose
<BlaXpirit>
jhass, removing it would mean intentionally breaking a construct that has no reason not to work
<sardaukar>
"loop do" is kind of a keyword in 2 parts :/ never liked it
<jhass>
well, I never really needed a do-while in ruby ever anyway
<jhass>
so for the very rare cases I don't mind at all
<BlaXpirit>
because expr while expr can't go away
<BlaXpirit>
or can it
<ozra>
jhass: is "do" really needed in that construct when newline'ing?
<BlaXpirit>
sardaukar, personally i think you should
<jhass>
ozra: yes, loop is a method call and you pass it a block
<sardaukar>
ozra: needing the "do" is why I think it's a keyword in two parts
<sardaukar>
kind oif
<jhass>
BlaXpirit: no reason we can't disallow begin expr end while expr while allowing expr while expr
<BlaXpirit>
jhass, of course there is a reason, it's consistency
<asterite>
I was able to reduce the memory to less than 2 gigas by having the program's array be Array(Array(UInt32)?)... that's because most of the arrays end up empty at the end, so instead of empty I just nil them and the memory is reclaimed
<BlaXpirit>
yeah,... loop do seems to be just an awkward alias to while true
ozra has joined #crystal-lang
<ozra>
asterite: Would you mind trying a type conditional in Pointer.malloc for primitives and use GC_malloc_atomic - as discussed above? I'm tinkering now, but the bench-program crashed on my ancient computer (guess out of mem or something) :-/
<asterite>
ozra: let me try
<ozra>
So progresses bit to slow.. It could potentially have a biig impact