use Perl

Accordingly with the perlvar manpage, $@ is used for error messages produced by eval.

I would like to use it as a more general variable for error messages. When a function returns a string, there isn't much that can be done to return a error string. Probably returning a list, setting an object, nothing clean and simple as real perl code :)

What I want is to use $@. The function will return undef and set $@ to the error message. This is clean enough and should work.

But I have some doubts: is there any problem on using this approach? In the function I probably need to clean up $@ and assign undef to it?

What is happening with use.perl main articles? Lack of time to moderate them?

Perl is complaining about a deep recursion on a subroutine. That is natural, as I have deep recursion :). But that recursion is being controled and therefore I know that will not be a problem.

Now the question is: can I silence Perl on these warnings?

In my last post I was complaining about 'use encoding'. As suggested, I changed. Now, I am using just 'Encode' module, 'encode' function. But that is not working correctly as well.

Basically, I continue to get errors with calls to renew and renewed method. Curiously, they are not deterministic. Sometimes nothing gives error. Some other times, it gives error when creating the CGI::Session object: Can't locate object method "renewed" via package "Encode::utf8" at /usr/lib/perl5/core_perl/POSIX.pm line 26

I really would like to know if this problem might be from Encode and CGI::Session working together (I just got the bug when adding sessions to the website) or if it is about mod_perl working with both of them.

No idea. But this is giving me pain...

I am trying to use CGI::Session (and of course, CGI::Cookie) together with 'use encoding "utf-8"', but things seems not to work.

The error is 'Can't locate object method "renewed" via package "Encode::utf8" at /usr/share/perl5/site_perl/5.10.0/CGI.pm' that seems to be common to other modules. For example, a google search shown similar problems with Safe.

I am not sure yet about who is responsbible for the bug, Encode, CGI::Session or CGI::Cookie. But if this kind of problem was detected previously probably somebody knows where is the problem and can point me to the correct place, so I can try to correct this bug.

For some time that Perl modules are numbered with a major version, a minor version, and sometimes, a alpha/beta numbering.

Lately some modules adopted the usage of a serialized date. One of the latest was Regexp::Common. Do not stress, Abigail, nothing against it.

Now, the question are: is it useful? Should it be used just for old and stable modules like Regexp::Common or should we use it from the beginning?

I think it might gets useful. Normally it is hard to know in what direction to number distributions. Especially when you get to .99 and do not want to change the major version in the next version.

But then, probably we should not use that numbering scheme for new modules. Just because you never know if you will need to change drastically the interface. And then, a major number version change might get useful.

Any thought?

• perl core memory improvements by Jim Cromie

• wxPerl Documentation by Eric J. Roode

• Improve the visual design of Perl websites by Jon Allen

• Corporate, Embedded, and Multi-user Perl on Windows by Curtis Jewell

• Changing the Perl 5 optree build process into a Abstract Syntax Tree generation and a code generation step by  Gerard Goossen

• Enhancing CPANHQ by Shlomi Fish

• Creating a ctypes-Like Interface for Perl to External Subroutines by Shlomi Fish

These proposals are open for public/community discussion. Please comment each post with your thoughts of the proposal. Please make sure you sign your comments, and also that your comment is something more than just one "I would like it" or "It sucks", or it will be moderated.

Voting will take place in 23th August, and results should be posted shortly after.

I still did not get the grip on Encodings and Perl. I have an UTF8 file that I want to process. This process calls a module that I know uses a bidirectional pipe with an latin1 process. But that should be hidden...

So, I am reading with <> operator, and printing with print. If I do not say a thing, I get output correct (UTF8) but the module does not work. If I put 'use encoding utf8', I get input and output correct, but the module does not work. If I put 'use open utf8' I get the module working, but no correct output. If I add the binmode for the STDOUT, it works. And finally, if I remove 'use open' and add a binmode for STDIN, it does not work, as <> is not affected by that.

Finally, I was hopping that 'use open utf8' would work for it all. Unfortunately it doesn't. Perl 5.10.0, btw.

Ideas, suggestions, corrections, are welcome.

You know you are doing too complex SQL queries... when DBI/DBD::SQLite refuses to parse the SQL statement.

The statement is simple: select a field, where it is one of a set of words:

SELECT word FROM dict WHERE word='aaaaa' OR word='bbbbb' OR word='ccccc' OR...

The first error was: parser depth of 1000 was reached.

No problem. Decided to construct a binary tree of ORs:

SELECT ... WHERE ((word = a or word = b) or (word = c or word = d))

Now, DBD::SQLite::db prepare failed: parser stack overflow.

I think the solution is to slipt this thing in more than one query. Damn!