jhass changed the topic of #crystal-lang to: The Crystal programming language | http://crystal-lang.org | Crystal 0.7.7 | Fund Crystals development: http://is.gd/X7PRtI | Paste > 3 lines of text to https://gist.github.com | GH: https://github.com/manastech/crystal | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/ | Logs: http://irclog.whitequark.org/crystal-lang
waj has joined #crystal-lang
<waj> jhass: oh... I think cc in mac doesn't like that flag
waj has quit [Client Quit]
shama has quit [Quit: (╯°□°)╯︵ɐɯɐɥs]
<travis-ci> manastech/crystal#927486b (master - Fixed a couple of cases where a proc was incorrectly marked as a closure): The build passed. https://travis-ci.org/manastech/crystal/builds/81109095
Neverdie has quit [Quit: http://radiux.io/]
Neverdie has joined #crystal-lang
vikaton has quit [Quit: Connection closed for inactivity]
havenwood has joined #crystal-lang
waj has joined #crystal-lang
jeromegn has quit [Ping timeout: 256 seconds]
jeromegn has joined #crystal-lang
jeromegn_ has joined #crystal-lang
jeromegn has quit [Ping timeout: 250 seconds]
jeromegn_ is now known as jeromegn
havenwood has quit [Quit: Textual IRC Client: www.textualapp.com]
havenwood has joined #crystal-lang
<crystal-gh> [crystal] waj pushed 1 new commit to master: http://git.io/vnOrz
<crystal-gh> crystal/master 56842cc Juan Wajnerman: Added -rdynamic link flag so backtace symbols are properly found in Linux
<travis-ci> manastech/crystal#56842cc (master - Added -rdynamic link flag so backtace symbols are properly found in Linux): The build passed. https://travis-ci.org/manastech/crystal/builds/81118990
Neverdie has quit [Quit: http://radiux.io/]
<crystal-gh> [crystal] waj pushed 1 new commit to master: http://git.io/vnOXZ
<crystal-gh> crystal/master 5d71cff Juan Wajnerman: Bring `caller` back. Refactored callstack generation.
<travis-ci> manastech/crystal#5d71cff (master - Bring `caller` back. Refactored callstack generation.): The build was broken. https://travis-ci.org/manastech/crystal/builds/81120983
Neverdie has joined #crystal-lang
waj has quit [Read error: Connection reset by peer]
waj_ has joined #crystal-lang
waj_ has quit [Read error: Connection reset by peer]
waj has joined #crystal-lang
<crystal-gh> [crystal] waj pushed 1 new commit to master: http://git.io/vnOb3
<crystal-gh> crystal/master 48788cb Juan Wajnerman: Removed obsolete spec
<travis-ci> manastech/crystal#48788cb (master - Removed obsolete spec): The build was fixed. https://travis-ci.org/manastech/crystal/builds/81122750
waj has quit [Remote host closed the connection]
waj has joined #crystal-lang
waj has quit [Ping timeout: 256 seconds]
Neverdie has quit [Quit: http://radiux.io/]
waj has joined #crystal-lang
waj has quit [Ping timeout: 255 seconds]
BlaXpirit has joined #crystal-lang
Raimondi has quit [Ping timeout: 250 seconds]
elia has joined #crystal-lang
waj has joined #crystal-lang
<crystal-gh> [crystal] technorama opened pull request #1524: Change waitpid handler to use a future. (master...f/fork_future) http://git.io/vn3rm
havenwood has quit [Ping timeout: 264 seconds]
waj has quit [Ping timeout: 252 seconds]
ssvb has quit [Ping timeout: 240 seconds]
waj has joined #crystal-lang
waj has quit [Ping timeout: 240 seconds]
ssvb has joined #crystal-lang
trapped has joined #crystal-lang
apt-get has joined #crystal-lang
waj has joined #crystal-lang
waj has quit [Ping timeout: 256 seconds]
elia has quit [Quit: (IRC Client: textualapp.com)]
<crystal-gh> [crystal] asterite pushed 1 new commit to master: http://git.io/vnskm
<crystal-gh> crystal/master e363b63 Ary Borenszweig: Crystal 0.8.0
<jhass> oh good morning ary
<BlaXpirit> :O
<BlaXpirit> i dunno, i would've packed some more breaking changes before making a 0.8.0
<jhass> BlaXpirit: well, SemVer below 1.0 is "throw a dice" ;)
<travis-ci> manastech/crystal#e363b63 (master - Crystal 0.8.0): The build passed. https://travis-ci.org/manastech/crystal/builds/81148972
nakilon has joined #crystal-lang
<asterite> Good morning
<asterite> :)
<asterite> Well, I think it's a nice release because you get to type a less more in c bindings and enum cases
<BlaXpirit> ?
<asterite> We'd also like to do 0.9.0 and 0.10.0 so that everyone knows it doesn't mean we are very close to 1.0 :-P
<BlaXpirit> I don't understand what you mean about enum cases
<BlaXpirit> "Automatically define questions methods for enum members"?
<BlaXpirit> "Enum.flags macro"?
<asterite> It's described in enum.cr
<BlaXpirit> indeed
<BlaXpirit> great stuff
<asterite> Once we do the automatic lib bindings, that would be awesome :)
<BlaXpirit> sure, automatic `lib` generator is doable
<BlaXpirit> i made one but people ignore it cuz it's python
<BlaXpirit> but then you still need to make wrapper objects
thor77 has left #crystal-lang ["Leaving"]
<asterite> Oh, but it'll be integrated in the compiler. Yes, there will be a need for wrapper objects
<asterite> maybe we can also try to do a separate tool for that
<asterite> I think there are just a few c libraries that are whole big frameworks. Most of them are small
<BlaXpirit> why would it need to be integrated in the compiler?
<asterite> Because of type changes between platforms
<asterite> and the compiler will generate another temporary file that contains the real definitions
<asterite> For other libs you'll be able to say "import everything with this prefix"
<asterite> Constant numbers and argument types change between platforms, and this is the best way to deal with this: generate it on the fly based on the current platform
<BlaXpirit> ok
<BlaXpirit> never needed that though
<jhass> asterite: I wonder, does clang expose preprocessor macros too, so we could maybe even translate the simple ones?
<asterite> Yes!
<jhass> that's nice
<asterite> For example yesterday we found one that had the value "((void*)-2)"
<asterite> we could translate that to Pointer(Void).new(-2)
<asterite> we can add these special cases as we need them
<jhass> I guess it gets interesting with parameters though :P
<asterite> For example?
<BlaXpirit> what about functions that have their body in the header file?
<asterite> But maybe, just maybe, for those cases you'd still have to write the value manually, if it gets too hard
<asterite> In any case, it'll be much better than what we have right now :)
<jhass> well, things like WIFEXITED(status)
<jhass> sure
<jhass> just curious if clang exposes enough to do that too
<asterite> Let me try :)
<BlaXpirit> i would guess that clang just exposes arguments and macro string
<asterite> Right now it says: can't parse value of constant WIFEXITED: (x)(_WSTATUS(x)==0) (Exception)
<asterite> so there could be a way to handle that...
<jhass> okay maybe a mean one since it "calls" into other ones :P
<jhass> difftime might be a macro too I guess
<BlaXpirit> i don't think this is reasonably doable
waj has joined #crystal-lang
<asterite> Today I feel too lazy to write a blog post
<asterite> Anyone wants to be a guest blogger? :)
* jhass hides
BlaXpirit has quit [Quit: Konversation]
BlaXpirit has joined #crystal-lang
BlaXpirit has quit [Client Quit]
<asterite> lol
waj has quit [Ping timeout: 256 seconds]
jhass changed the topic of #crystal-lang to: The Crystal programming language | http://crystal-lang.org | Crystal 0.8.0 | Fund Crystals development: http://is.gd/X7PRtI | Paste > 3 lines of text to https://gist.github.com | GH: https://github.com/manastech/crystal | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/ | Logs: http://irclog.whitequark.org/crystal-lang
apt-get has quit [Ping timeout: 260 seconds]
apt-get has joined #crystal-lang
<asterite> Please try crystal 0.8.0 and let me know if something went wrong :)
<jhass> asterite: btw any ideas yet how to workaround the issue with the eval bot here? I don't want to let it left stuck on 0.7.6 :/
<jeromegn> ah, this didn't make it? :( https://github.com/manastech/crystal/issues/1473
<jeromegn> good work btw :) such a nice language!
nakilon has quit [Read error: No route to host]
nakilon has joined #crystal-lang
<asterite> jeromegn: no, sorry :(
<asterite> Didn't have time to look at it
<asterite> But... json is pretty similar to bson and we don't have that issue. Maybe as a temporary workaround you can see how we do it
<asterite> For starters, there's no need to extend array or hash
<asterite> (I think)
<asterite> Can you parse the code using crystal and extract the last expression?
<asterite> jhass: ^
<jhass> maybe, perhaps as a macro?
<jhass> but then you want the rescue block around all expressions
<jhass> I don't really want to embed crystal into the bot :/
<asterite> Mmm... maybe you can sort the expressions and move all classes and defs to the top
<jhass> yeah
<jeromegn> what are we talking about now? :)
<jhass> will probably require a couple of new macro methods
<jeromegn> extending hash is an issue in this case?
<asterite> I'll think of a solution, don't worry
<jeromegn> I had the thought: well if any kind of Array is passed to []= on the BSON::Document, then I can recast it as [] of BSON::Document (which works as shown in the example in my comment)
<jeromegn> but that's probably not a great idea
<jeromegn> oh no that doesn't make sense
waj has joined #crystal-lang
<jeromegn> I guess I don't need to have a BSON::Document, I can just add methods on Hash
<jeromegn> I wonder if 0.8 breaks shards
<asterite> What methods you need to add to hash?
<jeromegn> to_bson, from_bson mostly
<jeromegn> like to_json, except it needs to produce a Slice(UInt8) of raw bytes instead of a string
<jeromegn> looking at the installation instructions for shards, we probably need something friendlier. right now crystal added the shards dependency by using shard.yml by default, however it doesn't seem super easy to get going with that lib.
<asterite> Oh, that's fine, to_bson and from_bson are OK. We also define to_json in the standard library
<jeromegn> yes
<jeromegn> I figured :)
<jeromegn> jhass: so that IO::Memory thing we we're talking about, is it the same thing as SliceIO, just named differently? :P
<jeromegn> oh the API docs are out of date
<nakilon> hmmm
<nakilon> [16:37:06] <asterite> Oh, that's fine, to_bson and from_bson are OK. We also define to_json in the standard library
<nakilon> and smth like Int32.new(x)
<jhass> jeromegn: depending on your definition of SliceIO, yes
<jeromegn> ha :)
<nakilon> then I suggest the univesral syntax: x.to(BSON), x.to(Int32), ...
<jeromegn> jhass: what's your definition? I was gonna say IO that lives in the heap, but then again, I'm not very familiar with all of this
<jhass> jeromegn: well, that aspect is obvious ;) More whether it should grow or just be a static view upon a Slice etc
<jeromegn> I'm glad it's obvious, I was actually testing the waters hah. I looked up the difference between heap and stack last week so... I have a long road ahead of me.
BlaXpirit has joined #crystal-lang
<jeromegn> self-taught web developer doesn't know much about lower-level stuff ;)
<jhass> it's not like I started anywhere else
<jeromegn> I'm sure I'll get there
waj has quit [Read error: Connection reset by peer]
waj_ has joined #crystal-lang
<jhass> willl: so, we gotta install shards on travis now. I think we should try to find a way to always install the latest version, which means either get the repo and find the latest tag and build it ourselves or setup a redirect somewhere so we can update the download
<jhass> mmh, or fetch the latest tag/release via the github api I guess
havenwood has joined #crystal-lang
waj_ has quit [Read error: Connection reset by peer]
waj has joined #crystal-lang
Raimondi has joined #crystal-lang
sferik has joined #crystal-lang
<jeromegn> well, apparently that works just fine: https://github.com/benoist/msgpack-crystal/blob/master/src/slice_io.cr
waj has quit [Read error: Connection reset by peer]
<jeromegn> it resizes itself
waj_ has joined #crystal-lang
ponga has quit [Quit: Connection closed for inactivity]
<jeromegn> what about merging the shards lib in crystal itself? package management seems like a good fit. at least more than OAuth ;)
<BlaXpirit> jeromegn, it's only a matter of time
<jeromegn> :+1:
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 244 seconds]
Raimondii is now known as Raimondi
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 255 seconds]
ssvb has quit [Ping timeout: 265 seconds]
Raimondii is now known as Raimondi
<waj_> we might merge shards into crystal in the future, but one reason to keep them separate for now is letting them have different releases
waj_ is now known as waj
waj has quit [Read error: Connection reset by peer]
waj_ has joined #crystal-lang
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 255 seconds]
<jeromegn> sounds good
<jeromegn> would be nice to have it easily installable like crystal via homebrew and aptitude
Raimondii is now known as Raimondi
waj has joined #crystal-lang
waj_ has quit [Ping timeout: 246 seconds]
waj_ has joined #crystal-lang
waj has quit [Ping timeout: 255 seconds]
<jhass> somebody needs to convince ysbaddaden to idle on IRC :P
<jeromegn> was length replaced by size everywhere?
<jeromegn> undefined method 'length' for String
<BlaXpirit> yes, jeromegn
<jeromegn> neat
<jeromegn> that's more consistent I think
waj_ has quit [Ping timeout: 265 seconds]
ssvb has joined #crystal-lang
jeromegn has quit [Ping timeout: 264 seconds]
jeromegn has joined #crystal-lang
waj has joined #crystal-lang
Neverdie has joined #crystal-lang
waj has quit [Read error: Connection reset by peer]
waj_ has joined #crystal-lang
waj_ has quit [Remote host closed the connection]
<crystal-gh> [crystal] technorama opened pull request #1527: Make Future lazier. Don't spawn an additional Fiber with lazy. (master...f/retirement) http://git.io/vnGTM
<BlaXpirit> i want a backwards compatible .new/.cast, how can i do that?
<jhass> why?
<jhass> supporting multiple crystal versions isn't sane at the current stage :P
<BlaXpirit> jhass, cuz why would i want to drop compatibility with all those previous versions?
<BlaXpirit> since 0.6.somethin
<BlaXpirit> this is something i'm trying http://carc.in/#/r/g06
<jhass> why keep it?
<BlaXpirit> why drop it? srsly
<jhass> we do breaking changes in point releases, nobody stays on the old versions since way too many issues are fixed etc
<BlaXpirit> oh i'm a dummy, that was jinja2, not crystal :p
<jhass> well, anyway, copy pasta https://github.com/manastech/crystal/blob/master/src/libc.cr#L82-L120 into your project then
<BlaXpirit> jhass, but there is no SizeT
<BlaXpirit> oh i'm silly, there is :p
<jhass> SizeT is an alias to one of those
<dzv> blaxpirit: support #1515 so you can do version checks
<BlaXpirit> dzv, mm ok
<jhass> dzv: uhm, defining methods does not work...
<jhass> with runtime version checks
<dzv> read my comment. it was pseudo code. you'd use macros to define versions
<dzv> define methods
<BlaXpirit> yes.....
<dzv> i do most of my pseudo code in a ruby style. normally that doesn't confuse people who use other languages.
<dzv> jhass: memory ballooning in #1524 could possibly be fixed if #1527 is merged. on my system the compiler doesn't exceed 2.1g with both applied
<jhass> well, from my obsersations it's address exhaustion actually, so you did watch VIRT not RES?
<jhass> *observations
<dzv> do you know why that would be?
<jhass> I have no idea
<jhass> I'll try if it gets fixed for me with both applied
<jhass> mmh, you changed future to lazy and the travis build passed?
<dzv> it should
<dzv> oh
<dzv> weird
<dzv> am i the only one who gets spurious travis build failures?
<jhass> where?
<dzv> sometimes after creating a PR or updating the build will fail. somtimes = 1 in 20
<dzv> changing the commit msg with push -f cures the problem
<jhass> there's a random failure in a bcrypt spec and one random "Could not raise" in the OS X build iirc
<jhass> so yeah #1524 no longer balloons VIRT here too, regardless of #1527
<dzv> how many times did you test and see the VIRT explosion?
<dzv> i've seen oom errors in my builds before.
<dzv> i wonder if this is a timing issue with the GC and possibly fork
BlaXpirit has quit [Read error: Connection reset by peer]
BlaXpirit has joined #crystal-lang
<jhass> well, both travis builds failed, the travis build I retriggered failed to see if it's random and it failed locally
<jhass> pretty sure it was fixed by something you changed (and it was future instead of lazy iirc)
<dzv> i don't see why
<dzv> it was 1 just changes the timing of spawning the fiber
<dzv> everything else is the same
<jhass> yes, I find it mysterious too, I'm just reporting the facts
<jhass> yep, if I change the lazy back to future it baloons VIRT again
<dzv> i find that disturbing
apt-get_ has joined #crystal-lang
apt-get has quit [Ping timeout: 240 seconds]
<jhass> merging #1527 in doesn't help it either
<jhass> note to reproduce you need to rebuild the compiler, since the bug is the compiler with that change failing to compile all_spec
<dzv> very disturbing
<dzv> there isn't much use of spawn anywhere in the code base
<dzv> except waitpid
<dzv> could there be a problem with channels/spawn?
<jeromegn> jhass: so I'm trying something like this: http://play.crystal-lang.org/#/r/g0g
<jeromegn> line 30 is probably off
<jeromegn> I'm not sure how to do that
<jhass> dzv: and fork? maybe
<jeromegn> @buffer.to_unsafe.realloc(count + @bytesize) if count > @bytesize
<jhass> jeromegn: if @post+count > @bytesize ?
<jhass> *@pos
<jeromegn> I basically get a segfault :)
<jeromegn> with our without that modification
<jhass> compile with -d and run it through valgrind and/or gdb
<jhass> should get you a startpoint for where you need to verify your assumptions
<dzv> jeromegn: why not use an Array and let it allocate for you?
<jhass> dzv: dunno, that couples it to the internals of array, wouldn't like that
<jeromegn> hmm, the arrays reallocates itself though
<dzv> the public interface maybe but not the internals i think. use array.to_slice everywhere else a copy or slice is used
<jhass> jeromegn: realloc returns you a new pointer
<jhass> it doesn't modify self
<jeromegn> oh
<jeromegn> that's right!
<dzv> too much low level manual memory management
<dzv> allows room for bugs to creep in
<jeromegn> jhass: was there a particular reason to use Slice vs Array? (in your initial thoughts)
havenn has joined #crystal-lang
<jhass> I don't see Array as "a blob of memory"
<jhass> I see Slice that way
<BlaXpirit> i see Slice as a pointer with length and I think Slice.new is a mistake
<BlaXpirit> with SIZE, sorry -_-
<jeromegn> so maybe the Slice needs to be able to realloc its buffer
<jeromegn> hah
<jhass> uh, no, blob of memory of fixed size ;)
<jeromegn> a fixed size IO sounds weird, no?
<BlaXpirit> i hate that Pointer and Slice either own some memory or they don't, depending on how they were created
<jhass> though I guess I actually wouldn't oppose an API like Slice.resize(slice : Slice, new_size)
havenwood has quit [Ping timeout: 250 seconds]
<dzv> blaxpirit: i agree
<dzv> very confusing
<dzv> slice is a struct. changing shrinking the underlying buffer size or reallocating to make it larger could lead to memory corruption if other copies of the slice are used
<jhass> mmh, true
<jhass> I guess it would only allow growing
<jhass> or always copy
<jeromegn> so, writing to a IO should not affect its position eh?
<jhass> of course it does
waj has joined #crystal-lang
<jeromegn> ugh, ok that SliceIO implementation in messagepack did not augment the position
<jeromegn> *add to the position
<jhass> weird
<jhass> meh, the new crystal hangs in the sandbox
waj has quit [Remote host closed the connection]
havenn has quit [Quit: Textual IRC Client: www.textualapp.com]
waj has joined #crystal-lang
<crystal-gh> [crystal] chastell opened pull request #1528: Fix type grammar Int32Ptr example (gh-pages...type_grammar_int32ptr_fix) http://git.io/vnGFf
<crystal-gh> [crystal] jhass closed pull request #1528: Fix type grammar Int32Ptr example (gh-pages...type_grammar_int32ptr_fix) http://git.io/vnGFf
<RX14> doesn't the atom crystal package have autocompletion or something?
<BlaXpirit> RX14, something was written about that recently, yes
<RX14> is it published? usable?
<BlaXpirit> maybe you have an old version of something, or maybe it needs proper configuration, because it calls the crystal process
<RX14> i'm not using atom
<RX14> but i have a friend who wants to try out crystal
<RX14> and they want completion/jump to def if possible
<BlaXpirit> RX14, i have no clue about atom. have you seen this? http://crystal-lang.org/2015/09/05/tools.html
<RX14> thanks!
<willl> jhass: regarding shards and travis: noted. we should open an issue somewhere to track it, but I'm not sure the best spot to do that
<jhass> willl: if we can agree on an approach now we might find out the best place. Another one besides the ones I listed is creating a PPA or similar I guess
sferik has quit [Quit: Textual IRC Client: www.textualapp.com]
<crystal-gh> [crystal] jhass opened pull request #1529: Doc generator: Prefer origin if it's a Github remote (master...docs_repo_detection) http://git.io/vnZv7
<RX14> isn't the 0 prefix for octal a bit easy to accidentally do?
<jhass> that's why we dropped it
<jhass> >> 008
<DeBot> jhass: Syntax error in eval:4: octal constants should be prefixed with 0o - http://carc.in/#/r/g1i
<jhass> RX14: ^
<RX14> then update the docs :P
<jhass> send a PR! :P (I have no clue where we still reference the old way)
<jhass> a, hmpf
<jhass> *ah
<RX14> yes, yes i know
<RX14> i was getting there
<RX14> >> 0b8
<DeBot> RX14: Syntax error in eval:4: unexpected token: 8 - http://carc.in/#/r/g1l
<RX14> >> 008
<DeBot> RX14: Syntax error in eval:4: octal constants should be prefixed with 0o - http://carc.in/#/r/g1m
<RX14> >> 0o8
<DeBot> RX14: Syntax error in eval:4: unexpected token: 8 - http://carc.in/#/r/g1n
<RX14> what am I doing
<RX14> >> 0o08
<DeBot> RX14: Syntax error in eval:4: unexpected token: 8 - http://carc.in/#/r/g1o
<RX14> uhh
<jhass> mmh, no leading 0's I guess
<jhass> >> 0o8
<DeBot> jhass: Syntax error in eval:4: unexpected token: 8 - http://carc.in/#/r/g1p
<jhass> wut
<RX14> bug?
<jhass> mmh
<RX14> so you can't do octal :P
<jhass> maybe that was in 0.7.7? I don't remember
<RX14> but it fails on the old syntax
<RX14> so...
<RX14> it must be
<jhass> ah, I'm dumb
<jhass> >> 0o07
<DeBot> jhass: # => 7 - http://carc.in/#/r/g1v
<RX14> oh dear
<RX14> silly me and you
<jhass> high five!
<RX14> yay!
<crystal-gh> [crystal] RX14 opened pull request #1530: Fix octal syntax in integer docs (gh-pages...patch-1) http://git.io/vnZTK
<jhass> <3
<crystal-gh> [crystal] jhass closed pull request #1530: Fix octal syntax in integer docs (gh-pages...patch-1) http://git.io/vnZTK
<RX14> woah, we have 0.8.0 now?
<BlaXpirit> yes
<RX14> noice
kulelu88 has joined #crystal-lang
nakilon has quit [Ping timeout: 260 seconds]
<RX14> i'm kinda sad about crystal deps going
<RX14> i think that the shard.yml is a vit verbose
<Papierkorb> anyone ever tried to implement a simple sidekiq client or server in crystal?
nakilon has joined #crystal-lang
BlaXpirit has quit [Quit: Konversation]
<jhass> haven't heard of any yet
<jhass> but would be cool
<jhass> and we already got a redis binding
vikaton has joined #crystal-lang
<jhass> dzv: crystal eval gets stuck in https://github.com/manastech/crystal/blob/e363b63c05abc63fc11c407c23507ff144900c45/src/process/waitpid_future.cr#L19 while invoking `uname -a -m` to determine the target triple when run inside playpen :(
<vikaton> hows Crystal going for Windows support
<crystal-gh> [crystal] chastell opened pull request #1531: Simplify Int#bit implementation and spec edge cases (master...simplify_Int#bit) http://git.io/vnZCh
<jhass> ?windows
<DeBot> Windows support is currently developed at https://github.com/xwanderer/crystal/tree/win32/win32
<jhass> looks like xwanderer left us I guess
chino_ has joined #crystal-lang
waj has quit [Remote host closed the connection]
<chino_> hi there
<jhass> hi
<chino_> Think I might have fallen in love with Crystal... it's the static dialect of ruby I always envisioned was possible :] but all the previous attempts like Mirah never really went anywhere?
waj has joined #crystal-lang
<jhass> I guess, I never looked at anything else myself :)
<chino_> have to say little I've read so far I love fact that you have compile time macros, a statically generated binary in the end (like in Go?), compile time checking via type unions, multiple dispatch functions, and what not...
<chino_> the Atom integration seem really nice too, hopefully someone ported it to vim for me :]
<jhass> ?vim
<DeBot> jhass: Nothing known about vim.
<jhass> uh
<jhass> ?vim=You can find a vim plugin for Crystal at https://github.com/rhysd/vim-crystal
<DeBot> jhass: Set vim.
<chino_> you've never used vim?
<jhass> I don't use it as my main editor
<chino_> are you one of the core devs?
<jhass> what we don't do (by default) is statically link everything, which Go does afaik
<chino_> hm
<jhass> mmh, I recently acquired commit rights, but I rather focus on stdlib development
<chino_> """ The compiled output is a standalone executable without any specific runtime dependency. Neat! Isn’t it?
<chino_> I haven't tried it my self yet since I've just started to read a few of the blog posts but thought that line meant it was generating a static binary in the end
<jhass> I think even with the official packages it's not fully static even though they ship most of the deps as static libs
<jhass> but if you have all the static libs available it's pretty much a --link-flags="-static" away I think
<chino_> yea that would be really great to support
<chino_> in the end managing ruby installs across servers can be quiet an effort compared to Go where you can simply compile each program to a binary and deploy it to your infrastructure very easily... compared to alternatives like omnibus
feifan has quit [Quit: Connection closed for inactivity]
<chino_> jhass: hm, i just ran a `crystal build` test on a simple hello world and `dyldinfo -dylibs` seems to show it only depends on /usr/lib/libSystem.B.dylib
trapped has quit [Read error: Connection reset by peer]
<chino_> which unless I did something wrong I think means it's a fully stand alone binary
<chino_> I mean maybe if I start to use some libraries this might change
apt-get_ has quit [Quit: Quit]
<chino_> hm would be interesting if crystal-build supported using mingw to build windows binaries from a linux/osx host
<jhass> we have no windows support yet
<jhass> but you can --cross-compile to supported platforms
<jhass> that'll yield which you need to link with the target libraries, either in a chroot, on the target host or whereever
<jhass> *yield an .o
<jhass> and well yeah, I guess for the hello world example you only catch things the official package ships an .a for ;)
<crystal-gh> [crystal] jhass pushed 3 new commits to master: http://git.io/vnZEz
<crystal-gh> crystal/master 4ddc115 Piotr Szotkowski: Document Int#bit
<crystal-gh> crystal/master 3cc967d Piotr Szotkowski: Simplify Int#bit implementation and spec edge cases
<crystal-gh> crystal/master 0435f7f Jonne Haß: Merge pull request #1531 from chastell/simplify_Int#bit...
<chino_> hm is that simply because the stdlib doesn't support windows?
<jhass> pretty much, yeah
<chino_> not like I'm a windows fan or anything but for making games then windows is a big target
<jhass> there's also adding support for the C ABI I guess
<jhass> ?windows
<DeBot> Windows support is currently developed at https://github.com/xwanderer/crystal/tree/win32/win32
<jhass> but it died down a bit
<travis-ci> manastech/crystal#0435f7f (master - Merge pull request #1531 from chastell/simplify_Int#bit): The build passed. https://travis-ci.org/manastech/crystal/builds/81209035
rvchangue has quit [Ping timeout: 240 seconds]
willl has quit [Quit: Connection closed for inactivity]
<chino_> is there anything like EventMachine right now in crystal?
<chino_> or I guess these days you might say Cellular::IO
<jhass> chino_: well, stdlib IO is evented, that is if you `spawn` a coroutine and an IO operation would block, another, unblocked coroutine is scheduled
<chino_> hm but you still have to start/pump the reactor right?
<jhass> nope
<dzv> jhass: i think #1524 is combined with #1527 it may not hang. the combo basically puts it back to the way it was before
<chino_> like in eventmachine you call EM::run{} or I imagine if it was a library i might say something like IO.pump?
<jhass> dzv: I'm afraid I tried that and it didn't help, it simply hangs on https://github.com/manastech/crystal/pull/1524/files#diff-78351da66abedae60fdba56c431a1910R60 instead
<dzv> how to reproduce?
<jhass> dzv: I think playpen might be getting the signals instead and not proxying them to the child process or something like that, but I'm not good in debugging that stuff, especially the signal_child_handler.cr stuff
<dzv> chino: libevent is used behind the scenes automatically
<jhass> dzv: well, it's a bit of setup, you need to get playpen and a chroot with crystal installed
<jhass> dzv: https://github.com/thestinger/playpen/blob/master/playpen.c it's "just" ~800 loc C, maybe you see something?
<chino_> so I imagine there is hooks into something like libevent timers?
<dzv> yes. sleep
<chino_> I'm still a bit confused on how it's "automatic" though since generally things are single threaded and you want explicit control over the ain program loop
<dzv> spawn { sleep(10); something } # run something in the background after 10s
<chino_> main*
<jhass> dzv: if you have any ideas (on how to fix it|how to debug it|how to get something informative about the issue) I'm happy to try them in my setup and share the results
<dzv> jhass: LibC.printf "#{Process.pid} received signal #{sig}" in signal_handler.cr:handle_signal
<dzv> combined with a similar print inside signal_child_hander.cr:trigger
<dzv> so we can see when the signal is received and when it's picked up by the callback
<jhass> where exactly in trigger? after the waitpid call?
<dzv> chino: the io model is closer to go's. don't do things in the main program loop. spawn fibers and do event handling there. loop { sock = server.accept; spawn { handle_request(sock) } }
<chino_> oh quickly before i forget is there any automatic c header parsers that can auto bind?
<dzv> accept attempts to accept. if EWOULDBLOCK is returned it switches to another runnable fiber. the other fibers do the same when read or write is called
<chino_> i guess i was confused because in ruby Fiber is just a coroutine that you control via yield/resume and not some type of automatically managed greenthread system like in Go/Erlang?
<dzv> jhass: you can try STDERR.puts if you don't see output. stdin may be buffered if the output is a file or pipe
<jhass> chino_: https://github.com/manastech/crystal_lib is currently being brushed up and has some prospect of getting integrated into the compiler, https://github.com/BlaXpirit/crystalize.py for something that spits out source files
<dzv> i'm in a habit of not using STD* since it sometimes fails to compile when working on event/* or concurrent/*
<chino_> cool
ssvb has quit [Ping timeout: 272 seconds]
<jhass> dzv: no output at all with printf, gonna try STDERR next and then LibC.write(2, ...) I guess
<dzv> jhass: 2 more prints may be helpful. signal_handler after_fork and signal_child_handler after_fork
<jhass> dzv: well, I get output outside playpen, so I think playpen just eats the signals
<dzv> oh
<dzv> let me look at playpen
<jhass> the question is where/if or how we can avoid that/whether other more traditional things might do that too (think systemd)
<dzv> what happens with signalfd after forking?
<jhass> I have no idea, hence I pinged you ;)
<dzv> reason for clone vs fork?
<chino_> man crystal_lib is written in ..... python???
<jhass> chino_: huh, no crystal_lib is written in Crystal, crystalize is written in Python
<jhass> dzv: in playpen? I didn't write it
<chino_> still i mean in context of crystal why not use ruby?
<jhass> because BlaXpirit :P
<jhass> we actually have quite a few people coming from the Nim and the like crowd
<chino_> yea Nim seemed interesting
<chino_> I'd still port that to ruby at some point :]
<chino_> or to crystal it self