| IDL 8.0 questions [message #71829] |
Sat, 24 July 2010 09:18  |
Mike Potter
Messages: 19
Registered: August 2008
|
Junior Member |
|
|
I downoaded and installed IDL8.0 yesterday. There are a few things I
don't understand (amongst the things I'm yet to understand that I
don't understand!):
1) I'm trying out the new "foreach" capability. The top loop, below,
works, the bottom one does not.
for i=0,nf-1 do begin
qfile = file_names[i]
image = readfits( qfile )
sky,image,sky,sky_sig,/silent
q = dialog_message( "Sky = "+string(sky)+" Sigma =
"+string(sky_sig) ,/information )
endfor
foreach qfile, file_names do begin
image = readfits( qfile )
sky,image,sky_mod,sky_sig,/silent
q = dialog_message( "Sky = "+string(sky_mod)+" Sigma =
"+string(sky_sig) ,/information )
endforeach
After running the bottom loop, the first time readfits is called it
crashes and the input "qfile" has been changed and either contains two
characters equal to the final two characters of what qfile was on
input, or it returns a short string of garbage characters.
(file_names is a string array of filenames returned by
dialog_pickfile).
Also, if I try to save a file using the file menu drop-down and select
"Save As" and save so as to overwrite the existing file I get
1) the expected information modal dialog asking if I really want to
overwrite the existing file. If I select yes then
2) the code in the Workbench disappears and is replaced by some text
saying something about the file being out-of-sync with the file
system, and to use "file > refresh" (it''s only there for a second or
two) - then the code returns and another modal dialog ("File Changed")
asks me if I want to replace the editor contents with the "changed"
file.
I've also had the Workbench just completely crash and exit - several
times. The Workbench also seems to occasionally loose it's way - when
that happens I can say "help" to have it print a list of current
variables and compiled modules and such but nothing gets printed. I
can also do "help,qfile", for instance, and nothing is returned, even
though the value of qfile is showing in the "variables" pannel.
Is it me or is it bugs?
THanks!
Mike Potter
|
|
|
|
|
|
|
|
|
|
|
|
| Re: IDL 8.0 questions [message #71882 is a reply to message #71829] |
Mon, 26 July 2010 11:47  |
chris_torrence@NOSPAM
Messages: 528
Registered: March 2007
|
Senior Member |
|
|
On Jul 26, 9:57 am, Paulo Penteado <pp.pente...@gmail.com> wrote:
> On Jul 25, 4:11 pm, Paulo Penteado <pp.pente...@gmail.com> wrote:
>
>> Maybe el is getting one of its metadata fields wrong when it is
>> created?
>
> I was curious about this, so I checked what flags were being set in a
> foreach element variable. I found that when just the loop is used, the
> variable has no flags. When a print is used inside the loop, the print
> call sets the IDL_V_DYNAMIC flag. Which, I thought should have been
> always set, as the element is a string.
Hi Paulo,
Let me echo David's comment about "good detective work!". This is
exactly what was happening. We had a bug in the foreach code where for
strings it was not setting the IDL_V_DYNAMIC flag. Inside STRMID,
since the DYNAMIC flag wasn't set, it didn't bother to make a copy of
the input variable but instead just wrote over the contents. This will
be fixed in the next available IDL update.
As far as Mike Potter's other problems:
1. The confusing "file is out of sync" issue - this is a known quirk.
For now, you just need to wait for IDL to present the dialog about
replacing the contents.
2. The problem where IDL "loses it's way" and stops printing output -
this is also a known bug and has been fixed in the next IDL update.
Thanks for finding these issues, and let us know if you see anything
else that isn't working.
Cheers,
Chris Torrence
IDL Software Development Manager
ITTVIS
|
|
|
|
| Re: IDL 8.0 questions [message #71958 is a reply to message #71864] |
Tue, 27 July 2010 10:38 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
'kay, thanks. A "few months" is the ballpark-y info I was after.
cheers,
paulv
BillO wrote:
> On Jul 27, 8:51 am, Paul van Delst <paul.vande...@noaa.gov> wrote:
>> Chris Torrence wrote:
>>> This will be fixed in the next available IDL update.
>> Any info on when that will be? I've need to give our sysadmins here enough warning about an additional install in the
>> future for the 8.0 bug fix update.
>>
>> cheers,
>>
>> paulv
>
> We are working on a bug fix release to IDL 8.0. Realistically, it is
> probably a few months away. That's about as accurate as I can say
> right now. Thanks for your patience.
>
> Bill Okubo, IDL Product Manager
|
|
|
|
| Re: IDL 8.0 questions [message #71959 is a reply to message #71863] |
Tue, 27 July 2010 10:37 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Paulo Penteado wrote:
> On Jul 27, 11:51 am, Paul van Delst <paul.vande...@noaa.gov> wrote:
>> Chris Torrence wrote:
>>> This will be fixed in the next available IDL update.
>> Any info on when that will be? I've need to give our sysadmins here enough warning about an additional install in the
>> future for the 8.0 bug fix update.
>
> The eternal unresponsiveness of sysadmins in academic environments...
> Is there anywhere this does not happen? Where they keep software
> updated and fully functional (instead of, say, just command-line IDL
> 6.4)?
This is off-topic, but I feel I have to come to the defense of my overworked sysadmin colleagues! :o)
I've never found any sysadmins I've ever worked with to be unresponsive at all - in my previous academic environment or
in my current non-academic one. My experience has been quite the opposite: in all cases the sysadmins have been *very*
responsive. They may not be able to do all that I might ask them to do, but that is nearly always due to policy issues
(out of their control) or, much much more rarely, simple lack of enough warm bodies to do all that is asked of them on
top of what they are already required to do.
My comment about "enough warning" was to allow our sysadmins to insert the necessary work ticket into their schedules
such that nobody has to feel bad when they knock off at end-of-day.
> Even worse, when all they have to keep is a license server, it is up
> to the users to keep the IDL installation, they still cannot be
> bothered to replace the license file when a new version comes. Which
> is why I argued that license files should not be version-specific.
That's never really been an issue for me. The licensing system IDL uses is generic enough. We use the same license
manager for several licensed products, not just IDL.
Anyway....
cheers,
paulv
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
