Spin 1.10 works in 6.2.0, but not in my 6.2.1 installation. Is this a known
compatibility issue, or perhaps is my 6.2.1 installation broken?
Thanks,
Marty Doane
Siemens Dematic
QNX has either fixed or broke something in 6.2.1 
“Marty Doane” <martin.doane@siemens.com> wrote in message
news:b3iqgr$d3j$1@nntp.qnx.com…
Spin 1.10 works in 6.2.0, but not in my 6.2.1 installation. Is this a
known
compatibility issue, or perhaps is my 6.2.1 installation broken?Thanks,
Marty Doane
Siemens Dematic
Marty…
Have you tried compiling the source?
Miguel.
Marty Doane wrote:
Spin 1.10 works in 6.2.0, but not in my 6.2.1 installation. Is this a known
compatibility issue, or perhaps is my 6.2.1 installation broken?Thanks,
Marty Doane
Siemens Dematic
No, I got the binary from the 3rd party repository.
Marty Doane
Siemens Dematic
“Miguel Simon” <simon@ou.edu> wrote in message
news:3E5D2866.7070504@ou.edu…
Marty…
Have you tried compiling the source?
Miguel.
Marty Doane wrote:
Spin 1.10 works in 6.2.0, but not in my 6.2.1 installation. Is this a
known
compatibility issue, or perhaps is my 6.2.1 installation broken?Thanks,
Marty Doane
Siemens Dematic
\
“Miguel Simon” <> simon@ou.edu> > wrote in message
news:> 3E5D2866.7070504@ou.edu> …
Marty…Have you tried compiling the source?
Miguel.
Marty Doane wrote:
Spin 1.10 works in 6.2.0, but not in my 6.2.1 installation. Is this a
known
compatibility issue, or perhaps is my 6.2.1 installation broken?
Try altering the refresh rate by using the -t option and it should
start working for you again.
Peter
Try altering the refresh rate by using the -t option and it should
start working for you again.
This bug has been fixed for the release of the 6.2.1 Public CD. There
was a bug in Spin where it wasn’t checking return values and setting up
itime values properly. It looks like timer_settime() got a little more
strict between 6.2.0 and 6.2.1 where one cannot set the nsec value to
more then 1 second (as it should be then in the sec value).
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Muhahahaha…
I am sure that is hidden somewhere in the release notes, only I can’t see it
right? 
Gotta love this ‘getting stricter’ game.
“Chris McKillop” <cdm@qnx.com> wrote in message
news:b4bt73$7d$1@nntp.qnx.com…
Try altering the refresh rate by using the -t option and it should
start working for you again.
This bug has been fixed for the release of the 6.2.1 Public CD. There
was a bug in Spin where it wasn’t checking return values and setting up
itime values properly. It looks like timer_settime() got a little more
strict between 6.2.0 and 6.2.1 where one cannot set the nsec value to
more then 1 second (as it should be then in the sec value).chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Igor Kovalenko <kovalenko@attbi.com> wrote:
Muhahahaha…
I am sure that is hidden somewhere in the release notes, only I can’t see it
right? >Gotta love this ‘getting stricter’ game.
Gotta love code that never checks any return values.
If you check POSIX 1003.1-2001 (System Interfaces) lines 46942 to 46945
you will see that your code was wrong and just happened to work before.
So should we take flack for your lack of understanding of the API you are
invoking? The flack we should be taking is for allowing it in the first
place.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
“Chris McKillop” <cdm@qnx.com> wrote in message
news:b4ilhu$8jk$1@nntp.qnx.com…
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
Muhahahaha…
I am sure that is hidden somewhere in the release notes, only I can’t
see it
right? >Gotta love this ‘getting stricter’ game.
Gotta love code that never checks any return values. >If you check POSIX 1003.1-2001 (System Interfaces) lines 46942 to 46945
you will see that your code was wrong and just happened to work before.
So should we take flack for your lack of understanding of the API you are
invoking? The flack we should be taking is for allowing it in the first
place.
I never implied you should be taking anything for my alleged lack of
understanding (which actually was lack of attention because the code was
born as a quick hack for private use). I only noticed that the change that
broke compatibility was not even mentioned anywhere in the release notes.
The flack you should be taking is for failing to ensure compatibility. This
should NOT happen between minor releases. They are supposed to be binary
compatible. Other systems have dealt with this in various ways, including
‘bug emulation’ options. Every minor update of NTO2/QNX6 has given us
similar issues - sudden change of behavior without a word of warning. Sure
it is nice to have an ideal world in which ideal programmers make ideal use
of API. You can keep dreaming, but it pisses management off big time when
stuff like that happens. They have less than perfect people and less than
perfect code. They aren’t anxious to sip through all gazillion lines of it
just because QNX has decided ‘we should not have allowed this in the first
place’.
Of course I am dreaming about an ideal world now. In real life we have less
than perfect OSes, that sometimes do break compatibility. Usually they do
document that though…
Igor Kovalenko wrote:
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:b4ilhu$8jk$> 1@nntp.qnx.com> …Igor Kovalenko <> kovalenko@attbi.com> > wrote:
Muhahahaha…
I am sure that is hidden somewhere in the release notes, only I can’tsee it
right? >
Gotta love this ‘getting stricter’ game.
Gotta love code that never checks any return values. >If you check POSIX 1003.1-2001 (System Interfaces) lines 46942 to 46945
you will see that your code was wrong and just happened to work before.
So should we take flack for your lack of understanding of the API you are
invoking? The flack we should be taking is for allowing it in the first
place.
I never implied you should be taking anything for my alleged lack of
understanding (which actually was lack of attention because the code was
born as a quick hack for private use). I only noticed that the change that
broke compatibility was not even mentioned anywhere in the release notes.The flack you should be taking is for failing to ensure compatibility.
/irony on
Why should they care about … the failure is always only in the
applications of the customers
/irony off
This
should NOT happen between minor releases. They are supposed to be binary
compatible. Other systems have dealt with this in various ways, including
‘bug emulation’ options. Every minor update of NTO2/QNX6 has given us
similar issues - sudden change of behavior without a word of warning. Sure
it is nice to have an ideal world in which ideal programmers make ideal use
of API. You can keep dreaming, but it pisses management off big time when
stuff like that happens. They have less than perfect people and less than
perfect code. They aren’t anxious to sip through all gazillion lines of it
just because QNX has decided ‘we should not have allowed this in the first
place’.Of course I am dreaming about an ideal world now. In real life we have less
than perfect OSes, that sometimes do break compatibility. Usually they do
document that though…
It’s different if you are using an open source RTOS …
Armin
Igor Kovalenko <kovalenko@attbi.com> wrote:
: I never implied you should be taking anything for my alleged lack of
: understanding (which actually was lack of attention because the code was
: born as a quick hack for private use). I only noticed that the change that
: broke compatibility was not even mentioned anywhere in the release notes.
You’re right; that should have been in the release notes. I’ve looked into
this, and there seem to be four functions that are now stricter about the
number of nanoseconds:
clock_settime()
nanosleep()
sigtimedwait()
timer_settime()
I’ll update the release notes for the website. Thanks.
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
“Steve Reid” <stever@qnx.com> wrote in message
news:b4l4v8$ra0$1@nntp.qnx.com…
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
: I never implied you should be taking anything for my alleged lack of
: understanding (which actually was lack of attention because the code was
: born as a quick hack for private use). I only noticed that the change
that
: broke compatibility was not even mentioned anywhere in the release
notes.You’re right; that should have been in the release notes. I’ve looked into
this, and there seem to be four functions that are now stricter about the
number of nanoseconds:clock_settime()
nanosleep()
sigtimedwait()
timer_settime()I’ll update the release notes for the website. Thanks.
Thanks for looking into it Steve!
– igor
Igor Kovalenko <kovalenko@attbi.com> wrote:
: Thanks for looking into it Steve!
You’re welcome. I also created a PR to get the docs for those functions
updated.