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

Home » Public Forums » archive » Re: gzipped files
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: gzipped files [message #11433] Thu, 16 April 1998 00:00 Go to next message
davidf is currently offline  davidf
Messages: 2866
Registered: September 1996
Senior Member
Dallas Masters (dallas@lanl.gov) writes:

> How can I pass the piped output (LUN) to READ_BMP, READ_GIF, READ_TIFF?
> These procedures take file names as inputs, not LUNs. Is there a way
> around this?
>
> Why did RSI not make all I/O routines take either one flavor or all
> flavors: file name string or LUN? LUNs would make IDL much easier to
> hack.

I have the distinct feeling I am missing something obvious
here, by why can't you just unzip the files in some temporary
"data" directory, use FindFile to get all of their names,
and then read and delete them to your hearts content?

Using LUNs to access files would surely be hacker heaven,
but as for me, I'm content to use file *names*.

Cheers,

9702210438

-----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
E-Mail: davidf@dfanning.com
Phone: 970-221-0438
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Re: gzipped files [message #11434 is a reply to message #11433] Thu, 16 April 1998 00:00 Go to previous messageGo to next message
Dallas Masters is currently offline  Dallas Masters
Messages: 3
Registered: April 1998
Junior Member
David Foster wrote:
>
> then use
> SPAWN to unzip the files if you're on a UNIX system. How you read
> them depends on what kind of files they are. You might use
> one of the READ_BMP, READ_GIF, etc. routines. If the images are

snip

How can I pass the piped output (LUN) to READ_BMP, READ_GIF, READ_TIFF?
These procedures take file names as inputs, not LUNs. Is there a way
around this?

Why did RSI not make all I/O routines take either one flavor or all
flavors: file name string or LUN? LUNs would make IDL much easier to
hack.

Thanks,
--
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Dallas Masters
Space Engineering Group, NIS-4
Los Alamos National Laboratory
(505)665-8018
Re: gzipped files [message #11555 is a reply to message #11433] Mon, 20 April 1998 00:00 Go to previous messageGo to next message
Dallas Masters is currently offline  Dallas Masters
Messages: 3
Registered: April 1998
Junior Member
Martin Schultz wrote:
>
> PS: But what I am really wondering about is WHY is READ_TIFF a function,
> whereas READ_GIF is a procedure ?

I wondered about this too, but a co-worker set me straight. RSI is very
good about backwards compatibility. Since most of the routines
originated from users, RSI doesn't tinker much with old code in new
releases. The fear is that everyone's calls to old code will die if RSI
were to "standardize". That's why READ_GIF and READ_TIFF are two very
different beasts--and will probably stay that way.

That's also why my wish for LUN or file name (or both) input
standardization will probably not happen except by my own hacking. If
everything could be like perl...

Cheers,
--
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Dallas Masters
Space Engineering Group, NIS-4
Los Alamos National Laboratory
(505)665-8018
Re: gzipped files [message #11569 is a reply to message #11433] Fri, 17 April 1998 00:00 Go to previous messageGo to next message
Martin Schultz is currently offline  Martin Schultz
Messages: 515
Registered: August 1997
Senior Member
Dallas Masters wrote:
>
> David Foster wrote:
>>
>> then use
>> SPAWN to unzip the files if you're on a UNIX system. How you read
>> them depends on what kind of files they are. You might use
>> one of the READ_BMP, READ_GIF, etc. routines. If the images are
>
> snip
>
> How can I pass the piped output (LUN) to READ_BMP, READ_GIF, READ_TIFF?
> These procedures take file names as inputs, not LUNs. Is there a way
> around this?
>
> Why did RSI not make all I/O routines take either one flavor or all
> flavors: file name string or LUN? LUNs would make IDL much easier to
> hack.
>
> Thanks,
> --

Just grab the READ_* routines from the IDL lib directory and adapt them
to your needs. A compatible way to do it would be something like :

if (n_elements(ilun) eq 0) then $
openr,ilun,filename,...


But of course you would have to do some error checking
(A) whether the files has been opened (fstat)
(B) if you need the name, make sure it is valid


Maybe RSINC will be interested in your patches.

Regards,
Martin.

PS: But what I am really wondering about is WHY is READ_TIFF a function,
whereas READ_GIF is a procedure ?

--
------------------------------------------------------------ -------
Dr. Martin Schultz
Department for Earth&Planetary Sciences, Harvard University
186 Pierce Hall, 29 Oxford St., Cambridge, MA-02138, USA

phone: (617)-496-8318
fax : (617)-495-4551

e-mail: mgs@io.harvard.edu
IDL-homepage: http://www-as.harvard.edu/people/staff/mgs/idl/
------------------------------------------------------------ -------
Re: gzipped files [message #11625 is a reply to message #11433] Thu, 23 April 1998 00:00 Go to previous message
gurman is currently offline  gurman
Messages: 82
Registered: August 1992
Member
In article <353BEF2F.45AD826@lanl.gov>, Dallas Masters <dallas@lanl.gov> wrote:

> If
> everything could be like perl...

Aaargh. I don't know how you'd finish the sentence, but I would say,
"no two pieces
of code to do the same thing would look even vaguely alike."

Joe Gurman

--
Joseph B. Gurman / NASA Goddard Space Flight Center/ Solar Data
Analysis Center / Code 682 / Greenbelt MD 20771 USA / Federal
employees are still prohibited from holding opinions while at work.
Any opinions expressed herein must therefore be someone else's.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: Data Handling
Next Topic: Re: object creation question

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

Current Time: Wed Oct 08 19:12:24 PDT 2025

Total time taken to generate the page: 0.00617 seconds