| Re: Naming batch files and main-level programs [message #50992] |
Thu, 02 November 2006 04:27  |
Robi
Messages: 9
Registered: October 2006
|
Junior Member |
|
|
Hey there Greg,
greg michael wrote:
> I don't see the problem, though - surely the batch files should be
> doing something more specific than the prog files, so use a name that
> reflects that...
You're right, the batch file should be descriptive, so, ya know, I have
batch files like accumulate_map.pro, but that doesn't tell me it's a
batch file when I do a directory listing. And there might be a
function named accumulate_spectra.pro... both very descriptive names,
but not in the sense of telling me whether a routine or batch file or
main-level program lives inside, so your suggestion isn't quite the
whole story. The key is, yes, there should be something descriptive in
the name to differentiate batch files and main-level programs from
routines. But that descriptive name has to include some specifier to
denote its batch-ness or main-level-ness. Something like
accumulate_map.bat.pro, well, that might do the trick. Or
accumulate_map.ml.pro or accumulate_map.main.pro for a main-level
program.
> The other scheme looks ugly to me - won't it mean that IDL can't find any of your routines?
Sorry, I don't understand this question. All routines should be stored
in files ending in .pro, so IDL will always be able to find them if you
specify the !PATH correctly. The ugly scheme you're referring to was a
stab at differentiating the batch files and main-level programs from
real routines (functions and procedures) while still maintaining the
.pro suffix so that IDL will be able to find them. I guess I'm
thinking that there's no way to avoid the gist of the scheme, but I
agree, the .idl and .idlprc part are pretty ugly to me, and seemingly
pulled out of the blue. I guess .bat.pro and .main.pro might be a bit
more descriptive.
Also, I think I'm being exhaustive when I state that the only types of
code that can be stored in text files and then used in some fashion by
IDL are routines, batch files and main-level programs. I've been using
these for years and always wondered if other people had worried about
differentiating them. I hadn't really started to trip over my own feet
until this last week when I started a huge project in a very ad-hoc
fashion and ended up with a ton of batch files and main-level programs.
They're nice for playing with complex data sets because they allow you
to have the functionality of a function or procedure but also allow you
to have command
line access to the variables that are defined at the MAIN level.
Best -Tim.
|
|
|
|
|
|
| Re: Naming batch files and main-level programs [message #51090 is a reply to message #50992] |
Thu, 02 November 2006 05:05  |
greg michael
Messages: 163
Registered: January 2006
|
Senior Member |
|
|
Hi Tim,
But if your routine is called 'fred' and you save it in a file called
fred.idl.pro, when you call fred, IDL will be looking for fred.pro...
and therefore not find it.
If I had this problem, I'd either just put the batch files in their own
directory which tells what they are (maybe called 'batch'), or tag the
batch files and leave the rest alone (although probably better with a
'_' separator than a '.', for the reason above. You can also use a file
with no extension to indicate a batch file - that's fine on UNIX; not
ideal on Windows.
regards,
Greg
|
|
|
|
| Re: Naming batch files and main-level programs [message #51091 is a reply to message #50992] |
Thu, 02 November 2006 04:57 |
Paolo Grigis
Messages: 171
Registered: December 2003
|
Senior Member |
|
|
If you really have trouble distinguishing them,
why don't you just put them in different subdirectories?
Somehting like
\yourproject\batch\
\yourproject\routines\
should clear any ambiguity...
Ciao,
Paolo
Tim wrote:
> Hey there Greg,
>
> greg michael wrote:
>
>> I don't see the problem, though - surely the batch files should be
>> doing something more specific than the prog files, so use a name that
>> reflects that...
>
>
> You're right, the batch file should be descriptive, so, ya know, I have
> batch files like accumulate_map.pro, but that doesn't tell me it's a
> batch file when I do a directory listing. And there might be a
> function named accumulate_spectra.pro... both very descriptive names,
> but not in the sense of telling me whether a routine or batch file or
> main-level program lives inside, so your suggestion isn't quite the
> whole story. The key is, yes, there should be something descriptive in
> the name to differentiate batch files and main-level programs from
> routines. But that descriptive name has to include some specifier to
> denote its batch-ness or main-level-ness. Something like
> accumulate_map.bat.pro, well, that might do the trick. Or
> accumulate_map.ml.pro or accumulate_map.main.pro for a main-level
> program.
>
>
>> The other scheme looks ugly to me - won't it mean that IDL can't find any of your routines?
>
>
> Sorry, I don't understand this question. All routines should be stored
> in files ending in .pro, so IDL will always be able to find them if you
> specify the !PATH correctly. The ugly scheme you're referring to was a
> stab at differentiating the batch files and main-level programs from
> real routines (functions and procedures) while still maintaining the
> .pro suffix so that IDL will be able to find them. I guess I'm
> thinking that there's no way to avoid the gist of the scheme, but I
> agree, the .idl and .idlprc part are pretty ugly to me, and seemingly
> pulled out of the blue. I guess .bat.pro and .main.pro might be a bit
> more descriptive.
>
> Also, I think I'm being exhaustive when I state that the only types of
> code that can be stored in text files and then used in some fashion by
> IDL are routines, batch files and main-level programs. I've been using
> these for years and always wondered if other people had worried about
> differentiating them. I hadn't really started to trip over my own feet
> until this last week when I started a huge project in a very ad-hoc
> fashion and ended up with a ton of batch files and main-level programs.
> They're nice for playing with complex data sets because they allow you
> to have the functionality of a function or procedure but also allow you
> to have command
> line access to the variables that are defined at the MAIN level.
>
> Best -Tim.
>
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
