Tcl_ParseArgv
Chris Nelson
Tk? For the second or third time in as many years, I find that I have
code that depends on Tk _ONLY_ to use Tk_parseArgv. The last thread I
found on groups.google.com ended with a suggestion that I submit a patch
to add Tcl_ParseArgv() based on Tk_ParseArgv(); that was in 1998! I may
not be desperate enough to do that but I'd like some preliminary
feedback before I go to that trouble. Is this a useful change? It is
core bloat?
Chris
--
Never doubt that a small group of thoughtful, concerned citizens
can change the world. Indeed, it's the only thing that ever has.
--Margaret Mead
Don Porter
> Am I the _only_ one who wants to be able to parse arguments in C
> without Tk?
No, I like that idea too.
> Is this a useful change? It is core bloat?
I think it's useful. It's similar to Tcl_WrongNumArgs(). A common
function that almost all extensions need, and if Tcl itself provides
one routine for it, then extensions are better standardized.
A TIP to move it from Tk to Tcl shouldn't need to be very long since we
all know the interface; it's just a move.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Don Porter
>> Am I the _only_ one who wants to be able to parse arguments in C
>> without Tk?
Don Porter wrote:
> A TIP to move it from Tk to Tcl shouldn't need to be very long since we
> all know the interface; it's just a move.
Well, that's not quite right, because Tk_ParseArgv() takes a Tk_Window
argument, so it will need to change a bit in the move.
Cameron Laird
Don Porter <d...@email.nist.gov> wrote:
.
.
.
>I think it's useful. It's similar to Tcl_WrongNumArgs(). A common
.
.
Oo, oo: Tcl_WrongNumArgs(). That's another
one that's occupied my thoughts.
... though not enough to TIP ...
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Don Porter
> Oo, oo: Tcl_WrongNumArgs(). That's another
> one that's occupied my thoughts.
> ... though not enough to TIP ...
??? In what way does the Tcl_WrongNumArgs() interface need revision?
George A. Howlett
> Am I the _only_ one who wants to be able to parse arguments in C without
> Tk? For the second or third time in as many years, I find that I have
> code that depends on Tk _ONLY_ to use Tk_parseArgv. The last thread I
> found on groups.google.com ended with a suggestion that I submit a patch
> to add Tcl_ParseArgv() based on Tk_ParseArgv(); that was in 1998! I may
> not be desperate enough to do that but I'd like some preliminary
> feedback before I go to that trouble. Is this a useful change? It is
> core bloat?
Isn't it easier to process command line arguments in Tcl?
Tk-based applications are somewhat special because they have a
standard set of options used for all Tk applications. Many of the
switches perform one-time initialization actions that have to be done
before the main window exists (-name, -colormap, -visual, -display,
etc.) that forces it to be in C.
I've never used tcllib's cmdline package (I have a set of my own
procedures). Is it wanting for features or convenience?
--gah
Chris Nelson
>
> Chris Nelson <ch...@pinebush.com> wrote:
> > Am I the _only_ one who wants to be able to parse arguments in C without
> > Tk? For the second or third time in as many years, I find that I have
> > code that depends on Tk _ONLY_ to use Tk_parseArgv. The last thread I
> > found on groups.google.com ended with a suggestion that I submit a patch
> > to add Tcl_ParseArgv() based on Tk_ParseArgv(); that was in 1998! I may
> > not be desperate enough to do that but I'd like some preliminary
> > feedback before I go to that trouble. Is this a useful change? It is
> > core bloat?
>
> Isn't it easier to process command line arguments in Tcl?
We're looking to parse arguments in C in our AppInit function.
Chris
--
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
lvi...@yahoo.com
According to George A. Howlett <g...@siliconmetrics.com>:
:Chris Nelson <ch...@pinebush.com> wrote:
:> Am I the _only_ one who wants to be able to parse arguments in C without
:> Tk?
:Isn't it easier to process command line arguments in Tcl?
Not if most of your app is in C...
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
George A. Howlett
> According to George A. Howlett <g...@siliconmetrics.com>:
> :Chris Nelson <ch...@pinebush.com> wrote:
> :> Am I the _only_ one who wants to be able to parse arguments in C without
> :> Tk?
> :Isn't it easier to process command line arguments in Tcl?
> Not if most of your app is in C...
That leads to an interesting question. What parts of your application
are better in Tcl and what parts in are better in C?
My personal view is that Tcl is great for glue. I take building blocks
written in C or C++ (like the Tk widgets) and wire them together with
Tcl in scripts. I get the best of both worlds: flexibility and ease
of programming from Tcl, structure and speed from C.
I can take an application written totally in C and replace the main
program with a Tcl script. The function calls in the main program
become Tcl commands. What this buys me is that I can now rewire my
application in all kinds of interesting ways. How interesting is a
consequence of the core functionality that each command brings.
So I don't understand how one can write a program with Tcl and C and
*not* write the main in Tcl (including argument parsing). You're not
taking advantage of what Tcl is best at. That's just my opinion.
--gah
Andreas Kupries
> lvi...@yahoo.com wrote:
>
> > According to George A. Howlett <g...@siliconmetrics.com>:
> > :Chris Nelson <ch...@pinebush.com> wrote:
> > :> Am I the _only_ one who wants to be able to parse arguments in C without
> > :> Tk?
>
> > :Isn't it easier to process command line arguments in Tcl?
>
> > Not if most of your app is in C...
> That leads to an interesting question. What parts of your application
> are better in Tcl and what parts in are better in C?
> My personal view is that Tcl is great for glue. I take building blocks
> written in C or C++ (like the Tk widgets) and wire them together with
> Tcl in scripts. I get the best of both worlds: flexibility and ease
> of programming from Tcl, structure and speed from C.
Your position seems to be similar to
http://wiki.tcl.tk/ACriticalMindsetAboutPolicy
--
Sincerely,
Andreas Kupries <akup...@shaw.ca>
Join us in Sept. for Tcl'2002: http://www.tcl.tk/community/tcl2002/
Developer @ <http://www.activestate.com/>
Private <http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------
}
Cameron Laird
Don Porter <d...@email.nist.gov> wrote:
>Cameron Laird wrote:
>> Oo, oo: Tcl_WrongNumArgs(). That's another
>> one that's occupied my thoughts.
>> ... though not enough to TIP ...
>
>??? In what way does the Tcl_WrongNumArgs() interface need revision?
.
.
Exposure for scripters; that's all I meant. I end up defining
a local
proc validated_proc {name number_of_args usage_message args body} {
...
}
It's not that the Tcl side needs C coding, but just deserves
standardization.
Don Porter
>>??? In what way does the Tcl_WrongNumArgs() interface need revision?
Cameron Laird wrote:
> Exposure for scripters; that's all I meant. I end up defining
> a local
> proc validated_proc {name number_of_args usage_message args body} {
> ...
> }
> It's not that the Tcl side needs C coding, but just deserves
> standardization.
In Tcl 8.4, the error messages produced by [proc]s when the actual
arguments do not match the formal arguments are consistent with the
messages produced by Tcl_WrongNumArgs().