Feature #1857: install *.h and *.inc

• Status: Closed
• Assignee: -
• Target version: -

[rogerdpack (Roger Pack)]

=begin
This is a request for installation procedure to save away more of the source files, for use later by gems.
See http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/24666

Thanks!
=r
=end

[mame (Yusuke Endoh)]

=begin
Hi,

2009/8/2 Roger Pack [e-mail]:

Feature #1857: install *.h and *.inc
http://redmine.ruby-lang.org/issues/show/1857

Author: Roger Pack
Status: Open, Priority: Normal

This is a request for installation procedure to save away more of the source files, for use later by gems.
See http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/24666

Those files (such as node.h) are not installed by design because core team
want to prevent them to be used.
They are just for internal. The compatibility is not ensured at all.

I guess that ruby-debug is an extension of ruby-core rather than an extension
library. So it is inevitable and reasonable to gain the source of ruby.

After ruby-debug becomes stable, you should suggest the integration of
ruby-debug to the core of ruby.

--
Yusuke ENDOH [e-mail]

=end

[jameskilton (Jason Roelofs)]

=begin
What about the many other libraries that exist to dig into, or work directly with, the Ruby node structure? Like Nodewrap, RubyNode, ParseTree (http://blog.zenspider.com/2009/04/parsetree-eol.html), Rice, etc.

Are they all supposed to work towards being included into Ruby core / Ruby stdlib? I think authors / maintainers of these libraries, myself included, will completely understand that accessing this information may change across versions if we can at least get proper access to this information.
=end

[nobu (Nobuyoshi Nakada)]

=begin
Hi,

At Sun, 2 Aug 2009 23:44:44 +0900,
Jason Roelofs wrote in [ruby-core:24691]:

What about the many other libraries that exist to dig into,
or work directly with, the Ruby node structure? Like
Nodewrap, RubyNode, ParseTree
(http://blog.zenspider.com/2009/04/parsetree-eol.html), Rice,
etc.

Impossible. AST is no longer available at runtime, since now
it's a transient structure which will be discarded after the
translation to byte code.

Are they all supposed to work towards being included into
Ruby core / Ruby stdlib? I think authors / maintainers of
these libraries, myself included, will completely understand
that accessing this information may change across versions if
we can at least get proper access to this information.

I think debugger-API should be introduced, but don't think
whole of ruby-debug (and others) should be included.

--
Nobu Nakada

=end

[mark-moseley (Mark Moseley)]

=begin

Impossible. AST is no longer available at runtime, since now
it's a transient structure which will be discarded after the
translation to byte code.

It's not impossible. An extension library can call rb_compile_cstr() itself and get the AST. I realize the core team isn't comfortable with this kind of thing, and that there are good reasons to discourage it. But it cannot be prevented.

Mark

=end

[mark-moseley (Mark Moseley)]

=begin
This is becoming more and more of a problem; people are trying to install the 1.9 ruby-debug and getting the vm_core.h not found error. So I'm going to tackle creating a gem to do this.

Here's my idea: at the time extconf.rb runs for linecache or ruby-debug-base, pull the Ruby sources from ftp.ruby-lang.org based on the current RUBY_VERSION and RUBY_PATCHLEVEL. Decompress, pull out *.h and *.inc, put it into a directory, and then proceed with the build. All of this in pure Ruby so I don't have to worry about wget or tar on Windows.

If anyone can think of a better approach, please let me know. I don't want this to be something that I have to maintain with every Ruby release.

=end

[jameskilton (Jason Roelofs)]

=begin
Yeah, something that can be taken care of automatically is a lot better than doing it manually for every version and patch level release of Ruby (that Roger Pack and I were discussing earlier). I'll need this functionality as well, are you thinking that this would pull down the sources and put the headers in your gem for building? What Roger and I were talking about was a single gem that itself included all header files, exposing up command-line and in-Ruby calls to get the paths to these header files.

I guess I'd personally be more partial towards a singular location for these header files but I can see cases where one would want the headers just included in with their library's sources. Thoughts?
=end

[luislavena (Luis Lavena)]

=begin
On Wed, Aug 12, 2009 at 2:53 PM, Mark [e-mail] wrote:

Issue #1857 has been updated by Mark Moseley.

This is becoming more and more of a problem; people are trying to install the 1.9 ruby-debug and getting the vm_core.h not found error. So I'm going to tackle creating a gem to do this.

Here's my idea: at the time extconf.rb runs for linecache or ruby-debug-base, pull the Ruby sources from ftp.ruby-lang.org based on the current RUBY_VERSION and RUBY_PATCHLEVEL. Decompress, pull out *.h and *.inc, put it into a directory, and then proceed with the build. All of this in pure Ruby so I don't have to worry about wget or tar on Windows.

Similar approach of what we did for RubyInstaller project, using
uri_ext and pure-ruby unzip.

--
Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

[mark-moseley (Mark Moseley)]

=begin
I've put an initial version at: http://github.com/mark-moseley/ruby_core_source

Currently it puts the *.h and *.inc files in /include/ruby-1.9.1/ruby-1.9.2-preview1 or /include/ruby-1.9.1/ruby-1.9.1-p###, depending on the version you're running. I didn't want to put it in the gems directory; it seems to me that that might lead to confusion when this ruby_core_source gem version changes.

And thanks to Luis for uri_ext.
=end

[yugui (Yuki Sonoda)]

=begin
On 8/2/09 11:44 PM, Jason Roelofs wrote:

What about the many other libraries that exist to dig into, or work directly with, the Ruby node structure? Like Nodewrap, RubyNode, ParseTree (http://blog.zenspider.com/2009/04/parsetree-eol.html), Rice, etc.

node.h is not installed because Ruby's AST is just an internal
implementation, not an API. The structure of AST sometimes changes for
performance improvement. Actually the structure changed between 1.8 and 1.9.

But, I love ParseTree and related projects like ruby2ruby or
sexp_processor.
AST itself is too internal to be widely used. But I think S-expression
like what seattle.rb products use is enough abstract. It is enough far
from internal implementation.

2 days ago, I talked with ko1 about Proc#to_source. If Proc#to_source is
supported by Ruby core, you can use ripper for generating S-expressoin.
Is this a good solution?

-- Yugui [e-mail]

=end

[mark-moseley (Mark Moseley)]

=begin

Maybe if you fail to find the exact same release on ftp, you can fall
back to svn? That's no longer a pure ruby solution, but I think it's
better to try svn and go ahead and fail if it's not installed, rather
than fail outright if the file isn't in ftp.

The tips are easy to get via HTTP (http://svn.ruby-lang.org/repos/ruby/trunk/), but I'm not sure where that would be useful. If I pull a revision from svn, then, how do I know which one?

=end

[zenspider (Ryan Davis)]

=begin

On Aug 16, 2009, at 21:51 , Yugui (Yuki Sonoda) wrote:

2 days ago, I talked with ko1 about Proc#to_source. If
Proc#to_source is
supported by Ruby core, you can use ripper for generating S-
expressoin.
Is this a good solution?

Yes. That would be wonderful.

I can write a ripper AST to ruby_parser converter so that existing
tools can remain the same.

=end

[judofyr (Magnus Holm)]

=begin
I've already written RipperRubyParser which generates emulates
ruby_parser. I can send it to you if you're interested, even though it
might require some refactoring since I'm both a Sexp- and Ripper-noob.
However, because of this bug http://redmine.ruby-lang.org/issues/show/1939
it's not reliable enough. Currently RipperRubyParser doesn't handle
local variables properly, it just parses them as s(:call, nil, :name, s
(:arglist)). Could we please get local variables straight from Ripper?

You would also have to update Ruby2Ruby to support the new lambda-
syntax and that blocks can capture blocks.

This would also be a good time to clean up the AST even more to make
it easier in the future. We should probably still support the "old
format", at least for some time... What'd you think Ryan?

On Aug 17, 7:55 am, Ryan Davis [e-mail] wrote:

On Aug 16, 2009, at 21:51 , Yugui (Yuki Sonoda) wrote:

2 days ago, I talked with ko1 about Proc#to_source. If  
Proc#to_source is
supported by Ruby core, you can use ripper for generating S-
expressoin.
Is this a good solution?

Yes. That would be wonderful.

I can write a ripper AST to ruby_parser converter so that existing  
tools can remain the same.

=end

[judofyr (Magnus Holm)]

=begin
I've already written a working Ripper to ruby_parser converter, but
becasue of bug #1939 (http://redmine.ruby-lang.org/issues/show/1939#),
it's not reliable enough. Could we please get local variables straight
from Ripper? I can send RipperRubyParser to you if you're interested
(I'm both a Sexp and Ripper-noobie, so you might want to refactor it a
bit).

Oh, and you would also have to update Ruby2Ruby to support the new
syntax (lambda-literal + blocks can capture blocks + probably more
I've forgotten).

This would also be a good time to try to simplify the AST even more.
What'd you think Ryan?

On Aug 17, 7:55 am, Ryan Davis [e-mail] wrote:

On Aug 16, 2009, at 21:51 , Yugui (Yuki Sonoda) wrote:

2 days ago, I talked with ko1 about Proc#to_source. If  
Proc#to_source is
supported by Ruby core, you can use ripper for generating S-
expressoin.
Is this a good solution?

Yes. That would be wonderful.

I can write a ripper AST to ruby_parser converter so that existing  
tools can remain the same.

=end

[usa (Usaku NAKAMURA)]

=begin
Hello,

In message "[ruby-core:24950] Re: [Feature #1857] install *.h and *.inc"
on Aug.17,2009 22:03:35, [e-mail] wrote:

With 1.9+ you've got

RUBY_DESCRIPTION
=> "ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-mingw32]"

Unfortunately that revision description doesn't say which branch it
came from [was it trunk or the 1.9.1 branch itself?]
Perhaps that should be added? <wink, wink, hint, hint>

p129 means that the source came from 1.9.1 branch, because
trunk doesn't have patchlevel.

Regards,

U.Nakamura [e-mail]

=end

[naruse (Yui NARUSE)]

• Status changed from Open to Closed

=begin

=end