2009/10/6 David Berry <[log in to unmask]>:
> One option would be to modify kpg1_gtgrp so that, before exiting, it
> concatenates all the elements in the returned group into a single
> comma-delimited string, and stores this string as the current value of
> the parameter. This is a bit like what kpg1_gtgrp already does, except
> that currently it only concatenates values supplied via multiple
> prompts (each ending with a minus sign). But there are two practical
> issues with this dea:
>
> 1) I wrote kpg1_gtgtp 11 years ago, so I can't remember the details,
> but I *do* remember that finding a way to set the current value of a
> "READ" parameter was difficult. And indeed, now I try it in practice,
> it seems not to work :-( That is, if you split up a group expression
> over (say) two prompts by ending the first prompt value with a minus
> sign, and then examine the contents of the application parameter file,
> you see that the current parameter value only hold the final prompt
> value, not the concatenation of all values. Still, there must surely
> be some way of setting the current value of a READ parameter from
> within a program (kpg1_gtgrp currently uses subpar_putname).
I've fixed kpg1_gtgrp by storing the current value with subpar_cursav
rather than subpar_putname. So now kpg1_gtgrp correctly does what it
was always supposed to do - stores the concatenated group expressions
as the current parameter value. Note, I've *not* changed it to store
the concatenated group *elements*.
There could be problems simply storing the concatenated list of group
elements as the current parameter value for the group parameter. What
would happen the next time the parameter was accessed? If the
parameter has PPATH=CURRENT, then the whole list of elements would be
presented within the parameter prompt. Maybe not a problem for short
groups, but for long groups the prompt string could go on for several
lines (although presumably subpar would choke on such long prompt
strings). Also, GRP itself has a limit of 255 characters for a single
group expression, so accepting the current value could cause GRP to
report an error.
What could work though, is if kpg1_grgrp was to store the concatenated
list of elements using a different parameter. So if kpg1_gtgrp is
called to get a value for parameter "CONFIG" (for instance), it could
store the list of group elements as the current value for parameter
"CONFIG_V". It would need to create an IFL entry for each such "_V"
parameter. Presumably it could call PARSECON_NEWPAR to do this, like
you did for MSG_FILTER etc. When the NDF is closed, the NDF library
would store values for both CONFIG and CONFIG_V in the history record.
Does that sound any good?
David
> 2) The contents of a file can be arbitrarily long, so I'd not be
> surprised if concatenating all the contents of a file into a single
> string and storing it as the current parameter value did not trigger
> some problem within subpar such as filling of fixed-sized buffers etc.
> And then it could lead to huge bloat in the history text which may
> often not be what you want in all cases.
>
> Still, I could look further into whether this option is doable or not.
>
> David
>
>
> 2009/10/5 Tim Jenness <[log in to unmask]>:
>> In SMURF some of the commands use big config files that are read using
>> kpg1Kymap and kpg1Gtgrp. The main problem we have is that the HISTORY
>> written out simply reports the name of the config file (with a "^") and not
>> its contentns. Usually the name is irrelevant and the contents are
>> important. I'm wondering whether anyone has ideas for a general solution to
>> this problem (maybe in NDF or KAPLIBS) before embarking on some
>> smurf-specific hack for dumping the AST keymap into an additional history
>> record (or even dumping the whole thing in a SMURF extension). There are
>> many places where this sort of thing would be useful (I'm thinking of IN/OUT
>> parameters that read a GRP file but then don't write the filenames into the
>> parameters). Recognizing GRP inputs automatically would be really useful.
>>
>> --
>> Tim Jenness
>> Joint Astronomy Centre
>>
>
|