2010-03-01T00:07:52 bott++ 2010-03-01T00:17:28 *** bshum has joined #evergreen 2010-03-01T07:42:41 *** sfortin has joined #evergreen 2010-03-01T07:43:41 *** eby has joined #evergreen 2010-03-01T07:45:39 *** bott-otr has quit IRC 2010-03-01T07:55:02 *** mck9 has joined #evergreen 2010-03-01T08:05:47 *** rjackson-isl has joined #evergreen 2010-03-01T08:07:55 <_bott_> jeff: is no news, good news? 2010-03-01T08:08:31 _bott_: just found minor bad news. some quick fixes to circ_duation.js -- sent mail on ticket. 2010-03-01T08:09:05 sorry if that diff complicated things -- i was trying to make it easier. :) 2010-03-01T08:12:26 er, not circ_duration.js, circ_item_config.js 2010-03-01T08:13:03 (got it right in the ticket) 2010-03-01T08:13:21 <_bott_> No worries. Just some overzealous copy/pasting on my part 2010-03-01T08:20:16 <_bott_> jeff: FWIW, soon you'll be able to provide full files (ala http://svn.grpl.org/mieg/general/browser/branches/rel_1_6/var/circ/) 2010-03-01T08:21:55 *** rsinger has quit IRC 2010-03-01T08:56:06 *** Meliss has joined #evergreen 2010-03-01T09:02:20 *** bshum has joined #evergreen 2010-03-01T09:09:48 *** leed has joined #evergreen 2010-03-01T09:24:39 *** rsinger has joined #evergreen 2010-03-01T09:26:23 *** jenny has joined #evergreen 2010-03-01T09:51:40 *** natschil has joined #evergreen 2010-03-01T10:08:12 *** r123 has joined #evergreen 2010-03-01T10:16:13 *** natschil has quit IRC 2010-03-01T10:18:34 *** natschil has joined #evergreen 2010-03-01T10:19:50 _bott_: you around? 2010-03-01T10:25:33 *** natschil has quit IRC 2010-03-01T10:25:49 *** natschil has joined #evergreen 2010-03-01T10:26:05 _dkyle_++ 2010-03-01T10:32:46 <_dkyle_> jeff: should be better now 2010-03-01T10:33:14 thanks! 2010-03-01T10:35:04 *** natschil has quit IRC 2010-03-01T10:37:34 *** brendan_bywater has quit IRC 2010-03-01T10:54:05 *** brendan_bywater has joined #evergreen 2010-03-01T11:28:36 *** alxp has joined #evergreen 2010-03-01T11:46:31 *** Dmagick has quit IRC 2010-03-01T12:11:50 *** 40FAAINFD has joined #evergreen 2010-03-01T12:12:09 *** 40FAAINFD is now known as Dmagick 2010-03-01T12:18:12 *** alxp has quit IRC 2010-03-01T12:22:40 *** alxp has joined #evergreen 2010-03-01T12:32:03 *** dbs has joined #evergreen 2010-03-01T12:35:45 *** r123 has quit IRC 2010-03-01T12:35:45 *** twirlip has joined #evergreen 2010-03-01T12:54:14 hey all, after adding a new circ modifier how do i map it to one of the rules in the circ matrix? 2010-03-01T12:55:16 mrpeters-isl: are you trying out in-DB circ rules or dealing with the old-style circ scripts? 2010-03-01T12:55:30 gmcharlt: i added them from the new in client interface 2010-03-01T12:55:43 but didnt see a location to match that up to the circ matrix 2010-03-01T12:56:29 circulation policy configuration im guessing is the "new way" 2010-03-01T12:57:10 guess not, know :) is this a test system or your production system? 2010-03-01T12:57:11 but im wondering if its wise to mix the ways we are doing this 2010-03-01T12:57:18 production 2010-03-01T12:57:58 it's either/or - you can use the legacy circ script support, or the new in-DB circ matrix, but not both at the same time 2010-03-01T12:58:09 ok, then i think we are still using the legacy 2010-03-01T12:58:09 for your production database, you're using the legacy circ scripts 2010-03-01T12:58:23 yeah, so its the stuff in /var/circ/js right? 2010-03-01T12:58:58 /openils/var/circ 2010-03-01T12:59:04 There must have been thought given to making the session cookie for logins use a path like /opac/ instead of /opac/en-CA/skin/lul/xml - is there some "Duhhhh, dbs... geez" reason why the more specific path was chosen? 2010-03-01T12:59:21 10-4 this rings a bell now (been since day 1 that we added new circ mods!) 2010-03-01T13:00:14 i can totally see the benefit to using the in-db version! this is messy 2010-03-01T13:02:27 * gmcharlt would argue the circ policies are inherently messy, but at least in-DB makes it easier to manage 2010-03-01T13:12:27 *** jamesrf has joined #evergreen 2010-03-01T13:13:59 WHEEEEEEEEEEEEEEEEEEEEE! so, for those that have been following along with the in-db xml pain, there will be bug-fix releases of postgres 8.3 and 8.4 which fix crashes caused by using both the in-core xml support and the contrib module (for xslt) 2010-03-01T13:14:12 now we just have to wait for distros to pick up the new versions... 2010-03-01T13:14:17 *** Dmagick has quit IRC 2010-03-01T13:14:38 *** 36DAAA345 has joined #evergreen 2010-03-01T13:14:51 miker_: any links to the relevant bug reports or changelogs? 2010-03-01T13:15:19 gmcharlt: I'll dig some up if you like. sec 2010-03-01T13:15:26 thanks 2010-03-01T13:16:37 http://archives.postgresql.org/pgsql-hackers/2010-02/msg02410.php 2010-03-01T13:16:46 *** jenny has quit IRC 2010-03-01T13:16:55 http://archives.postgresql.org/pgsql-hackers/2010-02/msg02429.php 2010-03-01T13:20:09 thanks again 2010-03-01T13:25:43 excellent! 2010-03-01T13:26:00 I did a little dance 2010-03-01T13:33:06 *** 36DAAA345 has quit IRC 2010-03-01T13:33:12 *** 40FAAINXE has joined #evergreen 2010-03-01T13:35:17 *** 40FAAINXE has quit IRC 2010-03-01T13:35:46 *** 5EXAAF1DI has joined #evergreen 2010-03-01T13:54:23 miker_: hmm. it looks like this might just be back-porting the patch from 8.4 (which is still crashy, at least on Ubuntu Karmic's take on 8.4). I could be wrong, though. I can always be wrong. 2010-03-01T13:56:59 oy vey, whitespace craziness in that oils_cstore patch 2010-03-01T14:03:59 *** rsinger has quit IRC 2010-03-01T14:10:11 *** jenny has joined #evergreen 2010-03-01T14:18:45 *** frzosima has quit IRC 2010-03-01T14:22:28 *** frzosima has joined #evergreen 2010-03-01T14:48:57 Can I make a suggestion that we add the Version= line to application.ini under the [App] header? 2010-03-01T14:55:01 *** 5EXAAF1DI has quit IRC 2010-03-01T14:55:15 dbs: the 8.3 backport was a precursor to the real fix, IIUC 2010-03-01T14:55:20 *** Dmagick has joined #evergreen 2010-03-01T14:58:20 *** jenny has left #evergreen 2010-03-01T15:02:28 emrikol: Any particular reason? 2010-03-01T15:05:09 moodaepo: Without it, the client cannot report its version to installing extensions, thus making it impossible to create an extension that works for only certain versions of the client. I also think it would stop the automatic update checking from seeing if new extensions are compatible, for the same reason (since the update.rdf also has the minVersion and maxVersion variables.) 2010-03-01T15:05:44 I didn't check the auto-updating part, since I already added the line before I set that up. 2010-03-01T15:06:31 emrikol: Ah I actually see that the packaged windows client doesn't have the version line, the linux clients do...which is why when I tried your extension on linux it didn't work 2010-03-01T15:06:59 commenting out that line on linux allowed me to install/test your extension on linux 2010-03-01T15:07:21 *** mrpeters-isl has quit IRC 2010-03-01T15:07:24 That's interesting. What was the version line in Linux? 2010-03-01T15:07:35 *** mrpeters-isl has joined #evergreen 2010-03-01T15:07:48 Well, I guess I could just go chek myself 2010-03-01T15:08:43 I think it get's assigned whatever you pass to the BUILD_ID during install, in my case it's "Version=rel_1_6_0_0" 2010-03-01T15:08:56 Ah-ha! 2010-03-01T15:09:01 I think I'd seen that in 1.4 before 2010-03-01T15:10:40 I completely forgot about that after we upgraded. The problem with that version string is that it is not the "Toolkit version format" that XULRunner expects. 2010-03-01T15:10:50 which would be 1.6.0.0 2010-03-01T15:11:33 https://developer.mozilla.org/en/XUL_Application_Packaging and https://developer.mozilla.org/en/Toolkit_version_format 2010-03-01T15:11:51 I blame this on Mozilla, because I can. 2010-03-01T15:12:38 oh, that sux0rs :) 2010-03-01T15:15:38 phasefx: you see? my typoed instructions to use rel_1.6.0.0 were almost on the mark! 2010-03-01T15:16:23 perl one-liner to take 'rel_1_6_0_0' style builds and turn them into 1.6.0.0 for application.ini? 2010-03-01T15:17:10 emrikol: I think we still need the "[XRE] EnableExtensionManager=1" entry 2010-03-01T15:17:53 Yes. Without it, the extension manager still opens up, but no matter what version you have, or version of the extension, it will always say it is "incompatible" 2010-03-01T15:18:02 http://svn.open-ils.org/trac/ILS/changeset/15639 2010-03-01T15:18:34 bah, don't follow that. Suffice it to say I commited the EnableExtensionManager line 2010-03-01T15:31:29 *** rsinger has joined #evergreen 2010-03-01T15:32:51 *** grantjohnson has joined #evergreen 2010-03-01T15:40:25 *** alxp has quit IRC 2010-03-01T15:59:53 *** Meliss has quit IRC 2010-03-01T16:08:18 dbs: the whitespace craziness in the cstore patch is mainly because the existing cstore code is indented with a mixture of tabs and spaces. As a result the alignment is chaotic when you look at it online in the repository. As I clean up various other things I'm tidying up the whitespace as I go. 2010-03-01T16:09:12 mck9: Understood, but for what seems to be a pretty important patch one would normally separate the whitespace changes out so that the important diffs could be focused on. 2010-03-01T16:10:09 yeah, separate patches for whitespace correction are definitely best practice 2010-03-01T16:15:58 This was going to be a pure whitepace/comment patch, but when I noticed some undefined behavior I didn't want to wait. The fix for that is actually very small and easily tested. In future I'll try to keep major whitespace patches more isolated though. 2010-03-01T16:16:27 *** bshum has quit IRC 2010-03-01T16:17:19 *** sfortin has quit IRC 2010-03-01T16:17:29 mck9: that would be awesome - and yeah, fixing undefined behaviour is Good(TM) 2010-03-01T16:21:38 dbs: fwiw, post-backport to 8.3, here's (the description of) the actual problem, and the fix that should be going (re pg xml stuff): http://archives.postgresql.org/pgsql-hackers/2010-02/msg02431.php 2010-03-01T16:22:23 miker_: ah, nice 2010-03-01T16:22:34 *** phase_bb has quit IRC 2010-03-01T16:24:23 * miker_ crosses fingers and leaves for home 2010-03-01T17:20:20 *** eby has quit IRC 2010-03-01T17:35:08 *** bott-otr has joined #evergreen 2010-03-01T17:46:00 *** phase_bb has joined #evergreen 2010-03-01T18:02:45 *** jamesrf has quit IRC 2010-03-01T19:01:02 *** dmagick-mac has left #evergreen 2010-03-01T19:09:20 *** jamesrf has joined #evergreen 2010-03-01T19:14:37 *** Dmagick-mac has joined #evergreen 2010-03-01T19:17:10 *** jamesrf has quit IRC 2010-03-01T19:19:00 *** jamesrf has joined #evergreen 2010-03-01T19:26:52 *** Dmagick-mac has quit IRC 2010-03-01T19:39:06 *** Dmagick-mac has joined #evergreen 2010-03-01T20:01:44 *** Dmagick-mac has quit IRC 2010-03-01T20:09:19 *** dbs has quit IRC 2010-03-01T20:36:44 *** lisppaste3 has quit IRC 2010-03-01T20:47:14 *** lisppaste3 has joined #evergreen 2010-03-01T20:50:31 *** Dmagick-mac has joined #evergreen 2010-03-01T21:00:58 *** brendan_bywater has quit IRC 2010-03-01T21:06:59 *** jamesrf has quit IRC 2010-03-01T21:15:59 *** brendan_bywater has joined #evergreen 2010-03-01T21:16:19 *** Dmagick-mac has quit IRC 2010-03-01T21:24:06 *** Dmagick-mac has joined #evergreen 2010-03-01T22:09:57 *** dbs has joined #evergreen 2010-03-01T23:01:49 *** jamesrf has joined #evergreen 2010-03-01T23:34:02 *** scott_r has joined #evergreen 2010-03-01T23:36:23 Anyone know an easy-ish way to add confirmations when tabs are about to navigate to another 'page'? Eg. When editing user information, the user hits 'checkout', a confirmation box could pop up asking them if they want to discard changes. 2010-03-01T23:36:49 onunload and onbeforeunload rarely seem to be triggered when this switch occurs 2010-03-01T23:38:03 *** mck9 has left #evergreen 2010-03-01T23:56:35 *** jamesrf has quit IRC