tkacik@kyzyl.mi.org (Tom Tkacik) (05/08/91)
I just compiled perl 4.003 on an AT&T 3b1. Not the world's biggest machine, but it does the job. It failed on test, op/dbm.t. Here's what I get when I run ./perl t/op/dbm.t. 1..12 ok 1 ok 2 Out of memory! From looking at t/op/dbm.t, it does not appear that the test should use that much memory. Does this test really use that much memory, or is something wrong? Do I need to do anything special when compiling perl on a 3b1? Now the 3b1 does not come with -lndbm, but that didn't stop me. I just grabbed Ozan Yigit's sdbm package, and used that. I compiled most of perl with gcc, (falling back to cc for eval.c and toke.c). Gcc tends to run out of virtual memory, (there's that 2.5Meg limit again). I did not use perl's malloc, (should I have?) And I used the shared libraries, (maybe I should not have). Any ideas? -- Tom Tkacik | tkacik@kyzyl.mi.org | To rent this space, call 1-800-555-QUIP. ...!rphroy!kyzyl!tkacik |
rmfowler@texrex.uucp (Rex Fowler) (05/09/91)
In article <339@kyzyl.mi.org> tkacik@kyzyl.mi.org (Tom Tkacik) writes: > >Now the 3b1 does not come with -lndbm, but that didn't stop me. >I just grabbed Ozan Yigit's sdbm package, and used that. I'm not 100% positive, but I believe at USENIX I heard that Oz's package is not compatible with dbm/ndmb/gdbm, just faster. There are some other mini-dbm's around but I don't know anything about their functionality. Maybe dbz from Henry Spencer's CNEWS will work. I didn't try to add dbm since I was having enough trouble already. >I did not use perl's malloc, (should I have?) I did >And I used the shared libraries, (maybe I should not have). I didn't > >Any ideas? >-- >Tom Tkacik | >tkacik@kyzyl.mi.org | To rent this space, call 1-800-555-QUIP. >...!rphroy!kyzyl!tkacik | -- Rex Fowler <rmfowler@texrex.cirr.com> UUCP: egsner!texrex!rmfowler
oz@yunexus.yorku.ca (Ozan Yigit) (05/09/91)
In article <339@kyzyl.mi.org> tkacik@kyzyl.mi.org (Tom Tkacik) writes: >Now the 3b1 does not come with -lndbm, but that didn't stop me. >I just grabbed Ozan Yigit's sdbm package, and used that. While I do not know the reasons for your current problem, I can tell you that with the version of sdbm you have, the same test will fail between 7 and 8. When I wrote sdbm, I considered an attempt to store null key (dsize 0) to be a sure sign of something bizarre going on, and decided to check for it. By some poetic :-) coincidence, the dbm test for perl attempts to store a null key between 7 and 8, and gets caught by this check. If you wish to allow for this, patch sdbm.c with the following diff, and re-compile with -DNULLKEY. enjoy... oz ------------- 11c11 < static char rcsid[] = "$Id: sdbm.c,v 1.2 1991/04/23 13:48:03 oz Exp $"; --- > static char rcsid[] = "$Id: sdbm.c,v 1.3 91/04/23 13:51:39 oz Exp Locker: oz $"; 13a14,20 > /* > * $Log: sdbm.c,v $ > * Revision 1.3 91/04/23 13:51:39 oz > * added #ifdef NULLKEY to allow storing of a key with 0 length, > * and NULL dptr.. > * > */ 59a67,69 > #ifdef NULLKEY > #define bad(x) ((x).dsize < 0) > #else 60a71 > #endif
jmm@eci386.uucp (John Macdonald) (05/10/91)
In article <1991May8.233806.28719@texrex.uucp> rmfowler@texrex.uucp (Rex Fowler) writes: |I'm not 100% positive, but I believe at USENIX I heard that Oz's package |is not compatible with dbm/ndmb/gdbm, just faster. | |There are some other mini-dbm's around but I don't know anything about |their functionality. Maybe dbz from Henry Spencer's CNEWS will work. |I didn't try to add dbm since I was having enough trouble already. I think you got it backwards, or misinterpreted. The dbz package is not a full dbm implementation, but just the subset that it required for storing and looking up news-ids. Sdbm, except for an early preliminary version, is compatible with dbm and ndbm at the functional interface. The only incompatibility is that it uses a different (and faster) hashing function, so that a program linked with sdbm cannot use the same file as a program linked with dbm/ndbm. I wrote a while ago a simple Perl script to dump or load a dbm file using whatever dbm package you perl interpreter was linked with. So, if you build Perl twice, you can use that script to convert from dbm format to sdbm format. You might also use this if you make use of the facility of defining your own hashing function that Ozan provides (if you have some special application that you are using sdbm for, you might be able to come up with a hashing function that is customized to your specific keys to be faster, smaller, or whatever). You might also look into the Berkely HASH package that Ozan has since developed with someone from Berkely (hence the name). I believe that it manages to remove some of the limitations from *dbm - no maximum size for key+data, no holes in the database file. I haven't yet gotten a copy, but expect to start using it shortly. -- sendmail - as easy to operate and as painless as using | John Macdonald manually powered dental tools on yourself - John R. MacMillan | jmm@eci386
rmfowler@texrex.uucp (Rex Fowler) (05/11/91)
In article <1991May10.145034.7299@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes: >In article <1991May8.233806.28719@texrex.uucp> rmfowler@texrex.uucp (Rex Fowler) writes: >|I'm not 100% positive, but I believe at USENIX I heard that Oz's package >|is not compatible with dbm/ndmb/gdbm, just faster. >| >Sdbm, except for an early preliminary version, is compatible with >dbm and ndbm at the functional interface. The only incompatibility . . >You might also look into the Berkely HASH package that Ozan has since >developed with someone Margo Seltzer >from Berkely (hence the name). I believe that it manages to remove ... This is the package I was thinking about, not sdbm like I stated. I never heard a name associated with it so I thought sdbm was it. Anyway, I was under-informed about the compatability issues. I just re-read the winter usenix proceedings and it sounds like it (HASH?) is the way to go. -- Rex Fowler <rmfowler@texrex.cirr.com> UUCP: egsner!texrex!rmfowler