1. Proposed TraceBack Change
In the current trace back (both in be_rterror.c and error.e) the path +
file name length is truncated to 99 chars. Does anyone have any objection
to raising this limit?
I often work deep in "My Documents", and it gets really annoying when
the path gets truncated, since I can't use the automated jump to error
feature of wxide (the editor I normally use).
Matt
2. Re: Proposed TraceBack Change
Matt Lewis wrote:
>
> In the current trace back (both in be_rterror.c and error.e) the path +
> file name length is truncated to 99 chars. Does anyone have any objection
> to raising this limit?
I'm curious as to why anyone would object.
Other than that curiosity, I have no idea what you're talking about. :D
I was hoping "traceback" was referring to this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1643933&group_id=182827&atid=902785
:)
3. Re: Proposed TraceBack Change
Matt Lewis wrote:
> In the current trace back (both in be_rterror.c and error.e) the path +
> file name length is truncated to 99 chars. Does anyone have any objection
> to raising this limit?
>
> I often work deep in "My Documents", and it gets really annoying when
> the path gets truncated, since I can't use the automated jump to error
> feature of wxide (the editor I normally use).
No problem.
But in the C code, you need to also enlarge TPTempBuff[]
to avoid any chance of buffer overflow with C's sprintf().
error.e has "99" in it, just because the
front-end was originally written in C. Euphoria's sprintf()
does not require a fixed-size buffer.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Proposed TraceBack Change
c.k.lester wrote:
>
> Matt Lewis wrote:
> >
> > In the current trace back (both in be_rterror.c and error.e) the path +
> > file name length is truncated to 99 chars. Does anyone have any objection
> > to raising this limit?
>
> I'm curious as to why anyone would object.
>
> Other than that curiosity, I have no idea what you're talking about. :D
>
> I was hoping "traceback" was referring to this:
No, it's basically any line in ex.err that lists a path/file/line number
combination.
Matt
5. Re: Proposed TraceBack Change
Robert Craig wrote:
>
> Matt Lewis wrote:
> > In the current trace back (both in be_rterror.c and error.e) the path +
> > file name length is truncated to 99 chars. Does anyone have any objection
> > to raising this limit?
> >
> > I often work deep in "My Documents", and it gets really annoying when
> > the path gets truncated, since I can't use the automated jump to error
> > feature of wxide (the editor I normally use).
>
> No problem.
>
> But in the C code, you need to also enlarge TPTempBuff[]
> to avoid any chance of buffer overflow with C's sprintf().
>
> error.e has "99" in it, just because the
> front-end was originally written in C. Euphoria's sprintf()
> does not require a fixed-size buffer.
>
Yep, found that....
Matt
6. Re: Proposed TraceBack Change
Matt Lewis wrote:
>
>
> In the current trace back (both in be_rterror.c and error.e) the path +
> file name length is truncated to 99 chars. Does anyone have any objection
> to raising this limit?
I will be *strongly* against this, unless you do one thing:
Wherever you output a full path + file name, make it a *FULL* path!
Regards,
Pete
PS actually, I cannot now reproduce the sort of annoying problem I've often had,
eg looking in C:\test when it should be C:\test\bench, or looking in
C:\test\bench\bench when it should just be C:\test\bench, but it has bit me more
than once - because line 1 just says "test.exw" or "bench\test.exw", which may
not [even] marry with location of ex.err, sometimes. (Erm maybe this bites harder
after a chdir() call within the app?)
7. Re: Proposed TraceBack Change
Pete Lomax wrote:
>
> Matt Lewis wrote:
> >
> >
> > In the current trace back (both in be_rterror.c and error.e) the path +
> > file name length is truncated to 99 chars. Does anyone have any objection
> > to raising this limit?
> I will be *strongly* against this, unless you do one thing:
> Wherever you output a full path + file name, make it a *FULL* path!
I'm curious why you're strongly against this. Maybe I'm just not understanding
you. The current behavior seems to depend upon how the interpreter is
invoked. If you rely on your PATH, then it will use paths in the traceback.
If you specify the interpreter directly, it appears to use file names only.
I'm not certain as to how/where this is done--just haven't looked into it.
My concern was that when you get an error, it would display most of the
path for a really long path, but might cut off part of it.
> Regards,
> Pete
> PS actually, I cannot now reproduce the sort of annoying problem I've often
> had, eg looking in C:\test when it should be C:\test\bench, or looking in
> C:\test\bench\bench
> when it should just be C:\test\bench, but it has bit me more than once -
> because
> line 1 just says "test.exw" or "bench\test.exw", which may not [even] marry
> with location of ex.err, sometimes. (Erm maybe this bites harder after a
> chdir()
> call within the app?)
Fixing this is a separate issue from the one to which I refer (basically,
I was doing stuff in a path that was somewhere around 120 chars). Anyways,
it's already committed. :P
Matt
8. Re: Proposed TraceBack Change
Matt Lewis wrote:
> I'm curious why you're strongly against this.
Because if you don't use this opportunity, it'll probably never get done.
> Anyways, it's already committed. :P
Oh well, nevermind then 
)
Pete
