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
shinnya has quit [Ping timeout: 245 seconds]
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
nagachika has joined #ruby-core
nagachika has quit [Remote host closed the connection]
nagachika has joined #ruby-core
soba has quit [Ping timeout: 240 seconds]
soba has joined #ruby-core
nari has joined #ruby-core
charliesome has joined #ruby-core
<felipec>
charliesome: what do you think about this?
<dbussink>
anyone around who could answer a question about what the exact use case is of rb_obj_hide and rb_obj_reveal?
<dbussink>
i see it used in a bunch of places, but honestly have no idea what they mean
<dbussink>
since they just seem to clear klass and restore it
<znz_jp>
biff: [ruby-changes:31094] ko1:r43173 (trunk): * test/-ext-/debug/test_profile_frames.rb: rename class C to - http://mla.n-z.jp/?ruby-changes=31094
<dbussink>
_ko1: looks like you added it, could you please explain it?
<znz_jp>
biff: [ruby-changes:31104] knu:r43183 (trunk): Make ruby-electric play nicely with smartparens-mode. - http://mla.n-z.jp/?ruby-changes=31104
nari has quit [Ping timeout: 268 seconds]
<znz_jp>
biff: [ruby-changes:31105] knu:r43184 (trunk): * misc/ruby-additional.el: Add a standard header and footer, - http://mla.n-z.jp/?ruby-changes=31105
<tenderlove>
then people could backport the method to 2.0 (where it would be a noop)
<tenderlove>
(or just call freeze)
<dbussink>
_ko1: just saw your tweet, so question is basically what rb_obj_hide() and rb_obj_reveal() are for, since i couldn't find that out from the source :(
<enebo>
I am all for it, but I would also like Ruby to change semantics for freeze can never be overriden
<tenderlove>
then you could sidestep the issue of people overriding `freeze`
<headius>
tenderlove: well there's the other feature for String#frozen to use the internal fstring table
<dbussink>
_ko1: as in, i understand what they do, but i don't understand why
<headius>
#frozen could be added as a new method nobody has ever overridden, explicitly using fstring table (unlike freeze), easy to backport (just alias freeze) and with explicit support for compiler optz
<tenderlove>
headius: yes
<headius>
"str".frozen
<headius>
or some other name… I think they were considering .pooled, but I don't think that makes the frozen nature explicit enough
<tenderlove>
frigid
<headius>
you can have pooled mutable objects
<enebo>
another name does solve the issue
kosaki2 has quit [Ping timeout: 246 seconds]
<headius>
"str".iced
<headius>
this is bikeshedding that can occur in the backup plan to just making .freeze do this logic
<tenderlove>
confirm
<enebo>
"hello".rimy
<tenderlove>
"str".vanilla_iced
<headius>
tenderlove: I thought about unary operators too
<headius>
^"str"
<enebo>
we could introduce western programmers to the kanji for frozen
<headius>
or whatever
<eam>
I seem to have found a bug involving SIGTERM and IO.popen when called with a block. Is this the right place to ask for help re: the ruby internals?
<headius>
~"str"
<headius>
alias ~ freeze on older impls
<eam>
ruby appears to set a signal handler which deadlocks
<headius>
it's like snow
<headius>
:-D
<enebo>
\"frozen"
<tenderlove>
oh, I like the unary op
<headius>
there's others but I liked ~ best
<headius>
if only * could be a unary operator… we could call it the snowflake
<headius>
I'm going to try to open an issue for .freeze instead of "str"f
<eam>
the issue I've found is: ruby -e'puts $$; IO.popen("sleep 60") { |f| f.read}' # send this a TERM while it's waiting to read, the first term hits a signal handler which fails to properly raise. A second term will kill it
kosaki2_ has quit [Remote host closed the connection]
<headius>
tenderlove: we have made changes over time that make it harder to cause but I think many threads all reading and writing will do it
<headius>
mostly the problem occur when it has to resize
ZachBeta has joined #ruby-core
shinnya has quit [Ping timeout: 240 seconds]
<tenderlove>
headius: I see. I want to try to demo AR objects no being thread safe.
<headius>
ahh…yeah it would have been easy to show a year ago but a contrib pointed out we could synchronize just resizing and eliminate a large class of problems