<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
<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 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?
<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
<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
<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
<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>
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
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 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
<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