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?
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
In article <3CB1F58F.3E17...@pinebush.com>, Chris Nelson wrote: > 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.por...@nist.gov Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________|
> In article <3CB1F58F.3E17...@pinebush.com>, Chris Nelson wrote: >> 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.
-- | Don Porter Mathematical and Computational Sciences Division | | donald.por...@nist.gov Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________|
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?
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?
> 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
:> 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:lvir...@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.
lvir...@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.
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.
> > 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.
In article <slrnab42hm.qg7....@clover.cam.nist.gov>, 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. --
>>??? 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().
-- | Don Porter Mathematical and Computational Sciences Division | | donald.por...@nist.gov Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________|
