Favorite REs?

0 views
Skip to first unread message

Christopher Nelson

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
I'm looking for example regular expressions for my book and I'm not feeling very
creative today. Got any favorite REs you care to share?

Chris
--
Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!

Steve Ball

unread,
Apr 17, 1999, 3:00:00 AM4/17/99
to

Christopher Nelson wrote:
>
> I'm looking for example regular expressions for my book and I'm not feeling very
> creative today. Got any favorite REs you care to share?

Stephen Uhler's example for parsing HTML are my favourite. Look for the
html_library package.

See also TclXML for how I've adapted it for XML.

Cheers,
Steve Ball

jeff_...@my-dejanews.com

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to ch...@pinebush.com
In article <3717CE4B...@pinebush.com>,

Christopher Nelson <ch...@pinebush.com> wrote:
> I'm looking for example regular expressions for my book and I'm not feeling
very
> creative today. Got any favorite REs you care to share?

Oh, this could be a very long list, but I'll make some heuristics whereby
you can start exploring regexp in depth to give it the best coverage that
no book has yet given, plus a couple favs.

Starting with the favorites, I like:
set truth {^(1|yes|true|on)$}
regexp -nocase $truth $val

I usually use this for setting vals or in expr's, because expr's don't
allow the Tcl boolean keywords that are allowed a lot of other places.

I also like to know when I qualify for certain types (mostly with regexp):
(from a validation function)

switch -glob -- $type {
alphab* { # alphabetic
return [regexp -nocase "^\[a-z\]$opt\$" $val]
}
alphan* { # alphanumeric
return [regexp -nocase "^\[a-z0-9\]$opt\$" $val]
}
b* { # boolean - would be nice if it were more than 0/1
return [regexp "^\[01\]$opt\$" $val]
}
d* { # date - always strict
return [expr {![catch {clock scan $val}]}]
}
h* { # hexadecimal
return [regexp -nocase "^(0x)?\[0-9a-f\]$opt\$" $val]
}
i* { # integer
return [regexp "^\[-+\]?\[0-9\]$opt\$" $val]
}
n* { # numeric
return [regexp "^\[0-9\]$opt\$" $val]
}
rea* { # real
return [regexp -nocase [expr {$strict
?{^[-+]?([0-9]+\.?[0-9]*|[0-9]*\.?[0-9]+)(e[-+]?[0-9]+)?$}
:{^[-+]?[0-9]*\.?[0-9]*([0-9]\.?e[-+]?[0-9]*)?$}}] $val]
}
reg* { # regexp
return [expr {![catch {regexp $val {}}]}]
}
val* { # value, any valid number type
return [expr {![catch {expr {0+$val}}]}]
}
l* { # list
return [expr {![catch {llength $val}]}]
}
w* { # widget
return [winfo exists $val]
}
default {
return -code error "bad [lindex [info level 0] 0] type \"$type\":\
\nmust be [join [lsort {alphabetic alphanumeric date \
hexadecimal integer numeric real value \
list boolean}] {, }]"
}
}

Aside from that, there are certain things that people should understand
to make best use of regexps (and, of course, regsubs). Since there is
(still) no eval switch for regexps, you should describe how the eval/subst
of a regsub result is done, and the necessary escaping to avoid problems.

Also, looking at 8.1 regexps (soooo much better than 8.0), you'll note
the benefits of the new \ sequences. The metasyntax is also a boon, but
not always where one thinks. For example, the (?i) says do a case
insensitive match. With regexp, you have always had -nocase, but since
the same regexp engine is used throughout Tcl (which you should note),
you can now take advantage of this in commands like switch and lsearch.

Basically, all the switches for regexp can now be placed in the
metasyntax, and the metasyntax can be used whereever the regexp engine
is in place.

newline handling is also always a bit fruity, so you might want to go
into that a bit.

The {} matching is new, and helpful for some, so don't forget that.
Also, greedy versus non-greedy has tripped up many, and is especially
good to understand for HTML-like parsing.

There's more I'm sure, but that's all off the top of my head for now.

--
jeff.hobbs @SPAM acm.org
jeffrey.hobbs @SPAM icn.siemens.de

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Christopher Nelson

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
jeff_...@my-dejanews.com wrote:
>
> In article <3717CE4B...@pinebush.com>,
> Christopher Nelson <ch...@pinebush.com> wrote:
> > I'm looking for example regular expressions for my book and I'm not
> > feeling very creative today. Got any favorite REs you care to share?
>
> Oh, this could be a very long list, but I'll make some heuristics whereby
> you can start exploring regexp in depth to give it the best coverage that
> no book has yet given, plus a couple favs.
>
> Starting with the favorites, I like:
> set truth {^(1|yes|true|on)$}
> regexp -nocase $truth $val

I like that. Thanks!

>
> ...snip...


>
> Aside from that, there are certain things that people should understand
> to make best use of regexps (and, of course, regsubs). Since there is
> (still) no eval switch for regexps, you should describe how the eval/subst
> of a regsub result is done, and the necessary escaping to avoid problems.
>
> Also, looking at 8.1 regexps (soooo much better than 8.0), you'll note
> the benefits of the new \ sequences. The metasyntax is also a boon, but
> not always where one thinks. For example, the (?i) says do a case
> insensitive match. With regexp, you have always had -nocase, but since
> the same regexp engine is used throughout Tcl (which you should note),
> you can now take advantage of this in commands like switch and lsearch.

Yeah, it's nice to have the embedded options for switch, etc.

> ...


> newline handling is also always a bit fruity, so you might want to go
> into that a bit.

Oh, GAWD!! I still have _no_ _idea_ what one of the newline-releated switched
to regexp does.

jeff_...@my-dejanews.com

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to ch...@pinebush.com
In article <371B1D99...@pinebush.com>,
Christopher Nelson <ch...@pinebush.com> (also cc'ed) wrote:

> jeff_...@my-dejanews.com wrote:
...
> > newline handling is also always a bit fruity, so you might want to go
> > into that a bit.
>
> Oh, GAWD!! I still have _no_ _idea_ what one of the newline-releated switched
> to regexp does.

It's not that tricky. It basically has to do with the relation between
^, $ and \n. Sometimes you want to make sure matches are within one line,
and sometimes not. I found it more annoying before with the text widget
use of -regexp, where it seemed I was oftened constrained by the end of a
text line. I haven't done tests to see if the new 8.1 syntax gets around
that (the docs haven't change to say I can).

Don Libes

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
jeff_...@my-dejanews.com writes:
> In article <3717CE4B...@pinebush.com>,
> Christopher Nelson <ch...@pinebush.com> wrote:
> > I'm looking for example regular expressions for my book and I'm not feeling
> very
> > creative today. Got any favorite REs you care to share?
>
> Oh, this could be a very long list, but I'll make some heuristics whereby
> you can start exploring regexp in depth to give it the best coverage that
> no book has yet given, plus a couple favs.

How about a chapter on the tradeoffs of parsing via regexps and the
tcLex approach. There are many cases where regexps really aren't
appropriate.

The expect book has lots of wild and cool regexps. For example, it
shows how to use regexps to parse the output of terminfo or understand
the telnet protocol. And some strange ones like {/\\(.)} for how a
one-handed person could graphically indicate control characters. Yes,
we really needed this!

*Calling* regexps would make a nice topic. For example, how to handle
streams that require some buffering and some cleverness in how args
are passed to regexp. For example, parsing RFC822 header lines can't
be done with a single regexp because you don't know if you're done
until you look at the NEXT line which might be a continuation. Doing
this efficiently requires some tricky regexp coding. This problem is
surprisingly common. For example, the exact same problem comes up
when parsing cgi file data.

> Aside from that, there are certain things that people should understand
> to make best use of regexps (and, of course, regsubs). Since there is
> (still) no eval switch for regexps, you should describe how the eval/subst
> of a regsub result is done, and the necessary escaping to avoid problems.

Good point. This is a killer technique. A client once asked me to
add some features for an existing Tcl product. After some analysis, I
replaced 150 lines of ugly parsing code (the client was cracking open
the strings, character by character, because regexps just didn't have
the power) with about 10 lines based on the idea Jeffrey describes.
The result was much easier to read (assuming you understand the idea)
because each transformation could now be in its own proc. And the run
time when from 10 minutes to 3 seconds.

Don


Cameron Laird

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
In article <s6ahfqc...@nist.gov>, Don Libes <li...@nist.gov> wrote:
>jeff_...@my-dejanews.com writes:
>> In article <3717CE4B...@pinebush.com>,
>> Christopher Nelson <ch...@pinebush.com> wrote:
>> > I'm looking for example regular expressions for my book and I'm not feeling
>> very
>> > creative today. Got any favorite REs you care to share?
>>
>> Oh, this could be a very long list, but I'll make some heuristics whereby
>> you can start exploring regexp in depth to give it the best coverage that
>> no book has yet given, plus a couple favs.
>
>How about a chapter on the tradeoffs of parsing via regexps and the
>tcLex approach. There are many cases where regexps really aren't
This would be wildly popular--well, at least among
a select group--but it would also be a different
book. Chris is operating under severe space con-
straints (and time and money and so on, too--those
are different matters).

>appropriate.
>
>The expect book has lots of wild and cool regexps. For example, it
Indeed.
.
.
.

>*Calling* regexps would make a nice topic. For example, how to handle
Indeed.
.
.

.
>> Aside from that, there are certain things that people should understand
>> to make best use of regexps (and, of course, regsubs). Since there is
>> (still) no eval switch for regexps, you should describe how the eval/subst
>> of a regsub result is done, and the necessary escaping to avoid problems.
>
>Good point. This is a killer technique. A client once asked me to
>add some features for an existing Tcl product. After some analysis, I
>replaced 150 lines of ugly parsing code (the client was cracking open
>the strings, character by character, because regexps just didn't have
>the power) with about 10 lines based on the idea Jeffrey describes.
>The result was much easier to read (assuming you understand the idea)
>because each transformation could now be in its own proc. And the run
>time when from 10 minutes to 3 seconds.
>
>Don
>

Indeed.

People like Don and Jeffrey have GREAT stories to
tell. Is there a better way to get them out? I
know you fellows contribute more than your share
already to the Tcl and other Conferences. Is there
something that would help you generate even more of
this prose?

On the demand side, how do readers like this stuff
packaged? Do off-hand paragraphs in Usenet work,
or do you-all need hardback books, or magazines, or
...?

Support the *Tcl Journal*.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX

Robert Seeger

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
Personally, I'd like to see a bok put out with a collection of articles
by the various "gurus" in the Tcl community. Perhaps we could put
together a web page that has a collection articles by the various people
in the Tcl community about how they do things in Tcl, good ways to do
things, etc. For example, a few interesting titles would be:

- "The Complexities of the Tcl Regular Expression"
A discussion of how to use regular expressions in Tcl. Where they
should be used instead of string functions. How to optimize them. Some
common and uncommon regexps that are usful in a variety of situations. .
.

- "String Handling in Tcl"
What is the best way to handle strings in a variety of situations. For
example, when is it a good idea to use [string compare $str1 $str2] vs
{$str1 != $str2}. I don't know how to describe this subject well, but it
could be a very interesting one.

- "Code Optimization in Tcl"
Discussion of things that you should keep in mind when writing Tcl code
to make it faster. For example, [expr 2 + 2] and [expr {2 + 2}] and [if
$bob] vs. [if {$bob}] and the like.

Many of these topics are covered on various web pages by various people.
However, it would be nice to have real articles on them, and have them
collected all in one place. Once there are enough of them, they could be
collected together into a book. I know I would buy it. It's the kind of
thing that all levels of Tcl programmer (except for maybe the very
beginner) would find extremely useful. I know it would be a valuable
addition to my library.

Any comments?

Robert Seeger


Cameron Laird wrote:
> People like Don and Jeffrey have GREAT stories to
> tell. Is there a better way to get them out? I
> know you fellows contribute more than your share
> already to the Tcl and other Conferences. Is there
> something that would help you generate even more of
> this prose?
>
> On the demand side, how do readers like this stuff
> packaged? Do off-hand paragraphs in Usenet work,
> or do you-all need hardback books, or magazines, or
> ...?
>
> Support the *Tcl Journal*.
> --
>
> Cameron Laird http://starbase.neosoft.com/~claird/home.html
> cla...@NeoSoft.com +1 281 996 8546 FAX

--
Whenever you're having a bad day, and it seems like everyone's
trying to piss you off, remember this - it takes 43 muscles to
frown, but only 4 to pull the trigger of a decent sniper rifle.
- Sorry, I stole this .sig, but I love it. . .

jeff_...@my-dejanews.com

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to li...@nist.gov
In article <s6ahfqc...@nist.gov>,

Don Libes <li...@nist.gov> (courtesy cc'ed) wrote:
> jeff_...@my-dejanews.com writes:
> > In article <3717CE4B...@pinebush.com>,
> > Christopher Nelson <ch...@pinebush.com> wrote:
> > > I'm looking for example regular expressions for my book and I'm not
...

> > Aside from that, there are certain things that people should understand
> > to make best use of regexps (and, of course, regsubs). Since there is
> > (still) no eval switch for regexps, you should describe how the eval/subst
> > of a regsub result is done, and the necessary escaping to avoid problems.
>
> Good point. This is a killer technique. A client once asked me to
> add some features for an existing Tcl product. After some analysis, I
> replaced 150 lines of ugly parsing code (the client was cracking open
> the strings, character by character, because regexps just didn't have
> the power) with about 10 lines based on the idea Jeffrey describes.
> The result was much easier to read (assuming you understand the idea)
> because each transformation could now be in its own proc. And the run
> time when from 10 minutes to 3 seconds.

Oh, I love those kind of results, and they really are acheivable when
you look at how some people, not familiar with modern parsing techniques
or good parsing languages (ahem, like Tcl :^) ), can make a massacre of
the keyboard out of a simple parsing task.

Although I think Don's paranthetical comment,


(assuming you understand the idea)

is a little understated. That can be said about most things, but (oddly
enough for the power it provides) regexps aren't all that well
recognized to start off with, and then you throw the eval or subst
on top of that... How many times a month does the basic eval question
(where eval ... is the answer) come up in the newsgroup? I believe
people come onto the power of subst even later usually.

When Stephen Uhler presented his "10-line HTML parser", it got a lot of
people interested in what was previously an underutilized ability of
regexp and substitution.

Here's another step in code-deciphering that improves upon the above
original for a specific case (CGI input decoding):

8.0: (from Libes' cgi.tcl)
proc cgi_unquote_input {buf} {
# rewrite "+" back to space
regsub -all {\+} $buf { } buf
# protect \ from quoting another \ and throwing off other things
# protect $ from doing variable expansion
# protect [ from doing evaluation
# protect " from terminating string
regsub -all {([\\[\"$])} $buf {\\\1} buf

# replace line delimiters with newlines
regsub -all -nocase "%0d%0a" $buf "\n" buf
# Mosaic sends just %0A. This is handled in the next command.

# prepare to process all %-escapes
regsub -all -nocase {%([a-f0-9][a-f0-9])} $buf {[format %c 0x\1]} buf
# process %-escapes and undo all protection
eval return \"$buf\"
}

8.1:
proc cgi_unquote_input buf {
# rewrite "+" back to space
regsub -all {\+} $buf { } buf
# protect \ from quoting another \ and throwing off other things
regsub -all {\\} $buf {\\\\} buf

# replace line delimiters with newlines
regsub -all -nocase "%0d%0a" $buf "\n" buf

# prepare to process all %-escapes
regsub -all -nocase {%([a-f0-9][a-f0-9])} $buf {\\u00\1} buf
# process \u unicode mapped chars
return [subst -novar -nocommand $buf]
}

This little extra magic provides a 20% speed increase, with a subst
that is more subtle than the format above. I get another 25% when
I have "string map" to replace the first 3 regsubs. This ain't
peanuts for CGI users, as this is called twice for each var/value
pair that comes into a CGI form.

Bob Techentin

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
Robert Seeger wrote:
>
> Personally, I'd like to see a bok put out with a collection of articles
> by the various "gurus" in the Tcl community.

I vote for the Tcler's Wiki at http://purl.org/thecliff/tcl/wiki/

The Wiki is a place where everyone can contribute just a little, and we
collectively end up with a lot. It's kind of like an on-line
peer-reviewed journal for micro-articles. There is already a "Tcl
Performance" page. You could easily add pages for REs and string
handling.

Bob

--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html

Bob Techentin

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
Bob Techentin wrote:
>
> Robert Seeger wrote:
> >
> > Personally, I'd like to see a bok put out with a collection of articles
> > by the various "gurus" in the Tcl community.
>
> I vote for the Tcler's Wiki at http://purl.org/thecliff/tcl/wiki/
>
> The Wiki is a place where everyone can contribute just a little, and we
> collectively end up with a lot. It's kind of like an on-line
> peer-reviewed journal for micro-articles. There is already a "Tcl
> Performance" page. You could easily add pages for REs and string
> handling.

Ooops! Look at that. Somebody added an Advanced Tcl page with
subtopics for REs, String processing, and others. :-)

jeff_...@my-dejanews.com

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to techenti...@mayo.edu
In article <371C73E3...@mayo.edu>,

Bob Techentin <techenti...@mayo.edu> (courtesy cc'ed) wrote:
> Robert Seeger wrote:
> > Personally, I'd like to see a bok put out with a collection of articles
> > by the various "gurus" in the Tcl community.
>
> I vote for the Tcler's Wiki at http://purl.org/thecliff/tcl/wiki/
>
> The Wiki is a place where everyone can contribute just a little, and we
> collectively end up with a lot. It's kind of like an on-line
> peer-reviewed journal for micro-articles. There is already a "Tcl
> Performance" page. You could easily add pages for REs and string
> handling.

Personally (since Cameron asked anyway), I don't find the Wiki all that
friendly. I do think the concept is important, but my main gripe is
presentation. Perhaps I've been too affected by my UI classes and
the psychology guys that I argue about UI design with, but the Wiki is
really ... well, as low-tech as it gets. This doesn't really encourage
Tcl newbies to use it as a resource. The fact that everything works
on a numbers basis is also a bit odd.

We can also go into the Cathedral-Bazaar argument. Wiki is
unquestionably the Bazaar. While I don't like the Cathedral (in
which most of the static Net basically sits), I fall more in between
for an open-moderated approach. Although this isn't something that
I grasp to tightly.

Aside from that, I've had problems in general accessing the Wiki.
Either funny error messages, or it's just darn slow. This is a
minor nit, and could come from me accessing it from Europe, but
it does deter me from being active there.

That said, I am trying to adapt something I did in-house for my
personal (open) use. Time, of course, eludes me at the moment,
and it is always important to have something (which the Wiki
provides).

Bob Techentin

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
jeff_...@my-dejanews.com wrote:
>
> Personally (since Cameron asked anyway), I don't find the Wiki all that
> friendly. I do think the concept is important, but my main gripe is
> presentation. Perhaps I've been too affected by my UI classes and
> the psychology guys that I argue about UI design with, but the Wiki is
> really ... well, as low-tech as it gets. This doesn't really encourage
> Tcl newbies to use it as a resource. The fact that everything works
> on a numbers basis is also a bit odd.
>

Hmmmmm. I agree that Wiki is a little clunky. I personally consider
the dearth of GIFs an advantage. :-) But the Wiki is evolving too.
The searching and bookmarking mechanism is only five days old.

I've got several bookshelf-meters dedicated to various programming
languages, tools, and libraries. Less than 20cm is dedicated to
Tcl/Tk. On the other hand, I've got a very long list of bookmarks
pointing to lots of home pages, FAQs, and other sites specifically for
Tcl. And I try to read comp.lang.tcl regularly to "keep up."

I look at the Wiki as a place to collect a little of the information
which is scattered around the world right now. I'm not going to write a
book any time soon, but I can help collect things into a more-or-less
organized pile. I can write a little about my own experiences. And
when my writing can be improved (or I leave out the smiley face on a
sarcastic remark), there are several others who will politely offer
corrections.

Some day the Tcl Performance page on the Tcler's Wiki will probably get
translated into "Joe Schmo's Turbo Tcl Page", complete with an animated
GIF of a chevy long-block turbocharger puffing out feathers. The
content might even end up in somebody's book some day.

Until then, I think the wiki is a reasonable place to collect and
collaboratively edit and manage some Tcl information. See you there.
;-)

Bob

lvi...@cas.org

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
> From: jeff_...@my-dejanews.com

>Tcl newbies to use it as a resource. The fact that everything works
>on a numbers basis is also a bit odd.

I assume you are referring to the fact that each page in the database
is given a 'name' that is a number here. It may be less than
evident that one need not use the page numbers to get to any page -
one can provide as URL the base url and the title of the page and get
to the page. From a database point of view, I suspect the code was
simpler to generate incremental numbers for each new page.

>Aside from that, I've had problems in general accessing the Wiki.
>Either funny error messages, or it's just darn slow. This is a

Unfortunately, the specter of file locking comes into play - last I had heard,
a way to do reliable file locking that works cross platform had yet to be
found.

As for speed - I've seen slow times and fast times. In general for me,
it's pretty average.

>personal (open) use. Time, of course, eludes me at the moment,
>and it is always important to have something (which the Wiki
>provides).

I've in the past tried other alternatives (yahoo clubs, mailing lists, etc.)
as well as have watched two different people attempt a Tcl related e-zine.
So far, none seem to make everyone happy...

Perhaps community and collabrative work is over-rated...
--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

Phil

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
Cameron Laird <cla...@Starbase.NeoSoft.COM> wrote:
> .
> .
> .
>Support the *Tcl Journal*.

How?

Phil
--
Phil Ehrens <peh...@ligo.caltech.edu>| Fun stuff:
The LIGO Laboratory, MS 18-34 | http://www.ralphmag.org
California Institute of Technology | http://www.yellow5.com
1200 East California Blvd. | ftp://ftp.no.pgpi.com/pub/pgp
Pasadena, CA 91125 USA | http://slashdot.org
Phone:(626)395-8518 Fax:(626)793-9744 | http://freshmeat.net

lvi...@cas.org

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to

According to Phil <peh...@ligo.caltech.edu>:

:Cameron Laird <cla...@Starbase.NeoSoft.COM> wrote:
:> .
:> .
:> .
:>Support the *Tcl Journal*.
:
:How?

Visit <URL: http://tcl.webjump.com/> or
<URL: http://www.linuxsupportline.com/~sto/journal/>, sign up for the
<URL: http://www.onelist.com/viewarchive.cgi?listname=tcltk>.
mailing list associated with the journal, and write small articles to
be published.

Jean-Claude Wippler

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
Bob Techentin wrote:

[in reply to Jeff Hobbs' valuable comments on "wiki"]

> Hmmmmm. I agree that Wiki is a little clunky. I personally consider
> the dearth of GIFs an advantage. :-) But the Wiki is evolving too.

Support for images would be nice. I'm not fond of flashy gimmicks, but
as they say: pictures can be worth a thousand words (more, IMO). Many
other implementations of wiki also support images on pages. The reason
it isn't on the Tcl'ers Wiki yet, is that this site can also be copied
and browsed locally (with a Tk interface), and I haven't figured out how
to best cache images (the entire Tcl'ers Wiki is inside a single file).

> The searching and bookmarking mechanism is only five days old.

In all practicality, yes. The mechanism was added a little while back,
but as with several aspects of this Wiki, it's still all so rough that
I'm very hesitant to start documenting it.

And it *is* far from perfect. Your "Advanced Tcl" shows up with an ugly
http://216.71.55.6/cgi-bin/wikit/395.html URL, to give one example. It
can also be reached as http://purl.org/thecliff/tcl/wiki/Advanced - but
who would figure this out? - it's far from obvious right now.

> I look at the Wiki as a place to collect a little of the information

> which is scattered around the world right now. [...]

Me too.

I guess the best characterization of the Tcl'ers Wiki today is: a spot
where you can find out how and whether the "wiki" mechanism is useful.
While it's tempting to discuss how to alter and improve the site itself,
especially among so many Tcl programmers, it seems to me that the idea
of having something which is quite different from email, usenet, and the
web is in itself a fascinating aspect. I like the idea of putting a few
lists of URL, topics, people, books, and more in one place - without
creating a maintenance burden, or a qhost site which ends up consisting
of so much outdated info that even the remaining good stuff drowns.

> Some day the Tcl Performance page on the Tcler's Wiki will probably
> get translated into "Joe Schmo's Turbo Tcl Page", complete with an
> animated GIF of a chevy long-block turbocharger puffing out feathers.
> The content might even end up in somebody's book some day.

More and more, I tend to use a local copy of WiKit (the implementatioon
of this Wiki) to create new pages for my own use. I know that when you
have a hammer everything starts to look like a nail, but it really works
for me. As a programmer, it was a surprising experience to find out
that I was more interested in *using* wiki than tinkering with it.

Am I excited about this - you bet :)
Will the Tcl'ers Wiki be a useful resource?
You decide. Literally. Anyone can add/edit anything there.
Grab a copy. Set up your own. I did: http://216.71.55.6/cgi-bin/jcw/

Even if all this wiki does is trigger new ideas or new implementations,
it will have served its purpose as far as I'm concerned.

-- Jean-Claude


========================================================================
In an attempt to help "spread the word" about wiki, here's more info.

Some pointers, for those who are deeply puzzled by this "wiki" stuff:
http://c2.com/cgi/wiki?WikiEssence
http://c2.com/cgi/wiki?WikiWikiWeb
http://c2.com/w2/wiki/
And a few alternate wiki implementations:
http://pbl.cc.gatech.edu:8080/myswiki
http://starship.python.net/crew/scharf/TWiki/bin/view/Main/WebHome
Some complex issues related to wiki (I found these pages just now):
http://c2.com/w2/wiki/EditLockingThatPreventsConcurrentUpdates
http://c2.com/w2/wiki/SupportOfNameAnchors
http://c2.com/w2/wiki/AsciiFormattingRules
As you can see, wiki wiki webs are actively being extended/discussed.

Now the Tcl'ers Wiki itself:
http://purl.org/thecliff/tcl/wiki/
There's lots of book titles, see:
http://purl.org/thecliff/tcl/wiki/BOOK
The archive of all previous Tcl-URL! postings on c.l.t:
http://purl.org/thecliff/tcl/wiki/Tcl-URL!
A page to voice complaints to wiki as a collaboration tool:
http://purl.org/thecliff/tcl/wiki/Gripes
How to search and use bookmarks, like those used here:
http://purl.org/thecliff/tcl/wiki/SearchAndBookmark
Setting up your own wiki site or local copy:
http://purl.org/thecliff/tcl/wiki/GrowYourOwnWiki
I just added a page on the performance of the Tcl'ers Wiki:
http://purl.org/thecliff/tcl/wiki/WiKitPerformance

========================================================================

Mark Roseman

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
Larry Virden wrote:
> I've in the past tried other alternatives (yahoo clubs, mailing lists, etc.)
> as well as have watched two different people attempt a Tcl related e-zine.
> So far, none seem to make everyone happy...
>
> Perhaps community and collabrative work is over-rated...


i doubt it, but i may be biased. ;-)

sure, there are better tools for online collaboration, but
i think the wiki does a great job of what its trying to do.
the fact that its fairly low-tech is i think one of its
strong points. people for the most part are able to get
over looking at the technology and get going on the content.

mark

--
Mark Roseman <ros...@teamwave.com>
http://www.teamwave.com
TeamWave Software Ltd.

Donal K. Fellows

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to
In article <371CD9DA...@equi4.com>,
Jean-Claude Wippler <j...@equi4.com> wrote:

> Bob Techentin wrote:
>> Hmmmmm. I agree that Wiki is a little clunky. I personally consider
>> the dearth of GIFs an advantage. :-) But the Wiki is evolving too.
>
> Support for images would be nice. I'm not fond of flashy gimmicks, but
> as they say: pictures can be worth a thousand words (more, IMO). Many
> other implementations of wiki also support images on pages. The reason
> it isn't on the Tcl'ers Wiki yet, is that this site can also be copied
> and browsed locally (with a Tk interface), and I haven't figured out how
> to best cache images (the entire Tcl'ers Wiki is inside a single file).

I suppose my main gripes with the Wiki are that it is *very* slow, and
that it seems to be completely incompatible with web caches.

Still, as a spot for collecting everything together in a big heap
(where it can be picked over to winnow out the bad ideas) it is a
really good thing.

I'm not all that keen on inline images. They may be sometimes worth a
thousand words, but not usually. And they discriminate against people
with text-only browsers.

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Don Libes

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to
fell...@cs.man.ac.uk (Donal K. Fellows) writes:
> In article <371CD9DA...@equi4.com>,
> Jean-Claude Wippler <j...@equi4.com> wrote:
> > Bob Techentin wrote:
> >> Hmmmmm. I agree that Wiki is a little clunky. I personally consider
> >> the dearth of GIFs an advantage. :-) But the Wiki is evolving too.
> >
> > Support for images would be nice. I'm not fond of flashy gimmicks, but
> > as they say: pictures can be worth a thousand words (more, IMO). Many
> > other implementations of wiki also support images on pages. The reason
> > it isn't on the Tcl'ers Wiki yet, is that this site can also be copied
> > and browsed locally (with a Tk interface), and I haven't figured out how
> > to best cache images (the entire Tcl'ers Wiki is inside a single file).
>
> I suppose my main gripes with the Wiki are that it is *very* slow, and

Wiki has always been *very* fast for me. It's probably a network
problem between you and Wiki, rather than its design. Hasn't everyone
who has complained about its speed been across the pond?

Don

Andreas Kupries

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to

I am across the pond too, but never had problems with its speed.

--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.westend.com/~kupries/>
-------------------------------------------------------------------------------

Donal K. Fellows

unread,
Apr 22, 1999, 3:00:00 AM4/22/99
to
In article <s6ad80y...@nist.gov>, Don Libes <li...@nist.gov> wrote:
> fell...@cs.man.ac.uk (Donal K. Fellows) writes:
>> I suppose my main gripes with the Wiki are that it is *very* slow, and
>
> Wiki has always been *very* fast for me. It's probably a network
> problem between you and Wiki, rather than its design. Hasn't everyone
> who has complained about its speed been across the pond?

I suspect that the problem is actually related to the other half of
the paragraph (which got snipped.) It is institution[*] *policy*
(enforced with a firewall) for all web traffic to go through caches to
reduce traffic. Given that this is applied across the whole UK Higher
Education sector[**] it makes a big difference to volume (~30%
reduction IIRC) and consequently fees. But it interacts badly with
some sites. It seems that the Wiki is one of these (primarily because
no page is ever cached?)

Many pages don't change all that often (e.g. the formatting rules,)
and so making the Wiki present the image to the world (however it
organises its internals) that it is just an ordinary webserver serving
ordinary files and CGI scripts would be a real bonus.

HTH the wikit crew, as it is something that is quite difficult to test
locally.

Donal.
[* Or possibly even service-provider policy. I've never checked. ]
[** And maybe into the field of Further Education too. ]

Bruce S. O. Adams

unread,
Apr 22, 1999, 3:00:00 AM4/22/99
to

"Donal K. Fellows" wrote:

> I suppose my main gripes with the Wiki are that it is *very* slow, and

> that it seems to be completely incompatible with web caches.
>

I have had no problems with speed on wiki. Perhaps it is down to where you are
connecting from
and what browsers you are using. It certainly seems to be netscape friendly. (For
reference, I
generally connect through a proxy running ftgate to a shared 56K modem).
Regards,
Bruce A.


[snip - sorry]


Reply all
Reply to author
Forward
0 new messages