[ruby-core:70895] Re: How to get started with ruby-core source code development

Eric,

Thanks for a great response. exhuberant ctags - Uh-mazing! I've seen 
this mentioned here and there, but didn't really know what it was for - 
what it does for vim is simply incredible. Thanks for the tip and for 
speaking to the chroot question specifically. I have a lot to learn and 
to research now - ccache, strace, __attribute__((constructor)) / 
__attribute__((destructor)), and write(-1, "..."); errno = 0; vs 
fprintf. I will be reading the README.EXT file next.

I followed your advice to sandbox with ./configure --prefix and have a 
running ruby that is step-debuggable - yay!

Thanks,

Will

On 9/23/15 1:50 PM, Eric Wong wrote:
> Will Senn <[e-mail]> wrote:
>> I apologize in advance if this question has been asked and answered
>> before. I have scoured the internet, including this group's archives
>> and have had no joy in finding the information I seek. Please be
>> kind :).
> Everyone has their own preferences/tools, so mine might be wildly
> different from everyone elses.
>
> I generally stick to old stuff, the lowest common denominator that's
> available on any GNU/Linix system, old or new.  Anything I'm willing to
> rely on, I must also be willing to debug and help fix if it goes wrong.
> I do not rely on having much.
>
>> What I would like to know is how to begin working with the ruby-core
>> source code effectively. Obviously, it can be read to reasonable
>> effect and understood intellectually to a large degree. I have found
>> Ruby Minero Aoki's book, Ruby Hacking Guide to be helpful in this
>> regard.
> If you haven't already, see doc/extension.rdoc in the source
> (README.EXT in older versions).
>
>> However, I am interested in studying it with a debugger and
>> this is more challenging than it sounds. I have built the source
>> code on my Macbook (Yosemite), but gdb doesn't seem to work on Mac,
>> and LLVM instructions are vague in the wild. I have built the 1.7.3
>> source code on a debian jessie VM and used eclipse to step through
>> code where I passed the path to irb into ruby as an argument and
>> this "works" ok. So, with high hopes, I built the source for 2.2.3
>> on the debian vm and while it built fine, it seems to be looking for
>> gem files. I gather, it needs an environment variable or argument,
>> so I will muddle on hoping to work past that hurdle. However, I am
>> hoping someone who is actively developing the code will share their
>> setup (or point me in the appropriate direction to a howto).
>>
>> Specifically, what do you use to work with the code:
>>      Which Operating System is hosting the ruby executable?
> Various versions of Debian or CentOS GNU/Linux, occasionally
> Debian GNU/kFreeBSD or FreeBSD
>
>>      Are there environment parameters that need to be set or passed
>> as arguments?
> Nothing besides an extra element in PATH ($HOME/r-whatever/bin)
> where I used ./configure --prefix=... (see below).
>
>>      What Tools are useful (eclipse, gdb, valgrind, etc)?
> I use (exuberant-)ctags in day-to-day with almost-stock vim.
> git commands: "git grep", "git log -p"  if I'm lucky enough
> to have a git repo + installation available.
>
> I use gdb for inspecting core dumps, only.
> valgrind if I'm actively hunting a memory leak.
>
> Often I'll find a well-placed "fprintf(stderr, ...)" is enough for
> figuring out what's going on.  strace helps, as does combining
> it with:
>
> 	write(-1, "..."); errno = 0;
>
> If you can't take too much output on stderr or are inside a signal
> handler or a small thread stack where you can't *printf.
>
> Sometimes I'll write a short functions with the GCC
> __attribute__((constructor)) / __attribute__((destructor))
> attributes to dump out accumulated stats and such.
>
> ccache is helpful for speeding up builds since I could be
> branches frequently and cause make to repeat too much work.
>
> None of this is specific to Ruby, by the way...
>
>
> Writing a test extension (see test/-ext/* for examples) helps,
> too.
>
> I definitely do not use Eclipse (or any GUI tools) as I only work with
> command-line interfaces.  Relying on a GUI would mean I'd potentially
> get dragged into debugging a constantly-changing GUI stack or worse:
> graphics drivers with poor, one-off specs and documentation and/or
> unfixable proprietary blobs.  Life's too short for that.
>
> I already get dragged into enough projects (ruby-core included)
> because I kept finding bugs or ways to improve through normal use.
>
>>      How do you keep a pristine working environment for your work, chroot?
> ./configure --prefix=$HOME/r-whatever/  for day-to-day with my
> usual user account.  This works for anything using autoconf or
> similar, so it's applicable to a lot of projects.
>
> Sometimes I might use a different user account + home directory
> if I want to test something more experimental/unsafe or likely
> to leave a mess.
>
> Then even more occasionally I'll use a chroot (if there's a larger
> dependency such as glibc change) or KVM if there's a kernel dependency.
>
>>      Any helpful hints on editing  a c file, rerunning make, running
>> gdb and info func myfunc, etc. would be tremendously helpful.
> I edit + make + and do whatever relevant tests in a loop until I'm
> satisfied with the result.