Hi
I’m tying to use SourceNavigator 4.5.1 as development environment , but I’m
already tired of crashes of Xphoton. As I use to move windows here and there
more intensively, crash of Xphoton is guaranteed.
Maybe someone has some notes and solution to this problems?
(I use normal TCP/IP stack (not tiny) on driver ne2000, if it is important)
Best Regards
Jonas Zaveckas
I have simply turned off full window dragging, and I have no Source
Navigator crashes at all (I use Source Navigator all day every day). I
also have 96MB of RAM in my machine, and consider this the minimum
usable for Source Navigator under RtP.
btw: I am using Source Navigator 4.52, and it is available as a one
click repository for RtP at http://www.os-cillo.com under the download
button.
-----Original Message-----
From: Jonas [mailto:jonas@elsis.com]
Posted At: Wednesday, February 21, 2001 7:54 AM
Posted To: devtools
Conversation: Xphoton crashes
Subject: Xphoton crashes
Hi
I’m tying to use SourceNavigator 4.5.1 as development environment , but
I’m
already tired of crashes of Xphoton. As I use to move windows here and
there
more intensively, crash of Xphoton is guaranteed.
Maybe someone has some notes and solution to this problems?
(I use normal TCP/IP stack (not tiny) on driver ne2000, if it is
important)
Best Regards
Jonas Zaveckas
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C902AB30@exchangecal.hq.csical.com…
I have simply turned off full window dragging, and I have no Source
Navigator crashes at all (I use Source Navigator all day every day). I
also have 96MB of RAM in my machine, and consider this the minimum
usable for Source Navigator under RtP.
I just re-read my own post, and as Jonas states it is an Xphoton crash not a
Source Navigator crash. SN is stable. Xphoton + SN is stable as long as
opaque dragging (full window dragging) is not enabled.
What I had meant to say in my original post was that I get no Source
Navigator induced Xphoton crashes 
Rennie
“Jonas” <jonas@elsis.com> wrote in message news:970kf2$chq$2@inn.qnx.com…
Hi
I’m tying to use SourceNavigator 4.5.1 as development environment , but
I’m
already tired of crashes of Xphoton. As I use to move windows here and
there
more intensively, crash of Xphoton is guaranteed.
I beleve Xphoton has very low priority for QSSL when it comes
to bugfixes and improvements. I had a discussion with one of the
developers of Xphoton a while back but nothing came out of that.
It is very sad for my project as I now pretty much have made the
decision to move back to Linux. My application would really have
had an edge if I had RT capabilities in the simulation engine.
The application is a protocol analyser and simulator for GSM, GPRS
and UMTS cellular telecom networks, connecting to the E1/T1 and
155 Mbps ATM interfaces.
Mats
Mats Byggmastar wrote:
“Jonas” <> jonas@elsis.com> > wrote in message news:970kf2$chq$> 2@inn.qnx.com> …
HiI’m tying to use SourceNavigator 4.5.1 as development environment , but
I’m
already tired of crashes of Xphoton. As I use to move windows here and
there
more intensively, crash of Xphoton is guaranteed.I beleve Xphoton has very low priority for QSSL when it comes
to bugfixes and improvements. I had a discussion with one of the
developers of Xphoton a while back but nothing came out of that.It is very sad for my project as I now pretty much have made the
decision to move back to Linux. My application would really have
had an edge if I had RT capabilities in the simulation engine.
The application is a protocol analyser and simulator for GSM, GPRS
and UMTS cellular telecom networks, connecting to the E1/T1 and
155 Mbps ATM interfaces.
Mat,
in the moment I see three alternatives:
Armin
Mats Byggmastar wrote:
“Jonas” <> jonas@elsis.com> > wrote in message news:970kf2$chq$> 2@inn.qnx.com> …
HiI’m tying to use SourceNavigator 4.5.1 as development environment , but
I’m
already tired of crashes of Xphoton. As I use to move windows here and
there
more intensively, crash of Xphoton is guaranteed.I beleve Xphoton has very low priority for QSSL when it comes
to bugfixes and improvements. I had a discussion with one of the
developers of Xphoton a while back but nothing came out of that.It is very sad for my project as I now pretty much have made the
decision to move back to Linux. My application would really have
had an edge if I had RT capabilities in the simulation engine.
The application is a protocol analyser and simulator for GSM, GPRS
and UMTS cellular telecom networks, connecting to the E1/T1 and
155 Mbps ATM interfaces.
Mat,
in the moment I see only three alternatives:
Armin
in the moment I see three alternatives:
- porting XFree86 4.x to QNX Neutrino
I don’t have time or the knowledge (?) to do that.
- porting (if neccessary) your application to BlueCat Linux and
using LynxOS for your real-time performance
LynxOS looks interesting. Is the current stable version as Linux
compatible with X11R6 and everything as they advertise on their webpage?
- using e.g. RTAI Linux
Not an option. RTAI Linux is only RT inside the kernel.
I need all my protocol stacks and simulation engine to
work in RT, and I can not put it all in a kernel module.
Mats
Just curious… what is preventing you from using native
Photon ?
I believe that QSSLs intention for Xphoton is for it to be
used in the way that Jonas, and I are using it (that is in
order to host X based development tools inside the Photon
environment). I don’t believe that QSSL ever intended Xphoton
to be used on targets, it is simply too large and slow for
that purpose (X is bad enough by itself, but hosting it
inside another GUI seems ridiculous for an embedded system).
-----Original Message-----
From: Mats Byggmastar [mailto:mats.byggmastar@multi.NOJUNK.fi]
Posted At: Thursday, February 22, 2001 12:31 AM
Posted To: devtools
Conversation: Xphoton crashes
Subject: Re: Xphoton crashes
“Jonas” <jonas@elsis.com> wrote in message
news:970kf2$chq$2@inn.qnx.com…
Hi
I’m tying to use SourceNavigator 4.5.1 as development environment ,
but
I’m
already tired of crashes of Xphoton. As I use to move windows here and
there
more intensively, crash of Xphoton is guaranteed.
I beleve Xphoton has very low priority for QSSL when it comes
to bugfixes and improvements. I had a discussion with one of the
developers of Xphoton a while back but nothing came out of that.
It is very sad for my project as I now pretty much have made the
decision to move back to Linux. My application would really have
had an edge if I had RT capabilities in the simulation engine.
The application is a protocol analyser and simulator for GSM, GPRS
and UMTS cellular telecom networks, connecting to the E1/T1 and
155 Mbps ATM interfaces.
Mats
Just curious… what is preventing you from using native
Photon ?
Theoretically nothing, but learning Photon is not whitin
our time budget for this project. We have based the GUI on
Qt as we had used Qt successfully for previous projects under
Linux.
Quite long ago, we had QNX sales representatives visiting us,
presenting QNX and RTP for several hours. We was ensured
that it was POSIX compatible and had X support so it would be
real easy to emigrate from the Linux world.
I believe that QSSLs intention for Xphoton is for it to be
used in the way that Jonas, and I are using it (that is in
order to host X based development tools inside the Photon
environment). I don’t believe that QSSL ever intended Xphoton
to be used on targets, it is simply too large and slow for
that purpose (X is bad enough by itself, but hosting it
inside another GUI seems ridiculous for an embedded system).
Well our target system will not be embedded, but run on a
fast desktop or portable PC, probably SMP. We are pretty much
looking for a Linux replacement with has TCP/IP networking,
a nice window system, etc. The basic QNX RTP CD would be just
fine.
Mats
Rennie Allen wrote:
Just curious… what is preventing you from using native
Photon ?
Have a look to qdn.public.qnxrtp.photon. There are also memory leaks
and massive problems if you are using off screen drawing
intensively.
I believe that QSSLs intention for Xphoton is for it to be
used in the way that Jonas, and I are using it (that is in
order to host X based development tools inside the Photon
environment).
Yes … it is (was?) their ‘intention’, but it is until now not a
part of their ‘reliable world’.
I don’t believe that QSSL ever intended Xphoton
to be used on targets, it is simply too large and slow for
that purpose (X is bad enough by itself, but hosting it
inside another GUI seems ridiculous for an embedded system).
That ‘bad X’ works much better than Xphoton and is more reliable
than Photon 2.0 … you can download a working version 3.3.6 at
Sourcforge in a short timeframe … and if theire are problems with
it you have a chance to fix it.
Armin
Quite long ago, we had QNX sales representatives visiting us,
presenting QNX and RTP for several hours. We was ensured
that it was POSIX compatible and had X support so it would be
real easy to emigrate from the Linux world.
Perhaps you misunderstood ? I have never received the impression
from any QSSL presentation that Xphoton is designed to be used on
targets (i.e. neutrino systems). From my perspective it has
always been clear that Xphoton is a tool to help you migrate
from Linux to QNX in two ways:
If you have X based code you can bring over your GUI easily,
while you port your back end code, once your back-end code
is working, then you can (piece by piece) port your GUI to
Photon. Now clearly Xphoton has to work reasonably well to
support this type of activity, but it does not have to work
to the degree that it would have to in order to be
distributed with a product.
It allows you to host the GUI based development tools from
Linux that you are familiar with. Same quality rules apply
as in #1.
Both of these are very significant aids in porting. It is
generally recognized in the QNX community, and in the
programming community at large, that typing “./configure;make”
does not constitute migration to a new platform (pedantic
interpretations aside).
QNX is indeed Posix compatible; unfortunately, there is no
approved Posix standard for GUI api’s. Now, Xphoton doesn’t
work to my satisfaction yet, even for the 2 purposes stated
above, however, it is usable, and I (and I suspect many other
users) will not hold it up to the standards that Photon itself
is held to.
I recognize that switching to Photon is not in your time budget,
but I also find it difficult to believe that QSSL made the
representation that Xphoton could be used in target systems, I
have never seen or heard them make such a representation. Your
statement (above) does not say that they made such a claim, but
it does imply that they did (since you seem to be concerned that
you can’t use Xphoton in this way).
Well our target system will not be embedded, but run on a
fast desktop or portable PC, probably SMP. We are pretty much
looking for a Linux replacement with has TCP/IP networking,
a nice window system, etc. The basic QNX RTP CD would be just
fine.
You must want something else beside what you state above,
otherwise, why not simply stick with Linux ?
Rennie
Perhaps you misunderstood ?
I don’t think so. Our GUI developer stated very clearly that
we was going to use Qt, which relied on X.
Well our target system will not be embedded, but run on a
fast desktop or portable PC, probably SMP. We are pretty much
looking for a Linux replacement with has TCP/IP networking,
a nice window system, etc. The basic QNX RTP CD would be just
fine.You must want something else beside what you state above,
otherwise, why not simply stick with Linux ?
I want something else yes; an OS with real-time capabilities.
Mats