Menu
▾
▴
naviserver-devel
|
From: Stephen D. <sd...@gm...> - 2005-02-21 23:27:18
|
Has anyone had a chance to look at the Ns_ParseObjv() patch I posted? http://sourceforge.net/tracker/index.php?func=detail&aid=1122940&group_id=130646&atid=719009 My main concern is that the general approach is about right. Does it make sense? One thing I notice is that there's no facility to check the presence of a switch that doesn't take an arg, a boolean switch. That is a simple Ns_ObjvProc plugin. I have a couple of other patches which use the facility so I'd like to make some headway with it. Thanks! |
|
From: Zoran V. <zv...@ar...> - 2005-02-22 14:56:35
|
On Tuesday 22 February 2005 00:27, Stephen Deasey wrote: > Has anyone had a chance to look at the Ns_ParseObjv() patch I posted? > > http://sourceforge.net/tracker/index.php?func=detail&aid=1122940&group_id=130646&atid=719009 > > My main concern is that the general approach is about right. Does it > make sense? One thing I notice is that there's no facility to check > the presence of a switch that doesn't take an arg, a boolean switch. > That is a simple Ns_ObjvProc plugin. > > I have a couple of other patches which use the facility so I'd like to > make some headway with it. > Yup. Been very busy in last few days. Did however looked at it very briefly. Yes, there's no facility to check a switch-type arg. This is what I immediately saw. Apart from that I didn't give it a try (which is what I'd like to, as soon as this support issues are off my back :( ) Cheers Zoran |
|
From: Zoran V. <zv...@ar...> - 2005-02-26 17:19:57
|
On Tuesday 22 February 2005 00:27, Stephen Deasey wrote: > Has anyone had a chance to look at the Ns_ParseObjv() patch I posted? > > http://sourceforge.net/tracker/index.php?func=detail&aid=1122940&group_id=130646&atid=719009 > > My main concern is that the general approach is about right. Does it > make sense? One thing I notice is that there's no facility to check > the presence of a switch that doesn't take an arg, a boolean switch. It makes sense. I have checked this in and took the liberty to reformat it a little to maintain the 80-char margin, fix tabs to spaces and a touch in function comment headers here/there. I hope you don't mind... I'm just an old nitpicker! > That is a simple Ns_ObjvProc plugin. Yup. This we should add as well. Oh, yes... I changed Ns_ObjvString to optionally return the length of the parsed string in *arg. This should not break anything, as I see it, or? int Ns_ObjvString(void *dest, Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[], void *arg) { if (objc > 0) { if (arg == NULL) { *((char **) dest) = Tcl_GetString(objv[0]); } else { *((char **) dest) = Tcl_GetStringFromObj(objv[0], (int*)arg); } return --objc; } return -1; } Cheers Zoran |
|
From: Stephen D. <sd...@gm...> - 2005-02-28 07:25:28
|
I was thinking about making the Ns_ObjvBool proc look at it's arg, and if present, place that in the destination pointer and not consume an object from the objv array. The presence of the option (without argument) alone would signify true, it's absence false. Then I realised I left out the short-circuit logic... When a -- (break) arg is found the options are assumed to have ended and we jump to arg processing. The signal for this is that the Ns_ObjvBreak proc returns exactly objc. But that's really what the Bool proc should return in the case described above when it doesn't consume an arg. Unfortunately it's not as simple as that. The "wrong num args" description needs to know that the option takes no argument too. Any thoughts? |
|
From: Zoran V. <zv...@ar...> - 2005-02-28 09:09:51
|
On Monday 28 February 2005 08:25, Stephen Deasey wrote:
> I was thinking about making the Ns_ObjvBool proc look at it's arg, and
> if present, place that in the destination pointer and not consume an
> object from the objv array. The presence of the option (without
> argument) alone would signify true, it's absence false.
>
> Then I realised I left out the short-circuit logic... When a --
> (break) arg is found the options are assumed to have ended and we jump
> to arg processing. The signal for this is that the Ns_ObjvBreak proc
> returns exactly objc. But that's really what the Bool proc should
> return in the case described above when it doesn't consume an arg.
>
> Unfortunately it's not as simple as that. The "wrong num args"
> description needs to know that the option takes no argument too.
>
>
> Any thoughts?
And if Ns_ObjvBreak returns zero as a signal that none
of the options are expected any more:
remain = specPtr->proc(specPtr->dest, interp, objc, objv + objvIndex,
specPtr->arg);
if (remain == 0 || remain == objc) {
remain = objc;
break;
}
Hm?
Zoran
|
|
From: Stephen D. <sd...@gm...> - 2005-03-04 09:26:51
|
On Mon, 28 Feb 2005 10:05:38 +0100, Zoran Vasiljevic <zv...@ar...> wrote:
>
> And if Ns_ObjvBreak returns zero as a signal that none
> of the options are expected any more:
>
> remain = specPtr->proc(specPtr->dest, interp, objc, objv + objvIndex,
> specPtr->arg);
> if (remain == 0 || remain == objc) {
> remain = objc;
> break;
> }
>
> Hm?
Oh yeah, the zero is free. That should do it.
|
|
From: Stephen D. <sd...@gm...> - 2005-03-18 11:36:21
|
> Oh yes, Stephen, I love the arg parsing code This is really
> a relief. After years any years of parsing... heh..
Well, it would be great if it actually worked... :-/
I don't think the return value of the parse-proc can be overloaded to
mean both the number of args left and 'break' (by saying zero args
left).
The way it is now, a command like [ns_foo -blah whatsit] will return 0
args left from the proc which handles the -foo switch because there
really are no args left. But this is used as a signal to end option
parsing so objc does't get updated to reflect that fact that 'whatsit'
was consumed. The result is that 'whatsit' gets treated as an arg
even though it was already handled.
I think the signature of the parse procs will have to be changed to
return TCL_OK, TCL_ERROR, TCL_BREAK, and pass a pointer to objc which
they will be expected to update. What do you think?
On Mon, 28 Feb 2005 10:05:38 +0100, Zoran Vasiljevic <zv...@ar...> wrote:
> On Monday 28 February 2005 08:25, Stephen Deasey wrote:
> > I was thinking about making the Ns_ObjvBool proc look at it's arg, and
> > if present, place that in the destination pointer and not consume an
> > object from the objv array. The presence of the option (without
> > argument) alone would signify true, it's absence false.
> >
> > Then I realised I left out the short-circuit logic... When a --
> > (break) arg is found the options are assumed to have ended and we jump
> > to arg processing. The signal for this is that the Ns_ObjvBreak proc
> > returns exactly objc. But that's really what the Bool proc should
> > return in the case described above when it doesn't consume an arg.
> >
> > Unfortunately it's not as simple as that. The "wrong num args"
> > description needs to know that the option takes no argument too.
> >
> >
> > Any thoughts?
>
> And if Ns_ObjvBreak returns zero as a signal that none
> of the options are expected any more:
>
> remain = specPtr->proc(specPtr->dest, interp, objc, objv + objvIndex,
> specPtr->arg);
> if (remain == 0 || remain == objc) {
> remain = objc;
> break;
> }
>
> Hm?
> Zoran
|
|
From: Zoran V. <zv...@ar...> - 2005-03-18 14:52:14
|
On Friday 18 March 2005 12:36, Stephen Deasey wrote: > I think the signature of the parse procs will have to be changed to > return TCL_OK, TCL_ERROR, TCL_BREAK, and pass a pointer to objc which > they will be expected to update. =A0What do you think? So, TCL_OK would mean all parsing is done, TCL_ERROR parsing failed and TCL_BREAK end of optional arguments? And each parsing proc will receice ptr to objc which it has to update to reflect what it consumed? Do I see this right? Cheers Zoran |
|
From: Zoran V. <zv...@ar...> - 2005-03-19 14:24:58
|
On Saturday 19 March 2005 15:02, Stephen Deasey wrote:
> ns_parseargs spec args
>
> e.g.
>
> proc foo args {
> ns_parseargs {-opt1 -opt2 -- arg1 {arg2 def} args} $args
> # do stuf with $opt1, $arg1 . . .
> }
>
> ns_parseargs would set variables in the callers environment, or throw
> an error if $args didn't matchs the spec.
>
> It's not very Tcl'ish, but some limited type checking is also
> possible. Perhaps -opt:int to specify an integer flag?
>
> I would create a new Tcl obj type to represent the 'spec'. The first
> time ns_parseargs is called, $spec would be compiled into a set of
> Ns_ObjcSpec options. Subsequent calls should be as fast as the C
> code.
I think this is a great idea. I know it's not tcl'ish but the
-opt:(int|wint|bool) would help a lot. Omitting it would default
to string, I assume. Not that this is strictly needed in a typeless
language, but it will often save me
if {[string is integer]} {
# dio things
}
types of constructs. What about:
% string is dummy dummy
bad class "dummy": must be alnum, alpha, ascii, control, boolean, digit, double, false, graph, integer, lower, print, punct, space, true, upper, wordchar, or xdigit
Would it make sense to also do like:
-opt:digit
-opt:print
etc ?
|
|
From: Zoran V. <zv...@ar...> - 2005-03-19 14:57:49
|
On Saturday 19 March 2005 15:45, Stephen Deasey wrote: > Do these 'is' functions have a C API? I think they're Tcl only, right? yeah... I think we should stick to built-in object types really. > Could get crazy... :-) And in order not to get crazy: KISS (keep it simple and stupid) Anyways, first things first: TCL_BREAK and &objc, right? Zoran BTW: do cc: on the naviserver-devel list so others can see what we're cooking. |
|
From: Stephen D. <sd...@gm...> - 2005-03-26 17:59:08
|
On Sat, 19 Mar 2005 15:52:47 +0100, Zoran Vasiljevic <zv...@ar...> wrote:
> On Saturday 19 March 2005 15:45, Stephen Deasey wrote:
>
> > Do these 'is' functions have a C API? I think they're Tcl only, right?
>
> yeah... I think we should stick to built-in object types really.
>
> > Could get crazy... :-)
>
> And in order not to get crazy: KISS (keep it simple and stupid)
> Anyways, first things first: TCL_BREAK and &objc, right?
>
> Zoran
>
> BTW: do cc: on the naviserver-devel list so others can
> see what we're cooking.
Woops, silly Gmail... :-)
I've added basic option parsing without any fancy stuff. It was the
easiest thing to implement and it leaves all our options (ha ha) open
for the future.
proc aproc {args} {
ns_parseargs {-foo {-bar BAR} -- required {default DEF} args} $args
# ...
}
There are some more examples in tests/ns_parseargs.test
I do think the type checking attributes are a good idea, but I'm not
going to have time to look at that any time soon. If any one else
would like to, that would be great.
Oh yeah, I think I finally got the parsing right :-) Ns_ObjvProc's
now return either TCL_OK, TCL_ERROR or TCL_BREAK. It's actually
shorter code. I hope everything looks ok now.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X