hsbt_away changed the topic of #ruby-core to: check the latest release candidate for 1.9.1 release ftp.ruby-lang.org:/home/yugui/ruby-1.9.1-r26021+1.tar.bz2
tylersmith has joined #ruby-core
xibbar has joined #ruby-core
xibbar has quit [Remote host closed the connection]
xibbar has joined #ruby-core
nagachika has joined #ruby-core
nagachika has quit [Remote host closed the connection]
nagachika has joined #ruby-core
shiba has joined #ruby-core
tylersmith has quit [Remote host closed the connection]
shiba has quit [Ping timeout: 264 seconds]
idkazuma has quit [Remote host closed the connection]
shiba has joined #ruby-core
idkazuma has joined #ruby-core
<zzak>
ping
r0bgleeson has quit [Ping timeout: 245 seconds]
<zzak>
znz_v: commit bot sleeping?
yugui_zzz_ is now known as yugui
shiba has quit [Ping timeout: 276 seconds]
r0bgleeson has joined #ruby-core
tylersmith has joined #ruby-core
tylersmith has quit [Ping timeout: 252 seconds]
idkazuma has quit [Remote host closed the connection]
DanKnox_away is now known as DanKnox
Domon has joined #ruby-core
DanKnox is now known as DanKnox_away
shiba has joined #ruby-core
tarui has quit [Quit: Quit Nadoka 0.8.2-trunk (-)]
nagachik_ has joined #ruby-core
tarui has joined #ruby-core
charliesome has joined #ruby-core
nagachika has quit [Ping timeout: 248 seconds]
marcandre has joined #ruby-core
nagachika has joined #ruby-core
nagachik_ has quit [Ping timeout: 255 seconds]
tylersmith has joined #ruby-core
shiba has quit [Ping timeout: 245 seconds]
Domon has quit [*.net *.split]
closer has quit [*.net *.split]
marcandre has quit [*.net *.split]
Guest70117 has quit [*.net *.split]
tarui has quit [*.net *.split]
tarui has joined #ruby-core
closer has joined #ruby-core
marcandre has joined #ruby-core
Domon has joined #ruby-core
Guest70117 has joined #ruby-core
Domon has quit [Remote host closed the connection]
tarui has quit [*.net *.split]
closer has quit [*.net *.split]
marcandre has quit [*.net *.split]
Guest70117 has quit [*.net *.split]
tarui has joined #ruby-core
marcandre has joined #ruby-core
closer has joined #ruby-core
Guest70117 has joined #ruby-core
nari_ has joined #ruby-core
Domon has joined #ruby-core
wudofyr_ has quit [Ping timeout: 256 seconds]
nari_ has quit [Ping timeout: 276 seconds]
xibbar has quit [Remote host closed the connection]
nagachika has quit [Remote host closed the connection]
nagachika has joined #ruby-core
tylersmith has quit [Remote host closed the connection]
kosaki8 has joined #ruby-core
xibbar has joined #ruby-core
tylersmith has joined #ruby-core
tylersmith has quit [Ping timeout: 246 seconds]
nagachik_ has joined #ruby-core
nagachika has quit [Ping timeout: 252 seconds]
eLobato has joined #ruby-core
nagachik_ has quit [Remote host closed the connection]
xibbar has quit [Remote host closed the connection]
corundum has quit [Disconnected by services]
corundum has joined #ruby-core
hiroyuki3 has joined #ruby-core
kbsa__ has joined #ruby-core
kbsa has quit [*.net *.split]
hiroyuki2 has quit [*.net *.split]
pdswan_ has quit [*.net *.split]
guilleiguaran__ has quit [*.net *.split]
pdswan_ has joined #ruby-core
guilleiguaran__ has joined #ruby-core
krombr has quit [Quit: krombr]
pdswan_ has quit [*.net *.split]
guilleiguaran__ has quit [*.net *.split]
pdswan_ has joined #ruby-core
guilleiguaran__ has joined #ruby-core
flori_ is now known as flori
flori has quit [Quit: leaving]
flori has joined #ruby-core
charliesome has joined #ruby-core
nokada_ has joined #ruby-core
nokada has quit [Ping timeout: 240 seconds]
Domon has quit [Remote host closed the connection]
nagachik_ has joined #ruby-core
nghialv2607 has joined #ruby-core
nagachika has quit [Read error: Connection reset by peer]
judofyr has quit [*.net *.split]
tarui has quit [*.net *.split]
closer has quit [*.net *.split]
marcandre has quit [*.net *.split]
Guest70117 has quit [*.net *.split]
dbussink has joined #ruby-core
<dbussink>
_ko10: if http://bugs.ruby-lang.org/issues/8399 isn't clear enough yet, feel free to ask more details or we can discuss quickly here if you want
<_ko10>
hi
<_ko10>
thank you for your detail message
<dbussink>
hopefully my proposal is clear now
<_ko10>
basically i agree with you
<dbussink>
basically the biggest thing is that extensions in ext/ aren't all just for mri, but also used outside
<dbussink>
so imho they should try to play nice as much as possible and not depend on internals etc
<dbussink>
_ko10: ok, cool!
judofyr has joined #ruby-core
Guest70117 has joined #ruby-core
marcandre has joined #ruby-core
closer has joined #ruby-core
tarui has joined #ruby-core
travis-ci has joined #ruby-core
travis-ci has left #ruby-core [#ruby-core]
<_ko10>
please give me a time to read your message
<_ko10>
basically, first three paragraph, maybe we think same.
<dbussink>
_ko10: ok, well, since you're working on generational gc stuff as well, hopefully the concerns are clear. personally i'd love to be able to remove RARRAY_PTR altogether but i can understand not doing that
<dbussink>
but i think it should be a longer term goal to remove it
<_ko10>
i agree
<_ko10>
what's the different from (1) and (2)?
<_ko10>
provide RARRAY_AREF or not?
<dbussink>
_ko10: (1) basically says removing occurrences of RARRAY_PTR() with rb_ary_entry / rb_ary_store etc.
<dbussink>
and not depending on the introduction of RARRAY_AREF
<_ko10>
i see
<dbussink>
which means it doesn't require updates to 1.9 and 2.0
<_ko10>
i agree that there are no performance issue using rb_ary_entry
<dbussink>
so in that case I would only do back port changes to the extensions themselves
<_ko10>
for 95%
<dbussink>
i've never seen it matter
<_ko10>
mathematic application, and so on
<dbussink>
and this is only for ext/ stuff
<_ko10>
s/application/lib/
<dbussink>
not for the VM itself
<_ko10>
yes.
<_ko10>
maybe, we are now (2).
<_ko10>
i don't against that you (and rubyist) suggest rb_ary_*
<dbussink>
right, well, (2) would require back porting the macro's to 1.9 / 2.0 etc.
<dbussink>
well, i think that extensions in ext/ should also try to follow the patterns that are recommended
<_ko10>
dbussink: Yes. and I want to ask to backport them.
<dbussink>
if rb_ary_entry is the recommended way to do it, i think extensions in ext/ should use that
<_ko10>
or provide foo.h which include def of RARRAY_AREF() for c-ext authors
<dbussink>
because people look at it as an example of how to write c extensions
nghialv2607 has quit [Remote host closed the connection]
<dbussink>
so coding patters found there will be duplicated
<_ko10>
i don't against it
<dbussink>
_ko10: for extensions that really need RARRAY_AREF because of performance or other concerns, they can of course use it
<_ko10>
at least, they can replace with RARRAY_AREF()
<_ko10>
zzak: ko-ten
<dbussink>
_ko10: true yeah, that can work as well, but that leaves the backporting situation I would like to solve for extensions we also use in Rubinius
<dbussink>
and we would like to ship the MRI 1.9 version with our 1.9 mode
<dbussink>
and 2.0 with 2.0 etc.
nghialv2607 has joined #ruby-core
<_ko10>
i see
<_ko10>
dbussink: BTW, how about RSTRING_PTR?
<dbussink>
_ko10: that is more tricky yeah, we have similar support stuff for that actually for if people change the string
<_ko10>
interesting. any documents?
<dbussink>
_ko10: for Rubinius you can add a define that basically says you play nice with strings
<dbussink>
so if you do a #define RSTRING_NOT_MODIFIED in the extension, it says that you don't modify it but just read the data
<_ko10>
ah cool
<dbussink>
but it would be nice to have explicit support for that
<_ko10>
and there are assumption most exts doesn't modify RSTRING_PTR()
<dbussink>
a lot of them don't no
<_ko10>
yes.
<dbussink>
we have rb_str_ptr_readonly which is used then
<dbussink>
but having explicit ways to specify this in the api itself would help
<_ko10>
however
<_ko10>
if rb_str_ptr_readonly() returns the pointer,
<_ko10>
we can't move the string body from this pointer.
<dbussink>
but rstring_ptr doesn't suffer from having to scan for pointers for the write barrier
<dbussink>
right
<dbussink>
we have a pin flag in rubinius
<dbussink>
which is set in an object then which says to the gc, don't move this object around
<_ko10>
next of rgengc,
<_ko10>
i want to make compaction memory management
<_ko10>
so i need to know the lifetime of ptr.
<dbussink>
right, but you probably need something like pinning then
<_ko10>
So, i want to replace them with RSTRING_PTR_USE similar to RARRAY_PTR_US
<dbussink>
and if it's active in the lifetime it isn't allowed to be moved
<_ko10>
RARRAY_PTR_USE(ary, ptr, {code using ptr})
<dbussink>
basically in rubinius we have a frame object around C extension calls
<_ko10>
dbussink: yes. pinned down only while a block
<dbussink>
where we track the handles that are allocated during that call
<dbussink>
so we also unpin after that
<dbussink>
so pinning is not permanent
<dbussink>
so it ends up doing the same, without having a need for a user api then
<_ko10>
dbussink: but there are no guarantee that ptr doesn't escape from frame.
<dbussink>
it that case if we deref them when we return we see it's not unused
<_ko10>
glboal_variable_ptr = RSTRING_PTR(xxx);
<dbussink>
we don't support that
<_ko10>
reasonable :)
<dbussink>
i think mri should say no to things like that as well
<_ko10>
i want to prohibit :)
<dbussink>
yay :)
<dbussink>
_ko10: you're also going to be at euruko right?
<_ko10>
so RSTRING_PTR_USE(...) is one propoasl to do that.
<_ko10>
dbussink: yes.
<_ko10>
you too?
<dbussink>
yeah, giving a talk as well
<_ko10>
sure. good time to discuss
<judofyr>
_ko10: slightly related: have you looked more at making regular classes play well with RGenCC?
<dbussink>
_ko10: anything thing btw is thread safety and C extensions, already put in a patch for openssl for that
<dbussink>
but that's a different topic :)
<_ko10>
judofyr: do you mean that making classes as sunny objects?
<judofyr>
_ko10: yes
<judofyr>
_ko10: or, making instances of Ruby classes as sunny objects (or are they already?)