neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) (03/03/91)
I've been having some problems recently. Is there any reason that the
command: fprintf(stderr,"Testing\n"); shouldn't work in a long program?
I don't have to open the file, it's standard open when run from the
shell. If I change it to printf("Testing\n"); everything works.
Other weird things include programs which run fine, but if you use
the "variables" command to monitor one of the variables, it immediately
crashes Prizm into the monitor, until you rename the variable in the
source code. No variable name conflicts were involved.
When I had a doubly defined #define argument, it issued the
appropriate error message and line and column numbers in the source
file, but it echoed the line after the error, which was another #define.
It took me a while to figure out that the line echoed in the error
message was not the one which caused the offense.
Is there any word on whether the upgrade will fix the problem in the
debugger which keeps the arrow from being visible, or the window from
scrolling to follow the arrow until after it makes its first subroutine
call, and sometimes not even then?
--
Christopher Neufeld....Just a graduate student | Note: new host.
neufeld@aurora.physics.utoronto.ca Ad astra! | helios will still
cneufeld@{pnet91,pro-cco}.cts.com | forward my mail to
"Don't edit reality for the sake of simplicity" | me on aurora.bazyar@ernie (Jawaid Bazyar) (03/03/91)
In article <1991Mar2.192847.12622@helios.physics.utoronto.ca> neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) writes: > > I've been having some problems recently. Is there any reason that the >command: fprintf(stderr,"Testing\n"); shouldn't work in a long program? >I don't have to open the file, it's standard open when run from the >shell. If I change it to printf("Testing\n"); everything works. fprintf(stderr,"Testing\n") has worked fine for me in programs. > Other weird things include programs which run fine, but if you use >the "variables" command to monitor one of the variables, it immediately >crashes Prizm into the monitor, until you rename the variable in the >source code. No variable name conflicts were involved. Oh! You're in Prizm. Now I see the problem... Prizm isn't worth the iron it's encoded on. Hopefully the new version will fix the almost infinite problems with Prizm, and make it useful. Orca/C 1.2 is now in beta. Mike says he's going to be working on it thru next week. 1.2b1 has fixed 15 bugs supposedly. -- Jawaid Bazyar |"I'm sure K&R have never heard of Mike." Senior/Computer Engineering | bazyar@cs.uiuc.edu |"That's okay. I'm sure Mike's never heard of K&R". Apple II Forever! | (discussion about Orca/C)
neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) (03/03/91)
In article <1991Mar2.210621.21501@ux1.cso.uiuc.edu> bazyar@cs.uiuc.edu (Jawaid Bazyar) writes: >In article <1991Mar2.192847.12622@helios.physics.utoronto.ca> neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) writes: >> >> I've been having some problems recently. Is there any reason that the >>command: fprintf(stderr,"Testing\n"); shouldn't work in a long program? >>I don't have to open the file, it's standard open when run from the >>shell. If I change it to printf("Testing\n"); everything works. > fprintf(stderr,"Testing\n") has worked fine for me in programs. > It worked for me a few times, then I lengthened the program and it stopped working. >> Other weird things include programs which run fine, but if you use >>the "variables" command to monitor one of the variables, it immediately >>crashes Prizm into the monitor, until you rename the variable in the >>source code. No variable name conflicts were involved. > > Oh! You're in Prizm. Now I see the problem... > > Prizm isn't worth the iron it's encoded on. >Hopefully the new version will fix the almost infinite problems with Prizm, >and make it useful. > I agree that using Prizm is an experience not to be enjoyed. I write my programs from the shell on MicroEMACS. When it comes to debugging, though, Prizm is less trouble than putting "printf()" commands everywhere you'd like to check variables. The variables package also doesn't handle arrays very well. I keep having to create dummy variables and lines which assign array elements to the variable so that I can view them with the variables package. Variables doesn't seem to handle structure elements at all, though it will give the pointer to the structure. > Orca/C 1.2 is now in beta. Mike says he's going to be working on it >thru next week. 1.2b1 has fixed 15 bugs supposedly. > I'm glad to hear it. It's a very nice package, despite the annoying problems with the desktop environment. -- Christopher Neufeld....Just a graduate student | Note: new host. neufeld@aurora.physics.utoronto.ca Ad astra! | helios will still cneufeld@{pnet91,pro-cco}.cts.com | forward my mail to "Don't edit reality for the sake of simplicity" | me on aurora.
gwyn@smoke.brl.mil (Doug Gwyn) (03/03/91)
In article <1991Mar2.192847.12622@helios.physics.utoronto.ca> neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) writes: > I've been having some problems recently. Is there any reason that the >command: fprintf(stderr,"Testing\n"); shouldn't work in a long program? So far as I know, it should work just fine -- providing that your code is strictly conforming (i.e. you need to #include <stdio.h>). > Is there any word on whether the upgrade will fix the problem in the >debugger which keeps the arrow from being visible, or the window from >scrolling to follow the arrow until after it makes its first subroutine >call, and sometimes not even then? The arrow will be visible if the entire path to the source file, including all directories and the file itself, use only UPPER-case characters. This deficiency in PRIZM is supposed to be fixed in a forthcoming release.
acmfiu@serss0.fiu.edu (ACMFIU) (03/07/91)
In article <1991Mar2.192847.12622@helios.physics.utoronto.ca> neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) writes: > > I've been having some problems recently. Is there any reason that the >command: fprintf(stderr,"Testing\n"); shouldn't work in a long program? >I don't have to open the file, it's standard open when run from the >shell. If I change it to printf("Testing\n"); everything works. > Other weird things include programs which run fine, but if you use >the "variables" command to monitor one of the variables, it immediately >crashes Prizm into the monitor, until you rename the variable in the >source code. No variable name conflicts were involved. > When I had a doubly defined #define argument, it issued the >appropriate error message and line and column numbers in the source >file, but it echoed the line after the error, which was another #define. >It took me a while to figure out that the line echoed in the error >message was not the one which caused the offense. > Is there any word on whether the upgrade will fix the problem in the >debugger which keeps the arrow from being visible, or the window from >scrolling to follow the arrow until after it makes its first subroutine >call, and sometimes not even then? Chris, i've also noticed these bugs. i have a 3000+ line program that i wrote and when you invoked it with a '-h' option for help on what further options were available, i used fprintf (stderr, <str>) to output the info. well, it didn't work. oddly enough, when i was going to report some bugs to mike last week i tried it again and it did work. i've been unable to recreate the bug as of yet. however, i am still hoping to do so. let mike know immediately about your bug as he's working on bug fixes now for the update to orca/c. call him if you can. if it's a small program, e-mail it to me and i will send it to him on america online. regarding prizm, you will see an updated version of prizm when orca/c v1.2 is released. i think that release of prizm should correct most of the bugs. albert
bclark@pro-harvest.cts.com (Brian Clark) (03/07/91)
In-Reply-To: message from neufeld@aurora.physics.utoronto.ca >From: neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) > > I've been having some problems recently. Is there any reason that the >command: fprintf(stderr,"Testing\n"); shouldn't work in a long program? >I don't have to open the file, it's standard open when run from the >shell. If I change it to printf("Testing\n"); everything works. > I've had this happen to me also... The funniest thing is that I can get the fprintf(stderr, "8^)"); to work fine if the text editor isn't memory resident... (I'm using only the text shell and editor, not Prizm). A hack to get the editor out of memory is this stupid program: This purges everything purgable from memory as you can guess. #include <orca.h> #include <memory.h> void main (void) { NewHandle ( TotalMem(), userid(), 0x0000, NIL ); } I believe ORCA/M customers have an update to the shell/editor, but I have not seen an update offer for ORCA/C customers. My guess is that ByteWorks is waiting till they finish more revisions on ORCA/C itself rather than just the shell and/or text enviorment editor. Prizm needs work also. ___________________________________________________________________ | ||| | | Brian Clark ||| \ ProLine: bclark@pro-harvest | |------------------|-|--=> InterNet: bclark@pro-harvest.cts.com | | "][gs Forever!!" ||| / UUCP: crash!pro-harvest!bclark | |__________________|||______________________________________________|