IDL killer [message #42199] |
Wed, 19 January 2005 05:23  |
marc schellens[1]
Messages: 183 Registered: January 2000
|
Senior Member |
|
|
IDL> print,!version
{ x86 linux unix linux 6.0 Jun 27 2003 32 64}
IDL> b=bindgen(64)
IDL> byteorder,b,/sswap,/l64swap
Floating exception
Cheers,
marc
|
|
|
Re: IDL killer [message #42262 is a reply to message #42199] |
Fri, 21 January 2005 11:22   |
wmconnolley
Messages: 106 Registered: November 2000
|
Senior Member |
|
|
Ben Panter <me@privacy.net> wrote:
> Marc Schellens wrote:
>> IDL> print,!version
>> { x86 linux unix linux 6.0 Jun 27 2003 32 64}
>> IDL> b=bindgen(64)
>> IDL> byteorder,b,/sswap,/l64swap
>> Floating exception
> I get the same with
> { x86 linux unix linux 6.1 Jul 14 2004 32 64}
On a Sun (ditto alpha) it survives but doesn't like the op:
wmc> b=bindgen(64)
wmc> byteorder,b,/sswap,/l64swap
% BYTEORDER: Operand's size must be a multiple of swap datum size: B.
% Execution halted at: $MAIN$
wmc> print,!version
{ sparc sunos unix Solaris 6.0.3 Feb 26 2004 64 64}
-W.
--
William M Connolley | wmc@bas.ac.uk | http://www.antarctica.ac.uk/met/wmc/
Climate Modeller, British Antarctic Survey | Disclaimer: I speak for myself
I'm a .signature virus! copy me into your .signature file & help me spread!
|
|
|
|
|
|
|
|
Re: IDL killer [message #42294 is a reply to message #42199] |
Wed, 19 January 2005 14:35   |
Robert Barnett
Messages: 70 Registered: May 2004
|
Member |
|
|
Perhaps we could have a competition to find as many one line killers as
possible.
Here's one, but it's only a 13 liner.
============================================================ ==
I've managed to find an error specific to IDL on Solaris
"SunOS adac9 5.9 Generic sun4u sparc SUNW,Ultra-5_10"
"SunOS adac7 5.9 Generic sun4u sparc SUNW,Ultra-1"
The error occurs in both IDL 6.0 and IDL 6.1 but not in IDL 6.0 on
Windows.
The error occurs when I run the DICOMTEST__TEST1 procedure from the
attached
code.
Running this program results in a core dump of the IDL process.
The problem is related to when I call IDLffDICOM::read as an inherited
method.
If the filename points to a file which does not exist then this will
cause a
segmentation fault (Most likely in the dicom DLM)
This error can be easily avoided by running file_test before
IDLffDICOM::read. Thus, I have managed to avoid this problem.
--
nrb@
Robbie Barnett
imag
Research Assistant
wsahs
Nuclear Medicine & Ultrasound
nsw
Westmead Hospital
gov
Sydney Australia
au
+61 2 9845 7223
; Define the dicomtest class which extends the IDLffDICOM class
pro dicomtest__define
struct = {dicomtest, image: ptr_new(), INHERITS IDLffDICOM }
end
; Define the dicomtest init method
function dicomtest::init
; Return 0 if the superclass did not init
if (NOT (self -> IDLffDICOM::init())) then return, 0
return, 1
end
; This procedure starts and runs the dicomtest wrapper object
pro dicomtest__test1
filename = 'dummyfilename'
help, file_test(filename)
dicom_obj = obj_new('dicomtest')
if (dicom_obj -> read(filename)) then print, 'ok'
end
|
|
|
|
|
|
|
Re: IDL killer [message #43006 is a reply to message #42199] |
Mon, 14 March 2005 07:56   |
marc schellens[1]
Messages: 183 Registered: January 2000
|
Senior Member |
|
|
David Fanning wrote:
> m_schellens@hotmail.com writes:
>
>> ++(((a=1))=3)
>
> I think it must be a general rule by now that any time
> you fail to have a LHS of an expression in IDL (by, for
> example, putting the RHS in parentheses and thereby
> making it a temporary variable) there is an excellent
> chance you will crash IDL. Just on the face of it,
> I would guess there must be an almost unlimited
> number of these expressions.
Well, I am sure it also crashes with other values,
what makes it almost infinite :-)
But here we DON'T fail to have a LHS!
IDL> help,(((a=1))=3)
A INT = 3
> I'm not so sure this is a bug as much as it is a peek
> into the underlying structure of the IDL code. In any
> case, I'm not surprised by it any longer.
Even though I would call it a bug, there is hardly a
case where such a construct would make sense (please post
whoever can think of one).
Generally assignment expressions shouldn't be alowed on LHS
of expressions.
Ah, did I mention that GDL (http://gnudatalanguage.sf.net)
refuses them, but does not crash :-)
Cheers,
marc
|
|
|
|
|
Re: IDL killer [message #43148 is a reply to message #42199] |
Mon, 21 March 2005 13:38  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Y.T. writes:
> Ah, the benefits of living under a rock:
>
>
> [12:37] YT [suttungr:~] > idl
> IDL Version 5.5a (linux x86). (c) 2001, Research Systems, Inc.
> Installation number: ****-*.
> Licensed for use by: MAD SCIENTISTS LTD.
>
> IDL> ++(((a=1))=3)
>
> ++(((a=1))=3)
> ^
> % Syntax error.
> IDL> help,(((a=1))=3)
> % Expression must be named variable in this context: <INT (
> 3)>.
> % Execution halted at: $MAIN$
>
>
> Sooo... what exactly are the reasons to "up"grade to V6?
Incomprehensible object tools?
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
Re: IDL killer [message #43150 is a reply to message #43006] |
Mon, 21 March 2005 13:33  |
Y.T.
Messages: 25 Registered: December 2004
|
Junior Member |
|
|
Ah, the benefits of living under a rock:
[12:37] YT [suttungr:~] > idl
IDL Version 5.5a (linux x86). (c) 2001, Research Systems, Inc.
Installation number: ****-*.
Licensed for use by: MAD SCIENTISTS LTD.
IDL> ++(((a=1))=3)
++(((a=1))=3)
^
% Syntax error.
IDL> help,(((a=1))=3)
% Expression must be named variable in this context: <INT (
3)>.
% Execution halted at: $MAIN$
Sooo... what exactly are the reasons to "up"grade to V6?
:)
cordially
Y.T.
--
Remove YourClothes before you email me.
|
|
|