[AOLSERVER] ns_set questions
While adding documentation to the Wiki for ns_set (see http://panoptic.com/wiki/aolserver/ns_set) I noticed that ns_set has ns_set idelete and ns_set purge subcommands, both of which are noops. ns_set idelete doesn't really make sense since ns_set delete takes a field number and so case is irrelevant. I'm not sure what ns_set purge did / was supposed to do. Should these subcommands be removed? Also, I think it would be useful to add some new subcommands, ns_set keys $setId and ns_set values $setId. These would return a list of the keys or values in the ns_set respectively. While you can get these lists from looping with ns_set key / value / array, it is convenient to have them as primitives. Adding them could conceivably break existing code if you are relying on an abbreviation of key and value that would now become ambiguous, but I suspect that is not common. What do people think? I'd be happy to submit a patch for the changes. Are there any other ns_set modifications you've been wanting? Thanks, Jamie -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_set questions
On Fri, Jun 11, 2004 at 02:31:18AM -0400, Jamie Rasmussen wrote: > While adding documentation to the Wiki for ns_set (see > http://panoptic.com/wiki/aolserver/ns_set) I noticed that ns_set has ns_set > Also, I think it would be useful to add some new subcommands, ns_set keys > $setId and ns_set values $setId. These would return a list of the keys or > values in the ns_set respectively. While you can get these lists from > looping with ns_set key / value / array, it is convenient to have them as Sounds like a good idea to me. Having to manually iterate over the ns_set to find all matching keys always did seem awfully strange to me. > What do people think? I'd be happy to submit a patch for the changes. Are > there any other ns_set modifications you've been wanting? About two years ago, I thought I wanted some, so I patched the stuff I wanted into my local AOLserver code. Ah, it was the "findall" and "findmatch" stuff: http://sourceforge.net/tracker/?func=detail&aid=530808&group_id=3152&atid=303152 But then I learned what horrible performance ns_set has for large quantities of data [I just added a note to the Wiki about that now], which was exactly the situation I was using findall and findmatch with. So I switched to Tcl Arrays, my need for a richer ns_set API evaporated then and there, and I never did post my cleaned up patch. (I still have it in my CVS though.) -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_set questions
Sets allow entries with duplicate keys. If duplicates are returned in
the list for this new ns_set keys, that's fine, except that a naiive
programmer can't go through the list of keys returned and fetch the
corresponding values. You'd have to do a foreach loop on the keys,
increment a counter, and use the counter to lindex into the ns_set values
result:
set values [ns_set values $myset]
set i -1
foreach key [ns_set keys $myset] {
incr i ;# put it here so that continues can be used to exit early
set val [lindex $values $i]
do whatever
}
It seems to me that this is worse than the current way of using a set
index with ns_set key and ns_set value:
set size [ns_set size $myset]
for {set i 0} {$i < $size} {incr i} {
set key [ns_set key $myset $i]
set val [ns_set value $myset $i]
do whatever
}
IMO, a better approach (or another one at least) would be to return a
list of key value pairs with something like "ns_set list", ie:
{{key1 val1} {key2 val2} ...}
Then a loop like this can be used:
foreach setel [ns_set list $myset] {
set key [lindex $setel 0]
set val [lindex $setel 1]
do whatever
}
Another option would be "ns_set aget" to return alternating keys and
values in a list that could be used as input to "array set" - sort of,
ignoring the multiple key issue - to convert sets to arrays, and
"ns_set aset" could be used to convert from arrays to sets, like:
set myset [ns_set create]
ns_set aset $myset [array get myarray]
I don't know how often these would be used in practice though, because
I think experienced TCL programmers quickly avoid using ns_sets except
where they have to, like for interfacing with smallish nsd data
structures.
Jim
>
> On Fri, Jun 11, 2004 at 02:31:18AM -0400, Jamie Rasmussen wrote:
> > While adding documentation to the Wiki for ns_set (see
> > http://panoptic.com/wiki/aolserver/ns_set) I noticed that ns_set has ns_set
>
> > Also, I think it would be useful to add some new subcommands, ns_set keys
> > $setId and ns_set values $setId. These would return a list of the keys or
> > values in the ns_set respectively. While you can get these lists from
> > looping with ns_set key / value / array, it is convenient to have them as
>
> Sounds like a good idea to me. Having to manually iterate over the
> ns_set to find all matching keys always did seem awfully strange to
> me.
>
> > What do people think? I'd be happy to submit a patch for the changes. Are
> > there any other ns_set modifications you've been wanting?
>
> About two years ago, I thought I wanted some, so I patched the stuff I
> wanted into my local AOLserver code. Ah, it was the "findall" and
> "findmatch" stuff:
>
> http://sourceforge.net/tracker/?func=detail&aid=530808&group_id=3152&atid=303152
>
> But then I learned what horrible performance ns_set has for large
> quantities of data [I just added a note to the Wiki about that now],
> which was exactly the situation I was using findall and findmatch
> with. So I switched to Tcl Arrays, my need for a richer ns_set API
> evaporated then and there, and I never did post my cleaned up patch.
> (I still have it in my CVS though.)
>
> --
> Andrew Piskorski <[EMAIL PROTECTED]>
> http://www.piskorski.com/
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with
> the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field
> of your email blank.
>
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] ns_set questions
some more $0.02...
--- Jim Wilcoxson <[EMAIL PROTECTED]> wrote:
> Sets allow entries with duplicate keys. If
> duplicates are returned in
> the list for this new ns_set keys, that's fine,
> except that a naiive
> programmer can't go through the list of keys
> returned and fetch the
> corresponding values. You'd have to do a foreach
> loop on the keys,
> increment a counter, and use the counter to lindex
> into the ns_set values
> result:
>
> set values [ns_set values $myset]
> set i -1
> foreach key [ns_set keys $myset] {
> incr i ;# put it here so that continues
> can be used to exit early
> set val [lindex $values $i]
> do whatever
> }
>
I think this would work too:
foreach key [ns_set keys $myset] val [ns_set values
$myset] {
do whatever
}
> Another option would be "ns_set aget" to return
> alternating keys and
> values in a list that could be used as input to
> "array set" - sort of,
> ignoring the multiple key issue - to convert sets to
> arrays, and
> "ns_set aset" could be used to convert from arrays
> to sets, like:
>
> set myset [ns_set create]
> ns_set aset $myset [array get myarray]
>
and you could do this as well:
{key1 val1 key2 val2 ...}
foreach {key val} [ns_set list $myset] {
do whatever
}
> I don't know how often these would be used in
> practice though, because
> I think experienced TCL programmers quickly avoid
> using ns_sets except
> where they have to, like for interfacing with
> smallish nsd data
> structures.
>
I actually never fully understood the reason for
ns_set...but I never really tried to understand it
either. I almost always just used Tcl's internal data
structures...
--brett
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] ns_set questions
On 2004.06.11, Jim Wilcoxson <[EMAIL PROTECTED]> wrote:
> It seems to me that this is worse than the current way of using a set
> index with ns_set key and ns_set value:
>
> set size [ns_set size $myset]
> for {set i 0} {$i < $size} {incr i} {
> set key [ns_set key $myset $i]
> set val [ns_set value $myset $i]
> do whatever
> }
Or,
foreach {key value} [ns_set array $setId] {
# key is in $key, value is in $value
do whatever
}
> IMO, a better approach (or another one at least) would be to return a
> list of key value pairs with something like "ns_set list", ie:
[ns_set list] returns a list of non-persistent ns_set's. You probably
meant [ns_set array] which returns a list of key-value pairs, like:
{key1 value1 key2 value2 key3 value3 ...}
Thus, my foreach example above.
> Another option would be "ns_set aget" to return alternating keys and
> values in a list that could be used as input to "array set" - sort of,
> ignoring the multiple key issue - to convert sets to arrays, and
> "ns_set aset" could be used to convert from arrays to sets, like:
>
> set myset [ns_set create]
> ns_set aset $myset [array get myarray]
What you want is:
set setId [eval ns_set create setName [array get arrayName]]
Although, if you wanted to update an already existing ns_set instead of
create a new one, I guess you'd need something that would allow it.
I'd rather see [ns_set put] be modified to take multiple key-value
pairs, instead of introducing a new subcommand.
> I don't know how often these would be used in practice though, because
> I think experienced TCL programmers quickly avoid using ns_sets except
> where they have to, like for interfacing with smallish nsd data
> structures.
I was really hoping that Tcl 8.5's [dict] dictionaries would allow for
duplicate keys the way ns_set does so that multisets could be
implemented using dict and we could retire ns_set entirely. Alas, it
doesn't seem like it: [dict] are just like [array] except it stores a
value.
In general, I'd consider ns_set's deprecated: use normal Tcl data
structures when you can.
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] ns_set questions
On 2004.06.11, Brett Schwarz <[EMAIL PROTECTED]> wrote: > > I actually never fully understood the reason for ns_set...but I never > really tried to understand it either. I almost always just used Tcl's > internal data structures... When you need to implement sets (or hash arrays, etc.) where keys are not unique, and you need reasonably fast performance, ns_set is the way to go. However, with Tcl 8's performance improvements (Tcl_Obj's, etc.) I'm willing to bet I could probably write a pure-Tcl implementation of ns_set that would perform adequately compared to the C implementation. The added bonus would be binary support (ns_set's currently do not handle embedded NULLs in the key or values) as well as some other side-effects (Tcl_Obj refcounting/copy-on-write, etc.). But yes, in general, you probably don't need to use them except when interfacing with other things (like ns_conn headers, ns_db, etc.) that use ns_sets. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_set questions
On Fri, Jun 11, 2004 at 12:14:40PM -0400, Dossy wrote: > I was really hoping that Tcl 8.5's [dict] dictionaries would allow for > duplicate keys the way ns_set does so that multisets could be > implemented using dict and we could retire ns_set entirely. Alas, it > doesn't seem like it: [dict] are just like [array] except it stores a > value. > > In general, I'd consider ns_set's deprecated: use normal Tcl data > structures when you can. I believe the ns_set data structure (as opposed the the API) differs from Tcl Arrays only in these two properties: - Multiple identical keys are allowed. - Insert order is retained. There are probalby several feasible ways to map those properties onto Tcl Arrays, *IF* there's some separator string which you know will never be used in an ns_set key. (Basically, take the user's ns_set key, tack on an integer to store the sort order, and tack on another integer to tell you whether this is the 1st or Nth instance of that same ns_set key. Now use that whole thing as your Tcl Array key.) But, is there any such reserved separator character? Maybe define a new binary string containing nulls to be the separator? That way you'd know for sure that no OLD code uses that string, because the current/old ns_set implementation doesn't support binary strings at all, right? Would a binary separator like that cause any other problems? Also, a real drop in ns_set replacement has to be done in C (with both C and Tcl APIs), which may make things trickier. A real order-preserving multi-set data structure would be of general use though, unlike ns_set. The one and only advantage of the current ns_set, of course, is that its implementation is very simple. Presumably this is why it exists at all - way back in the AOLserver 0.x days, somebody needed something like a multi-set for HTTP headers and other small amounts of data, and whipped up Ns_Set. Rather than building on top of Tcl Array, another alternative is to use some entirely new from-scratch C implementation, in the future maybe even something like Ratcl. But I'm not aware of any existing code that would currently be a good fit as an ns_set replacement. http://www.equi4.com/ratcl.html -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_set questions
> > Rather than building on top of Tcl Array, another > alternative is to > use some entirely new from-scratch C implementation, > in the future > maybe even something like Ratcl. But I'm not aware > of any existing > code that would currently be a good fit as an ns_set > replacement. > I've never really used them but what about keyed lists in Tclx? I believe the order is preserved, and by the looks of it, it has a very similiar interface to ns_set (from a quick look through). It also supports nesting, which would be nice. Maybe we could hijack this __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_set questions
--- Brett Schwarz <[EMAIL PROTECTED]> wrote: > > > > Rather than building on top of Tcl Array, another > > alternative is to > > use some entirely new from-scratch C > implementation, > > in the future > > maybe even something like Ratcl. But I'm not > aware > > of any existing > > code that would currently be a good fit as an > ns_set > > replacement. > > > > > I've never really used them but what about keyed > lists > in Tclx? I believe the order is preserved, and by > the > looks of it, it has a very similiar interface to > ns_set (from a quick look through). It also supports > nesting, which would be nice. Maybe we could hijack > this > although it doesn't support duplicate keys :( __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] encoding aware nsreturnz
I took the encoding aware version of rlreturnz I had and made it mirror the old ns_return behavior (so bug 951391 should be fixed). I made it an Tcl ObjCommand as well. The testing was limited to checking it returns things gzipped and and not depending on Accept-Encoding header. I do: rename ns_return ns_return_safe rename ns_returnz ns_return in zz-postload.tcl to use it globally. The code is at http://xarg.net/download/nsreturnz-2.0d1.tar.gz if anyone wants to try it out (most important is probably checking the encoding stuff works correctly since I tested that not at all). It won't work with aolserver 3 though. -- Jeff Davis http://xarg.net -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_set questions
AOLserver already includes keyldel, keylget, keylkeys, and keylset, but they
aren't a suitable ns_set replacement. I'll finish documenting these on the
Wiki if someone doesn't beat me to it ;-)
Back in April 2001, people posted lists of their most frequently used
AOLserver commands, and ns_set was near the top of most lists. Even if
there are alternatives that make sense for future development, I think it
would be reasonable to enhance ns_set if the functionality is useful. It
might be interesting to see how command usage has changed in the past three
years. I suspect not much has changed, ns_share -> nsv is the only thing
that really comes to mind.
As an example of how ns_set keys and values might be handy, in some of my
code I often need to generate a using ns_htmlselect from the keys
and values in an ns_set, which means we need separate lists of the values
and labels to pass to that proc. So we implemented ns_set keys and values
functionality at the TCL level for this and other uses. (As an aside,
ns_htmlselect also needs cleanup to be useful.)
I went ahead and patched AOLserver locally, < 20 lines of code, taken
directly from ns_set array. In tclsh:
% load nsd
% set setId [ns_set create]
d0
% for {set i 0} {$i < 1000} {incr i} {
ns_set put $setId k$i v$i
}
% time {ns_set keys $setId} 1
147 microseconds per iteration
% time {
set l [list]
foreach {key value} [ns_set array $setId] {
lappend l $key
}
} 1
3341 microseconds per iteration
% time {
set l [list]
set s [ns_set size $setId]
for {set i 0} {$i < $s} {incr i} {
lappend l [ns_set key $setId $i]
}
} 1
3803 microseconds per iteration
A 1000-field ns_set isn't typical of course, the C version is maybe 10x
faster than the TCL work-alikes for ns_sets with 10 fields.
Jamie
On Fri, 11 Jun 2004 10:43:41 -0700, Brett Schwarz <[EMAIL PROTECTED]>
wrote:
>--- Brett Schwarz <[EMAIL PROTECTED]> wrote:
>> >
>> > Rather than building on top of Tcl Array, another
>> > alternative is to
>> > use some entirely new from-scratch C
>> implementation,
>> > in the future
>> > maybe even something like Ratcl. But I'm not
>> aware
>> > of any existing
>> > code that would currently be a good fit as an
>> ns_set
>> > replacement.
>> >
>>
>>
>> I've never really used them but what about keyed
>> lists
>> in Tclx? I believe the order is preserved, and by
>> the
>> looks of it, it has a very similiar interface to
>> ns_set (from a quick look through). It also supports
>> nesting, which would be nice. Maybe we could hijack
>> this
>>
>
>although it doesn't support duplicate keys :(
>
>
>
>
>
>__
>Do you Yahoo!?
>Friends. Fun. Try the all-new Yahoo! Messenger.
>http://messenger.yahoo.com/
>
>
>--
>AOLserver - http://www.aolserver.com/
>
>To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
>body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] ns_set questions
On 2004.06.11, Jamie Rasmussen <[EMAIL PROTECTED]> wrote:
> Back in April 2001, people posted lists of their most frequently used
> AOLserver commands, and ns_set was near the top of most lists.
Interesting! I definitely think doing this exercise again today would
be lots of fun, and very telling ...
> % time {ns_set keys $setId} 1
> 147 microseconds per iteration
> % time {
> set l [list]
> foreach {key value} [ns_set array $setId] {
> lappend l $key
> }
> } 1
> 3341 microseconds per iteration
> % time {
> set l [list]
> set s [ns_set size $setId]
> for {set i 0} {$i < $s} {incr i} {
> lappend l [ns_set key $setId $i]
> }
> } 1
> 3803 microseconds per iteration
>
> A 1000-field ns_set isn't typical of course, the C version is maybe 10x
> faster than the TCL work-alikes for ns_sets with 10 fields.
One problem is that you didn't put those code in procs, so the [time]
command isn't timing the code with byte-compilation benefits.
Try:
proc ns_set_foreach {setId} {
set l [list]
foreach {key value} [ns_set array $setId] {
lappend l $key
}
return $l
}
proc ns_set_for {setId} {
set l [list]
set s [ns_set size $setId]
for {set i 0} {$i < $s} {incr i} {
lappend l [ns_set key $setId $i]
}
return $l
}
Then do:
% time {ns_set_foreach d0} 1
% time {ns_set_for d0} 1
And see how those timings compare to the [ns_set keys] C version. Also,
include what version of Tcl you're testing on.
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] ns_set questions
>One problem is that you didn't put those code in procs, so the [time]
>command isn't timing the code with byte-compilation benefits.
> ...
Thanks for pointing that out, when in procs I get:
% time {ns_set_foreach d0} 1
1403 microseconds per iteration
% time {ns_set_for d0} 1
1483 microseconds per iteration
% ns_info patchlevel
4.1.0
% info patchlevel
8.4.6
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
[AOLSERVER] ANN: Searchable list archive at Gmane.org
First, I want to thank all the lurkers who responded to my request for feedback! I am pleasantly surprised by the number of responses: thank you all. In exchange, I heard a common theme amongst a lot of the responses: searching the AOLSERVER list archive using the LISTSERV interface is annoying as it requires you to log in first. Also, the LISTSERV archive isn't indexed by Google or other popular search engines, so unless people subscribe to the list and use the LISTSERV's pretty pathetic search facility, they won't find messages: newbies to AOLserver most likely won't know to do this. So, I've gone through the process of getting the AOLSERVER list archived at Gmane, a wonderful gateway service at http://www.gmane.org/. The list archives can be read here: http://news.gmane.org/gmane.comp.web.aolserver Here's a link to the search page: http://search.gmane.org/search.php?group=gmane.comp.web.aolserver&sort=relevance Once Google indexes Gmane, the archive's articles should show up in Google searches, too. Append your search terms to this URL to urge Google to limit searches to just the archive at Gmane: http://www.google.com/search?q=site%3Aarticle.gmane.org+gmane.comp.web.aolserver As an added bonus (!!!), I've supplied my own personal mail archive of all the messages I've received from the list since January 2000 when the list was created, and the kind folks at Gmane have started importing them all! So, very soon you will be able to search the archive all the way back to the beginning. (I think my archive may be missing a total of 50 messages over the past 4 years. Oh well, I'm sorry about that.) I hope this new archive will be useful to folks, and hoepfully will help more people once the mailing list contents can be found via Google. I'll continue to gather everyone's feedback and try to come up with other common themes, but the next big one is, of course, the documentation which is being actively worked on. Again, I plead with everyone: help out, pitch in and contribute to the documentation! Either by helping to write it, or by making specific requests for what documentation you feel would be most useful! As usual, feel free to send requests directly to me off-list and I'll take care of the rest. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_set questions
On 2004.06.11, Jamie Rasmussen <[EMAIL PROTECTED]> wrote:
> >One problem is that you didn't put those code in procs, so the [time]
> >command isn't timing the code with byte-compilation benefits.
> > ...
>
> Thanks for pointing that out, when in procs I get:
> % time {ns_set_foreach d0} 1
> 1403 microseconds per iteration
>
> % time {ns_set_for d0} 1
> 1483 microseconds per iteration
Much better than the 3,800 usec timings you got before, but still
nowhere near the 140 usec that the C version gets. Some of the slowness
of the Tcl version may be because the ns_set API isn't using Tcl_Obj's
-- still lots of Tcl_DString's to build lists instead of creating list
Tcl_Obj's, etc.
If any work should go into ns_set, I think making it take more
advantages of Tcl_Obj's would get everyone the most benefit as opposed
to adding new subcommands that people would have to modify their
existing code to start using. Thoughts?
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] ANN: Searchable list archive at Gmane.org
If you are interested in adding historical stuff to the archive, I have the mailing list from March 23rd, 1996 to Oct 9, 1999. Lemme know. Jim > As an added bonus (!!!), I've supplied my own personal mail archive of > all the messages I've received from the list since January 2000 when the > list was created, and the kind folks at Gmane have started importing > them all! So, very soon you will be able to search the archive all the > way back to the beginning. (I think my archive may be missing a total > of 50 messages over the past 4 years. Oh well, I'm sorry about that.) > > I hope this new archive will be useful to folks, and hoepfully will help > more people once the mailing list contents can be found via Google. > > I'll continue to gather everyone's feedback and try to come up with > other common themes, but the next big one is, of course, the > documentation which is being actively worked on. Again, I plead with > everyone: help out, pitch in and contribute to the documentation! > Either by helping to write it, or by making specific requests for what > documentation you feel would be most useful! As usual, feel free to > send requests directly to me off-list and I'll take care of the rest. > > -- Dossy > > -- > Dossy Shiobara mail: [EMAIL PROTECTED] > Panoptic Computer Network web: http://www.panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with > the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field > of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] 6/11/2004 documentation update
We are almost a quarter of the way complete with updating the Tcl API documentation, having completed 51 out of 219 commands, or 23%. You can see the results of this effort starting here: http://panoptic.com/wiki/aolserver/Tcl+API 168 commands left by 6/25. That's 10 more business days, or 17 commands a day that we need to complete! Even if you don't want to write documentation, please take some time to look over a few of the pages and review them for accuracy and clarity. Thanks! -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
