| Re: Attempt to subscript FILNAM with I is out of range.... [message #31721] |
Fri, 16 August 2002 12:43  |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Fri, 16 Aug 2002 01:05:11 -0700, Timm Weitkamp wrote:
> Kolbjorn,
>
> Following Craig's suggestion is definitely the easiest (and cleanest)
> way, but I think his script "run_myfile.pro" should be extended by one
> line that will make all the difference:
>
> .run myfile.pro ; compile the routine(s) contained in myfile.pro
> myfile ; run procedure myfile (if that's what is in
> myfile.pro) exit ; quit IDL
>
> Don't let yourself confuse by the fact that file naming conventions in
> IDL are such that the ".pro" extension is used for both batch scripts
> and files containing procedures and/or functions, or by the fact that
> the .RUN statement only *compiles* the routines in its argument file,
> but does *not run* them. This is why the additional 2nd line in the
> batch file above is needed, which must have seemed too obvious to Craig
> so he didn't mention it.
Or he meant for myfile.pro to contain a MAIN-level routine, i.e. one like:
do_some_stuff
for i=0,1000 do begin
do_something_else
endfor
end
This doesn't have the batch file no-multi-line-block restriction, and only
differs from a real procedure in that no routine definition is included
(but notice the mandatory closing END statement), and, obviously, no
arguments are allowed. When you ".run" a main level routine, it compiles
and runs at the same time. In fact it is re-compiled each time -- one
advantage to MAIN-level routines is you don't have to compile then run for
each change:
IDL> .run myplot
<change some plot parameters>
IDL> .run myplot ; new plot
They're good for one-off scripts like plotting sequences.
The only good uses of batch files I can think of:
1. Including small definitions, especially common blocks:
pro my_pro
@my_common_block
end
in my_common_block:
common my_common_block,blarh,foo,test
Why is this a nice way to include common blocks? If it's used throughout
many different files, redifining it becomes an awful chore. But if it's
just included from a single file, all changes (e.g. adding a variable)
occur in one place. And no, using the abbreviated form:
common my_common_block
doesn't always work. For this to succeed you need one point of entrance
where the common block can be defined... not always practical.
2. Because they're the default for scripts mentioned on the command line
(though SAVE files can also be used, as was demonstrated). Not really an
advantage, just a necessity.
JD
|
|
|
|
|
|
| Re: Attempt to subscript FILNAM with I is out of range.... [message #31724 is a reply to message #31722] |
Fri, 16 August 2002 10:15  |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Kolbjorn Bekkelund wrote:
> On Fri, 16 Aug 2002 09:08:42 +0000, Reimar Bauer wrote:
>
>
>> Dear Kolbjorn
>>
>> I was believing that's in idl5.5 the "& $" isn't any more necessary. Am
>> I wrong? Or did you use idl 5.4 ?
>
> You're right !
> I'm using 5.4.
>
>>
>> One more comment to your code. you should use [] for arrays and () for
>> functions. itim(i) is an array. If you always use only () you can get in
>> a conflict if sometimes a variable is named like a function.
>
> I'll tryu to clean it after the functionality is ok. The base of the
> program is remains after some older guys working here earlier. They
> preferred the "manual" way. I'm trying to automate this old program, and
> it works 95 %, but I've got a new problem that I found today when I had
> the system running past midnight. The plot timescale is supposed to be a
> result of the old manual inout of start- and stop time. ie: if I enter 22
> 00 and 03 00, the
> timescale is 22-03.
>
Dear Kolbjorn
this is a more general problem with the handling of time series data.
I speak from a general problem because their might be an easy fix of
this but then you have always later on to do more fixes too.
For example if you like to do some interpolations or comparisions etc.
My suggestion is to use as we do julian seconds for the time.
Julian seconds is based on 2000-01-01 00:00:00 UTC.
It wss defined by Ray Sterner
(http://fermi.jhuapl.edu/s1r/idl/s1rlib/time/time.html)
and he and we too have a lot of routines for this timeforamt.
( http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_source/idl _html/idl_work_libraries.htm)
The idea of this is all timeseries data are stored continously.
The advantages is plenty described by Ray.
( http://fermi.jhuapl.edu/s1r/idl/s1rlib/time/time_series.html)
This is a small example for a plot
you need the package setup_time_axis and string2js from our library.
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_source/idl _html/dbase/download/setup_time_axis.tar.gz
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_source/idl _html/dbase/download/jstring2.tar.gz
or as idl 5.5 binary
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_source/idl _html/dbase/download/setup_time_axis.sav
http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_source/idl_ html/dbase/download/js2string.sav
(Remember a idl compiled file with the extension sav is automaticly loaded
the first time it is used. This is the same behaviour as for idl sources
(.pro). They run on each idl platform with the same idl version)
Please have a look for further routines and licensing at
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
Only for my interest, which kind of format is the data you have is it
NASA Ames ?
pro test
x=dindgen(30)*3600.0+string2js(/now)
y=sin(findgen(30)/10.)
tf='DD-MM!CHH:MM'
setup_time_axis, x, XRANGE = xrange, XSTYLE = xstyle, $
XTITLE = 'time UTC', $
XTICKS = xticks, XMINOR = xminor,$
XTICKV = xtickv, XTICKNAME = xtickname, $
TIMEFORMAT = tf, TIMESTEP = ts, NO_DATE = nod
help,xrange,yrange
help,xtickname
help,xtickv
plot,x,y,XRANGE = xrange, XSTYLE = xstyle, XTITLE = 'time UTC', $
XTICKS = xticks, XMINOR = xminor, XTICKV = xtickv, XTICKNAME = xtickname
end
In the description of js2time which is included into the package are the
several time formats descibed.
best regards
Reimar
> With my way of doing it, setting the inputs to fixed 00-24 I get a nice
> timescale of 24 hours, but all files occuring after 24 is not plotted. I
> would really like some help getting that set up right. Any ideas ?
>
> A system where the plot is moving the timescale to the left as soon as it
> hits the upper time limit would be nice. At least I would like to get rid
> of the stupid way is't done now.
>
>> Labels as Label1: are very bad program style in my eyes and the code
>> could be very hard to understand.
>
> As I said above- I'll certainly clean the code in the end !!
> Runtime license is not an option. Economics you see. We've got two server
> licenses soon, so I'll survive.
>
> I've included the whole code below for you to see.
>
> ====================================================
>
> PRO BATCH_CALC_QUALITY_DUAL_ONLINE_AUTO, filnam
> device, decomposed = 0
> loadct, 23
>
> fil_dir = ''
> fil_dir = '/data/ozon/dialdata/ozon-online/*'
> filnam = findfile(fil_dir)
> iff = N_ELEMENTS(filnam)
>
> dummy = ''
> idat = intarr(3) & idat0 = 0 & dat = fltarr(2) & idat1 = lonarr(4)
> ref308 = fltarr(iff) & ref353 = fltarr(iff) & itim = fltarr(iff)
> back308 = fltarr(iff) & back353 = fltarr(iff) & dz = fltarr(iff)
> hr = 0 & min = 0 & stim = 0. & etim = 0.
> hr='00'
> min='00'
> stim = hr + min/60.
> hr='24'
> min='00'
> etim = hr + min/60.
> IF etim LT stim THEN etim = etim + 24.
>
> FOR i = 0, iff-1 DO BEGIN & $
> openr, resf, filnam(i), /get_lun & $
> filnavn=STRMID(filnam(i), 32,5) & $
> FOR j = 0, 5 DO readf, resf, dummy & $
> readf,resf,format = '(a36,i2,1x,i2,1x,i2)',dummy,idat & $
> itim(i) = idat(0) + (idat(1) + idat(2)/60.)/60. & $
> IF itim(i) LT itim(0) THEN itim(i) = itim(i) + 24. & $
> IF itim(i) LT stim OR itim(i) GT etim THEN GOTO, label1 & $
>
> readf, resf, dummy & $
> readf, resf, format = '(a24,i6)', dummy, ishot & $
> FOR j = 0, 5 DO readf, resf, dummy & $
> iback = 0 & $
> WHILE NOT eof(resf) DO BEGIN & $
> readf,resf,idat0,dat,idat1 & $
> IF dat(1) EQ 19.993 THEN BEGIN & $
> dz(i) = dat(0)/1000. & $
> ref308(i) = idat1(0)/dz(i) & $
> ref353(i) = idat1(2)/dz(i) & $
> ENDIF & $
> IF dat(1) GE 85. AND dat(1) LT 87. THEN BEGIN & $
> back308(i) = back308(i) + idat1(0)/dz(i) & $
> back353(i) = back353(i) + idat1(2)/dz(i) & $
> iback = iback + 1 & $
> ENDIF & $
> ENDWHILE & $
> back308(i) = (back308(i)/iback)/ishot & $
> back353(i) = (back353(i)/iback)/ishot & $
>
> ref308(i) = (ref308(i)/ishot)-back308(i) & $
> ref353(i) = (ref353(i)/ishot)-back353(i) & $
> Label1: & $
> free_lun, resf & $
> ENDFOR ; i
>
> dato= systime()
>
> !p.multi = [0,1,2]
>
> window, 0, xsize=800, ysize=600, title='ALOMAR Ozone Lidar Combined
> Signal/Background Count'
> usersym, [ -1, 0, 1, -1 ], [ 1, -1, 1, 1 ], color=166, /fill
> ; filled downward triangle
> plot_io, itim, ref308, psym = 8, color=119, yrange = [0.001, 200.],
> yticklen=1, ygridstyle=2, ystyle = 1, xstyle = 1, $
> xrange = [stim,etim],xtitle = 'Time printed [UT]: '+ dato +'', title =
> 'Signal at 19.993 km ' + filnavn
> axis, yaxis = 0, color=119, yrange = [0.001, 200.], ystyle = 1, $
> xrange = [stim,etim],ytitle = 'normalized countrate [cts/km.shot]'
> usersym, [ -1, 0, 1, -1 ], [ -1, 1, -1, -1 ], color=217, /fill
> ; filled upward triangle
> oplot,itim,ref353,psym = 8
>
> ;xyouts, 460, 450, 'Green: 308 nm', /device
> ;xyouts, 460, 460, 'Yellow: 353 nm', /device
>
> usersym, [ -1, 0, 1, -1 ], [ -1, 1, -1, -1 ], color=217, /fill
> ; filled upward triangle
> plot_io, itim, back353, psym = 8, color=119, yrange = [1e-5,
> 100],yticklen=1, ygridstyle=2, ystyle = 1, xstyle = 1, $
> xrange = [stim,etim],xtitle = 'Time printed [UT]: '+ dato +'', title =
> 'Background on ' + filnavn + ', 85 - 87 km', $ ytitle = 'normalized
> countrates [cts/km.shot]'
>
> usersym, [ -1, 0, 1, -1 ], [ 1, -1, 1, 1 ], color=166, /fill
> ; filled downward triangle
> oplot,itim,back308,psym = 8
>
> ;xyouts, 460, 450, 'Green: 308 nm', /device
> ;xyouts, 460, 460, 'Yellow: 353 nm', /device
>
> write_png, '/data/ozon/plots/latest-combined.png', tvrd(/true)
>
> close,/all
> exit, status=45
> END
>
> ====================================================
>
>
> Best regards,
> Kolbjorn
>
--
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
http://www.fz-juelich.de/icg/icg-i/
============================================================ ======
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
|
|
|
|
|
|
| Re: Attempt to subscript FILNAM with I is out of range.... [message #31727 is a reply to message #31726] |
Fri, 16 August 2002 02:08 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Kolbjorn Bekkelund wrote:
> Hi again, David.
>
> As I said; When running FOR statements in batch mode the IDL help said
> that I had to connect all lines after BEGIN until ENDFOR to one line. I
> did this by using & $ after each line in the original FOR statement.
>
> I ended up with this:
Dear Kolbjorn
I was believing that's in idl5.5 the "& $" isn't any more necessary.
Am I wrong? Or did you use idl 5.4 ?
One more comment to your code. you should use [] for arrays
and () for functions. itim(i) is an array.
If you always use only () you can get in a conflict if sometimes
a variable is named like a function.
Labels as Label1: are very bad program style in my eyes and the code
could be very hard to understand.
Did you have thougt about an idl runtime version of your program,
Bevause it looks like a procedure with one input parameter but this
isn't used it's overwritten by the findfile function.
I believe more you have an older version because findfile is replaced
by file_search in idl5.5.
These steps are required
.compile batch_calc_quality_dual_online_auto
resolve_all
save,file='batch_calc_quality_dual_online_auto.sav',/routine s,/compress
Now you can execute in a cron job the runtime routine
idl -rt="./batch_calc_quality_dual_online_auto.sav"
If you do so you can work together with your development license while
this job is running.
regards
Reimar
>
> PRO BATCH_CALC_QUALITY_DUAL_ONLINE_AUTO, filnam
> device, decomposed = 0
> loadct, 23
>
> fil_dir = ''
> fil_dir = '/data/ozon/dialdata/ozon-online/*'
> filnam = findfile(fil_dir)
> iff = N_ELEMENTS(filnam)
>
> dummy = ''
> idat = intarr(3) & idat0 = 0 & dat = fltarr(2) & idat1 = lonarr(4)
> ref308 = fltarr(iff) & ref353 = fltarr(iff) & itim = fltarr(iff)
> back308 = fltarr(iff) & back353 = fltarr(iff) & dz = fltarr(iff)
> hr = 0 & min = 0 & stim = 0. & etim = 0.
> hr='00'
> min='00'
> stim = hr + min/60.
> hr='24'
> min='00'
> etim = hr + min/60.
> IF etim LT stim THEN etim = etim + 24.
>
> FOR i = 0, iff-1 DO BEGIN & $
> openr, resf, filnam(i), /get_lun & $
> filnavn=STRMID(filnam(i), 32,5) & $
> FOR j = 0, 5 DO readf, resf, dummy & $
> readf,resf,format = '(a36,i2,1x,i2,1x,i2)',dummy,idat & $
> itim(i) = idat(0) + (idat(1) + idat(2)/60.)/60. & $
> IF itim(i) LT itim(0) THEN itim(i) = itim(i) + 24. & $
> IF itim(i) LT stim OR itim(i) GT etim THEN GOTO, label1 & $
>
> readf, resf, dummy & $
> readf, resf, format = '(a24,i6)', dummy, ishot & $
> FOR j = 0, 5 DO readf, resf, dummy & $
> iback = 0 & $
> WHILE NOT eof(resf) DO BEGIN & $
> readf,resf,idat0,dat,idat1 & $
> IF dat(1) EQ 19.993 THEN BEGIN & $
> dz(i) = dat(0)/1000. & $
> ref308(i) = idat1(0)/dz(i) & $
> ref353(i) = idat1(2)/dz(i) & $
> ENDIF & $
> IF dat(1) GE 85. AND dat(1) LT 87. THEN BEGIN & $
> back308(i) = back308(i) + idat1(0)/dz(i) & $
> back353(i) = back353(i) + idat1(2)/dz(i) & $
> iback = iback + 1 & $
> ENDIF & $
> ENDWHILE & $
> back308(i) = (back308(i)/iback)/ishot & $
> back353(i) = (back353(i)/iback)/ishot & $
>
> ref308(i) = (ref308(i)/ishot)-back308(i) & $
> ref353(i) = (ref353(i)/ishot)-back353(i) & $
> Label1: & $
> free_lun, resf & $
> ENDFOR ; i
>
>
> Now I can run 'idl batch_calc_quality_dual_online_auto.pro' and get my
> plots via a cron-job in Linux.
>
> Thanks for bearing over with me :-)
>
> Kolbjorn
>
> On Thu, 15 Aug 2002 18:44:34 +0000, David Fanning wrote:
>
>> Kolbjorn Bekkelund (kobe@rocketrange.no) writes:
>>
>>> I'm following up my own last post since I found that one cannot use FOR
>>> statements in batch mode like in normal .run. You have to place all the
>>> FOR stuff (until the ENDFOR) on one line using $ and &. This because
>>> the batch mode use of IDL is looking for an END statement on each line
>>> after the BEGIN. If it doesn't find it you get a syntax error.
>>>
>>> BUT:
>>> How do I split the below FOR ..... ENDFOR using $ and &, and still make
>>> it work ????
>>
>> Kolbjorn,
>>
>> You *really* don't want to do this!
>>
>> You have written the code as a procedure. Why not just use it as a
>> procedure? (Put the name of the procedure in your batch file.) What am I
>> missing!?
>>
>> David
>
>
|
|
|
|
| Re: Attempt to subscript FILNAM with I is out of range.... [message #31728 is a reply to message #31727] |
Fri, 16 August 2002 01:05 |
Timm Weitkamp
Messages: 66
Registered: August 2002
|
Member |
|
|
Kolbjorn,
Following Craig's suggestion is definitely the easiest (and cleanest) way,
but I think his script "run_myfile.pro" should be extended by one line
that will make all the difference:
.run myfile.pro ; compile the routine(s) contained in myfile.pro
myfile ; run procedure myfile (if that's what is in myfile.pro)
exit ; quit IDL
Don't let yourself confuse by the fact that file naming conventions in IDL
are such that the ".pro" extension is used for both batch scripts and
files containing procedures and/or functions, or by the fact that the .RUN
statement only *compiles* the routines in its argument file, but does *not
run* them. This is why the additional 2nd line in the batch file above is
needed, which must have seemed too obvious to Craig so he didn't mention
it.
Cheers,
Timm
On 15.08.02 at 16:14 -0500, Craig Markwardt wrote:
> [...]
>
> The first easiest solution is to make a separate file called
> run_myfile.pro, which contains the lonely statement:
>
> .run myfile.pro
> exit
>
> and then use "idl run_myfile.pro". Since run_myfile.pro is fed to the
> IDL command interpreter, the .RUN directive will work. Why you don't
> want to call it as a procedure, well that's up to you.
>
> Good luck,
> Craig
--
Timm Weitkamp E-mail: timm.weitkamp@psi.ch
Paul Scherrer Institut (PSI) http://people.web.psi.ch/weitkamp
CH-5232 Villigen, Switzerland
|
|
|
|
| Re: Attempt to subscript FILNAM with I is out of range.... [message #31735 is a reply to message #31728] |
Thu, 15 August 2002 14:14 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Kolbjorn Bekkelund <kobe@rocketrange.no> writes:
> I'm following up my own last post since I found that one cannot use FOR
> statements in batch mode like in normal .run. You have to place all the
> FOR stuff (until the ENDFOR) on one line using $ and &. This because the
> batch mode use of IDL is looking for an END statement on each line after
> the BEGIN. If it doesn't find it you get a syntax error.
As David was saying, probably the *last* thing you want to do is put
all sorts of $ and &'s througout your file. It makes it pretty
incomprehensible.
First of all, IDL code which is run from the command line like you are
doing, "idl myfile.pro", is read directly into the command line
interpretter. Procedure definitions are not allowed, and multi-line
code blocks are not allowed, as you have found out.
The first easiest solution is to make a separate file called
run_myfile.pro, which contains the lonely statement:
.run myfile.pro
exit
and then use "idl run_myfile.pro". Since run_myfile.pro is fed to the
IDL command interpreter, the .RUN directive will work. Why you don't
want to call it as a procedure, well that's up to you.
Good luck,
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Attempt to subscript FILNAM with I is out of range.... [message #31738 is a reply to message #31735] |
Thu, 15 August 2002 13:06 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Kolbjorn Bekkelund (kobe@rocketrange.no) writes:
> I'm not a scientist, nor an IDL purist :-(
> I'm only a systems engineer at an observatory, trying my best to make our
> daily work a bit more flexible. I've got a feeling that my solution to
> the problem offended your professional IDL skills ?
No, no. Not at all. I've always been firmly
in the "whatever works" camp. :-)
> I'm pretty new to IDL, that's for sure, but I'll try to improve and learn
> as I walk withn the help of good guys like you :-)
I'm pretty sure that as long as you keep a sense
of humor about things, you will learn quickly.
Anyway, we need more arctic guys. And I expect
typing all those damn "& $" characters will warm
your hands up during those long, cold winters. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
|
|
| Re: Attempt to subscript FILNAM with I is out of range.... [message #31742 is a reply to message #31740] |
Thu, 15 August 2002 12:43 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
David Fanning (david@dfanning.com) writes:
> Oh, dear! You must be a scientist instead of an IDL
> purist. But I can hear shutters all over IDL-dom. :-)
My God, people, do I have to explain everything to you!
No one could possibly hear shudders, but windows slamming
means... Oh, never mind. I'm going back to writing my
new book, "Programming the Way Our Grandfathers Did:
Writing the Elegant Batch File". :-(
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Attempt to subscript FILNAM with I is out of range.... [message #31750 is a reply to message #31748] |
Thu, 15 August 2002 11:20 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Kolbjorn Bekkelund (kobe@rocketrange.no) writes:
> Hi again, David.
>
> I've checked the value of i and it starts at 0 and grows up to number of
> files contained in the ozon-online. No -1 !!
>
> What's strange is that the program runs without any hitches from within
> IDL, but if ran as part of a script with 'idl pro-name.pro' it craches.
> I've included the start of the code below. The rest, not included, is just the plotting
> stuff. maybe you can see something ?
Well, I'm perplexed. This code didn't generate those
errors unless no files were found in the location you
were looking for them. :-)
Why don't you set a breakpoint and step through your code,
examining things as you go. That's the best way to discover
these kinds of errors.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
|
|
|
|
| Re: Attempt to subscript FILNAM with I is out of range.... [message #31818 is a reply to message #31728] |
Fri, 16 August 2002 17:07 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Timm Weitkamp <timm.weitkamp@psi.ch> writes:
> Kolbjorn,
>
> Following Craig's suggestion is definitely the easiest (and cleanest) way,
> but I think his script "run_myfile.pro" should be extended by one line
> that will make all the difference:
>
> .run myfile.pro ; compile the routine(s) contained in myfile.pro
> myfile ; run procedure myfile (if that's what is in myfile.pro)
> exit ; quit IDL
Right, I missed that "PRO" at the top of his file.
Of course, because he was running the file like an "@" script, the PRO
statement was ignored, and the rest of the commands were simply
executed.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
