Just bite the bullet already and use the parser! It won't be 1.0
until you use a parser, no matter what, because this is only one
syndrome of the lack of a parser among many syndromes.
Tavis Rudd <[EMAIL PROTECTED]> wrote:
> On Tuesday 29 May 2001 23:34, Ian Bicking wrote:
> > To be safe, any us
On Tuesday 29 May 2001 23:34, Ian Bicking wrote:
> To be safe, any use of this syntax in a WYSIWYG editor
> should use explicit closures -- newlines are meaningless
> in HTML, and you never can be sure how the editor will
> treat them, or preserve them.
Good point. You raised this before, but I'd
I tightened up the verbose output of the app server (Threaded only; not
Async) as described earlier. I ended up putting the request URI on the
second line with duration for even easier matching.
I don't currently have PATH_INFO in there, or any configuration options,
both of which need to be l
Tavis Rudd <[EMAIL PROTECTED]> wrote:
> On Tuesday 29 May 2001 23:11, Chuck Esterbrook wrote:
>
> > Well, for what it's worth, I prefer ;
> > I think ;# looks awkward at best and confusing at worst.
>
> I agree with you about that. It's just a pain in the ass to
> switch to a single char closur
At 11:31 PM 5/29/2001 -0700, Tavis Rudd wrote:
>I agree with you about that. It's just a pain in the ass to
>switch to a single char closure - i.e. create
>a parser that would be able to handle all the different types of
>directives in addition to $placeholders. Adding a new directive
>is current
On Tuesday 29 May 2001 23:11, Chuck Esterbrook wrote:
> Well, for what it's worth, I prefer ;
> I think ;# looks awkward at best and confusing at worst.
I agree with you about that. It's just a pain in the ass to
switch to a single char closure - i.e. create
a parser that would be able to handl
At 01:11 AM 5/30/2001 -0500, Ian Bicking wrote:
>Yeah. *I* just *think* it should be #. I don't actually remember
>quite what it is either.
Well, for what it's worth, I prefer ;
I think ;# looks awkward at best and confusing at worst.
___
Webware-d
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> Isn't the terminator for TS #; ?
> Or was it ;# ? I forget...
Yeah. *I* just *think* it should be #. I don't actually remember
quite what it is either.
Ian
___
Webware-devel mailing list
[EMAIL PROT
Just a minor update. There is a new CheckInterval setting that defaults to
100. The value is passed to sys.setcheckinterval().
As shown in earlier benchmarks, this improves WebKit's performance by a
worthwhile amount. Higher values achieve almost nothing.
100 is also the same value baked into
On Tuesday 29 May 2001 22:56, Chuck Esterbrook wrote:
> Isn't the terminator for TS #; ?
> Or was it ;# ? I forget...
Directive closures are the end of the line or ;# if you need
to close it explicitly. I don't think many people will ever use
the explicit ;# closure unless they're doing some
On Tuesday 29 May 2001 22:57, Mike Orr wrote:
> > On Tuesday 29 May 2001 22:07, Ian Bicking wrote:
> > I meant the ## comments in TemplateServer rather than
> > those Python. Anyway, I think I also prefer sticking
> > with # for everything except for $placeholders. It's
> > consistent and it def
On Tuesday 29 May 2001 22:59, Ian Bicking wrote:
> #comment is readable, and I know non-programmers really
> like things they can read aloud, as opposed to lots of
> punctuation. I suggest it for their benefit.
Fair enough. I don't see any harm in allowing both
#comment and ##. It's dead simple
At 12:49 AM 5/30/2001 -0500, Ian Bicking wrote:
>Well, if ## comments seem odd, how about:
>
>#comment
>
>That's easy, easy to read, and doesn't propogate funny symbols. I
>think I considerably prefer it to ##, especially since I prefer # as a
>terminator too, since that feels balanced to me.
I
Tavis Rudd <[EMAIL PROTECTED]> wrote:
> ## comes from Velocity as well. #comment is symmetrical
> with the other directives, however. But as # is a comment
> in Python you could say that ## is a synonym for #comment ;)
#comment is readable, and I know non-programmers really like things
they can
On Tue, May 29, 2001 at 10:36:11PM -0700, Tavis Rudd wrote:
> On Tuesday 29 May 2001 22:07, Ian Bicking wrote:
> > I think # works well. It's big, even in a proportional
> > font. It's not used much, #1 isn't that common, and the
> > only HTML place is anchors. You aren't like Python
> > anyway
On Tuesday 29 May 2001 22:49, Ian Bicking wrote:
> Tavis Rudd <[EMAIL PROTECTED]> wrote:
> Well, if ## comments seem odd, how about:
> #comment
too much to type. I like ## because it makes escaping
#directives dead simple and it allows you to use decorative
comments like
##
or
On the HTTPServer thread... wouldn't it be easiest to make a
HTTPServerAdapter? Or would this imply a speed hit for the socket
connection that was the point of using the embedded HTTP server in the
first place?
Also, eventually there *is* going to be a FTPServerAdapter... if
someone else doesn't
Tavis Rudd <[EMAIL PROTECTED]> wrote:
> On Tuesday 29 May 2001 22:07, Ian Bicking wrote:
> > I think # works well. It's big, even in a proportional
> > font. It's not used much, #1 isn't that common, and the
> > only HTML place is anchors. You aren't like Python
> > anyway, since $ isn't meanin
On Tuesday 29 May 2001 22:07, Ian Bicking wrote:
> I think # works well. It's big, even in a proportional
> font. It's not used much, #1 isn't that common, and the
> only HTML place is anchors. You aren't like Python
> anyway, since $ isn't meaningful in Python.
I meant the ## comments in Temp
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> >Probably. But I think a good English description is useful too, and
> >general enough to be all-encompassing, flexible enough to be as formal
> >as you desire. And it's easy to inline ASCII representations of the
> >description, and I suppose possib
Hi,
just been thinking about the #stop directive we
stole from Velocity. Seeing as I've added a
#restart directive, how about using #verbatim instead?
#verbatim
Text to be escaped from TemplateServer
$varToBeIgnored
#/verbatim
like \begin{verbatim}...\end{verbatim} in LaTeX.
vs.
#stop
Text t
Tavis Rudd <[EMAIL PROTECTED]> wrote:
> There is one point about "What should it look like?" that might
> be worthwhile looking at again. In Velocity, WebMacro, and
> thus TemplateServer, all directives begin with # and macro
> calls are in the form #macroName(). Last night, Mike asked
> if t
On Tuesday 29 May 2001 06:40, Chuck Esterbrook wrote:
> BTW I CCed webware-devel where these discussions on
> templating design are taking place. Although recently
> they have quieted down as we have phased out of "What
> should it look like?" to "Who's implementation is doing
> what?".
There is
Sounds good! How about displaying the PATH_INFO
as well since this is fairly critical to WebKit and can help
pin down problems with the config of the adaptors?
On Tuesday 29 May 2001 05:11, you wrote:
> The WebKit app server in Verbose mode prints something
> like this:
>
> BEGIN REQUEST
> Tue
On Tuesday 29 May 2001 09:16, Geoff Talvola wrote:
> I'll bet some of the problems in AsyncThreadedHTTPServer
> would be easier to fix using ThreadedAppServer as the
> base instead of Async, just because it's simpler. It'll
> just take somebody's time to do the rewrite.
There's a very simple ver
At 08:08 PM 5/29/2001 -0500, Ian Bicking wrote:
>Python code is well-structured and far richer than what a spreadsheet
>can represent, because it structures it in a grammar. No novice is
>ever going to edit a model description, so it's no hinderance to use.
I've had novices read MK models and gl
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> >The whole thing is just 248 lines, there's not a lot there to share
> >anyway. The most useful might be the marshalling. mod_webkit uses
> >Python's marshalling functions, I think. I just recreated the small
> >portion needed to send the request, w
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> >I don't like spreadsheets. I code in Emacs. I read my mail in
> >Emacs. I love Emacs. I never ever use spreadsheets, why use them for
> >this one thing?
>
> Because Emacs does not and never will contain the entire world. It doesn't
> do diagrams
At 06:24 PM 5/29/2001 -0500, Ian Bicking wrote:
>Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> > At 01:40 PM 5/29/2001 -0500, Ian Bicking wrote:
> > >Though if IE had just kept the HTMLINPUT tag, that would have helped a
> > >lot too. It was such a good idea. Sigh.
> >
> > What was that? I never
I've been experimenting with the retry logic in adapters. It looks like it
is actually very difficult to get it to work exactly right and not lose any
requests when you're restarting the server.
Suppose the app server isn't running. The adapter calls sock.connect() to
connect to the server.
At 05:59 PM 5/29/2001 -0500, Ian Bicking wrote:
>Well, retry is just a code structure issue, not something that could
>fit in a library. It could be added easily enough.
Retrying has 2 settings: How many times to retry and how long to wait in
between. Code is required to read those settings.
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> At 01:40 PM 5/29/2001 -0500, Ian Bicking wrote:
> >Though if IE had just kept the HTMLINPUT tag, that would have helped a
> >lot too. It was such a good idea. Sigh.
>
> What was that? I never heard of it.
Apparently for a beta (5.0 beta, maybe) the
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> At 01:54 PM 5/29/2001 -0500, Ian Bicking wrote:
> >If you have an auxiliary directory, how about putting CAdapter in it?
> >It really is a lot faster than the Python version, and easier to
> >install than mod_python|snake. I've used it happily for qui
At 02:16 PM 5/29/2001 -0500, Ian Bicking wrote:
>The webkit rc script includes /etc/rc.d/init.d/functions. My Debian
>system doesn't have such a file. It seems like the only function used
>is "success". If that definition was inlined, it would make it more
>portable.
>
>But otherwise it works g
At 01:40 PM 5/29/2001 -0500, Ian Bicking wrote:
>Though if IE had just kept the HTMLINPUT tag, that would have helped a
>lot too. It was such a good idea. Sigh.
What was that? I never heard of it.
>It's quite improper, but it works, and it gets around the fact that
> is paragraph-level.
Oh,
At 11:20 AM 5/29/2001 -0700, Donovan Preston wrote:
>Comments welcome, especially if there is a better way to do this.
Currently I do this like so:
python Launch.py ThreadedAppServer > Logs/stdioerr.log 2>&1 &
e.g., I know that the op sys can redirect stdout and stderr so instead of
adding yet
At 01:54 PM 5/29/2001 -0500, Ian Bicking wrote:
>If you have an auxiliary directory, how about putting CAdapter in it?
>It really is a lot faster than the Python version, and easier to
>install than mod_python|snake. I've used it happily for quite a while
>now.
The only question I have at this p
The webkit rc script includes /etc/rc.d/init.d/functions. My Debian
system doesn't have such a file. It seems like the only function used
is "success". If that definition was inlined, it would make it more
portable.
But otherwise it works good.
Ian
_
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> >In the case of HTML/XML, such faithfullness is a significant
> >advantage as this would keep open the option to manipulate
> >templates (HTML/XML + extra template mark-up) with any tool in
> >the ever-growing world of XML tools. (I am quite surprised
Chuck, I agree with your suggestion for the verbose mode output, since
the most relevant information is the URL. Since most people probably use
the console output for debugging via print statements (as I do),
reducing the amount of visual clutter while still retaining the
important information
At 12:38 PM 5/29/01 -0400, Chuck Esterbrook wrote:
>At 12:16 PM 5/29/2001 -0400, Geoff Talvola wrote:
>>I'll bet some of the problems in AsyncThreadedHTTPServer would be easier
>>to fix using ThreadedAppServer as the base instead of Async, just because
>>it's simpler. It'll just take somebody's
At 12:16 PM 5/29/2001 -0400, Geoff Talvola wrote:
>I'll bet some of the problems in AsyncThreadedHTTPServer would be easier
>to fix using ThreadedAppServer as the base instead of Async, just because
>it's simpler. It'll just take somebody's time to do the rewrite.
[snip]
>No objection, just
At 11:26 AM 5/29/01 -0400, Chuck Esterbrook wrote:
>At 08:20 AM 5/29/2001 -0700, Mike Orr wrote:
>>But AsyncThreadedHTTPServer is also "experimental" and has its own
>>problems. (Remember how it timed out whenever I tried to log in to a
>>protected page?) So why not just give AsyncThreadedAppSer
At 08:20 AM 5/29/2001 -0700, Mike Orr wrote:
>But AsyncThreadedHTTPServer is also "experimental" and has its own
>problems. (Remember how it timed out whenever I tried to log in to a
>protected page?) So why not just give AsyncThreadedAppServer the
>same status? Then just change the AppServer s
On Tue, May 29, 2001 at 10:57:30AM -0400, Geoff Talvola wrote:
> At 07:19 AM 5/29/01 -0400, Chuck Esterbrook wrote:
> >At 03:05 AM 5/29/2001 +0200, Tom Schwaller wrote:
> >>AsyncThreadedAppServer (5.1-rc3) crashes with
> >[snip]
> >>ThreadedAppServer seems to work ok..
> >
> >Seems like Async:
> >
At 07:19 AM 5/29/01 -0400, Chuck Esterbrook wrote:
>At 03:05 AM 5/29/2001 +0200, Tom Schwaller wrote:
>>AsyncThreadedAppServer (5.1-rc3) crashes with
>[snip]
>>ThreadedAppServer seems to work ok..
>
>Seems like Async:
> - has problems in general
> - is often slower than plain Threa
At 02:50 PM 5/29/2001 +0200, Ruggier, Mario wrote:
>The (rather terse) discussion at the beginning of xyaptu.py tries
>to list the main requirements for something like xyaptu. Other than
>**simplicity**, an important feature is that the extra template-mark-up
>in a html/xml document must itself no
The WebKit app server in Verbose mode prints something like this:
BEGIN REQUEST
Tue May 29 08:00:46 2001
receiving request from
request has keys: format, time, environ, input
request uri = /webkit/monkey/StyleSheet.css
connection closed.
0.06 secs
END REQUEST
Note that sometimes these messages
At 07:54 AM 5/29/2001 -0400, Geoff Talvola wrote:
>Launch.py doesn't always get used. For instance, OneShot.cgi and
>ThreadedAppServerService.py don't use launch, I think. Maybe _those_ need
>the path fix, not Cookie?
Good point. Perhaps we need to move this to a FixPath.py which gets used by
At 10:14 PM 5/25/2001 -0400, Jay Love wrote:
>I had the same problem, and used the same fix. Actually this is where we
>went off on a tangent a while back about paths. I actually ended up
>fixing the path issues in Launch instead of Cookie.py. Maybe that would
>be a more appropriate place to
At 03:05 AM 5/29/2001 +0200, Tom Schwaller wrote:
>AsyncThreadedAppServer (5.1-rc3) crashes with
[snip]
>ThreadedAppServer seems to work ok..
Seems like Async:
- has problems in general
- is often slower than plain Threaded
- adds more code and complexity and maintenanc
51 matches
Mail list logo
