We're getting wall-to-wall errors following a CVS update of our test server: [Wed Dec 10 16:03:47 2003] [error] [client 192.168.5.27] Premature end of script headers: /usr/local/koha/intranet/cgi-bin/mainpage.pl "use" not allowed in expression at /usr/local/koha/intranet/modules/C4/Search.pm line 21, at end of line (Might be a runaway multi-line << string starting on line 3) syntax error at /usr/local/koha/intranet/modules/C4/Search.pm line 21, near "pm use strict" BEGIN not safe after errors--compilation aborted at /usr/local/koha/intranet/modules/C4/Search.pm line 23. Compilation failed in require at /usr/local/koha/intranet/modules/C4/Reserves2.pm line 29. BEGIN failed--compilation aborted at /usr/local/koha/intranet/modules/C4/Reserves2.pm line 29. Compilation failed in require at /usr/local/koha/intranet/modules/C4/Circulation/Circ2.pm line 35. BEGIN failed--compilation aborted at /usr/local/koha/intranet/modules/C4/Circulation/Circ2.pm line 35. Compilation failed in require at /usr/local/koha/intranet/modules/C4/Auth.pm line 30. BEGIN failed--compilation aborted at /usr/local/koha/intranet/modules/C4/Auth.pm line 30. Compilation failed in require at /usr/local/koha/intranet/cgi-bin/mainpage.pl line 9. BEGIN failed--compilation aborted at /usr/local/koha/intranet/cgi- bin/mainpage.pl line 9. Something I did wrong, or a problem with the latest files? -- Owen
Owen Leonard a écrit :
Something I did wrong, or a problem with the latest files?
You made nothing wrong. It was typo error introduced by Slef when fixing bug 662. I've fixed them fixed now in CVS. slef : could you pls always check that a C4 package compile before commiting it (at least). For other scripts it's not as important, but breaking a C4 package causes Koha major failure. slef again : i think I didn't introduce bugs in Search.pm, but check that it still works well. (bugs in Circ2.pm where minor & shouldn't have introduced any bugs) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2003-12-11 13:04:02 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
It was typo error introduced by Slef when fixing bug 662.
OK, sorry. I'm working through 40 screens of likely security problems for bug 662 on my own in my spare time. Occasional typos happen, especially when seeing the same buggy code fragment pasted in the Nth place. Maybe I should be refactoring that when I find it, but that will probably introduce more bugs. Sorry for non-response here yesterday: I'd been out driving through the bad weather.
slef : could you pls always check that a C4 package compile before commiting it (at least).
Can you write me a unit test for this, or point me at the pre-commit unit tests, please? Surely there are other things which I should check, but I won't know until I break.
For other scripts it's not as important, but breaking a C4 package causes Koha major failure.
CVS users should be used to this?
slef again : i think I didn't introduce bugs in Search.pm, but check that it still works well.
Looks fine. One place you concatenated what I would interpolate, but there's more than one way to do it. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
MJ Ray a écrit :
On 2003-12-11 13:04:02 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
It was typo error introduced by Slef when fixing bug 662.
OK, sorry. I'm working through 40 screens of likely security problems for bug 662 on my own in my spare time. Occasional typos happen, especially when seeing the same buggy code fragment pasted in the Nth place. Maybe I should be refactoring that when I find it, but that will probably introduce more bugs. Sorry for non-response here yesterday: I'd been out driving through the bad weather.
no prob (except a nice -but cold- sunny here :-) ) & I agree refactoring too much results in more risks than improvements.
slef : could you pls always check that a C4 package compile before commiting it (at least).
Can you write me a unit test for this, or point me at the pre-commit unit tests, please? Surely there are other things which I should check, but I won't know until I break.
That's something we lack, for sure... & we always have 2 choices : * improve code stability * improve features. The problem being that users prefer features :-(
For other scripts it's not as important, but breaking a C4 package causes Koha major failure.
CVS users should be used to this?
yes, of course. But it's always boring to see something suddenly badly broken by "compilation error" (not sure "boring" is a good word here. Maybe too much, but i don't know another word :-) ). -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On Thu, 11 Dec 2003, paul POULAIN wrote:
MJ Ray a �crit :
On 2003-12-11 13:04:02 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
It was typo error introduced by Slef when fixing bug 662.
OK, sorry. I'm working through 40 screens of likely security problems for bug 662 on my own in my spare time. Occasional typos happen, especially when seeing the same buggy code fragment pasted in the Nth place. Maybe I should be refactoring that when I find it, but that will probably introduce more bugs. Sorry for non-response here yesterday: I'd been out driving through the bad weather.
no prob (except a nice -but cold- sunny here :-) ) & I agree refactoring too much results in more risks than improvements.
One nice thing about proper refactoring (with unit-tests) is that the risk is very low. make a change, test to verify nothing broke, make another change, etc.
slef : could you pls always check that a C4 package compile before commiting it (at least).
This should be a basic rule. anytime we make a code change, we should *at least* use 'perl -c' to make sure we haven't introduced a compile time error. As we build unit tests (see below), running those will provide even more safety.
Can you write me a unit test for this, or point me at the pre-commit unit tests, please? Surely there are other things which I should check, but I won't know until I break.
Currently there are very few tests (unit or otherwise) within Koha. This is a major shortcoming. Please, if you're going to fix a bug, or add a feature, take a little bit of extra time and add a test to the existing test harness. If you have a bit of extra time, but aren't up to working on a new feature or a bug fix, write some tests (and/or some docs/comments). It's little things like this that will really pay off.
That's something we lack, for sure... & we always have 2 choices : * improve code stability * improve features. The problem being that users prefer features :-(
I don't think I agree (about the 2 choices, not about user preferences). Not improving the code stability/maintainablity is like going into debt. We will always be incurring some debt as we try to do new things. If we don't pay off what we owe (by refactoring), we *will* become overwhelmed. Another major win is that as the code become more stable and manageable, new features become easier to add (and, more importantly, easier to add without breaking existing code).
For other scripts it's not as important, but breaking a C4 package causes Koha major failure.
CVS users should be used to this?
yes, of course. But it's always boring to see something suddenly badly broken by "compilation error" (not sure "boring" is a good word here. Maybe too much, but i don't know another word :-) ).
While CVS users might be used to it, there is something to say for them not having to see it too often. Yes, we will introduce bugs. Hopefully we won't leave things in flames ... it's almost a shame we can't really run a tinderbox/smoketest environment -pate
-- Paul POULAIN Consultant ind�pendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
On 2003-12-11 16:32:12 +0000 Pat Eyler <pate@eylerfamily.org> wrote:
This should be a basic rule. anytime we make a code change, we should *at least* use 'perl -c' to make sure we haven't introduced a compile time error. As we build unit tests (see below), running those will provide even more safety.
That doesn't work right now. A lot of things in CVS seem not to compile before I touch them. I think it's a bit unfair to suggest that I make sure everything compiles before commit. Should I be fixing the other compilation bugs as well as the DBI bugs that I want fixed now? This is why I asked for unit tests and help in fixing DBI. I don't know which parts are used and which parts are obsolete. If someone can give me a list of which files are not used, or better yet remove them from the CVS trees (careful), it would shorten the time spent on this bug. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
MJ Ray a écrit :
On 2003-12-11 16:32:12 +0000 Pat Eyler <pate@eylerfamily.org> wrote:
This should be a basic rule. anytime we make a code change, we should *at least* use 'perl -c' to make sure we haven't introduced a compile time error. As we build unit tests (see below), running those will provide even more safety.
That doesn't work right now. A lot of things in CVS seem not to compile before I touch them. I think it's a bit unfair to suggest that I make sure everything compiles before commit. Should I be fixing the other compilation bugs as well as the DBI bugs that I want fixed now? This is why I asked for unit tests and help in fixing DBI. I don't know which parts are used and which parts are obsolete. If someone can give me a list of which files are not used, or better yet remove them from the CVS trees (careful), it would shorten the time spent on this bug.
I plan to clean CVS tree soon. (but NOT before having a HEAD tree & a 2.0.0 branch, that chris should create & explain how to use) PS1 : pat was spaking of perl -c on the file you plan to commit, not on all scripts. PS2 : I still agree we lack a unit test. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (4)
-
MJ Ray -
Owen Leonard -
Pat Eyler -
paul POULAIN