Since upgrading ORCA/C 2.1.0 to 2.2.0 B6 I’m unable to enter the debugger using Prizm...
Since upgrading ORCA/C 2.1.0 to 2.2.0 B6 I’m unable to enter the debugger using Prizm. If I set a breakpoint and try to run or compile I get an undeclared identifier error where the breakpoint is set.
Is this a known thing or is there something I haven’t done that I should? It seems to work using v2.1.0 though I’m having some difficulty using it with a desktop exe.
Unsetting a breakpoint doesn’t work in either version though I’ll be the first to admit I have no experience with it.
So, deal with it and use v2.2.0 B6 or revert to v2.1.0 or…?
On Thursday, December 8, 2022 at 12:23:00 PM UTC-6, justliketom...@gmail.com wrote:ORCA/C 2.2.0 B6.
Since upgrading ORCA/C 2.1.0 to 2.2.0 B6 I’m unable to enter the debugger using Prizm. If I set a breakpoint and try to run or compile I get an undeclared identifier error where the breakpoint is set.
Is this a known thing or is there something I haven’t done that I should? It seems to work using v2.1.0 though I’m having some difficulty using it with a desktop exe.
Unsetting a breakpoint doesn’t work in either version though I’ll be the first to admit I have no experience with it.
So, deal with it and use v2.2.0 B6 or revert to v2.1.0 or…?This sounds like it could be a bug in ORCA/C 2.2.0 B6, but it is not one I'm aware of, and in a couple quick tests I could not reproduce it. I was able to set breakpoints in Prizm, build a small program without errors, and debug it using Prizm with
If you can provide more details, like an example program that has the problem and where exactly you're setting a breakpoint in it, I'd be happy to look into it more.
--
Stephen Heumann
I think my best course of action is a fresh install. Ah, where to start...
On Thursday, December 8, 2022 at 5:50:01 PM UTC-5, stephen...@gmail.com wrote:
If you can provide more details, like an example program that has the problem and where exactly you're setting a breakpoint in it, I'd be happy to look into it more.
Even simplest code setting a break point doesn't work for me:undeclared identifier. It seems the breakpoint is set as a ^D. If I don't set a breakpoint and just select step from the debug menu I can step through the code and display variables in the variable window as expected.
#include <stdio.h>
void main(void)
{
int i,x;
printf("Say what? \n");
for(i = 0; i < 11; i++)
{
x = i * 2;
}
printf("What do you mean?\n");
}
I'll place the cursor at the beginning of the line "x = I * 2;", set a breakpoint, either from the debug menu or OA-H and try to trace through or otherwise compile and I'll get a stop alert "undeclared identifier" . The shell window points to x as an
I'm not sure what I have wrong. I was thinking that updating v2.1.0 to v2.2.0 B6 doesn't overwrite everything and leaves some old stuff untouched and that is where the problem lies but I'm not sure that is so.
On Friday, December 9, 2022 at 7:40:33 AM UTC-6, justliketom...@gmail.com wrote:undeclared identifier. It seems the breakpoint is set as a ^D. If I don't set a breakpoint and just select step from the debug menu I can step through the code and display variables in the variable window as expected.
Even simplest code setting a break point doesn't work for me:
#include <stdio.h>
void main(void)
{
int i,x;
printf("Say what? \n");
for(i = 0; i < 11; i++)
{
x = i * 2;
}
printf("What do you mean?\n");
}
I'll place the cursor at the beginning of the line "x = I * 2;", set a breakpoint, either from the debug menu or OA-H and try to trace through or otherwise compile and I'll get a stop alert "undeclared identifier" . The shell window points to x as an
I tried doing the same thing with the exact code that you posted, and I'm still not seeing the problem. One thing to check is to make sure that there isn't actually an undeclared identifier. If the line is actually "x = I * 2;" with a capital I, thenthat would be an undeclared identifier, since C is case-sensitive. If that's not the issue, then I suspect it's some problem with your setup.
update on top of that, and seeing if you still have the issue there. If not, it was likely a problem with your old installation.I'm not sure what I have wrong. I was thinking that updating v2.1.0 to v2.2.0 B6 doesn't overwrite everything and leaves some old stuff untouched and that is where the problem lies but I'm not sure that is so.It's true that the ORCA/C 2.2.0 B6 update does not overwrite everything, so if there was some problem with your ORCA installation, it might still exist. I'd suggest making a copy of the stock ORCA installation from Opus ][, applying the ORCA/C 2.2.0 B6
--
Stephen Heumann
I'm unaware of Opus ][, I'll have to check into it. I have my original diskettes and copies of ORCA/M and ORCA/C and figured I'd probably reinstall on my IIgs first or maybe make disk images and create a new install with Bernie or KEGS. Finding time tofit that in is a bit problematic but thank you and I'll post what becomes of it when I do.
On Friday, December 9, 2022 at 7:01:21 PM UTC-6, justliketom...@gmail.com wrote:and I'll post what becomes of it when I do.
I have my original diskettes and copies of ORCA/M and ORCA/C and figured I'd probably reinstall on my IIgs first or maybe make disk images and create a new install with Bernie or KEGS. Finding time to fit that in is a bit problematic but thank you
... you can also get a "clean" installation of ORCA/C 2.2.0 B6 by installing ORCA/C 2.1.0 from the original floppy disks, and then applying the ORCA/C 2.2.0 B6 update.
--
Stephen Heumann
After working around that and making the installer happy I have a new installation of ORCA/C and ORCA/M updated to version 2.2.0 B6. Then trying to set a breakpoint, same problem, bummer. But, it was the file that didn’t work before. I created a newfile and set a breakpoint and, yeah, it works but it looks identical to the one that doesn’t. So i’m going through it with a few files, some old , some new, some work, some don’t and thought I was onto some sequence of saving a file and setting a
It all works as it should now with the new install. The old files created with the old installation had some errant entry in the resource fork when a breakpoint was set. I used removerez on an old file that didn’t work and set a breakpoint andrecompiled it and it works as expected.
I had looked at both the older and newer files with a different editor and the character displayed for the breakpoint was different betwen the two; ^D for the former I think and an N under a ~ in the latter.
i guess I could have just said I reinstalled and it’s all good now. Thanks for the help and bearing with me.
On Tuesday, December 13, 2022 at 8:57:55 PM UTC-6, justliketom...@gmail.com wrote:new file and set a breakpoint and, yeah, it works but it looks identical to the one that doesn’t. So i’m going through it with a few files, some old , some new, some work, some don’t and thought I was onto some sequence of saving a file and setting
After working around that and making the installer happy I have a new installation of ORCA/C and ORCA/M updated to version 2.2.0 B6. Then trying to set a breakpoint, same problem, bummer. But, it was the file that didn’t work before. I created a
recompiled it and it works as expected.It all works as it should now with the new install. The old files created with the old installation had some errant entry in the resource fork when a breakpoint was set. I used removerez on an old file that didn’t work and set a breakpoint and
were changed at that time, with corresponding changes to Prizm. If ORCA/C 2.1.0 or later encounters the old debugging characters, it will treat them as accented letters beginning an identifier, leading to the error you saw.I had looked at both the older and newer files with a different editor and the character displayed for the breakpoint was different betwen the two; ^D for the former I think and an N under a ~ in the latter.
i guess I could have just said I reinstalled and it’s all good now. Thanks for the help and bearing with me.I'm glad you got things working now.
In case you're interested, I think I figured out what was going on. ORCA/C 2.1.0 added support for extended characters such as Ñ. The characters used to indicate breakpoints and auto-go points in older versions of ORCA/C conflicted with those, so they
This was a change in ORCA/C 2.1.0 back in 1996, but I think at least parts of your old setup must have been older than that, leading to this problem.have to remove the resource forks too.
Anyhow, you will have to remove any old breakpoints set using the old characters. With some combinations of versions, it might also be possible for the "use old debugging characters" flag to get stored in the resource forks of source files, so you may
--
Stephen Heumann
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 29:49:28 |
| Calls: | 6,669 |
| Calls today: | 1 |
| Files: | 12,216 |
| Messages: | 5,338,039 |