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