Welcome to iraf.net Friday, May 10 2024 @ 02:14 AM GMT
Jason Quinn |
11/12/2008 03:54PM (Read 2938 times)
|
|
|
Status: offline
Registered: 04/07/2006
Posts: 175
|
I have a few quick general questions/suggestions about IRAF scripting:1) is the "file" variable type functionally identical to the "char" and "string" types? (I think the answer is yes but it'd be good to know for sure)2) Is there a way to hide struct pointers (used for file lists) from the user when they do an epar on a procedure script? I always use something like:[code:1:c80594f90e]
procedure mytaskname()struct *fP {"",prompt="Internal. Ignore."}begin
[/code:1:c80594f90e]But this is kind of ugly and adds confusion to the user. Is there a better way to do this? I'd prefer if the user never sees this at all.3) Out of curiosity, how hard (impossible?) would it be to add support for functions within IRAF scripts? I realize that returning a value is unreasonable but what about a limited function (or procedure) with no uparmed variables that just takes input and then performs its code on that input. Sure, you could just write another script. But having "minimal procedures" like this would be a great way to encapsulate code in a single file and without the user having to define multiple tasks to accomplish a goal. I'm thinking along the lines of having two procedures within a single file. When the user defines a new task, IRAF only lets the user "see" the first procedure but when the user runs that procedure, IRAF knows how to use the other procedures. Hopefully that's clear enough to understand the idea. One could argue that if you need functions you should be doing the spp programming but I still think the simplicity of scripts benefits from function support.4) I might have asked this before. Sorry if it's a repeat. What is the best way for a script to detect if an image display server is running? I could of course hack up a way but I really think that this should be a part of the IRAF language. All scripts that need a display server should gracefully exit if there isn't one running. Jason
|
|
|
|
fitz |
11/12/2008 03:54PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Hi Jason,[quote:e57861c305]
1) is the "file" variable type functionally identical to the "char" and "string" types? (I think the answer is yes but it'd be good to know for sure)[/quote:e57861c305]Yes, see https://iraf.net/phpBB2/viewtopic.php?t=87297[quote:e57861c305]2) Is there a way to hide struct pointers (used for file lists) from the user when they do an epar on a procedure script?[/quote:e57861c305]Anything before the 'begin' is considered a param and presently is isn't possible in the grammar for a struct to be a "local list variable". We'd need to change the grammar or implement a 'hideparam' function so these aren't visible.[quote:e57861c305]3) Out of curiosity, how hard (impossible?) would it be to add support for functions within IRAF scripts? [/quote:e57861c305]This was something I was planning to do when I did the error-handling but never got around to. It wouldn't be that hard and was part of general language enhancements such as allowing multiple procedures to be declared in the same .cl file (e.g. to allow you to break up long scripts in one source file and then use "local" procedures rather than declare whole new tasks). The idea was that these 'local procedure' could also be functions. Alas, getting support to improve CL as a scripting language is tough to do nowadays.[quote:e57861c305]I realize that returning a value is unreasonable ....[/quote:e57861c305]Actually, the idea was to allow syntax like "i = myfunc (infile)"
[quote:e57861c305]4) I might have asked this before. Sorry if it's a repeat. What is the best way for a script to detect if an image display server is running? I could of course hack up a way but I really think that this should be a part of the IRAF language. All scripts that need a display server should gracefully exit if there isn't one running.[/quote:e57861c305]The same argument could be made that any script needing graphics should be capable of checking for a graphics-ready terminal, but I don't really buy it. The preferred method would be to wrap your display command in an iferr statement to catch the error and exit, e.g.[code:1:e57861c305]
iferr { display ("dev$pix", 1, >& "dev$null") }
error (0, "No display server runnng")
[/code:1:e57861c305]Cheers,
-Mike
|
|
|
|
| |
|
Content generated in: 0.10 seconds |
|