[#119132] Segfault using ruby C on MacOS (Intel Catalina and M2 Sonoma) — "martin.kufner--- via ruby-core" <ruby-core@...>
Hey guys,
4 messages
2024/09/12
[#119133] Re: Segfault using ruby C on MacOS (Intel Catalina and M2 Sonoma)
— "martin.kufner--- via ruby-core" <ruby-core@...>
2024/09/12
I just saw, that the #includes dont show up in the c file ...
[#119145] [Ruby master Misc#20728] Propose Eileen Uchitelle as a core committer — "kddnewton (Kevin Newton) via ruby-core" <ruby-core@...>
Issue #20728 has been reported by kddnewton (Kevin Newton).
14 messages
2024/09/12
[#119312] [Ruby master Bug#20762] `make test-basic` with -DRGENGC_FORCE_MAJOR_GC is always failure — "hsbt (Hiroshi SHIBATA) via ruby-core" <ruby-core@...>
Issue #20762 has been reported by hsbt (Hiroshi SHIBATA).
6 messages
2024/09/27
[ruby-core:119278] [Ruby master Feature#20757] Make rb_tracearg_(parameters|eval_script|instruction_sequence) public C-API
From:
richardboehme via ruby-core <ruby-core@...>
Date:
2024-09-22 11:36:31 UTC
List:
ruby-core #119278
Issue #20757 has been updated by richardboehme (Richard B=F6hme). Actually it seems like retrieving the method object using the `method_id` d= oes not work well for super-calls. See this example: ``` ruby TracePoint.new(:call) do |tp| p tp.self end.enable class A def test end end class B < A def test =3D super end B.new.test ``` `TracePoint#self` will return the instance of B twice, which makes it hard = to get the parameters of `A#test` without being able to call `TracePoint#pa= rameters`. In general this makes it hard to track down the location of the = method behind `TracePoint#method_id`, but this is another issue. ---------------------------------------- Feature #20757: Make rb_tracearg_(parameters|eval_script|instruction_sequen= ce) public C-API https://bugs.ruby-lang.org/issues/20757#change-109886 * Author: richardboehme (Richard B=F6hme) * Status: Open ---------------------------------------- **Abstract** As a C-extension developer when using tracepoints I include "ruby/debug.h".= This includes most of TracePoint's API but it seems like the C-equivalents= for TracePoint#parameters, TracePoint#eval_script and TracePoint#instructi= on_sequence are missing/not being exported in the header. =20 **Background** Most APIs like rb_tracearg_return_value are exported in "ruby/debug.h". If = I understand correctly, the implementations for those methods are located i= n "ruby/vm_trace.c". The following methods implemented in "ruby/vm_trace.c"= are missing in "ruby/debug.h": * rb_tracearg_parameters * rb_tracearg_eval_script * rb_tracearg_instruction_sequence =20 **Proposal** I propose to add those methods to "ruby/debug.h". From my limiting understa= nding the change should be simple and not break backward compatibility, bec= ause we'd only need to add those function declarations to "ruby/debug.h". I'd be open to contribute this change if it was approved. **Use cases** I'm implementing a method call tracer for Ruby using the C-extension API. I= wanted to get information about the parameters that the called method rece= ives. When writing in Ruby this can be done using the TracePoint#parameters= method, but I could not find the equivalent C-API. A workaround is to retr= ieve the method object (using the method_id) and check the method parameter= s. =20 **See also** * Implementation of TracePoint#parameters in #14694=20 * Implementation of TracePoint#eval_script and TracePoint#instruction_seque= nce in #15287=20 --=20 https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.rub= y-lang.org/