comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: LONG - reads 4 or 8 bytes??
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: LONG - reads 4 or 8 bytes?? [message #51894] Wed, 13 December 2006 09:25
Rick Towler is currently offline  Rick Towler
Messages: 821
Registered: August 1998
Senior Member
subir wrote:
> Thanks for your reply Rick. Here is the output of running the 'print,
> !Version' on the two workstations.
>
> - Workstation on which LONG reads 4 bytes
> WAVE> print, '!Version
> { sparc solaris 8.50 sun4}
>
> - Workstation on which LONG reads 8 bytes
> WAVE> print, "!Version"
> { sparc solaris64 8.51 b sun4}
>
> Any ideas on how to change the PV-Wave configuration to run the 64-bit
> version?


Just a guess, but look in your PV-Wave install directory and see if
there are 2 executables. Many vendors ship both a 32 and 64-bit version
of their program with their 64-bit version. It might be as simple as
changing your symlink to point to pvwave64 or something like that.

It's been a while since I installed PV-Wave. The newest version I have
around here is 2.01 :) I don't know what's fashionable these days.
/var? /usr/local? Poke around and you should be able to find the
install dir.

Worst case, PV-Wave ships separate 32 or 64-bit versions and you'll have
to install the 64-bit version.

-Rick



> Thanks,
> Subir
>
> Rick Towler wrote:
>> Are you running the 64-bit version on one machine and the 32-bit version
>> on the other?
>>
>> Try print, !Version or PV-Wave's equivalent.
>>
>> -Rick
>>
>>
>> subir wrote:
>>> Hi All,
>>>
>>> I would appreciate if someone could help me with a problem that we are
>>> having. I am trying to use the LONG function to convert bytes in to a
>>> longword.
>>>
>>> On the first workstation (Solaris 10, PV-Wave v 8.51) LONG reads 8
>>> bytes from the input byte array. However, on the second workstation
>>> (Solaris 10, PV-Wave v8.50), LONG reads only the first 4 bytes! Is
>>> there a configuration setting that needs to be set for LONG to read 8
>>> bytes instead of 4. Has anybody out there had a similar problem?
>>>
>>> Please let me know if you need more information of the environment in
>>> which we are running.
>>>
>>> Thanks!
>>>
>
Re: LONG - reads 4 or 8 bytes?? [message #51895 is a reply to message #51894] Wed, 13 December 2006 08:37 Go to previous message
subir.vasanth is currently offline  subir.vasanth
Messages: 5
Registered: March 2006
Junior Member
Thanks for your reply Rick. Here is the output of running the 'print,
!Version' on the two workstations.

- Workstation on which LONG reads 4 bytes
WAVE> print, '!Version
{ sparc solaris 8.50 sun4}

- Workstation on which LONG reads 8 bytes
WAVE> print, "!Version"
{ sparc solaris64 8.51 b sun4}

Any ideas on how to change the PV-Wave configuration to run the 64-bit
version?

Thanks,
Subir

Rick Towler wrote:
> Are you running the 64-bit version on one machine and the 32-bit version
> on the other?
>
> Try print, !Version or PV-Wave's equivalent.
>
> -Rick
>
>
> subir wrote:
>> Hi All,
>>
>> I would appreciate if someone could help me with a problem that we are
>> having. I am trying to use the LONG function to convert bytes in to a
>> longword.
>>
>> On the first workstation (Solaris 10, PV-Wave v 8.51) LONG reads 8
>> bytes from the input byte array. However, on the second workstation
>> (Solaris 10, PV-Wave v8.50), LONG reads only the first 4 bytes! Is
>> there a configuration setting that needs to be set for LONG to read 8
>> bytes instead of 4. Has anybody out there had a similar problem?
>>
>> Please let me know if you need more information of the environment in
>> which we are running.
>>
>> Thanks!
>>
Re: LONG - reads 4 or 8 bytes?? [message #51900 is a reply to message #51895] Tue, 12 December 2006 15:12 Go to previous message
Rick Towler is currently offline  Rick Towler
Messages: 821
Registered: August 1998
Senior Member
Are you running the 64-bit version on one machine and the 32-bit version
on the other?

Try print, !Version or PV-Wave's equivalent.

-Rick


subir wrote:
> Hi All,
>
> I would appreciate if someone could help me with a problem that we are
> having. I am trying to use the LONG function to convert bytes in to a
> longword.
>
> On the first workstation (Solaris 10, PV-Wave v 8.51) LONG reads 8
> bytes from the input byte array. However, on the second workstation
> (Solaris 10, PV-Wave v8.50), LONG reads only the first 4 bytes! Is
> there a configuration setting that needs to be set for LONG to read 8
> bytes instead of 4. Has anybody out there had a similar problem?
>
> Please let me know if you need more information of the environment in
> which we are running.
>
> Thanks!
>
Re: LONG - reads 4 or 8 bytes?? [message #51901 is a reply to message #51900] Tue, 12 December 2006 13:39 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
subir writes:

> I would appreciate if someone could help me with a problem that we are
> having. I am trying to use the LONG function to convert bytes in to a
> longword.
>
> On the first workstation (Solaris 10, PV-Wave v 8.51) LONG reads 8
> bytes from the input byte array. However, on the second workstation
> (Solaris 10, PV-Wave v8.50), LONG reads only the first 4 bytes! Is
> there a configuration setting that needs to be set for LONG to read 8
> bytes instead of 4. Has anybody out there had a similar problem?

This sounds, well, unlikely. What evidence do you
have for it?

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: file_expand_path
Next Topic: Spawning EML Scripts in IDL

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 09:58:42 PDT 2025

Total time taken to generate the page: 1.04032 seconds