January 2003 - Koha-devel - lists.koha-community.org

to ambrose
by Pat Eyler 08 Jan '03

08 Jan '03

sorry for taking up a public forum for this ... Ambrose, I've tried to reply to your email several times, but for some reason, my MTA doesn't get a good response when i try to resolve you're email address. We can either chat in irc, or i can try another email address -- whichever is better for you. -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

1 0

Koha and testing
by Pat Eyler 08 Jan '03

08 Jan '03

Ed Summers wrote: > Hi Nathan: thanks for writing. And thanks for kicking off this thread Ed. This is one of the places I'd really like to see Koha do better, and it's going to take the efforts of several people. > > On Tue, Dec 31, 2002 at 12:44:11PM -0500, Nathan Gray wrote: > > I would prefer to use Test::Debugger over Test::More. I like the > > interface of Test.pm, though it doesn't handle all the scenarios I > > need. I wrote a new version of Test.pm, but Test::More beat me to > > CPAN. > > I've use Test::More quite a bit, and have really come to like it. It > also comes standard in Perl 5.8 now. I could adapt to another > framework though, as long as it works :) I'd just as soon we stuck to a standard part of the Perl distro. The fewer bits people need tograb to make Koha work the better (although this is easier now that Mike's built the bundle for us.) > > > I am uncertain whether it would be better to have a small set of test > > scripts with each module, or to have one large test suite in a > > central location. I'm leaning toward a centralized test suite, but > > haven't grasped Koha enough to know where to start, or where the test > > suite should be kept. > If you grab Koha from CVS, all the tests (what few there are) are in the t subdir of the top level directory. Once 2.0 is out the door, we'll start working on the great reorg that will become 2.2 and we can look at breaking modules into functional groups and including tests with the individual modules. > Yes, I'm unclear on this as well. In my current work environment we've > adopted the former approach: to have component tests that are easily > paired with the components they test: > > C4/Format.pm > C4/Format.t > > Then we have a 'smoking' program which goes and looks for all the *.t > files and runs the tests. Having them split out like this is extremely > useful when adding new functionality: because you know exactly where > you have to go to add or modify a test. It also uses the filesystem to > illustrate which components lack tests. > This is a great model. I'd like to get to the point where smoke tests are run before cvs commits are made, on a nightly basis (reported to a web page and/or mailing list), and prior to rolling a new release (reported to a file in the release docs). We have a ways to go before we get there, but it makes a nice, comforting dream. > > Definitely all the modules which interact with the database should > > have tests to make sure selects, updates, deletes, inserts are all > > working correctly. > > > > Likewise, any module which performs searches should have tests to make > > sure that the correct information is returned, in the correct order. > > > > A test should make sure the templating system works, especially for > > the various languages which are going to be supported. > I rally agree with the first two, but the third isn't too big a deal to me. Since we're using HTML::Template (which is pretty well tested), I feel comfortable with some cursory tests of HTML output. If we could get to the level of testing allowed by the Narf html/cgi library in ruby, I could be convinced to change my mind. > Yes, these are important. I guess a test database will need to be up > and running for alot of these sorts of tests. > /me nods. We do have a test DB dataset for just this purpose. I don't know that it's up to date for 1.3/2.0, but I'm guessing that it is ... Paul is pretty thourough. > > Let me know what your ideas are. Pat Eyler will be overjoyed to have > > another tester on board! We'll hear from him as soon as the holidays > > are past, I am assuming. He is very good about writing. > > Yes, I am overjoyed. Welcome aboard. Before they're over even. Don't listen to Ed about this ... the holidays have left him in too good a mood and he's telling stories. Happy New Year, -pate > > I hope to have Test::Debugger on CPAN in a day or three. > > OK, I look forward to seeing it. I know what you mean about getting > bogged down in work. I feel the same way, but I want to find time to > work on this. > > //Ed > > -- > > % perl -MData::Dumper -e "print Dumper($me)" > $VAR1 = { > 'WEB' => 'http://www.inkdroid.org', > 'NAME' => 'Ed Summers', > 'AIM' => 'inkdroid', > 'EMAIL' => 'ehs(a)pobox.com' > }; Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

3 2

Koha 1.3.3 released
by Pat Eyler 07 Jan '03

07 Jan '03

Thanks to more hard work by Paul Poulain and his band of franch hackers (and thanks to the support of the Nelsonville Public Library), Koha is continuing to improve. The big step this time is the release of Koha 1.3.3, a development release of the branch destined to become Koha 2.0. This release features many bug fixes, improvements to MARC handling, and French, Spanish, and Polish translations (not yet complete but hey, this *is* a development release.) This will be the last 1.3.X release. The next schedule release will be 1.9.0 amrking feature completion for the 2.0.0 release. Paul Poulain Koha 2.0 release manager the Koha project Pat Eyler kaitiaki/manager the Koha project

1 0

Re: [Koha-devel] problems installing z3950 module
by Ed Summers 07 Jan '03

07 Jan '03

> does nothing for me, as cc is a link to gcc : > cc (GCC) 3.2 (Mandrake Linux 9.0 3.2-1mdk) > Copyright (C) 2002 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO Argh. You're right, my cc is a link to gcc as well...so the compiler is definitely not the issue. UNLESS, the versions are significant. What version of gcc do you have? gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) Do you only have one version of Perl installed (5.8.0)? And did you install it from source? It is possible that some of Perl's configuration files are not present on a fresh Mandrake install of the binary. //Ed -- Ed Summers aim: inkdroid web: http://www.inkdroid.org

1 0

problems installing z3950 module
by paul POULAIN 07 Jan '03

07 Jan '03

Hi, I try to install Net::Z3950 : _** yaz is installed :*_ make[2]: Rien à faire pour `install-exec-am'. /bin/sh ./mkinstalldirs /usr/local/share/aclocal mkdir /usr/local/share/aclocal /usr/bin/install -c -m 644 ./yaz.m4 /usr/local/share/aclocal/yaz.m4 make[2]: Quitte le répertoire `/home/paul/archives/a_compiler/yaz-1.9.2' make[1]: Quitte le répertoire `/home/paul/archives/a_compiler/yaz-1.9.2' _** Perl Makefile.PL in Net::Z3950*_ [root@localhost Net-Z3950-0.31]# perl Makefile.PL Warning: prerequisite Event 0.77 not found. MakeMaker (v6.03) Writing Makefile for Net::Z3950::yazwrap Writing Makefile for Net::Z3950 What is Event 0.77 ? Is it mandatory. It doesn't seems ? _** make*_ [root@localhost Net-Z3950-0.31]# make cd yazwrap && make LIB="" LIBPERL_A="libperl.a" LINKTYPE="dynamic" PREFIX="/usr" OPTIMIZE="-O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce" PASTHRU_DEFINE="" PASTHRU_INC="" make[1]: Entre dans le répertoire `/home/paul/archives/a_compiler/Net-Z3950-0.31/yazwrap' gcc -c -Dbool=char -DHAS_BOOL -I/usr/local/include -Wall -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce -DVERSION=\"\" -DXS_VERSION=\"\" -fpic "-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" connect.c cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/op.h:480, from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/perl.h:2209, from ywpriv.h:5, from connect.c:12: /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/reentr.h:602: field `_crypt_struct' has incomplete type In file included from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/perl.h:3368, from ywpriv.h:5, from connect.c:12: /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:246: parse error before "off64_t" /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:248: parse error before "Perl_do_sysseek" /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:248: parse error before "off64_t" /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:248: warning: type defaults to `int' in declaration of `Perl_do_sysseek' /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:248: warning: data definition has no type or storage class /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:249: parse error before "Perl_do_tell" /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:249: warning: type defaults to `int' in declaration of `Perl_do_tell' /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:249: warning: data definition has no type or storage class /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:1378: parse error before "Perl_PerlIO_tell" /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:1378: warning: type defaults to `int' in declaration of `Perl_PerlIO_tell' /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:1378: warning: data definition has no type or storage class /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:1379: parse error before "off64_t" make[1]: *** [connect.o] Erreur 1 make[1]: Quitte le répertoire `/home/paul/archives/a_compiler/Net-Z3950-0.31/yazwrap' make: *** [yazwrap/libyazwrap.a] Erreur 2 does someone have an idea to help me ??? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

2 3

koha and testing
by Ed Summers 06 Jan '03

06 Jan '03

Hi, I'm new to the koha-devel list (somehow forgot to subscribe a few weeks ago) and I'm interested in getting familiar with the Koha source code by writing unit tests for it. I guess I could go back through the archives and see what discussion I can find, but I was wondering if anyone could provide me with some guidance on how testing is being done currently, and good places to start looking at creating new tests. I've worked quite a bit with the Test::More framework, and would be interested in writing a 'smoke' program that would iterate through the available tests, run them, and report any failures. This process could even be automated, if it proves feasible. Anyhow, I just thought I'd express my interest and see if anyone has any ideas. -- Ed Summers aim: inkdroid web: http://www.inkdroid.org

2 2

1.3.3 NOT released !
by paul POULAIN 06 Jan '03

06 Jan '03

Hi, During chrismas holidays, i can't work a lot on my computer as you may have seen :-) The 1.3.3 could not be released before christmas, because of many installer problems. I just have spend 2 hours on it, and it still doesn't work well; so, the 1.3.3 will be released in january 2003 ! note that ppl using a cvs version should be able to test the uptodate version, as the remaining bugs are only on installer/db-updater/koha.conf creation. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://fr.koha.org)

2 2

Re: SPUG: windfall -> contest (fwd)
by Pat Eyler 03 Jan '03

03 Jan '03

I've recently come into a bit of a windfall, and I thought I might try to find a way to share it a bit more widely, and this is what I came up with. I'll pass along all of the ideas that I hear about. If anyone wants to pick up one of the ideas to implement it, please feel free. -pate ---------- Forwarded message ---------- Date: Thu, 2 Jan 2003 15:45:41 -0500 From: Asim Jalis <asimjalis(a)acm.org> To: Pat Eyler <pate(a)eylerfamily.org> Subject: Re: SPUG: windfall -> contest On Thu, Jan 02, 2003 at 01:27:32PM -0500, Pat Eyler wrote: > I write the occasional book review. Recently, I asked for a > copy of 'LDAP Programming, Integration, and Management' by > Manning Press and was a bit suprised when they shipped me a > couple of copies. I asked them what to do with the other one, > and they said I should find someone in SPUG that would write a > review of it and pass the extra copy along. > > Since I figure there are likely to be a few people that would > like a free book, I thought I'd put together a quick contest to > see who gets the free copy. I also manage the Koha project (a > free software library system), so I thought I'd tie libraries, > LDAP, and maybe even Perl into the contest. > > If you'd like to review this book, please send me an idea for > using LDAP within a library system (Patron authentication is > already a work in progress). You don't need to actaully > implement your idea, but the idea should be clearly defined so > that someone can sit down and implement it in Perl for Koha. Hello Pat, I am not terribly familiar with Koha but let me try anyway. 1. LDAP could be used to determine how to contact a patron when a book they recalled was checked in or when books they had checked out became overdue or in response to other events. For example you could contact the patron using phone, page, e-mail, internet messenger, SMS. The library user could set his preferences and these could be stored in LDAP. The user might prefer to get different kinds of notifications in different ways. She/he might prefer some over SMS and others over e-mail for example. Parents might wish to be notified by e-mail when their children checked out books. 2. LDAP is optimized for "read many, write few" while databases are usually optimized for writing. LDAP could be used to store the static attributes of the books which are unlikely to change. The checkout information and other changing state information could be stored in a database. The title, author, keywords, etc. of the books could be stored in LDAP. 3. The library staff directory could be stored on LDAP. This could include names, contact information, and possibly even pictures. A front-end in Perl could access LDAP and make this information available over the web. Those are my suggestions. And yes, I would be interested in writing a review of the book. I also had a more general question. How did you get started writing reviews for technical books? Did you just write to publishers and offer your services? I am interested in doing this also and was wondering how to break into this field. Thanks. Asim

2 1