comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Hard crash
items: Re: Hard crash

Hard crash
type: item
description: Ok, I've done it again. After the dictionary() bug here is a new one. *disclaimer: don't do this at home. Your pc might go in flames and your cat might bite your nose. I take no responsibility for any losses, damages or whatsoever. Create a new file, name it "testObj.pro" Put the following code in it: pro testObj::crash, res ;This is bad: print, res.test[self.refPos] end function testObj::init self.refPos = 0l return,1 end pro testObj__Define, class class = {testObj, refPos:0} end pro testObj o = obj_new('testObj') o.crash, -1l end Save the file and run it. IDL window , in my case, closes. No warnings. Nothing. Bang. I ran a few tests. The following options in the method crash, will not make it crash: print, res.test[0] void = self.refPos print, res.test[void] IDL> !version { "ARCH": "x86_64", "OS": "Win32", "OS_FAMILY": "Windows", "OS_NAME": "MicrosoftWindows", "RELEASE": "8.4", "BUILD_DATE": "Sep272014", "MEMORY_BITS": 64, "FILE_OFFSET_BITS": 64 } Any explanations? Also on previous builds (<8.4)? Cheers, Helder
creator: Helder Marchetto
date: 2014-12-18T15:20:46-00:00

Re: Hard crash
type: item
description: On Thursday, December 18, 2014 8:20:49 AM UTC-7, Helder wrote: > Ok, I've done it again. After the dictionary() bug here is a new one. > > *disclaimer: don't do this at home. Your pc might go in flames and your cat might bite your nose. I take no responsibility for any losses, damages or whatsoever. > > > Create a new file, name it "testObj.pro" > Put the following code in it: > > pro testObj::crash, res > ;This is bad: > print, res.test[self.refPos] > end > > function testObj::init > self.refPos = 0l > return,1 > end > > pro testObj__Define, class > class = {testObj, refPos:0} > end > > pro testObj > o = obj_new('testObj') > o.crash, -1l > end > > Save the file and run it. > IDL window , in my case, closes. No warnings. Nothing. Bang. > > I ran a few tests. The following options in the method crash, will not make it crash: > > print, res.test[0] > > void = self.refPos > print, res.test[void] > > IDL> !version > { > "ARCH": "x86_64", > "OS": "Win32", > "OS_FAMILY": "Windows", > "OS_NAME": "MicrosoftWindows", > "RELEASE": "8.4", > "BUILD_DATE": "Sep272014", > "MEMORY_BITS": 64, > "FILE_OFFSET_BITS": 64 > } > > Any explanations? Also on previous builds (<8.4)? > > Cheers, > Helder Here's an even simpler reproduce: IDL Version 8.4, Mac OS X (darwin x86_64 m64) IDL> foo = {bar:0} IDL> (-1).test[foo.bar] Segmentation fault: 11 I'm at home today, but I'll log a bug when I get back to work, and try to fix it for the next service pack. Thanks for catching it! -Chris Exelis
creator: chris_torrence@NOSPAM
date: 2014-12-18T16:08:22-00:00

Re: Hard crash
type: item
description: Chris, There seems to be something "magic" about a variable name "test" and implied print. Perhaps related: IDL> !version { "ARCH": "x86_64", "OS": "darwin", "OS_FAMILY": "unix", "OS_NAME": "MacOSX", "RELEASE": "8.4", "BUILD_DATE": "Sep272014", "MEMORY_BITS": 64, "FILE_OFFSET_BITS": 64 } IDL> test = 1 IDL> test Crashes IDL. - mh On Thursday, December 18, 2014 10:08:24 AM UTC-6, Chris Torrence wrote: > On Thursday, December 18, 2014 8:20:49 AM UTC-7, Helder wrote: >> Ok, I've done it again. After the dictionary() bug here is a new one. >> >> *disclaimer: don't do this at home. Your pc might go in flames and your cat might bite your nose. I take no responsibility for any losses, damages or whatsoever. >> >> >> Create a new file, name it "testObj.pro" >> Put the following code in it: >> >> pro testObj::crash, res >> ;This is bad: >> print, res.test[self.refPos] >> end >> >> function testObj::init >> self.refPos = 0l >> return,1 >> end >> >> pro testObj__Define, class >> class = {testObj, refPos:0} >> end >> >> pro testObj >> o = obj_new('testObj') >> o.crash, -1l >> end >> >> Save the file and run it. >> IDL window , in my case, closes. No warnings. Nothing. Bang. >> >> I ran a few tests. The following options in the method crash, will not make it crash: >> >> print, res.test[0] >> >> void = self.refPos >> print, res.test[void] >> >> IDL> !version >> { >> "ARCH": "x86_64", >> "OS": "Win32", >> "OS_FAMILY": "Windows", >> "OS_NAME": "MicrosoftWindows", >> "RELEASE": "8.4", >> "BUILD_DATE": "Sep272014", >> "MEMORY_BITS": 64, >> "FILE_OFFSET_BITS": 64 >> } >> >> Any explanations? Also on previous builds (<8.4)? >> >> Cheers, >> Helder > > Here's an even simpler reproduce: > > IDL Version 8.4, Mac OS X (darwin x86_64 m64) > IDL> foo = {bar:0} > IDL> (-1).test[foo.bar] > Segmentation fault: 11 > > I'm at home today, but I'll log a bug when I get back to work, and try to fix it for the next service pack. > > Thanks for catching it! > > -Chris > Exelis
creator: Matt Haffner
date: 2014-12-19T21:34:15-00:00

Re: Hard crash
type: item
description: On Friday, December 19, 2014 2:34:17 PM UTC-7, Matt Haffner wrote: > Chris, > > There seems to be something "magic" about a variable name "test" and implied print. Perhaps related: > > IDL> !version > { > "ARCH": "x86_64", > "OS": "darwin", > "OS_FAMILY": "unix", > "OS_NAME": "MacOSX", > "RELEASE": "8.4", > "BUILD_DATE": "Sep272014", > "MEMORY_BITS": 64, > "FILE_OFFSET_BITS": 64 > } > IDL> test = 1 > IDL> test > > Crashes IDL. > > - mh > > On Thursday, December 18, 2014 10:08:24 AM UTC-6, Chris Torrence wrote: >> On Thursday, December 18, 2014 8:20:49 AM UTC-7, Helder wrote: >>> Ok, I've done it again. After the dictionary() bug here is a new one. >>> >>> *disclaimer: don't do this at home. Your pc might go in flames and your cat might bite your nose. I take no responsibility for any losses, damages or whatsoever. >>> >>> >>> Create a new file, name it "testObj.pro" >>> Put the following code in it: >>> >>> pro testObj::crash, res >>> ;This is bad: >>> print, res.test[self.refPos] >>> end >>> >>> function testObj::init >>> self.refPos = 0l >>> return,1 >>> end >>> >>> pro testObj__Define, class >>> class = {testObj, refPos:0} >>> end >>> >>> pro testObj >>> o = obj_new('testObj') >>> o.crash, -1l >>> end >>> >>> Save the file and run it. >>> IDL window , in my case, closes. No warnings. Nothing. Bang. >>> >>> I ran a few tests. The following options in the method crash, will not make it crash: >>> >>> print, res.test[0] >>> >>> void = self.refPos >>> print, res.test[void] >>> >>> IDL> !version >>> { >>> "ARCH": "x86_64", >>> "OS": "Win32", >>> "OS_FAMILY": "Windows", >>> "OS_NAME": "MicrosoftWindows", >>> "RELEASE": "8.4", >>> "BUILD_DATE": "Sep272014", >>> "MEMORY_BITS": 64, >>> "FILE_OFFSET_BITS": 64 >>> } >>> >>> Any explanations? Also on previous builds (<8.4)? >>> >>> Cheers, >>> Helder >> >> Here's an even simpler reproduce: >> >> IDL Version 8.4, Mac OS X (darwin x86_64 m64) >> IDL> foo = {bar:0} >> IDL> (-1).test[foo.bar] >> Segmentation fault: 11 >> >> I'm …
creator: Jim Pendleton
date: 2014-12-20T04:52:06-00:00

Re: Hard crash
type: item
description: On Friday, December 19, 2014 9:52:08 PM UTC-7, Jim P wrote: > On Friday, December 19, 2014 2:34:17 PM UTC-7, Matt Haffner wrote: >> Chris, >> >> There seems to be something "magic" about a variable name "test" and implied print. Perhaps related: >> >> IDL> !version >> { >> "ARCH": "x86_64", >> "OS": "darwin", >> "OS_FAMILY": "unix", >> "OS_NAME": "MacOSX", >> "RELEASE": "8.4", >> "BUILD_DATE": "Sep272014", >> "MEMORY_BITS": 64, >> "FILE_OFFSET_BITS": 64 >> } >> IDL> test = 1 >> IDL> test >> >> Crashes IDL. >> >> - mh >> >> On Thursday, December 18, 2014 10:08:24 AM UTC-6, Chris Torrence wrote: >>> On Thursday, December 18, 2014 8:20:49 AM UTC-7, Helder wrote: >>>> Ok, I've done it again. After the dictionary() bug here is a new one. >>>> >>>> *disclaimer: don't do this at home. Your pc might go in flames and your cat might bite your nose. I take no responsibility for any losses, damages or whatsoever. >>>> >>>> >>>> Create a new file, name it "testObj.pro" >>>> Put the following code in it: >>>> >>>> pro testObj::crash, res >>>> ;This is bad: >>>> print, res.test[self.refPos] >>>> end >>>> >>>> function testObj::init >>>> self.refPos = 0l >>>> return,1 >>>> end >>>> >>>> pro testObj__Define, class >>>> class = {testObj, refPos:0} >>>> end >>>> >>>> pro testObj >>>> o = obj_new('testObj') >>>> o.crash, -1l >>>> end >>>> >>>> Save the file and run it. >>>> IDL window , in my case, closes. No warnings. Nothing. Bang. >>>> >>>> I ran a few tests. The following options in the method crash, will not make it crash: >>>> >>>> print, res.test[0] >>>> >>>> void = self.refPos >>>> print, res.test[void] >>>> >>>> IDL> !version >>>> { >>>> "ARCH": "x86_64", >>>> "OS": "Win32", >>>> "OS_FAMILY": "Windows", >>>> "OS_NAME": "MicrosoftWindows", >>>> "RELEASE": "8.4", >>>> "BUILD_DATE": "Sep272014", >>>> "MEMORY_BITS": 64, >>>> "FILE_OFFSET_BITS": 64 >>>> } >>>> >>>> Any explanations? Also on previous builds (<8.4)? >>>> >>>> Cheers, >>>> Helder >>> >>> Here's an even simpler reprodu…
creator: chris_torrence@NOSPAM
date: 2014-12-20T22:34:31-00:00

Re: Hard crash
type: item
description: (sorry for the delay--holidays...) Well, I guess it's good it's just me--thought it was a pretty odd one. But I don't see any obvious rouge routine. IDL> where(strmatch(routine_info(/system), '*test*', /fold_case)) -1 IDL> .run test % Error opening file. File: test I run a pretty vanilla IDL other than Astro routines and my library, which has no DLM--only routines and macros written in IDL. I'll try it on my other machines... - mh On Saturday, December 20, 2014 at 4:34:33 PM UTC-6, Chris Torrence wrote: > On Friday, December 19, 2014 9:52:08 PM UTC-7, Jim P wrote: >> On Friday, December 19, 2014 2:34:17 PM UTC-7, Matt Haffner wrote: >>> Chris, >>> >>> There seems to be something "magic" about a variable name "test" and implied print. Perhaps related: >>> >>> IDL> !version >>> { >>> "ARCH": "x86_64", >>> "OS": "darwin", >>> "OS_FAMILY": "unix", >>> "OS_NAME": "MacOSX", >>> "RELEASE": "8.4", >>> "BUILD_DATE": "Sep272014", >>> "MEMORY_BITS": 64, >>> "FILE_OFFSET_BITS": 64 >>> } >>> IDL> test = 1 >>> IDL> test >>> >>> Crashes IDL. >>> >>> - mh >>> >>> On Thursday, December 18, 2014 10:08:24 AM UTC-6, Chris Torrence wrote: >>>> On Thursday, December 18, 2014 8:20:49 AM UTC-7, Helder wrote: >>>> > Ok, I've done it again. After the dictionary() bug here is a new one. >>>> > >>>> > *disclaimer: don't do this at home. Your pc might go in flames and your cat might bite your nose. I take no responsibility for any losses, damages or whatsoever. >>>> > >>>> > >>>> > Create a new file, name it "testObj.pro" >>>> > Put the following code in it: >>>> > >>>> > pro testObj::crash, res >>>> > ;This is bad: >>>> > print, res.test[self.refPos] >>>> > end >>>> > >>>> > function testObj::init >>>> > self.refPos = 0l >>>> > return,1 >>>> > end >>>> > >>>> > pro testObj__Define, class >>>> > class = {testObj, refPos:0} >>>> > end >>>> > >>>> > pro testObj >>>> > o = obj_new('testObj') >>>> > o.crash, -1l >>>> > end >>>> > >>>> > Save the file and run it. >>>> > IDL window , in my case, clos…
creator: Matt Haffner
date: 2015-01-08T21:45:27-00:00

Re: Hard crash
type: item
description: Hey Matt, That's weird. I still don't have any clue what could be happening for your bug. Regarding the original bug from Helder, it's fixed for IDL 8.4.1 - it now throws the following error: % Subscripts are not allowed with variable attributes. Cheers, Chris
creator: chris_torrence@NOSPAM
date: 2015-01-08T22:34:28-00:00

Re: Hard crash
type: item
description: On Thursday, January 8, 2015 at 3:34:31 PM UTC-7, Chris Torrence wrote: > Hey Matt, > > That's weird. I still don't have any clue what could be happening for your bug. Regarding the original bug from Helder, it's fixed for IDL 8.4.1 - it now throws the following error: > % Subscripts are not allowed with variable attributes. > > Cheers, > Chris Is it the same behavior when running from command line IDL and from the Workbench? Are there any files named hs_err*.log created in the default directory when the IDL process exits?
creator: Jim Pendleton
date: 2015-01-09T02:17:32-00:00

Re: Hard crash
type: item
description: Jim (& Chris), No, the command line was fine. But I understand why now... Those log files were very helpful--I wasn't aware of those before. The stack track in there made it clear it was indeed trying to open a user routine somewhere. dtrace helped me ID a 'test.sav' that was trying to be loaded from the IDLWorkspace84/Default directory, which is why it was only crashing in eclipse--that directory isn't added to the command line IDL path by default. Trying the same thing from the command line with that file in the path does then give the same result, with a bit more error output: IDL> test % Wrong number of tags defined for structure: LIST. % Structure not restored due to conflict with existing definition: LIST. Segmentation fault: 11 The file contained an old save of an object that does contain some LISTs buried in it's property hierarchy. Restoring the file does not crash IDL: IDL> restore,'./test.sav' % Wrong number of tags defined for structure: LIST. % RESTORE: Structure not restored due to conflict with existing definition: LIST. % Wrong number of tags defined for structure: LIST. % RESTORE: Structure not restored due to conflict with existing definition: LIST. % Wrong number of tags defined for structure: LIST. % RESTORE: Structure not restored due to conflict with existing definition: LIST. Looks like the save was in IDL 8.2.3. Did LIST's data structure evolve since then? None of this is critical for me to restore/retain... mostly morbid curiosity at this point. But let me know if it's useful to poke around further to characterize a bug. - Matt On Thursday, January 8, 2015 at 8:17:34 PM UTC-6, Jim P wrote: > On Thursday, January 8, 2015 at 3:34:31 PM UTC-7, Chris Torrence wrote: >> Hey Matt, >> >> That's weird. I still don't have any clue what could be happening for your bug. Regarding the original bug from Helder, it's fixed for IDL 8.4.1 - it now throws the following error: >> % Subscripts are not allowed with variable attributes. >> >> Cheers, >> Chris > …
creator: Matt Haffner
date: 2015-01-09T19:31:36-00:00

Re: Hard crash
type: item
description: On Friday, January 9, 2015 at 12:31:39 PM UTC-7, Matt Haffner wrote: > Jim (& Chris), > > No, the command line was fine. But I understand why now... > > Those log files were very helpful--I wasn't aware of those before. The stack track in there made it clear it was indeed trying to open a user routine somewhere. dtrace helped me ID a 'test.sav' that was trying to be loaded from the IDLWorkspace84/Default directory, which is why it was only crashing in eclipse--that directory isn't added to the command line IDL path by default. > > Trying the same thing from the command line with that file in the path does then give the same result, with a bit more error output: > > IDL> test > % Wrong number of tags defined for structure: LIST. > % Structure not restored due to conflict with existing definition: LIST. > Segmentation fault: 11 > > The file contained an old save of an object that does contain some LISTs buried in it's property hierarchy. > > Restoring the file does not crash IDL: > > IDL> restore,'./test.sav' > % Wrong number of tags defined for structure: LIST. > % RESTORE: Structure not restored due to conflict with existing definition: LIST. > % Wrong number of tags defined for structure: LIST. > % RESTORE: Structure not restored due to conflict with existing definition: LIST. > % Wrong number of tags defined for structure: LIST. > % RESTORE: Structure not restored due to conflict with existing definition: LIST. > > Looks like the save was in IDL 8.2.3. Did LIST's data structure evolve since then? > > None of this is critical for me to restore/retain... mostly morbid curiosity at this point. But let me know if it's useful to poke around further to characterize a bug. > > - Matt > > On Thursday, January 8, 2015 at 8:17:34 PM UTC-6, Jim P wrote: >> On Thursday, January 8, 2015 at 3:34:31 PM UTC-7, Chris Torrence wrote: >>> Hey Matt, >>> >>> That's weird. I still don't have any clue what could be happening for your bug. Regarding the original bug from Helder, it's fix…
creator: Jim Pendleton
date: 2015-01-10T01:13:53-00:00

Re: Hard crash
type: item
description: Jim P writes: > A new blog explaining this effect is now posted at > http://tinyurl.com/ocohc6n Hi, Jim, I read this article this morning. Talk about a recipe for disaster! :-) I was going to offer to host a copy of this article on my web page, if you would like me to. I think a few more people might see it and benefit greatly from the information. That DataPoint blog is great, but really hard for some of us to get to. Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")
creator: David Fanning
date: 2015-01-30T17:25:40-00:00

Re: Hard crash
type: item
description: On Friday, January 30, 2015 at 5:37:28 PM UTC+1, Jim P wrote: > A new blog explaining this effect is now posted at > http://tinyurl.com/ocohc6n I think the problem is more general. Save files created after any use of LIST or HASH will include the unwanted routines. For example: IDL> l=list() IDL> save,/routines,/verbose,file='test.sav' % SAVE: Portable (XDR) SAVE/RESTORE file. % SAVE: Saved procedure: COLLECTION::CLEANUP. % SAVE: Saved procedure: COLLECTION::_OVERLOADBRACKETSLEFTSIDEARRAY. % SAVE: Saved procedure: COLLECTION__DEFINE. ... regards, Lajos
creator: Lajos Foldy
date: 2015-01-30T18:36:56-00:00

Re: Hard crash
type: item
description: On Fri, 30 Jan 2015 10:25:40 -0700, David Fanning wrote: > Jim P writes: > >> A new blog explaining this effect is now posted at >> http://tinyurl.com/ocohc6n > > Hi, Jim, I read this article this morning. Talk about a recipe for > disaster! :-) > > I was going to offer to host a copy of this article on my web page, if > you would like me to. I think a few more people might see it and benefit > greatly from the information. That DataPoint blog is great, but really > hard for some of us to get to. > That would be very helpful. The link from tinyurl leads me to http://www.exelisvis.com/Company/PressRoom/Blogs/IDLDataPoin tDetail/TabId/902/ArtMID/2926/ArticleID/14277/Problems-Assig ning-LIST-HASH-etc-to-Class-or-Structure-Tags.aspx and there I get the information: "Article does not exist or Permission Denied." Heinz
creator: Heinz Stege
date: 2015-01-30T21:15:24-00:00

Re: Hard crash
type: item
description: On Friday, January 30, 2015 at 10:15:18 PM UTC+1, Heinz Stege wrote: > On Fri, 30 Jan 2015 10:25:40 -0700, David Fanning wrote: > >> Jim P writes: >> >>> A new blog explaining this effect is now posted at >>> http://tinyurl.com/ocohc6n >> >> Hi, Jim, I read this article this morning. Talk about a recipe for >> disaster! :-) >> >> I was going to offer to host a copy of this article on my web page, if >> you would like me to. I think a few more people might see it and benefit >> greatly from the information. That DataPoint blog is great, but really >> hard for some of us to get to. >> > That would be very helpful. The link from tinyurl leads me to > http://www.exelisvis.com/Company/PressRoom/Blogs/IDLDataPoin tDetail/TabId/902/ArtMID/2926/ArticleID/14277/Problems-Assig ning-LIST-HASH-etc-to-Class-or-Structure-Tags.aspx > and there I get the information: > "Article does not exist or Permission Denied." > > Heinz I can confirm that it was there two hours ago. Now it is here: http://www.exelisvis.com/Company/PressRoom/Blogs/TabId/836/A rtMID/2928/ArticleID/14277/Problems-Assigning-LIST-HASH-etc- to-Class-or-Structure-Tags.aspx Read quickly before it changes its address again :-) regards, Lajos
creator: Lajos Foldy
date: 2015-01-30T21:25:45-00:00

Re: Hard crash
type: item
description: On Fri, 30 Jan 2015 13:25:45 -0800 (PST), fawltylanguage@gmail.com wrote: > I can confirm that it was there two hours ago. Now it is here: > > http://www.exelisvis.com/Company/PressRoom/Blogs/TabId/836/A rtMID/2928/ArticleID/14277/Problems-Assigning-LIST-HASH-etc- to-Class-or-Structure-Tags.aspx > > Read quickly before it changes its address again :-) > Thank you Lajos. The second link is working for me to. :-) However I wonder, if the most important point isn't that in the comment: "BUT you should use the SKIP keyword to RESOLVE_ALL before creating your SAVE file to ensure the "hash.sav" file is NOT included in your build." I don't use lists and hashes frequently, but does it really make a change to use OBJ_NEW() instead of LIST() in the class definition? Don't misunderstand me, it is always a good idea to be clearly in coding. So it may be more readable to use OBJ_NEW(). But what is the difference? When I define two structures s1={a:list()} s2={a:obj_new()} IDL's help command help,s1,s2,/str prints: ** Structure <1606fea8>, 1 tags, length=4, data length=4, refs=1: A OBJREF <ObjHeapVar1(LIST)> ** Structure <11587c78>, 1 tags, length=4, data length=4, refs=1: A OBJREF <NullObject> There are object references in both structures s1 and s2. The first one s1 is already allocated in the heap, the second one s2 is a null object. But somewhere in the code I have to make it a list: s2.a=list() And then the help command says, that s2 is equal s1: ** Structure <11587c78>, 1 tags, length=4, data length=4, refs=1: A OBJREF <ObjHeapVar2(LIST)> Is there something wrong in my understanding? Cheers, Heinz
creator: Heinz Stege
date: 2015-01-30T23:39:57-00:00

Re: Hard crash
type: item
description: On Friday, January 30, 2015 at 4:39:51 PM UTC-7, Heinz Stege wrote: > On Fri, 30 Jan 2015 13:25:45 -0800 (PST), fawltylanguage@gmail.com > wrote: > >> I can confirm that it was there two hours ago. Now it is here: >> >> http://www.exelisvis.com/Company/PressRoom/Blogs/TabId/836/A rtMID/2928/ArticleID/14277/Problems-Assigning-LIST-HASH-etc- to-Class-or-Structure-Tags.aspx >> >> Read quickly before it changes its address again :-) >> > Thank you Lajos. The second link is working for me to. :-) > > However I wonder, if the most important point isn't that in the > comment: "BUT you should use the SKIP keyword to RESOLVE_ALL before > creating your SAVE file to ensure the "hash.sav" file is NOT included > in your build." > > I don't use lists and hashes frequently, but does it really make a > change to use OBJ_NEW() instead of LIST() in the class definition? > Don't misunderstand me, it is always a good idea to be clearly in > coding. So it may be more readable to use OBJ_NEW(). > > But what is the difference? When I define two structures > s1={a:list()} > s2={a:obj_new()} > IDL's help command > help,s1,s2,/str > prints: > ** Structure <1606fea8>, 1 tags, length=4, data length=4, refs=1: > A OBJREF <ObjHeapVar1(LIST)> > ** Structure <11587c78>, 1 tags, length=4, data length=4, refs=1: > A OBJREF <NullObject> > There are object references in both structures s1 and s2. The first > one s1 is already allocated in the heap, the second one s2 is a null > object. But somewhere in the code I have to make it a list: > s2.a=list() > And then the help command says, that s2 is equal s1: > ** Structure <11587c78>, 1 tags, length=4, data length=4, refs=1: > A OBJREF <ObjHeapVar2(LIST)> > Is there something wrong in my understanding? > > Cheers, Heinz Sorry about the jumping links, folks. I have no control over that side of things. It may be that if a comment is added after publication, the original URL changes. (I noticed someone recently purchased the idldatapoint dot com domain and t…
creator: Jim Pendleton
date: 2015-01-31T01:24:33-00:00

Re: Hard crash
type: item
description: Wow - this is an important point! I have just gone through a large codebase and removed all of the references to list() and hash() from my class definitions. One question: I also have a large collection of structure definition files, which are part of the project. Should I also remove list() and hash() from my structure definitions? This doesn't seem to make sense, however, since when the structure is created it will be initialized automatically with an empty list or hash. thanks.
creator: markb77
date: 2015-02-02T15:09:10-00:00

Re: Hard crash
type: item
description: On Fri, 30 Jan 2015 17:24:33 -0800 (PST), Jim P wrote: > The key to understanding the problem is that the IDL compiler *must* restore the hash.sav at compile time if a structure tag is defined as LIST(), HASH(), etc. At that point, all is lost* with respect to IDL "forgetting" about the compiled definitions. > Aah, that brings some light into the darkness. IDL 8.4 restores the hash.sav file when compiling a routine with LIST() as a structure tag? I didn't know this, since I'm still working with Version 8.0.1.* My version is different. It does _not_ restore hash.sav or list.sav when compiling a routine with a LIST() tag in the class structure definition. Do you think, that it may be interesting for the news group, why this change was done? Cheers, Heinz * My company does not have the money to upgrade. :-(
creator: Heinz Stege
date: 2015-02-02T21:40:15-00:00

Re: Hard crash
type: item
description: Heinz Stege wrote, On 2015-02-02, 1:40pm: > On Fri, 30 Jan 2015 17:24:33 -0800 (PST), Jim P wrote: > >> The key to understanding the problem is that the IDL compiler *must* restore the hash.sav at compile time if a structure tag is defined as LIST(), HASH(), etc. At that point, all is lost* with respect to IDL "forgetting" about the compiled definitions. >> > Aah, that brings some light into the darkness. IDL 8.4 restores the > hash.sav file when compiling a routine with LIST() as a structure tag? > I didn't know this, since I'm still working with Version 8.0.1.* My > version is different. It does _not_ restore hash.sav or list.sav when > compiling a routine with a LIST() tag in the class structure > definition. > > Do you think, that it may be interesting for the news group, why this > change was done? > > Cheers, Heinz > > * My company does not have the money to upgrade. :-( I think I was caught by this issue, hoping to compile a .sav in 8.4 for a client to run in 8.3. Some problems were relieved by: 1. In my project's Build, replacing the standard RESOLVE_ALL with post-process command: RESOLVE_ALL, skip=['list','hash','orderedhash'] 2. Avoiding the use of myList = List(myArray, /EXTRACT) But I'm seeing another problem I can't seem to avoid, where I'm adding an item to a list, and I get: IDL_CONTAINER::ADD: Object reference type required in this context: INDEXITEM. (INDEXITEM was my variable that I was Adding to the list) I confirm that neither IDL 8.3 nor 8.4 actually require this of a List() object. I tried adding 'idl_container' to the "skip" list in RESOLVE_ALL, to no avail. Any suggestions of how to get around this? -- Cheers, -Dick Dick Jackson Software Consulting Inc. Victoria, BC, Canada www.d-jackson.com
creator: Dick Jackson
date: 2015-02-10T02:18:11-00:00

Re: Hard crash
type: item
description: On Monday, February 9, 2015 at 7:18:13 PM UTC-7, Dick Jackson wrote: > Heinz Stege wrote, On 2015-02-02, 1:40pm: >> On Fri, 30 Jan 2015 17:24:33 -0800 (PST), Jim P wrote: >> >>> The key to understanding the problem is that the IDL compiler *must* restore the hash.sav at compile time if a structure tag is defined as LIST(), HASH(), etc. At that point, all is lost* with respect to IDL "forgetting" about the compiled definitions. >>> >> Aah, that brings some light into the darkness. IDL 8.4 restores the >> hash.sav file when compiling a routine with LIST() as a structure tag? >> I didn't know this, since I'm still working with Version 8.0.1.* My >> version is different. It does _not_ restore hash.sav or list.sav when >> compiling a routine with a LIST() tag in the class structure >> definition. >> >> Do you think, that it may be interesting for the news group, why this >> change was done? >> >> Cheers, Heinz >> >> * My company does not have the money to upgrade. :-( > > I think I was caught by this issue, hoping to compile a .sav in 8.4 for a client to run in 8.3. Some problems were > relieved by: > > 1. In my project's Build, replacing the standard RESOLVE_ALL with post-process command: > RESOLVE_ALL, skip=['list','hash','orderedhash'] > > 2. Avoiding the use of myList = List(myArray, /EXTRACT) > > But I'm seeing another problem I can't seem to avoid, where I'm adding an item to a list, and I get: > IDL_CONTAINER::ADD: Object reference type required in this context: INDEXITEM. > (INDEXITEM was my variable that I was Adding to the list) > > I confirm that neither IDL 8.3 nor 8.4 actually require this of a List() object. > > I tried adding 'idl_container' to the "skip" list in RESOLVE_ALL, to no avail. > > Any suggestions of how to get around this? > > -- > > Cheers, > -Dick > > Dick Jackson Software Consulting Inc. > Victoria, BC, Canada > www.d-jackson.com Hi Dick, Okay, this is a tricky one. The bottom line is you'd probably be better off compiling your app in 8.3, i…
creator: Jim Pendleton
date: 2015-02-10T03:16:26-00:00