Re: [challenge] new mod_perl site
> 3. Download the new mod_perl site source > http://www.apache.org/~stas/site/modperl-site-new.src.tar.gz I've forgotten to include bin/build (which is the same as DocSet/example/bin/build). So I've updated it now. Thanks to Thomas Klausner for the alert. - Also I forgot to mention that if you want to change the color of the widgets, you just need to change [% PROCESS splash/config; splash.images = "$doc.dir.abs_doc_root/images/splash"; splash.fg = 'mauve'; splash.bg = 'lilac'; -%] in tmpl/custom/html/page and tmpl/custom/html/index (need to specify this in one place obviously) See the Splash documentation for more info. Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [challenge] new mod_perl site
> What about an additional requirement: > > The site should be validated sucessfully by validator.w3.org Maybe we should give the horse a chance to catch up to the cart... Once there is a design that people are satisfied with, you are more than welcome to submit patches to fix validation problems. - Perrin
Re: cgi-object not cacheable
> One run of my script takes about 2 seconds. This includes a lot of > database-queries, calculations and so on. about 0.3 seconds are used > just for one command: $query=new CGI; That's really awfully slow. Are you positive it's running under mod_perl? Have you considered using Apache::Request instead of CGI.pm? > This is not a problem of my persistent variables, cause this works > with many other objects like db-handles (cant use Apache::DBI cause > this keeps to many handles opened, so I need to cache and pool on my > own), filehandles etc. Whoa, you can't use Apache::DBI but you can cache database handles yourself? That doesn't make any sense. What are you doing in your caching that's different from what Apache::DBI does? - Perrin
missing directive
Hello We're running a cobalt raq4 and have some problems with the apache configuration. the configuration over the web-interface works all fine, but when i add some lines in the httpd.conf for the mod_perl-things (p.ex. "PerlInitHandler Apache::Reload" & "PerlModule Apache::Registry") and some handlers of myself, a restart succeeds, but with the message: mod_perl: mod_perl: Missing directive at end-of-file chiliasp: module started, version 3.5.2.31 /usr/sbin/httpd and the cobalt-web-interface for server administration isn't available over the ../admin/ adress, which should be rewritten by a rule written in some $PerlConfig-Variable which is filled in a - part of the httpd.conf do you have any hints? i don't know this server really good, but it seems to me that it should be obvious for people working with it ... thanks alot in advance! Thomas Bach <><><><> think karo... bkaro.net
Re: Can't install Apache::Request on Linux
Jonathan Bennett <[EMAIL PROTECTED]> writes:
> Request.xs:40 mod_perl.h: No such file or directory
>
> just after attempting to compile Request.c
libapreq expects to find it using Apache::src->new->inc :
% perl -MApache::src -wle 'print grep {s/^-I//; -f $_ . "/mod_perl.h"}
split / /, Apache::src->new->inc'
/usr/lib/perl5/site_perl/.../auto/Apache/include/modules/perl
> mod_perl.h is present in
> /usr/local/apache/src/modules/perl/
>
> Where do I need to stick the option to make the makefile include the
> correct paths?
>
You might try tinkering with the INC and LIB settings in
Request/Makefile.PL.
--
Joe Schaefer
cgi-object not cacheable
One run of my script takes about 2 seconds. This includes a lot of database-queries, calculations and so on. about 0.3 seconds are used just for one command: $query=new CGI; I tried to cache the retrieved object between several requests by storing to a persistent variable to avoid this long time, but it is not cacheable. (in the meaning of : operations on a cached CGI-object will just produce nothing) This is not a problem of my persistent variables, cause this works with many other objects like db-handles (cant use Apache::DBI cause this keeps to many handles opened, so I need to cache and pool on my own), filehandles etc. any idea ? thnx, peter -- mag. peter pilsl phone: +43 676 3574035 fax : +43 676 3546512 email: [EMAIL PROTECTED] sms : [EMAIL PROTECTED] pgp-key available
Re: [challenge] new mod_perl site
On Tuesday 13 November 2001 11:57, Thomas Klausner wrote: > Hi! > > On Wed, Nov 14, 2001 at 01:31:52AM +0800, Stas Bekman wrote: > > Obviously the site should be very light on graphics, but since you are > > a good web designer you know this and all the other requirements > > already. The only requirement we have is that this is an information > > site, so avoid fancy graphics and god forbid flash splashes :) > - - - snip - - - > Anyway, I think I will give it a try ... Hi: Well, take your time. As soon as I find out from the SuSE list what the path is to Apache on 7.1 to use, I'm goona try out the http://perl.apache.org/embperl/IntroEmbperlObject.pod.2.html Say, there's no deadline on this thing, is there? Tom
Re: [OT] New persistent perl engine
Matt Sergeant wrote: > > It actually wasn't written for web apps. I wrote it for our virus checker, > which is 10K+ lines of perl code, and takes about 0.7s to load, and almost > zero time to process an email, so we needed to eliminate that 0.7s. So, the > benefit of PPerl is it's more generally usable than FastCGI or SpeedyCGI. > > There are downsides, of course, like the fact that the daemon stub is > written in Perl, rather than C. And the forking version doesn't seem to work > (not sure what I've done wrong there), so it's single threaded at the moment > (the forking code is in the distro if anyone wants to try and make it work). > Hey this is a great idea! I particularly like the idea of having it be in pure perl ... one of the drawbacks to CGI::SpeedyCGI I could see was that so much was in C, it seems like it might be hard to port to Win32 one day. If PPerl becomes viable for running web cgis, then it may be that a heavy web app environment like Apache::ASP could one day run under IIS/Win2000 as a pperl CGI !! Sounds cool. I will try to help with this project as time permits, as I am very interested in taking Apache::ASP to other platforms where mod_perl is not necessarily available. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: [challenge] new mod_perl site
Hi! On Wed, Nov 14, 2001 at 01:31:52AM +0800, Stas Bekman wrote: > Obviously the site should be very light on graphics, but since you are > a good web designer you know this and all the other requirements > already. The only requirement we have is that this is an information > site, so avoid fancy graphics and god forbid flash splashes :) What about an additional requirement: The site should be validated sucessfully by validator.w3.org (The current design doesn't, BTW) I know that it is hard to get a page validated there, but IMO there should be more "clean"/standard-compatible websites. I guess you all know the reasons for this, so I won't repeat them here. Anyway, I think I will give it a try ... -- D_OMM O_xyderkes M_echanenhttp://domm.zsi.at M_asteuei
ANNOUNCEMENT: HTML::Template::Expr 0.03
CHANGES - Added register_function() class method add functions globally. (Tatsuhiko Miyagawa) - Fixed broken cache mode. DESCRIPTION This module provides an extension to HTML::Template which allows expressions in the template syntax. This is purely an addition - all the normal HTML::Template options, syntax and behaviors will still work. Expression support includes comparisons, math operations, string operations and a mechanism to allow you add your own functions at runtime. AVAILABILITY This module is available on SourceForge. Download it at: http://prdownloads.sourceforge.net/html-template/HTML-Template-Expr-0.03.tar.gz The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [challenge] new mod_perl site
As David Young has pointed out you can change the style.css in addition to the template changes. the one I've gave to you includes some old classes, which I'll remove, so disregard those. Thanks _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
[challenge] new mod_perl site
This is the boilerplate for the new mod_perl site: http://www.apache.org/~stas/site/boilerplate/ It actually includes a lot of content, which I've ported from the old site and added some new stuff. Even the new mod_perl 2.0 docs. But it's incomplete. Please do not post your likes or dislikes of this boilerplate, but keep on reading. Nathan Torkington was sick of waiting for Messiah to come and redo our site, so he started re-doing it by himself. Since I've planned to merge the documentation project with the site, I've picked it up from Nat and started the DocSet project to make the site autogenerated. The DocSet project is based on the idea used by Template::Toolkit's documentation builder and of course re-using the Splash HTML Widgets library Andy Wardley has developed. This is Pod::HtmlPsPdf's big brother (Pod::HtmlPsPdf is currently used to build the mod_perl guide). Currently it supports HTML and POD as sources and HTML/PS/PDF as an output. More formats will be supported in the future. If you want to get involved see: http://www.template-toolkit.org/mailman/listinfo/template-docset I've revamped the existing site and with help of DocSet provided a consistent look-n-feel and auto-generated navigation. I *did* *not* do a design of the site, and that's where comes the challenge... The Challenge: - If you are a good *web* designer and willing to design our site in return for the eternal fame and major ego boost, or just because you feel like contributing back... we want your design. Obviously the site should be very light on graphics, but since you are a good web designer you know this and all the other requirements already. The only requirement we have is that this is an information site, so avoid fancy graphics and god forbid flash splashes :) It's possible that the current boilerplate at the URL I've posted above is exactly what we need, with possibly a few tweaks. So don't get over your head, change things only if it's really necessary. If nobody sends their designs the posted URL is what you get to use for "eternity" :) If you are interested, read the rules and explanations. Rules: -- The deadline is Monday Nov, 26 2001 (whatever time-zone you are in, I'll check on the next day). All the designs are to be submitted to me. Please send me only the modified source as an attachment and name the package (and the dir it resides in) as modperl-site-fname-lname.tar.gz If you submit more than one version, append the version to the package name. e.g. modperl-site-fname-lname-A.tar.gz Use: Subject: [modperl-site design challenge] fname lname [version] as a subject for your submissions. I'll make the submitted designs available online on Nov, 27. I'm not sure yet how we are going to vote. Is anybody willing to setup a clean voting script (which prevents cheating). I was thinking about take23.org to host the votes... Matt? The submission may include only changes to the existing templates (it's ok to add new templates, the point is to work only with templates). Generating HTML: Before doing any changes, see that you can build the current version. 1. Install Template::Toolkit (use CPAN) 2. Install DocSet. You can get it from here: http://www.apache.org/~stas/site/DocSet-0.03.tar.gz Notice that it's not released on CPAN yet, as it may change the name. This module is discussed here: http://www.template-toolkit.org/mailman/listinfo/template-docset So if something doesn't work, post to this list. You can read the docset archives here: http://www.template-toolkit.org/pipermail/template-docset/ 3. Download the new mod_perl site source http://www.apache.org/~stas/site/modperl-site-new.src.tar.gz 4. Test that you can build the site. Assuming that you've untarred the package into its original dir: % cd modperl-site-new % bin/build -vf in the dst_html dir you will find the generated site. See the README file and DocSet pods for more info, but you don't really need to read these or understand how the builder works to get the design done. Modifying Templates: --- You shouldn't mess with src/ dir, The tmpl/std/ dir includes the standard Splash library of templates, so generally you shouldn't touch this one. But if you see that it generates improper HTML do change it and we will submit the fixes to Andy. To learn how splash templates are called see: http://www.template-toolkit.org/splash/index.html Do play with the templates in the tmpl/custom/ dir. All you have to change is two templates: tmpl/custom/html/index - tmpl used for generating index.html pages tmpl/custom/html/page - tmpl used for generating the rest of the pages and of course you may change the templates these two templates include. If you need help with Template::Toolkit, see: http://www.template-toolkit.org/. At this site you will find a lot of good docs and the pointers the mailing list and its archives. Communications: --- Please try to use the
PPerl --- Some ideas (was Fwd: event-based programming with atwist)
Matt,
From a friend of mine, when he head about PPerl.
--
Godoy. <[EMAIL PROTECTED]>
Escritório de Projetos - Projects Office
Solutions Developer - Conectiva Inc. - http://en.conectiva.com
Desenvolvedor de Soluções - Conectiva S.A. - http://www.conectiva.com.br
msg22402/pgp0.pgp
Description: PGP signature
--- Begin Message ---
Now it seems to be really solid now.
Probably will help (or give some ideas) to PPerl.
http://search.cpan.org/search?dist=Coro
[]'s
Raul Dias
Marc <[EMAIL PROTECTED]> wrote:
>I recently hacked a module named Coro (short for coroutines, similar
>but not the same as threads or perl's faked threads). After using it to
>implement fake continuations (to make damian conway happy, if he ever
>finds out) I thought let's give Event a try (no, not faked this time ;)
>
> use Coro 0.04;
> use Coro::Event;
>
> my $stdin = Coro::Event->io(fd => \*STDIN, poll => 'r');
>
> # read one line from the filehandle. if we were doing non-blocking i/o
> # we could loop inside this function until a complete line has arrived
> sub kbdline {
> $stdin->next; # wait for & fetch next event
> my $x = ; chomp $x; $x;
> }
>
> # this creates a new asynchronous coroutine
> sub keyboard : Coro {
> $| = 1;
> # loop endlessly and fetch commands
> while () {
> print "cmd> "; my $cmd = kbdline;
> print "data> "; my $data = kbdline;
> # maybe read more lines, depending on the command
> print "cmd<$cmd> data<$data>\n";
> print "working...";
> do_timer(after => 1); # wait a second before continuing
> print "done\n";
> }
> }
>
> sub finger : Coro {
> use IO::Socket::INET;
> # is there ANY way to do non-blocking connects with IO::Socket::INET?
> # I don't see how...
> my $io = new IO::Socket::INET PeerAddr => "noc.dfn.de:finger";
> print "connected, sending finger request\n";
> syswrite $io, "trouble\n";
> my $r = Coro::Event->io(fd => $io, poll => 'r');
> my $buf;
> # now assemble the return data
> $r->next while 0 != sysread $io, $buf, 8192, length $buf;
> print $buf;
> }
>
> Coro::Event->main;
>
>it is difficult to get the point across using a small program - the idea
>is to linearize programs, while still using the benefits of a state
>machine. My ideal for perl 6 and high performance servers is to start one
>real (os) thread per cpu and then use event and coroutines to distribute
>work
>
>I still have small problems with the design (localize $_ or not? i am for
>not...), but given that I thought this to be much too complicated for many
>years it was surprisingly easy to implement so far... (yes, there are many
>unresolved logical problems, but it's the first version... 0.05 will be
>much better ;)
>
>I hope you found this posting somewhat entertaining...
>
>--
> -==- |
> ==-- _ |
> ---==---(_)__ __ __ Marc Lehmann +--
> --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
> -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
>The choice of a GNU generation |
> |
>
--- End Message ---
Re: weird update problem
Ahh... like usually, problem is solved after the mail is sent. Problem was, that code that moved things was after the code which told which file to include... so thats why i saw it next time. Thnx anyway :) Viljo Marrandi wrote: > > Hello, > > I have one website which is running on Apache/mod_perl and > Template-Toolkit. There is one piece of code which moves categories > up'n'down. Now the problem is, that when I submit page with parametres > it doesn't show that category has moved, but actually it has. I can see > the change only after I 'hard-refresh' the page again - eg. Shift + > refresh under IE. > > But what's interesting is that the same code works just fine in another > section of same page. .. > > All information is stored in MySQL tables and I use standard DBI in > mod_perl modules to manipulate it. > > All ideas are welcome, I'm kinda... lost in this problem. > > Rgds, > Viljo
weird update problem
Hello, I have one website which is running on Apache/mod_perl and Template-Toolkit. There is one piece of code which moves categories up'n'down. Now the problem is, that when I submit page with parametres it doesn't show that category has moved, but actually it has. I can see the change only after I 'hard-refresh' the page again - eg. Shift + refresh under IE. But what's interesting is that the same code works just fine in another section of same page. .. All information is stored in MySQL tables and I use standard DBI in mod_perl modules to manipulate it. All ideas are welcome, I'm kinda... lost in this problem. Rgds, Viljo
[OT] New persistent perl engine
This may have slipped by most people, but I know the SpeedyCGI discussions sparked quite a bit of conversation/debate earlier this year, so I thought people might be interested here... PPerl is a tool I wrote here at Star for running perl processes persistently, as a daemon. The idea for it was simplicity - both in development and in running it. Not only that, but I couldn't get SpeedyCGI to compile, or the author to respond to me, so I wrote my own. So, it's really easy - just use "pperl" wherever you'd have previously used "perl", even in the shebang line. It actually wasn't written for web apps. I wrote it for our virus checker, which is 10K+ lines of perl code, and takes about 0.7s to load, and almost zero time to process an email, so we needed to eliminate that 0.7s. So, the benefit of PPerl is it's more generally usable than FastCGI or SpeedyCGI. There are downsides, of course, like the fact that the daemon stub is written in Perl, rather than C. And the forking version doesn't seem to work (not sure what I've done wrong there), so it's single threaded at the moment (the forking code is in the distro if anyone wants to try and make it work). Anyway, let me know if this interests anyone. It's called PPerl, and it's on CPAN. Matt. -- <:->Get a smart net _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
