lists.koha.org as slef recomends?← Previous day | Today | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 13:46 | hdl | hi america |
| 13:46 | nengard are you around ? | |
| 13:48 | nengard | hdl i am now |
| 13:49 | hdl i can't do private messages :( i'm trying to figure that out - i've lost my password - will open skype | |
| 14:04 | hdl | kados : |
| 14:04 | Should I send a message on the lists to announce the new lists ? | |
| 14:05 | kados_ : | |
| 14:12 | hi gmcharlt | |
| 14:12 | gmcharlt | hi hdl |
| 14:21 | slef | hi all... how's things? |
| 14:23 | owen | Hi slef and everyone |
| 14:27 | hdl | hi slef |
| 14:29 | slef | do we have a handy guide to zebra care anywhere? Like, how to see if the serials are being indexed... |
| 14:36 | gmcharlt | hi slef |
| 15:15 | kados_ | hdl: yes, I think we're ready to switch the lists, they seem to be working just fine |
| 15:15 | kados | slef: you're asking if Koha indexes serials? |
| 15:16 | slef: that's a very broad question ... what part of the serial record specifically? to find the answer you'd want to check the record.abs file | |
| 15:16 | slef | if zebra does... I've a catalogue with serials entered but they don't show up in the catalogue search |
| 15:16 | and they don't show up from yaz-client | |
| 15:16 | kados | slef: zebra just follows what Koha's record.abs tells it to index |
| 15:16 | slef | I'm using whatever's in 3 beta IIRC |
| 15:16 | kados | and we need to know aht field specifically |
| 15:17 | what field I mean | |
| 15:17 | s/field/fields/ | |
| 15:17 | hdl | slef, kados : serials are now stored only in tables, as far as i know. |
| 15:17 | slef | well, searched for 942$c being SER, which seems to be how to spot a serial |
| 15:17 | hdl | So zebra has no knowledge of it. |
| 15:18 | slef | hdl: so how are old stocks acquired into the collection? |
| 15:18 | hdl: as we can't simply Add Item them | |
| 15:18 | kados | hdl: it has knowledge of the bib record for a serial |
| 15:18 | hdl | Am I misunderstandng ? |
| 15:18 | kados | just not the planning data |
| 15:19 | slef | kados: this zebra doesn't seem to have knowledge of the bib record for some reason... can I TCP to liblime's demo's zebra? |
| 15:19 | hdl | is serialseq stored in marcrecord ? |
| 15:19 | kados | slef: yup ... running on port 9998/biblios |
| 15:19 | slef: use SRU if you like: opac.liblime.com:9998/biblios | |
| 15:20 | slef: have you indexed the bib records? | |
| 15:20 | slef | rebuild_zebra.pl is cronned |
| 15:20 | because zebradaemon_queue.pl fails noisily | |
| 15:20 | is there more that must be done? Other bibs show in search results | |
| 15:22 | Search was a success. | |
| 15:22 | Number of hits: 100, setno 2 | |
| 15:22 | kados | no, sounds lie your'e doing it |
| 15:22 | slef | so opac.liblime.com is happily indexing SERs |
| 15:22 | (query was f @attr 1=/record/datafield[@tag="942"]/subfield[@code="c"] SER if anyone wants it) | |
| 15:24 | kados: does opac.ll.c run with record.abs as shipped in 3beta? | |
| 15:24 | kados | slef: yup |
| 15:24 | hdl: can you start by moving koha-infos? | |
| 15:24 | slef | but zebraqueue_daemon.pl? |
| 15:24 | kados | hdl: and perhaps change the name to Koha-French ? |
| 15:24 | slef | I'm currently wondering whether rebuild_zebra.pl transfers SERs properly. |
| 15:25 | kados | slef: yea, it should be fine |
| 15:25 | slef | kados: French isn't french for french. |
| 15:25 | kados | slef: yea, I'm following debian conventions |
| 15:25 | http://www.debian.org/MailingLists/subscribe | |
| 15:25 | slef | kados: debian sucks at mailing lists, news at 11 |
| 15:25 | kados | hehe |
| 15:26 | slef: so what, we use RFC4646 codes? | |
| 15:26 | koha-fr-FR ? | |
| 15:26 | slef | ISO-3106 or whatever it is... koha-fr? |
| 15:26 | kados | last time I checked, only latin characters were allowed in email |
| 15:26 | slef | Isn't the spanish already koha-es? |
| 15:27 | kados | slef: what do we do when a canadian group wants to create a french list? |
| 15:28 | hdl | kados ???? |
| 15:28 | slef | kados: tell 'em to stop being so silly and use the french one ;-) |
| 15:28 | kados: or have koha-fr-... lists | |
| 15:28 | hdl | start by moving koha-infos ? |
| 15:29 | slef | or koha-...-fr if you want to mimic debianisms |
| 15:29 | hdl | infos on koha-fr.org is not a problem for you. |
| 15:30 | I thought of all the savannah lists move. | |
| 15:31 | kados | hdl: my understanding was the goal was to move all koha lists to lists.koha.org, right? |
| 15:31 | hdl: can't we start with koha-infos to test the migration? It should be easiest since you and paul manage that one | |
| 15:31 | hdl: and perhaps re-name it koha-frlists.koha.org as slef recomends? |
|
| 15:32 | since it's a french koha user list? | |
| 15:32 | then we can move koha-*@nongnu.org soon thereafter | |
| 15:32 | hdl: does that make sense? | |
| 15:33 | hdl | kados: my understanding was different. |
| 15:33 | first problem was savannah. | |
| 15:33 | and not koha-fr. | |
| 15:34 | kados | *shrug* ... it doesn't matter much to me |
| 15:34 | hdl | not to me either. |
| 15:35 | But I am much prepared to change savannah's list than french lists who are already on the same server | |
| 15:36 | kados | OK |
| 15:36 | go for it | |
| 15:36 | hdl: if you want me to proofread your announcement let me know | |
| 15:36 | hdl: (for English readers) | |
| 15:36 | hdl | OK. |
| 15:36 | kados | mornin fbcit |
| 15:37 | fbcit | man, the gang's all here :) |
| 15:37 | kados | heh |
| 15:37 | fbcit | hi kados, koha |
| 15:47 | gmcharlt | hi fbcit |
| 15:58 | hdl | kados: message sent. |
| 16:18 | kados | hdl: response sent |
| 16:18 | hdl++ | |
| 16:21 | hdl: so you can also redirect all mail from koha-*@nongnu.org to koha-*@lists.koha.org ? | |
| 16:41 | hdl | i think so. |
| 17:04 | kados | hdl: how can we find out for sure? |
| 17:05 | cool | |
| 17:14 | hdl | not sure to be able to do that clean. |
| 17:15 | kados | bummer |
| 17:15 | hdl: http://www.webmasterworld.com/forum92/3366.htm | |
| 17:16 | maybe we don't have access to mailman.conf? | |
| 17:16 | but maybe savannah guys will help us out? | |
| 17:20 | hdl | It is for redirecting lists/mailman/listinfo into mailman.lists.org |
| 17:22 | kados | hdl: can't you use the .forward file? |
| 17:22 | hdl | on savannah ? |
| 17:23 | we donot have ssh access | |
| 17:23 | kados | maybe the savannah guys will help? |
| 17:23 | we also need to update koha.org to show the new list info | |
| 17:24 | and nabble.com, etc. | |
| 17:41 | slef | savannah-hackers should help I think |
| 17:41 | also, can you keep the list-id when the lists move, or is mailman still dumb like that? | |
| 17:42 | kados | hdl: I'm guessing that's another qeustion for savannah-hackers |
| 17:43 | I've found #savannah on freenode to be helpful at times too | |
| 17:54 | atz | how is koha/zebra handling boolean searches? |
| 17:56 | my impression is that it isn't currently structuring, say: money AND love | |
| 17:56 | into a boolean conjunction | |
| 18:00 | kados | atz: q=money&op=and&q=love |
| 18:01 | atz | but there is no OPAC construction for that? perhaps only adv. search? |
| 18:01 | kados | adv search should do it |
| 18:01 | money+love should work too | |
| 18:02 | atz: http://opac.liblime.com/cgi-bi[…]pl?q=money%2Blove | |
| 18:02 | atz: http://opac.liblime.com/cgi-bi[…]?q=money+and+love | |
| 18:02 | atz: http://opac.liblime.com/cgi-bi[…]ney&op=and&q=love | |
| 18:02 | atz | adv. search builds a more complex query, but equiv: opac-search.pl?idx=kw&q=murder&idx=kw&q=love&idx=kw&sort_by=relevance&do=OK |
| 18:02 | kados | atz: comparing those results should answer it |
| 18:04 | atz | thx |
| 18:04 | kados | it's a very reasonable question |
| 18:05 | atz | i notice that the 3rd link doesn't reproduce the "display" version of the query |
| 18:05 | (the slot up top is blank) | |
| 18:08 | and the op symbol for "OR" is pipe? | |
| 18:12 | kados | atz: it's OR or alternatively pipe |
| 18:12 | op=or | |
| 18:12 | shoudl work | |
| 18:12 | really, the user-facing query language needs some peer review | |
| 18:12 | I spent a lot of time worrying about it :=) | |
| 18:13 | atz | the results are pretty good from zebra even if not functionally boolean |
| 18:14 | the query structure there doesn't really jive, either | |
| 18:14 | kados | actually, zebra queries are perfect CCL or CQL |
| 18:14 | atz | idx=kw can't reliably be "paired" to the q terms |
| 18:15 | kados | I didn't have time to write a real query parser |
| 18:15 | a bit beyond my puny skills at the moment | |
| 18:15 | atz | sorry, I mean the HTTP request form of the query |
| 18:15 | kados | though I did my best to read the Dragon book and understand recursion and compilers in general :-) |
| 18:15 | atz | it relies on parameter order, which is not guaranteed by spec. |
| 18:16 | kados | ahh, when i researched it, I think CGI does enforce the parameter order |
| 18:16 | atz | the browser does not! |
| 18:16 | (though most are somewhat reasonable) | |
| 18:18 | opac-search.pl?idx=kw&idx=kw&idx=kw&q=murder&q=love&sort_by=relevance&do=OK | |
| 18:18 | kados | ahh, I see |
| 18:18 | atz | ^^ legitimate browser formulation of above query |
| 18:18 | kados | yea, that doesn't matter |
| 18:18 | koha matches up the queries | |
| 18:18 | first idx is matched to the first q, etc. | |
| 18:19 | doesn't matter what order you send them in | |
| 18:19 | make sense? | |
| 18:19 | obviously the operators are offset by one | |
| 18:20 | atz | no... they are params w/ the same name, so Koha gets them as an array |
| 18:20 | the order of elements in that array is determined by the browser's implmentation, not Koha | |
| 18:20 | kados | I don't know how to explain it in English |
| 18:20 | go check the code | |
| 18:20 | it works | |
| 18:20 | atz | it works b/c of non-spec browser-dependent behavior |
| 18:20 | kados | nope |
| 18:21 | :) | |
| 18:21 | it works because it keeps track of each array and matches up each query phrase | |
| 18:21 | regardless of the order | |
| 18:22 | atz | all that the server gets is the browser request |
| 18:22 | kados | atz: give me an example of a query CGI that doesn't work |
| 18:23 | atz | FF 2 does a GET for this URL, based on adv. search form: |
| 18:23 | http://opac.liblime.com/cgi-bi[…]y=relevance&do=OK | |
| 18:24 | kados | yep, and that will work just fine |
| 18:24 | atz | now, in a min. I'll produce a VALID HTTP request based on the same form that will break |
| 18:24 | kados | go for it |
| 18:28 | atz: http://opac.liblime.com/cgi-bi[…]y=relevance&do=OK | |
| 18:28 | atz: is what I think you were hoping would trip it up ;-) | |
| 18:28 | atz | interesting... not the same results though |
| 18:28 | kados | identical for me |
| 18:29 | atz | http://opac.liblime.com/cgi-bi[…]ance&do=OK&q=love |
| 18:30 | kados | there you're asking for an author,word list like 'love' |
| 18:30 | ie, you've re-ordered the idx array, which woudln't ever happen | |
| 18:30 | atz | again, my point is that the spec doesn't guarantee the order of params from froms |
| 18:31 | kados | yea, and it does actually |
| 18:31 | specifically if they are named the same, they come back as an ordered array | |
| 18:31 | atz | i'll check |
| 18:33 | indradg | kados, around? |
| 18:34 | kados | atz: http://search.cpan.org/dist/CG[…]R_LIST_AS_A_HASH: |
| 18:34 | atz: is what we use to fetch the list | |
| 18:34 | hey indradg ! | |
| 18:34 | indradg: it's been a while! | |
| 18:35 | indradg | kados, thats for sure! |
| 18:35 | kados, did some people from an organisation called Akshara, from India try to get in touch with you? | |
| 18:36 | kados | it's possible, we are swamped with US work at the moment |
| 19:08 | atz | kados: you are right |
| 19:18 | kados | not_having_to_rewrite_koha's_searching++ |
| 19:37 | atz | reference: http://www.w3.org/TR/html401/interact/forms#h-17.13.3.3 |
| 19:38 | "The control names/values are listed in the order they appear in the document." | |
| 20:01 | hdl | kados : /me asking savannah guys. |
| 20:07 | atz : do you know who subscribed kohalists on nabble.com ? | |
| 20:08 | atz | hdl: no |
| 20:18 | hdl | atz : thanks. |
← Previous day | Today | Search | Index
