Wojciech Kocjan <[EMAIL PROTECTED]> writes:

> On 6 Jul 2001, David N. Welton wrote:
> > > #ifdef UNDEFINEDDEFINE
> > > #endif
> > > Ok, I'll check out the code and probably change it a bit...

> > If you don't fix the style, and I end up including the code, I
> > will, as I want the code to look reasonably uniform.  But I would
> > appreciate receiving code that more or less looks like the rest of
> > mod_dtcl:-)

> Ok, I'll do that. That was my style for about 2-3 years, but I'll
> try to improve my 'codewriting' ;-)

It's not a question of 'improving', necessarily - it's a subjective
considerationg, of course.  However, I would like to keep the mod_dtcl
code relatively uniform.

> Yeap. But still, AFAIR the best way is to mmap() it. Also,
> threads+non-blocking sockets on about 10 sockets/thread should be
> optimal - I read on it someplace, maybe /.

What do threads and sockets have to do with reading files?  You're
right that mmap should be faster - is it portable to windows/other
operating systems?

> Anyway, I still claim that it's faster to use memchr() than getc().

Let's see by how much:-)

> > > Also, I'd like to hear opinions from people on this list if <?= and
> > > <?dtcl could be useful for someone except me?
> > Comments?  I don't really like <?=, because it's a special case that
> > makes code harder to read, and less immediate for new users. 

> But it makes it easy to write pages. I use it in ADP, use <?p $var?>
> in dtcl, and I suppose many people find it useful.

You could create a command in Tcl, =, and do <?= $foo ?>, no?:-)

> It's just a nice feature. Nothing more...

I would like to hear other people on this.  Do you want this or not?

-- 
David N. Welton
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
     Personal: http://www.efn.org/~davidw/
         Work: http://www.innominate.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to