← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:04 | thd | kados: are you still there? |
| 12:17 | kados | back |
| 12:17 | I still don't understand how we construct the hierarchy in the first place | |
| 12:17 | ie, how to build the relationships | |
| 12:20 | thd | kados: you could have some meta-record which starts in some design I have not conceptualised properly and fill successive children into a meta-record starting with the records with records that have no parents |
| 12:21 | kados: the immediate children and immediate parents as well as related siblings are shown in each in individual record | |
| 12:22 | kados | so we're talking about a completely new record format? |
| 12:22 | thd | kados: or you could keep adding grand parents and grandchildren to special fields for indexing larger parts of the relation hierarchy |
| 12:23 | kados: a meta-record format containing the standard records inside | |
| 12:24 | kados | I think you're going to end up with a very problematic structure |
| 12:24 | impossible to maintain | |
| 12:24 | thd | kados: This has value for the way that Zebra 2 can index records |
| 12:24 | kados | and which denies all of the principles of relational databases have taught us |
| 12:25 | thd | kados: it is maintained by batch scripts but authorities change very slowly so that is not much of a problem |
| 12:26 | kados | the goal IMO is normalization, which seems to be the exact opposite of what your're proposing :-) |
| 12:27 | thd | kados: this is how all databases storing complex relations worked in the 1960s and into the 70s before the relational model became dominant |
| 12:27 | kados: what would you mean by normalisation in this context? | |
| 12:32 | kados: if the authority records are from the same thesaurus they should already be significantly normalised | |
| 12:34 | kados: when combining multiple thesauri so one can search consistently across more than one or for other non-explicit relationships then some normalisation for indexing authorities is needed | |
| 12:35 | kados: how would normalisation help in this context | |
| 12:35 | ? | |
| 12:35 | kados: within a single authority thesaurus? | |
| 12:37 | kados: did you loose your connection again? | |
| 12:38 | kados | I don't think so |
| 12:39 | thd | kados: what don't you think? |
| 12:39 | kados | don't think I lost my connection :-) |
| 12:40 | thd | kados: how would normalisation help in this context for a single authorities thesaurus? |
| 12:40 | kados | perhaps lack of sleep is the problem :-) |
| 12:40 | thd | kados: how do we index authorities such that |
| 12:41 | we can find any grandparents from any children and any grandchildren from any parent? | |
| 12:42 | kados: are you awake enough to appreciate that abstraction? | |
| 12:42 | kados | es |
| 12:42 | yes even | |
| 12:43 | zebra can't do it efficieintly | |
| 12:43 | we need a relational database IMO | |
| 12:43 | for that specific case | |
| 12:44 | a 'nested set' would be the most efficient storage method | |
| 12:44 | thd | kados:that costs money and is not efficient for searching large numbers of fields from different tables |
| 12:45 | kados | what costs money? |
| 12:45 | if all you need to find out is the relationships between records, an index engine is not the best tool for the job | |
| 12:45 | thd | kados: hiring ID to add some very significant additional feature to Zebra |
| 12:46 | kados | an SQL interface to Zebra would IMO defeat the purpose of Zebra |
| 12:46 | Zebra is an indexing engine | |
| 12:46 | thd | kados: exactly |
| 12:46 | kados | what you want to do is best done using nested sets in SQL |
| 12:49 | thd | kados: however, in SQL you would not have the ability to search on all bibliographic fields as well as the nested set without the same inefficiencies that had prompted adopting Zebra in the first place |
| 12:50 | kados: how do you merge the nested set index with the Zebra index so that you can search both very quickly at the same time? | |
| 12:50 | kados | searching on bibliographic fields wouldn't ever be combined with a nested set search, would it? |
| 12:50 | thd | kados: yes |
| 12:50 | kados | under what circumstance? |
| 12:51 | thd | kados: it would be a limiting factor of a bibliographic search |
| 12:52 | kados | hmmm |
| 12:52 | then the only way to do it efficiently in zebra is to have the relationships explicitly defined in each record beforehand | |
| 12:54 | meaning that the textual data would have to represent the full hierarchy | |
| 12:54 | North American -- Ohio -- Athens | |
| 12:54 | Europe -- Greece -- Athens | |
| 12:54 | etc. | |
| 12:54 | thd | kados: what you are thinking of would merely find a set of authority records for running many bibliographic searches. The many searches would be very inefficient if they were really all place names in North America and really Excluded all place names in Europe |
| 12:54 | kados: yes | |
| 12:54 | kados | then you could construct a query such that +North America and -Europe |
| 12:55 | but so far as I know, there is not currently a subject thesaurus or headings standard that does this in a machine readable way | |
| 12:55 | in libraries anyway :-) | |
| 12:55 | thd | kados: and I mean where the bibliographic record only contains Athens, OH or only contains Athens (understood to be Greece) |
| 12:56 | kados: there is | |
| 12:56 | kados: there is more than one | |
| 12:57 | kados: the Getty foundation even has such a thesaurus | |
| 02:19 | btoumi | hi all |
| 08:19 | kados | morning owen |
| 08:19 | owen | Hi kados |
| 08:19 | kados | owen: can you get to koha.org? |
| 08:19 | owen | Yes, quite quickly too |
| 08:19 | kados | and had the same problem at the OU campus at the CS class |
| 08:21 | owen | kados: have you tested the Book Bag in the dev-week opac? |
| 08:21 | kados | i don't think it works, right? |
| 08:22 | so it can't count | |
| 08:22 | and the records don't display | |
| 08:23 | IIRc that was all just javascript, right? | |
| 08:23 | owen | I've been baning my head on it for a week now and I can't figure out what's gone wrong |
| 08:23 | kados | did any of the names of the elements change on the page? |
| 08:23 | owen | Not as far as I can tell |
| 08:27 | kados | it looks to me like the items are being added |
| 08:27 | the popup has the right count | |
| 08:27 | but the status count is wrong | |
| 08:28 | owen | but the popup doesn't recognize when you're adding something that you alread added |
| 08:28 | kados | true |
| 08:28 | owen | the added items aren't being retained in memory...meaning I guess the cookie isn't getting written |
| 08:28 | paul | kados : 'morning. www.koha.org works from here, although slowly, as often |
| 08:28 | kados | morning paul |
| 08:36 | owen | The basket.js script hasn't changed at all, so I guess it has to be something on the results page... |
| 08:36 | kados | owen: also, I had it set up to auto-submit when you selected a sort option |
| 08:36 | but that seems to have died | |
| 08:36 | Error: document.mainform has no properties | |
| 08:36 | Source File: http://zoomopac.liblime.com/se[…]son&do=Search&r=1 | |
| 08:36 | Line: 1 | |
| 08:37 | brb | |
| 08:37 | owen | That at least I can fix :| |
| 08:39 | kados | I also get a js error on page load: |
| 08:39 | Error: Expected ':' but found '}'. Declaration dropped. | |
| 08:39 | Source File: http://zoomopac.liblime.com/op[…]s/opac-layout.css | |
| 08:39 | Line: 970 | |
| 08:40 | our cappuccino machine arrived today, but we don't have expresso beans :-) | |
| 08:41 | owen | kados' productivity is about to go up 300%! |
| 08:41 | (not counting bathroom breaks) | |
| 08:41 | kados | hehe |
| 08:49 | owen | When I save the results page locally the javascript works fine >:( |
| 08:51 | kados | weird |
| 08:53 | why would it work locally? | |
| 08:55 | owen | kados: do you know why opac-detail isn't working? |
| 08:55 | kados | probably because the import isn't done yet |
| 08:56 | yea, looks like it's only half-way there | |
| 08:57 | I should change the cron job to start it Saturday evening | |
| 08:57 | instead of Sun morning | |
| 09:51 | yea, what a pain | |
| 09:52 | owen | I'm really stumped. I don't know where to look next. |
| 09:54 | kados | owen: well the basket.pl might not work due to the update |
| 09:55 | but that still doesn't account for the count being wrong | |
| 09:55 | owen | yeah, the reason the basket.pl page doesn't load anything is that the right bib ids aren't being passed to it by the javascript |
| 09:56 | kados | hmmm |
| 09:56 | I wonder if this has something to do with the bibid vs biblionumber confusion | |
| 09:56 | each record seems to have a bibid number assigned | |
| 10:31 | paul | huray for kados ;) |
| 10:34 | kados | it's european machine too, so it tastes like in France or Italy :-) |
| 10:36 | (well, more like italy actually ... ) | |
| 10:39 | hi tumer | |
| 10:39 | dewey | hi tumer is still strugling |
| 10:40 | tumer | hi kados long time! |
| 10:40 | kados | yea, we've both been busy I guess :-) |
| 10:40 | tumer | i am having proýblems committing new stuff. I am not good at it and it gives me lots of errors |
| 10:40 | kados | how's the Alvis filter stuff coming along? |
| 10:41 | tumer | I have it running at NEU |
| 10:41 | kados | yea, I noticed that you committed to rel_2_2 a couple of times |
| 10:41 | we had to roll those changes back IIRC | |
| 10:41 | tumer: did you ever switch to linux? | |
| 10:42 | tumer | today I tried commiting lots of stuff all rejected |
| 10:42 | no linux never managed to get it running | |
| 10:42 | kados | what's the error? |
| 10:42 | tumer | it says that the stuff is newer on head while they are not |
| 10:43 | kados | someties it says that if the files really belong to another branch |
| 10:44 | tumer | i have all the branches |
| 10:44 | but sometiing must have gone wrong somewhere | |
| 10:44 | kados | all of them? |
| 10:44 | what I do is have a single directory called cvsrepos | |
| 10:44 | in cvsrepos I have: | |
| 10:44 | rel_2_2 | |
| 10:45 | dev_week | |
| 10:45 | dewey | well, dev_week is rel_2_2 with zebra ... ie, same API as rel_2_2 |
| 10:45 | kados | rel_3_0 |
| 10:45 | head | |
| 10:45 | tumer | yea thats what i have |
| 10:45 | kados | each of them has a 'koha' directory that is the specific branch |
| 10:45 | tumer | i think i will tar and send them to chris to commit them |
| 10:45 | kados | and I 'symlink' a given installation of Koha to that koha directory |
| 10:45 | for simplicy of testing changes, etc. | |
| 10:46 | tumer | i do not know any symlinking |
| 10:46 | kados | I think you can do it in windows too |
| 10:46 | tumer | not with windows anyway |
| 10:46 | kados | it makes things much easier |
| 10:46 | because the CVS version is identical to the running copy | |
| 10:46 | so for example, zoomopac is running off a CVS repository | |
| 10:47 | tumer | what i am trying to do is |
| 10:47 | i have a working copy | |
| 10:47 | kados | here is a debian guide for symlinking: http://www.kohadocs.org/Updating_Koha.html |
| 10:47 | tumer | i want to commit that and do any changes necessary on that |
| 10:47 | hdl | hi tumer.... |
| 10:47 | dewey | hi tumer is still strugling |
| 10:47 | kados | in windows symlinks may be called 'shortcuts' |
| 10:48 | tumer | hi hdl |
| 10:48 | well i will be very busy this week and i want to finish this by the end of this mont | |
| 10:49 | currently the only module thats not working is Acquisitions | |
| 10:49 | the rest is all working in XML API | |
| 10:50 | Acquisitions is a bit of a mess it seems, is there any version that works bug-free? | |
| 10:50 | kados | rel_2_2 is nearly bug free |
| 10:50 | tumer | and not dev_weeek? |
| 10:51 | paul | & rel_3_0 is synch with 2_2 |
| 10:51 | kados | AFAIK the only version of Koha that had a bug free acquisitions was 1.2 :-) |
| 10:51 | paul | so, head should not be too far |
| 10:51 | kados | dev_week is in sync with rel_2_2 |
| 10:51 | tumer | well rel_3 is not working |
| 10:51 | kados | though it misses a few changes in the past two weeks |
| 10:52 | paul: have you tested rel_3_0 acquisitions? | |
| 10:52 | paul | nope |
| 10:52 | (but toins should have) | |
| 10:52 | tumer | yes paul i have took it as base |
| 10:52 | i tried keeping head in sync with rel_3 | |
| 10:52 | kados | tumer: what bugs are you experiencing? |
| 10:53 | tumer | you create a suggestion, accept it but cannot go further than that. Budgeting not always work etc. |
| 10:54 | Also DB structures seems a little bit confusing | |
| 10:54 | dev_week has a few fields that rel_3 does not have but than asks for those fields | |
| 10:55 | we never actually used acquisitions so its taking time to master | |
| 10:56 | kados | well, AFAIK, rel_2_2 is the first time it actually works in the 2.x series |
| 10:56 | those bugs sound familiar | |
| 10:56 | perhaps your rel_3 is not quite up to date with the changes in rel_2_2 | |
| 10:56 | tumer | so i will take rel_2_2 as base and start over |
| 10:56 | kados | hdl and paul fixed some bugs in the last month or so |
| 10:57 | hmmm, probably not a good idea tumer | |
| 10:57 | because IIRC, toins has done some code cleaning as well | |
| 10:57 | paul: right? | |
| 10:57 | we don't want to overwrite his cleaning efforts | |
| 10:57 | hdl | yes. |
| 10:58 | tumer | i am keeing all his cleaning |
| 10:59 | kados | tumer: have you seen perltidy? |
| 10:59 | http://perltidy.sourceforge.net/ | |
| 10:59 | tumer | nope |
| 10:59 | kados | it can help tidy up code |
| 10:59 | format it in a readable way, etc. | |
| 11:00 | tumer | i'll check |
| 11:09 | owen | tumer, are you having trouble committing files using TortoiseCVS? |
| 11:09 | tumer | yes owen |
| 11:10 | owen | What version are you using? Are you getting an error message about "cvs: Obsolete --lf option used. Please update your client." ? |
| 11:10 | tumer | lemme check |
| 11:11 | owen: version 2.4.6 | |
| 11:13 | owen | Is that the CVSNT versioN? TortoiseCVS is only up to 1.8.27 (stable) |
| 11:13 | tumer | the errors are different. It says up-to-date check failed and terminates |
| 11:13 | owen | http://sourceforge.net/mailarc[…]p?msg_id=17118682 |
| 11:14 | Hmm... I haven't seen that before. | |
| 11:14 | kados | tumer: in each directory there is a CVS directory |
| 11:14 | tumer | sorry version 1.8.25 |
| 11:14 | kados | tumer: look in the Entries file |
| 11:14 | it will tell you the version string of each CVS file in that directory | |
| 11:14 | perhaps that can help you locate the problem | |
| 11:15 | tumer | i will go into it |
| 11:20 | kados | as an example: |
| 11:20 | /opac-authorities-home.pl/1.1.2.6/Mon Apr 10 20:08:43 2006//Trel_2_2 | |
| 11:21 | this entry says it's version 1.1.2.6 the date it was committed, and the branch it is assigned to | |
| 11:21 | here is an example from 'head': | |
| 11:21 | /loadmodules.pl/1.20/Thu Feb 9 03:20:38 2006// | |
| 11:21 | there is no branch assignment | |
| 11:21 | but still version and date | |
| 11:22 | tumer: does that make sense? | |
| 11:22 | tumer | i am following |
| 11:23 | kados | when you check out a fresh copy of a repository the Entries files ar all correct for that branch |
| 11:23 | but if you swap directories between two or more branches, the Entries files will get messed up | |
| 11:23 | tumer | i am now trying to get a fresh copy of head and start over |
| 11:30 | Burgwork | morning kados |
| 11:31 | kados | morning Burgwork |
| 11:31 | how's things? | |
| 11:33 | Burgwork | not bad |
| 11:33 | banging away on the weekend on that stuff for you | |
| 11:33 | kados | sweet |
| 11:33 | Burgwork | just need to proof it at lunch and it is good to go |
| 11:44 | thd | kados: Is there a devel meeting today? |
| 11:45 | kados | thd: it's on Wednesday |
| 11:46 | thd | kados: you wrote Monday, I think in your most recent koha-devel list message |
| 11:46 | kados | woops |
| 11:46 | I will correct that after Lunch | |
| 11:49 | brb |
← Previous day | Today | Next day → | Search | Index