RubyInline

[Mark Volkmann]

I'm using RubyInline-3.6.2 and am having trouble getting this simple
example to work.

require 'rubygems'
require 'inline'

class Example
inline do |builder|
builder.c "
int simple() {
int x = 10;
return x;
}"
end
end

p Example.new.simple

When I run this I get

/usr/local/lib/ruby/gems/1.8/gems/RubyInline-3.6.2/./inline.rb:378:in
`build': undefined method `+' for nil:NilClass (NoMethodError)
from /usr/local/lib/ruby/gems/1.8/gems/RubyInline-3.6.2/./
inline.rb:628:in `inline'
from demo.rb:5

I'm not sure if I'm doing something wrong or there is a bug in that
version of RubyInline.

 

[Ryan Davis]

I'm using RubyInline-3.6.2 and am having trouble getting this
simple example to work.

require 'rubygems'
require 'inline'

class Example
inline do |builder|
builder.c "
int simple() {
int x = 10;
return x;
}"
end
end

p Example.new.simple

When I run this I get

/usr/local/lib/ruby/gems/1.8/gems/RubyInline-3.6.2/./inline.rb:
378:in `build': undefined method `+' for nil:NilClass (NoMethodError)
from /usr/local/lib/ruby/gems/1.8/gems/RubyInline-3.6.2/./
inline.rb:628:in `inline'
from demo.rb:5

I'm not sure if I'm doing something wrong or there is a bug in that
version of RubyInline.

First off, this isn't the right forum for reporting something like
this. Filing a bug on the rubyinline project on rubyforge is the
correct forum.

That said, No bug has been reported against this version of inline.

Please provide output of the following:

ruby -v -rrbconfig -e 'p Config::CONFIG["archdir"], Config::CONFIG
["srcdir"]'

 

[Gregory Brown]

First off, this isn't the right forum for reporting something like
this. Filing a bug on the rubyinline project on rubyforge is the
correct forum.

This is starting to be a real problem, in the sense that bug reports
or problems end up in RubyTalk or some other forum / mailing list
rather than in the hands of the developers who can address the
problems in the format they expect.

With no offense intended to the OP, how can we get people to go to the
right place?
For example, Ruport we want you to use our Trac and/or Mailing List
for contact, but putting these links in our README doesn't seem to do
the trick.

I'm mostly looking for ideas, but how do you guys think we can best
direct traffic? Maybe hacking a "where to go for help" link into
RubyForge?

 

[Joel VanderWerf]

This is starting to be a real problem, in the sense that bug reports
or problems end up in RubyTalk or some other forum / mailing list
rather than in the hands of the developers who can address the
problems in the format they expect.

With no offense intended to the OP, how can we get people to go to the
right place?
For example, Ruport we want you to use our Trac and/or Mailing List
for contact, but putting these links in our README doesn't seem to do
the trick.

I'm mostly looking for ideas, but how do you guys think we can best
direct traffic? Maybe hacking a "where to go for help" link into
RubyForge?

Is this really a problem?

If it's not a bug, asking on ruby-talk may be the best way to get help.

 

[Gregory Brown]

Is this really a problem?

If it's not a bug, asking on ruby-talk may be the best way to get help.

I just feel like the best help you can hope to get on projects is from
the authors of those projects or the users who've managed to find the
communication channels closer to the project.

RubyTalk is no longer at a traffic level in which it can comfortably
support discussions about specific projects, unless they're somewhat
general, I feel.

Even if that's not an issue, I guess I just favour archive
preservation somewhere closer to the actual project.

Just an opinion of course, and RubyTalk is a great place to go when
you can't find the right place, if nothing else, to be pointed in the
right direction.

 

[Eric Hodel]

Is this really a problem?

Yes. For example, for RubyGems there are many bug reports here (and
on the RubyGems list) that should be in the tracker. The active
RubyGems developers don't have the time to read ruby-talk, so these
bug reports are just going to get lost.

If it's not a bug, asking on ruby-talk may be the best way to get
help.

If you're doing something and there's an exception, its probably a bug.

 

[Mark Volkmann]

First off, this isn't the right forum for reporting something like
this. Filing a bug on the rubyinline project on rubyforge is the
correct forum.

I'll admit to why I did this. It's probably the reason you would
guess. I was perhaps being a little lazy. It's cumbersome to have to
sign up for the mailing list of every Ruby library if you don't
anticipate needing to use them very much. I just wanted to try out
RubyInline. I was hoping that I could get a quick answer without
having to signup for another mailing list, post there, wait for an
answer, and unsubscribe. I thought I could sneak that through since
there was an announcement about RubyInline on this list. I understand
your concern though, so I'll sign up and ask my question on that list.

 

[ara.t.howard]

I'll admit to why I did this. It's probably the reason you would guess. I
was perhaps being a little lazy. It's cumbersome to have to sign up for the
mailing list of every Ruby library if you don't anticipate needing to use
them very much. I just wanted to try out RubyInline. I was hoping that I
could get a quick answer without having to signup for another mailing list,
post there, wait for an answer, and unsubscribe. I thought I could sneak
that through since there was an announcement about RubyInline on this list.
I understand your concern though, so I'll sign up and ask my question on
that list.

for rubyforge projects you can post bugs anywhere if you have a login. no
mailing lists required. imho this is the only reasonable method if posting
bugs for not oft used libs like you're suggesing.

i personally don't mind the cross posting either, nevetheless i can understand
it bothering some and not helping the developers specifically.

cheers.

-a

 

[Ryan Davis]

I'll admit to why I did this. It's probably the reason you would
guess. I was perhaps being a little lazy. It's cumbersome to have
to sign up for the mailing list of every Ruby library if you don't
anticipate needing to use them very much. I just wanted to try out
RubyInline. I was hoping that I could get a quick answer without
having to signup for another mailing list, post there, wait for an
answer, and unsubscribe. I thought I could sneak that through since
there was an announcement about RubyInline on this list. I
understand your concern though, so I'll sign up and ask my question
on that list.

Filing a bug != subscribe to mailing list.

My whole point was that mailing lists are fleeting and not even
remotely guaranteed to be tracked over time. That is why we have bug
dbs in the first place.

 

[Ryan Davis]

This is starting to be a real problem, in the sense that bug reports
or problems end up in RubyTalk or some other forum / mailing list
rather than in the hands of the developers who can address the
problems in the format they expect.

Gregory, I couldn't agree more. I've missed a number of things
because they get sent here.

I'm mostly looking for ideas, but how do you guys think we can best
direct traffic? Maybe hacking a "where to go for help" link into
RubyForge?

I'm still not sure. I thought that adding urls on all my readmes,
email announcements, blog announcements would be enough, but
obviously it isn't. I think at some stage I have to say that I did
_my_ due diligence and now it is on the user to do theirs, but
obviously, that means that potentially important stuff will slip
through.

 

[Joel VanderWerf]

Filing a bug != subscribe to mailing list.

My whole point was that mailing lists are fleeting and not even remotely
guaranteed to be tracked over time. That is why we have bug dbs in the
first place.

I guess my point is that people file bugs that aren't. Every now and
then the ruby-core list gets a generated copy of a bug report saying
something like "I don't like how feature X behaves", typically something
answered in the FAQ and in ruby-talk archives. For example:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/10066

At least in the case of ruby itself, it seems better to filter this kind
of thing through ruby-talk before it escalates to bother the developers.

Also, I like to learn about other projects without having to subscribe
to all their lists....

I do agree that in the case of real bugs, you want to find the reports
in your db, rather than have to read every message on ruby-talk. So, I
guess there's a tradeoff...

 

[Tomas Pospisek's Mailing Lists]

This is starting to be a real problem, in the sense that bug reports
or problems end up in RubyTalk or some other forum / mailing list
rather than in the hands of the developers who can address the
problems in the format they expect.
With no offense intended to the OP, how can we get people to go to the
right place?

Maybe I can provide an anecdotical data point. Last time I reported a
request for a feature improvement in Ruby in Rubyforge it did feel a lot
to me like it had disapeard in /dev/null [1].

Lately a coworker of mine was discussing some Ruby project he was doing
and the fact that he was not sure where to report bugs because sending
them to the tracker didn't result in any feedback [2].

That's also why I recently went to ruby-talk with the gettimeofday
problem...

I'm not saying this because I'd like to be cared about like a baby but
because no feedback is not trivially distinguishable from non-function.

For example, Ruport we want you to use our Trac and/or Mailing List
for contact, but putting these links in our README doesn't seem to do
the trick.
I'm mostly looking for ideas, but how do you guys think we can best
direct traffic? Maybe hacking a "where to go for help" link into
RubyForge?

*t

[1] http://rubyforge.org/tracker/index.php?func=detail&aid=4833&group_id=426&atid=1698
[2] search the same tracker for "Karl Brodowsky"

 

[MenTaLguY]

Filing a bug != subscribe to mailing list.

My whole point was that mailing lists are fleeting and not even
remotely guaranteed to be tracked over time. That is why we have bug
dbs in the first place.

Non-rhetorical question: personally, do you prefer users to file bug reports, or do you prefer them to ask questions when they are in doubt whether an error they are seeing is the consequence of a bug or their own mistake?

-mental

 

[Eric Hodel]

On Sat, 3 Mar 2007 07:06:22 +0900, Ryan Davis <ryand-


Non-rhetorical question: personally, do you prefer users to file
bug reports, or do you prefer them to ask questions when they are
in doubt whether an error they are seeing is the consequence of a
bug or their own mistake?

Bugs. If people file multiple bugs for the same not-a-bug on my
project, I have poor design or poor documentation.

 

[Austin Ziegler]

Non-rhetorical question: personally, do you prefer users to file bug
reports, or do you prefer them to ask questions when they are in doubt
whether an error they are seeing is the consequence of a bug or their
own mistake?

It depends. Certain things are complex enough that I want questions
first (especially with PDF::Writer); what I *don't* like is having to
answer questions that I've answered over and over again ...

Part of my problem on top of everything else is that I think that the
bug tracker in GForge completely sucks. I don't have anywhere I want to
run Trac (and I'm not convinced I want to run Trac, either) and I
haven't yet made a decision with respect to the Google Code bug tracker.

Honestly, I've written a better bug tracker than the one provided in
GForge, but as it's in perl I don't maintain it anymore (I'm not even
sure I carried the source forward when I switched computers this time).

-austin

 

[Mark Volkmann]

Filing a bug != subscribe to mailing list.

My whole point was that mailing lists are fleeting and not even
remotely guaranteed to be tracked over time. That is why we have
bug dbs in the first place.

I understand that, but I didn't initially think I was reporting a
bug. I just thought I wasn't installing it or using it correctly. In
that case I would have to subscribe to the mailing list.

 

[Brian Candler]

I'm using RubyInline-3.6.2 and am having trouble getting this simple
example to work.

require 'rubygems'
require 'inline'

class Example
inline do |builder|
builder.c "
int simple() {
int x = 10;
return x;
}"
end
end

p Example.new.simple

When I run this I get

/usr/local/lib/ruby/gems/1.8/gems/RubyInline-3.6.2/./inline.rb:378:in
`build': undefined method `+' for nil:NilClass (NoMethodError)
from /usr/local/lib/ruby/gems/1.8/gems/RubyInline-3.6.2/./
inline.rb:628:in `inline'
from demo.rb:5

I'm not sure if I'm doing something wrong or there is a bug in that
version of RubyInline.

Running exactly what operating system and version, and what version of ruby?

Wild guess: perhaps you are running something like Ubuntu without the
ruby1.8-dev package installed. But without basic information about the
environment, it's hard to give any concrete suggestions.

 

[Brian Candler]

Running exactly what operating system and version, and what version
of ruby?

Wild guess: perhaps you are running something like Ubuntu without the
ruby1.8-dev package installed. But without basic information about the
environment, it's hard to give any concrete suggestions.

I ran this under Mac OS X.

Output from ruby -v -rrbconfig -e 'p Config::CONFIG["archdir"],
Config::CONFIG["srcdir"]' is
ruby 1.8.5 (2006-12-25 patchlevel 12) [i686-darwin8.8.1]
"/usr/local/lib/ruby/1.8/i686-darwin8.8.1"
nil

On my machine, the context is

srcdir = Config::CONFIG["srcdir"]
archdir = Config::CONFIG["archdir"]
if File.exist? archdir + "/ruby.h" then
hdrdir = archdir
elsif File.exist? srcdir + "/ruby.h" then
hdrdir = srcdir
else
$stderr.puts "ERROR: Can't find header files for ruby. Exiting..."
exit 1
end

So you could try adding

$stderr.puts "srcdir = #{srcdir.inspect}"
$stderr.puts "archdir = #{archdir.inspect}"

before the File.exist? line, to see if that helps narrow things down.