On Thu, Jan 15, 2009 at 11:10 AM, Matt Revelle wrote:
>
> Perhaps for built-in types, the command-line spec should support
> defining the destination type and handle the conversion from string.
That's an interesting idea. It would allow the automatic help text to
be more specific as well.
--Ch
On Jan 15, 2009, at 10:51 AM, Chouser wrote:
>
> On Mon, Jan 12, 2009 at 10:58 PM, aria42 wrote:
>>
>> Couldn't it have access to the other bindings so far like let? And
>> then just have the order of options reflect the partial order induced
>> by dependency? So is this possible...
>>
>> (with
On Mon, Jan 12, 2009 at 10:58 PM, aria42 wrote:
>
> Couldn't it have access to the other bindings so far like let? And
> then just have the order of options reflect the partial order induced
> by dependency? So is this possible...
>
> (with-command-line *command-line-args*
> "my-program"
> [[si
Couldn't it have access to the other bindings so far like let? And
then just have the order of options reflect the partial order induced
by dependency? So is this possible...
(with-command-line *command-line-args*
"my-program"
[[size "The size of something" #(if % (Integer/parseInt %) 99)]
On Mon, Jan 12, 2009 at 9:44 PM, aria42 wrote:
>
> Currently, you'd need to do something like this, where you might re-
> def the var
>
> (with-command-line *command-line-args*
> "my-program"
> [[picture "Path to Picture" "/default/path"]]
> (def picture (load-picture picture))
> (blah))
I u
Hi,
I've got some suggestions for improving command-line.clj...
It would be great if you could provide a function to be called with
the value of the option and the result of that function binds to the
variable. This would take care of the annoying stuff like calling
(Integer/parseInt intAsStr)
