kosaki2 has joined #ruby-core
<znz_v> biff: [ruby-changes:27114] drbrain:r39166 (trunk): * lib/rubygems/package/old.rb: Fix behavior only on ruby 1.8. - http://mla.n-z.jp/?ruby-changes=27114
<znz_v> biff: [ruby-changes:27115] ktsj:r39167 (trunk): * BSDL: update copyright notice for 2013. - http://mla.n-z.jp/?ruby-changes=27115
kosaki2 has quit [Remote host closed the connection]
kosaki2 has joined #ruby-core
kosaki2 has quit [Ping timeout: 246 seconds]
idkazuma has joined #ruby-core
idkazuma has quit [Ping timeout: 255 seconds]
nari has joined #ruby-core
nari has quit [Ping timeout: 240 seconds]
drbrain has quit [Ping timeout: 264 seconds]
Hanmac1 has joined #ruby-core
Hanmac has quit [Ping timeout: 264 seconds]
charliesome has joined #ruby-core
drbrain has joined #ruby-core
davidbalbert is now known as davidbalber|away
kosaki2 has joined #ruby-core
kosaki2 has quit [Ping timeout: 248 seconds]
nokada has quit [Remote host closed the connection]
knu has quit [Ping timeout: 256 seconds]
knu has joined #ruby-core
<zzak> _ko1: here?
<_ko1> yes
<zzak> mame1: or yusuke-san?
<_ko1> wakeup now
<zzak> i have question re ruby-core:52034
<zzak> i want to commit doc fixes
<zzak> should i commit to trunk, or ruby_2_0_0 branch?
<_ko1> zzak: you need mame-san's approval
<zzak> what about tracepoint docs, we discussed earlier?
<_ko1> commit to trunk and get approval.
<zzak> ok
<zzak> _ko1: also, おはよう！
<_ko1> おはよう！
<_ko1> sorry I need to propose this doc issue erlier
<_ko1> i'm writing Japanese article about TracePoint and i remember about that
<zzak> np
<zzak> doc is ongoing task
nokada has joined #ruby-core
<zzak> _ko1: i want to read about tracepoint :)
<_ko1> RubyVM advent calendar
<_ko1> and I got specification problem
<_ko1> TracePoint#enable with block should be affect on target thread only
<_ko1> it is pecification bug.
<_ko1> now, trace.enable{...} affect all of threads
<_ko1> but it should be restricted to current thread only
<zzak> only with block?
<_ko1> only with block.
<_ko1> and only with in current thread
<_ko1> created thread in the block "trace.enable{ ... Thread.new{...} ...}" can inherit tracing
knu has quit [Ping timeout: 257 seconds]
<_ko1> but independent threads should not be affected
<_ko1> I want to change spec but it is too late to discuss...
<_ko1> too sad
<zzak> i like your idea
<zzak> but i think its still early and change wont affect so many people
<zzak> noone knows tracepoint yet :)
<_ko1> after 2.1?
<_ko1> or bug fix patch release?
knu has joined #ruby-core
<_ko1> expand TracePoint#enable is good idea
<_ko1> enable(target_thread)
<_ko1> or
<_ko1> enable() # all thread
<zzak> i think patch release
<zzak> sooner the better
<_ko1> no compatibility issue
<zzak> right
<_ko1> thank you. i'll propose this extension
<zzak> double check with yusuke-san tho
<zzak> ok :)
<_ko1> thanks!
<zzak> _ko1: I forgot to update Thread#set_trace_func
<zzak> this is also obsolete, right?
<_ko1> ah,,,
<_ko1> I think so. but we don't have consensus
<zzak> it's same as set_trace_func() but given thread pointer
<_ko1> thread pointer?
kosaki2 has joined #ruby-core
<zzak> set_trace_func uses rb_add_event_hook
<_ko1> yes
<zzak> and Thread#set_trace_func uses rb_threadptr_add_event_hook
<_ko1> thread is Thread#set_trace_func
<_ko1> yes.
<zzak> both use connect_event_hook
<zzak> rb_add_event_hook uses &GET_VM()->event_hooks and rb_threadptr_add_event_hook uses &th->event_hooks
<_ko1> yes
<zzak> same implementation only one uses all threads and other uses target thread
<zzak> they are both obsolete imo
<_ko1> obsolte C API?
<_ko1> or set_trace_func/Thread#set_trace_func ?
<zzak> B
<_ko1> B means latter ?
<zzak> yes
<_ko1> i see
<zzak> api is fine
<_ko1> i agree with you
<zzak> you can reproduce these in tracepoint tho
<zzak> but i dont know how to use tracepoint on target thread
<zzak> _ko1: within enable block, right?
<_ko1> zzak: exactly, we lack the API to specify thread
<_ko1> enable(target_thread) or enable(target_thread) do...end
<_ko1> will be fine
<_ko1> and it has no compatibility issue
<_ko1> (because it is expansion)
<zzak> target_thread already running?
<_ko1> one problem is
<_ko1> trace.enable(Thread.current) do ...; trace.enable; ... end
<_ko1> what happen on this example
<_ko1> (already enabled on thread, and enable on all of threads)
<zzak> what about, instead of Thread.current, you use thread_b?
kosaki2 has quit [Remote host closed the connection]
<_ko1> yes.
<zzak> _ko1: can you show me an example? starting a new thread, and then tracepoint an event on given thread
<_ko1> we need consideration
<zzak> can we do this with current api?
<_ko1> th = Thread.new{...}; trace.enable(th)
knu has quit [Ping timeout: 256 seconds]
<zzak> :(
carlosantonio has quit [Remote host closed the connection]
<zzak> _ko1: does TracePoint.new require block?
davidbalber|away is now known as davidbalbert
<_ko1> yes
<zzak> ahh, i was doing TracePoint.new.enable {} is why
<_ko1> ?
knu has joined #ruby-core
<zzak> it was mistake
<_ko1> your question is enable should need block?
<zzak> my question is how to use tracepoint on target thread
<zzak> trace.enable(th) is unimplemented
<_ko1> yes.
<_ko1> so we need feature request with a patch
<_ko1> just now, no way to do it
<zzak> in that case, Thread#set_trace_func still preferred way to do this
<_ko1> only way just now
<_ko1> (except using C API)
<znz_v> biff: [ruby-changes:27116] zzak:r39168 (trunk): * vm_trace.c: Note about TracePoint events set, and comment on - http://mla.n-z.jp/?ruby-changes=27116
<_ko1> ah
<_ko1> so I think it is too strong message that set_trace_func is obsolete
<_ko1> *I* think so, but i'm not sure everyone sae
<_ko1> same
idkazuma has joined #ruby-core
<_ko1> + * See TracePoint@Events for more information.
<_ko1> What means? > TracePoint@Events
<_ko1> RDoc notation?
<zzak> rdoc label links
<_ko1> I see.
<zzak> A heading inside the documentation can be linked by following the class or method by an @ then the heading name. RDoc::Markup@Links will link to this section like this: Links at RDoc::Markup. Spaces in headings with multiple words must be escaped with + like RDoc::Markup@Escaping+Text+Markup. Punctuation and other special characters must be escaped like CGI.escape.
<zzak> i think Kernel#set_trace_func is obsolete
<zzak> meaning out of date
<zzak> its older api, and we have new api to do the same thing
<_ko1> i agree with you
<_ko1> almost same :)
<zzak> but better
<zzak> also, we can say obsolete
<zzak> and not mean deprecated
<zzak> because it still has purpose
<zzak> its not harmful in any way
<zzak> just old api
<_ko1> i agree
knu has quit [Ping timeout: 256 seconds]
knu has joined #ruby-core
<zzak> i think theres something wrong with github mirror
<_ko1> i checked your patch and it's perfec
<_ko1> t
<zzak> _ko1: thank you!
<_ko1> yes, github sync causes error
<zzak> :(
<zzak> there goes my 7 day commit streak :(
<zzak> 27 commits in a week
<_ko1> ask evan :)
<evan> something up with it?
<_ko1> github/ruby doesn't update now
<evan> oh no!
<evan> when did it stop?
<_ko1> is not updated ?
<_ko1> i'm not sure
<evan> I haven't checked in a while.
<evan> i'm looking now.
<_ko1> thank you !!
<zzak> evan!
<zzak> :D
<zzak> evan: thank you! someone was also asking about the ruby_2_0_0 branch: https://bugs.ruby-lang.org/issues/7813
<evan> here is the error:
<evan> r39168 = 810516ed20967a69b801b518ef2b2c0dc4184824 (refs/remotes/svn/trunk)
<evan> error: unable to push to unqualified destination: ruby_2_0_0
<evan> The destination refspec neither matches an existing ref on the remote nor
<evan> begins with refs/, and we are unable to guess a prefix based on the source ref.
<evan> error: failed to push some refs to 'git@github.com:ruby/ruby.git'
<_ko1> shyouhei had said that we need some work because of creating 2_0_0 branch
<_ko1> i'm not sure deitals.
<evan> ok
<evan> hm.
<_ko1> [ruby-core:52060] [ruby-trunk - Bug #7813][Open] github mirror missing ruby_2_0_0 branch
<evan> his script I run has a section commented out
<evan> that appears to initialize branches
<evan> i'll run it manually
charliesome has quit [Ping timeout: 246 seconds]
charliesome has joined #ruby-core
<evan> thats a bingo!
<evan> it's a weird edge case in git.
<evan> should be ready to go now.
<_ko1> cool!
kosaki2 has joined #ruby-core
<_ko1> nice prompt > λ
<charliesome> cheers :p
<_ko1> ah, you finished?
<charliesome> still need to make sure it hasn't broken anything
<charliesome> test it thouroughly
<_ko1> cool
<_ko1> difficult to test
<charliesome> yeah. i figure make test-all then the rails tests should do it
<_ko1> we need *how to test it*
<_ko1> consideration
<_ko1> error proof framework
<charliesome> for everything or this patch in particular?
<_ko1> this patch
<charliesome> sure thing
<_ko1> maybe this bug is very rare
<_ko1> bug is very rare
<charliesome> i have a concern that refinements may cause an issue with this
<charliesome> i don't know enough about how refinements are implemented to tell
<_ko1> me too :)
<charliesome> also i had another idea
<charliesome> what if there was a rb_funcall_cache() that let you do method caching in C code
<_ko1> there is global cache alredy
<charliesome> oh i wasn't aware
<charliesome> how does it work?
oscardelben has joined #ruby-core
<_ko1> there is big table
<charliesome> so it still requires a hashtable lookup?
<_ko1> key is [klass, id, vm state] and value is [method body]
<_ko1> static struct cache_entry cache[CACHE_SIZE];
<_ko1> in vm_method.c
<charliesome> ah
<_ko1> ah, man
<_ko1> we need to consider about this table
<_ko1> with your patch
<_ko1> mmm
<charliesome> i think it won't have an impact
<charliesome> for the same reason this patch works fine with inline caches in ruby methods
<_ko1> ah, i see
<_ko1> i understand
<charliesome> the cache entry is only filled if the method exists
<charliesome> we increment state if the method redefines an existing method
<charliesome> however we do need to think about everything that may be impacted
<_ko1> as i said, it seems difficult
<_ko1> to proof crrect 'inherited' flag
<charliesome> at the moment i'm setting inherited flag in rb_class_boot
<_ko1> how about module?
<_ko1> included/extended/prepended
<charliesome> ah yes..
<_ko1> and singleton method/classes
kosaki2 has quit [Remote host closed the connection]
kosaki2 has joined #ruby-core
kosaki2 has quit [Remote host closed the connection]
kosaki8 has quit [Ping timeout: 245 seconds]
oscardelben has quit [Quit: oscardelben]
nari has joined #ruby-core
davidbalbert is now known as davidbalber|away
<znz_v> biff: [ruby-changes:27117] kazu:r39169 (trunk): fix typos - http://mla.n-z.jp/?ruby-changes=27117
Hanmac1 is now known as Hanmac
idkazuma has quit [Remote host closed the connection]
idkazuma has joined #ruby-core
nari has quit [Ping timeout: 255 seconds]
nari has joined #ruby-core
<charliesome> _ko1: rails boots 15% faster with my patch
<znz_v> biff: [ruby-changes:27118] nobu:r39170 (trunk): configure.in: fix help message - http://mla.n-z.jp/?ruby-changes=27118
<znz_v> biff: [ruby-changes:27119] nobu:r39171 (trunk): configure.in: empty version - http://mla.n-z.jp/?ruby-changes=27119
nokada has quit [Remote host closed the connection]
nokada has joined #ruby-core
idkazuma has quit [Remote host closed the connection]
idkazuma has joined #ruby-core
idkazuma has quit [Ping timeout: 248 seconds]
knu has quit [Ping timeout: 256 seconds]
knu has joined #ruby-core
idkazuma has joined #ruby-core
marcandre has quit [Remote host closed the connection]
kosaki8 has joined #ruby-core
<_ko1> charliesome: cool!!
idkazuma has quit [Remote host closed the connection]
kosaki8 has quit [Ping timeout: 246 seconds]
carlosantonio has joined #ruby-core
<znz_v> biff: [ruby-changes:27120] svn:r39173 (ruby_2_0_0): * 2013-02-09 - http://mla.n-z.jp/?ruby-changes=27120
<znz_v> biff: [ruby-changes:27121] ktsj:r39172 (ruby_2_0_0): * backport r39167 from trunk. [Bug #7812] - http://mla.n-z.jp/?ruby-changes=27121
<znz_v> biff: [ruby-changes:27122] akr:r39174 (trunk): * configure.in: move header files check to the beginning of - http://mla.n-z.jp/?ruby-changes=27122
<charliesome> looks like RUBY_VERSION_NAME isn't set in makefiles generated by mkmf.rb, so c extensions in gems can't be compiled
<charliesome> anyone know anything about that?
<znz_v> biff: [ruby-changes:27123] nobu:r39175 (trunk): * ChangeLog: fix typo. - http://mla.n-z.jp/?ruby-changes=27123
kosaki2 has joined #ruby-core
kosaki8 has joined #ruby-core
<znz_v> biff: [ruby-changes:27124] nobu:r39176 (trunk): configure.in: escape - http://mla.n-z.jp/?ruby-changes=27124
kosaki2 has quit [Remote host closed the connection]
kosaki2 has joined #ruby-core
nari has quit [Ping timeout: 276 seconds]
carlosantonio has quit [Remote host closed the connection]
<znz_v> biff: [ruby-changes:27125] nobu:r39177 (trunk): common.mk: no expansion - http://mla.n-z.jp/?ruby-changes=27125
<znz_v> biff: [ruby-changes:27126] svn:r39178 (trunk): * 2013-02-10 - http://mla.n-z.jp/?ruby-changes=27126
kosaki2 has quit [Remote host closed the connection]
marcandre has joined #ruby-core
kosaki8 has quit [Ping timeout: 256 seconds]
kosaki8 has joined #ruby-core
<zzak> _ko1: I just now created backport request to yusuke-san re: TracePoint events warning: https://bugs.ruby-lang.org/issues/7815
<_ko1> we need to persude mame-san :)
<_ko1> I add a reason
<zzak> thank you!
<charliesome> _ko1: my patch might be almost ready!
<_ko1> cool
<charliesome> http://pastie.org/6104088 <- 320 requests per second before patch, 440 requests per second after patch
<_ko1> we need reviewing
<_ko1> could you make a ticket?
<charliesome> yes, sure
<_ko1> thanks
<_ko1> nobu will verify your patch :)
<charliesome> we can't be too careful
carlosantonio has joined #ruby-core
<_ko1> should we make an internal method vm_state?
<charliesome> hm?
<_ko1> maybe you made
<charliesome> oh btw i think we should split the vm_state into a method_state and constant_state
<_ko1> ah, i see
<_ko1> English question
<charliesome> right now 'class Foo; end' if Foo doesn't exist invalidates the cache
<charliesome> _ko1: sure!
<_ko1> do you have any good name about vm_state?
<_ko1> vm_version
<charliesome> i think vm_state is a good name
<charliesome> maybe vm_serial
<charliesome> vm_state_serial
<_ko1> vm_state_serial
<_ko1> hm
<_ko1> i see
<charliesome> vm_state is fine IMO
<_ko1> INC_VM_STATE_SERIAL
<_ko1> everytime i have worry about such a name
<charliesome> _ko1: i added two methods in my patch, I just want to check that's ok
<charliesome> Class#subclassed?
<charliesome> RubyVM.state
<charliesome> the second could be very useful for performance profiling
<_ko1> i think `state' is too short and introduce misunderstanding
<charliesome> cache_state ?
<_ko1> so i want to ask the good name :)
<_ko1> or Class#has_subclass?
carlosantonio has quit [Remote host closed the connection]
<_ko1> method_cache_serial
<charliesome> i don't think including method is a good idea, because right now it is used for more than just methods
<_ko1> yes
<_ko1> ah
<_ko1> how about this case?
<_ko1> Module's method definition should increment state?
<charliesome> it should, let me check it
<_ko1> All of Module's, I mean
<charliesome> oh i see
<charliesome> yes, perhaps it should
<charliesome> i don't see any easy solution
<_ko1> I agree
<charliesome> main use case is singleton methods on objects
<charliesome> OpenStruct, etc
<_ko1> Yes.
<charliesome> _ko1: do you know how jruby solves this?
<_ko1> JRuby tracking subclasses
<lopex> yes
<_ko1> there is professional :)
<lopex> me, not!
<charliesome> _ko1: but in this case, M0 has no subclasses
<charliesome> so i wonder how jruby solves
<_ko1> maybe tracking ICLASS
<charliesome> weakref from module to its iclasses?
<_ko1> maybe yes
<_ko1> but it's my speculation
<charliesome> perhaps a module could hold a doubly linked list of weakrefs to iclasses
<charliesome> an iclass is unlinked when it is collected
<charliesome> maybe for future patch?
kosaki8 has quit [Quit: Leaving...]
<lopex> jruby uses WeakHashSet to subclasses
<lopex> *for
<_ko1> it can be. but i think it is overspec IMO
<charliesome> ah, jruby uses WeakHashSet for module iclasses too /cc lopex
oscardelben has joined #ruby-core
<znz_v> biff: [ruby-changes:27127] naruse:r39179 (trunk): the process maybe already finished - http://mla.n-z.jp/?ruby-changes=27127
carlosantonio has joined #ruby-core
carlosantonio has quit [Remote host closed the connection]
carlosantonio has joined #ruby-core
<_ko1> cool
<charliesome> anyway, good night
charliesome has quit [Quit: Textual IRC Client: www.textualapp.com]
carlosantonio has quit [Remote host closed the connection]
carlosantonio has joined #ruby-core
carlosantonio has quit [Remote host closed the connection]
knu has quit [Read error: Connection reset by peer]
oscardelben has quit [Quit: oscardelben]
<injekt> anyone have issues building 2.0.0-rc2 on osx?
<drbrain> injekt: I haven't
<drbrain> injekt: CC=clang ./configure --with-openssl-dir=/usr/local/Cellar/openssl/1.0.1c/
<drbrain> --program-suffix or --prefix if you want
<injekt> drbrain: hm ok, issue installing via ruby-build but building myself now to check
Hanmac has quit [Read error: Connection reset by peer]
Hanmac has joined #ruby-core
<injekt> drbrain: yeah same thing I get a segfault
<injekt> although it doesn't recognize the --with-openssl-dir option, but that seems unrelated
<drbrain> configure complains but it gets passed over to the openssl extension just fine
<injekt> ah ok
<drbrain> … presuming you have openssl installed via brew
<injekt> then it's certainly unrelated to the segfault
<injekt> yeah I do
<injekt> I usually use that option though, hadn't noticed configure complain about it before
<injekt> it's when linking miniruby
<drbrain> can you paste a dump?
<drbrain> also, have you built ruby in that checkout before?
<injekt> i downloaded straight from the website in the end, rc1 was fine though, checking logs will paste
* drbrain nods
<injekt> well shit, the system didn't log anything anyway, here's the make dump https://gist.github.com/injekt/4e26a6dee2ce42fc463d
<injekt> not very useful
<drbrain> it's probably the next step following linking miniruby
<drbrain> you can edit uncommon.mk and set V = 1 to see where it is crashing
<zzak> what CC are you using?
<drbrain> zzak: clang, see line 2
<zzak> :(
<injekt> what version of clang did you compile with?
<drbrain> I have Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
<drbrain> Target: x86_64-apple-darwin12.2.1
<drbrain> from Xcode 4.6
<injekt> Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)
<injekt> Target: x86_64-apple-darwin12.2.0
<injekt> that'll be why
<injekt> it's my clang version, compiles fine on gcc
<drbrain> can you report it?
<injekt> no problem
<drbrain> awesome
davidbalber|away is now known as davidbalbert
<nurse> your Xcode seems too old (4.1?)
<drbrain> nurse: if so, we should say so in README or somewhere
<injekt> 4.5 actually
<injekt> nonetheless, we should state it, because xcode isn't even 'old' I just didn't upgrade to the latest version
<nurse> if write the verssion in README, we must up to date it.
<nurse> Xcode 4.5's clang is clang-421.11.65
<injekt> weird
<injekt> then I guess my system was somewhat wonky
<injekt> nurse: yes
knu has joined #ruby-core
carlosantonio has joined #ruby-core
davidbalbert is now known as davidbalber|away
davidbalber|away is now known as davidbalbert
carlosantonio has quit [Remote host closed the connection]
carlosantonio has joined #ruby-core
carlosantonio has quit [Remote host closed the connection]
carlosantonio has joined #ruby-core
carlosantonio has quit [Remote host closed the connection]
idkazuma has joined #ruby-core
kosaki2 has joined #ruby-core
tenderlove has joined #ruby-core
kosaki2 has quit [Remote host closed the connection]
carlosantonio has joined #ruby-core
nokada has quit [Read error: Connection reset by peer]
nokada has joined #ruby-core
idkazuma has quit [Remote host closed the connection]