Shared memory
Hello! :) After moving to RedHat 7.3 with kernel 2.4.18-3smp system can't use shared memory: --- CPU0 states: 26.1% user, 13.0% system, 0.0% nice, 59.0% idle CPU1 states: 24.0% user, 10.1% system, 0.0% nice, 64.0% idle Mem: 1030724K av, 953088K used, 77636K free, 0K shrd, 27856K buff Swap: 1052248K av, 0K used, 1052248K free 619432K cached --- Can anybody get me info about this problem Thank you in advnace. Kosyo __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Problem with dbm files?
Hello, I'm in the process of converting my perl CGI scripts to run under mod_perl. I'm working on an ibook (MacOSX 10.1.5 -Apache/1.3.26 (Darwin) mod_perl/1.26) So far, so good - the apps using mysql still work under mod_perl :-). One app uses MLDBM (with DB_File) to store a complex hash. One doc, mod_perl and dbm files, suggests that there might be consistency problems (locking related) when using dbm files with mod_perl. It seems that the MLDBM::Sync module is supposed to eliminate this concern. Could someone that uses MLDBM with DB_File under mod_perl please let me know if there are, in fact, problems with this combination. If so, will MLDBM::Sync fix them or do I need to rewite my app to use mysql? Thanks, Warren
Re: 0x444ba45b in prof_mark () from /usr/lib/perl5/5.6.1/i686-linux/auto/Devel/DProf/DProf.so
Hi Stas, On Sun, 8 Dec 2002, Stas Bekman wrote: I see no reason why we should mislead readers, saying do not upgrade to 5.8.0, but to 5.7.2 instead. I'm sorry if I misled anyone. I thought it was clear that my own personal recommendation was at least 5.7.2 and that there are those who would recommend 5.8.0 but I'm not one of them. That's because I have no personal experience of that release. Anyway, if they've read all this I think they have the idea now... :) 73, Ged.
Re: Apache::Session and user sessions
md wrote: My question is with regards to whether I need or should put the submitted data into the session as the user navigates the forms (to create an account). The user will be taken through three forms to create an account. So for instance, form one will ask the user to create a username, password, and provide an email address. Before moving on to form two (billing info), should I put this data in the session, or just go ahead and dump it in the database (after making any nec. checks), since I won't need the info until they actually login? Or should I collect all the info from all three screens by putting it in the session as the user traverses the forms and then put it all in the database at once? I'm currently using the first option. BTW, it is possible for a user to create a free account by hitting form one only, so no harm would come if something happened after form one. This is really a question of requirements. In systems where all information needs to be collected before a valid account can be created, you have to wait until the end to put it in the permanent tables. I usually don't store form input in the session because it leads to strange results if the user has multiple browser windows open on the site, but that may not be an issue for your application. Another question, while not mod_perl related (sorry:), is how to taint check input data like usernames, address fields and email addresses. All info is just put in the database, no unsafe system calls are run. I'm curious as to what characters to limit for usernames in particular. If you're using bind variables with DBI, there is no technical reason to restrict the characters at all. Just make sure you HTML-escape them whenever you display them on a page. - Perrin
Re: Apache::Session and user sessions
On Mon, 9 Dec 2002, Perrin Harkins wrote:
md wrote:
My question is with regards to whether I need or
should put the submitted data into the session as the
user navigates the forms (to create an account). The
user will be taken through three forms to create an
account. So for instance, form one will ask the user
to create a username, password, and provide an email
address. Before moving on to form two (billing info),
should I put this data in the session, or just go
ahead and dump it in the database (after making any
nec. checks), since I won't need the info until they
actually login? Or should I collect all the info from
all three screens by putting it in the session as the
user traverses the forms and then put it all in the
database at once? I'm currently using the first
option. BTW, it is possible for a user to create a
free account by hitting form one only, so no harm
would come if something happened after form one.
This is really a question of requirements. In systems where all
Agreed.
I have a golden rule for this:
if (( management are annoying and like to know about incomplete
registrations
||
you want one point of varifying input so that designers can
shove in as many intermediary pages as possible)
)
You don't have a ridiculous amount of fields to process )
{
place in session
}
else
{
shove in hiddens.
}
I wouldn't start populating your real tables until the registration is
complete since you may end up with lots of incomplete junk in there and
your form design will be governed by any database constraints placed on
your table (foreign keys, and stuff).
Then again, I sometimes have to bend my golden rules. Fortunately Perl
and Gold both bend easily.
usually don't store form input in the session because it leads to
strange results if the user has multiple browser windows open on the
site, but that may not be an issue for your application.
I'm not sure how often a user will attempt to complete one form through
multiple browsers. To be honest I'm not sure that he/she should. I think
of a form as one process which may remain persistant due to hiddens or a
session. Once the form has been completed or a user has logged in, the
session data used for the rest of the site should probably be unrelated
and populated separately.
That's just my 0.02 EU on a cold Monday evening.
R.
Re: Apache::Session and user sessions
Rafiq Ismail (ADMIN) wrote: I'm not sure how often a user will attempt to complete one form through multiple browsers. To be honest I'm not sure that he/she should. There are all kind of forms. An obvious example would be a search. Users often open up multiple windows when browsing a site and do searches in them. If you store search-related data in the session, the multiple windows will interfere with each other. These should be stored in the HTML instead. - Perrin
Reading XML input from flash
Has anyone had any luck reading in the XML sent by the flash XML.sendandload function? I've looked on Macromedias site, and all over the web, but cant seem to get it to work. I know that the flash code is supposed to be POSTing the data. Ourflash app connects to the server and seems to be trying to send the data, but I cant capture it. If there's any sites or code snippets anyone can provide it would help out a lot. Thanks, Marc Slagle The Fulkert Consulting Group, Inc. 559 Liberty Hill 2W Cincinnati, OH 45210
Re: Can't find Apache::ModuleConfig
Am Mon, 2002-12-09 um 03.06 schrieb Stas Bekman: Tom Schindl wrote: Thanks Stas. The documentation on perl.apache.org pointed me in a wrong direction (e.g. Apache::DBIPool (http://perl.apache.org/docs/2.0/user/overview/overview.html#Apache__DBIPool)) --cut- use strict; use Apache::TIPool (); use Apache::ModuleConfig (); use DBI (); --cut- Maybe one could mark the things not implemented yet with a big comment and remove things which will never implemented. I'm thinking of Apache::TIPool, Apache::ModuleConfig, ... . I'm planning to revamp these old docs all at once. Sounds good. Do you know how long this will take? May I ask more question? 1) How can I read params sent via GET or POST? In mod_perl-1.2x this was done via $r-param(bla). Apache::RequestRec does not provide such an method. For now use CGI.pm, till Apache::Request gets ported to 2.0. Apache::compat also provides methods to retrieve the params couldn't I use them? Although they're a little bit buggy (see my posting from yesterday Problems with Apache::compat and german special chars ). 2) Will Apache::TIPool ever implemented? Not in the way it's described in the overview, but yes should be implemented at some point. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- b e s t s o l u t i o n . a tEDV Systemhaus GmbH Thomas SchindlProject Management mobile ++43/664/314 59 58 Anton-Rauch-Str.6aA-6020 Innsbruck fax ++43/512/935834 http://www.bestsolution.at phone ++43/512/935834 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Reading XML input from flash
At 1:01 PM -0500 12/9/02, Marc Slagle wrote: Has anyone had any luck reading in the XML sent by the flash XML.sendandload function? I've looked on Macromedias site, and all over the web, but cant seem to get it to work. I know that the flash code is supposed to be POSTing the data. I'd like to shoot whoever designed the Flash object model. There's a different send and load function for each data type. So you can't POST cgi stuff and get back xml. (You can hack a GET, by hand appending the arguments, but that's it.). The stream communications should have been in a separate class, not there for each type of parser. But that doesn't solve your problem. I've forwarded the question to someone who's playing with it. We're actually just a few days away from doing the same thing (right now we are doing a GET and reading XML, but we need to switch, and since we can't POST anything except XML, we'll have to gen up some type of XML communication). I'd be intrested in your progress. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: Can't find Apache::ModuleConfig
Tom Schindl wrote: Maybe one could mark the things not implemented yet with a big comment and remove things which will never implemented. I'm thinking of Apache::TIPool, Apache::ModuleConfig, ... . I'm planning to revamp these old docs all at once. Sounds good. Do you know how long this will take? Hopefully, soonish. May I ask more question? 1) How can I read params sent via GET or POST? In mod_perl-1.2x this was done via $r-param(bla). Apache::RequestRec does not provide such an method. For now use CGI.pm, till Apache::Request gets ported to 2.0. Apache::compat also provides methods to retrieve the params couldn't I use them? Sure you can. That's why there were added. Although they're a little bit buggy (see my posting from yesterday Problems with Apache::compat and german special chars ). Yes, thanks. I didn't have a chance to look at it yet. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
