Re: [OPEN-ILS-DEV] Exception running autogen.sh
On 7/17/07, Karen Collier [EMAIL PROTECTED] wrote: I tried running the srfsh test you suggested. It paused for a moment and gave me a new prompt. Following is what appeared in the error log. Does anything in there tell you what's wrong and how I might fix it? [snip] srfsh 2007-07-17 11:48:14 [DEBG:0:osrf_stack.c:73:] We received 1 messages from [EMAIL PROTECTED]/open-ils.cstore srfsh 2007-07-17 11:48:14 [WARN:0:osrf_stack.c:84:] !!! Received Jabber layer error message srfsh 2007-07-17 11:48:14 [WARN:0:osrf_stack.c:94:] * Jabber Error is for top level remote id [EMAIL PROTECTED]/open-ils.cstore], no one to send my message too!!! This indicates the open-ils.cstore processes are not running (or not functioning correctly). A lot of times this has to do with database connectivity issues. If there are DB problems, there should be errors in your osrfsys.log (or wherever you are directing the log files). grep ERR osrfsys.log may give you some useful info. If the following srfsh query works, it indicates a problem with the C libs in particular, most likely a libdbi problem of some sort: srfsh# request open-ils.storage open-ils.storage.direct.actor.org_unit.retrieve 1 Hope this help. -bill
[OPEN-ILS-DEV] opensrf java support - quick intro
With the latest OpenSRF JSON changes, the OpenSRF Java library is now alive. The code lives in OpenSRF/trunk/src/java. org/opensrf/*.java -- essential OpenSRF objects org/opensrf/net/xmpp/*.java -- slim Jabber client code org/opensrf/util/*.java -- generic utility stuff (JSON handling, etc.) Fetch dependencies and build: $ make Create the javadocs: $ make docs The makefile has a very basic 'run' target for running test code. example (requires a running system): $ make run JAVA_EXE=org.opensrf.test.TestClientJAVA_ARGS='/openils/conf/opensrf_core.xml opensrf.settings opensrf.system.time' The Java library is almost completely unused, so it's likely to be a little buggy. It should get some excercise soon when we begin the acquisitions/serials plugins. The only ILS-specific Java code required to talk intelligently to Evergreen is the IDL parsing code in ILS/trunk/Open-ILS/src/java/. Note that both the OpenSRF and ILS repositories have Java test modules for demonstating basic API usage. org/opensrf/test/TestClient.java is a good place to start. Regards, -bill
Re: [OPEN-ILS-DEV] autogen.sh barfing on opac_visible?
On 9/14/07, John Fink [EMAIL PROTECTED] wrote: On 9/9/07, Dan Scott [EMAIL PROTECTED] wrote: Hmm. There are a few possibilities that come to mind, if that's the case: * libdbdpgsql.so might not be linked against libdbdi.so (try $ ldd /usr/local/lib/dbd/libdbdpgsql.so and ensure that libdbi.so is one of the libraries it is linked against) This might very well be it -- libdbdpgsql.so isn't linked against libdbi.so, and recompiling libdbi-drivers with an explicit ./configure --with-dbi-libdir *still* doesn't result in the compiled drivers/pgsql/.libs/libdbdpgsql.so linking against libdbi.so. So something fresh and exciting and new for me to beat my head against. Thanks for your help -- I'll continue to plug away. Are you using the --enable-libdbi configure flag when you run ./configure for libdbi-drivers? Also, what version of libdbi-drivers are you building? -bill -- Bill Erickson Equinox Software, Inc. [EMAIL PROTECTED] http://esilibrary.com/
Re: [OPEN-ILS-DEV] Access 2007
On 9/28/07, John Fink [EMAIL PROTECTED] wrote: I'll be there and jumping for a BoF session. Mike and I will be there... jumping as well ;) -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] osrf_system.c line 138 error
On 10/4/07, Jason Zou [EMAIL PROTECTED] wrote: Hi everyone, Long time no see. I tried to install the 1.2.0 RC 4 on a 'new' FC6 machine this morning. I found the following in the osrfsys.log: opensrf 2007-10-04 12:55:57 [ERR::osrf_system.c:130:] * Running application opensrf.math opensrf 2007-10-04 12:55:57 [ERR:5556:osrf_system.c:130:] * Running application opensrf.dbmath opensrf 2007-10-04 12:55:57 [ERR:5557:osrf_system.c:130:] * Running application open-ils.auth opensrf 2007-10-04 12:55:57 [ERR:5558:osrf_system.c:130:] * Running application open-ils.cstore opensrf 2007-10-04 12:55:57 [ERR:5558:osrf_system.c:130:] * Running application open-ils.reporter-store It seems that in osrf_system.c the fork() does not work. I am wondering what could cause this kind of problem. Jason, This actually isn't an error, but an informational message logged at ERROR level. At first glance, I'm not sure why it's logging as an ERROR, but it's been that way for a while. You can essentially ignore that for now and we can change that to an INFO message. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Make error installing EG
On 10/8/07, Brandon W. Uhlman [EMAIL PROTECTED] wrote: Hey, all. I'm installing EG and OpenSRF from trunk, using Dan's Gentoo instructions. I beat my way through installing all the Perl dependencies, and it appears I've managed to build and install OpenSRF successfully, and build OpenILS successfully. But, when I try to install OpenILS, I get the following error if I run 'make verbose install': -- [ openils_db ] --- Installing... mkdir: cannot create directory `': No such file or directory A build error occured: Error creating make: *** [install] Error 99 I took a look in install.sh, and I think it might be complaining about the fact that it can't find a directory called 'storage-bootstrap', which I can't find either. Makefiles are a bit of hocus-pocus for me though, so I could be off the ball completely, though. A search of the list and the wiki didn't turn up anything relevant either. Any suggestions? This looks like an unset makefile variable, to me. In other words, the makefile is trying to create a directory whose name is stored in a makefile variable and that variable is unset, so it's trying to create a directory called . I would try running make config again to ensure all of the variables have data. When that's done, look at install.conf to check for oddness. Then run 'make verbose install' again. Also, does the user who is running this command have permission to create the necessary directories at install time? Hope this helps, -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] reporter problems
Bill Erickson wrote: Regarding the NOT_FOUND events, those are not necessarily a bad thing. In this case, it may be looking for folders that other users have shared, which probably don't exist yet. Let me rephrase that... It's searching to see if there are any shared folders. I didn't mean to imply that there existed a shared folder that didn't exist :) -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Organisational units
Mike Rylander wrote: On 10/25/07, Roberge, Pierre [EMAIL PROTECTED] wrote: [snip] Finally, I noticed that the OPAC pages are delivered with an ISO 8859-1 encoding. The pages are not explicitely referring to a character set. Did someone experimented something like that? Hrm... I'm not seeing that on any of the dev or demo server, the live PINES site, or other installations; I'm only seeing UTF-8. Bill, any Apache spells that would affect the encoding? I'm not sure about other OS's, but Debian creates /etc/apache2/conf.d/charset which has the default setting: AddDefaultCharset UTF-8 -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Function naming conventions
Scott McKellar wrote: In a number of cases I have found pairs of functions with similar names, where one is lower case with underscores (foo_bar) and the other is camel case (fooBar). One way or another they execute the same underlying code, so they are effectively just different spellings of the same function. For example, in osrf_app_session.c, osrfAppSessionMakeLocaleRequest simply passes all of its arguments to osrf_app_session_make_locale_req and returns the result. My guess is that these redundancies reflect an incomplete transition to a consistent naming convention. However I can't guess which convention is preferred and which is deprecated. If you'll tell me which is which, I can add this cleanup to my janitorial agenda. Exactly... It was an incomplete transition to the camelcase (osrfAppSessionMakeLocalRequest) style of function names. Naturally, it wasn't terribly high on the priority list. Or maybe you'd rather I left things alone. Never! ;) Thanks, Scott. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: Small enhancements to OPAC (CSS instead of center)
Hi: I was working on some clean up of the landing page XHTML / CSS for the current dynamic search. I'm posting this for the purposes of getting a little bit of testing on IE6 before committing the changes. I've tested it on Firefox 2.0.0.9, IE 7, Konqueror 3.5.7, and Opera 9.2.4, and the results are almost identical to the current layout. I've eliminated a number of center tags by using margin: auto; and moved a number of inline style attributes back into layout.css. Looks good in my un-patched VMware IE6. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Holdings Import Program
Dan Scott wrote: On 14/11/2007, Travis Schafer [EMAIL PROTECTED] wrote: Thanks for the code, Travis! [snip] This looks really nice, actually - it's always good to have examples of well-documented code that make the import process more explicit! As xmlReadFile() reads the whole XML document into memory, I suppose it would make sense for large libraries interested in using this approach to chunk the blocks of records up into reasonable sizes (50K records per file or so). import_holdings.pl, which I reworked a bit in trunk, suffers from the same affliction, but what are you gonna do? A SAX version might be in order... Libxml2 and Expat both provide fast and relatively easy to use SAX API's. An Expat example can be found at http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/src/apachemods/mod_xmlent.c (search for XMLCALL and parser) Just a thought.. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] oils_utils.h et alia
Dan Scott wrote: On 14/11/2007, Scott McKellar [EMAIL PROTECTED] wrote: --- Bill Erickson [EMAIL PROTECTED] wrote: Mike Rylander wrote: On Nov 14, 2007 12:00 AM, Scott McKellar [EMAIL PROTECTED] wrote: Where is oils_utils.h supposed to reside? ...and where or what is the openils directory? In ils/trunk/ the only file by named oils_utils.h is in Open-ILS/src/c-apps/, where also reside four .c files that #include it. However the file Open-ILS/src/extras/oils_requestor.c #includes openils/oils_utils.h. I see no directory named openils in the repository trunk. Elsewhere I see references to other header files in this non-existent directory: idl_fieldmapper.h, fieldmapper_lookup.h, and oils_event.h. Of these, two are in the c-apps directory and another is in the apachemods directory. What's up with that? Unless you have some funky links that aren't reflected in the repository, I don't see how some of these files can even compile. These are moved into a single temp dir by the build process and (by default, during the build) live in trunk/ILS/.tmp/ My understanding of Bill's purpose there was to keep everything in one place at build time to reduce confusion back when a whole lot more was being built in the ILS tree -- back when OpenSRF and Evergreen were in one repo. I think awkward evolution defines it a little better. In my opinion, the ILS C headers need the same treatment the OpenSRF headers received when OpenSRF was given its own repository. Any shared headers should go into a new Open-ILS/include/openils/ directory, -Ipath/to/Open-ILS/include should be appended to CFLAGS for the various makefiles, and all C files should #include the fully qualified openils/some_header.h. Thoughts? -bill I agree. Except where there is some persuasive reason to the contrary, the directory structure within the repository should reflect the directory structure of the build environment. That way you don't need to understand the build in order to understand the code. That said, I can live with it either way. What I don't like is having different files #include the same header in different ways: #include oils_utils.h #include openils/oils_utils.h There is some virtue in consistency. +1 for #include openils/oils_utils.h (To put my money where my mouth is, I'm also willing to rework the build accordingly) Dan++ -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] documenting upgrade paths
I've created a new Upgrading section at the bottom of the Server Installation page on the wiki [1]. My goal is to document configuration changes required for upgrading from one version to the next. I'm in the process of back-porting some features from trunk into 1.2 in preparation for 1.2.2, so you will see the beginnings of the 1.2.1 to 1.2.2 documentation. I'll continue to update this as I back-port. The 1.2.0 to 1.2.1 path needs documenting, obviously. Any takers? ;) Comments/suggestions welcome! Thanks, -bill [1] http://open-ils.org/dokuwiki/doku.php?id=server_installation -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] problems with demo server
Mike Rylander wrote: On Nov 20, 2007 1:28 PM, Tara Robertson (BC Pines) [EMAIL PROTECTED] wrote: Hi, I'm not sure who can help fix this... When I search the catalog from within the staff client I get an error message that says: *Fix Me* Error parsing JSON [SyntaxError: missing } after property list] and then a really long bunch of stuff. This is a known issue with 1.2.1-rc1. It's been fixed in SVN, and the next release candidate will be out soon. In fact, we're discussing cutting it today. 1.2.1-rc2 was cut last night to fix this issue and another issue with inactive patron searches in the staff client. The demo servers have been updated. Thanks, -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Integrating automated code analysis tools into regular practice?
Scott McKellar wrote: --- Dan Scott [EMAIL PROTECTED] wrote: snip I just ran PMD (a code copy paste detector from http://pmd.sourceforge.net/) against OpenSRF trunk and it found some large chunks of duplicated code that we could probably refactor into a single shared block of code - rationale being that duplicated code is eventually likely to have a bug fixed in one place but missed in the other. The output is attached. I looked very briefly at the reported code duplications. Most of the duplication is between two different version of the JSON-handling code. Not surprisingly, these two versions have a lot in common. I don't know what Bill plans to do with the older version. I had planned to wade into the newer JSON code, applying my usual fetishes about const-correctness, static functions, and the like. However if we're going to abstract out the commonalities between the new JSON code and the old JSON code, I should hold off on my efforts so that I can do it just once. Ideally, the old JSON code would be removed from the repository over the next 6-12 months. It's probably not worth de-duplicating. The other duplications are in the patch directory. I've never looked at this directory before but it appears to contain patched versions of jabberd code. In the case of nad.c I suspect (but have not verified) that the duplication occurs because of conditional compilation -- two similar blocks of code chosen through #ifdefs. Anyway I don't think we want to mess with jabberd code if we don't have to. I have removed the jabber2d patch files. They were out of date and we generally recommend Ejabberd over jabber2d. Thanks, guys. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] OpenSRF Makefile, source, bourne shell, bash, dash
Jason Etheridge wrote: This came up before (http://list.georgialibraries.org/pipermail/open-ils-dev/2007-July/001451.html), but I was installing OpenSRF on Kubuntu and got this error: CFLAGS=-D_LARGEFILE64_SOURCE make verbose source install.conf make -C src all /bin/sh: source: not found make: *** [verbose] Error 127 source is an built-in shell command, and my /bin/sh was symlinked to dash, which doesn't have source. Bash, of course, does have source. Would it be more portable for us to change source to . everywhere we use it? So instead of source install.conf, for example, we could use . install.conf No objections here. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: osrf_json_object.c (tweaks)
Scott McKellar wrote: I've never used a SAX-style parser, but as I understand it, the idea is to parse the data stream incrementally, and respond to syntactic features as you encounter them. The alternative DOM-style approach is to load the whole thing into memory at once in some kind of data structure, such as a jsonObject. That's pretty much it. [snip] What I'm leading up to is the following suggestion. Some kinds of needs might be well met by something like a jsonParseNextSubobject function, and maybe a jsonParseFirstSubobject. Given a pointer to the middle of a buffer somewhere, it would parse until it reached the end of the next subobject and then return a pointer to a jsonObject representing it. In the example of the Houghton-Mifflin extractor, it would extract one book's worth of jsonObject at a time, including whatever lower-level objects were contained therein. Once you were done with a given book you could free it and grab the next one. However I have no idea whether such a thing would be useful in the context of Evergreen -- nor can I claim to know much about what I'm talking about. The new JSON parser has both DOM and SAX style API's. The DOM API is just a thin wrapper over the SAX core. This makes the DOM internals slightly more obtuse and less efficient, but I'm sure with a little tweaking it can be as fast as a non-SAX implementation. There was no direct purpose for the SAX API when it was developed, but I would like to keep the API intact for potential future use. Currently, no ILS or OpenSRF code is using the SAX API. Mike, your suggestion for replacing SAX callbacks to construct classed objects sounds like a good potential use. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: osrf_json_parser.c (bug fix in _jsonParserError)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Rylander wrote: On Dec 10, 2007 11:53 PM, Scott McKellar [EMAIL PROTECTED] wrote: This patch corrects some problems with _jsonParserError(), which constructs and issues a message about a parsing error. The problems arise in the course of extracting a fragment of JSON text to provide the context of the error. Humbly applied. (Yeah, those loops look silly to eyes in general now, I think. ;) ) Hahaaa... These are going into the hall of fame ;) while( pre 0 ) pre++; while( post = ctx-chunksize ) post--; $1 says I felt like a genius after writing them. - -bill - -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHXqmQTYLnlSoY2kIRAlj3AJwNRPzlQQMsu+0HzHBC6SswlCPt6QCfbXv+ 0nq6exNEbmoeyDfXauc9/bA= =4B2B -END PGP SIGNATURE-
[OPEN-ILS-DEV] new OpenSRF perl dependency (in trunk)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just what everyone wanted for the holidays, right? ;) Well, we've finally found a good Unicode-compliant C-based Perl JSON module called JSON::XS. http://search.cpan.org/~mlehmann/JSON-XS-2.01/XS.pm With some casual testing, the new module gives us a noticeable speedup and reduction of CPU usage in the Perl applications. The new code cuts out large swaths of OpenSRF::Utils::JSON and replaces the logic with about 3 lines of new code. The plan is to commit this new code to OpenSRF trunk in preparation for OpenSRF 1.0. I'll likely make this commit tomorrow after some more testing. I just wanted to give everyone a heads up. - -bill - -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfWzkTYLnlSoY2kIRAifHAJ9Lgq7WYxnHOjewEuaFqoYEtnx0ogCfXB8T 46cLiDLZatlpZZNmd+jDSEE= =fAsw -END PGP SIGNATURE-
Re: [OPEN-ILS-DEV] new OpenSRF perl dependency (in trunk)
Mike Rylander wrote: On Jan 3, 2008 8:16 PM, John Schmidt [EMAIL PROTECTED] wrote: On Thursday 03 January 2008, Bill Erickson wrote: Just what everyone wanted for the holidays, right? ;) Well, we've finally found a good Unicode-compliant C-based Perl JSON module called JSON::XS. http://search.cpan.org/~mlehmann/JSON-XS-2.01/XS.pm I assume that this debian package is the same as above? libjson-xs-perl As long as that is version 2.0 or higher, yes. An earlier 1.x effort by the same name had severe unicode issues, and /will/ break things. Change is committed to OpenSRF trunk. There is a Debian unstable package at http://packages.debian.org/sid/libjson-xs-perl. Of course, 'cpan JSON::XS' also works. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] SPAM: PATCH: storing numbers as strings in jsonObjects
Mike Rylander wrote: On Dec 22, 2007 11:44 PM, Scott McKellar [EMAIL PROTECTED] wrote: These patches are the culmination of several postings on this subject. The overall effect is to store numbers in jsonObjects as strings, rather than as doubles, in order to avoid needless loss of precision in translating back and forth between text and floating point representations. This compiles fine in a full environment, and it's the direction we need to go, so these are applied. We will keep a close eye on things, but I suspect any issues will show up right away, and should be easy to spot with high enough logging. Thanks for all the work on this, Scott. It's been nagging me, and I think this will be a great benefit in the long run. I'd just like to echo Mike's thanks. We really appreciate the hard work and good code, Scott. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Dubious code in mod_xmlbuilder.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott McKellar wrote:
In mod_xmlbuilder.c, xmlBuilderStartElement() contains the following
fragment of code (condensed here for brevity):
char* href = strdup(xmlSaxAttr( atts, href ));
if(href) {
...snip...
}
if(!node) {
apacheError(Unable to parse xinclude: %s, href );
free(href);
return;
}
free(href);
My first thought was: why are we checking the return code of
strdup() to see if it's NULL? If strdup() ever returns NULL we
are almost certainly hosed, and cannot save ourselves simply by
skipping over a short stretch of code.
In fact just after skipping that stretch we may find ourselves
passing the NULL to apacheError(), which probably invokes undefined
behavior.
Upon looking further I realized that xmlSaxAttr() may return NULL,
which we then try to strdup, with unhappy results. My system
segfaults when I try to strdup a NULL.
My guess is that the test for a NULL from strdup() was intended
conceptually to test for a NULL return from xmlSaxAttr(), but it
just wasn't written right. However I don't understand the intent
of the code well enough to try to fix it.
Looks like you've stumbled on another deprecated file. The
functionality of mod_xmlbuilder.c has been replaced by mod_xmlent.c.
I'll remove mod_xmlbuilder.c from the repository.
Thanks again,
- -bill
- --
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHjM24TYLnlSoY2kIRAhNwAKCVwmLn32EBM07GsZnBuZXyvXAD7ACfRbHo
uF8VxTHKsWDyRNMFq08m5lk=
=W2Zl
-END PGP SIGNATURE-
Re: [OPEN-ILS-DEV] component.c -- compile error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott McKellar wrote: I'd submit a patch, but I'm not sure what was intended. It is old, unused, out of date test code. I'll remove from the repository. Thanks Scott, - -bill - -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjMy1TYLnlSoY2kIRAixWAJ0WJ7yC68+2g/NnSQKZw/mNOsOApACfSG/Q kamg23rQeXZKCj7KhEo9nu8= =oe9J -END PGP SIGNATURE-
Re: [OPEN-ILS-DEV] squid proxy for z3950 searches.
Will ladda wrote: hello, we are using evergreen-1.2.1.0, behind a firewall. I have a squid proxy available that will handle non-standard ports. Is there a way to config evergreen to use a http proxy for z3950 searches, z3950.loc.gov:7090 or zcat.oclc.org:210? Did a quick search... It's not explicitly mentioned in the Perl ZOOM docs [1], but the C docs [2] claim to accept a proxy server connection option . My hunch is the Perl layer would just pass the option down if provided. Assuming that's true, it would be a case of adding a new proxy setting in opensr.xml (in the z39 server section), reading the value in do_service_search() in Z3950.pm, then passing the value into the OpenILS::Utils::ZClient-new() call in Z3950.pm. [1] http://search.cpan.org/~mirk/Net-Z3950-ZOOM-1.21/lib/ZOOM.pod#new() [2] http://www.indexdata.dk/yaz/doc/zoom.tkl -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] osrf_json_parser.c: memory leak when handling error
Scott McKellar wrote: In _jsonInsertParserItem(), we receive a pointer to a jsonObject named newo. Normally, newo is incorporated into the object that the parser is building. Whoever receives the object built by the parser is responsible for freeing it. However: if the sub-object currently being processed by the parser is neither a hash nor an array, the default branch of the switch/case structure merely writes a message to stderr, without incorporating newo into the growing jsonObject. My first impulse was to add a line to the default branch, to free newo. Then I noticed that, after the switch/case, we reference newo again. So we don't want to free it as I had first thought. The end result, if this situation ever occurs, is that we leak newo. We may hang on to it for a while as the current object, but since we don't incorporate it into the object wo're building, we eventually lose it. Presumably this situation never arises in practice, or happens so rarely that the memory leak isn't worth worrying about. For all I know it may be impossibe for this situation to arise at all, even for arbitrarily mangled JSON input text. I haven't tried to unravel all the logic. However the handling of this situation looks like leftover debugging code rather than proper error reporting. At a minimum we should use the usual logging functions instead of writing directly to stderr. In addition, I'm not sure that it's appropriate to point p-current to newo in this situation. I'd submit a patch, but I don't trust myself to guess what the right response is. Yep, that's old debugging code. The switch in _jsonInsertParserItem() should probably be changed to an if/else ( JSON_HASH vs. JSON_ARRAY). There's no other way to reach that chunk of code. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] osrf_json_xml.c: memory leak and apparent bug
Scott McKellar wrote: At the end of startElementHandler(), there is a branch of code that runs when the name passed in is boolean. It constructs a jsonObject of type JSON_BOOL but doesn't do anything with it. The pointer goes out of scope and the memory leaks. As a result, this branch of logic has no effect at all, except to leak memory. I would have expected a call to appendChild(), and probably to osrfListPush() as well. However the other branches are not completely consistent in this regard -- for null we create a jsonObject and pass it to appendChild(), but we don't call osrfListPush() for it. Given the wait-and-see approach of SAX parsing, some data has to be pushed onto various stacks for processing in later callbacks, hence the inconsistencies in the code branches. For boolean objects, we have all the data we need at element parse time, so all that's left is call appendChild() to shove the un-used boolean object onto the growing JSON object. I'll go ahead and commit that fix. Thanks for the eyes, Scott. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Adding Z39.50 host
Bill Erickson wrote: Bill Ott wrote: [snip] It reports an error: ZOOM error 100 Unspecified error (addinfo: Expected CONSTRUCTED PDU not found (pdu error: 3002)) from diag-set 'Bib-1' I don't quite know how to parse this, but the $rs-option() is what makes the difference. For some reason, fetching the full record with no holdings from the specified Z server is returning data the Z client can't understand. Of course, the Z server may not support that option or may have another name for it. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Adding Z39.50 host
Bill Ott wrote:
Has anyone else added additional Z39.50 hosts to search?
I thought this would be a simple matter of adding the host into the
opensrf.xml z3950 section. However, the few I've tried have failed.
Am I missing something?
My osrfsys.log, it looks like the initial search completes, in this case
returning 2 hits
[snip]
From my gateway.log. It looks like this is actually an error while
trying to report an error.
It sure does...
[snip]
So, I threw the following at the perl debugger, and sure enough, I get
two records.
use ZOOM;
$host='library.usc.edu';
$port='2200';
$db='unicorn';
$conn = new ZOOM::Connection($host, $port,
databaseName = $db);
$conn-option(preferredRecordSyntax = usmarc);
$rs = $conn-search_pqf('@attr 1=4 @attr 4=6 learning perl');
$n = $rs-size();
print $rs-record(0)-render();
I augmented your script to look more like the ILS code and I've been
able to condense it down to a repeatable error.
If I change the last few lines like so:
$n = $rs-size();
$rs-option(elementSetName = FI); # full records with no holdings
eval { print $rs-record(0)-render(); };
if($@) { die [EMAIL PROTECTED]; }
It reports an error:
ZOOM error 100 Unspecified error (addinfo: Expected CONSTRUCTED PDU
not found (pdu error: 3002)) from diag-set 'Bib-1'
I don't quite know how to parse this, but the $rs-option() is what
makes the difference. For some reason, fetching the full record with
no holdings from the specified Z server is returning data the Z client
can't understand.
-bill
--
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Adding Z39.50 host
Bill Ott wrote: Doesn't it figure that I'd start testing with one that didn't support that option. If nothing else, I learned a good bit about ZOOM, Yaz, and z39.50 in general. You and me both ;) The following entry works quite nicely. olink hostolc1.ohiolink.edu/host port210/port dbinnopac/db attrs tcncode12/codeformat1/format/tcn isbncode7/codeformat3/format/isbn lccncode9/codeformat1/format/lccn authorcode1003/codeformat3/format/author titlecode4/codeformat3/format/title issncode8/codeformat1/format/issn publishercode1018/codeformat3/format/publisher pubdatecode31/codeformat1/format/pubdate item_typecode1001/codeformat1/format/item_type /attrs /olink Excellent! -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Debian install instructions: plpgsql barf
John Fink wrote: Hey folks, Following along (and editing some of) the Dokuwki instructions at http://open-ils.org/dokuwiki/doku.php?id=installing_evergreen_1.2_on_debian_etch_x86_32-bit, I get the following errors when doing a make install for Evergreen-ILS-1.2.1.2. I've installed the Debian etch postgresql-plperl-8.1 package, but something else is probably missing as I'm doing this install on as minimal a Debian machine as possible; basically nothing extra except openssh-server. jf BEGIN psql:000.english.pg81.fts-config.sql:9: ERROR: language plpgsql does not exist HINT: Use CREATE LANGUAGE to load the language into the database. psql:000.english.pg81.fts-config.sql:11: ERROR: current transaction is abo rted, commands ignored until end of transaction block psql:000.english.pg81.fts-config.sql:12: ERROR: current transaction is abo rted, commands ignored until end of transaction block psql:000.english.pg81.fts-config.sql:13: ERROR: current transaction is abo rted, commands ignored until end of transaction block psql:000.english.pg81.fts-config.sql:14: ERROR: current transaction is abo rted, commands ignored until end of transaction block (and so on so on ad infinitum, a bunch of aborts basically) I think those docs might need an additional: su -c createlang plpgsql evergreen - postgres -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Register Workstation broken in trunk?
Bill Ott wrote: I can't use the client to register new client installs under trunk. I receive the following: Call to [open-ils.actor.user.perm.highest_org] failed for session [1202309547.426312.120230954716702], thread trace [1]: Can't call method id without a package or object reference at /openils/lib/perl5/OpenILS/Application/AppUtils.pm line 781. Being impatient, I can manually insert the client into actor.workstation and hack the chrome/ws_info accordingly, after which the client runs normally. So it seems to be strictly related to the new registration. I've been working on some changes in that area. When was the last time you updated from subversion? -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Register Workstation broken in trunk?
Bill Ott wrote: I've been working on some changes in that area. When was the last time you updated from subversion? Just this morning. At revision 8656. I've committed some fixes which should resolve the problem. Thanks, Bill. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] What's up with object.c?
Scott McKellar wrote: object.c doesn't compile any more. Do we need to fix it, or can we get rid of it? object.c is dead. I need to double check first, but the entire objson directory should be deprecated at this point. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Acq development request for consideration
Carri L. Oviatt wrote: Assuming that the option will be given to create item/holding records at the time an order is created, is it possible to place that option on the individual PO line rather than for an entire PO? Hi, Carri This is quite do-able with the existing architecture. I imagine there will be a variety of criteria for determining which lineitems create holdings at order time. I can see one of those criteria being a simple create holdings checkbox (or some such) next to each lineitem at PO creation time. Is that more or less what you are getting at? -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] 2 important changes to opensrf_core.xml in OpenSRF trunk (changeset 1253 -- multi-domain mode)
The following configuration chunk: config opensrf domains domainlocalhost/domain /domain ... has been simplified to: config opensrf domainlocalhost/domain ... (NOTE: The above change is necessary in ~/.srfsh.xml as well!) Also, the router configuration near the bottom of the file has been given a routers wrapper element so that additional routers may be configured: config ... routers router !-- router configuration goes here -- /router /routers /config I have updated the OpenSRF and ILS example files. I've also added an additional multi-domain example file. http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/examples/opensrf_core.xml.example http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/examples/opensrf_core.xml.example.multidomain --- What is all of this? OpenSRF now has the ability to run in multi-domain mode. In multi-domain mode, different jabber domains handle different OpenSRF services. One router per domain is launched to handle requests to that domain. Certain clients are allowed access to certain domains only. With this, we can physically separate an untrusted client from sensitive resources. This crudely drawn diagram might just confuse you more ;) http://open-ils.org/documentation/opensrf-multi-domain.jpg In this setup, the client and the open-ils.cstore service are logged in to 2 different jabber domains. Additionally, open-ils.cstore is not registered with the router on the clients domain (public.domain). In a nutshell, the client has no way to send requests directly to open-ils.cstore. It's forced to go through a protected service first, which will enforce authentication/authorization, before it can access sensitive data. The old approach, as seen in the HTTP gateway, was to define an explicit list of services that the gateway could communicate with. With this change, the gateway will not need to manage its own access list, since it won't have access to private services anyway. Doesn't this complicate things? -- These features are optional and they only require changes to opensrf_core.xml, plus the addition of a host in the Ejabberd config. Running with two domains will eventually be the default behavior, but the install process will need to be streamlined before we make that step. Do I need to run 2 jabber servers for multi-domain mode? -- Not if you are using Ejabberd. Ejabberd allows you to host multiple domains within a single Ejabberd instance. Because of this, no additional Jabber processes or domain-to-domain network IO is required. Do I need to manually launch more routers? -- No. The router process will automatically launch as many routers as you have configured. For those of you who have made it this far, I realize it's a lot to digest. I've had my head in the code most of the afternoon and I'm sure I'm leaving out some crucial detail that will make all of this clear. If anyone has any questions about any of this, fire away... -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] transport_session.c: use of $HOSTNAME
Scott McKellar wrote: Similar questions apply to two other cases where we look for $HOSTNAME: 1. osrfChatMkAuthKey(), in osrf_chat.c 2. osrfSystemBootstrapClientResc(), in osrf_system.c Scott McKellar http://home.swbell.net/mck9/ct/ --- Scott McKellar [EMAIL PROTECTED] wrote: In session_connect() we have have the following fragment: /* the first Jabber connect stanza */ char* our_hostname = getenv(HOSTNAME); size1 = 150 + strlen( server ); char stanza1[ size1 ]; snprintf( stanza1, sizeof(stanza1), long message abbreviated here %s %s, username, our_hostname ); My first observation is that in calculating size1 we presumably should have used strlen(our_hostname), not strlen(server), since server is not included in the formatted stanza that we build. I could fix that myself. But what I'm writing about is the use of the environmental variable $HOSTNAME. Is there a reason why we don't get the host name by calling gethostname()? Normally the two methods will yield the same result. The difference is that the user can change the value of $HOSTNAME to anything he likes, or even unset it entirely. The resulting stanza that we build here will then be different accordingly. But gethostname() is not affected by changes in $HOSTNAME, as I confirmed by a little experimentation. Unless we want the user to be able to change the contents of this stanza, I suggest that we use gethostname(). Give me the go-ahead and I'll prepare a patch to do so Hi Scott, In each of these cases, the hostname is used for informational purpose or to seed a random string. gethostname() matches the original intent and, to me, looks cleaner. I say go for it for all of the mentioned instances. Thanks, -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] check out problem
Jeff Edminster wrote:
I’ve managed to load bibs, items, and borrowers. I can search and place holds
on items without a problem. When I attempt to do a check out, however, I get
the following error:
Check Out Failed #3
{
desc:null,
ilsevent:1609,
pid:4425,
servertime:Mon Mar 10 15:01:55 2008,
stacktrace:/openils/lib/perl5/OpenILS/Application/AppUtils.pm:811
/openils/lib/perl5/OpenILS/Application/Circ/Circulate.pm:1023
/openils/lib/perl5/OpenILS/Application/Circ/Circulate.pm:1023,
textcode:CONFIG_RULES_RECURING_FINE_NOT_FOUND
}
Any ideas?
Jeffrey,
This means the circulation rules calculation resulted in a recurring
fines rules that does not exist in your database. The recurring fines
rule is calculated with a script call to
/openils/var/circ/circ_duration.js, which loads some values from
/openils/var/circ/circ_item_config.js. If you have changed nothing, then
all circulation request will results in rules called default. If there
are no default rules in your DB (I don't recall if any are included
with the default DB seed data), they will need to be created. These
rules can be created in the Circulation and Hold Rules section of the
configuration CGIs (http://myhost/cgi-bin/config.cgi).
Hope this helps,
-bill
--
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
Re: SPAM: Re: [OPEN-ILS-DEV] osrfHash: alternative implementation
Scott McKellar wrote: --- Mike Rylander [EMAIL PROTECTED] wrote: snip I've been mulling this over for a couple days, and I've got to disagree with Bill. IFF mid-iteration changes (removal, in particular, of a key) can be handled transparently and safely, and that guarantee can be carved into the requirements for the API, then I think it is a decidedly /good/ thing. Removal is the scenario I had in mind as well. For some reason, mid-iteration changes seem dangerous to me, though I have no concrete examples to support my paranoia. However, if, as Mike pointed out, they can be handled transparently and safely, then I'm all for it. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Typo in rdetail_copyinfo.xml
On Sunday 20 April 2008 11:20 Ben Ostrowsky wrote: /openils/var/web/opac/skin/default/xml/rdetail/rdetail_copyinfo.xml includes the text nowrap='nowarp' as an attribute of the td that holds the name of the status (as a column header). I haven't found a browser that fails to render it properly as a result, but just in case there's a browser that expects the value 'nowrap', we should probably fix that. Fixed, though lack of good warp protection may haunt us! ;) Thanks, Ben. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] SIP2: Unexpected Results from Patron Info Request (Msg 64)
David J. Fiander wrote: Brandon, That makes sense. This probably hasn't come up before because there are few SIP clients that implement lots of enhanced functionality, like renewing and paying fines at the terminal. Right. I can also see cases where the data is displayed to the user, in which case titles are a good thing to return. The code that handles what data gets put into the holds, overdue, etc, fields isn't in my SIP protocol code; it's part of the ILS backend module that I call. So, Bill's the one that decided to return the title, rather than the barcode. Well, my test stub code returned titles, because that makes it easy to read the packets, and Bill just mirrored that. Either way, it's pretty straight-forward. you just need to edit the ILS::Patron::hold_items() function to return the right stuff from the patron record. In Brandon's case, we're talking about Patron::overdue_items() and Patron::charged_items(), though, right? Shortly, I'll be implementing an org unit setting to support the suppression of holds information in patron information requests. (In the case where the client doesn't care about the holds information and a patron has 50+ holds, it's just passing around a lot of unnecessary data.) Along those same lines, we could add an additional org unit setting to determine what data is returned from the overdue|charged_items() calls... -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Dead file: mod_xmlbuilder.h
Scott McKellar wrote: There used to be a file mod_xmlbuilder.c, but it has been removed from the trunk source tree. We should presumably remove the corresponding header file mod_xmlbuilder.h as well. It is nowhere #included. Removed, along with some other dead code. Thanks, Scott. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: apachetools.c (performance)
On Tuesday 13 May 2008 11:54 Scott McKellar wrote: This patch is mostly a performance tweak, but also tidies up a few things. Applied. Thanks for the cleanup! -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: osrf_hash[ch] (new implementation)
On Sunday 06 April 2008 8:16 Scott McKellar wrote: If you prefer, I can wait till you apply yesterday's patches and create new patches then. Or I can send you entire files instead of patches. Whatever is least troublesome for you. Scott, would it be possible to get an updated set of osrf_hash_c and osrf_hash_h patches? There's now enough matching code between the patches and the version in the repository to break things good. Thanks, Scott. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: osrf_legacy_json.c (miscellaneous)
On Sunday 13 April 2008 12:20 Scott McKellar wrote: This patch tweaks a few things. 1. In json_parse_json_string() we declare a character array buff[], fill it with nuls, and never refer to it again. I eliminated it. 2. A few lines below that, we use memset() to clear a three-character buffer. I replaced the memset() with an initializer clause. 3. in json_handle_error() we were relying on the osrf_clearbuf macro to add a terminal nul. However the plan is for this macro to become a no-op someday. I added the nul manually. Also applied. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: osrf_stack.c (camel case)
On Sunday 13 April 2008 10:18 Scott McKellar wrote: This patch replaces some deprecated identifiers with their camelCase equivalents. osrf_app_session == osrfAppSession osrf_message == osrfMessage osrf_message_free == osrfMessageFree Applied. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: oils_requestor.c (camel case)
On Sunday 13 April 2008 9:53 Scott McKellar wrote: This patch replaces a deprecated identifier with its camelCase equivalent. osrf_app_client_session_init == osrfAppSessionClientInit Applied. Thanks, Scott. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] SPAM: autoconf support for openSRF (resubmission)
On Wednesday 14 May 2008 1:40 Kevin Beswick wrote: This is an initial patch supporting the effort of porting OpenSRF to the GNU autotools. The goal of this patch is to enable someone to generate a configure script using autoconf, allow someone to choose various install options through the generated configure script, and to remove the need for the install.conf file. The configure script makes various checks based on the dependencies of openSRF, allows users to customize the install directories, and select various install options (whether or not to install python modules, java libraries, legacy json headers). It outputs the results of these custom checks/settings at the end of the default configure script output. The automake Makefile.am's are not included as of yet, instead only Makefile.in's are included so that configure can generate appropriate Makefiles based on the already existing ones. To test: automake -a autoconf ./configure [--option] make make install Some comments: When I invoke 'automake -a', I get some warnings: configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). configure.ac: installing `./install-sh' configure.ac: installing `./missing' automake: no `Makefile.am' found for any configure output Should I fear these? -- It's also important to note that if you run ./configure as a non-root user, it may die with: checking for ejabberd... no configure: error: *** ejabberd not found, aborting /usr/sbin, where ejabberd lives on my test system (Debian Lenny), is not in my path. This works fine: PATH=$PATH:/usr/sbin/ ./configure I ran configure with the defaults and later realized that I needed to update my tmp_dir, since it was already in use by another user on this system. I ran: PATH=$PATH:/usr/sbin/ ./configure --with-tmp_dir=/tmp/osrftmp The configure output reports: Tmp dir location: /tmp/osrftmp However, Makefile[.in] still shows TMP=/tmp/ilstemp, which causes my 'make' attempts to fail. Should re-running configure update that? It's likely my own autoconf ignorance is coming into play here... - Minor nit: Can we make the default TMP directory /tmp/osrftmp (or similar)? --- To prevent filling up the file, can we wrap the mod_placeholder insertion (in 'make install') in a check to see if it's needed? For example: if [ ! $$(grep mod_placeholder /etc/apache2/httpd.conf) ]; then \ echo #LoadModule mod_placeholder /usr/lib/apache2/modules/mod_placeholder.so \ /etc/apache2/httpd.conf; \ fi; \ make -s -C src install -- Kevin, this is looking /very/ good. I didn't realize you had gotten this far until I went for it. Kudos. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: osrf_app_session.[ch] (camel case)
On Saturday 17 May 2008 3:59 Scott McKellar wrote: These patches eliminate two deprecated identifiers in favor of their camel case equivalents:   osrf_app_client_session_init   osrf_app_session All other instances of these identifiers have already been eliminated from the code base. Applied with thanks. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] SPAM: autoconf support for openSRF (resubmission)
On Friday 16 May 2008 11:29 Kevin Beswick wrote: On Fri, May 16, 2008 at 11:09 AM, Bill Erickson [EMAIL PROTECTED] wrote: -- It's also important to note that if you run ./configure as a non-root user, it may die with: checking for ejabberd... no configure: error: *** ejabberd not found, aborting /usr/sbin, where ejabberd lives on my test system (Debian Lenny), is not in my path. This works fine: PATH=$PATH:/usr/sbin/ ./configure Thanks for pointing that out, I will fix this. it occurred to me while talking autoconf with Dan S. that a check for the existence of Ejabberd isn't necessary. While OpenSRF requires a jabber server to run, it does not depend on Ejabberd in particular. I say just remove that check. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Z39.50 target
On Monday 26 May 2008 8:57 Mike Rylander wrote: On Sat, May 24, 2008 at 8:03 PM, Grant Johnson [EMAIL PROTECTED] wrote: snip This is the plan for 1.4, though I don't think Debian has a modern enough YAZ package, which means installing YAZ from source. The EG installer makefile will handle this for you: http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/src/extras/Makefile.install $ make -f Makefile.install install_yaz -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] INNOPAC
On Friday 30 May 2008 10:26 Grant Johnson wrote: Hellooo, Has anyone out there added a z39.50 cataloging target to an INNOPAC Z server? I don't get all this BATH stuff... I take showers! usask for example! usask !-- usask does not require username/password -- nameusask/name hostsundog.usask.ca/host port210/port dbINNOPAC/db record_formatF/record_format attrs tcncode12/codeformat1/format/tcn isbncode7/codeformat6/format/isbn lccncode9/codeformat1/format/lccn authorcode1003/codeformat6/format/author titlecode4/codeformat6/format/title issncode8/codeformat1/format/issn pubdatecode31/codeformat1/format/pubdate /attrs /usask Hi Grant, Would you mind setting record_format to b (brief) to see if that works? Also, is there anything interesting in the log files? -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] OpenSRF autotools support
On Friday 30 May 2008 11:08 Kevin Beswick wrote: This patch adds GNU autotools support to the OpenSRF project. By having autotools support, one can generate the appropriate configure script and Makefiles for OpenSRF by running automake and autoconf. They can then configure, compile and install OpenSRF by running the generated files. The configure script checks dependencies, sets install locations, compiler flags, install options, etc, and transfers those settings to the Makefiles. To prepare the package (add missing files etc), generate makefiles and configure script, run the following commands: aclocal libtoolize --force automake -a automake autoconf To configure, compile, and install, run the following commands: ./configure make make install Hi Kevin, I checked out a fresh copy of OpenSRF trunk and ran through the steps. The only departure I made was to provide a new TMP directory. The compilation fails when it can't find the OpenSRF header files. % aclocal % libtoolize --force % automake -a configure.ac: installing `./install-sh' configure.ac: installing `./missing' src/c-apps/Makefile.am: installing `./depcomp' src/libopensrf/Makefile.am: installing `./compile' Makefile.am: installing `./INSTALL' % automake % autoconf % PATH=$PATH:/usr/sbin ./configure --with-tmp_dir=/tmp/o1 ... % make ... osrf_json_object.c:20:25: error: opensrf/log.h: No such file or directory ... I see a -I/include/ in the compile line. Does that need to be changed to a relative path (or an explicit path to /mypath/OpenSRF/trunk/include)? Lookin good... -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] FW: Problem with autogen
On Monday 09 June 2008 1:30 Frances Dean McNamara wrote: Hi Dan, I ran the settings-tester.pl script with the following output, using your modification for 1.2.2 (output below). It looks like it clears except for a linking problem with libdbi. Can this linking problem account for the autogen error I am getting? Yes, if libdbi is not set up correctly, cstore, and subsequently autogen, will fail. Quickest fix is to grab http://svn.open-ils.org/trac/ILS/export/9799/trunk/Open-ILS/src/extras/Makefile.install then run: % make -f Makefile.install install_libdbi This will install libdbi and Postgres drivers from source. Then, restart C services (osrf_ctl.sh -a restart_c) and you should be good to go. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] FW: Problem with autogen
On Monday 09 June 2008 5:13 Bill Erickson wrote: On Monday 09 June 2008 1:30 Frances Dean McNamara wrote: Quickest fix is to grab http://svn.open-ils.org/trac/ILS/export/9799/trunk/Open-ILS/src/extras/Make file.install There is actually a typo in this version of the file, which has since been repaired. The latest is at http://svn.open-ils.org/trac/ILS/export/9809/trunk/Open-ILS/src/extras/Makefile.install -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Evergreen Staff Client login network
On Tuesday 10 June 2008 12:41 Charlene Woo Ling wrote: Hi I have installed Evergreen ILS 1.2.2.0 on Ubuntu 7.04 based on the instructions given at http://open-ils.org/dokuwiki/doku.php?id=installing_evergreen_on_ubuntu_7.0 4 Everything more or less ran fine except on the last lap when i started up the client xulrunner application.ini The host name resolved and tested fine but when I try to login using user name admin and password open-ils it gave the network failure problem. When I access the web interface I get the JSON error. for the fqdn I use pc2665ubuntu.ttec.co.tt and for the hostname I put the domain name so both the fqdn and hostname are the same. perl -MNet::Domain=hostfqdn -e print hostfqdn(); 'hostname -f' I have double and triple check my config files where the user name and password needs to be changed but I cannot see any error. I checked various formums for resolving the error but I still cannot get through. It has been a long time I have been fighting up with this problem. Can anybody HELP ? Thanks a mil Charlene, I would recommend taking a step back and testing the system at a lower level. Can you log in from srfsh? http://open-ils.org/dokuwiki/doku.php?id=installing_evergreen_1.2_on_debian_etch_x86_32-bit#testing_connections_to_evergreen -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] offline blocked list
On Monday 16 June 2008 10:24 Bill Ott wrote: Strange doings with the offline blocked list. When running offline-blocked-list.pl, I end up missing one user. I don't see any rhyme or reason for which user it drops, but it seems consistent. I've narrowed it down to this line: next if $barcode =~ /^oils/o; # hack to chop out the oils_requestor prompt I find one of the results that looks like this: oils# 123456 Replacing the noted hack with: $barcode =~ s/oils#\s+//; Works as long as there are values for each, otherwise you'll end up with something like: oils L So, another check, or a different substitute should finish it off. Thanks for tracking that down, Bill. Alternately, you can change the if(1) test at line 9 to if(0) and take advantage of the older version of the script, which relies on open-ils.storage instead of making an external call to oils_requestor. (The oils_requestor version was added to accommodate speedier processing of blocked lists with hundreds of thousands of patrons.) -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCHES: OpenNCIP (Attn: David) and OpenILS::SIP
On Wednesday 18 June 2008 5:20 Brandon W. Uhlman wrote:
Hi, all.
Attached are two patches for SIP2 support in Evergreen -- one to the
OpenNCIP server module that speaks to external services, and one to
OpenILS::SIP, Evergreen's connecting glue between OpenNCIP and the
OpenSRF-y underbelly.
First, due_dates.patch makes some relatively trivial changes to
MsgType.pm in OpenNCIP.
Due dates being returned by the ACS to the SC outside the
handle_checkout() method were in a different format than those being
returned by handle_checkout(). Specifically, handle_checkout()
returned the due_date result direct from the SIP interface (in our
case, Evergreen). The other due_dates (for example, in handle_renew)
were trying to be parsed through SIP::timestamp(), which expects a
Unix timestamp, and was getting an EG due date string. It would fail
being parsed, and the SC would get a duedate of 1969-12-31 (or so)
back instead.
The SIP2 standard specifically says that the ACS 'can send this date
field in any format it wishes'. Since the format currently being
returned by Evergreen and used in handle_checkout seems to be working
with most SCs, and since I like consistency, I elect to use that
format. Larry Wall once said about Perl, it generally does what you
want, unless what you want is consistency. We can do better. :)
I agree with the spirit of this patch, but I'll let David comment on it in
case he has any grand schemes I'm not aware of.
My second patch resolves a problem where some SCs expect message 64,
the Patron Information Request, to return item barcodes instead of
item titles when asking for a list of charged/overdue items, so that
the results can be used in an Item Information Request to ask the ACS
for more information about the item.
This patch introduces a new configuration stanza, options in the
implementation_config of an institution in oils_sip.xml. Currently,
the only option is 'msg64_summary_datatype', which can have a value of
'barcode', which causes message 64 responses to return item barcodes
instead of item titles, the previously default behaviour in
Evergreen's SIP2 implementation. Setting any value other than
'barcode', or not setting this value at all will result in message 64
returning titles.
+ if($return_datatype[0]-{value} ne 'title') {
+ push( @o, __circ_to_barcode($self-{editor}, $circid));
+ } else {
+ push( @o, __circ_to_title($self-{editor}, $circid));
+ }
In this case, if the option is not set, then it will return a barcode. How
about we change that first test to:
if($return_datatype[0]-{value} eq 'barcode') { ...
The patch updates both the sample oils_sip.xml configuration file, and
Patron.pm in the SIP2 implementation, where the charged_items()
lookups are made.
These patches may not qualify as SIP2-fu, but they are little steps
toward making the default shipping configuration of Evergreen a little
bit more humane, which I think is a desirable thing.
A worthy goal ;)
DCO included, just in case these aren't trivial.
Thanks for the code, Brandon. I'd qualify these as anything but trivial.
I'll let you comment on my statement above, then get these committed.
-bill
--
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCHES: OpenNCIP (Attn: David) and OpenILS::SIP
On Wednesday 18 June 2008 8:07 Grant Johnson wrote: Hey, Is there a LookupUserResponse available in OpenNCIP yet? That's the only piece I need for our ILL implementation to RELAIS. Hi Grant, The OpenNCIP project only provides SIP2 at this point, no NCIP yet. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Help understanding Directories in Evergreen
On Wednesday 18 June 2008 11:39 John van Rassel wrote: Hello again, I am just having a few issues trying to understand the different directories in Evergreen. When I look in ~/Evergreen-ILS-1.2.2.0 on both the server I setup, and the vmware images, there are two directories of note; and Evergreen directory and an Open-ILS directory. When I ran the canuck.patch, I noticed it patches the files in the Open-ILS directory. When I build a new client though, it uses the ue.xhtml file from the ~/Evergreen-ILS-1.2.2.0/Evergreen directory. I guess what I am really trying to understand is: Why does this extra Evergreen directory exist. Excellent question, John. The Evergreen directory was initially created to act as the PINES implementation of OpenILS, which was called Evergreen. As such, it contains almost exclusively PINES-specific files. The only set of files in the Evergreen directory that are not PINES-specific are the user editor files. They were originally supposed to act as the PINES skin of the user editor, but have become the supported and default version, which is why the staff client copies those files into place at build time. The plan moving forward is to move the Evergreen version of the user editor files back into the Open-ILS directory and to move the PINES-specific files into an external repository or the proposed ILS-Contrib repository to reduce confusion. After that, we can remove the Evergreen directory from the repository entirely. These changes are proposed for Evergreen 1.4. Clear as mud? ;) -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCHES: OpenNCIP (Attn: David) and OpenILS::SIP
On Wednesday 18 June 2008 10:13 Brandon W. Uhlman wrote:
Quoting Bill Erickson [EMAIL PROTECTED]:
This patch introduces a new configuration stanza, options in the
implementation_config of an institution in oils_sip.xml. Currently,
the only option is 'msg64_summary_datatype', which can have a value of
'barcode', which causes message 64 responses to return item barcodes
instead of item titles, the previously default behaviour in
Evergreen's SIP2 implementation. Setting any value other than
'barcode', or not setting this value at all will result in message 64
returning titles.
+ if($return_datatype[0]-{value} ne 'title') {
+ push( @o, __circ_to_barcode($self-{editor}, $circid));
+ } else {
+ push( @o, __circ_to_title($self-{editor}, $circid));
+ }
In this case, if the option is not set, then it will return a barcode.
How about we change that first test to:
if($return_datatype[0]-{value} eq 'barcode') { ...
I guess I'm editorializing that barcode should be the default return
value if the option is unset. :)
Seriously? Oops. I have no problem with your suggested adjustment.
Patch to Patron.pm and oils_sip.xml.example applied with the above change.
Thanks, Brandon!
-bill
--
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
[OPEN-ILS-DEV] demo data generation tools in ILS-Contrib
Hi all, Jason Etheridge and I have separately developed some tools to autogenerate patron, volume, and copy data for demonstration purposes. Jason's is cool, because it actually scrambles census data into mostly-realistic looking patrons. My copy/volume script is much simpler, taking advantage of a lot of random number/string generation for barcodes and call numbers. They do, in their own way, get the job done, though. I'd like to propose that these two projects be added to the ILS-Contrib repository. With Dan Scott's blessing, they could even live in the existing import_demo project. They are documented here: http://open-ils.org/dokuwiki/doku.php?id=advocacy:demonstration_data Comments? Thanks, -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] segfault in JSON object re-use code
On Monday 07 July 2008 8:46 David J. Fiander wrote: On 7-Jul-2008, at 19:38 , Bill Erickson wrote: This is also right, although it's incomplete. The next line of code better be freeObjList = unused; Otherwise, you just keep dropping pointers. Yep, it's there. Thanks, David. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] WWW::Redirect
On Wednesday 09 July 2008 10:39 Doug Kyle wrote:
I've created a lib_ips.txt file under /openils/conf, and have these
lines in startup.pl:
use OpenILS::WWW::Redirect qw(/openils/conf/opensrf_core.xml);
OpenILS::WWW::Redirect-parse_ips_file('/openils/conf/lib_ips.txt');
No Redirecting is being done and nothing from Redirect.pm is being
logged. What am I missing?
Hi Doug,
In /etc/apache2/eg_vhost.conf, remove this:
RedirectMatch 301 ^/$ /opac/en-US/skin/default/xml/index.xml
And add this:
LocationMatch ^/$
SetHandler perl-script
PerlHandler OpenILS::WWW::Redirect
PerlSendHeader On
allow from all
/LocationMatch
-b
--
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Staff client self-check/express-check mode
On Thursday 10 July 2008 3:36 John Fink wrote: I'm rallly interested in this -- we've got some self check stations now but they're pretty expensive. One item though -- how does this work with a thumper? Or is there some other method used to desensitize? Hey John, This is probably a dumb question, but I feed on details ;) How exactly would you like/expect the self check station to handle desensitization? -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] purging objson (legacy json) for opensrf 1.0 / Evergreen 1.4
The topic of purging objson, which implements the old-style, comment-embedded class hints for OpenSRF objects came up recently during a discussion of the new autotools infrastructure. OK, fine, I brought it up. The current objson setup provides support for parsing old-style objects via a separate API call (used in the opensrf gateway) and an implementation of the old jsonObjectIterator API, which changed with the latest JSON code. The original idea for the legacy json layer was that the system may need to support old and new-style JSON objects for Evergreen 1.4. However, if we are in agreement that there is no need to support old-style JSON objects in Evergreen 1.4, and I'm pretty sure we've passed that bridge already, then the legacy JSON layer seems like an unnecessary layer of complexity that we should just drop. What would it take? 1. The cstore application makes heavy use of the jsonObjectIterator API, which would need to be manually updated to use the new jsonIterator API. The difference there is that the call to next() now returns a jsonObject instead of a the intermediary jsonObjectNode. Also, instead of accessing the current key through the node, you access it directly on the iterator object. 2. Remove all references to objson on the source/makefiles for Evergreen (only a few remain) 3. Purge objson from OpenSRF autotools and remove osrf_legacy_json* files Sound sane for Evergreen 1.4 and OpenSRF 1.0? -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] ejabberd problems
On Tuesday 15 July 2008 4:15 Lyons, Cyrus 2 wrote: [snip] Anyway, after going through the install for OpenSRF and Open-ILS, starting the webserver initially threw a couple of errors: [EMAIL PROTECTED]:/etc/apache2/ssl# /etc/init.d/apache2 restart Forcing reload of web server (apache2)... waiting Syntax error on line 69 of /etc/apache2/sites-enabled/eg.conf: Invalid command 'CacheRoot', perhaps misspelled or defined by a module not included in the server configuration failed! Fortunately, this is easily enough solved by enabled mod_cache and mod_disk_cache: [EMAIL PROTECTED]:/etc/apache2/ssl# ln -s /etc/apache2/mods-available/cache.load /etc/apache2/mods-enabled/cache.load [EMAIL PROTECTED]:/etc/apache2/ssl# ln -s /etc/apache2/mods-available/disk_cache.load /etc/apache2/mods-enabled/disk_cache.load [EMAIL PROTECTED]:/etc/apache2/ssl# /etc/init.d/apache2 start Starting web server (apache2) [EMAIL PROTECTED]:/etc/apache2/ssl# Hi Cyrus, mod_cache is no longer needed as of Evergreen 1.2.2.2. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Problem with doing keyword searches in release 1.2.2.0
On Wednesday 16 July 2008 12:54 Dale Arntson wrote: Hi all, We have had a problem with keyword searches failing to return in Evergreen release 1.2.2.0. These failed searches were accompanied by an uninitialized value error in the open-ils.search_unix.log. I traced this error down to the following missing element in the opensrf.xml file: /opensrf/default/apps/open-ils.search/app_settings/use_staged_search I set this to true, and our keyword searches are now working. Good catch, Dale. For everyone's benefit, the staged search setting is on by default in 1.2.2.1 and beyond. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] OPAC on Safari 1.x
On Thursday 17 July 2008 5:53 Brandon W. Uhlman wrote: Hi, all. We have a user who is unable to access the Evergreen OPAC on her older Mac, running OS X 10.3, Safari 1.3.2 on dialup. Has anyone tried using Safari 1.3 with Evergreen, and experienced either positive or negative results? I will suggest that the user upgrade to a more modern browser, but the only really modern broswer with support for OS X = 10.3.9 is the latest version of Camino, which is not a small download on dialup. Brandon, I've used Safari in the past. I know there are issues with bookbags and probably some other small issues, but, if I recall, it generally works OK. What kind of problems is she having? -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] purging objson (legacy json) for opensrf 1.0 / Evergreen 1.4
On Monday 14 July 2008 2:38 Dan Scott wrote:
2008/7/14 Bill Erickson [EMAIL PROTECTED]:
The topic of purging objson, which implements the old-style,
comment-embedded class hints for OpenSRF objects came up recently during
a discussion of the new autotools infrastructure. OK, fine, I brought it
up.
The current objson setup provides support for parsing old-style objects
via a separate API call (used in the opensrf gateway) and an
implementation of the old jsonObjectIterator API, which changed with the
latest JSON code.
The original idea for the legacy json layer was that the system may need
to support old and new-style JSON objects for Evergreen 1.4. However, if
we are in agreement that there is no need to support old-style JSON
objects in Evergreen 1.4, and I'm pretty sure we've passed that bridge
already, then the legacy JSON layer seems like an unnecessary layer of
complexity that we should just drop.
What would it take?
1. The cstore application makes heavy use of the jsonObjectIterator API,
which would need to be manually updated to use the new jsonIterator API.
The difference there is that the call to next() now returns a jsonObject
instead of a the intermediary jsonObjectNode. Also, instead of accessing
the current key through the node, you access it directly on the iterator
object.
2. Remove all references to objson on the source/makefiles for Evergreen
(only a few remain)
3. Purge objson from OpenSRF autotools and remove osrf_legacy_json* files
Sound sane for Evergreen 1.4 and OpenSRF 1.0?
That sounds quite sane to me. The earlier, the better, as far as
testing before 1.4 goes :)
Attached is a patch to purge objson from the ILS tree. It ports all of the
cstore jsonObjectIterator calls to the newer jsonIterator and replaces all
objson/object.h references with opensrf/osrf_json.h.
I wanted to push it out to the list since it touches a lot of cstore code and
that's not my usual stomping ground. This patch is running on
acq.open-ils.org. So far so good.
If there are no objections, I'll get this committed and start clearing out the
legacy JSON from OpenSRF.
-b
--
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
Index: Open-ILS/include/openils/oils_utils.h
===
--- Open-ILS/include/openils/oils_utils.h (revision 10093)
+++ Open-ILS/include/openils/oils_utils.h (working copy)
@@ -1,4 +1,4 @@
-#include objson/object.h
+#include opensrf/osrf_json.h
#include opensrf/log.h
// XXX replacing this with liboils_idl implementation
Index: Open-ILS/include/openils/oils_event.h
===
--- Open-ILS/include/openils/oils_event.h (revision 10093)
+++ Open-ILS/include/openils/oils_event.h (working copy)
@@ -1,6 +1,6 @@
#ifndef OILS_EVENT_HEADER
#define OILS_EVENT_HEADER
-#include objson/object.h
+#include opensrf/osrf_json.h
#include opensrf/utils.h
#include opensrf/log.h
#include opensrf/osrf_hash.h
Index: Open-ILS/src/c-apps/oils_cstore.c
===
--- Open-ILS/src/c-apps/oils_cstore.c (revision 10093)
+++ Open-ILS/src/c-apps/oils_cstore.c (working copy)
@@ -6,7 +6,6 @@
#include opensrf/log.h
#include openils/oils_idl.h
#include dbi/dbi.h
-#include objson/object.h
#include time.h
#include stdlib.h
@@ -53,9 +52,9 @@
static char* searchWriteSimplePredicate ( const char*, osrfHash*,
const char*, const char*, const char* );
static char* searchSimplePredicate ( const char*, const char*, osrfHash*, const jsonObject* );
-static char* searchFunctionPredicate ( const char*, osrfHash*, const jsonObjectNode* );
+static char* searchFunctionPredicate ( const char*, osrfHash*, const jsonObject*, const char* );
static char* searchFieldTransform ( const char*, osrfHash*, const jsonObject*);
-static char* searchFieldTransformPredicate ( const char*, osrfHash*, jsonObjectNode* );
+static char* searchFieldTransformPredicate ( const char*, osrfHash*, jsonObject*, const char* );
static char* searchBETWEENPredicate ( const char*, osrfHash*, jsonObject* );
static char* searchINPredicate ( const char*, osrfHash*, const jsonObject*, const char* );
static char* searchPredicate ( const char*, osrfHash*, jsonObject* );
@@ -181,7 +180,7 @@
int i = 0;
char* method_type;
- char* st_tmp;
+ char* st_tmp = NULL;
char* _fm;
char* part;
osrfHash* method_meta;
@@ -649,12 +648,12 @@
obj = doFieldmapperSearch(ctx, class_obj, ctx-params, err);
if(err) return err;
- jsonObjectNode* cur;
- jsonObjectIterator* itr = jsonNewObjectIterator( obj );
- while ((cur = jsonObjectIteratorNext( itr ))) {
- osrfAppRespond( ctx, cur-item );
+ jsonObject* cur;
+ jsonIterator* itr = jsonNewIterator( obj
Re: [OPEN-ILS-DEV] What I did on my summer vacation
On Thursday 24 July 2008 11:05 Dan Scott wrote: I've been meaning to do this for ages, and finally scraped a few hours together to get it done. As Evergreen 1.4 is introducing the use of Dojo (http://dojotoolkit.org) for a number of administrative interfaces, and even more so for 2.0 (acquisitions and serials interfaces), I thought it might make sense to start using Dojo to replace other widgets. In my dream world, the fewer widget sources that we use, the simpler infrastructure maintenance and extension shall be. Okay, enough gobbledygook. Attached is a patch (less than 200 lines) that introduces the use of the Dojo dijit.DateTextBox widget to replace the use of the jscalendar date-picker widget in the OPAC. It's not yet perfect, but it's headed there. I don't have extensive experience with the OPAC code, so I'm hoping Bill and/or Jason can take a look and see if there are any obvious horrible things lurking in this patch. Summary: Tested successfully with Firefox 3.0.1 (Linux) and IE6 (under IES4Linux). Works in FF2 as well. Functional differences: * Dates are now displayed according to the chosen locale, based on CLDR standards. For example, the textual representation of ISO8601 format 2008-07-27 in the en-US locale is 7/27/2008; in the fr-CA locale the textual representation is 27/07/2008. Dates are still transferred to the server in ISO8601 format. Accordingly, the formatting hints have been removed from the hold date fields. * body tag now gets class=tundra attribute to support Dojo widget formatting * css_common.xml gets the Dojo tundra CSS imports * js_common.xml gets the Dojo JavaScript required to support dijit.DateTextBox; if we do start using more Dojo widgets, in the longer term we might want to break this out into a separate file or files if we don't want to load the whole Dojo stack for each page. Regressions introduced: * An attempt to pick a hold activation date in the past no longer outlines the box in red; it just silently refuses to do anything. Haven't investigated the reason for this change in behaviour too deeply yet. I believe it's calling holdsVerifyThawDate() on the raw input value and not the ISO8601-ized value. Easy enough to fix post-patch. Potential improvements: * Use a min: constraint of today to prevent picking dates before today - this could short-circuit most of the current date comparison code. * Use the Dojo date methods to perform comparisons instead of the Date extension (DP_DateExtensions) class currently in use. * Use the Dojo date formatting methods to output dates in other parts of the OPAC, such as the Due date and Activate date columns in My Account * Use the DateTextBox throughout the staff client as well and delete jscalendar entirely Dojo also includes support for number and currency formatting according to the user's preferred locale; assuming the date approach is considered acceptable, these would be the next areas to tackle (IMHO). Agreed all around. The patch looks and behaves sanely. +1 from me for committing. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Saturday 26 July 2008 10:52 Mike Rylander wrote: We've had requests in the past for the ability to use an item's price as the max fine amount on a circulation, instead of a predefined amount. Because of how rules are defined and chosen in Evergreen today, the solution to this request had not presented itself in a clear and consistent manner. However, John Craig of Alpha-G Consulting (another firm getting into the Evergreen support and migration biz) was wondering about a specialization of this idea and how it might be implemented. He has had a request to be able to use a percentage of the item price as the max fine amount -- and this, it turns out, is the twist that finally made the solution stand out, bright as day as if it had always been right there, as a consistent and general extension of the existing framework. John and I went to our separate corners and dummied up a plan for this, and it turns out that we both saw the same solution. Here attached is an implementation of that solution, which works thusly: * The config.rule_max_fine table gets a new boolean column called is_percent which defaults to false * The IDL (and, for good measure, the storage server's ancient equivelant) is taught about this new field * OpenILS::Circ::Circulate::build_checkout_circ_object inspects this field on the chosen rule for truthiness, and finding a positive result: - gets the item price from the copy and - if that's null (not allowed yet, but will be in 1.4) attempts to find an org_unit-appropriate default item price (also used for LOST fee) - or, if price == 0 and the charge default on 0-price org unit setting is true, attempts to find an org_unit-appropriate default item price (also used for LOST fee) - and now, having found an appropriate full price for the item, interprets the max fine amount as a percentage value, scaling the full price as specified - and finally, uses that amount as the max fine amount, instead of a specific value As an example, say you have an item being checked out and the max fine rule chosen for this circulation looks like this: name = up_to_half_of_price amount = 50.00 is_percent = true and the item price is 20.00. The max fine for that circ would be set to 10.00 ... Another example with the same rule, but the copy has a null (in 1.4) price or a price of 0.00 and charge default on 0-price org unit setting is in effect, and that default price is 25.00. The max fine would be set to 12.50. And, finally, if the max fine amount is 100.00, the full price of the copy or the default price (the original request) would be used. We have come full circle. Thoughts? I think it's a great addition. I eyeballed the patch and it looks good. (comment: instead of redefining isTrue, we can use $U-isTrue). One addition to consider is adding an org-setting cache (just a local data structure) for default item price and charge-on-0 to reduce network calls. That can come later, though. Good work, guys. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] removing of objson from opensrf
On Friday 25 July 2008 12:23 Bill Erickson wrote: This patch is running on acq.open-ils.org... also, so far so good. If there are no objections, I'll commit soon. Committed. http://svn.open-ils.org/trac/OpenSRF/changeset/1373 -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Thinking about receiving
On Thursday 24 July 2008 8:54 David J. Fiander wrote: Receiving needs to be efficient, since it's most definitely a materials handling process above everything else. Imagine that the staff have opened a box and dug out the packing slip / invoice. Once they've checked that against the contents of the box against the slip, they're ready to start checking materials into the system. They go to the receiving screen, which comes up with today's date, which will be used as the actual received date in the acqlids that are updated. In order to properly track things, the acqlid should probably have an invoice # field. On the receiving screen, there will be a field at the top into which the staff member enters the current invoice number, which will then be applied to all the acqlids that are updated. The primary field on the receiving screen is an ISBN input field. The staff scan the ISBN barcode on each item, which pulls up the corresponding JUB. This seems like a reasonable approach. I guess this screen will also have a box for ISSN, etc. I think it would also be good to support using the PO as the receiving entry point. Assuming the PO number is included with the invoice, staff can pull up the PO by ID and mark all items or individual items as received. Dan S. also submitted a work flow at http://open-ils.org/dokuwiki/doku.php?id=acq:scenarios:receiving_monographs -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Sunday 27 July 2008 11:24 Mike Rylander wrote: On Sun, Jul 27, 2008 at 11:21 AM, Mike Rylander [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 8:52 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Saturday 26 July 2008 10:52 Mike Rylander wrote: I think it's a great addition. I eyeballed the patch and it looks good. (comment: instead of redefining isTrue, we can use $U-isTrue). I don't see the definition for isTrue anywhere in the OpenILS:: namespace Arg, sorry, the Perl code is mostly non-camel-case: $U-is_true -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Sunday 27 July 2008 11:21 Mike Rylander wrote: On Sun, Jul 27, 2008 at 8:52 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Saturday 26 July 2008 10:52 Mike Rylander wrote: Next question is ... how far back do we backport this. I would lobby for 1.2.3.0, but not to strongly. Well, you've done the hard part! 1.2.3.0 seems reasonable to me. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and staff client
On Saturday 26 July 2008 9:57 Mike Rylander wrote: On Tue, Jul 22, 2008 at 5:35 PM, Mike Rylander [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 2:40 PM, Dan Scott [EMAIL PROTECTED] wrote: [snip] After supposing for a few days, here are 2 patches which remove the normalization (there was less than I thought) sprinkled throughout the code. No more lowercasing, but we do change '_' to '-' in the core stored procedure that does the translated value lookup. With these patches in place (they're not yet), it's required that ALL locales be assembled in the ll-LL format (that's not strictly true ... there's just no fudge factor in locale case anymore). Eyeballs apreciated, since they touch python and java in addition to my areas. The Java and Python bits look good. -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] removing legacy json from autotools
In my previous patch, all of the objson code was removed from OpenSRF,
including the autotools bits that compiled objson. This patch removes the
remaining autotools bits, in particular giving the user the choice of whether
to build legacy json.
-b
--
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
Index: configure.ac
===
--- configure.ac (revision 1375)
+++ configure.ac (working copy)
@@ -80,19 +80,6 @@
AM_CONDITIONAL([BUILDPYTHON], [test x$OSRF_INSTALL_PYTHON = xtrue])
AC_SUBST([OSRF_INSTALL_PYTHON])
-# create the legacy JSON headers and .so file for backwards compatibility?
-AC_ARG_ENABLE([legacyjson],
-[ --disable-legacyjsondisable the legacy json headers and .so file for backwards compatibility],
-[case ${enableval} in
-yes) OSRF_LEGACY_JSON=true ;;
-no) OSRF_LEGACY_JSON=false ;;
- *) AC_MSG_ERROR([please choose another value for --disable-legacyjson (supported values are yes or no)]) ;;
-esac],
-[OSRF_LEGACY_JSON=true])
-
-AM_CONDITIONAL([BUILDJSON], [test x$OSRF_LEGACY_JSON = xtrue])
-AC_SUBST([OSRF_LEGACY_JSON])
-
# enable debug?
AC_ARG_ENABLE(debug,
@@ -293,12 +280,6 @@
AC_MSG_RESULT([OSRF install python?:no])
fi
-if test $OSRF_LEGACY_JSON = true ; then
-AC_MSG_RESULT([OSRF install legacy json?: yes])
-else
-AC_MSG_RESULT([OSRF install legacy json?: no])
-fi
-
AC_MSG_RESULT(Installation directory prefix: ${prefix})
AC_MSG_RESULT(Tmp dir location:${TMP})
AC_MSG_RESULT(APXS2 location:${APXS2})
Index: bin/osrf_config.in
===
--- bin/osrf_config.in (revision 1375)
+++ bin/osrf_config.in (working copy)
@@ -21,16 +21,12 @@
function showInstalled {
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
- [EMAIL PROTECTED]@
if test $JAVA = true; then
echo OSRF_JAVA
fi
if test $PYTHON = true; then
echo OSRF_PYTHON
fi
- if test $JSON = true; then
- echo OSRF_LEGACY_JSON
- fi
}
function showAll {
Re: [OPEN-ILS-DEV] Thinking about receiving
On Sunday 27 July 2008 11:19 Mike Rylander wrote: On Sun, Jul 27, 2008 at 9:51 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Thursday 24 July 2008 8:54 David J. Fiander wrote: [snip] The primary field on the receiving screen is an ISBN input field. The staff scan the ISBN barcode on each item, which pulls up the corresponding JUB. This seems like a reasonable approach. I guess this screen will also have a box for ISSN, etc. Learning/stealing from Vandelay, we could add an identifier boolean to acq.lineitem_attr_definition, and simply search all of these attrs as an exact-match from a single search box. Add ISBN, ISSN, UPC, po number (as a vendor attribute), ASN id, etc. We'd also want to search the barcode on lineitem_detail for detecting shelf-ready items. I like this approach. It will certainly make the interface more streamlined. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] Re: removing legacy json from autotools
On Monday 28 July 2008 9:35 Kevin Beswick wrote: Looks good to me Committed. Thanks for the eyes, Kevin. -b Kevin On Mon, 2008-07-28 at 09:33 -0400, Bill Erickson wrote: In my previous patch, all of the objson code was removed from OpenSRF, including the autotools bits that compiled objson. This patch removes the remaining autotools bits, in particular giving the user the choice of whether to build legacy json. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] overdue and pre-due notice config
I'm beginning work on courtesy (predue) notices and a re-architecture of the existing overdue notice script for better templating and configuration. Attached is a sample configuration section (from opensrf.xml) I created for setting these up. I wanted to work backwards from the configuration to the code to make sure the requirements are accurately represented. This configuration is only for email notices and generating a local XML file (for sending to a vendor, creating local mail notices, etc.). This is not the full-blown notication system (telephony, etc.) described in http://open-ils.org/dokuwiki/doku.php?id=scratchpad:notification_systems=notices. However, I'd like to think that this is at least a step in that direction. For predue notices, there was a discussion of basing the notice date on a percentage of the total circulation duration. I toyed with that some and decided in the end to model predue notices on duration date ranges instead. It's just easier on the eyes. I'm open to discussion on that one, though. For 1.4.0, the plan is to have locale-aware templates, built with Perl's Template Toolkit. 1.4.X will introduce per-org-unit templates. Suggestions and comments on the configuration welcome. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com notifications !-- global mail server settings -- smtp_serverlocalhost/smtp_server sender_address[EMAIL PROTECTED]/sender_address !-- Overdue notices -- overdue !-- optionally, you can define a sender address per notice type -- sender_address[EMAIL PROTECTED]/sender_address !-- The system can generate an XML file of overdue notices. This is the directory where they are stored. Files are named overdue.-MM-DD.xml -- notice_dir/openils/var/data/overdue/notice_dir notice !-- Notify at 7 days overdue -- notify_interval7 days/notify_interval !-- Options include always, noemail, and never. 'noemail' means a notice will be appended to the notice file only if the patron has no valid email address. -- file_appendnoemail/file_append !-- do we attempt email notification? -- email_notifytrue/email_notify !-- notice template file -- template/openils/var/data/templates/overdue_7day/template /notice notice notify_interval14 days/notify_interval file_appendalways/file_append email_notifytrue/email_notify template/openils/var/data/templates/overdue_14day/template /notice /overdue !-- Courtesy notices -- predue notice_dir/openils/var/data/predue/notice_dir notice !-- All circulations that circulate between 5 and 13 days -- circ_duration_range5 days,13 days/circ_duration_range !-- notify at 1 day before the due date -- notify_interval1 day/notify_interval file_appendfalse/file_append email_notifytrue/email_notify template/openils/var/data/templates/predue_1day/template /notice notice !-- All circulations that circulate for 14 or more days -- circ_duration_range14 days/circ_duration_range notify_interval2 day/notify_interval file_appendfalse/file_append email_notifytrue/email_notify template/openils/var/data/templates/predue_2day/template /notice /predue held_item_ready notice email_notifytrue/email_notify template/openils/var/data/templates/held_item_ready/template /notice /held_item_ready /notifications
Re: [OPEN-ILS-DEV] overdue and pre-due notice config
On Wed, 06 Aug 2008 13:00:48 -0400, Dan Scott [EMAIL PROTECTED] wrote: Hi Bill: 2008/8/6 Bill Erickson [EMAIL PROTECTED]: [snip] Some general comments: It's not explicit, but I suspect this could be used/abused for items like laptops that might have a four hour circulation period, so that you could send an email 30 mins in advance to remind the user that it's due real soon now. That should be feasible. I'm thinking we need a command-line param to the notifier which tells it to generate notices for circs that have a notify_interval of = 1 day. That way, CRON can be set up to run the notifier every hour, but once a day it will set the switch to generate notices for = 1 day notify_interval items. In other words, if I'm supposed to get a notice today about an item due tomorrow, I won't get a notice every hour. For the pre-overdues, it would be nice to take advantage of the system's knowledge of the circ rule in play to offer a link to a renewal page (if applicable for each item) and specify the fines that will be accrued. I like that. I'm also hoping that this will group items together in some way, rather than generating one email per item. The current behavior for overdues and planned behavior for this next batch of code is to generate one email per type of notice. E.g. 1 email for all items 7 days overdue, 1 email for all items 14 days overdue, etc. This allows for separate templates for each type. Is this grouped enough or do you think putting all notices into a single email is crucial? Specific comment on the configuration syntax: At first glance, I didn't find the circ_duration_range syntax particularly intuitive. 5 days, 13 days looked like an OR set of items, and 14 days on its own looked like, well, just 14 days, not 14 days or more. At the risk of making the XML even more verbose, but perhaps more intuitive, I would propose something more like the following: !-- rather than 5 days, 13 days notation -- circ_duration_range from5 days/from to13 days/to /circ_duration_range !-- for items with a circ duration of exactly 28 days, set from == to -- circ_duration_range from28 days/from to28 days/to /circ_duration_range !-- if to element is missing, then the range extends to the end of time -- circ_duration_range from14 days/from /circ_duration_range !-- if from element is missing, then the range extends from the start (0 mins) to to -- circ_duration_range to5 days/to /circ_duration_range !-- and if circ_duration_range holds neither from nor to, then it encompasses all circ_duration ranges -- circ_duration_range/circ_duration_range That works for me. Thanks, Dan! -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: SPAM: Re: [OPEN-ILS-DEV] Thinking about receiving
On Tue, 12 Aug 2008 12:34:43 -0400, Lori Bowen Ayre [EMAIL PROTECTED] wrote: I'll try again to chime into this thread...I think my last message was blocked. I'm going to jump in here and suggest that someone needs to get familiar with ASN (advanced shipment notificiation) which allows the libraries to electronically receive their materials rather than having to check in each item one at a time. Essentially, once the shipment contents is verified (one order or partial orders), the items represented on the packing slip can be uploaded using the ASN process. Ingram can do this and I don't know about others. The problem, as usual, is on the ILS side. I don't know much more than that but I can refer you to a document at http://www.pubnet.org/community/EDI.pdf that may help. I can also refer you to at least one person I know of (on the front lines) who has been watching this for some time and may have some insights. Let me know if I can help further. We (the ESI folks) have spoken to Ingram about their ACQ processes and about ASN in paticular. We agree it's a cool feature and have every intention of making sure Evergreen can process ASN EDI. As we start looking closer at the process, we may take you up on your offer of help ;) Thanks, Lori. Let us know if you have any other thoughts/suggestions. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Circ problem with 1.2.3.0?
On Fri, 15 Aug 2008 06:14:18 -0400, Garry Dunn
[EMAIL PROTECTED] wrote:
Mike Rylander wrote:
On Thu, Aug 14, 2008 at 10:34 AM, Garry Dunn
[EMAIL PROTECTED] wrote:
To all,
I just recently upgraded (from 1.2.2.0) to 1.2.3.0 (going through each
of
the minor upgrades between) and now I can't check a book out. I've
upgraded
both the server and the client. I'm hoping someone can point me in the
right direction.
The error I get is:
method=open-ils.circ.checkout
params=[27e22ed97a705d7c17cc5a8bb41c2838,{barcode:1234,patron:2,permit_key:4f9f0412833fc870
bae69de74be90fb0},0]
THROWN:
{payload:[],debug:osrfMethodException : *** Call to
[open-ils.circ.checkout] failed for session
[1218719016.028563.121871901617073], thread trace [1]:\n * !
EXCEPTION ! *
\nTYPE: OpenSRF::EX::ERROR
\nMess: System ERROR \nMess: Circ Duration Script Died: Error:
TypeError:
parent has no properties at line 163: (null)\nLoc.: 185
OpenSRF::Application
\nLoc.: /openils/lib/perl5/OpenSRF/Application.pm \nTime: Thu Aug 14
09:03:36 2008\n\n,status:500}
STATUS:
I get this on a 'blank' database (no Gutenberg records or any of our
records
imported). I created 1 book and 1 patron and tried to get that patron
to
checkout that book.
Any chance you added your user to the User group (at the top of the
tree, and which has no parent group)? My theory is that it's either
that, or there is a group mentioned in the JS that does not exist in
the database. If it's the former, that User group is mainly intended
to be a parent group for others, such as Patron and Staff.
The patron is a member of the 'Patrons' group. I left the groups and
permissions alone when the database was created, so it's got the default
that comes with Evergreen.
Where would I look in the JS for other groups? I know I 'autogen-ed'
after importing the data (the old library hierarchy would've existed).
The exact same data (from the old ILS) imports properly into 1.2.2.0
(and 1.2.3.0). 1.2.2.0 will let me circulate books, but 1.2.3.0 won't.
Thanks for the help.
Garry,
I committed code to handle this situation more gracefully in 1.2.3 and
trunk: http://svn.open-ils.org/trac/ILS/changeset/10366
It would be safe/trivial to merge this change into your installed system
at /openils/var/circ/circ_lib.js.
It sill sounds, however, like the user being checked is not in a valid
group. Can you make sure there is no small descrepency between group
names? For example Patron vs. Patrons?
-b
--
Bill Erickson
| VP, Software Development Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://esilibrary.com
[OPEN-ILS-DEV] moving PINES example code from ILS repo to ILS-Contrib
Currently, there are a number of customization files, policy scripts, etc. specific to PINES in the Evergreen directory of the Evergreen ILS repository. Early on, the ILS repository served as a good place to keep these files, but as Evergreen expands, it makes less sense for them to stay there. Also, as you might imagine, it tends to create confusion. I would like to propose that these files be moved into the ILS-Contrib repository (http://svn.open-ils.org/trac/ILS-Contrib) to continue to serve as examples of how one can configure certain parts of the software. Perhaps ILS-Contrib/PINES-Examples/ ? The long-term goal here is to completely remove the Evergreen directory from the ILS repository, since no one outside of PINES uses any of its contents. Suggestions/thoughts welcome. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] mod_placeholder.so problems
On Wed, 27 Aug 2008 07:33:21 -0400, Ephraim Makeke [EMAIL PROTECTED] wrote: Hi all I tried to do everything the documentation on installing evergreen server instructed and i tried to do what Dan Scot suggested but still i get the error message * Starting web server apache2 Syntax error on line 2 of /etc/apache2/httpd.conf: Invalid command '/usr/lib/apache2/modules/mod_placeholder.so', perhaps misspelled or defined by a module not included in the server configuration I tried to check the folder /usr/lib/apache2/modules and the module mod_placeholder.so does not exist. what could really be the problem. I need to run my evergreen server for some demonstrations to other librarians. Hi Ephraim, Your /etc/apache2/httpd.conf file should look something like this: # #LoadModule mod_placeholder /usr/lib/apache2/modules/mod_placeholder.so LoadModule osrf_json_gateway_module /usr/lib/apache2/modules/osrf_json_gateway.so LoadModule xmlent_module /usr/lib/apache2/modules/mod_xmlent.so Hope this helps, -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] libxml2 router issue on Debian Etch
Hi all, Just a heads up... I just found what appears to be a bug in libxml2 version on 2.6.27.dfsg-4 on Debian Etch, which is the latest stable libxml2 release (as of late August). After parsing a certain number of jabber messages within a given SAX parser context, it just stops working. In my test environment (2.6.18-5-amd64), it always breaks between 26k and 31k messages. This manifests itself as failed messages to the OpenSRF router: the requests go in, but they never come out the other end. You can see what version you have installed with $ dpkg -l libxml2 libxml2-dev I downgraded my machine to libxml2_2.6.27.dfsg-2_amd64 and libxml2-dev_2.6.27.dfsg-2_amd64 (to match other local machines) and problem solved. Finding old Debian packages isn't always easy, so I've put our AMD 64 versions on the open-ils.org site in case they can be of use to anyone: http://open-ils.org/~erickson/libxml2_2.6.27.dfsg-2_amd64.deb http://open-ils.org/~erickson/libxml2-dev_2.6.27.dfsg-2_amd64.deb I'll try to isolate the problem so I can send something useful to the libxml2 folks. Thanks, -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Dojo Release 1.2.0
On Sun, 05 Oct 2008 10:13:04 -0400, Mike Rylander [EMAIL PROTECTED] wrote: On Sun, Oct 5, 2008 at 9:41 AM, Dan Scott [EMAIL PROTECTED] wrote: Dojo released 1.2.0 a few days ago; here are my findings as of last night (yay planes) with a quick run-through of Conify and Vandelay: * no more dojo.js.uncompressed.js - so in those few places where we did call it, we would need to just point at dojo.js instead (a debugging version must still be available but our defaults in delivered files should point to dojo.js anyway) * dojox.grid._data.* has moved to dojox.grid.compat._data.* (this is now deprecated and will no longer be maintained - a new Grid has been added that will be the preferred grid going forward) * dojox.grid.editors has moved to dojox.grid.compat._data.editors That's more change than I'd hoped for (or thought there would be) but obviously not unmanageable. :) I have attached a patch for Conify; no changes were needed for Vandelay. My testing was largely to the point of getting things working without JS errors in Conify and Vandelay, and testing date picker widget / display in the OPAC, but nothing deeper. So the question: should we switch to 1.2.0 using these compatibility mechanisms so that the prereq will already be in place if we decide to rewrite to use the new easier-to-use Grids? Or maybe it's a moot point because we're going to sidestep the problem by packaging our own Dojo build for EG anyway. If we have a patch, and the JS loads, then I'm for upping the version of Dojo. Agreed on 1.2. However, I put 1.2 on dev.gapines.org and applied the patch locally and found 2 additional issues. We seemed to have lost some styling in Vandelay (the blue gradient css) and we're getting the extra scroll bars in the Vandelay queue grid (a la pre-LayoutContainer). LayoutContainers are technically deprecated in 1.2, so even though they exist, they may be broken. I'm experimenting with alternatives. If I run into any showstoppers, I'll report. Thanks, Dan! -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] searching from remote form
On Thu, 09 Oct 2008 00:20:57 -0400, Dan Scott [EMAIL PROTECTED] wrote: giant context-destroying snip I think it would be best if, just like the ISSN hyphen filtering, we pulled the filtering from the client side and made it all happen server side, so that we can ensure that the results are consistent from any interface. Agreed with one caveat. There is a know issue with Evergreen 1.2 (in particular, OpenSRF 0.9) where a trailing \ will give the perl JSON parser fits. So, we need to keep \-escapding in the OPAC until 1.4. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Numbering of search results invalid
On Tue, 14 Oct 2008 08:53:36 -0400, Grant Johnson [EMAIL PROTECTED] wrote: Thanks Brandon, Keep me in that loop ... We can do some testing for the resolution when it comes. Cheers Grant Changeset 10858 (http://svn.open-ils.org/trac/ILS/changeset/10858) should resolve the hit count issue. Grant, I can't say for sure yet if it will resolve your details display issue. If anyone has an opportunity to test this change, I would certainly appreciate any feedback. Thanks, -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] How to log on to acq.open-ils
On Thu, 23 Oct 2008 13:34:15 -0400, Frances Dean McNamara [EMAIL PROTECTED] wrote: We were trying to look at the acq development server. In the Webinar they said it will log you on automatically. It doesn't seem to be doing that. Is there a log on that should be used? (Or maybe it's being upgraded or something?) Hi Frances, You can log in with user=berick pass=demo123 We just did some renovations on the server, including a clean DB and some shaking up of the web login handler, among other things. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Installing 1.4RC1 on Ubuntu 8.04 Server
On Tue, 28 Oct 2008 22:37:23 -0400, Warren Layton [EMAIL PROTECTED] wrote: I recently installed Evergreen 1.4 RC1 on a fresh install of Ubuntu 8.04 Server. Following the instructions on the DokuWiki[1], I ran into two minor issues: 1) Running the Makefile.install attempts to install syslog-ng. This itself isn't a problem but it causes the package manager to warn the user that syslogd, ksyslogd and ubuntu-minimal will be uninstalled, which the package manager doesn't seem to like. I did and apt-get install syslog-ng before running the Makefile.install and it made things a bit less confusing. (I don't think this is specific to Ubuntu Server - I seem to remember the same thing happening when I installed on Desktop). Technically speaking, syslog-ng (and ntpdate) are not required for running Evergreen. They were just grandfathered in. Syslong-in in particular should probably be removed from the Makefile, since choosing a logger is more of a personal choice. 2) After attempting to compile Evergreen in step 5, the configure script failed because it couldn't find the libdbi libraries and installed by the Makefile.install, including the associated pgsql driver (Step 5(I)). The solution was to skip ahead to Step 20 and add the /etc/ld.so.conf/eg.conf file and run ldconfig before doing the configure; make; make install commands in Step 5 (thanks to the friendly people on the Evergreen IRC channel for their help!). This certainly wasn't an issue when I had previously installed Evergreen on Ubuntu 8.04 desktop. I'm guessing this will be the same for all fresh 1.4 installs, because of the new autotools infrastructure. With these two changes to the install procedure, everything was up and running in record time. If these two changes are sane, I'd be happy to update the instructions on the DokuWiki. Updating the wiki for #2 would be great. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
[OPEN-ILS-DEV] notifications (internals)
Hi all, I put some thoughts together on how we may want to wire up the plumbing for event-based notifications. http://open-ils.org/dokuwiki/doku.php?id=feature:notifications There are missing pieces, questions, and likely some non-obvious assumptions on my part, but I wanted to push it out to solicit thoughts on filling in the gaps or doing things differently. The code will probably be developed in stages, starting with email notices and only a few event types, later moving on to telephony, etc. Anyway, let me know if you have any thoughts or questions. Thanks, -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: utils.h (OSRF_BUFFER_ADD_CHAR)
This patch fixes a bug in the OSRF_BUFFER_ADD_CHAR macro. Like the corresponding buffer_add_char function, this macro appends a specified character to a growing_buffer. Unlike the function, however, the existing version of the macro does not also append a terminal nul. This bug had gone unnoticed because, most of the time, the rest of the buffer is already filled with nuls, left over from the initial creation of the growing_buffer. I stumbled across the problem when, in the course of writing a test harness for some other changes, I called buffer_reset() in order to reuse an existing growing_buffer instead of destroying and re-creating it. With debugging turned on, buffer_reset() fills the buffer with exclamation points, leaving a nul only in the very last byte. Later, if we use buffer_add() or buffer_fadd() to extend the string stored in the growing_buffer, it uses strcat() to append the new characters. The result is a buffer overflow. Actually buffer_reset() should place a nul in the first byte of the buffer. Tomorrow I shall submit a patch to that effect. Hey, Scott! It's good to hear from you. Patch is applied with thanks. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: utils.c (miscellaneous)
This patch is mostly a couple of tweaks to the growing_buffer code, loosely related to my previous patch to utils.h. There is also a small tweak to uescape(). 1. in buffer_add() I replaced strcat() with strcpy() for appending the new string. Since we already know where the end of the old string is, we don't need to ask strcat() to find it for us. 2. In buffer_reset(), the old code contains the following: osrf_clearbuf( gb-buf, sizeof(gb-buf) ); The evident intent is to clear the buffer. However sizeof(gb-buf) is not the size of the buffer, it's the size of the pointer to the buffer. We were clearing only the first four bytes or so. I changed the line to: osrf_clearbuf( gb-buf, gb-size ); 3. Also in buffer_reset(), I added a line to populate the first byte of the buffer with a nul, to ensure that the length of the (empty) string matches the n_used member. 4. In uescape(), we were examining the contents of string[] without first verifying that string was not NULL. The result would be undefined behavior if string were ever NULL. I added a couple of lines to treat a NULL pointer as if it were a pointer to an empty string. Also applied. -- Together with yesterday's patch to utils.h, these changes are intended to guarantee that the length of the string stored in a growing_buffer always matches the value of n_used. buffer_data() relies on such a match. So did buffer_add() (and, indirectly, buffer_fadd()) until I changed it. So does every bit of code that calls buffer_release(). Previously the terminal nuls were supplied by filling the entire buffer with nuls before otherwise populating it. This practice always bothered me because it looked like a waste of CPU cycles. The use of osrf_clearbuf() in buffer_reset() is probably no longer necessary or useful. However, from an abundance of caution I have left it in there. I cannot guarantee that there is no other bit of code that fails to append a terminal nul where it should. It might be a useful experiment to eliminate the prenullification and see if anything breaks. Another possible experiment is to insert the assert() macro at the entry and exit of each of the growing_buffer functions: assert( strlen( gb-buf ) == gb-n_used ); Such an assertion would add overhead for development and debugging, but would reduce to a no-op when NDEBUG is #defined. I bet there are still some dragons lurking, so your caution is appreciated. Thanks again, -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: osrf_json.c (rewrite of jsonObjectToJSON[Raw])
On Mon, 17 Nov 2008 23:32:21 -0500, Scott McKellar [EMAIL PROTECTED] wrote: This patch is a rewrite of the jsonObjectToJSON and jsonObjectToJSONRaw functions. It is dependent on my previous patch to utils.c and utils.h, adding the new buffer_append_uescape function. One purpose is to replace a call to the uescape function with a call to the faster buffer_append_uescape function. The other purpose is to introduce a faster way to translate a jsonObject into a string. (Also in one spot I broke up a very long string literal into several smaller pieces so that it wouldn't wrap around in the editor.) In the existing jsonObjectToJSON function, we receive a pointer to a jsonObject and return a string of JSON. However we don't translate the original jsonObject directly. Instead, we create a modified clone of the original, inserting an additional JSON_HASH node wherever we find a classname. Then we translate the clone, and finally destroy it. It always struck me as an egregious waste to create and destroy a whole parallel object just so that we could turn it into a string. So I looked for a way to eliminate the cloning. The result is a modification of add_json_to_buffer(), a local function that recursively traverses and translates the jsonObject. When it sees a classname (and it has been asked to expand classnames), the new version inserts additional gibberish into the output text and then continues the traversal, without modifying or copying the original jsonObject at all. In my benchmark, this new approach was faster than the original by a factor of about 5. When I combined this change with the use of the new buffer_append_uencode function, it was faster by a factor of about 7.2. The benchmark used a moderately complex jsonObject about 5 or 6 levels deep, with both hashes and arrays, with classnames at several levels. The performance gain will no doubt depend on the contents of the jsonObject,but I haven't tried to isolate the variables. The new version is a bit trickier and harder to read than the old. In my opinion the speedup is worth the obscurity, because a lot of places in Evergreen will benefit. With this change, the jsonObjectEncodeClass function, which had been called only from jsonObjectToJSON, is no longer called from anywhere. It's the function that created the modified copy of the original jsonObject. I see no reason to keep it around. After a decent interval, if no one objects I shall submit a patch to eliminate it. Agreed. Likewise the jsonObjectToJSONRaw function is no longer called from anywhere. It translates a jsonObject to JSON without expanding classnames. In this rewritten version it is identical to jsonObjectToJSON except that it calls add_json_to_buffer() with a different parameter value. If we eliminate jsonObjectToJSONRaw, I can simplify add_json_to_buffer() a bit. However we might someday want to be able to translate a jsonObject without expanding classnames. If nobody minds, I'll leave this function where it is. Also agreed. We (or other code using OpenSRF) may need the Raw() version in the future. This code path is used /a lot/, so the speedups are greatly appreciated. I've run into one issue with these last 2 patches, in particular, there seems to be a subtle difference in uescape() and buffer_append_uescape(). The majority of the JSON parsing succeeds, but parsing certain bibliographic data (MARC records) always results in NULL when attempting to encode the containing object (biblio_record entry objects).If I replace the call to buffer_append_uescape() with a call to uescape() in osrf_json_object.c, then all is well. I would send you some sample data to test, but I've yet to recreate the issue outside of a running system. For now, I'm adding some logging to see if I can track it down. I just wanted to pass this on in case any lightbulbs went off. I'll let you if I find something... Thanks, Scott -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: osrf_app_session_.c (minor correction)
On Tue, 18 Nov 2008 11:24:02 -0500, Scott McKellar [EMAIL PROTECTED] wrote: In some earlier patches I eliminated the old osrf_app_client_session_init function in favor of its camel-case equivalent. Unfortunately I didn't notice that the new function now puts the old function's name into an error message. Here's the fix for that little oversight. Applied. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] disable automatic record deletion
On Tue, 09 Dec 2008 12:37:22 -0500, Grant Johnson [EMAIL PROTECTED] wrote: Hey all, It's cold and snowy here! Where do I go to do this? disable automatic record deletion using an org_unit setting Hi Grand, I believe that's referring to not deleting a bib record when all attached items/call-numbers are being deleted? If so, you can set an org_unit setting called cat.bib.keep_on_empty. For now, you'll have to do that directly in the database. Something to the effect of: insert into actor.org_unit_setting (org_unit, name, value) values (1, 'cat.bib.keep_on_empty', 1); That will apply the setting globally, if top of your org_unit hierarchy has an ID of 1. You can also tell the system to alert the staff when this occurs with the cat.bib.alert_on_empty setting. Hope this helps, -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] disable automatic record deletion
On Tue, 09 Dec 2008 15:23:10 -0500, Bill Erickson [EMAIL PROTECTED] wrote: On Tue, 09 Dec 2008 12:37:22 -0500, Grant Johnson [EMAIL PROTECTED] wrote: Hey all, It's cold and snowy here! Where do I go to do this? disable automatic record deletion using an org_unit setting Hi Grand, Er.. Grant. Sorry. Although, Grand isn't such a bad thing to be ;) -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Is there a preferred Date calculations module?
On Tue, 09 Dec 2008 21:02:40 -0500, David Fiander [EMAIL PROTECTED] wrote: If Evergreen's already got a perl Date module loaded, then it makes sense for me to use that one. It looks like there's a dependency on DateTime. is that right, and is it the only one? Yep, we use DateTime (and it's associated modules) extensively for Perl. I believe that's the only one. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] disable automatic record deletion
On Tue, 09 Dec 2008 15:23:10 -0500, Bill Erickson [EMAIL PROTECTED] wrote: On Tue, 09 Dec 2008 12:37:22 -0500, Grant Johnson [EMAIL PROTECTED] wrote: Hey all, It's cold and snowy here! Where do I go to do this? disable automatic record deletion using an org_unit setting Hi Grand, I believe that's referring to not deleting a bib record when all attached items/call-numbers are being deleted? If so, you can set an org_unit setting called cat.bib.keep_on_empty. For now, you'll have to do that directly in the database. BTW, I've added these two settings to the library settings editor for 1.4 and beyond. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
