2011-02-08T00:29:13 *** youdonotexist has quit IRC 2011-02-08T00:30:54 *** bshum has joined #evergreen 2011-02-08T00:31:20 *** dave-esi_ has joined #evergreen 2011-02-08T00:31:41 *** atz has quit IRC 2011-02-08T00:32:32 *** dave-esi has quit IRC 2011-02-08T00:32:43 *** dave-esi_ is now known as dave-esi 2011-02-08T00:32:43 dbs: re: 001/035 behavior, thanks for answering my question awhile back. Curious about that setting though, according to the original commit it was done not enabled by default. Did this change to be enforced according to the standard? 2011-02-08T00:32:57 bshum: yes 2011-02-08T00:33:18 dbs: Cool, thanks. I have to explain to some of our catalogers why this enforcement is in play for 2.0 2011-02-08T00:34:05 They should be thrilled 2011-02-08T00:48:08 *** youdonotexist has joined #evergreen 2011-02-08T00:58:18 *** Guest32260 has quit IRC 2011-02-08T01:13:13 *** mjg_ has joined #evergreen 2011-02-08T01:13:43 *** mjg_ has left #evergreen 2011-02-08T01:21:41 *** bshum has quit IRC 2011-02-08T01:32:44 *** jennam has joined #evergreen 2011-02-08T02:47:01 *** jennam has quit IRC 2011-02-08T02:51:39 *** jennam has joined #evergreen 2011-02-08T02:52:05 *** jennam is now known as Guest18473 2011-02-08T03:05:07 *** Guest18473 is now known as jennam 2011-02-08T03:05:12 *** jennam has joined #evergreen 2011-02-08T03:07:38 *** brendan2 has quit IRC 2011-02-08T03:19:37 *** mrpeters-isl has quit IRC 2011-02-08T03:19:46 *** mrpeters-isl has joined #evergreen 2011-02-08T03:22:58 *** mrpeters-isl has quit IRC 2011-02-08T07:27:02 *** kmlussier has joined #evergreen 2011-02-08T08:03:36 *** alxp has joined #evergreen 2011-02-08T08:05:14 *** sfortin has joined #evergreen 2011-02-08T08:20:50 *** rsoulliere has joined #evergreen 2011-02-08T08:26:07 importing authorities question: are the steps for the 1.6.1 series the same as the 2.0 steps found here?: http://www.open-ils.org/dokuwiki/doku.php?id=authorities:2.0:importing_authority_records 2011-02-08T08:37:43 rsoulliere: not from the command line 2011-02-08T08:38:26 you might remember having to insert direct_ingest.pl in between marc2are.pl and pg_loader.pl 2011-02-08T08:43:17 *** r123 has joined #evergreen 2011-02-08T08:43:21 *** r123 has left #evergreen 2011-02-08T08:56:01 *** bshum has joined #evergreen 2011-02-08T08:56:26 dbs: yes, I remember there was another step for ingesting. Thanks. 2011-02-08T08:56:51 okay, a little unusual... OpenILS::WWW::Exporter isn't exporting a handful of records. The records to not appear to be deleted or otherwise inactive. 2011-02-08T08:56:55 * jeff digs 2011-02-08T08:58:01 *** mrpeters-isl has joined #evergreen 2011-02-08T09:09:19 *** bshum_ has joined #evergreen 2011-02-08T09:09:19 *** bshum_ has joined #evergreen 2011-02-08T09:09:44 *** bshum_ has joined #evergreen 2011-02-08T09:09:44 *** bshum_ has joined #evergreen 2011-02-08T09:09:52 *** bshum has quit IRC 2011-02-08T09:09:52 *** bshum_ is now known as bshum 2011-02-08T09:10:12 *** eby has left #evergreen 2011-02-08T09:10:15 *** atz has joined #evergreen 2011-02-08T09:10:28 *** atz has left #evergreen 2011-02-08T09:10:49 *** Meliss has joined #evergreen 2011-02-08T09:13:13 phasefx: i did some digging, and it looks like getelementById is the way to go for an xul listbox 2011-02-08T09:16:52 looking at https://developer.mozilla.org/en/XUL/listbox - it seems they're using a string length to tell which values are selected 2011-02-08T09:17:07 i don't think thats what we need to do for the profile listbox though, right? 2011-02-08T09:24:58 mrpeters-isl: What are you working on at this point? You have me curious now. 2011-02-08T09:26:26 tsbere: i'm working on including a permission profile filter in the patron search 2011-02-08T09:26:32 see v 2011-02-08T09:26:33 http://i56.tinypic.com/260bi2d.png 2011-02-08T09:26:51 i'm just REALLY struggling with linking up the selected values, to the actual search query 2011-02-08T09:27:25 Ok. You using selectedItems to get an array to walk over the values thereof? 2011-02-08T09:27:57 Or you relying on the backend somewhere to know how to handle multi-value form input? 2011-02-08T09:28:05 frankly, i don't know 2011-02-08T09:28:25 i know nothing about javascript - i'm totally reaching based on what little i've picked up from phasefx so far 2011-02-08T09:28:34 how about i post my diff's so far 2011-02-08T09:35:19 tsbere: http://blog.evergreen.lib.in.us/profilesearch.diff 2011-02-08T09:36:09 the more i'm looking at this page on mozilla, i think this is something different - this is what I'm doing with " var listbox = document.getElementById('multi-box'); " 2011-02-08T09:36:39 im not sure this document actually covers passing the selected rows into the submit function 2011-02-08T09:39:21 i'm trying to follow how "inactive" works in the submit function, but i'm geting lost with the variables i think 2011-02-08T09:40:32 query[id] = node.getAttribute('value'); - i don't follow what "node" is - it sort of looks like it's a variable equal to "document.getElementById(id);" but then i'm confused by what "document" is 2011-02-08T09:40:40 Well, for "clearall" I would use the "clearSelection()" function instead of selectItem(-1) 2011-02-08T09:42:19 Could be a tough row to hoe without grokking large chunks of the DOM, JavaScript, JavaScript manipulation of the DOM, and XUL 2011-02-08T09:42:38 do i have that in there? i was thinking i had the clear all/select all buttons out of this at the moment? 2011-02-08T09:42:54 You have the functions there at least 2011-02-08T09:43:01 The patch file you linked adds them 2011-02-08T09:43:29 oh right 2011-02-08T09:44:13 i can certainly change that, i was following the example from the "XUL Periodic Table" 2011-02-08T09:46:54 Ok mrpeters-isl, as for that "node" value, look up a little. In particular, at "var node = document.getElementById(id);". Node is a pre-fetched document.getElementById result. 2011-02-08T09:46:56 *** jenny has joined #evergreen 2011-02-08T09:48:44 mrpeters-isl: You appear to be going for multi-select ability as well. May be slightly harder to do, I don't think anything else in that form already does that. 2011-02-08T09:49:06 yeah, we need to be able to multi select 2011-02-08T09:49:29 people might want to search for Resident, Non-Resident, PLAC - but not Student - for example 2011-02-08T09:49:31 ah. my exporter issue from earlier was empty tags making MARC::File::XML puke. 2011-02-08T09:49:46 don't want to have to do lots of seperate searches by doing these individually 2011-02-08T09:50:45 tsbere: ok, so i see where the node variable gets set...but don't understand what document.getElementById(id); does? 2011-02-08T09:51:41 document.getElementById(id) returns a reference to the element having a specific id (in this case, whatever the id variable is set to at the time). If no such element exists it returns null/undefined. 2011-02-08T09:52:15 Thus, if you hand it an id for, oh, a listbox, the call will return a handle to that listbox 2011-02-08T09:52:35 oh my 2011-02-08T09:53:51 ok, so the first test in this function is where id == 'inactive' 2011-02-08T09:54:28 query[id] perorms a node.getAttribute('value') which i assume looks to see if "inactive" is checked or not? 2011-02-08T09:54:55 *** yboston has joined #evergreen 2011-02-08T09:55:31 so i need to build an else for (id == 'multi-box') then query[id] -- which is actually "mutli-box" for it's selected values, if any? 2011-02-08T09:56:24 Only problem: I don't know how to tell query[id] to accept multiple values. 2011-02-08T09:56:38 *** tspindler has joined #evergreen 2011-02-08T09:56:48 well, at least that gives me something more concrete to research 2011-02-08T09:58:13 tsbere: am i in the ballpark here? http://pastie.org/1541057 2011-02-08T09:58:33 except my awful formatting that got screwed up in the paste 2011-02-08T09:58:49 I am going to have to say "I don't think so" 2011-02-08T09:59:01 ok :( 2011-02-08T10:00:04 Line...12 of your paste? You want to add your code before that, starting with "} else if (id == 'multi-box') {" 2011-02-08T10:00:22 although I would highly recommend finding a better name than "multi-box" 2011-02-08T10:00:56 tsbere: yep - plan is to rename that to "profile" but i figured i should get it working first, before tinkering 2011-02-08T10:02:37 something more like http://pastie.org/1541057 ? 2011-02-08T10:03:45 err and add a ) after 'multibox' 2011-02-08T10:04:22 Closer, yea. You using vim right now? 2011-02-08T10:04:35 i'm actually using notepad++ 2011-02-08T10:04:47 Ahhh. Dunno how to tell you to fix your tabs instead of spaces in notepad++. 2011-02-08T10:04:47 editing on windows - dirty i know 2011-02-08T10:05:04 yeah i will fix it up in vim 2011-02-08T10:05:18 Not going to complain about your choice of editing environment, just find it easier if tabs and spaces are consistent in pastes. 2011-02-08T10:05:36 Don't forget to remove your extra else at the end, though. 2011-02-08T10:05:44 oh right 2011-02-08T10:07:18 so, key now is figuring out how to make a query see the multiple selected values? 2011-02-08T10:07:56 tsbere: i'm also wondering if i need the "obj.error.sdump('D_DEBUG','id = ' + id + ' value = ' + node.getAttribute('value') + '\n');" that i see in a few places in this else if 2011-02-08T10:07:59 i believe you're going to be in the perl for that. i don't think it currently handles multiple values. 2011-02-08T10:08:33 mrpeters-isl: That is a debugging line. You may need a few. 2011-02-08T10:08:36 and you'll likely be changing the api. 2011-02-08T10:09:01 ok, maybe phasefx can chime in on that jeff - he was thinking yesterday that modifying search_result.js to add a "case 'profile' would avoid having to get into the perl 2011-02-08T10:09:45 to have the client filter the results by profile from the full set returned by the api call? 2011-02-08T10:09:53 would doing query[id] = node.getAttribute('value'); get this working for just a single selection? 2011-02-08T10:10:41 node.selectedItem.getAttribute('value') I think. But your id would be wrong then. 2011-02-08T10:10:57 I think your id needs to be "profile" at that point. 2011-02-08T10:11:33 hmm so the id == 'profile' doesn't do that? 2011-02-08T10:12:08 *** atz_ has joined #evergreen 2011-02-08T10:12:22 Your id is currently "multibox". You would want to change that to "profile", I think. 2011-02-08T10:12:32 yes i've started doing that 2011-02-08T10:12:44 sorry - i took your advice and went ahead and changed it now, rather than later 2011-02-08T10:13:33 *** atz_ has left #evergreen 2011-02-08T10:14:59 yay! !! This software has encountered an error. Please tell your friendly system administrator or software developer the following:\npatron/search_form.xul\nTypeError: listbox is null\n 2011-02-08T10:16:20 my xul is using a listbox id="profile" 2011-02-08T10:16:38 search_form.js has var listbox = document.getElementById('profile'); 2011-02-08T10:16:44 what did i break? 2011-02-08T10:17:03 Dunno. Don't have your current patch. 2011-02-08T10:17:12 yeah let me do that 2011-02-08T10:17:16 And yea, looks like the perl layer will need to be touched. 2011-02-08T10:17:34 It won't know the profile field until it is 2011-02-08T10:17:58 Side bonus: You can decide how it wants the profile field! Kindof. 2011-02-08T10:19:12 http://blog.evergreen.lib.in.us/profilesearch-rev2.diff 2011-02-08T10:19:18 * phasefx would expect for the perl to need some love for multi-values 2011-02-08T10:19:48 ok - maybe someone with more knowledge on that likes this idea and wants to help :) 2011-02-08T10:19:56 phasefx: The perl doesn't know how to search for any patron field not already there. Ad-hoc fields aren't included, if I am reading it right. 2011-02-08T10:20:16 search_form is building a simple query hash (field name => value), and search_result is munging it into something the perl wants (grouping certain fields together) 2011-02-08T10:20:36 open-ils.storage.actor.user.crazy_search only knows specific field names, though. 2011-02-08T10:20:48 I think any field on actor.usr is fair game as long as search_result is putting it with the other "group 0" fields 2011-02-08T10:20:56 really? 2011-02-08T10:20:57 bleh 2011-02-08T10:22:17 phasefx: feel free to point out that I don't know enough about perl to see the ad-hoc field inclusions. 2011-02-08T10:22:32 (and then please point me where they are) 2011-02-08T10:22:55 oh you're very likely right. I had skimmed the other day and thought otherwise 2011-02-08T10:23:25 mrpeters-isl: going to be a fun project for you :-) 2011-02-08T10:23:41 mrpeters-isl: Well, one thing that jumps at me is that you put a haha it's getting very near something out of my skill range 2011-02-08T10:24:46 *** senator has left #evergreen 2011-02-08T10:25:16 mrpeters-isl: Also, your xul is still using "multi-box" instead of "profile" 2011-02-08T10:25:27 wait, it is? 2011-02-08T10:25:57 and a couple other references just after that 2011-02-08T10:26:10 ok - weird i have 2011-02-08T10:27:31 You should probably remove your obj.error.sdump, or adjust the node.getAttribute to include the selectedItem piece 2011-02-08T10:28:24 As for your "listbox is null", the issue is likely the fact that this patch doesn't have a listbox with id of "profile". 2011-02-08T10:28:51 Thus when you try to listbox.appendChild you are basically doing undefined.appendChild 2011-02-08T10:30:12 yeah this patch isn't accurate i did something wrong with svn diff i guess 2011-02-08T10:30:38 You can attempt to protect against that by wrapping your for block in an "if (listbox) { }" 2011-02-08T10:37:06 hey! it works! 2011-02-08T10:37:14 (with a single profile selected, that is) 2011-02-08T10:37:32 Does it actually limit by that, or just not fail? 2011-02-08T10:37:45 limits! 2011-02-08T10:37:48 i filtered by Circ1 2011-02-08T10:38:01 only have "main (profile) permission group" = 24 in the results 2011-02-08T10:38:13 no other search terms....just selected Circ1 2011-02-08T10:38:34 * tsbere now wonders where it knows profile or ad-hoc in writing the query 2011-02-08T10:38:40 maybe i'll just turn this into a "dropdown" and make it "include only this profile" 2011-02-08T10:39:07 works like a charm with all of the different profiles 2011-02-08T10:39:49 if you select Circ1 and Circ2 it just only includes the Circ1 results 2011-02-08T10:39:53 which is expected 2011-02-08T10:40:10 Hmmm. Now I think I see, looks like it is, in fact, grabbing ad-hoc from the group 0 and group 1 blocks. Missed that on my first read-through. 2011-02-08T10:40:27 tsbere: so maybe this can be made to work without touching the perl? 2011-02-08T10:40:52 Only for single-profile check. If you want multi-profile checking, on the other hand........ 2011-02-08T10:41:02 ah ok 2011-02-08T10:41:23 ok perl experts - who want's to team up :) 2011-02-08T10:41:37 mrpeters-isl: Looks like it should be fairly easy on the perl side, actually 2011-02-08T10:41:54 yeah? how about for smoeone who has never written a line of perl in their life? lol 2011-02-08T10:42:18 mrpeters-isl: Fairly easy, actually. Especially if I give you the line and tell you where to put it. ;) 2011-02-08T10:42:30 haha that'd make me cry tears of joy :) 2011-02-08T10:42:39 wow C4L11's streaming is very good - I'm wishing we could do something similar for EG11 2011-02-08T10:42:50 csharp: why not? 2011-02-08T10:42:59 * csharp will look into it ;-) 2011-02-08T10:43:00 mrpeters-isl: Worse if you want to match those in a child of a given group, though. 2011-02-08T10:43:02 indiana has some equipment im sure i could lug down! 2011-02-08T10:43:09 tsbere: don't want to do that 2011-02-08T10:43:17 you have to explicitly select the profile in the list for it to be included 2011-02-08T10:44:26 mrpeters-isl: I'll keep that in mind - thanks ;-) 2011-02-08T10:45:26 mrpeters-isl: Ok, I have at least one "er, wha?" moment here in the perl. <_< Not sure how to handle it yet. 2011-02-08T10:45:33 dont worry 2011-02-08T10:46:38 * tsbere isn't sure how to deal with selectcol_arrayref at the moment 2011-02-08T10:48:55 Well, as a general idea, it could be handled with turning the list of ids into a 1,2,3,4 list, then doing profile IN () in the sql. I just lost any idea how the sql would need to be edited. 2011-02-08T10:49:12 mainly due to not knowing how to use selectcol_arrayref 2011-02-08T10:51:22 brb - need to reboot 2011-02-08T10:51:32 *** mrpeters-isl has quit IRC 2011-02-08T11:03:41 *** dbs has quit IRC 2011-02-08T11:04:07 *** mjg_ has joined #evergreen 2011-02-08T11:05:47 *** dbs has joined #evergreen 2011-02-08T11:05:47 *** dbs has joined #evergreen 2011-02-08T11:12:54 *** bshum has quit IRC 2011-02-08T11:13:21 *** mrpeters-isl has joined #evergreen 2011-02-08T11:13:26 *** mjg_ has left #evergreen 2011-02-08T11:13:34 * mrpeters-isl is back - that was a rough reboot! 2011-02-08T11:14:04 And I am not sure that multiple profile group search is easy anymore, having dug up some docs. At least, not how the query is generated currently. 2011-02-08T11:14:16 ah bummer! 2011-02-08T11:14:48 I could be wrong, but I don't think you can bind an IN(?) parameter. 2011-02-08T11:16:23 you can't 2011-02-08T11:17:41 but, you can count the number of elements in the array and bind them: 'IN (' . join(',', map {'?'} @$list) . ')'; ...; $sth->bind(@$list); (or the like) 2011-02-08T11:17:42 tsbere: standard solution is to generate the IN (?[, ...]) with the appropriate number of placeholders for your incoming array, prep that statement, then bind the values 2011-02-08T11:18:26 dbs: I figured as much. My perl-fu is not strong enough to do that and be sure I am doing it even close to right at the moment, though. 2011-02-08T11:20:00 http://blog.evergreen.lib.in.us/profilesearch.patch is the "working" version of this that will search one selected profile 2011-02-08T11:20:08 got the issue with svn diff sorted 2011-02-08T11:21:50 tsbere: several examples in the modules under OpenILS::Application::Storage::Publisher, IIRC 2011-02-08T11:21:57 and mrpeters-isl 2011-02-08T11:23:52 mrpeters-isl: just a style note, the code generally cuddles }{ to the block ... same style makes maint easier 2011-02-08T11:24:32 *** atz has joined #evergreen 2011-02-08T11:24:44 ok 2011-02-08T11:24:54 i will try and find my mistakes and clean up 2011-02-08T11:25:08 *** atz has left #evergreen 2011-02-08T11:28:13 eeevil: forgive me - i'm not sure i follow what's off 2011-02-08T11:28:26 i'm looing at the new else if i added for (id == profile) 2011-02-08T11:28:54 im looking at the if above for it's style - seems liek i did the same? 2011-02-08T11:29:32 mrpeters-isl: you have your else-if and else on a new line, but they should be cuddled to the preceding } 2011-02-08T11:29:47 } else { instead of }\n else { 2011-02-08T11:29:51 ah i think i see 2011-02-08T11:30:45 like so - http://i51.tinypic.com/2lsdvzn.png ? 2011-02-08T11:31:04 right 2011-02-08T11:31:05 *** mjg_1 has joined #evergreen 2011-02-08T11:31:12 ok that does make it easier to follow 2011-02-08T11:31:14 thanks for the tip 2011-02-08T11:31:37 it's more about following the surrounding conventions, but I agree, it's easier to follow 2011-02-08T11:31:56 *** mjg_1 has left #evergreen 2011-02-08T11:32:32 and that patch from earlier - it's wrong - it used lang.dtd from 2.1 not trunk...just caught that 2011-02-08T11:32:38 err 2.0.1 that is 2011-02-08T11:33:15 *** mjg_ has joined #evergreen 2011-02-08T11:33:31 *** mjg_ has left #evergreen 2011-02-08T11:33:45 proper version now up at the same url 2011-02-08T11:35:50 *** eby has joined #evergreen 2011-02-08T12:01:03 *** jamesrf has joined #evergreen 2011-02-08T12:05:04 dev meeting? 2011-02-08T12:05:18 * eeevil fears he just volunteered for something ... :) 2011-02-08T12:05:35 *** tspindler has quit IRC 2011-02-08T12:05:44 * phasefx sure wasn't speaking first :D 2011-02-08T12:09:57 wondering if weekly needs to change to biweekly. 2011-02-08T12:10:10 uh, yeah 2011-02-08T12:10:25 * tsbere thought weekly dev meetings were only until 2.0 came out anyway 2011-02-08T12:10:54 I just have one thing to ask ... shall I cut a 2.1 alpha from trunk asap? (integrating some patches from LP first) 2011-02-08T12:11:16 (also, grabbing 0482) 2011-02-08T12:11:35 alphas for 2.1 already? Pretty fast moving. 2011-02-08T12:11:48 eeevil: sounds good to me. and the more you can flesh out those build-cutting steps (and ++ for that!) the bettah 2011-02-08T12:12:19 tsbere: I'd like to try a rolling release cycle to avoid the dogpile at the end and encourage testing earlier 2011-02-08T12:12:26 spell out some of the mental logic for upgrade numbers 2011-02-08T12:12:28 and to get 2.1 out more fasterer 2011-02-08T12:12:32 tsbere: hey, 2.0 is done as far as features go 2011-02-08T12:13:06 2.1 should get us your good stuff on staff client building + upgrading 2011-02-08T12:13:17 true. true. 2011-02-08T12:13:21 and in-db junk 2011-02-08T12:13:32 * tsbere still has to do fallthrough and such for circ again 2011-02-08T12:13:41 as far as today's meeting goes, the agenda was http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-02-08 2011-02-08T12:14:20 bshum++ # for that 2011-02-08T12:15:04 eeevil: you're not just branching a 2.1, but want to tag an alpha too? There's a string I'd want to change with the staff client windows installer, where it's using Trunk in the installation path 2011-02-08T12:15:34 we can just defer the rest to next meeting - if we move to biweekly, then we can get back to announcing them on-list, etc; weekly got too noisy for that 2011-02-08T12:15:43 * dbs admits to having been distracted by #code4lib 2011-02-08T12:16:12 phasefx: I'm not branching anything 2011-02-08T12:17:05 * tsbere should fix some issues with the installer, for that matter 2011-02-08T12:17:10 eeevil: on the build steps, I'm trying to figure out where to automate when possible, and some bits seem to currently require human intervention (determining the start and end points for generating changelogs, for example) 2011-02-08T12:17:37 the plan is to have a branches/rel_2_1 at some point? 2011-02-08T12:18:10 eeevil: also, I think you can safely rm -fr build/i18n before tarring up and save 30MB on-disk. My mind was blown when I realized that the tarball extracts to > 100 MB 2011-02-08T12:20:43 *** r123 has joined #evergreen 2011-02-08T12:21:03 we have opened up testing on 2.0.0 to some of our sites, only one issue so far but they just started 2011-02-08T12:21:15 sitka++ 2011-02-08T12:21:17 the one issue was a display glitch with 'estimated wait time' in the PAC 2011-02-08T12:21:22 i have to confirm the issue 2011-02-08T12:21:30 dbs: I will start doing that for real releases 2011-02-08T12:21:40 (rm -rf build/i18n) 2011-02-08T12:21:49 jamesrf++ 2011-02-08T12:22:16 eeevil: coolness 2011-02-08T12:22:25 phasefx: yes, we would (eventually) need a rel_2_1 branch for back-porting bug fixes. since 2.1 is equivalent to trunk at this point, though, i don't think it's critical to create the branch now 2011-02-08T12:22:49 well... 2011-02-08T12:23:03 if we're cutting an alpha, yeah, we do need the rel_2_1 branch 2011-02-08T12:23:15 or 2_1 will start picking up trunk-only stuff 2011-02-08T12:23:40 berick: is that a problem? 2011-02-08T12:24:06 2_x, where x is a fixed set of features, right? 2011-02-08T12:24:09 I thought the new rule was "new stuff in trunk only, and release therefrom" 2011-02-08T12:24:13 is there any trunk-only stuff yet? 2011-02-08T12:24:43 otherwise we should have a rel_2 branch, which we don't 2011-02-08T12:25:02 and wouldn't serve much purpose unless we're working on 3.0 stuff right now 2011-02-08T12:25:04 IMO 2011-02-08T12:25:34 eeevil: well, yeah, alpha implies a fixed set of features to me. 2011-02-08T12:25:37 hey phasefx: xul formatting question -- since we're hung up on the multi-choice searching, I was thinking I'd move on to trying to make this search box "hidden" unless you expand it out 2011-02-08T12:25:55 berick: ahh... well, that's the difference in our thinking ;) 2011-02-08T12:26:01 * phasefx just doesn't want to see anything labelled 2.1.x coming from trunk 2011-02-08T12:26:06 fixed, but slightly moldable 2011-02-08T12:26:14 the closest thing i can find on the top.xul is a tree - but i'm not sure that's the appropriate way for hiding the listbox? 2011-02-08T12:26:21 berick: I was thinking more along the lines of "stuff that may (will?) be coming in 2.1, but not all of it) 2011-02-08T12:26:26 er, s/)/" 2011-02-08T12:26:51 IOW, I want to avoid dogpiling at the end of a dev cycle 2011-02-08T12:27:02 eeevil: Why bother calling it 2.1 alpha. Call it "trunk preview (svn rev #)" or something instead. 2011-02-08T12:27:15 tsbere++ 2011-02-08T12:27:28 tsbere: as a psycological aid to get people to actually test stuff out :) 2011-02-08T12:27:31 mrpeters-isl: one sec 2011-02-08T12:27:32 eeevil: i see it that way too, generally, but without the branch it really means "stuff that will be coming in 2.1, but not all of it, and then maybe some other stuff we didn't want to get into 2.1 yet" 2011-02-08T12:27:52 berick: is there anything that we don't want in 2.1? 2011-02-08T12:27:56 IOW, w/o a branch to back-port to, 2.1 is a free-for-all of features 2011-02-08T12:27:57 ah darn it sorry guys didn't realize dev meeting was going 2011-02-08T12:28:16 or, rather, is there stuff we want in trunk (as opposed to topic branches) that can't be done before 2.1 comes out 2011-02-08T12:29:09 eeevil: by calling trunk 2.1, we are saying you are not allowed to commit code to trunk that should not go into 2.1. 2011-02-08T12:29:21 (I mention topic branches because many of us are now using them, and we seem to be headed that way (DVCS)) 2011-02-08T12:29:23 which i'm not necessarily opposed to, just want to be clear on the plan 2011-02-08T12:30:13 berick: right, that's what I'm saying ;) ... but the reverse of that is, what do we not want in 2.1? (that isn't being handled in another way than an svn branch right now) 2011-02-08T12:30:28 nothing that I'm aware of ATM 2011-02-08T12:30:41 berick: if i may -- in python, if using an iterator "for foo in some_iterator:" that raises an exception DURING the iteration, i can't "move on to the next iteration" 2011-02-08T12:30:48 berick: i think i answered my own question. :) 2011-02-08T12:30:59 (which isn't me trying to be argumentative, but trying to be clear on the purpose of my proposal) 2011-02-08T12:31:06 jeff: :) 2011-02-08T12:31:26 mangled_marc-- 2011-02-08T12:31:33 eeevil: what happens if somebody new comes up with something that is worthwhile to commit to trunk but not quite ready for prime time (i.e., a 2.1 release)? 2011-02-08T12:31:44 jeff: the first part there was redundant, IMO 2011-02-08T12:32:04 I mean, sure, once we have a DVCS we can more readily maintain such experimental stuff in a topic branch 2011-02-08T12:32:21 gmcharlt: what does? I think it's held off in a patch or topic branch 2011-02-08T12:32:29 but we're not quite there yet 2011-02-08T12:32:39 we can branch in svn for topics... 2011-02-08T12:33:04 if we really need to 2011-02-08T12:33:42 (digression: that's one of the advantages of most/all DVCSs - takes the "really need to" roadbump out of choosing to start a topic branch) 2011-02-08T12:33:44 do we have a plan for what we want/expect in 2.1? 2011-02-08T12:33:56 so, it comes down to risk (new "trunk"-only feature appears) vs maint overhead (have to commit everything to both trunk and rel_2) 2011-02-08T12:34:44 dbs: not written down yet, but there's the "post-2.0" page now 2011-02-08T12:34:55 i think you'd also still have the option of "hey, i'm about to commit this big neat thing to trunk, we should probably make a rel_2 branch now" 2011-02-08T12:35:04 hey phasefx - when you have time - http://blog.evergreen.lib.in.us/profile.xul 2011-02-08T12:35:14 i think something like that would be cleaner 2011-02-08T12:35:18 jeff: absolutely 2011-02-08T12:36:15 jeff: agreed - if we're not quite ready to branch off rel_2 now, we obviously can do so later; this may be more a discussion about what we call the trunk snapshots 2011-02-08T12:36:17 related, having to think a little more about the stability of trunk (and having one target to think about) doesn't seem bad to me 2011-02-08T12:37:14 before 2.0, we had (at least) 2 targets for most things -- trunk and "next release" -- and often more for anything bug-ish 2011-02-08T12:37:39 +1 to keeping trunk more stable 2011-02-08T12:38:05 one of the reasons AIUI for moving to 3-part release numbering is to reduce both the breadth of supported releases and the overhead of maintaining the repo (less branches to cross-port) 2011-02-08T12:38:06 +1 to that 2011-02-08T12:39:18 and that, I think, is a midpoint between lots of supported releases and ubuntu-style times/monotonic releases 2011-02-08T12:39:30 maybe I'm taking branch reduction too far? 2011-02-08T12:39:32 dunno 2011-02-08T12:40:08 eeevil: i think yr just taking it 1 step further than perhaps anticipated. again, not a bad thing (i like simplicity) just need to agree on what it means to everyone 2011-02-08T12:40:12 but, I'd like to get things out faster (and have many more "cuts") that have a name non-devs want to test ... 2011-02-08T12:40:17 I think any "release", alpha, beta, or otherwise from trunk should state it is from trunk. If you want to label it 2.x then make a place to commit 2.x stuff to. 2011-02-08T12:41:10 couldn't we branch a rel_2_1, allow backports of features and alpha tags until we decide to call it feature frozen, at which point we no longer backport features and only tag betas or releases? 2011-02-08T12:41:12 Although I suppose a compromise could be 2.trunk.svnrev or something. :P 2011-02-08T12:41:18 with a possible ultimate end point of fully-automatic nightly builds 2011-02-08T12:41:20 tsbere: unless, that is, we only cut feature releases from trunk ... but I take your (and others') point 2011-02-08T12:42:50 phasefx: of course we can do that, but I'm trying to avoid the need to backport everything (everything) if the risk we're avoiding (something that shouldn't go into 2.1) has no concrete example 2011-02-08T12:42:55 * dbs doesn't find "svn merge -c #### svn://svn.open-ils.org/ILS/trunk; svn log -c #### svn://svn.open-ils.org/ILS/trunk; svn ci" too cumbersome for backporting to one or more branches 2011-02-08T12:43:38 (although DVCS branching/merging would probably be much less painful) 2011-02-08T12:43:53 since it's just trunk <=> rel_2_1 with nothing in between, no more great catalcylsms with whitespace, etc. I find it trivial to backport 2011-02-08T12:45:29 I have no real problems with that ... I'm not crazy about "nothing in between", but that's a gut reaction, not an intellectual one 2011-02-08T12:45:58 you threw me for a loop when you first mentioned a rel_2 2011-02-08T12:47:17 so, revised proposal on the table is: branch rel_2_1 now, devs backport to that for nearly everything new, cut alphas (not feature locked -- that's beta from now on (secondary vote requested on that)) from that 2011-02-08T12:47:22 *** Dyrcona has joined #evergreen 2011-02-08T12:48:00 and work towards automating the cutting process 2011-02-08T12:48:04 +1 to revised propposal 2011-02-08T12:48:15 +1 to that 2011-02-08T12:48:18 +1 2011-02-08T12:48:18 +1 2011-02-08T12:48:38 and to revisit after (if) we move to a dvcs 2011-02-08T12:49:02 dbs: btw, how about a command line param for the "previous revision" for changelog, then a person runs the script (builder web app, whatever) with that param 2011-02-08T12:49:03 berick: would need to revist the automation bit, if only to start pulling revision numbers, etc from the new system 2011-02-08T12:49:05 where topic branches can bake longer in the public eye 2011-02-08T12:49:50 *nod* 2011-02-08T12:50:14 eeevil: I was thinking that would be a first step (dropped into build/tools), but the system needs to be able to figure out as much as possible 2011-02-08T12:51:50 dbs: ideally, yes. I'm sure there's a way to use svn log to get the last revision on a branch (tag) (which is what I do manually) 2011-02-08T12:51:54 eeevil: e.g. if we went with your every-two-week scheduled release, ideally no human input would be required 2011-02-08T12:52:36 dbs: sure, that works for monotonic trunk (or branch, I guess) ... less so for releases 2011-02-08T12:53:04 or the tool could simply modify a "last release revision" file, and commit that 2011-02-08T12:53:31 s/last/previous/ 2011-02-08T12:53:38 eeevil: yeah, although that can be deceiving - to get the changelog for 2.1.0, using the last commit for rel_2_0 as the start point and the last commit for rel_2_1_0 as the end point might not tell the real tale 2011-02-08T12:53:59 right 2011-02-08T12:54:52 more important than that though is probably the Dojo layer build, including our 1.3 patches 2011-02-08T12:55:52 yeah ... we have a blob to use, we may just have to include my mechanations directly in the script 2011-02-08T12:57:14 Ideally into the Makefile.am or build/tools so that others can recreate / tweak locally with a bit more ease, but I'll take anything :) 2011-02-08T12:57:51 ahh, yes, indeed. good point 2011-02-08T12:59:55 *** jamesrf has quit IRC 2011-02-08T13:00:44 ok ... I'll make the rel_2_1 so RSN 2011-02-08T13:00:58 *** jamesrf has joined #evergreen 2011-02-08T13:01:13 tsbere: is https://bugs.launchpad.net/evergreen/+bug/635463 outdated now? (Oct 2010 fallthrough patch) 2011-02-08T13:01:33 eeevil: Horribly outdaded. 2011-02-08T13:01:56 Doesn't take into account dynamic weighting, hard due dates, and several other things at this point 2011-02-08T13:02:07 * tsbere can have a replacement in the fairly near future 2011-02-08T13:02:30 tsbere: no rush, just checking 2011-02-08T13:04:42 has anyone had a chance to poke at gmcharlt's proposed fix in https://bugs.launchpad.net/evergreen/+bug/678078 ? that's the css selector change to get html elements to respect font sizes intended initially for xul (would effect all html interfaces, I think, which is probably the right thing to do) 2011-02-08T13:05:10 (also, if testing shows good results, I'd call that a bug fix) 2011-02-08T13:06:35 * phasefx will test it today 2011-02-08T13:07:31 phasefx: cool. if you're feeling saucy, add a sign-off when you commit it :) 2011-02-08T13:08:21 maybe I'll make an experiment of it.. pulling from that git repo into mine, etc. 2011-02-08T13:08:45 and, finally, https://bugs.launchpad.net/evergreen/+bug/702518 (missing perms in trunk) ... Dyrcona, will you have the bandwidth to fix the oils_i18n_gettext changes required to make that committable? (put the id value in the first param to that function) 2011-02-08T13:09:14 or anyone for that matter ... 2011-02-08T13:09:16 yeah. I can. 2011-02-08T13:09:21 Dyrcona++ 2011-02-08T13:09:40 ok ... branching rel_2_1 now ... BEWARE, COMMITTERS! 2011-02-08T13:09:47 you just want me to put the id in, I don't have to come up with any translations? 2011-02-08T13:10:38 Dyrcona: it looks like you've retained the strings that were there before, so that should be enough ... unless you want to add descriptions for those missing any ;) ... I'm not going to /stop/ you 2011-02-08T13:10:55 but committable with current data is enough for me to be happy 2011-02-08T13:11:01 so do you want the same ids as in 2.0? 2011-02-08T13:11:37 Dyrcona: yes please, if there's no collision 2011-02-08T13:12:03 ok. i'll get on that in a couple of minutes. 2011-02-08T13:12:07 rock 2011-02-08T13:13:27 *** Rhod has joined #evergreen 2011-02-08T13:14:03 phasefx: i've got a solid revision at http://paste.lisp.org/display/119486 - this revision gives !! This software has encountered an error. Please tell your friendly system administrator or software developer the following:\npatron/search_form.xul\n[Exception... "Node cannot be inserted at the specified point in the hierarchy" code: "3" nsresult: "0x80530003 (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR) 2011-02-08T13:14:03 " location: "http://dev.evergreen.lib.in.us/xul/rel_2_0_1/server/main/JSAN.js Line: 513"]\n -- i think i've done something wrong in populating the treerow values from my_pgt 2011-02-08T13:15:31 mrpeters-isl: you're appending a treerow to itself 2011-02-08T13:15:39 rel_2_1 exists 2011-02-08T13:15:45 eeevil++ 2011-02-08T13:16:18 mrpeters-isl: where you do var treerow = document.getElementById('profile'); use a different variable name there. And change treerow.appendChild(treerow); to match 2011-02-08T13:17:38 mrpeters-isl: actually, the xul element you're using is more complex than the listbox.. you'll need to do more here 2011-02-08T13:17:48 ah crap ok 2011-02-08T13:18:01 well, first off - do you think this is the right direction as far as "look" 2011-02-08T13:18:05 mrpeters-isl: are you going for a single-select instead of multi-select? I'd suggest a drop-down menu if so 2011-02-08T13:18:17 i'm still planning for multi-select in the future 2011-02-08T13:18:32 if tsbere is able to help later on, i figure it's best to build it so it's ready for multi 2011-02-08T13:18:56 I can give it a shot. I have to dig into the perl stuff for fallthrough again anyway. 2011-02-08T13:19:27 i've had a couple of groups express interest if i can get this worknig, so i thikn it's worth following through on 2011-02-08T13:19:46 but i think phasefx knows best of all how it should "look" in the client 2011-02-08T13:20:16 mrpeters-isl: I think a tree is a good way to go if you want to show the hierarchy of the perm groups 2011-02-08T13:20:51 yeah, i'm not sure we care to do that though, do we? since it gets really tough to include "children" of something in the search results 2011-02-08T13:20:52 but it makes building it dynamically more complicated :) 2011-02-08T13:21:29 mrpeters-isl: You would be amazed how many helper functions exist for including children. 2011-02-08T13:21:49 might even could get the tree to do that work for you (and select descendants) 2011-02-08T13:22:01 That could be the case as well 2011-02-08T13:22:01 tsbere: i'm sure they woudl, but I'm not sure i'll be able to pick up on most of this via irc --- maybe at hackfests? 2011-02-08T13:22:49 * tsbere has yet to attend a hackfest 2011-02-08T13:23:09 * tsbere has also yet to attend a conference in general, too busy 2011-02-08T13:23:18 ah ok 2011-02-08T13:23:55 mrpeters-isl: off to lunch 2011-02-08T13:24:01 no problem - thanks for help so far 2011-02-08T13:25:01 I'm not sure how educational the hackfests to date have been - probably hit or miss for individuals 2011-02-08T13:25:37 maybe not, but i'm probably more likely to pick up on something working side by side with someone than i would by looking at file revisions 2011-02-08T13:28:16 i think i'll convert this to a groupbox for now and i bet it'd still be helpful for people to be able to filter to just one specific patron profile 2011-02-08T13:31:16 okay, this breaks the exporter -- i think there was at least a UI fix that prevented these from being created: 2011-02-08T13:33:46 jeff: 1.6? 2.0? 2011-02-08T13:43:32 dbs: exporter in 1.6. i was looking for the changeset to see how deep it goes, then got distracted. 2011-02-08T13:43:56 if there are broken records out there, it might be worth at least documenting the suggested mass update. 2011-02-08T13:43:57 *** bshum has joined #evergreen 2011-02-08T13:44:22 my other issue is that i have some marcxml that both marcedit and MARC::File turn into invalid MARC21 2011-02-08T13:44:58 i suspect leader/control are broken in the xml and are being used (with breakage effect) in the resulting MARC21, but not sure yet. 2011-02-08T13:45:15 in any case, good test "break me" record i'll try to share 2011-02-08T13:47:08 jeff: incorrect encoding leader is a very common cause of breakage when MARC::File tries to do the right thing given bad input data 2011-02-08T13:47:25 and yeah, feel free to document! 2011-02-08T13:48:21 jeff pasted "troublesome MARCXML" at http://paste.lisp.org/display/119488 2011-02-08T13:48:28 dbs: thanks. i'll look there next. 2011-02-08T13:49:13 argh i'm so close here - http://paste.lisp.org/display/119486#1 but I'm getting an empty dropdown 2011-02-08T13:49:18 00759cam a2200241 454500 2011-02-08T13:49:21 (Directory offset 240: Bad value for data length and/or length starting) 2011-02-08T13:49:21 (Directory offset 24: Data out of bounds 14340 >= 759) 2011-02-08T13:49:33 i thought i woould be pulling in the menuitem label's from my_pgt.name 2011-02-08T13:50:37 dbs: i have pymarc, marcedit, MARC::File, and yaz-marcdump at my disposal. other than a text/hex editor, any essential marc-de-mangling / marc-debugging tools I should add to my tool bag? 2011-02-08T13:57:53 *** bshum_ has joined #evergreen 2011-02-08T13:58:04 *** bshum has quit IRC 2011-02-08T13:58:04 *** bshum_ is now known as bshum 2011-02-08T14:04:34 00926cam a2200301Ia 4500 2011-02-08T14:04:39 00711cam a2200229 45004500 2011-02-08T14:04:42 ding ding ding! 2011-02-08T14:05:13 mmm 2011-02-08T14:05:17 jeff++ 2011-02-08T14:05:31 * dbs just added a patch to https://support.process-one.net/browse/EJAB-1399 2011-02-08T14:07:39 *** bshum_ has joined #evergreen 2011-02-08T14:07:59 *** bshum has quit IRC 2011-02-08T14:08:08 dbs++ 2011-02-08T14:08:37 *** bshum_ has quit IRC 2011-02-08T14:08:59 so the lesson here is don't be so trusting when it comes to the leader in marcxml 2011-02-08T14:09:12 i've NO IDEA how this leader became so mangled, though. 2011-02-08T14:11:15 I've seen the MARC Editor fixed fields helper do some mangling in the past, not sure if it was in a particular version 2011-02-08T14:11:29 or whether it's still the case :/ 2011-02-08T14:11:53 never trust marc or the humans that touch it 2011-02-08T14:12:24 eeevil: permission ids match very little between trunk and 2.0. the first 5 don't even match. 2011-02-08T14:12:38 eby: I second, third and fourth that. 2011-02-08T14:13:26 *** bshum has joined #evergreen 2011-02-08T14:15:02 eeevil: I also don't see any permissions in trunk that don't exist in 2.0, so my patch is going to be replace the code from trunk's 950.data.seed-values.sql with the code from 2.0. 2011-02-08T14:15:30 No one should be using trunk in a production environment where the permission ids would matter. 2011-02-08T14:16:21 @later tell phasefx - if you have a sec after lunch can you peek at http://paste.lisp.org/display/119486#1 -- I'm getting an empty dropdown, but I'm close! 2011-02-08T14:16:21 mrpeters-isl: The operation succeeded. 2011-02-08T14:16:26 Dyrcona: ok ... that's fine. please add a big warning about that in LP 2011-02-08T14:16:58 will do. 2011-02-08T14:17:29 *** bshum has quit IRC 2011-02-08T14:20:57 jeff: I think Marc4j's XML/MARC21 conversions can deal with bad leader data. 2011-02-08T14:21:15 agJohn: thanks! i know there are some very tolerant readers out there. 2011-02-08T14:22:43 * dbs should probably add jeff's mangled record to File_MARC's set o' tests 2011-02-08T14:26:53 jeff: fwiw, File_MARC (PEAR PHP beast) currently just ignores the leader entirely, at least for MARCXML -> MARCXML 2011-02-08T14:32:22 i.e., garbage-in, garbage-out? 2011-02-08T14:32:35 * Dyrcona has a hacked version of Marc4j's MarcStreamReader that ignores the length from the leader. This solves a couple of problems that even MarcPermissiveReader can't get around. 2011-02-08T14:33:17 issue with this record was that the leader ended in " 45004500" when it should have ended in " a 4500" 2011-02-08T14:34:02 my current ils will allow a "short" tag, i.e. only 1 or two characters. that messes up the directory something awful. 2011-02-08T14:34:32 jeff: exactly 2011-02-08T14:34:56 (gigo, for File_MARC currently) 2011-02-08T14:35:39 gigo for databases, currently, and for always. :) 2011-02-08T14:37:21 jeff/dbs: does File_MARC have a permissive mode (i.e. one that tries to correct errors)? 2011-02-08T14:38:00 i think MARC::File *tried* to fix it, because the marcxml -> marc21 conversion changed the tail end of the leader from 45004500 to 45450000 2011-02-08T14:38:04 'course, I don't think any library could fix a leader that's just plain too long. 2011-02-08T14:38:15 oh, i see what it tried to do. 2011-02-08T14:38:27 Dyrcona: File_MARC sets warnings when it runs into something weird 2011-02-08T14:38:37 but tries to soldier on 2011-02-08T14:38:49 Marc4j craps itself. :) 2011-02-08T14:40:26 jeff: leader wasn't long enough, trying to do a str replace of a section that didn't exist? 2011-02-08T14:41:19 in this case, the leader was too long, and it was just trying to ensure that the last four bytes were 4500 2011-02-08T14:42:30 er, "the bytes in positions 20-23 were 4500" 2011-02-08T14:44:00 *** jamesrf has quit IRC 2011-02-08T14:45:10 jeff: ah, I can see that being an issue. So needs a sanity check if strlen > 24... "uh oh" 2011-02-08T14:45:31 lamest of all lamenesses, PG probably won't see full syncronous streaming replication until 9.2 ... boo 2011-02-08T14:45:34 File_MARC's core was derived from MARC::Record, so that sounds like the same problem 2011-02-08T14:46:21 now i shall attempt to repair this 200k+ record marc21 dump... 2011-02-08T14:46:40 dbs: that ejabberd patch, is that diff in the wrong direction, or does it not matter? 2011-02-08T14:46:54 phasefx: oh, it's probably in the wrong direction 2011-02-08T14:47:16 whether it matters or not is if the person who owns the bug cares to be picky about it, doesn't it? 2011-02-08T14:48:03 maybe. I've never tried to use a patch thus, but I can see the intent in yours :) 2011-02-08T14:48:29 mrpeters-isl: looking at your last paste, your 'profile' id is on a menuitem. If you want to appendChild(menuitem), you need to append to a menupopup 2011-02-08T14:49:09 phasefx: patch -R was invented for a reason - a long history of screw-ups like me 2011-02-08T14:49:18 dbwells: hmm ok i will have a look 2011-02-08T14:49:44 dbs++ I learn something new every day 2011-02-08T14:51:27 dbwells: are there changes to the xul too? 2011-02-08T14:51:52 or i'm just appending the rows betlow the that this javascript creates 2011-02-08T14:52:44 mrpeters-isl: the problem I noticed was in the xul. There you have '', and I would think you want that id on the instead. 2011-02-08T14:53:09 ah 2011-02-08T14:53:59 You don't need the in the xul at all 2011-02-08T14:54:04 interesting 2011-02-08T14:54:24 well lookie there! 2011-02-08T14:56:20 uh oh, i broke somethign - now i can't search 2011-02-08T14:56:48 i'm sure it's this else if for id == profile 2011-02-08T14:57:22 } else if (id == 'profile') { query[id] = node.selectedItem.getAttribute('value'); will no longer work? 2011-02-08T14:58:41 mrpeters-isl: I didn't look that far ahead, let me see what this is trying to do 2011-02-08T14:59:05 this may be bad too, because what if we want to not filter by permission profile at all 2011-02-08T14:59:21 we won't have that option i dont think now 2011-02-08T15:00:39 probably helps if i paste a new diff 2011-02-08T15:01:04 *** alxp has quit IRC 2011-02-08T15:01:11 http://paste.lisp.org/display/119486#2 2011-02-08T15:02:10 grr. i thought that patience and vi might get me through fixing the marc record in the middle of this 300M file, but apparently not. 2011-02-08T15:03:38 mrpeters-isl: ultimately, you are probably going to want to 'id' the menulist, then create the menupopup dynamically in addition to the menuitems. menulist is the object which can return the selection information, not the menupopup 2011-02-08T15:04:30 *** jenny has quit IRC 2011-02-08T15:04:51 * mrpeters-isl thinks he'd better go back to the working listbox he has... 2011-02-08T15:06:10 mrpeters-isl: you could also create an empty menuitem for indicating no selection. Just set a label but no value; I think that'd suffice 2011-02-08T15:07:16 in the xul, you could do something like and in the init, just do var menupopup = document.getElementById('profile').firstChild; 2011-02-08T15:07:28 and append your menuitems to menupopup 2011-02-08T15:08:18 sorry, menulist, not menuitem 2011-02-08T15:08:48 so you could even do something like this 2011-02-08T15:09:07 the append's would add menuitems after that empty one 2011-02-08T15:11:15 and remove all of the var menulist... that i have already? 2011-02-08T15:11:52 jeff: heh. I have a pretty horrible, but WORKS, hack for making File_MARC more permissive that might make MARC::Record more permissive too 2011-02-08T15:12:11 long story short: $leader = substr($leader, 0, 24); 2011-02-08T15:12:38 mrpeters-isl: in init? just use var menupopup = document.getElementById('profile').firstChild; // this will get you the first child of your menulist, which is menupopup 2011-02-08T15:13:35 and that replaces var menulist = document.getElementById('profile'); ? 2011-02-08T15:13:51 or this is an addition somewhere? 2011-02-08T15:14:38 dbs: yeah, hacky but works. mangled leader remains mangled, but doesn't push the directory into uselessness. 2011-02-08T15:15:11 It satisfies my 30-odd unit tests, so it can't be that bad :) 2011-02-08T15:16:17 mrpeters-isl: replacement, right. When your xul file gets rendered, it creates an object available to javascript called the DOM (document object model). In javascript, the keyword "document" is refering to that DOM, and you can use javascript to manipulate it dynamically on the fly. So, we're relying on the xul file to do most of the work in a convenient syntax, and then using the javascript 2011-02-08T15:16:23 to tweak things. In this case, you want to dynamically (on the fly) create menuitems, and you want them to be children of that menupopup 2011-02-08T15:16:32 ok, so i did that and failed 2011-02-08T15:16:33 dbs: i was (naively) disappointed in the number of tools that either puked with no decent recovery options, or silently accepted what it should have at least warned about. 2011-02-08T15:16:38 -= THIS MESSAGE NOT LOGGED =- 2011-02-08T15:17:26 mrpeters-isl: so menulist is a variable that no longer exists, because you renamed it to menupopup. You need to rename it in the other place it occurs (probably menulist.appendChild(menuitem)) 2011-02-08T15:17:40 ahha 2011-02-08T15:19:20 freakin awesome 2011-02-08T15:19:34 only thing i notice - maybe this is a bug, maybe it's not a big deal... 2011-02-08T15:19:56 when i pick just a filter, and search - i get a "flash" in green in the "last name box" like it's asking me to put something tehre 2011-02-08T15:20:01 but then search results appear 2011-02-08T15:20:24 thinking maybe tehre is some sort of check that needs modified so the "profile" dropdown is seen as a valid search term? 2011-02-08T15:22:03 also - this still limits to 50 results, but i don't get the dialog that it exceeded 50 like you would for searching "Smith" or some common name 2011-02-08T15:22:52 or maybe that message is no longer in trunk... 2011-02-08T15:24:09 *** tildeequals has joined #evergreen 2011-02-08T15:26:39 *** bshum has joined #evergreen 2011-02-08T15:31:57 phasefx: should this work in 1.6? 2011-02-08T15:32:58 i get this error A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. 2011-02-08T15:32:58 Script: http://mig.evergreen.lib.in.us/opac/common/js/fmgen.js:64 2011-02-08T15:33:04 *** jamesrf has joined #evergreen 2011-02-08T15:33:15 which i'm betting is the fieldmapper taking a really long time to respond with the pgt values? 2011-02-08T15:33:35 mrpeters-isl: I don't know what's going on there. but you should modify search_result.js as well, to make sure it has a line for 'profile' 2011-02-08T15:33:51 right - i made sure to do that 2011-02-08T15:35:42 *** atz has joined #evergreen 2011-02-08T15:35:53 if all of the "pieces" are there for this to work in older versions I'll keep working - if not then i should quit while i'm ahead and be happy it works in trunk :) 2011-02-08T15:37:43 silly question here - if i create a patch with svn diff, is there an "automated" way to apply that to my working /openils directory? 2011-02-08T15:38:06 jeff: just released File_MARC 0.6.2 with fix + unit test for your record, hope you don't mind that I included your record as the test case :) 2011-02-08T15:41:35 heh 2011-02-08T15:42:35 dbs: that seems to have been the single affected record of our relevant bibs. 2011-02-08T15:43:17 dbs: fixed in the full binary dump using sed, now comparing the bre ids i requested with the output 901$c values 2011-02-08T15:43:29 looks like 67 failed to export, likely due to the empty tag issue. 2011-02-08T15:45:54 hrm. only 16/67 match 'datafield tag=\\"\\"' 2011-02-08T15:47:00 mrpeters-isl pasted "rel_1_6_0 patron search profile filter" at http://paste.lisp.org/display/119493 2011-02-08T15:47:16 anyone with a 1.6 willing to try that and see if you get the same "unresponsive script" error 2011-02-08T15:47:32 *** Meliss has quit IRC 2011-02-08T15:47:39 Script: http://DOMAIN/opac/common/js/fmgen.js:64 2011-02-08T15:48:10 it hangs for about 30 seconds then gives that, then if you "continue", same loop 2011-02-08T15:48:29 jeff: 'subfield code=\\"\\"' perhaps? 2011-02-08T15:49:54 also forgot to account for xmlns:marc attributes 2011-02-08T15:50:19 *** atz has left #evergreen 2011-02-08T15:51:22 *** rsoulliere has quit IRC 2011-02-08T15:53:25 *** jamesrf has quit IRC 2011-02-08T15:53:33 *** kmlussier has quit IRC 2011-02-08T15:53:45 hrm. ind1="" vs ind1=" "? 2011-02-08T15:54:03 is the former valid? 2011-02-08T15:54:30 no 2011-02-08T15:55:21 *** jamesrf has joined #evergreen 2011-02-08T15:58:02 okay. down to 11 records where i'm not sure why they didn't export. let the digging commence! 2011-02-08T16:00:59 jeff: you may want to try exporting exactly those and watch the apache error log? 2011-02-08T16:03:37 eeevil: since i lack access to that log, i'm going to try the next best thing... MARC::File on each of the records in my bre export, and see what errors I get. 2011-02-08T16:03:50 though i suppose i could import the bre export into a system here 2011-02-08T16:06:24 *** brendan2 has joined #evergreen 2011-02-08T16:19:15 *** sfortin has quit IRC 2011-02-08T16:23:43 *** jenny has joined #evergreen 2011-02-08T16:30:02 *** yboston has quit IRC 2011-02-08T16:39:09 *** bshum has quit IRC 2011-02-08T17:09:35 *** AaronZ-PLS has quit IRC 2011-02-08T17:14:00 *** mrpeters-isl has quit IRC 2011-02-08T17:25:55 *** Dyrcona has quit IRC 2011-02-08T17:34:46 *** LBA has joined #evergreen 2011-02-08T17:37:00 alright, so I'm trying something like this: git remote add git.esilibrary.com git://git.esilibrary.com/git/evergreen-equinox.git && git checkout -b test git.esilibrary.com/bugs/678078 2011-02-08T17:37:26 and being extra paranoid, I then do git checkout -b test2 && git cherry-pick test 2011-02-08T17:38:01 and I know I can go to master now and do git merge test2 && git dcommit -e to get this in svn 2011-02-08T17:38:23 but at what point to I use the --sign-off argument? 2011-02-08T17:38:51 of course, I'm getting ahead of myself, should actually test the change first :) 2011-02-08T17:39:37 looks like I do --signoff with the cherry pick, maybe 2011-02-08T17:39:47 phasefx: i usually apply the sign-off when I cherry-pick into my svn tracking branches 2011-02-08T17:39:58 berick: roger that, thanks 2011-02-08T17:40:22 so cherry-pick is just taking the last commit from the specified branch if you don't give a more specific commit hash? 2011-02-08T17:40:35 I usually us a commit hash 2011-02-08T17:40:53 i don't think it works without a commit hash 2011-02-08T17:41:02 it seems to 2011-02-08T17:41:23 if I git diff master from test2, I see it 2011-02-08T17:43:45 git-cherry-pick takes any reference to a commit 2011-02-08T17:43:50 yeah, looks like it takes the commit at the tip of the slected branch if you don't specify a hash 2011-02-08T17:43:55 if you feed it a branch name, it interprets it as the tip of the branch 2011-02-08T17:44:06 gotcha 2011-02-08T17:44:26 git's reference syntax has lots of options 2011-02-08T17:44:35 so you could do something like git cherry-pick HEAD^ 2011-02-08T17:44:48 to pick the commit before last in the current branch 2011-02-08T17:44:58 which ... doesn't make sense 2011-02-08T17:45:08 but you can do git cherry-pick random-branch^ 2011-02-08T17:45:47 cool 2011-02-08T17:46:19 *** jenny has left #evergreen 2011-02-08T17:47:01 does it make sense to use -x here, since git.esilibrary.com is public, or no sense, since my private git-svn is not and presumably svn will be throwing that info away? 2011-02-08T17:48:06 *** jamesrf has quit IRC 2011-02-08T17:48:22 phasefx: I wouldn't bother except maybe when backporting 2011-02-08T17:50:33 css is working for me in winders and linux 2011-02-08T17:52:48 w00t. That wasn't too painful 2011-02-08T17:55:19 *** alynn26 has joined #evergreen 2011-02-08T17:56:01 *** jamesrf has joined #evergreen 2011-02-08T18:26:44 *** blongwell has joined #evergreen 2011-02-08T18:42:42 *** blongwell has quit IRC 2011-02-08T19:01:54 *** pmplett_ has joined #evergreen 2011-02-08T19:07:32 phasefx: Do you have to commit that last patch to the rel_2_1 branch too? 2011-02-08T19:10:36 *** brendan2 has quit IRC 2011-02-08T19:11:27 *** brendan2 has joined #evergreen 2011-02-08T19:12:55 *** jamesrf has quit IRC 2011-02-08T19:18:35 *** pmplett_ has quit IRC 2011-02-08T19:20:37 *** pmplett_ has joined #evergreen 2011-02-08T19:22:32 signed-off-by thing is neat, might be even more valuable to discern between "written by" vs. "tested / thumbs-up by" 2011-02-08T19:24:14 *** pmplett__ has joined #evergreen 2011-02-08T19:25:25 maybe that doesn't work for merging entire branches; i dunno 2011-02-08T19:28:32 I believe git (at least) can keep track of everyone who contributed to a changeset, with name and email. Thus you can get the person who wrote it and the one who commits it signs off on it. I think. Haven't played with that much. 2011-02-08T19:31:27 I suppose if it goes through a reviewer's repo it could get the reviewer too 2011-02-08T19:31:57 *** pmplett__ has left #evergreen 2011-02-08T19:32:32 guessing is fun 2011-02-08T19:42:02 *** pmplett_ has quit IRC 2011-02-08T20:18:25 *** tildeequals has quit IRC 2011-02-08T20:35:50 tsbere: yeah, I think I'll even backport to rel_2_0 2011-02-08T20:53:28 dbs you can sign off a merge 2011-02-08T20:53:51 for koha, every patch has to have at least 1 signoff before it hits the RM 2011-02-08T20:54:48 and yes tsbere author is different to committer, git tracks both, and it tracks all the sign offs too 2011-02-08T20:55:24 *** bshum has joined #evergreen 2011-02-08T20:57:23 tsbere: eg http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=8ce06ddf3220bf4b16efe6d796ec80251f3390fb 2011-02-08T20:57:50 *** pmplett_ has joined #evergreen 2011-02-08T21:11:39 *** atz has joined #evergreen 2011-02-08T21:13:28 *** atz has left #evergreen 2011-02-08T21:25:57 *** jtbates has joined #evergreen 2011-02-08T21:27:34 *** bshum has quit IRC 2011-02-08T21:29:22 *** bshum has joined #evergreen 2011-02-08T21:30:39 *** bshum has joined #evergreen 2011-02-08T21:35:01 agJohn: Are you around? Sorry, I had to run yesterday. 2011-02-08T21:45:05 *** bshum has quit IRC 2011-02-08T21:49:42 *** pmplett_ has quit IRC 2011-02-08T21:51:27 *** bshum has joined #evergreen 2011-02-08T21:53:06 rangi: thanks! 2011-02-08T21:53:14 np 2011-02-08T22:00:00 * phasefx is making another git-svn clone of Evergreen, but this time not just trunk. taking forever :) 2011-02-08T22:00:22 svn will do that ;) 2011-02-08T22:00:25 in the past this would break whenever I attempted it 2011-02-08T22:12:12 *** pmplett__ has joined #evergreen 2011-02-08T22:22:06 *** pmplett__ has quit IRC 2011-02-08T23:02:22 *** LBA has left #evergreen 2011-02-08T23:21:56 *** denials has quit IRC 2011-02-08T23:21:56 *** csharp has quit IRC 2011-02-08T23:21:57 *** _dkyle_ has quit IRC 2011-02-08T23:21:57 *** phasefx has quit IRC 2011-02-08T23:21:58 *** gdunbar has quit IRC 2011-02-08T23:21:59 *** jennam has quit IRC 2011-02-08T23:22:01 *** jtbates has quit IRC 2011-02-08T23:22:02 *** r123 has quit IRC 2011-02-08T23:22:02 *** rsinger has quit IRC 2011-02-08T23:22:02 *** Dmagick has quit IRC 2011-02-08T23:22:02 *** finnapz has quit IRC 2011-02-08T23:22:02 *** gmcharlt has quit IRC 2011-02-08T23:22:03 *** brendan2 has quit IRC 2011-02-08T23:22:03 *** sylvar has quit IRC 2011-02-08T23:22:05 *** bradl has quit IRC 2011-02-08T23:22:05 *** berick has quit IRC 2011-02-08T23:27:19 *** jtbates has joined #evergreen 2011-02-08T23:27:20 *** brendan2 has joined #evergreen 2011-02-08T23:27:20 *** r123 has joined #evergreen 2011-02-08T23:27:20 *** jennam has joined #evergreen 2011-02-08T23:27:20 *** sylvar has joined #evergreen 2011-02-08T23:27:20 *** rsinger has joined #evergreen 2011-02-08T23:27:20 *** phasefx has joined #evergreen 2011-02-08T23:27:20 *** Dmagick has joined #evergreen 2011-02-08T23:27:20 *** gdunbar has joined #evergreen 2011-02-08T23:27:20 *** finnapz has joined #evergreen 2011-02-08T23:27:20 *** _dkyle_ has joined #evergreen 2011-02-08T23:27:20 *** gmcharlt has joined #evergreen 2011-02-08T23:27:20 *** bradl has joined #evergreen 2011-02-08T23:27:20 *** berick has joined #evergreen 2011-02-08T23:27:20 *** csharp has joined #evergreen 2011-02-08T23:27:20 *** denials has joined #evergreen 2011-02-08T23:28:26 *** jennam has quit IRC 2011-02-08T23:29:32 *** bshum has quit IRC 2011-02-08T23:29:36 *** jennam has joined #evergreen 2011-02-08T23:55:42 *** tildeequals has joined #evergreen