Experiences with VxWorks compared to QNX

QNX Newsgroups (Archives) qdn.public.qnxrtp.advocacy
61

It is pretty much as quick. Plus you get a backtrace of function calls
leading to crash.

“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.020215182856.1844A@schoenbrun.com…

Previously, Wojtek Lerch wrote in qdn.public.qnxrtp.advocacy:

Most of the time, a debugger is also the quickest way to find out why
your code crashes.

Back in the not so distant past, I would record the address that
a program was crashing at, look up the location in the link map.
I guess doing it with a debugger is about as quick.


Mitchell Schoenbrun --------- > maschoen@pobox.com

62

Igor Kovalenko <kovalenko@attbi.com> wrote:

It is pretty much as quick. Plus you get a backtrace of function calls
leading to crash.

Plus you can look at your variables, without having to add new printfs
and recompile and rerun every time it turns out that a variable that you
haven’t thought of is relevant.

Plus, sometimes you can put a breakpoint somewhere a bit before the
crash, and single-step from there. Useful to find out why a pointer
became NULL and caused the crash…

“Mitchell Schoenbrun” <> maschoen@pobox.com> > wrote in message
news:> Voyager.020215182856.1844A@schoenbrun.com> …
Previously, Wojtek Lerch wrote in qdn.public.qnxrtp.advocacy:

Most of the time, a debugger is also the quickest way to find out why
your code crashes.

Back in the not so distant past, I would record the address that
a program was crashing at, look up the location in the link map.
I guess doing it with a debugger is about as quick.


Mitchell Schoenbrun --------- > maschoen@pobox.com
\

–
Wojtek Lerch QNX Software Systems Ltd.

63

Rennie Allen <rallen@csical.com> wrote:

Wojtek Lerch wrote:

Most of the time, a debugger is also the quickest way to find out why
your code crashes. But if my code seems to be doing the right thing,
I usually can think of better ways of making sure that it indeed is
correct than running it under a debugger…

Unless your code is safety critical control software, in which case you
must know that it is doing the right thing, regardless of what black
box testing implies that it is doing. That said, most of the software
that falls into this category can’t be stepped through with a debugger
anyway…

A debugger is much more helpful in finding out what goes wrong in one
particular scenario, than in prooving that nothing can go wrong in any
possible scenario. In most cases, you simply don’t have enough time to
run all the possible scenarios under the debugger…

–
Wojtek Lerch QNX Software Systems Ltd.

64

Previously, Wojtek Lerch wrote in qdn.public.qnxrtp.advocacy:

It is pretty much as quick. Plus you get a backtrace of function calls
leading to crash.

Plus you can look at your variables, without having to add new printfs
and recompile and rerun every time it turns out that a variable that you
haven’t thought of is relevant.

Plus, sometimes you can put a breakpoint somewhere a bit before the
crash, and single-step from there. Useful to find out why a pointer
became NULL and caused the crash…

Well, these are all good points. My own personal experience is that
just knowing where the crash happens is usually enough. I spend my
mental energy looking at my code, rather than tracing how the problem
got there. This works pretty well. In past ages when I would create
more “exciting” debugging experiences, a debugger was more useful,
and even required.


Mitchell Schoenbrun --------- maschoen@pobox.com

65

Wojtek Lerch wrote:


A debugger is much more helpful in finding out what goes wrong in one
particular scenario, than in prooving that nothing can go wrong in any
possible scenario. In most cases, you simply don’t have enough time to
run all the possible scenarios under the debugger…

I agree. In most cases you don’t have enough time to test all (or even
most) of the scenerios. That is why I said that “I try” to run the code
through in the debugger after initial implementation. The goal of
stepping through with the debugger, is exactly the same as a code
walkthrough, to validate that the implementation is reasonable, and that
it is doing (at least in the most common code paths) what the designer
intended (not to prove that the design is inviolate :slight_smile: In doing this I
have (on more than one occasion - although not frequently) found that
externally, the code appeared to be behaving as designed, but when
stepping through with the debugger, it could be clearly seen that
undesirable side-effects were taking place.

66

I have to disagree on this point, and it’s a fair few years since I turned
out of university. A good IDE, and begrudgingly I must admit to liking MS
Visual Studio, can save much development time.

BTW, there’s rumours about new IDE for QNX6 from QSSL.
Does anybody knows when it’s available?

67

Links to that subject:
http://www.qnx.com/testdrive/QNXIDEdatasheet.pdf
http://www.eclipse.org/
http://www.eclipse.org/eclipse/eclipse_project_plan_2_0_rev0214.html

Werner Schweizer

“Dmitri” <ivdal@yahoo.com> schrieb im Newsbeitrag
news:a6s8c8$ktd$1@inn.qnx.com…

I have to disagree on this point, and it’s a fair few years since I
turned
out of university. A good IDE, and begrudgingly I must admit to liking
MS
Visual Studio, can save much development time.

BTW, there’s rumours about new IDE for QNX6 from QSSL.
Does anybody knows when it’s available?

68

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C923A9F.1DD2A7F1@web_.de…

Werner Schweizer wrote:

Links to that subject:
http://www.qnx.com/testdrive/QNXIDEdatasheet.pdf

Reading this data sheet … I wonder if this IDE is using native Photon
by JNI or is it
using an AWT API based on Photon … or X11 ??

The IDE is written in JAVA.

Armin


http://www.eclipse.org/
http://www.eclipse.org/eclipse/eclipse_project_plan_2_0_rev0214.html

Werner Schweizer

“Dmitri” <> ivdal@yahoo.com> > schrieb im Newsbeitrag
news:a6s8c8$ktd$> 1@inn.qnx.com> …

I have to disagree on this point, and it’s a fair few years since I
turned
out of university. A good IDE, and begrudgingly I must admit to
liking
MS
Visual Studio, can save much development time.

BTW, there’s rumours about new IDE for QNX6 from QSSL.
Does anybody knows when it’s available?

69

Werner Schweizer wrote:

Links to that subject:
http://www.qnx.com/testdrive/QNXIDEdatasheet.pdf

Reading this data sheet … I wonder if this IDE is using native Photon
by JNI or is it
using an AWT API based on Photon … or X11 ??

Armin


http://www.eclipse.org/
http://www.eclipse.org/eclipse/eclipse_project_plan_2_0_rev0214.html

Werner Schweizer

“Dmitri” <> ivdal@yahoo.com> > schrieb im Newsbeitrag
news:a6s8c8$ktd$> 1@inn.qnx.com> …

I have to disagree on this point, and it’s a fair few years since I
turned
out of university. A good IDE, and begrudgingly I must admit to liking
MS
Visual Studio, can save much development time.

BTW, there’s rumours about new IDE for QNX6 from QSSL.
Does anybody knows when it’s available?

70

Actually, Eclipse uses IBM’s widget toolkit SWT. This is an attempt at a
one to one mapping of java calls to gui calls, based on the premise that
most gui’s provide similar functionality (ie scrollbars, buttons, etc.).
There’s some interesting whitepapers on the eclipse.org site but the gist of
it is that you’re using native widgets that are called by java which gives
some nice performance benefits as well as having a look and feel closer to
that of the host system. (and themes work too)

cheers,

Kris
“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C923A9F.1DD2A7F1@web_.de…

Werner Schweizer wrote:

Links to that subject:
http://www.qnx.com/testdrive/QNXIDEdatasheet.pdf

Reading this data sheet … I wonder if this IDE is using native Photon
by JNI or is it
using an AWT API based on Photon … or X11 ??

Armin


http://www.eclipse.org/
http://www.eclipse.org/eclipse/eclipse_project_plan_2_0_rev0214.html

Werner Schweizer

“Dmitri” <> ivdal@yahoo.com> > schrieb im Newsbeitrag
news:a6s8c8$ktd$> 1@inn.qnx.com> …

I have to disagree on this point, and it’s a fair few years since I
turned
out of university. A good IDE, and begrudgingly I must admit to
liking
MS
Visual Studio, can save much development time.

BTW, there’s rumours about new IDE for QNX6 from QSSL.
Does anybody knows when it’s available?

71

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C924A3D.D85242D7@web_.de…

Kris Warkentin wrote:

Actually, Eclipse uses IBM’s widget toolkit SWT. This is an attempt at
a
one to one mapping of java calls to gui calls, based on the premise that
most gui’s provide similar functionality (ie scrollbars, buttons, etc.).
There’s some interesting whitepapers on the eclipse.org site but the
gist of
it is that you’re using native widgets that are called by java

using JNI ?

Yes.

which gives
some nice performance benefits as well as having a look and feel closer
to
that of the host system. (and themes work too)

Interesting … so it isn’t a threat against Photon > :slight_smile:> . Or ?

Armin


cheers,

Kris

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C923A9F.1DD2A7F1@web_.de…


Werner Schweizer wrote:

Links to that subject:
http://www.qnx.com/testdrive/QNXIDEdatasheet.pdf

Reading this data sheet … I wonder if this IDE is using native
Photon
by JNI or is it
using an AWT API based on Photon … or X11 ??

Armin


http://www.eclipse.org/
http://www.eclipse.org/eclipse/eclipse_project_plan_2_0_rev0214.html

Werner Schweizer

“Dmitri” <> ivdal@yahoo.com> > schrieb im Newsbeitrag
news:a6s8c8$ktd$> 1@inn.qnx.com> …

I have to disagree on this point, and it’s a fair few years
since I
turned
out of university. A good IDE, and begrudgingly I must admit to
liking
MS
Visual Studio, can save much development time.

BTW, there’s rumours about new IDE for QNX6 from QSSL.
Does anybody knows when it’s available?

72

Kris Warkentin wrote:

Actually, Eclipse uses IBM’s widget toolkit SWT. This is an attempt at a
one to one mapping of java calls to gui calls, based on the premise that
most gui’s provide similar functionality (ie scrollbars, buttons, etc.).
There’s some interesting whitepapers on the eclipse.org site but the gist of
it is that you’re using native widgets that are called by java

using JNI ?

which gives
some nice performance benefits as well as having a look and feel closer to
that of the host system. (and themes work too)

Interesting … so it isn’t a threat against Photon :slight_smile:. Or ?

Armin

cheers,

Kris

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C923A9F.1DD2A7F1@web_.de…


Werner Schweizer wrote:

Links to that subject:
http://www.qnx.com/testdrive/QNXIDEdatasheet.pdf

Reading this data sheet … I wonder if this IDE is using native Photon
by JNI or is it
using an AWT API based on Photon … or X11 ??

Armin


http://www.eclipse.org/
http://www.eclipse.org/eclipse/eclipse_project_plan_2_0_rev0214.html

Werner Schweizer

“Dmitri” <> ivdal@yahoo.com> > schrieb im Newsbeitrag
news:a6s8c8$ktd$> 1@inn.qnx.com> …

I have to disagree on this point, and it’s a fair few years since I
turned
out of university. A good IDE, and begrudgingly I must admit to
liking
MS
Visual Studio, can save much development time.

BTW, there’s rumours about new IDE for QNX6 from QSSL.
Does anybody knows when it’s available?

73

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C924A3D.D85242D7@web_.de…

…
Interesting … so it isn’t a threat against Photon > :slight_smile:> . Or ?

It might be a threat to Photon native API but not for Photon itself since
the engine and widget library are provided by Photon. Still, some
applications might prefer to use native Photon API because of performance
and memory consumption considerations. SWT feels much faster than Swing and
actually it is fast enough to feel comfortable on desktop but still it is
not quite as fast as C. Java takes its toll in both CPU and memory usage.

– igor

74

Igor Kovalenko wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C924A3D.D85242D7@web_.de…


…
Interesting … so it isn’t a threat against Photon > :slight_smile:> . Or ?


It might be a threat to Photon native API but not for Photon itself since
the engine and widget library are provided by Photon.

Oh, what a nice statement … especially from you :slight_smile:

OK, then tell me why e.g. wxWindows and Qt could be a thread to Photon
when SWT is acceptable ??

Would be nice if the SWT/Photon interface could also be used for other
languages like Phython. (Jython should work with it …)

Is the SWT implementation freely available for XFree86 ??

Still, some
applications might prefer to use native Photon API because of performance
and memory consumption considerations.

BTW, wxWindows and Qt are C++ based … so there are no performance
problems.

SWT feels much faster than Swing and
actually it is fast enough to feel comfortable on desktop but still it is
not quite as fast as C.

Is SWT in any way compatible to SWING ??

Cheers

Armin

75

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C934D39.6F12F128@web_.de…

Igor Kovalenko wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C924A3D.D85242D7@web_.de…


…
Interesting … so it isn’t a threat against Photon > :slight_smile:> . Or ?


It might be a threat to Photon native API but not for Photon itself
since
the engine and widget library are provided by Photon.

Oh, what a nice statement … especially from you > :slight_smile:

OK, then tell me why e.g. wxWindows and Qt could be a thread to Photon
when SWT is acceptable ??

SWT maps Java classes into Photon widgets. Qt (last time I checked) has
hardware abstraction layer with their own drawing primitives. That means
they have their own widgets and map only low level drawing primitives. The
result is okay wrt speed, but it looks ‘alien’ in the environment. And it
would not provide integration with other applications, like drag and drop
(not without additional work). What you get is essentialy another
environment, which only shares graphics drivers and Photon engine, just like
Xphoton.

I don’t know what is situation with wxWindows, did not look into their
code.

Would be nice if the SWT/Photon interface could also be used for other
languages like Phython. (Jython should work with it …)

Is the SWT implementation freely available for XFree86 ??

Not sure, but I’d think so.

Still, some
applications might prefer to use native Photon API because of
performance
and memory consumption considerations.

BTW, wxWindows and Qt are C++ based … so there are no performance
problems.

I’ve read Qt code.

SWT feels much faster than Swing and
actually it is fast enough to feel comfortable on desktop but still it
is
not quite as fast as C.

Is SWT in any way compatible to SWING ??

Compatible? What that would mean? There is no integration between them,
AFAIK. Swing is bigger and more generalized system.

  • igor
76

Igor Kovalenko wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C934D39.6F12F128@web_.de…


Igor Kovalenko wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C924A3D.D85242D7@web_.de…


…
Interesting … so it isn’t a threat against Photon > :slight_smile:> . Or ?


It might be a threat to Photon native API but not for Photon itself
since
the engine and widget library are provided by Photon.

Oh, what a nice statement … especially from you > :slight_smile:

OK, then tell me why e.g. wxWindows and Qt could be a thread to Photon
when SWT is acceptable ??

SWT maps Java classes into Photon widgets. Qt (last time I checked) has
hardware abstraction layer

No, this was only true for the ealier versions of Qt … I’m talking
about the classic X11 based Qt version. The Xlib isn’t a hardware
abstraction layer …

with their own drawing primitives. That means
they have their own widgets and map only low level drawing primitives. The
result is okay wrt speed, but it looks ‘alien’ in the environment.

I’m not convienced … a XPhoton application e.g doesn’t look ‘alien’ in
Photon.

And it
would not provide integration with other applications, like drag and drop
(not without additional work). What you get is essentialy another
environment, which only shares graphics drivers and Photon engine, just like
Xphoton.

Whay not only sharing graphics drivers and the Photon engine if I get
back a nice object oriented GUI API and an itegration into Photon like
XPhoton??

I don’t know what is situation with wxWindows, did not look into their
code.

I heard that the first steps of a port should not be very complicate …

Would be nice if the SWT/Photon interface could also be used for other
languages like Phython. (Jython should work with it …)

Is the SWT implementation freely available for XFree86 ??


Not sure, but I’d think so.

[ clip …]
Is SWT in any way compatible to SWING ??


Compatible? What that would mean? There is no integration between them,

So SWT is a proprietary niche of IBM … no ‘write once … run
everywhere’ !

Armin

77

Armin Steinhoff wrote:


I’m not convienced … a XPhoton application e.g doesn’t look ‘alien’ in
Photon.

Huh ? Beside the fact that the user interface looks completely
different, and cut & paste doesn’t work between native Photon apps and
Xphoton apps :wink:

78

Rennie Allen wrote:

Armin Steinhoff wrote:


I’m not convienced … a XPhoton application e.g doesn’t look ‘alien’ in
Photon.

Huh ? Beside the fact that the user interface looks completely
different, and cut & paste doesn’t work between native Photon apps and
Xphoton apps > :wink:

Ok … then try to use cut & paste for Voyager :slight_smile:

79

On Mon, 18 Mar 2002 11:33:31 +0100, Armin Steinhoff
<a-steinhoff@web_.de> wrote:

So SWT is a proprietary niche of IBM … no ‘write once … run
everywhere’ !

Armin

Ummm, what? Swing is necessary for WORA? Must be pain for all of the
cell phone developers then.

I think even Sun has realized WORA is not absolute. At ESC last year
they were talking about WOCRAC (Write Once Carefully Run Anywhere
Conditionally).

Anyway, it also depends on where you draw the WORA line. I can run an
SWT app on Photon, Motif, win32, winCE, Qt/e. GTK and Mac OS ports are
coming.

Plus, SWT is currently open source/CPL on www.eclipse.org, and I have
heard IBM intends to run SWT through JCP. Not proprietary.

-Andrew

80

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C9644F2.F7C62C03@web_.de…

Rennie Allen wrote:

Armin Steinhoff wrote:


I’m not convienced … a XPhoton application e.g doesn’t look ‘alien’
in
Photon.

Huh ? Beside the fact that the user interface looks completely
different, and cut & paste doesn’t work between native Photon apps and
Xphoton apps > :wink:

Ok … then try to use cut & paste for Voyager > :slight_smile:

Ctrl-Alt-C / Ctrl-Alt-V. Works fine ? :slight_smile:

// wbr