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

Home » Public Forums » archive » Different behavior of RESTORE and IDL_SaveFile::Restore ?
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
Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90251] Sat, 14 February 2015 11:13 Go to next message
lecacheux.alain is currently offline  lecacheux.alain
Messages: 325
Registered: January 2008
Senior Member
In a previous IDL session, I built three long LIST() variables made of various arrays and structures (no objects). I then save them, by the usual command:
IDL> save, list1, list2, list3

Problem arises when I want to restore the lists by using:
IDL> restore, 'idlsave.dat'
Actually, IDL crashes immediately. Likely, I made some error in the creation program.

The strange thing is that I can restore my variables by using the IDL_SaveFile object, i.e:

IDL> s = Obj_New('IDL_SaveFile', 'idlsave.dat')
IDL> s.Names()
LIST1
LIST2
LIST3
IDL> s.Restore, 'LIST1'
IDL> s.restore, 'LIST2'
IDL> s.Restore, 'LIST3'
IDL> help, list1, list2, list3
LIST1 LIST <ID=2 NELEMENTS=11916>
LIST2 LIST <ID=23835 NELEMENTS=154366>
LIST3 LIST <ID=332568 NELEMENTS=166282>

Any clue ?
What kind of error might make a successful saveset crashing IDL ?

alx.
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90252 is a reply to message #90251] Sat, 14 February 2015 11:17 Go to previous messageGo to next message
Matthew Argall is currently offline  Matthew Argall
Messages: 286
Registered: October 2011
Senior Member
See this discussion.

https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90253 is a reply to message #90252] Sat, 14 February 2015 11:51 Go to previous messageGo to next message
lecacheux.alain is currently offline  lecacheux.alain
Messages: 325
Registered: January 2008
Senior Member
Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
> See this discussion.
>
> https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw

Thanks for the tip. I know this discussion.
But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?

alx.
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90261 is a reply to message #90253] Sun, 15 February 2015 08:33 Go to previous messageGo to next message
chris_torrence@NOSPAM is currently offline  chris_torrence@NOSPAM
Messages: 528
Registered: March 2007
Senior Member
On Saturday, February 14, 2015 at 12:51:23 PM UTC-7, alx wrote:
> Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
>> See this discussion.
>>
>> https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
>
> Thanks for the tip. I know this discussion.
> But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
> And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?
>
> alx.

Hi alx,

Are you sure that you don't have an old IDL version on your path? When IDL restores the save file, it will try to load the list code, to make sure it is in sync with the latest version. If you have an old version on IDL's path, it will accidentally pick that up and that will lead to problems.

-Chris
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90262 is a reply to message #90261] Sun, 15 February 2015 09:35 Go to previous messageGo to next message
lecacheux.alain is currently offline  lecacheux.alain
Messages: 325
Registered: January 2008
Senior Member
Le dimanche 15 février 2015 17:33:32 UTC+1, Chris Torrence a écrit :
> On Saturday, February 14, 2015 at 12:51:23 PM UTC-7, alx wrote:
>> Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
>>> See this discussion.
>>>
>>> https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
>>
>> Thanks for the tip. I know this discussion.
>> But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
>> And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?
>>
>> alx.
>
> Hi alx,
>
> Are you sure that you don't have an old IDL version on your path? When IDL restores the save file, it will try to load the list code, to make sure it is in sync with the latest version. If you have an old version on IDL's path, it will accidentally pick that up and that will lead to problems.
>
> -Chris

Hi Chris,
The used machine is a freshly installed one so that I am sure that there is only one IDL (8.4) on it.
{ x86_64 Win32 Windows Microsoft Windows 8.4 Sep 27 2014 64 64}
After a machine reboot the problem disappeared: RESTORE is now restoring correctly.
Before the machine reboot, I just restarted each time the IDL session.
Can we imagine that some error in managing LIST variables inside the first session (loaded DLL or something else) could have permanently affected the other following sessions ?
I suspect the construct "list1 += list_", used in a large loop, when building at first the lists variables.

alain.
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90265 is a reply to message #90262] Mon, 16 February 2015 09:14 Go to previous messageGo to next message
chris_torrence@NOSPAM is currently offline  chris_torrence@NOSPAM
Messages: 528
Registered: March 2007
Senior Member
On Sunday, February 15, 2015 at 10:35:50 AM UTC-7, alx wrote:
> Le dimanche 15 février 2015 17:33:32 UTC+1, Chris Torrence a écrit :
>> On Saturday, February 14, 2015 at 12:51:23 PM UTC-7, alx wrote:
>>> Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
>>>> See this discussion.
>>>>
>>>> https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
>>>
>>> Thanks for the tip. I know this discussion.
>>> But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
>>> And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?
>>>
>>> alx.
>>
>> Hi alx,
>>
>> Are you sure that you don't have an old IDL version on your path? When IDL restores the save file, it will try to load the list code, to make sure it is in sync with the latest version. If you have an old version on IDL's path, it will accidentally pick that up and that will lead to problems.
>>
>> -Chris
>
> Hi Chris,
> The used machine is a freshly installed one so that I am sure that there is only one IDL (8.4) on it.
> { x86_64 Win32 Windows Microsoft Windows 8.4 Sep 27 2014 64 64}
> After a machine reboot the problem disappeared: RESTORE is now restoring correctly.
> Before the machine reboot, I just restarted each time the IDL session.
> Can we imagine that some error in managing LIST variables inside the first session (loaded DLL or something else) could have permanently affected the other following sessions ?
> I suspect the construct "list1 += list_", used in a large loop, when building at first the lists variables.
>
> alain.

Well, I can imagine a lot. :-) But I've never heard of this happening... Anyway, it sounds like you solved the problem, so unless it occurs again, I would just pretend that it never happened...

Cheers,
Chris
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90266 is a reply to message #90265] Mon, 16 February 2015 10:47 Go to previous message
lecacheux.alain is currently offline  lecacheux.alain
Messages: 325
Registered: January 2008
Senior Member
Le lundi 16 février 2015 18:14:07 UTC+1, Chris Torrence a écrit :
> On Sunday, February 15, 2015 at 10:35:50 AM UTC-7, alx wrote:
>> Le dimanche 15 février 2015 17:33:32 UTC+1, Chris Torrence a écrit :
>>> On Saturday, February 14, 2015 at 12:51:23 PM UTC-7, alx wrote:
>>>> Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
>>>> > See this discussion.
>>>> >
>>>> > https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
>>>>
>>>> Thanks for the tip. I know this discussion.
>>>> But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
>>>> And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?
>>>>
>>>> alx.
>>>
>>> Hi alx,
>>>
>>> Are you sure that you don't have an old IDL version on your path? When IDL restores the save file, it will try to load the list code, to make sure it is in sync with the latest version. If you have an old version on IDL's path, it will accidentally pick that up and that will lead to problems.
>>>
>>> -Chris
>>
>> Hi Chris,
>> The used machine is a freshly installed one so that I am sure that there is only one IDL (8.4) on it.
>> { x86_64 Win32 Windows Microsoft Windows 8.4 Sep 27 2014 64 64}
>> After a machine reboot the problem disappeared: RESTORE is now restoring correctly.
>> Before the machine reboot, I just restarted each time the IDL session.
>> Can we imagine that some error in managing LIST variables inside the first session (loaded DLL or something else) could have permanently affected the other following sessions ?
>> I suspect the construct "list1 += list_", used in a large loop, when building at first the lists variables.
>>
>> alain.
>
> Well, I can imagine a lot. :-) But I've never heard of this happening... Anyway, it sounds like you solved the problem, so unless it occurs again, I would just pretend that it never happened...
>
> Cheers,
> Chris

Ok. Forget it.
But I must also say that I never had any problem with IDL Save/Restore, while using IDL since several decades (since V2.0 on PDP11).
Whence my surprise...
alx.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Bridge Logging = OFF not working using the Java Bridge
Next Topic: recursive search in a dictionary

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

Current Time: Wed Oct 08 15:11:25 PDT 2025

Total time taken to generate the page: 0.00497 seconds