1. Proposed TraceBack Change
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 17, 2007
- 472 views
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
- Posted by c.k.lester <euphoric at cklester.com> Apr 17, 2007
- 454 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Apr 17, 2007
- 452 views
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
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 17, 2007
- 444 views
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
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 17, 2007
- 458 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Apr 18, 2007
- 449 views
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
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 18, 2007
- 449 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Apr 18, 2007
- 455 views
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