naviserver-devel — Developer discussion

Re: [naviserver-devel] Re: RFE #1202462

[Zoran V. <zv...@ar...>]

Am 30.05.2005 um 12:01 schrieb Stephen Deasey:

>
> What's the return value of Ns_FSOpen?
>

Something that can be fed to Ns_FSRead and/or Ns_FSClose
for example. I haven't started the implementation yet
but this is first what comes to mind.

Presumably, it will be Tcl_Channel in VFS or a regular
OS filehandle w/o VFS.

Is there any specific (hidden) reason why you took
this particular exmaple?
If you think about mmap, this should be wrapped entirely
so you'd give a file to mmap and optionally the address
to map it to. All the rest will be done by the implementation.

Zoran

Re: [Re: Re: [naviserver-devel] ns_parseargs example]

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 28.05.2005 um 21:01 schrieb vl...@cr...:
>=20
> > I like this but can it be list instead of oneof
> >
> > ns_proc connect {{-eightbit flag} {{-speed list {1200 2400 4800}}
> > 4800} {port /dev/ttya}}
> >
>=20
> Of course it can. But Stephen is not very optimistic
> about the syntax altogether...


Well, the above example is wrong.  It should be:

    ns_proc connect {{{-eightbit flag}} {{-speed list ...

Nested lists are clearly unusable.


> I'm afraid we do not have very much options about all that.
> Either we drop the type checking and therefore accept no
> flag-type arguments or similar, or we do something like above
> and be faced with more complex writing.


The other option is -eightbit:flag syntax.  It's not perfect, but it's
better than nested lists and has ~5 years of usage in the ACS behind
it.

Re: [naviserver-devel] Re: RFE #1202462

[Stephen D. <sd...@gm...>]

On 5/30/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 30.05.2005 um 01:59 schrieb vl...@cr...:
>=20
> > Perfect
> >
>=20
> Even more "perfect":
>=20
>    instead of compile-time, you could select vfs operation
>    as a ns/server config option.
>=20
> I'd have to write Ns_FSStat, Ns_FSOpen, Ns_FSDirents
> etc wrappers *anyway*. So instead of ifdefing pieces of
> code in there, I can make the judgement on the basis of
> checking the config setup which is one quick operation.
> This is more friendly and would allow people to easily
> experiment with the performance and pros/cons added with
> the vfs interface w/o the hassle of recompiling all.


What's the return value of Ns_FSOpen?

[naviserver-devel] Re: RFE #1202462

[Zoran V. <zv...@ar...>]

Am 30.05.2005 um 01:59 schrieb vl...@cr...:

> Perfect
>

Even more "perfect":

   instead of compile-time, you could select vfs operation
   as a ns/server config option.

I'd have to write Ns_FSStat, Ns_FSOpen, Ns_FSDirents
etc wrappers *anyway*. So instead of ifdefing pieces of
code in there, I can make the judgement on the basis of
checking the config setup which is one quick operation.
This is more friendly and would allow people to easily
experiment with the performance and pros/cons added with
the vfs interface w/o the hassle of recompiling all.

I think this is the proper way to go:

ns_section ns/server
ns_param   usetclvfs (false|true)

I'd put this process-wide instead of virtual-server-wide
because I do not know if I have access to the current
virtual server from all places where those calls are made.

Zoran

[Re: Re: [Re: [naviserver-devel] RFE #1202462]]

[<vl...@cr...>]

Perfect

-------- Original Message --------
To: nav...@li...
From: Zoran Vasiljevic <zv...@ar...>
Subject: Re: [Re: [naviserver-devel] RFE #1202462]


Am 29.05.2005 um 15:24 schrieb vl...@cr...:

> If that will be configurable, let's say with --with-vfs during  
> configure or somehow to have the ability using low-level or Tcl  
> interfaces, i have no problems with it. The cases when direct calls  
> would be necessary for high performance sites, but in cases when  
> performance is acceptable Tcl Vfs can be used.

OK. This is fine with me.

I will fix the mmap usage so it can be used from windows as well.
In the same time, I'll define Ns_XXX wrappers for doing file stuff
and those will be ifdef'ed USE_TCL_VFS. The USE_TCL_VFS will be
undefined by default.

Is this OK so?

Zoran


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [Re: [naviserver-devel] RFE #1202462]

[Zoran V. <zv...@ar...>]

Am 29.05.2005 um 15:24 schrieb vl...@cr...:

> If that will be configurable, let's say with --with-vfs during  
> configure or somehow to have the ability using low-level or Tcl  
> interfaces, i have no problems with it. The cases when direct calls  
> would be necessary for high performance sites, but in cases when  
> performance is acceptable Tcl Vfs can be used.

OK. This is fine with me.

I will fix the mmap usage so it can be used from windows as well.
In the same time, I'll define Ns_XXX wrappers for doing file stuff
and those will be ifdef'ed USE_TCL_VFS. The USE_TCL_VFS will be
undefined by default.

Is this OK so?

Zoran

[Re: [naviserver-devel] RFE #1202462]

[<vl...@cr...>]

If that will be configurable, let's say with --with-vfs during configure or
somehow to have the ability using low-level or Tcl interfaces, i have no
problems with it. The cases when direct calls would be necessary for high
performance sites, but in cases when performance is acceptable Tcl Vfs can be used.

-------- Original Message --------
To: Navidevel <nav...@li...>
From: Zoran Vasiljevic <zv...@ar...>
Subject: [naviserver-devel] RFE #1202462

Hi friends,

I would like to get some movement for this RFE since it
is somehow important for us.

The basics is: we'd be able to abstract (almost) all
file-related operation to use the Tcl API and herewith
get all the benefits of the Tcl VFS infrastructure.
So, we can serve pages from ZIP files, for example,
build self-contained distributions (single file containing
all of the server distribition plus user application) etc.

Stephen has expressed his doubts about ability to support
the mmap()'ed pages and this is true. Using the Tcl VFS
API, mmaped files are not supported. But, this is no big
deal, IMO. Since the mmap functionality is per default disabled
in standard setup I do not consider this a showstopper for
the Tcl VFS. If somebody would like to use mmaped pages,
he can do this anytime by properly configuring the server.
I would leave this untouched. Actually, I will also touch
this part in order to make mmaped pages available for Windows
platform as well (which is not the case now).

Needed changes would be to replace all open/close/stat/fstat
and alike with their Tcl API counterparts all over the place.
Also, some platform-specific wrappers need to be written in
order to add Windows support for mmaped files.
I would like to do this on the short term (say in couple of
weeks).

I'd like to get some (more) pros/cons of that and discuss them
with you.

Zoran


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] RFE #1202462

[Zoran V. <zv...@ar...>]

Hi friends,

I would like to get some movement for this RFE since it
is somehow important for us.

The basics is: we'd be able to abstract (almost) all
file-related operation to use the Tcl API and herewith
get all the benefits of the Tcl VFS infrastructure.
So, we can serve pages from ZIP files, for example,
build self-contained distributions (single file containing
all of the server distribition plus user application) etc.

Stephen has expressed his doubts about ability to support
the mmap()'ed pages and this is true. Using the Tcl VFS
API, mmaped files are not supported. But, this is no big
deal, IMO. Since the mmap functionality is per default disabled
in standard setup I do not consider this a showstopper for
the Tcl VFS. If somebody would like to use mmaped pages,
he can do this anytime by properly configuring the server.
I would leave this untouched. Actually, I will also touch
this part in order to make mmaped pages available for Windows
platform as well (which is not the case now).

Needed changes would be to replace all open/close/stat/fstat
and alike with their Tcl API counterparts all over the place.
Also, some platform-specific wrappers need to be written in
order to add Windows support for mmaped files.
I would like to do this on the short term (say in couple of
weeks).

I'd like to get some (more) pros/cons of that and discuss them
with you.

Zoran

Re: [Re: Re: [naviserver-devel] ns_parseargs example]

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 21:01 schrieb vl...@cr...:

> I like this but can it be list instead of oneof
>
> ns_proc connect {{-eightbit flag} {{-speed list {1200 2400 4800}}  
> 4800} {port /dev/ttya}}
>

Of course it can. But Stephen is not very optimistic
about the syntax altogether...

I'm afraid we do not have very much options about all that.
Either we drop the type checking and therefore accept no
flag-type arguments or similar, or we do something like above
and be faced with more complex writing.

Zoran 

[Re: Re: [naviserver-devel] ns_parseargs example]

[<vl...@cr...>]

I like this but can it be list instead of oneof<br />
<br />
ns_proc connect {{-eightbit flag} {{-speed list {1200 2400 4800}}  
4800} {port /dev/ttya}}<br />
<br />
<br />
-------- Original Message --------
To: nav...@li...
From: Zoran Vasiljevic 
Subject: Re: [naviserver-devel] ns_parseargs example


Am 27.05.2005 um 18:44 schrieb Stephen Deasey:

&gt; Right, but the option list is type checking.  One of the syntaxes we
&gt; talked about was:
&gt;
&gt;     ns_parseargs {-a:int -b:bool -s:switch} $args
&gt;

Which seems really as the only meaningful, simple and easy
way to do this, I must admit, after thinking awhile.

So:

      ns_parseargs {{-varname?:type? ?default?} ...}

where -varname is going to set the variable &quot;varname&quot; and
it will first check, according to the ?:type? what it gets.
The best is to make some examples:

    -option

    would expect an argument and set &quot;option&quot; to argument value
    and if the -option is not given, will do nothing

    -option default

    if option is given, it will take it, otherwise will set the
    default value

    -option:flag

    if the option is given it will set it to the boolean true,
    otherwise to boolean false

    -option:oneof {a b c}

    if the option is given it will check the argument for being
    one of the a, b or c and set the variable accordingly.

Alternatively, one could use lists instead of &quot;:&quot; like this:

    {-option flag}
    {-option oneof {a b c}}

This is more Tcl-like and allows you freedom in the variable name.
Example:

   ns_proc connect {{-eightbit flag} {{-speed oneof {1200 2400 4800}}  
4800} {port /dev/ttya}} {
     # ...
   }

So I can say:

    connect
      and it will use 7bit comm, will take speed 4800 to connect to / 
dev/ttya

    connect /dev/ttyb
      as above but will connect to /dev/ttyb

    connect -speed 2400 /dev/ttyb
      as above but will use 2400bps instead of 4800bps

    connect -speed 9600 /dev/ttyc
      will throw error

    connect -eightbit /dev/ttyc
      will use 8bit comm to connect to /dev/ttyc

Apart from &quot;flag&quot; and &quot;oneof&quot; we can later introduce &quot;int&quot;, &quot;bool&quot;,  
&quot;wide&quot; etc
in order to additionaly check the given value:

     {{-number_of_retries int} 4}

Will expect number_of_retries to be an interger and if not given will  
set it to 4.

What do you think?
Zoran&#160;

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 16:26 schrieb Zoran Vasiljevic:

>
> So what's from above: cut toes, drill holes, buy shoes or dismount ??
>

I will answer this myself: cut toes!

Lets KISS (Keep It Simple and Stupid).

There are no boolean flags.
There are no choice lists.
There is no other type of checking.
We only check "-" prefixed arguments to be optionally set (or not)
We allow defaults for opional args.

Pros:

o. all is already in place (we do not need to write anything more)
o. we are keeping Tcl philosophy of typeless arguments
o. it is easy to write/code

Cons:
o. all checking (except for parsing-out optional args)
    must be done by the programmer him/herself

I knew that this damn checking will lead us to complications.
Therefore: forget it.
What do you think? Ouch again?

Zoran

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 15:50 schrieb Stephen Deasey:

>>
>> Here is how:
>>
>>      ns_parseargs {=10=10{{-eightbit flag}} {-foo flag} args}
>>
>
>
> Ouch!

:-)

>>> It will confuse people who read the code, don't you think?
>>>
>>
>> I do but I do not care.
>>
>
>
> I think you're optimising for the wrong thing... :-(

Well... trying to keep the {option value} format
and introducing more options...

One can also use the

    -option:type

but this will save you just one list level if you want
to be Tcl-proc compatible.

OTOH, if you *do not* expect the 100% compatilibity with
the Tcl proc, then other possiblities open, of course.
So:
     ns_proc {
              -retries  {default 4 type int}
              -eightbit {type flag}
              -speed    {default 2400 type {oneof {1200 2400 4800}}}
              devpath   {default /dev/ttya}
             } {
        #....
    }

Ouch?

The thing is: we'd like to force a large foot into a small shoe!
This will not go without cutting the toes or drilling the hole
in the shoe :-)
When I look this from another perspective: the best way would
be to go and buy larger shoes!
Or, to quote some american indian: when you discover you're
riding a dead horse the best strategy is to dismount.

So what's from above: cut toes, drill holes, buy shoes or dismount ??

Zoran

>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-=20=

> q22005
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
> Am 28.05.2005 um 14:19 schrieb Stephen Deasey:
> >
> > ns_parseargs {{-eightbit flag} {-foo flag} args}
> >
> > How do you distinguish between -eightbit which is a boolean flag, and
> > -foo which is an option with a default string value of 'flag'?
>=20
> Here is how:
>=20
>      ns_parseargs {=10=10{{-eightbit flag}} {-foo flag} args}


Ouch!


> This is just a nested-list exercise. It is Tcl-natural and can become
> difficult to write with all those curly braces, but that's the price
> of the flexibility.

...

> > It will confuse people who read the code, don't you think?
>
> I do but I do not care.


I think you're optimising for the wrong thing... :-(

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 14:19 schrieb Stephen Deasey:

>
>
> ns_parseargs {{-eightbit flag} {-foo flag} args}
>
> How do you distinguish between -eightbit which is a boolean flag, and
> -foo which is an option with a default string value of 'flag'?

Here is how:

     ns_parseargs {=10=10{{-eightbit flag}} {-foo flag} args}

The first argument of the above spec is:

      {{-eightbit flag}}

which is a one-element list.

Generally you'd have:

     {{spec} {spec} {spec} args}

where "spec" is:

     {option value}

where option is:

     {-variable type ?type_specific_part?}

The "type_specific_part" whould be a choice-list for "oneof" type, =20
for example.
This is just a nested-list exercise. It is Tcl-natural and can become
difficult to write with all those curly braces, but that's the price
of the flexibility.

>
> I don't know that it makes much sense to supply a default for boolean
> flags.  In that case you probably want to invert the sense of the flag
> name: -nofoo.

There is no sense in supplying defaults for boolean flags, but the
syntax would/must allow it (i.e. special case).

Zoran

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 14:10 schrieb Stephen Deasey:

>> Hm.. so you are after
>>
>>     arg {arg val} args
>>
>> type of compatibility as in Tcl proc? I did not think about that
>> because we are using our own parser. What is the benefit/reason
>> to maintain this kind of compatibility when we already preprocess
>> args ourselves?
>>
>
>
> It will confuse people who read the code, don't you think?

I do but I do not care. It is the new functionality and
it has to be learned. Furthermore it is compatible to
usual Tcl syntax and is "natural" in the way it uses nested
lists. Admitently, it can grow complex, but the task ain't
simple anyway.


>
> Some Unix utilities use + to signify flipping an option when ther are
> many, so you could end up with something like this:
>
>     ns_parseargs {+bool -opt {-opt def} arg {arg def} args}
>
> This disadvantage of this is that you could not emulate some of the
> standard Tcl commands...
>
> I guess you could use all sorts of symbols:
>
>     ns_parseargs {+bool -opt {=choice x {x y z}}}
>
> Hmm, is it a problem that you have to supply a default if you want to
> enforce choosing oneof many?  If the choices are contrained to x, y
> and z but you also want to allow 'neither', couldn't you extend the
> choices to 0, x, y, z, with 0 being the default?

I also thought about using the first char as the type-selector
but it becomes weird if you are about to introduce other type-checking
like "int", "wide", "ascii", "print" (more generally, [string is...]
type of checks). Pretty soon you're out of signs and it is not very
illustrative/readable:

    +bool -opt =choice ?string &int

Hm... I do not think this will be very user-friendly...
Although the "user-friendliness" is not my first objective, it HAS
to be somehow "readable".

Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 28.05.2005 um 13:36 schrieb Stephen Deasey:
>=20
> >
> > I think it looks like 'flag' is the literal default value for the
> > -eightbit option.  I do like the idea of lists, it is more Tcl-like.
> > But Tcl already has a syntax for procs, and this clashes with it.
> >
>=20
> Oh it does not!
>=20
>     {{-eightbit flag}}
>=20
> This is the correct syntax. If you wanted to have a default
> it would be something like
>=20
>     {{-eightbit flag} 1}


ns_parseargs {{-eightbit flag} {-foo flag} args}

How do you distinguish between -eightbit which is a boolean flag, and
-foo which is an option with a default string value of 'flag'?

I don't know that it makes much sense to supply a default for boolean
flags.  In that case you probably want to invert the sense of the flag
name: -nofoo.

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 28.05.2005 um 13:36 schrieb Stephen Deasey:
>=20
> > To be compatible, the type specifier would have to be the third arg,
> > but then you couldn't specify the type without also specifying a
> > default.  I don't see a clean way to do it...
>=20
>=20
> Hm.. so you are after
>=20
>     arg {arg val} args
>=20
> type of compatibility as in Tcl proc? I did not think about that
> because we are using our own parser. What is the benefit/reason
> to maintain this kind of compatibility when we already preprocess
> args ourselves?


It will confuse people who read the code, don't you think?

Some Unix utilities use + to signify flipping an option when ther are
many, so you could end up with something like this:

    ns_parseargs {+bool -opt {-opt def} arg {arg def} args}

This disadvantage of this is that you could not emulate some of the
standard Tcl commands...

I guess you could use all sorts of symbols:

    ns_parseargs {+bool -opt {=3Dchoice x {x y z}}}

Hmm, is it a problem that you have to supply a default if you want to
enforce choosing oneof many?  If the choices are contrained to x, y
and z but you also want to allow 'neither', couldn't you extend the
choices to 0, x, y, z, with 0 being the default?

Just throwing out ideas...

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 13:36 schrieb Stephen Deasey:

>
> I think it looks like 'flag' is the literal default value for the
> -eightbit option.  I do like the idea of lists, it is more Tcl-like.
> But Tcl already has a syntax for procs, and this clashes with it.
>

Oh it does not!

    {{-eightbit flag}}

This is the correct syntax. If you wanted to have a default
it would be something like

    {{-eightbit flag} 1}

Generally, I do maintain the

    {option default}

form, just the "option" is now a list in itself, like:

    {{-flag oneof {a b c}} b}

The option is: {-flag oneof {a b c}}
Default value is: b

Clear?
Zoran

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 13:36 schrieb Stephen Deasey:

> To be compatible, the type specifier would have to be the third arg,
> but then you couldn't specify the type without also specifying a
> default.  I don't see a clean way to do it...


Hm.. so you are after

    arg {arg val} args

type of compatibility as in Tcl proc? I did not think about that
because we are using our own parser. What is the benefit/reason
to maintain this kind of compatibility when we already preprocess
args ourselves?

Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> ...
>
> Alternatively, one could use lists instead of ":" like this:
>=20
>     {-option flag}
>     {-option oneof {a b c}}
>=20
> This is more Tcl-like and allows you freedom in the variable name.
> Example:
>=20
>    ns_proc connect {{-eightbit flag} {{-speed oneof {1200 2400 4800}}
> 4800} {port /dev/ttya}} {
>      # ...
>    }
>=20
> ...
>
> What do you think?


I think it looks like 'flag' is the literal default value for the
-eightbit option.  I do like the idea of lists, it is more Tcl-like.=20
But Tcl already has a syntax for procs, and this clashes with it.

To be compatible, the type specifier would have to be the third arg,
but then you couldn't specify the type without also specifying a
default.  I don't see a clean way to do it...

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 27.05.2005 um 18:44 schrieb Stephen Deasey:

> Right, but the option list is type checking.  One of the syntaxes we
> talked about was:
>
>     ns_parseargs {-a:int -b:bool -s:switch} $args
>

Which seems really as the only meaningful, simple and easy
way to do this, I must admit, after thinking awhile.

So:

      ns_parseargs {{-varname?:type? ?default?} ...}

where -varname is going to set the variable "varname" and
it will first check, according to the ?:type? what it gets.
The best is to make some examples:

    -option

    would expect an argument and set "option" to argument value
    and if the -option is not given, will do nothing

    -option default

    if option is given, it will take it, otherwise will set the
    default value

    -option:flag

    if the option is given it will set it to the boolean true,
    otherwise to boolean false

    -option:oneof {a b c}

    if the option is given it will check the argument for being
    one of the a, b or c and set the variable accordingly.

Alternatively, one could use lists instead of ":" like this:

    {-option flag}
    {-option oneof {a b c}}

This is more Tcl-like and allows you freedom in the variable name.
Example:

   ns_proc connect {{-eightbit flag} {{-speed oneof {1200 2400 4800}}  
4800} {port /dev/ttya}} {
     # ...
   }

So I can say:

    connect
      and it will use 7bit comm, will take speed 4800 to connect to / 
dev/ttya

    connect /dev/ttyb
      as above but will connect to /dev/ttyb

    connect -speed 2400 /dev/ttyb
      as above but will use 2400bps instead of 4800bps

    connect -speed 9600 /dev/ttyc
      will throw error

    connect -eightbit /dev/ttyc
      will use 8bit comm to connect to /dev/ttyc

Apart from "flag" and "oneof" we can later introduce "int", "bool",  
"wide" etc
in order to additionaly check the given value:

     {{-number_of_retries int} 4}

Will expect number_of_retries to be an interger and if not given will  
set it to 4.

What do you think?
Zoran

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 05:05 schrieb Stephen Deasey:

>
> Well, OK.  I guess you can change your mind...  :-)
>

Ehm... (blush) I frequently change my mind :-)
The thing is: I'd like to keep the spec as simple
as possible, otherwise you end up in tons of options
and very few people understand them and use them.

So, I'm back to work now and I have a whole day to
think about the options... Lets see what will pop
out of that ;-)

Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/27/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Oh NO! Excatly that I did not wanted to do. I would not check argument
> types on being integer or similar... This should really be left to the
> programmer.


Well, OK.  I guess you can change your mind...  :-)

http://sourceforge.net/mailarchive/forum.php?thread_id=3D6839358&forum_id=
=3D43966

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 27.05.2005 um 18:44 schrieb Stephen Deasey:

>     ns_parseargs {-a:int -b:bool -s:switch} $args
>
> So the boolean switch could use the type syntax.  I'm not desperate
> for [string is ...] checks so leaving that out will certainly make
> life easier, but we still have to think about the syntax for
> specifying types as seems we need it anyway...
>

Hmmm.... not very excited about the syntax, but have not any
other idea yet... will have to think about it.

>
>
> You mean checking for integers etc.?  The C API does do this (has to,
> it's C!), but the Tcl wrapper doesn't use it.  It was easier to define
> a new Ns_ObjvSpec proc to handle all Tcl args than to massage the arg
> spec into what the C API expects.  I don't know whether it makes sense
> to try and use the underlying C stuff or not.

Oh NO! Excatly that I did not wanted to do. I would not check argument
types on being integer or similar... This should really be left to the
programmer.

>
> Sure.  How would you specify an option list?  And would there be the
> two types that the C API supports, the choose 1 and the choose 1 or
> more?  For the choose 1 or more the result should probably be an array
> (where the C implementation logically OR's bits).

Do not know. I will invest some time in thinking about that tomorrow
morning...

Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/27/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 27.05.2005 um 11:34 schrieb Stephen Deasey:
>=20
> > Where we left the discussion last time is how to deal with type
> > checking.  Boolean switches and range values are basically just forms
> > of type checking.
>=20
> Hmm.... what I understood here was data-type checking as in
> integer/string type of thing.
>=20
> Under boolean support, I actually ment *absence* or *existence*
> of the option. I do not know how I could achieve this now, unless
> I say:
>=20
>     ns_parseargs {{-boolean 0} args}
>=20
> but this is also half-baked.


Right, but the option list is type checking.  One of the syntaxes we
talked about was:

    ns_parseargs {-a:int -b:bool -s:switch} $args

So the boolean switch could use the type syntax.  I'm not desperate
for [string is ...] checks so leaving that out will certainly make
life easier, but we still have to think about the syntax for
specifying types as seems we need it anyway...


> OK, lets think about type-checking. I would definitely say that
> boolean type-checking (as described above) should be in.
> The same for option-lists. Those two are most commonly found
> and needed. Other type of checking would not be needed.
> So, if I say:
>=20
>      ns_parseargs {-a args}
>=20
> then anything what is given to "-a" should be accepted as is.
> Something like "string is ..." checking should be left to the
> programmer.
>=20
> I believe that underlying C-api already does the above, or?


You mean checking for integers etc.?  The C API does do this (has to,
it's C!), but the Tcl wrapper doesn't use it.  It was easier to define
a new Ns_ObjvSpec proc to handle all Tcl args than to massage the arg
spec into what the C API expects.  I don't know whether it makes sense
to try and use the underlying C stuff or not.

=20
> >
> > Depending on how type checking is implemented, then the syntax of an
> > arg specification may change.  You may or may not end up pulling your
> > hair out later if you change all your code to use ns_proc now...  :-)
> >
>=20
>=20
> Right. Lets fix this now. We can talk about the syntax when/if we
> agree on the scope of the implemented type-checking (as above).
> Deal?


Sure.  How would you specify an option list?  And would there be the
two types that the C API supports, the choose 1 and the choose 1 or
more?  For the choose 1 or more the result should probably be an array
(where the C implementation logically OR's bits).

So, with an option of -thingy where you can choose 1 or more of foo,
bar or baz, specifying -thingy {foo bar} would result in foo(bar) and
foo(baz) being set.


Maybe it would look something like this:

    ns_parseargs {{-thingy:either {foo bar baz}}} $args
    ns_parseargs {{-thingy:either {foo bar baz} foo} $args  ;# foo is defau=
lt

    ns_parseargs {{-thingy:any {foo bar baz}}} $args
    ns_parseargs {{-thingy:any {foo bar baz} {foo bar}} $args

i.e. either and any would have to be at least a two element list, the
optional third element being the default value.