<BlaXpirit>
hm looks like quite a suboptimal way to do this, now that i'm more experienced
<BlaXpirit>
i would store in an array and then join instead
<BlaXpirit>
at the very least
<manveru>
ok, gotta continue this when i got more time...
<BlaXpirit>
in docs, how do i refer to a method of the same class and classmethod of the same class?
<BlaXpirit>
`#meth` and `.clsmeth` ?
qard has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<jhass>
vegai: cross compilation would be easier, there are a commit or two that can't be build by the previous one
<jhass>
vegai: bin/crystal build --cross-compile "linux i686" src/compiler/crystal.cr --target i686-pc-linux-gnu -o crystal32 change the arch, maybe you'll need --mcpu too, copy the resulting .o to the target system and invoke the linker command printed
<jhass>
BlaXpirit: don't think we got references yet
<RX14>
i've been trying to do something with crystal but keep getting distracted :(
<jokke>
i'm gonna try to rewrite some of my simpler scripts for starters
<jhass>
great
<jokke>
how does crystal somescript.cr compare against ruby somescript.rb
<jokke>
still faster?
<jokke>
even though having to compile the thing first
<BlaXpirit>
jokke, not faster only if it's something trivial because compilation takes some time
<jokke>
yeah
<jokke>
thought so
<jhass>
but not slower IME
<jokke>
ok
<jhass>
the compiler is quite fast, most time is spent in LLVM translating the IR and linking
<jokke>
llvm is so cool
<jokke>
yay, it built!
<jhass>
ffs the checksums don't match. OBS's Arch support is really subpar
<jhass>
okay, I think that fixed it
<jokke>
jhass: cool
<jokke>
there's no heredoc in crystal?
<jhass>
jokke: there is, <<-FOO
<jokke>
oh
<jokke>
ok with the -
<jhass>
yeah
NeverDie has joined #crystal-lang
<dzv>
jhass: read(slice, x) waits for x bytes. should read_partial be implemented to get any available data? thoughts?
<jhass>
dzv: don't we already have read_nonblock for that?
<dzv>
a) read_nonblock returns immediately and does not wait for any data. i want to wait for any available data, but not necessarily a whole slice worth b) read_nonblock looks like an old ruby ported method to me. it sets nonblocking every time directly through libc without using any existing methods.
<dzv>
read_partial would wait and hook into the scheduler/libevent and return the first available data
<jhass>
idk, you should discuss this with waj & asterite
<BlaXpirit>
well yeah but that would give a string
<Kilo`byte>
jhass: ah thanks
<ssvb>
vegai: I guess, installing these libraries (or compiling them from the source tarballs) should not be a big problem, just let me know if you need some help or have questions
<jhass>
.each_with_object([] of Char) {|chars, accum| accum.concat chars }
<Kilo`byte>
jhass: speaking of which
<Kilo`byte>
wait, thats like fold in other languages?
blue_deref has joined #crystal-lang
<jhass>
fold is closer to reduce/inject
<Kilo`byte>
also why does my program exit when the main thread exits even though other threads are running?
<Kilo`byte>
how can i fix that (crystal seems to lack parameterless sleep)
<jhass>
join them
<Kilo`byte>
the are not directly acessible from main thread
<jhass>
gotta change that
<Kilo`byte>
also, do instance variables have ability for atomic integer operations?
<jhass>
didn't see a SIMD library (or whatever it was called) library yet
<jhass>
the atomic operation would be on the object/method call btw, not the variable
wherd has joined #crystal-lang
strcmp1 has quit [Quit: Leaving]
zamith has joined #crystal-lang
strcmp1 has joined #crystal-lang
strcmp1 has quit [Read error: Connection reset by peer]
zamith has quit [Quit: Be back later ...]
elbow_jason has joined #crystal-lang
wherd has quit [Quit: leaving]
kulelu88 has joined #crystal-lang
blue_deref has quit [Quit: bbn]
kulelu88 has left #crystal-lang ["Leaving"]
kyrylo has quit [Ping timeout: 255 seconds]
juancate_ is now known as juancate
juancate has quit [Changing host]
juancate has joined #crystal-lang
<RX14>
it's a shame that googling crystal classes usually doesn't get you to the api
<BlaXpirit>
that gives me an idea
<BlaXpirit>
nope, nevermind
<RX14>
>>
<BlaXpirit>
RX14, u can make a custom google search with site:crystal-lang.org
<willl>
I still think toml is just an elaborate prank
<jhass>
heh
tliff_ is now known as tliff
<jhass>
I think it makes sense for user facing configuration
<jhass>
json has issues with quoting that are hard to catch for inexperienced users
<jhass>
yaml has the same with indentation
<jokke>
json has no comments
<jokke>
which is a major drawback
<jokke>
imho
<willl>
yeah json is bad for actually editing. i see the yaml indentation thing, but it seems alright
<jhass>
so having something like a formalized ini instead of everybody reinventing the wheel a slightly different seems nice
<jokke>
yeah a formalized ini would be great
<jhass>
I guess the main issue is libyaml fails at user understandable error messages
<jhass>
jokke: that's pretty much what TOML is
<jokke>
ok
havenwood has joined #crystal-lang
<jokke>
hm that's too bad :/ i heavily rely on user readable serialization
<willl>
https://github.com/toml-lang/toml/issues/42 when they didn't take these things seriously is when I kinda lost interest in toml, i think they started working on them more recently from what I've heard, but haven't looked into it
<jokke>
and since crystal is not ruby, i can't just make me a dsl for configuring my application
<jokke>
:)
<jhass>
so take a look at libyaml's serialization interfaces? sounds like it could be fun actually
<jhass>
I also didn't check if TOML defines serialization properly
<jokke>
i understand less than half when i look at the "low level" code of crystal
<jhass>
or just parsing
<jhass>
jokke: that can change!
<jokke>
jhass: :)
<jokke>
well it'd be really awesome to be part of this
<willl>
yeah, it's practice by taking on things always a bit harder than you did before
<jhass>
if you can understand why UInt8* is a C string I'm sure you can do it
<jokke>
sure :)
<jokke>
i've written a few drivers in C even
<jhass>
eh, then it shouldn't be hard really
<jokke>
(really basic ones, mind you) :D
<jokke>
ok what do i need to get started?
<jokke>
i'll just clone the repo and then?
<jhass>
yeah, but understanding how to map C types & structs and how to map them to Crystal types gets you 90% there
<jhass>
we don't need the user data, so we can ignore the first arg, @file.write Slice.new(buffer, size) should be enough to write
<jhass>
oh btw, map out any structs just as alias Foo = Void* unless you need to allocate them yourself, that is there's nothing like foo *make_me_foo(void)
<strcmp1>
BlaXpirit, im not sure about that, but maybe if you avoid calling into crystal code from the threads, its fine
<BlaXpirit>
i'm just wondering how broken would it be if i just used the threads that SFML provides
<BlaXpirit>
but there is of course crystal code + crystal wrapper code involved
<RX14>
hmmn, hmmn
<jhass>
again, as long as you don't use stdlib IO stuff you're fine
<jhass>
no Socket, no File
<BlaXpirit>
sounds good
<jhass>
it was working on fine on 0.6.1, DeBot still runs that
<RX14>
what's interesting is when I run a wrk test on a crystal webserver, it uses about 101% (1 core) but a single core on htop doesn't seem to be maxed
<BlaXpirit>
:o
<jhass>
sender thread, receiver thread, n processor threads
<crystal-gh>
[crystal] jpellerin opened pull request #1260: Add flatten() for iterators (master...iterator-flatten-2) http://git.io/vsVbe
<jhass>
the port to evented IO broke it
<jhass>
with 0.7
<BlaXpirit>
finally i know the secret
<BlaXpirit>
of DeBot
<strcmp1>
BlaXpirit, im not sure how it'd work out but everytime i see threads brought up on github its because they segfault on IO, and the response is to not use them, never directly anyway, because crystal will provide its own Go-like concurrency model
<jhass>
BlaXpirit: you can do the same with coroutines just fine, I'm just too lazy to port it
<BlaXpirit>
threads = [] of Thread; 3.times { threads << Thread.new { while true; end } }; threads.each &.join
<BlaXpirit>
sure enough, this fully uses 3 cores
<BlaXpirit>
RX14, you were interested
<jhass>
no magic, as said it's just phtread_create really
<strcmp1>
i dont think it matters if it used 100 cores, as soon as you do anything IO-related it'll segfault
<BlaXpirit>
yeah just some confirmation
<BlaXpirit>
IO-related or stdlib IO-related?
<jhass>
stdlib IO
<BlaXpirit>
ok
<BlaXpirit>
thx for info
<strcmp1>
all cases of IO i have seen, the french dude opened many issues about it
<jhass>
I have some vague plan to do crystal-posix-io sometime
<RX14>
nice
<jhass>
mainly for that reason
<BlaXpirit>
sounds like SFML would be just fine with threads
<jhass>
BlaXpirit: as long as you don't File.write("savegame", savegame) :P
<strcmp1>
i cant spell his name from memory :(
<RX14>
I can get a good 23K rps from the crystal webserver
<jhass>
RX14: built with --release ?
<RX14>
don't know how optimised it is though
<RX14>
jhass, yup
<RX14>
it doesn't use all the 8 cores though
<RX14>
neither does it max a single core
<jhass>
yes, as said it's single threaded atm, see my link
<RX14>
so i don't know what the bottleneck is
<jhass>
it doesn't max out the core because it'll still have IO wait time
<RX14>
but if it was singlethreaded, wouldn't 1 core be stuck at 100%
<RX14>
hmmn...
<jhass>
evented IO minimizes it, but doesn't eliminate
<jhass>
you still have the IO inside the thread
<RX14>
well, 23K is fast enough for me
<RX14>
i can always scale out
<jhass>
whereas with multithreaded one could shuffle the IO into the memory and the other could max out on CPU processing it
<jhass>
you probably could squeeze out 100 r/s by pining it to a single CPU
<jhass>
dunno, that number is out of my ass but some
<jhass>
man taskset
<RX14>
i get 26K
<RX14>
up from 23K
<RX14>
and a single core gets 100% when I use taskset
<RX14>
so it was just the scheduler moving it around, okay
<jhass>
nice, didn't really expect more than 500
kori has joined #crystal-lang
<RX14>
i'm impressed with crystal's performance on just one core
<RX14>
imagine if it scaled lineraly to 8
<RX14>
would be over 200K rps
<jhass>
well, the workstealing scheduler will introduce some overhead
<jhass>
but my guts say 150K might be feasible
<RX14>
well, i suppose we can only speculate until it's benchmarked
<RX14>
can you profile crystal?
<kori>
hello, I'm a new programmer and crystal caught my interest
<RX14>
"Each repo has a special branch (maybe _releases) with metadata for dependencies for each version. These are cummulative, so version 0.2 contains metadata for 0.1 and 0.2."
<RX14>
I don't like this
<kori>
same
<RX14>
i think git tags
<kori>
I don't like most of the things listed here
<RX14>
with metadata in the git tags
<kori>
but the fact there's no package manager yet is comforting
<kori>
gotta get to work FAST
<RX14>
would be nice if you could precompile the deps
<RX14>
but it doesn't look like you can
<jhass>
check shards (link at the bottom)
<jhass>
lots of discussions in its issue tracker too
<kori>
alright, cool
<kori>
got crystal installed!
havenwood has quit [Ping timeout: 245 seconds]
<jhass>
great!
<RX14>
and another day passes where I get about 5 lines of crystal done
<DeBot>
jhass: in line 4: undefined method 'zero' for String:Class - http://carc.in/#/r/cc8
<jhass>
just pick any undefined single letter constant
<Kilo`byte>
this should work
tatey_ has joined #crystal-lang
<kori>
alright... I don't really know where to get started
<jhass>
kori: have some goal? know ruby?
dylanmei has quit [Read error: Connection reset by peer]
TheMysticWyvern has quit [Read error: Connection reset by peer]
dylanmei has joined #crystal-lang
zamith has quit [Quit: Be back later ...]
<Kilo`byte>
now to figuring out how to convert an Int32 to an Int8
<jhass>
to_i8
<Kilo`byte>
crystal doesn't by any chance ship with ip parsing utils?
<jhass>
grep -Rin says no
<Kilo`byte>
hmm
<Kilo`byte>
didn't expect it tbh, but you never know
<Kilo`byte>
so another thing i gotta implement \o/
<Kilo`byte>
and while at it, add ip serialization/deserialization to my binary stream lib
<Kilo`byte>
can i find out the endianess of the host system at runtime btw? atm i assume little endian, idk if there are platforms that use big endian that crystal runs on
<jhass>
atm crystal only runs on x86 and x86_64, so...
<Kilo`byte>
not even arm? D:
* Kilo`byte
removes plans to use crystal for web apps on his pi