guile-user
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Web development

From: Alejandro Forero Cuervo
Subject: Re: Web development
Date: Thu, 15 Nov 2001 18:39:09 -0500
User-agent: Mutt/1.2.5i 
Hey.  :)

    > Now what other wrapper function do you want me to write!  :)
    
    Just the modules and .scm handler ;-)

Working on 'em!  Heheh.

Hmm, should I make the defaults for the handler handle ".scm" files or
".guile" files?  I guess I'll go with ".guile".

It'd be nice to see ".guile" start popping up in URLs rather than .pl
or .cgi or .php or .asp.  :)

    I suppose I ought to know how to test for that, but it misses me
    at 3am :-/

I guess you have a point.  Heh.

What is the standard thing to return when in C one would return NULL?
Or should I throw an exception?  Hmm.

    I haven't checked whether automated tools like w3c's Tidy can cope
    with xhtml extended in this way, though.

Hmm, I wouldn't expect Tidy to cope with HB's code directly, just like
I wouldn't expect it to cope with C code that generates HTML.

I can't think of a way to use Tidy, for example, to analyze whether
the following code is correct (without executing the code, obviously):

    :out main
    <html><body><+header.title> Foobar<+header./title><+closeup>
    :

    :set closeup
    </body></html>
    :

    :set header.title
    <p><font size=+1><b>Header:</b>
    :

    :set header./title
    </font></p>
    :

You can't throw Tidy at the main object nor, obviously, at the header
or the closeup objects.

On the other hand, in HB's mailing list we (specially Vladimir Támara
and I) discussed about this already and concluded that it would be
nice if one could tie Tidy to have it automatically parse the output
produced by HB (the results of executing the code).  You could take a
look at (sorry, it's in spanish)
    <http://groups.yahoo.com/group/hb-usr/message/111> .

    [benchmarks] would be interesting reading, especially for others
    here.

My first extremely simple tests shown that, running under CGI in my
slow machine, Perl can handle 37.25 requests per second, Guile 2.85
and HB 1.91.  I'm surprised by how much Perl outperformed Guile and
HB.  As I'm still optimizing late changes I have done to HB (which I
have not commited to CVS), I would expect HB's performace to improve.
By the way, the tests were done in GNU/Linux 2.4.12 with Apache and ab
sending 500 requests to each of the CGIs at individual times.  The
files were very similar and the HB file had both code in Perl and
Guile (and the HB interpreter I used depends on a lot of shared
objects: pthreads, postgresql client, mysql client, guile, perl, ...).
Now I need to make the interesting tests: what happens in serious
scenarios, not CGI: mod_perl, HB daemon and some sort of non-HB Guile
option (such as mod_guile).

I'll keep you updated once I get to make SERIOUS benchmarks.  :)  I
think I'll include other engines such as PHP and publish ALL the
information (such as the code used) if time permits.

    Well, this is another interesting question: at what level does HB
    cache objects, if at all?

Answering this question would take me by far more time than I
currently have.  :(

The answer would first state that none of this optimizations have been
performed to HB yet (other than extremely simple optimizations such as
keeping caches of information in hashes, only parsing .hb files once
as long as they don't get discarded from memory due to not getting use
in long amounts of time, etc.) and then I would explain you all the
algorithms for optimizations (distantly comparable to those of
Makefiles, with lists of functions associated to each of HB's
primitives but ... the devil is in the details) that I have in mind.

Thanks.  :)

Alejo.
http://bachue.com/alejo

--
The mere formulation of a problem is far more essential than its solution.
      -- Albert Einstein.

$0='!/sfldbi!yjoV0msfQ!sfiupob!utvK'x44;print map{("\e[7m \e[0m",chr ord
(chop$0)-1)[$_].("\n")[++$i%77]}split//,unpack'B*',pack'H*',($F='F'x19).
"F0F3E0607879CC1E0F0F339F3FF399C666733333CCF87F99E6133999999E67CFFCCF3".
"219CC1CCC033E7E660198CCE4E66798303873CCE60F3387$F"#Don't you love Perl?

Attachment: pgplOrY_oWZZz.pgp
Description: PGP signature

reply via email to
[Prev in Thread] Current Thread [Next in Thread]