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 1:23:00 PM UTC-5, Tom Thumb wrote:
> Since upgrading ORCA/C 2.1.0 to 2.2.0 B6 I’m unable to enter the debugger using Prizm...

Oh, I've gone over this using KEGS, Bernie ][ the Rescue, and my IIgs thinking it might be an emulator thing. Same results on all.

On Thursday, December 8, 2022 at 12:23:00 PM UTC-6, justliketom...@gmail.com wrote:
> 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 ORCA/C 2.2.0 B6.

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

On Thursday, December 8, 2022 at 5:50:01 PM UTC-5, stephen...@gmail.com wrote:
> On Thursday, December 8, 2022 at 12:23:00 PM UTC-6, justliketom...@gmail.com wrote:
> > 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 ORCA/C 2.2.0 B6.
>
> 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

Oh, so it works for you. Thank you for verifying that. I'm inclined to believe my install is suspect. It's all based on a years old install on my IIgs. It seems to me there are other troubles. I think my best course of action is a fresh install. Ah, where to start...

Curious; compiling from the shell the executable's subtype is $0100 and runs invoked from the shell. Compiling in Prizm the executable's subtype is $DB01. That will run in Prizm's shell window but will crash from the text shell. Is that what is?

On Thursday, December 8, 2022 at 11:37:12 PM UTC-5, Tom Thumb wrote:

>> I think my best course of action is a fresh install. Ah, where to start....

This morning I'm not so sure anymore.

> 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:

#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 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.

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:
> 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 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.

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, then that 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.

> 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 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.

--
Stephen Heumann

On Friday, December 9, 2022 at 4:10:24 PM UTC-5, stephen...@gmail.com wrote:
> On Friday, December 9, 2022 at 7:40:33 AM UTC-6, justliketom...@gmail.com wrote:
> > 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 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.
> 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, then that 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.
> > 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 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.
>
> --
> Stephen Heumann

The "x = I * 2;" was a typo. The code compiles and runs okay if I don't set a breakpoint. I'm having a problem compiling from Prizm also, a bit difficult to go into and describe, I've been compiling and running from the text shelling so hadn't really delved into it until I wanted to set a breakpoint and check something.

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 to fit 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:
> 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 to fit that in is a bit problematic but thank you and I'll post what becomes of it when I do.

Opus ][ is a collection of all the ORCA languages and other Byte Works products, including a disk image with all the software preinstalled. It's available here:
https://juiced.gs/store/opus-ii-software/

That said, 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

On Friday, December 9, 2022 at 8:39:55 PM UTC-5, stephen...@gmail.com wrote:
> On Friday, December 9, 2022 at 7:01:21 PM UTC-6, justliketom...@gmail.com wrote:
> > 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 and I'll post what becomes of it when I do.

> ... 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

While likely not here nor there, but… after some foibles; the power jack has gone flaky on my PB 3400c running Bernie ][ the Rescue, cracked solder joint most likely; I have a VST Zip drive in the expansion bay and a Zip drive hooked up to my IIgs and transfer files between the two that way then FTP them between the PB and my MacBook Pro to use with KEGS; the installer on the disk image didn’t like a disk image in the set to be mounted until it asked for it; gave an I/O error, I forget exactly its lament..

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 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 a breakpoint, but…

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 recompiled 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.

-- Mark Wade

On Tuesday, December 13, 2022 at 8:57:55 PM UTC-6, justliketom...@gmail.com wrote:
> 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 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 a breakpoint, but…
>
> 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 recompiled 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.

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 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.

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.

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 have to remove the resource forks too.

--
Stephen Heumann

On Thursday, December 15, 2022 at 7:00:45 PM UTC-5, stephen...@gmail.com wrote:
> On Tuesday, December 13, 2022 at 8:57:55 PM UTC-6, justliketom...@gmail.com wrote:
> > 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 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 a breakpoint, but…
> >
> > 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 recompiled 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.
> 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 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.
>
> 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..
>
> 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 have to remove the resource forks too.
>
> --
> Stephen Heumann

Yeah, it’s weird. I’m sure you’re right that parts of the old setup were mixed from different versions and thank you for explaining it.

If I take one of those files I made with the old setup and then use it with the new setup it will compile and run okay but if I set a breakpoint (and it does show up as a reddish stylized X) it won’t compile and laments “undeclared identifier”. Then if I remove the resourse fork and open it again in Prizm the breakpoint that was set displays as that Ñ character even though I set it with the newly installed Prizm. If I then delete that character and set a new breakpoint it will work as expected and apparently is no longer being saved in the resource fork and is an entirely different character, though I’m not sure what it is and removing the resource fork doesn’t affect the breakpoint, the file still compiles and runs and the breakpoint works as expected. I’m not sure how well I explained that.

After I posted all was working the next day I couldn’t get anything working except that simple example I posted. All I got no matter what I tried was “### Rez - Unable to access program resource fork”. “Man,” I’m thinking, “what did I do?. So I uninstalled and reinstalled ORCA/C again but left out ORCA/M and all was well.

It seems installing ORCA/M after ORCA/C and updating to 2.2.0 B6 hosed somesuch thing. I used the “install new system” option from the ORCA/C 2.1.0 installer and then the “update system” option in the ORCA/M 2.1.0 installer and I thought that was the correct way to go about it.

With everything working with ORCA I manually added the files specific to ORCA/M and it looks like everything is working as expected.