«

Has anyone ever seen Ruby report incorrect line numbers
where runtime errors occur?

It's doing it to me, but it's hard to reproduce without
the (large) file I'm using.

Matz: If you're interested, I'll send you a tarball.


Hal

Hi,

In message "Re: Errors in line numbers reported?"
on Tue, 26 Oct 2004 08:13:05 +0900, Hal Fulton <> writes:

|Matz: If you're interested, I'll send you a tarball.

Send me, unless the source file is larger than 8191 lines.
It's implementation restriction.

matz.

On Tue, 26 Oct 2004, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Errors in line numbers reported?"
> on Tue, 26 Oct 2004 08:13:05 +0900, Hal Fulton <> writes:
>
> |Matz: If you're interested, I'll send you a tarball.
>
> Send me, unless the source file is larger than 8191 lines.
> It's implementation restriction.
>
> matz.

you mean __LINE__ cannot go > that that?

-a
--
================================================== =============================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
================================================== =============================

Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Errors in line numbers reported?"
> on Tue, 26 Oct 2004 08:13:05 +0900, Hal Fulton <> writes:
>
> |Matz: If you're interested, I'll send you a tarball.
>
> Send me, unless the source file is larger than 8191 lines.
> It's implementation restriction.

OK, I never knew that.

The file is 11,756 lines (down from 22,000).

I know that's a lot, and in general is a very bad idea.

But this file is generated code. I'm generating a large
number of child classes based on data.

Is there a workaround -- perhaps the line reported is
real_line mod 8192? In that case I could just add 8K
once or twice...


Thanks,
Hal

Hi,

In message "Re: Errors in line numbers reported?"
on Tue, 26 Oct 2004 11:34:05 +0900, writes:

|> Send me, unless the source file is larger than 8191 lines.
|> It's implementation restriction.

|you mean __LINE__ cannot go > that that?

Unfortunately yes. It's balance between performance and my
intelligence. Maybe someone wiser than me can enlighten me.

matz.

Hi,

In message "Re: Errors in line numbers reported?"
on Tue, 26 Oct 2004 11:27:59 +0900, Hal Fulton <> writes:

|> Send me, unless the source file is larger than 8191 lines.
|> It's implementation restriction.
|
|Is there a workaround -- perhaps the line reported is
|real_line mod 8192? In that case I could just add 8K
|once or twice...

It should be. It is a bad restriction. I should have fix that. But
I couldn't think of the way to fix the problem without hindering
performance.

matz.

On Tue, 26 Oct 2004, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Errors in line numbers reported?"
> on Tue, 26 Oct 2004 11:34:05 +0900, writes:
>
> |> Send me, unless the source file is larger than 8191 lines.
> |> It's implementation restriction.
>
> |you mean __LINE__ cannot go > that that?
>
> Unfortunately yes. It's balance between performance and my
> intelligence. Maybe someone wiser than me can enlighten me.
>
> matz.

with a lead in like that you can't expect many patches can you?

-a
--
================================================== =============================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
================================================== =============================

On Mon, 2004-10-25 at 20:54, wrote:
> On Tue, 26 Oct 2004, Yukihiro Matsumoto wrote:
>
> > Hi,
> >
> > In message "Re: Errors in line numbers reported?"
> > on Tue, 26 Oct 2004 11:34:05 +0900, writes:
> >
> > |> Send me, unless the source file is larger than 8191 lines.
> > |> It's implementation restriction.
> >
> > |you mean __LINE__ cannot go > that that?
> >
> > Unfortunately yes. It's balance between performance and my
> > intelligence. Maybe someone wiser than me can enlighten me.
> >
> > matz.
>
> with a lead in like that you can't expect many patches can you?
>

I agree with Ara; so instead I will sign up under the always
implicit "more foolhardy" clause in the hopes of learning a little by
claiming less.

I have a patch (attached). It removes the 8k line limit on error
tracking but increases the size of the RNODE to 36 bytes (if I calculate
correctly) from the easier to align 32 bytes. I suspect that this is
where the performance hit would come from, but I have been unable to
measure any consistent speed difference between the patched and
unpatched versions, so I may not be testing the right cases. It may
also be that the savings of not having to shift the bits around makes up
for the alignment hit somewhat, but I have not tested this idea.

-- Markus

diff -u ruby-1.8.2/eval.c ruby-1.8.2-8klines/eval.c
--- ruby-1.8.2/eval.c 2004-07-27 23:32:37.000000000 -0700
+++ ruby-1.8.2-8klines/eval.c 2004-10-25 22:13:13.000000000 -0700
@@ -8296,7 +8296,7 @@

Data_Get_Struct(self, struct BLOCK, data);
if ((node = data->frame.node) || (node = data->body)) {
- len += strlen(node->nd_file) + 2 +
(SIZEOF_LONG*CHAR_BIT-NODE_LSHIFT)/3;
+ len += strlen(node->nd_file) + 2 + (SIZEOF_LONG*CHAR_BIT)/3;
str = rb_str_new(0, len);
sprintf(RSTRING(str)->ptr, "#<%s:0x%.*lx@%s:%d>", cname, w,
(VALUE)data->body,
node->nd_file, nd_line(node));
diff -u ruby-1.8.2/node.h ruby-1.8.2-8klines/node.h
--- ruby-1.8.2/node.h 2004-10-25 22:05:16.000000000 -0700
+++ ruby-1.8.2-8klines/node.h 2004-10-25 22:20:04.000000000 -0700
@@ -130,6 +130,7 @@
typedef struct RNode {
unsigned long flags;
char *nd_file;
+ unsigned long nd_line;
union {
struct RNode *node;
ID id;
@@ -159,11 +160,8 @@
#define nd_set_type(n,t) \

RNODE(n)->flags=((RNODE(n)->flags&~FL_UMASK)|(((t)<<FL_USHIFT)&FL_UMASK))

-#define NODE_LSHIFT (FL_USHIFT+
-#define NODE_LMASK (((long)1<<(sizeof(NODE*)*CHAR_BIT-NODE_LSHIFT))-1)
-#define nd_line(n) ((unsigned
int)(((RNODE(n))->flags>>NODE_LSHIFT)&NODE_LMASK))
-#define nd_set_line(n,l) \
-
RNODE(n)->flags=((RNODE(n)->flags&~(-1<<NODE_LSHIFT))|(((l)&NODE_LMASK)<<NODE_LSHIFT))
+#define nd_line(n) (((RNODE(n))->nd_line))
+#define nd_set_line(n,l) (RNODE(n)->nd_line=(l))

#define nd_head u1.node
#define nd_alen u2.argc

>>>>> "M" == Markus <> writes:

M> I have a patch (attached). It removes the 8k line limit on error
M> tracking but increases the size of the RNODE to 36 bytes (if I calculate
M> correctly) from the easier to align 32 bytes.

The game is to not change the size of R struct


Guy Decoux

> The game is to not change the size of R struct

As long as the size of the file is recorded somewhere, then you could use
this to have a varying granularity of line numbers. e.g.

file size recorded accuracy
--------- -----------------
0..8191 exact
8192..16383 to within 2 lines
16384..24575 to within 3 lines
24576..32767 to within 4 lines
... etc

def encode_line(n, filesize)
raise "oops" if n > filesize
x = (filesize >> 13) + 1
n / x
end

def decode_line(n, filesize)
x = (filesize >> 13) + 1
(n*x)..(n*x + x - 1)
end

You get the same lack of resolution in the current system. However, if the
file size is 20000 lines (say), then an error in line 17 could be in line
17, line 8209 or line 16401 - rather than line 15, 16 or 17.

Just a thought.

Regards,

Brian.