_protagoras271_ has quit [Remote host closed the connection]
<znz_v>
biff: [ruby-changes:27367] knu:r39419 (trunk): misc/ruby-electric.el: Avoid electric insertion in some cases. - http://mla.n-z.jp/?ruby-changes=27367
<kosaki2>
to prevent resource leak. think when timeout is happen when running ensure clause.
<zzak>
it's like writing: begin; ...; rescue TimeoutError => e; # ...; ensure; # deallocate resource; end
<zzak>
?
<_ko1>
ko1.inject(alcoholic drink)
<_ko1>
#=> red_faced_ko1
<kosaki2>
it doesn't work if TimeoutError was raised when _within_ ensure clause.
<kosaki2>
your code assume TimeoutError is only raised between "begin" and "rescue".
<zzak>
aha
<zzak>
begin; #...; ensure; rescue Exception => e; #...; end is valid?
<zzak>
can you rescue in an ensure block?
<zzak>
haha
<kosaki2>
this is ruby language mistake, I think. but I lost a debate and we decided to keep current semantics.
<kosaki2>
i think you need write ensure; begin; #... ; rescue #...; end
<kosaki2>
i.e. nested begin..rescue.
<zzak>
eww
<kosaki2>
however, ensure; begin don't have a guarantee to run atomically. then current example call handle_interrupt twice.
<kosaki2>
TimeoutError => :never at first and TimeoutError => on_block at second.
<kosaki2>
this is over thinking when assuming current MRI implementation. but we hoped to write generic example.
<kosaki2>
XXX: I wrote Japanish-English.
<kosaki2>
The example worry about too much. because current MRI run atomically "ensure; begin" pair in this situation. but we are not sure all other implementaion does so. and we want to avoid too strong assumption.
<zzak>
kosaki2: it seems verbose, but maybe thats a good thing
<zzak>
the example's assumptions are to provide same functionality across implementations
<kosaki2>
yes.
<zzak>
so: #handle_interupt(TimeoutError => :on_blocking) {} will be executed during blocking i/o for example?
<zzak>
or #: block is executed when timeouterror occurs during blocking i/o operation
<kosaki2>
#handle_interupt(TimeoutError => :on_blocking) mean TimeoutError is only handled when blocking point while running passed block.
<kosaki2>
blocking point is similar blocking i/o. but not equal.
<kosaki2>
currently on_blocking is bound to releasing gvl. then bignum and zlib can be blocking point too.
<kosaki2>
i know this is bad naming. but nobody think up better name.
<zzak>
ok
<zzak>
"any operation that will block the calling thread"?
<zzak>
Then in the TimeoutError => :on_blocking block, any operation that will block the calling thread is susceptible to a TimeoutError exception being raised.
<zzak>
is this correct?
<kosaki2>
yes.
<kosaki2>
the background of on_blocking is simple. When using YARV, each ruby statement divide to multiple yarv instruction. but when using on_block, we can prevent only half of statement ran and got interrupted.
<kosaki2>
> Thread.handle_interrupt(Foo => :bar) { Thread.handle_interrupt(Baz => :qux) {} } the same as Thread.handle_interrupt(Foo => :bar, Baz => :qux) {} ?
<kosaki2>
yes. but one exception
<kosaki2>
formar have a chance to get Baz exception between two handle_interrupt().
<kosaki2>
The intention is to introduce atomic change to multiple exception handling.
<zzak>
the former is like nested begin;rescue;end's
<kosaki2>
yup
<zzak>
i think there should be th#handle_interrupt
<zzak>
it makes sense, since there is th#pending_interrupt?
kosaki8 has quit [Ping timeout: 252 seconds]
<zzak>
kosaki2: do you know about Thread#backtrace_locations ?
kosaki2 has quit [Remote host closed the connection]
kosaki2 has joined #ruby-core
<kosaki2>
sorry, no > backtrace_locations
<zzak>
does it take same [start,length] or range params as #caller_locations?
<zzak>
:(
nokada has joined #ruby-core
<zzak>
_ko1: please see r39430
nokada has quit [Remote host closed the connection]
<znz_v>
biff: [ruby-changes:27379] zzak:r39431 (trunk): test_backtrace.rb: test Thread#backtrace_locations with range - http://mla.n-z.jp/?ruby-changes=27379
kosaki2 has quit [Remote host closed the connection]
kosaki8 has quit [Ping timeout: 252 seconds]
<zzak>
i want to know about Thread::Default
<zzak>
but tim efor sleep
ikst has joined #ruby-core
kosaki2 has joined #ruby-core
kosaki8 has joined #ruby-core
kosaki2 has quit [Remote host closed the connection]
agarie has quit [Remote host closed the connection]
ikst has quit [Remote host closed the connection]
kosaki8 has quit [Ping timeout: 244 seconds]
kosaki8 has joined #ruby-core
kosaki2 has joined #ruby-core
vondruch has joined #ruby-core
kosaki8 has quit [Ping timeout: 256 seconds]
kosaki2 has quit [Remote host closed the connection]
ikst has joined #ruby-core
ikst has quit [Remote host closed the connection]
<marcandre>
zzak: For Exception, it is in vm_method.c, REPLICATE_METHOD(rb_eException, idMethodMissing, NOEX_PRIVATE);
<zzak>
rdoc probably doesn't know about REPLICATE_METHOD
<zzak>
still need to work on backtrace location labels sometime today
<marcandre>
zzak: glad to see you manage to improve the doc
<marcandre>
"This method behaves similarly to Kernel#caller_locations except for a specific thread.", wouldn't "except it applies to a specific thread." be clearer?
<zzak>
yes
<zzak>
i am going to update the params too
<zzak>
since r39431, it does take same arguments as caller_locations
<zzak>
i know it does*
<zzak>
i wasn't totally sure last night
<marcandre>
Then in the ensure block is where you can safely deallocate your resources
<marcandre>
=>
<marcandre>
Then, the ensure block is where we can safely deallocate your resources
<zzak>
thanks!
<marcandre>
Thank you for improving the doc. I still haven't got around understanding the pending interrupt stuff.
<zzak>
marcandre: please check my doc for on_blocking call
<zzak>
i dont fully understand it either
<zzak>
marcandre: thanks to you, i would have missed it if you didn't say anything
<zzak>
we need a good way for documenters to easily get a list of new features from implementers
<zzak>
NEWS file isn't always up to date
<zzak>
pending_interrupt slipped past me because it didn't show up in 'rdoc -C'
<zzak>
thats how i usually find undocumented features
<zzak>
but for new features, that may include docs, is why we need a list
<zzak>
it would be nice to have associated ticket/s too
<marcandre>
For new methods, my script will detect them.
<zzak>
can you turn it into a gem or something?
<zzak>
i will lose a gist
<zzak>
marcandre: also, do you know about Thread::Default?
<marcandre>
For my script, it's much easier to execute as a .rb file than as a gem. Maybe it could be added to tool/? That directory is not part of the final distribution, right?
<zzak>
looks like my local rvm has ./tool under src
<marcandre>
Oh. Anyways, I plan to use it as is, but of course feel free to modify it if you like :-)
<zzak>
marcandre: thanks, a member of #ruby-lang channel reported the <=> doc bugs
<zzak>
marcandre: i like your update, unfortunately theres a lot of *_cmp methods in core
<zzak>
so you might have to check them as well
<zzak>
marcandre: this brings up another issue, a lot of call-seq's and examples we use short version of literal name
<zzak>
like ary, str, flt, etc etc
<zzak>
when i come across these i try to make them full version, like: array, string, float, other_array, other_string, etc etc
<marcandre>
I think the other additions you made a good. I mean, there's no real need to discuss when a Numeric#<=> returns a nil. It's just that it should be clear that two File::Stat are always comparable.
<marcandre>
For Array#<=>, it wasn't clear at all what values we're talking about.
<marcandre>
As for abbreviations, I think the idea is to avoid confusion with some global methods, e.g. "proc.curry"... is proc a variable or a method?
<zzak>
in that case yes
<marcandre>
The distinction between "io.write" and "IO.write" might not be clear either. Both the instance method and the singleton method exists
<marcandre>
Or `Array[1]` vs `array[1]` vs `Array(1)`
<zzak>
haha yeah
<zzak>
but ary is so unclear
<marcandre>
I would recommend to either keep them abbreviated or else go for 'an_array'
<zzak>
i like array, it's not a method
<marcandre>
I'm noticing that the receivers don't even show on http://ruby-doc.org/
<marcandre>
I also disagree with "ary.flatten! -> Array or nil"
<zzak>
yeh ruby-doc.org uses it's own generator
<zzak>
i agree it should use our receivers, but at least they're in ri
<zzak>
formatting core docs is a never-ending struggle
<marcandre>
Do you agree that "ary.flatten! -> Array or nil" is not acceptable?
<marcandre>
I wonder if drbrain didn't notice or if he agreed with all those "an_enumerator -> Enumerator" changes
<zzak>
i think i made that change
<marcandre>
Yeah, it's your patch and drbrain's commit
<zzak>
for some of the returns in array.c, i think i went through and made the return value the class
<marcandre>
In your defense, it was already erroneous "ary.flatten!(level) -> array or nil"
<zzak>
it was an early patch
<marcandre>
drbrain: ping?
kosaki2 has joined #ruby-core
<marcandre>
Wow, there are so many of those now. I don't like it at all, but that may be just me.
<marcandre>
Was that ever discussed on ruby-core?
davidbalber|away is now known as davidbalbert
kosaki2 has quit [Remote host closed the connection]
<zzak>
marcandre: i havent been backporting my doc patches
<marcandre>
but you notified mame, right?
<zzak>
no
<zzak>
only the one patch i backported
<zzak>
i thought it was too close to release
<marcandre>
It would be nice to have the doc patches in the 2.0.0 release, right?
<zzak>
there are too many patches
<zzak>
over 20 patches since the freeze
<zzak>
and more otw
<kosaki2>
backport is no permitted now. mame-san declared at ruby-core several ago.
<marcandre>
kosaki2: we're talking about rdoc only.
<kosaki2>
If it is outside of ruby repo, no matter. sorry for noise.
davidbalber|away is now known as davidbalbert
<marcandre>
mame can revert my commits if he wants. I can not understand why it would be a problem to commit rdoc only changes to 2.0.0 branch. After release, one needs to be careful to change build number, but that's not even the case now.
<zzak>
maybe open backport after release
<zzak>
for next patch level
<zzak>
but i dont want to make a lot of noise for mame, and there will always be more patches
<zzak>
plus i am not that confident in merging with svn
<marcandre>
you're not using git-svn?
<zzak>
no
<zzak>
i have 3 separate right now, trunk, 2_0_0 and git clone
<marcandre>
wow
<marcandre>
using git with git-svn works really well.
<zzak>
it hasnt been a problem until now
kosaki2 has quit [Remote host closed the connection]
<zzak>
plus, i dont really want to manage documentation patches across multiple releases
kosaki2 has joined #ruby-core
<zzak>
mostly because you ahve to open a backport request for every one
<zzak>
otherwise the maintainers lose sleep at night
<marcandre>
_ko1 doesn't appear to sleep, so no problem ;-)
<marcandre>
I agree that opening a backport request for doc patches is insane. IMHO, it should be easy for committers to backport those themselves if they want.
<zzak>
"One we can demonstrate was to make many floats immediates." sounds a little weird to me
<zzak>
its hard to tell your link on "Additional details and examples in the doc of to_enum"
<zzak>
looks like any other code block
<drbrain>
marcandre: pong
<zzak>
marcandre: under "The way to avoid the warning was to use _. Now we can use any variable name starting with an underscore:"
<zzak>
you might want to mention in the 1.9 example the name "_" is not warned
<drbrain>
marcandre: the style of the result in call-seq has never been discussed
<zzak>
at first glance i didn't catch that _ != _hello
<zzak>
drbrain: hello!
<drbrain>
so, I guess we need to make a decision
ortuna has joined #ruby-core
nokada has quit [Remote host closed the connection]
nokada has joined #ruby-core
<zzak>
drbrain: result and object names
<drbrain>
yeah
<zzak>
we were talking about "ary" vs "array" too
<drbrain>
I like full words better
<drbrain>
for the result, I'm unsure if the class name is best or not
<drbrain>
for example, with String#[]
<drbrain>
currently it is str[index] -> new_str or nil
<marcandre>
hi :-) One of the idea behind it all is to stress when the object returned is the receiver or not.
<drbrain>
… then str[regexp] -> new_str or nil
<drbrain>
marcandre: ooh, yes
<marcandre>
but that point is a bit moot on the official rdoc site, where the name of the receiver doesn't even show.
<marcandre>
but maybe `flatten! -> self or nil` is even better
<drbrain>
yes
nokada has quit [Ping timeout: 252 seconds]
<marcandre>
My first reaction to "str[index] -> String or nil" was one of horror, but to be honest I can't think of a single case where it would not be clear what is meant, even if it's not strictly consistent
<_ko1>
おはよう！ good morning!
<marcandre>
In any case, there are like a zillion of them right now, in particular for "-> Enumerator"
<zzak>
_ko1: ohayou
<marcandre>
-ko1: Good morning! Hope you got some sleep at least :-)
<_ko1>
many sleep! thanks
<drbrain>
for my own personal OCD hell, the mixed use of -> and => for the result
<zzak>
i like array.flatten! -> self or nil, and string[index] -> new_string or nil
<drbrain>
I made rdoc turn them both into unicode arrows, but it still bugs me
<zzak>
not sure beginners fully understand "self" tho
<drbrain>
I have some parts of the syntax guides that say, essentially, "these are the definitions for the terms that follow"
<drbrain>
we could have the same in the README
<marcandre>
drbrain: at least, this way we can have => be strict, like in irb, when -> means something else.
<drbrain>
for "string[index] -> new_string or nil", why not "new string" instead
<drbrain>
marcandre: hrm, that is a nice proposal
<marcandre>
I expect " x.class # => Array" to mean that Array is returned, not an instance of Array
<drbrain>
a few weeks ago _ko1 was talking about mixing in automatic tests with rdoc in a natural way
<drbrain>
it seems like -> vs => might be a nice hint
<marcandre>
And " x.class -> Class" could mean that an instance of Class is returned.
<drbrain>
bbiab, I'm going to hang some curtains
<_ko1>
> Unused variables can start with _
<_ko1>
Ah, I missed this feature
<marcandre>
#6693
<zzak>
marcandre: add your blog post to the announcement
<_ko1>
zzak: ++
<_ko1>
> One we can demonstrate was to make many floats immediates
<_ko1>
only on 64bit CPU
nari has joined #ruby-core
<marcandre>
_ko1: Right, forgot that. Will add to my blog.
<zzak>
is there any doc for Flonum?
<marcandre>
I added my post to the wiki
hsbt has joined #ruby-core
<zzak>
marcandre: btw, i think i forgot to thank you for the feedback on #backtrace_locations :D
<marcandre>
don't mention it
<marcandre>
zzak: I don't think there is a doc, but I don't think that there should; it's completely implementation dependant