codewarrior 8.0 debugger is a slug

codewarrior 8.0 debugger is a slug

Post by anal_aviato » Sun, 05 Jan 2003 19:41:27



Hi,
I have been using code warriot products for many years,
my last purchase was cw5 , that i use for c++ & java under os9.2.2
carbon 1.6

i went and got CW8, compiled my java project and ran the de*.

the machine hung for a couple of minutes, then hit the java breakpoint
it then took about 20 seconds to update each of the variables on the right
hand side, then another 40 seconds to redraw the bits of the de* screen
overwritten by other windows.
single stepping the code takes about 1 minute per line, but is faster if ii
bring the debug app to the foreground.

taking the project back to 5.0 and everything is great.
have i missed somthing silly.

 
 
 

codewarrior 8.0 debugger is a slug

Post by stev » Mon, 06 Jan 2003 06:59:06


On Sat, 4 Jan 2003 22:58:28 +0800, MW Ron wrote



>> Hi,
>> I have been using code warriot products for many years,
>> my last purchase was cw5 , that i use for c++ & java under os9.2.2
>> carbon 1.6

>> i went and got CW8, compiled my java project and ran the de*.

>> the machine hung for a couple of minutes, then hit the java breakpoint
>> it then took about 20 seconds to update each of the variables on the right
>> hand side, then another 40 seconds to redraw the bits of the de*
>> screen
>> overwritten by other windows.
>> single stepping the code takes about 1 minute per line, but is faster if
>> ii
>> bring the debug app to the foreground.

>> taking the project back to 5.0 and everything is great.
>> have i missed somthing silly.

> No you would have had the same problem with CW 5 if you were using the
> SUN API you just forgot about this.  In CW 5 we moved from MetroNub
> debugging to the SUN API  but you could still use the MetroNub with CW 5
> if you set it up.   You probably set it up but forgot about it.

> The debugging is much faster in OS X for Java and it lets us support the
> newer VMs and JDK versions but if you are running on Mac OS 9.  the
> stepping is just slow slow slow.

> Ron

gosh thanks ron , but i am not using os x

1.how can i fix it?

2.so why does the CW de* screen take so long to draw each line, for the
variables, this is just unuseable, and i cannot believe that metrowerks would
release such a poor implementation.

steve

 
 
 

codewarrior 8.0 debugger is a slug

Post by Eric Alber » Mon, 06 Jan 2003 10:46:59




> On Sat, 4 Jan 2003 22:58:28 +0800, MW Ron wrote



> >> i went and got CW8, compiled my java project and ran the de*.

> >> the machine hung for a couple of minutes, then hit the java
> >> breakpoint it then took about 20 seconds to update each of the
> >> variables on the right hand side, then another 40 seconds to
> >> redraw the bits of the de* screen overwritten by other
> >> windows. single stepping the code takes about 1 minute per line,
> >> but is faster if ii bring the debug app to the foreground.

> >> taking the project back to 5.0 and everything is great.
> >> have i missed somthing silly.

> > No you would have had the same problem with CW 5 if you were using the
> > SUN API you just forgot about this.  In CW 5 we moved from MetroNub
> > debugging to the SUN API  but you could still use the MetroNub with CW 5
> > if you set it up.   You probably set it up but forgot about it.

> > The debugging is much faster in OS X for Java and it lets us support the
> > newer VMs and JDK versions but if you are running on Mac OS 9.  the
> > stepping is just slow slow slow.
> gosh thanks ron , but i am not using os x

> 1.how can i fix it?

Upgrade to Mac OS X or downgrade to CodeWarrior Pro 5.

Metrowerks didn't have any control over this, unfortunately, and there's
nothing they can do about it.  The problem is that MRJ had to move to
the Sun debugging API, and that API happens to work very poorly for
classic Mac OS.

The API requires local networking between two applications -- the Java
app and the de* -- and in a cooperatively threaded system like Mac
OS 9, local networking works very poorly.  The API requires many context
switches between the JVM and the de* for each operation.  In
classic Mac OS, context switches don't happen without explicit work from
the current frontmost application.  Apple and Metrowerks worked together
to add the appropriate calls on both sides to make things work, but
making things fast would've required massive changes that simply weren't
possible as both companies faced the Mac OS X transition.

Hope this helps explain things,
Eric
(once upon a time on Apple's Java team)

--

http://www.veryComputer.com/~ejalbert/

 
 
 

codewarrior 8.0 debugger is a slug

Post by MW Ro » Wed, 08 Jan 2003 02:10:28




>gosh thanks ron , but i am not using os x

>1.how can i fix it?

You could try using the metroNub fix for CW 5, (see your release notes)
in the CW 8 version but I don't know if anyone has tried this myeslf.  
Other than that there isn't much you can do.

Quote:>2.so why does the CW de* screen take so long to draw each line, for the
>variables, this is just unuseable, and i cannot believe that metrowerks would
>release such a poor implementation.

Eric explained it.  For Apple this was a good deal it leveled the
playing field so other vendors could bring their tools for Java to Mac.  
For us it took away one of our advantages  (we still have native
compilers and small fast IDE's).

Ron

--
     Free Programming Courses at CodeWarrior U
          <http://www.veryComputer.com/>

 Metrowerks, maker of CodeWarrior  -  "Software Starts Here"  

 
 
 

codewarrior 8.0 debugger is a slug

Post by stev » Wed, 08 Jan 2003 15:05:16


On Tue, 7 Jan 2003 1:10:28 +0800, MW Ron wrote



>> gosh thanks ron , but i am not using os x

>> 1.how can i fix it?

> You could try using the metroNub fix for CW 5, (see your release notes)
> in the CW 8 version but I don't know if anyone has tried this myeslf.  
> Other than that there isn't much you can do.

>> 2.so why does the CW de* screen take so long to draw each line, for
>> the
>> variables, this is just unuseable, and i cannot believe that metrowerks
>> would
>> release such a poor implementation.

> Eric explained it.  For Apple this was a good deal it leveled the
> playing field so other vendors could bring their tools for Java to Mac.  
> For us it took away one of our advantages  (we still have native
> compilers and small fast IDE's).

> Ron

O.K thanks, that explains it more clearly.
I'll keep my CW8 for when i upgrade to osx. currently i'm stuck with legacy
apps ( foxpro), that is preventing my upgrade.

steve

 
 
 

codewarrior 8.0 debugger is a slug

Post by Thomas Engelmeie » Wed, 08 Jan 2003 20:00:26




> O.K thanks, that explains it more clearly.
> I'll keep my CW8 for when i upgrade to osx. currently i'm stuck with legacy
> apps ( foxpro), that is preventing my upgrade.

Given you have enough memory (384 MB+) and at least a 300 Mhz machine,
FoxPro should run in classic. Legacy apps and OS X are not mutually
exclusive.

Regards,
       Tom_E

--
This address doesn't need demangling but will expire soon.

By sending unsolicited bulk mails (UBE, Spam) to this address you agree
to pay me not less than $200 processing fee for canceling your accounts

 
 
 

codewarrior 8.0 debugger is a slug

Post by stev » Sat, 11 Jan 2003 08:18:11


On Tue, 7 Jan 2003 19:00:26 +0800, Thomas Engelmeier wrote



>> O.K thanks, that explains it more clearly.
>> I'll keep my CW8 for when i upgrade to osx. currently i'm stuck with
>> legacy
>> apps ( foxpro), that is preventing my upgrade.

> Given you have enough memory (384 MB+) and at least a 300 Mhz machine,
> FoxPro should run in classic. Legacy apps and OS X are not mutually
> exclusive.

> Regards,
>        Tom_E

Ahhhh!!!
memory is not a problem 1gig should do it, but i'm on a umax S900, with g4
upgrade.

so i could run my legacy stuff in 9 and my java apps in 10,  is it done in
windows, or when 9 opens does it take the whole screen (as in current 9 only
situations)

 
 
 

codewarrior 8.0 debugger is a slug

Post by Thomas Engelmeie » Sat, 11 Jan 2003 21:28:35




> Ahhhh!!!
> memory is not a problem 1gig should do it, but i'm on a umax S900, with g4
> upgrade.

PCI transfer rates (e.g. to the graphic card) will be an bottleneck.

Quote:> so i could run my legacy stuff in 9 and my java apps in 10,  is it done in
> windows, or when 9 opens does it take the whole screen (as in current 9 only
> situations)

Classic is an process, but has not an "Classic window" like an
redmontish MDI interface. Any classic app has it's normal windows,
though they have the OS9 appearance instead of Aqua appearance.

Regards,
        Tom_E

--
This address doesn't need demangling but will expire soon.

By sending unsolicited bulk mails (UBE, Spam) to this address you agree
to pay me not less than $200 processing fee for canceling your accounts

 
 
 

1. Porting Programs from Codewarrior 5.0 to Codewarrior 8.0

Hi,

I had written a small Palm application in Codewarrior 5.0. This
application works absolutely fine.

After getting the Codewarrior 8.0, I tried to open my 5.0 project in
Codewarrior 8.0. After giving an intial dialog telling me that the
project would need to be modified it opened up after giving me a few
errors.

One of the project errors that is gives me is
" The following access path in target "Sales" cannot be found:
  {Compiler}Palm OS 3.0 Support"

When I try to compile my code the header files dont open.

Is there any specific setting that I need to set in the project or
Linker properties that I am unaware of.

Can anyone shed some light on this problem

Regards
Ali

2. BootWarePLUS for OS/2?

3. Linking error with Codewarrior 8.0

4. different head entry and toc entry

5. REQ: Codewarrior 8.0 for Palm OS

6. persistant error & warning

7. CleatType fonts blurry in Codewarrior 8.0 (running XP of course)

8. FS: HandyBoard (68HC11) MicroController Board

9. Mac OS X CodeWarrior debugger problem

10. CodeWarrior COM API & debugger

11. Setowner using CodeWarrior Debugger

12. Codewarrior Debugger Freezes

13. New CodeWarrior Debugger Plugins