my $var at file scope and __DATA__ sections under mod_perl
I've had a little bit of a look, but can't
find anything in the mod_perl guide about this. Basically it seems to me that
'my' variables at the package level don't retain their value under
mod_perl.
For instance, consider the following
mod_perl handler.
package My::Module;
my $var;
sub handler {
warn($var ||
'blah');
$var =
'test';
}
Each time, the warn is for 'blah' because
the value 'test' is never retained in $var. Is this intended behaviour?
Personally I don't actually do this myself, but the module MIME::Types does, and
it's causing it to break badly.
Actually, it's a bit deeper than that.
MIME::Types does this:
my %list;sub new(@) { (bless {},
shift)->init( {@_} ) }
sub init($){ my ($self,
$args) = @_;
unless(keys %list) { local
$_;
while()
{ s/\#.*//;
next
if m/^$/;
...
What I'm finding is that it ends up running
the loop everytime because (keys %list) == 0 always. Now in theory this should
work, it would just be a performance annoyance. But it doesn't, if I change the
code to
{ local
$_;
while()
{ s/\#.*//;
warn($_);
next
if m/^$/;
...
I end up seeing in my logs...
[Mon Jan 14 13:47:01 2002] null: type:
application/index.response[Mon Jan 14 13:47:01 2002] null: type:
application/index.vnd[Mon Jan 14 13:47:01 2002] null: type:
application/iotp[Mon Jan 14 13:47:01 2002] null: type:
application/ipp[Mon Jan 14 13:47:01 2002] null: type: applicati at
/usr/local/lib/perl5/site_perl/5.6.1/MIME/Types.pm line 75, line
30.
Weird, it's like the
handle just mysteriously ran out of data halfway
through reading from it. Does anybody have any idea what's going on here. What's
the best idea for fixing a module like this, change all:
my $var;
to
usr vars qw($var);
and submit a patch?
Rob
Re: segfault when using PerlRequire
> I assume that you use Apache DSO. I think that you need to rebuild your > perl with -Ubincompat5005. I cannot see the value of bincompat5005 in > your 'perl -V' > http://perl.apache.org/guide/install.html#When_DSO_can_be_Used Still cores after explicit -Ubincompat5005, I'm fairly certain I answered "NO" to that question. Thanks for pointing me to the guide, I'm due for a refresher reading from top to bottom. John [EMAIL PROTECTED]
Re: segfault when using PerlRequire
John D Groenveld wrote: > I hesitate to post this because I haven't kept up with my reading. I did > do several searches of my 28K message modperl mail folder and the list > archives. > > My httpd.conf reads... > LoadModule perl_module /opt/apache/libexec/libperl.so > #PerlModule Apache::Status > PerlRequire /home/stevens.1/apache-perl/conf/startup.pl > > If I uncomment the PerlModule config, then no core dump. > If I downgrade to perl-5.0.3, then no core dump. > If I Configure -Uuselargefiles, I still core dump. > > Solaris bug, Perl bug, modperl bug, Apache bug, or driver error? I assume that you use Apache DSO. I think that you need to rebuild your perl with -Ubincompat5005. I cannot see the value of bincompat5005 in your 'perl -V' http://perl.apache.org/guide/install.html#When_DSO_can_be_Used > Thanks, > John > [EMAIL PROTECTED] > > gdb /opt/apache/bin/httpd > GNU gdb 5.0 > Copyright 2000 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-pc-solaris2.7"... > (gdb) run -d /home/stevens.1/apache-perl -X > Starting program: /opt/apache/bin/httpd -d /home/stevens.1/apache-perl -X > > Program received signal SIGSEGV, Segmentation fault. > 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libper > l.so > (gdb) bt > #0 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li > bperl.so > #1 0xdf7eb859 in Perl_sv_upgrade () from /opt/perl/lib/5.6.1/i86pc-solaris/COR > E/libperl.so > #2 0xdf7ba53a in Perl_pad_allocmy () from /opt/perl/lib/5.6.1/i86pc-solaris/CO > RE/libperl.so > #3 0xdf7a5f29 in Perl_yylex () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/lib > perl.so > #4 0xdf7b7f4f in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l > ibperl.so > #5 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe > rl.so > #6 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR > E/libperl.so > #7 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari > s/CORE/libperl.so > #8 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li > bperl.so > #9 0xdf79b772 in Perl_call_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l > ibperl.so > #10 0xdf79eacb in S_call_list_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CO > RE/libperl.so > #11 0xdf79e743 in Perl_call_list () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE > /libperl.so > #12 0xdf7c37eb in Perl_newATTRSUB () from /opt/perl/lib/5.6.1/i86pc-solaris/COR > E/libperl.so > #13 0xdf7c0636 in Perl_utilize () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l > ibperl.so > #14 0xdf7b8d1a in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l > ibperl.so > #15 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe > rl.so > #16 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR > E/libperl.so > #17 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari > s/CORE/libperl.so > #18 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li > bperl.so > #19 0xdf79bb92 in Perl_eval_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l > ibperl.so > #20 0xdf546147 in perl_do_file () from /opt/apache/libexec/libperl.so > #21 0xdf5461f2 in perl_load_startup_script () from > /opt/apache/libexec/libperl.so > #22 0xdf540f93 in perl_cmd_require () from /opt/apache/libexec/libperl.so > #23 0x805e15b in invoke_cmd () > #24 0x805e629 in ap_handle_command () > #25 0x805e6cb in ap_srm_command_loop () > #26 0x805ed93 in ap_process_resource_config () > #27 0x805f718 in ap_read_config () > #28 0x806a26b in standalone_main () > #29 0x806abf0 in main () > #30 0x8057bf3 in _start () > > perl -V > Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: > Platform: > osname=solaris, osvers=2.7, archname=i86pc-solaris > uname='sunos stevens 5.7 generic_106542-18 i86pc i386 i86pc ' > config_args='-Dprefix=/opt/perl -Dcc=gcc -Duseshrplib -Uusemymalloc' > hint=recommended, useposix=true, d_sigaction=define > usethreads=undef use5005threads=undef useithreads=undef > usemultiplicity=undef > useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef > use64bitint=undef use64bitall=undef uselongdouble=undef > Compiler: > cc='gcc', ccflags ='-fno-strict-aliasing -I/opt/gnu/include > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', > optimize='-O', > cppflags='-fno-strict-aliasing -I/opt/gnu/include' > ccversion='', gccversion='2.95.3 20010315 (release)', > gccosandvers='solaris2.7' > intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 > d_longlong=define, longlongsize=8, d_lo
Re: Modperl 2.0 error
The Doctor wrote: > On Sat, Jan 12, 2002 at 10:00:04AM -0600, Randy Kobes wrote: > >>On Sat, 12 Jan 2002, The Doctor wrote: >> >> >>>Why in this beta am I getting: >>> >>> >>>Script started on Sat Jan 12 02:42:20 2002 >>>doctor.nl2k.ab.ca//usr/source/modperl-2.0$ make cd >>>"src/modules/perl" && make cc -c >>>-I/usr/source/modperl-2.0/src/modules/perl >>>-I/usr/source/modperl-2.0/xs -I/var/www/include >>>-fno-strict-aliasing -I/usr/local/include >>>-DMOD_PERL -O2 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC >>>-I/usr/libdata/perl5/i386-bsdos/CORE Lock.c In file >>>included from Lock.xs:26: >>>/usr/source/modperl-2.0/xs/APR/Lock/APR__Lock.h:6: >>>syntax error before `apr_lockmech_e' >>> >>Hi, >>Are you using the latest Apache-2 and modperl-2 cvs >>sources? > Yes. For modperl 2.0 you *always* need to get the latest cvs version of httpd-2.0. If you use perl 5.7.2 you also *always* need to get the latest bleadperl. What you saw is the change in httpd 2.0's API, which was adjusted in mod_perl 2.0. in some cases you need to run: % make source_scan If the maps weren't updated yet in cvs. and then run perl Makefile.PL again. _ 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: kylix: rad!
> > On Sun, 13 Jan 2002, brian moseley wrote: > > Kylix is, as I understand it, something much closer to original Delphi aim > of programming without coding. I'm not saying it wouldn't be neat if you > could do Kylix for Perl. I'm just saying I don't think it would be a > fantastic success. So, yeah, I'm agreeing with Perrin, but I don't think > that makes me some kind of horrible elitist. > Slashdot and Freshmeat ran a story on the weekend about the Borland/Kylix license. Pretty draconian stuff. http://freshmeat.net/articles/view/369/ -- Danny Aldham Providing Certified Internetworking Solutions to Business www.postino.com E-Mail, Web Servers, Web Databases, SQL PHP & Perl
DECLINED unless 'text/html' but images never make it
I've a script (controlled by a directive) that wraps a standard header and footer around an HTML page I've this at the top of my script: my $r = shift; return DECLINED unless ($r->content_type() eq 'text/html'); but any images that may be inline never make it to the browser (also, if I explicitly call the image in question it never makes it to the browser). Apache gives a 200 status code for these requests in the access log but Netscape 6.2 just sits there and IE returns a 'Cannot find server...' error. Any ideas, where to start looking, etc.? --rjm--
Re: kylix: rad!
On Mon, 14 Jan 2002, Gunther Birznieks wrote: > OK, I learned mod_perl, now where are my hot chicks! :) no, no, you have to pledge the frat! > I think a UI tool would help a bit, but it wouldn't > necessarily solve the hard part of mod_perl which is the > lack of Interpreter cleanup between invocations. PHP and > ASP clear their variables at the start so it seems > harder for applications to overwrite each other and > cause weird subtle bugs. > > To some degree, the nature of mod_perl "feels like" it > makes it harder. true, altho it can be said that persistent state is part of the nature of server programming, and whether you use a tool to generate an app or code it all by hand, you have to learn to exist according to that nature. you can certainly write php code that scopes its variables properly, uses disk- and shmem-based configuration and persistence mechanisms rather than global variables, etc. but you don't have to, cos php bends over backwards to make the world a very forgiving place. i think that best practices should be enforced by the environment. i don't think it's inconsistent to create tools that make a developer's job "easier" (enabling him to speed up the implementation lifecycle) and that also enforce best practices. > A point to note... even though we give out free Perl and > Java applications, we feel that even our own config > files are large and therefore daunting for beginners so > we have been doing R&D to come up with a web interface > to create config files for MVC based web apps. A UI is > not what we want because we'd like people to go through > the wizard and then be able to download a pre-packaged > app. web and desktop uis are all guis, right? hell, emacs jde is an ide/gui. it shouldn't be a huge technical challenge to design an application that can have multiple types of gui layered onto it. i built my last little project exactly that way - with a web interface and a command line interface. mvc helped immensely with that. > I Think making things "easier" is always a "noble" > effort but it's not always clear until you try, what is > truly easier. 1 size doesn't usually fit all. Many peple > like IDEs, many people hate them... yah. i don't really feel very comfortable in them myself. i wasn't suggesting that i was going to build this tool myself; i just thought i'd share the idea. because given the number of gui tools that exist, and the testimony of users, it's clear that at last some people find those tools useful. subject line aside, the idea/opinion that really got me in this thread was "mod_perl is not for less/non experienced programmers". that may be the reality today, but it doesn't have to be by nature. it's like we were talking about on #modperl yesterday. somebody wondered why php applications tend to sport prettier/cleaner/better ui's than perl applications. i think it's cos the php community is more design oriented, specifically because the environment is so conducive to less experienced programmers getting stuff done. if you were a designer sitting down to do your first application, which would you choose - php or perl+mason/tt/whatever? you can go to php.net and see a comprehensive searchable manual of all core apis. you don't have to install anything to be able to send an email or connect to a database. you don't have to look at many web sites - just one (maybe two, if you consult phpbuilder for tips and tricks). you can store data in a web session with 2 function calls. you can reasonably make a dynamic page within 30 seconds of your admin telling you that php is installed in the web server. contrast that with what's available for mod_perl, mason, tt, etc. all well documented, but at a lower level technically. you have to ask your admin to install DBI and MIME-tools (or figure out how to install them into your home dir). you have to figure out how to cause registry scripts or mason pages to be executed (and you have to install mason). you have to write wrapper code to rig up a session framework (and you have to install session modules). etc. the bar is higher for mod_perl and friends. you have to read and understand many more concepts in order to make a hello world web page. you can't be a 9th level designer/1st level coder.
perlio
All my perl-5.0.3 installs have useperlio=define d_sfio=undef I recall that this was to fix problems with early modperl's and print methods. Is there any reason to use the perlio abstraction if I'm not using AT&T's sfio? John [EMAIL PROTECTED]
Re: kylix: rad!
At 06:16 AM 1/14/2002, brian moseley wrote: >On Sun, 13 Jan 2002, Sam Tregar wrote: > > > On Sat, 12 Jan 2002, Perrin Harkins wrote: > > > > > Well, does this product actually have any users to compete for? GUI > > > builders usually don't work for anything but the most trivial websites > > > that could be written in anything and do fine. People seem to come to > > > mod_perl because they need more performance or more control than they > > > can get from CGI. > > > > Agree. > >you know, i think it's this attitude, or a more insidious >version of it, that keeps mod_perl from being as ubiquitous >as php. it's like having to pledge the frat before you can >get the hot chicks. i, for one, would like to see more >people getting interested in making it easy for people who >don't practice black magic to take advantage of mod_perl. OK, I learned mod_perl, now where are my hot chicks! :) I think a UI tool would help a bit, but it wouldn't necessarily solve the hard part of mod_perl which is the lack of Interpreter cleanup between invocations. PHP and ASP clear their variables at the start so it seems harder for applications to overwrite each other and cause weird subtle bugs. I guess there is PerlRun (but it's not true cleanup) or PerlRestart, but that's really slow To some degree, the nature of mod_perl "feels like" it makes it harder. A UI would help though especially if it had a debugger that learned when attached to a given httpd process what variables were being preserved and reused over and over again... so you could trace those things down. A point to note... even though we give out free Perl and Java applications, we feel that even our own config files are large and therefore daunting for beginners so we have been doing R&D to come up with a web interface to create config files for MVC based web apps. A UI is not what we want because we'd like people to go through the wizard and then be able to download a pre-packaged app. I Think making things "easier" is always a "noble" effort but it's not always clear until you try, what is truly easier. 1 size doesn't usually fit all. Many peple like IDEs, many people hate them... Later, Gunther
segfault when using PerlRequire
I hesitate to post this because I haven't kept up with my reading. I did do several searches of my 28K message modperl mail folder and the list archives. My httpd.conf reads... LoadModule perl_module /opt/apache/libexec/libperl.so #PerlModule Apache::Status PerlRequire /home/stevens.1/apache-perl/conf/startup.pl If I uncomment the PerlModule config, then no core dump. If I downgrade to perl-5.0.3, then no core dump. If I Configure -Uuselargefiles, I still core dump. Solaris bug, Perl bug, modperl bug, Apache bug, or driver error? Thanks, John [EMAIL PROTECTED] gdb /opt/apache/bin/httpd GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-pc-solaris2.7"... (gdb) run -d /home/stevens.1/apache-perl -X Starting program: /opt/apache/bin/httpd -d /home/stevens.1/apache-perl -X Program received signal SIGSEGV, Segmentation fault. 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libper l.so (gdb) bt #0 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #1 0xdf7eb859 in Perl_sv_upgrade () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #2 0xdf7ba53a in Perl_pad_allocmy () from /opt/perl/lib/5.6.1/i86pc-solaris/CO RE/libperl.so #3 0xdf7a5f29 in Perl_yylex () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/lib perl.so #4 0xdf7b7f4f in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #5 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe rl.so #6 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #7 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari s/CORE/libperl.so #8 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #9 0xdf79b772 in Perl_call_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #10 0xdf79eacb in S_call_list_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CO RE/libperl.so #11 0xdf79e743 in Perl_call_list () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE /libperl.so #12 0xdf7c37eb in Perl_newATTRSUB () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #13 0xdf7c0636 in Perl_utilize () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #14 0xdf7b8d1a in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #15 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe rl.so #16 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #17 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari s/CORE/libperl.so #18 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #19 0xdf79bb92 in Perl_eval_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #20 0xdf546147 in perl_do_file () from /opt/apache/libexec/libperl.so #21 0xdf5461f2 in perl_load_startup_script () from /opt/apache/libexec/libperl.so #22 0xdf540f93 in perl_cmd_require () from /opt/apache/libexec/libperl.so #23 0x805e15b in invoke_cmd () #24 0x805e629 in ap_handle_command () #25 0x805e6cb in ap_srm_command_loop () #26 0x805ed93 in ap_process_resource_config () #27 0x805f718 in ap_read_config () #28 0x806a26b in standalone_main () #29 0x806abf0 in main () #30 0x8057bf3 in _start () perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=solaris, osvers=2.7, archname=i86pc-solaris uname='sunos stevens 5.7 generic_106542-18 i86pc i386 i86pc ' config_args='-Dprefix=/opt/perl -Dcc=gcc -Duseshrplib -Uusemymalloc' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/opt/gnu/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -I/opt/gnu/include' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='solaris2.7' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags ='-L/opt/gnu/lib -R/opt/gnu/lib ' libpth=/opt/gnu/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -lgdbm -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: d
Re: kylix: rad!
On Sun, 13 Jan 2002, brian moseley wrote: > altho kylix was discussed in the first post of the thread, > my actual reply to you stood on its own as a condemnation of > a general cliquish attitude. Oh, consider me properly chastened then. BTW - kylix is actually the subject of this thread, supposedly. I didn't think addressing it directly was too out of bounds! And Kylix *is* aimed at non-programmers, or at least it was when it was Delphi. > but microsoft visual studio blah blah .net blah blah is > quite popular, isn't it? Have you used MS "visual" studio? There isn't much "visual" about it. In my experience it's pretty much on par with the various C/C++ IDE's around for Linux already. All of which are pretty close to useless, IMO. People use MS Visual Studio because they have to. Same reason they'll use .NET. If there's anything Borland has proved it's that providing a better development environment than Microsoft doesn't get you more developers. Kylix is, as I understand it, something much closer to original Delphi aim of programming without coding. I'm not saying it wouldn't be neat if you could do Kylix for Perl. I'm just saying I don't think it would be a fantastic success. So, yeah, I'm agreeing with Perrin, but I don't think that makes me some kind of horrible elitist. -sam
Re: kylix: rad!
On Sun, 13 Jan 2002, Sam Tregar wrote: > Ah, gimme a break. You want to convince me that > non-programmers can find their way to the party with a > fancy GUI? Go right ahead! I'll let you wear the > moose-hat for a whole week if you succeed. However, > that doesn't mean I'm going to stay quiet about just how > unlikely I think it is! you apparently didn't read my second-to-last message in this thread, in which i explained that non-programmers are not the subject of the original idea. altho kylix was discussed in the first post of the thread, my actual reply to you stood on its own as a condemnation of a general cliquish attitude. > Kylix is not a new idea - it's an old, mostly > unsuccessful one ported to Linux by an old and mostly > unsuccessful company. If it had worked then we'd all be > out of business and most commercial apps would be > "written" by business majors with Delphi. but microsoft visual studio blah blah .net blah blah is quite popular, isn't it? and many commercial apps /are/ written with that toolset, aren't they? once again: give people tools they are comfortable with, and they are more likely to try alternative technologies and perhaps find their way to the party. maybe if i said "maybe activestate could make komodo generate cgis and mod_perl modules", you'd find the idea more interesting. cos you know, people actually write code with komodo.
Re: kylix: rad!
On Sun, 13 Jan 2002, brian moseley wrote: > On Sun, 13 Jan 2002, Sam Tregar wrote: > > > > Agree. > > you know, i think it's this attitude, or a more insidious > version of it, that keeps mod_perl from being as ubiquitous > as php. it's like having to pledge the frat before you can > get the hot chicks. i, for one, would like to see more > people getting interested in making it easy for people who > don't practice black magic to take advantage of mod_perl. Ah, gimme a break. You want to convince me that non-programmers can find their way to the party with a fancy GUI? Go right ahead! I'll let you wear the moose-hat for a whole week if you succeed. However, that doesn't mean I'm going to stay quiet about just how unlikely I think it is! Kylix is not a new idea - it's an old, mostly unsuccessful one ported to Linux by an old and mostly unsuccessful company. If it had worked then we'd all be out of business and most commercial apps would be "written" by business majors with Delphi. -sam
Re: kylix: rad!
On Sun, 13 Jan 2002, Sam Tregar wrote: > On Sat, 12 Jan 2002, Perrin Harkins wrote: > > > Well, does this product actually have any users to compete for? GUI > > builders usually don't work for anything but the most trivial websites > > that could be written in anything and do fine. People seem to come to > > mod_perl because they need more performance or more control than they > > can get from CGI. > > Agree. you know, i think it's this attitude, or a more insidious version of it, that keeps mod_perl from being as ubiquitous as php. it's like having to pledge the frat before you can get the hot chicks. i, for one, would like to see more people getting interested in making it easy for people who don't practice black magic to take advantage of mod_perl.
Re: kylix: rad!
On Sat, 12 Jan 2002, Perrin Harkins wrote: > Well, does this product actually have any users to compete for? GUI > builders usually don't work for anything but the most trivial websites > that could be written in anything and do fine. People seem to come to > mod_perl because they need more performance or more control than they > can get from CGI. Agree. > I'm not sure I want to try and draw in users who can't program at all. Tangential thought: we may not want to draw individual non-programmers but we undoubtably do work with non-programmers - artists and HTML "writers". I think a GUI system that made it easier for these non-programmers to interface with our creations would have some utility. I've got a half-baked module sitting in my workspace, HTML::Template::Explorer, that was an attempt to do something along these lines for HTML::Template. I didn't get very far before I realized I didn't have a strong enough design to be coding... -sam
Re: oddities
Hi Arnold, On Sun, 13 Jan 2002, Arnold van Kampen wrote: > So if you could still be so kind as to look at the code sample below: I'm sorry, I cannot afford the time to vet your code for you. Perhaps you don't need CGI.pm at all, could you use Apache::Request? 73, Ged.
[ANNOUNCE] Apache::UploadMeter-0.17
The URL http://prdownloads.sourceforge.net/apache-umeter/Apache-UploadMeter-0.17.tar.gz has entered CPAN as file: $CPAN/authors/id/I/IS/ISAAC/Apache-UploadMeter-0.17.tar.gz size: 6182 bytes md5: 184038fd7ce8255c1591f0ec4f5eff25 No action is required on your part Also available on SourceForge (see above URL). SourceForge project homepage http://sourceforge.net/projects/apache-umeter Issac
Re: formmail spammers
On Sat, 12 Jan 2002, Perrin Harkins wrote: > > http://www.spamassassin.org/ > > > > Without a doubt, the best anti-spam solution around. > > That looks great for solving the problem on my own account, Well it might look great, but the only result I've had from it so far is MORE SPAM! Mail:: SpamAssassin's "make test" failed for me (apparently similar problems have been seen and should have been fixed but aren't), no response from the mailing list (admittedly after only 24 hours:) to a question - but loads of spam through their list server! 73, Ged.
Re: Unsetting standard response headers?
On Sun, 13 Jan 2002, Perrin Harkins wrote: > > I have noticed that Yahoo uses Location: header only for redirect > responses and thought > > it may be good to save half of the bandwidth and do the same, as my > particular script/server > > is serving redirects mostly. So my question is how to unset Date:, > Server: and > > Content-Type: response headers? > > Who is setting them in the first place? If they are generated by your > script and you don't set them, Apache will not add them. You may be > seeing them added for redirects that Apache does for you, like sending > http://yoursite to http://yoursite/. You can handle those yourself > instead if you want to. Apache core always sets 'Server' and 'Date' headers. You can not simply overwrite them - you need patch Apache or use low-level Apache API. Igor Sysoev
Re: formmail spammers
On Sat, 12 Jan 2002, Perrin Harkins wrote: > > http://www.spamassassin.org/ > > > > Without a doubt, the best anti-spam solution around. > > That looks great for solving the problem on my own account, but the > larger problem is that there are all of these insecure installations of > formmail.pl out there that spammers are using to send tons of mail. > It's like having an open relay. > > A program to check for these on Google and then alert the webmaster at > each offending site could be a really good thing. Right, and point them to NMS for a replacement too. -- <:->Get a smart net
Re: kylix: rad!
-- brian moseley <[EMAIL PROTECTED]> > many of us on this list have well-developed preferences for > editing and debugging our code, configuring and testing our > applications that are based on executing shell commands in a > terminal. don't you think there are lots of well developed > advocacy reasons for offering an alternative paradigm? Good example would be W32 developers who want to migrate and simply don't know their way around *NIX yet. Even if they've taken the time to learn how the HTTP/HTML/etc end of things function, working on NT doesn't give them very good reflexes for dealing with *NIX. This does seem like a good way to show people that gaining add'l control with mod_perl doesn't have to be painful. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: kylix: rad!
On Sat, 12 Jan 2002, Perrin Harkins wrote: > Well, does this product actually have any users to > compete for? unknown. i figure a large established software company isn't going to spend time developing a product for a market that doesn't exist, but you never know. > GUI builders usually don't work for anything but the > most trivial websites that could be written in anything > and do fine. consider struts, a popular java mvc framework. it defines simple interfaces for things like actions and forms. does struts (and mvc in general) work for non trivial websites? a struts-oriented rad tool could easily scan WEB-INF dirs to find action and form classes and represent them in the gui. the main purpose of the tool would be to assemble and configure those classes in order to generate a struts-config.xml file. it could also incorporate ide functionality. > People seem to come to mod_perl because they need more > performance or more control than they can get from CGI. > I'm not sure I want to try and draw in users who can't > program at all. why do you think this tool would appeal to people who can't program at all? consider the popularity of java and c++ ides. do you think it's possible that people who use those languages might switch to perl if tools like this existed to generate webapps in perl? many of us on this list have well-developed preferences for editing and debugging our code, configuring and testing our applications that are based on executing shell commands in a terminal. don't you think there are lots of well developed advocacy reasons for offering an alternative paradigm? said another way, just cos *you* don't use gui development tools to develop modperl apps doesn't mean there aren't heaps of people out there who'd love to do just that.
Re: Unsetting standard response headers?
> I have noticed that Yahoo uses Location: header only for redirect responses and thought > it may be good to save half of the bandwidth and do the same, as my particular script/server > is serving redirects mostly. So my question is how to unset Date:, Server: and > Content-Type: response headers? Who is setting them in the first place? If they are generated by your script and you don't set them, Apache will not add them. You may be seeing them added for redirects that Apache does for you, like sending http://yoursite to http://yoursite/. You can handle those yourself instead if you want to. - Perrin
Re: formmail spammers
> http://www.spamassassin.org/ > > Without a doubt, the best anti-spam solution around. That looks great for solving the problem on my own account, but the larger problem is that there are all of these insecure installations of formmail.pl out there that spammers are using to send tons of mail. It's like having an open relay. A program to check for these on Google and then alert the webmaster at each offending site could be a really good thing. - Perrin
Re: kylix: rad!
> competition with this product (which has some really > freaking license clauses which you can read about on > freshmeat) seems pretty easy: [...] > anybody interested? Well, does this product actually have any users to compete for? GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. I'm not sure I want to try and draw in users who can't program at all. - Perrin
Re: Unsetting standard response headers?
On Sun, 13 Jan 2002, Richard [utf-8] Čepas wrote: > I have noticed that Yahoo uses Location: header only for redirect responses and >thought it may be good to save half of the bandwidth and do the same, as my >particular script/server is serving redirects mostly. To save bandwidth you can try mod_deflate - it gzips content like mod_gzip does. > So my question is how to unset Date:, Server: and Content-Type: response headers? >mod_headers and 'Header unset' doesn't work for some reason, maybe it is possible to >use some Perl*Handler? mod_headers would not help. There are two ways to omit 'Server', 'Date' and 'Content-Type' headers: 1. to use ap_rwrite()/BUFF API to send response as mod_proxy does; 2. to patch Apache sources. This helps to all Apache modules that use ap_send_http_header()/'return HTTP_MOVED_*' API. Igor Sysoev
Unsetting standard response headers?
Hi, I have noticed that Yahoo uses Location: header only for redirect responses and thought it may be good to save half of the bandwidth and do the same, as my particular script/server is serving redirects mostly. So my question is how to unset Date:, Server: and Content-Type: response headers? mod_headers and 'Header unset' doesn't work for some reason, maybe it is possible to use some Perl*Handler? -- ☻ Ričardas Čepas ☺
Re: oddities
Ok, that works!
But I never realized this before.
Quite contra intuitive.
And what about the /per/ dir...
So if you could still be so kind as to look at the code sample below:
On Sat, 12 Jan 2002, Ged Haywood wrote:
> Hi again,
>
> On Sat, 12 Jan 2002, Arnold van Kampen wrote:
>
> > (only the plain string works, not the function textfield() after
> > several submissions)
>
> Try this instead of the first line in your handler:
>
> my $r=shift;
> my %params = ($r->method eq 'POST') ? $r->content : $r->args;
> my $bla = $params{'position'} + 10;
>
> I think you'll find the second line there in the Guide somewhere.
>
[ I tried this with ./httpd -X ]
So it is possible to create a textfield with another name and show it with
the new value. The textfield with the same name will remain unchanged!
So textfield(-name=>position, -value=>$bla) will not accept submission
value from field with name position.
But textfield(-name=>position2, -value=>$bla) will accept the value from
field position!
When using the string code the 'position' field will accept the new data
after submission.
I did not find these among the misteries before..
Very Strange. Is this a well known pittfall?
Arnold
#!/usr/bin/perl
# file bla.cgi
use strict;
use CGI qw(:standard :html3 :netscape );
CASE: {
if (defined(param('forward'))) {
$_ = param('forward');
/^first/i and do {second_show();last CASE;};
/^second/i and do {first_show();last CASE;};
}
first_show();
}
exit 0;
sub first_show() {
my @deel_display =();
my $position = param('position');
my $ref = ref($position);
my $somename_data = param('somename');
push @deel_display, td('param: '.param('position'));
my $bla = $position + 10;
push @deel_display, td('param + 10: '.$bla);
push @deel_display, td('hidden value: '.$bla);
push @deel_display, td(textfield(-name=>'position', -value=>$bla));
push @deel_display, td(textfield(-name=>'position2', -value=>$bla));
push @deel_display, td(textfield(-name=>'position3', -value=>$ref));
push @deel_display, td(hidden(-name=>'somename', -value=>$bla));
# push @deel_display, "";
my $button_value='first';
push @deel_display, td(submit(-name=>'forward', -value=>$button_value));
print header(-pragma=>'no-cache'),
start_html(-title => 'visualise'),
start_multipart_form(-method=>'post'),
table({-valign=>'top',border=>'1'},Tr(\@deel_display)),
endform,
end_html();
}
sub second_show {
my @deel_display =();
my $position = param('position');
push @deel_display, td('param: '.param('position'));
my $bla = $position + 10;
push @deel_display, td('param + 10: '.$bla);
push @deel_display, td(textfield(-name=>'position', -value=>$bla));
# push @deel_display, "";
push @deel_display, td(submit(-name=>'forward', -value=>'second'));
print header(-pragma=>'no-cache'),
start_html(-title => 'visualise'),
start_multipart_form(-method=>'post'),
table({-valign=>'top',border=>'1'},Tr(\@deel_display)),
endform,
end_html();
}
> 73,
> Ged.
>
