<yorickpeterse>
cremes: clearly we need to rewrite the VM in Go
<yorickpeterse>
and use Redis for IO handling
<cremes>
yorickpeterse: just what i was thinking.
<jc00ke>
At least there's a nice shout out for Rubinius
<cremes>
seriously, this is why Ruby needs a kick in the ass. why should someone have to switch to Go to get good multithreading support. i wish these guys had tried celluloid out on rubinius….
<cremes>
ruby needs a good actor impl that is part of stdlib
<yorickpeterse>
because Ruby is no longer a thing for hipsters
<yorickpeterse>
it's too mainstream nowadays
<yorickpeterse>
people want to actually earn money with it, instead of circlejerking on HackerNews
<yorickpeterse>
also MRI sucks at multi-threading, which puts a lot of people off
<|jemc|>
cremes: I think it's hard to do actors right in ruby without good builtin support for deep freezing or thread ownership transfer semantics - so let's start there
<cremes>
|jemc|: yes, let’s start there. i have it on good authority that we might see immutable strings sometime in the near future which will help us down that path.
<cremes>
found and fixed a segv in rbx ffi support. pointed me to another bug. down the rabbit hole we go!
<|jemc|>
it frustrates me that in ruby it's hard for an actor framework to make sure that user-code actors actually end up "disowning" the objects they send instead of squirreling them away internally
<|jemc|>
that is, I'd rather not freeze everything if I could just steal your reference to it and be sure you didn't still hold one
<yorickpeterse>
freeze is dumb as a brick
<yorickpeterse>
all the pain of immutability, zero of the benefits
<|jemc|>
some builtin concept of raising exceptions on violation of thread ownership would be a big step in the right direction
<|jemc|>
you could monkey patch that in, but all it does in enforce safety - if the VM knew about thread ownership it could start making some interesting guarantees / optimizations
<cremes>
note to self, don’t try to pass a negative length to memset; it will SEGV the vm.
<|jemc|>
heh
<|jemc|>
cremes: I ran into an interesting unexpected FFI issue today
<cremes>
|jemc|: and?
<|jemc|>
my callback FFI:Functions that I was passing into C and not keeping a ruby reference to were getting garbage collected
<|jemc|>
which C didn't like :D
<|jemc|>
that was my FFI note to self for the day
<cremes>
haha, i did that once too. :)
|jemc| has quit [Ping timeout: 272 seconds]
<brixen>
I've got 7 time-related failures on freebsd
<brixen>
I wonder if these are bad (platform dependent) specs
goyox86_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nirvdrum__ has quit [Ping timeout: 245 seconds]
|jemc| has joined #rubinius
nirvdrum has joined #rubinius
|jemc| has quit [Quit: WeeChat 1.0.1]
|jemc| has joined #rubinius
nirvdrum has quit [Ping timeout: 245 seconds]
johnmuhl has joined #rubinius
craigp has joined #rubinius
<djellemah>
cremes: thanks for confirming. There are tests in MRI. Can I just copy them across to rubysl-thread?
<cremes>
djellemah: i recommend asking brixen, yorickpeterse or jc00ke that question. i’m not qualified to answer. :)
<brixen>
djellemah: we don't import MRI tests, but you could certainly use them to write some specs
<brixen>
use them as inspiration
<brixen>
require "thread" to get Queue is so not surprising also
<|jemc|>
sometime I'd like to look at providing a Rubinius-optimized version of Queue that uses Rubninius::Channel directly instead of the Mutex mess internally
<|jemc|>
(I'd also like to benchmark it to see if it actually helps :P )
<brixen>
both sound like great ideas!
<brixen>
dmilith: ok, I've got a fix-ish for your Readline issue
<brixen>
dmilith: I've removed rb-readline/readline from the deps for rubysl-irb
<brixen>
rubysl-readline appears to work fine on freebsd
<brixen>
so, I'll move the dep into the build and if you build on freebsd (at least) you'll get rubysl-readline
craigp has quit [Remote host closed the connection]
noop has joined #rubinius
craigp has joined #rubinius
pietr0 has joined #rubinius
flavio has quit [Quit: WeeChat 1.0]
yxhuvud has joined #rubinius
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #rubinius
yxhuvud has quit [Remote host closed the connection]
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
yxhuvud has joined #rubinius
djellemah_ has joined #rubinius
djellemah_ has quit [Client Quit]
djellemah_ has joined #rubinius
slaught has quit [Quit: slaught]
craigp has quit [Remote host closed the connection]
djellemah_ has quit [Quit: Leaving]
slaught has joined #rubinius
<dmilith>
cool
<dmilith>
<3
craigp has joined #rubinius
lbianc has quit [Read error: Connection reset by peer]
meh` has joined #rubinius
goyox86 has joined #rubinius
goyox86_ has joined #rubinius
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
goyox86_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
josh-k has quit [Remote host closed the connection]
Bwild has joined #rubinius
heroux has quit [Ping timeout: 272 seconds]
heroux has joined #rubinius
craigp has quit [Remote host closed the connection]
goyox86 has joined #rubinius
goyox86_ has joined #rubinius
goyox86_ has quit [Read error: Connection reset by peer]
goyox86_ has joined #rubinius
craigp has joined #rubinius
goyox86_ has quit [Read error: Connection reset by peer]
goyox86_ has joined #rubinius
craigp has quit [Ping timeout: 264 seconds]
goyox86_ has quit [Read error: Connection reset by peer]
craigp has joined #rubinius
goyox86_ has joined #rubinius
goyox86_ has quit [Read error: Connection reset by peer]
goyox86_ has joined #rubinius
<yorickpeterse>
Argh, fucking rb_block_call is a disaster
<yorickpeterse>
apparently the last "extra data" argument must be a VALUE
<yorickpeterse>
ffs who came up with this
<yorickpeterse>
and here I was trying to make my parser not have an internal state, seems there's no way around that :/
<yxhuvud>
is that the block argument? or what is it used for?
<yorickpeterse>
VALUE rb_block_call(VALUE recv, ID mid, int argc, VALUE * argv, VALUE (*func) (ANYARGS), VALUE data2)
<yorickpeterse>
here data2 is just some extra arg you can passs in
<yorickpeterse>
but it must be a VALUE, opposed to it just using fucking void*
<yorickpeterse>
so unless I can still give it a void* I must move a lot of stuff over to using Data_Get_Struct & friends
havenwood has quit [Remote host closed the connection]
<[spoiler]>
yorickpeterse, you can give it a NULL I think
<[spoiler]>
oh nvm
<[spoiler]>
I misread
havenwood has joined #rubinius
<[spoiler]>
no wait, data2 can be NULL, iirc?
<[spoiler]>
unless you want to pass a value
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #rubinius
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #rubinius
<yorickpeterse>
I _want_ a value for it, I can probably cast it to a void*
<yorickpeterse>
but first I need to check if rbx would barf on that
Thijsc has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
diegoviola has joined #rubinius
<yorickpeterse>
lel apparently MRI just lets you cast it to a VALUE
<yorickpeterse>
but it crashes on Rbx :<
<yorickpeterse>
fffff
johnmuhl has quit [Quit: Connection closed for inactivity]
goyox86_ has quit [Read error: Connection reset by peer]
goyox86_ has joined #rubinius
<brixen>
you can't cast a random pointer to a VALUE on rbx
<brixen>
a VALUE is a reference to practically any region of memory in MRI
<yorickpeterse>
Yeah I figured it wouldn't let me commit a crime like that
<brixen>
usually it should have the expected structure, but you can get away with a ton of broken shit
<yorickpeterse>
well, seems the solution here is more Data_Get_Struct/Data_Wrap_Struct
<yorickpeterse>
ughhh
<brixen>
like reading random bits from an allocated chunk
<brixen>
in rbx, a VALUE is a handle
<yorickpeterse>
tl;dr: C code needs to call a Ruby block while having access to some C objects created before said call
<yorickpeterse>
I was hoping to do this all inline in a C function, removing the need for an internal state (thus making it thread-safe), but blegh
<brixen>
why can't you pass the state in?
<yorickpeterse>
The state isn't a Ruby object
<yorickpeterse>
it's a C struct
<brixen>
these are two distinct things
<yorickpeterse>
(unless I missed the part where you can give arbitrary objects somehow to a callback for rb_block_call)
<brixen>
1. you can make a Ruby method interface to any non-Ruby state
<brixen>
2. you can have state, whether Ruby objects or C structs, that you pass in
<brixen>
as opposed to global state, which is the thread-safety issue
<brixen>
most things don't work with arbitrary anything
<brixen>
so, no, that's not likely a solution
<[spoiler]>
bye peeps
[spoiler] has quit [Quit: I'm running to save my life!]
craigp has quit [Remote host closed the connection]
<yorickpeterse>
brixen: I fail to see how rb_block_call() lets me pass in arbitrary C types though
<yorickpeterse>
That is, I'm looking for something like this:
unreal has quit [Remote host closed the connection]
<brixen>
you can make a Ruby interface to anything with the data wrap struct stuff
<yorickpeterse>
I know, but I was hoping not to need more of that
GitHub24 has joined #rubinius
<GitHub24>
[rubinius] chuckremes pushed 2 new commits to ffi-io: http://git.io/39lEVQ
<GitHub24>
rubinius/ffi-io 6a0742e Chuck Remes: specs for requesting a negative-sized pointer which causes SEGV
<GitHub24>
rubinius/ffi-io c936f67 Chuck Remes: return NULL for a MemoryPointer.new with a negative size
GitHub24 has left #rubinius [#rubinius]
<goyox86_>
Good
<goyox86_>
Good work @cremes
<goyox86_>
!
<goyox86_>
@cremes How is the ffi-io going?
unreal has joined #rubinius
<cremes>
goyox86_: not much to report since yesterday. chipping away at it piece by piece.
<yorickpeterse>
you mean byte by byte? :>
<yorickpeterse>
*badum tsh*
Bwild has quit [Ping timeout: 255 seconds]
Bwild has joined #rubinius
noop has quit [Ping timeout: 256 seconds]
<cremes>
heh
<cremes>
ugh, #read_to_separator_with_limit is the latest bane of my existence.
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #rubinius
<yorickpeterse>
while we're at it: rb_gc_mark() can be used to mark a Ruby object in case it's stored somewhere in C, how does MRI/Rbx know when to actually free said object again?
<yorickpeterse>
or do you have to free it manually?
<brixen>
yorickpeterse: if you attach a free function, it will be called by the finalizer when that object is no longer referenced
<brixen>
so, the lifetime of the C data will mirror the lifetime of the Object
<brixen>
however, that doesn't need to be true
<brixen>
if the C data should persist, don't attach a free function (pass NULL)
<yorickpeterse>
In this case I have a struct that contains a VALUE (an array), if said struct is free'd then the VALUE will also be GC'd at some pointer right?
<brixen>
you need a mark function in that case
<brixen>
the GC *only* knows about Ruby objects
<brixen>
if you have a non-Ruby object (some C data), you need to wrap it in a Data object
<brixen>
now, it can be a part of the Ruby object graph
<yorickpeterse>
what I meant is this:
<brixen>
if that C data has a VALUE reference, your mark function must tell the GC about it
<brixen>
the GC knows absolutely nothing about your C structures
<yorickpeterse>
I have a Ruby class, which has some corresponding C functions and an allocator function, this function uses Data_Wrap_Struct to wrap a C struct
<yorickpeterse>
and it associates a free function for said struct
<yorickpeterse>
Said struct contains a VALUE
<brixen>
the GC does not know about your C struct
<brixen>
cannot know
<yorickpeterse>
But so if you mark it, when does the GC know to collect it?
<brixen>
it doesn't
<brixen>
but it also doesn't know that it's reachable
<brixen>
your mark function makes it reachable
<yorickpeterse>
not sure if I'm following
<brixen>
this is where we need free-form drawing tools embedded in IRC
<brixen>
dang, I gatto finish slides
<brixen>
can this wait till tomorrow?
<brixen>
I can draw you a picture that will make it very simple
<yorickpeterse>
Sure
<yorickpeterse>
I'll do some googling and apply sadism in the mean time :P
<brixen>
ok, I'll do that
<yorickpeterse>
(fkn README.ext is as useless as ever)
<brixen>
think of this like a graph where the edges define a relation R(a, b)
<brixen>
where a is an object that references b, another object
<brixen>
a, b being *Ruby* objects
<brixen>
if you want a relation R(a, c), where c is a C struct, you need to wrap c in Data
<brixen>
now your relation is R(a, c') where c' is Data(c)
<yorickpeterse>
Yeah that part I get
<brixen>
if c has a reference to b, then the transitive relation R(a, c') and R(c', b) (giving R(a, b)) is only defined if c' has a mark function that tells the GC about b
<yorickpeterse>
But I was wondering if somehow the CAPI would free embedded VALUEs for me
<brixen>
no, not directly
<brixen>
neither the GC nor the C-API know anything about your C structure
<brixen>
they cannot know
<brixen>
there are two functions that allow your C structure to participate in GC, the mark function and the free function
<brixen>
the mark function tells the GC about Ruby objects that are not reachable (ie no R relation exists)
<brixen>
the free function lets the GC deallocate *non*Ruby objects based on the Ruby object's lifetime
<brixen>
since the VALUE embedded in the C struct isn't reachable by the GC scan, it will be immediately garbage
<brixen>
unless you call the mark function on it
<brixen>
a tracing GC is really simple, it's a transitive closure over a graph
<brixen>
the graph is a set of relations R(a, b)
<brixen>
that's it
<brixen>
if you create a Ruby object for which no such relation R(a, b) exists, it's as good as immediate garbage
<brixen>
sorry, must finish slides
<|jemc|>
(which is what was happening to my FFI::Functions yesterday >_< )
<yorickpeterse>
brixen: np
<brixen>
I'm going to add a feature request to gitter for drawing tools :)
<jc00ke>
brixen: like integration for Google Draw, et al?
<brixen>
jc00ke: interesting idea!
Bwild has quit [Ping timeout: 255 seconds]
Bwild has joined #rubinius
[spoiler] has joined #rubinius
goyox86_ has quit [Read error: Connection reset by peer]
slaught has quit [Quit: slaught]
Bwild has quit [Ping timeout: 245 seconds]
<yorickpeterse>
oh great, I typedef a struct yet gcc complains the type is unknown
<yorickpeterse>
when it very much is there
<yorickpeterse>
ugh, I'm not old enough for C
<yorickpeterse>
but at lesat it's C11 so I can finally use // foo !!
Bwild has joined #rubinius
goyox86_ has joined #rubinius
nirvdrum has joined #rubinius
goyox86_ has quit [Read error: Connection reset by peer]
goyox86_ has joined #rubinius
Bwild has quit [Ping timeout: 264 seconds]
Bwild has joined #rubinius
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
goyox86_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<yorickpeterse>
alksjdlajdlkasdj
<yorickpeterse>
get rb_block_call working, performance goes down the drain
<yorickpeterse>
ffs
jeremyevans has quit [Ping timeout: 245 seconds]
jeremyevans has joined #rubinius
josh-k has joined #rubinius
josh-k_ has joined #rubinius
<yorickpeterse>
heh, it seems that no matter what I try I can't get my parser to be more than 1,5x faster
<yorickpeterse>
compared to Racc
<yorickpeterse>
:<
<yorickpeterse>
Ruby y u no more webscale
josh-k has quit [Ping timeout: 245 seconds]
<yorickpeterse>
also crap, there's a pretty hefty overhead to allocating Data objects
<jc00ke>
yorickpeterse: rewrite it in Go?
<yorickpeterse>
as in, re-using instances (removing the allocations) makes my parser 1,7x faster instead of 1,5 ://
<yorickpeterse>
also, block calls without the performance overhead would be nice
<yorickpeterse>
but hey, I might have my own unicorn soon
<yorickpeterse>
(more likely to happen)
josh-k has joined #rubinius
<yorickpeterse>
heh, even the Ruby profiler now shows only calls of my parser callback code
<yorickpeterse>
That is, the code to run for certain actions
<yorickpeterse>
so basically the parser itself doesn't appear to be the bottleneck anymore, at least according to the profiler