| Time |
Nick |
Message |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:15 |
|
JBoyer joined #evergreen |
| 07:14 |
|
rjackson_isl_hom joined #evergreen |
| 07:40 |
|
collum joined #evergreen |
| 08:26 |
|
rfrasur joined #evergreen |
| 08:30 |
|
mmorgan joined #evergreen |
| 08:34 |
|
mantis joined #evergreen |
| 08:46 |
|
Dyrcona joined #evergreen |
| 09:22 |
|
jvwoolf joined #evergreen |
| 09:41 |
Dyrcona |
Y'know, sometimes it's faster to reinvent the wheel than to find the existing wheel. |
| 10:01 |
rhamby |
and sometimes you end up making a better wheel ... sometimes :) |
| 10:06 |
|
Keith-isl joined #evergreen |
| 10:09 |
mmorgan |
Then you wonder how you ended up with so many old wheels lying around ;-) |
| 10:22 |
|
berick joined #evergreen |
| 10:23 |
Dyrcona |
mmorgan: Not if you can't find them. :) |
| 10:24 |
Dyrcona |
I was trying to find an Emacs command or function to make a file: URL from a path. Doesn't look like such a thing exists, but after 15 minutes of search the function help and online, I decided, "I could have implemented it by now." |
| 10:29 |
Dyrcona |
I still haven't implemented it, but it might be a handy thing to have. |
| 10:35 |
Dyrcona |
Of course, there's a Jabber/XMPP library for Emacs..... :) |
| 10:44 |
Dyrcona |
MARC::Charset apparently does not like EM DASH: \xE2\x80\x94. |
| 10:50 |
Dyrcona |
The message suggests that triplets beginning with \xE2\x80 are the problem: no mapping found for [0x80] at position 24 |
| 10:50 |
Dyrcona |
gmcharlt ^^ Should I file a bug on MARC::Charset? |
| 10:55 |
Dyrcona |
FWIW: I'm using this program to load some binary MARC records: https://pastebin.com/g4RGDJLr |
| 11:01 |
miker |
Dyrcona: doesn't like going from MARC8 to UTF-8? |
| 11:06 |
Dyrcona |
The file is UTF-8. |
| 11:08 |
miker |
hrm... that's strange ... could the records be claiming MARC8? IIRC we do look at the leader, but I think there's a way to force the issue |
| 11:09 |
Dyrcona |
Ah, wait a minute. The records don't seem to say that they're UTF-8.... |
| 11:09 |
Dyrcona |
vendor-records-- |
| 11:10 |
Dyrcona |
I'll have to test this... again.... I have a prep script that can set the encoding, I saw 'a' in the leader and thought I didn't have to, but after counting, that 'a' isn't the 'a' that I want. :) |
| 11:14 |
Dyrcona |
I'm going to see what these problem records look like in the database before I do anything else. |
| 11:16 |
Dyrcona |
One of them has different characters for the first letter of the author's last name in different fields. It's \xC3\x85 in one field and \xC3\x81 in another.... |
| 11:18 |
Dyrcona |
245$c on that record is empty in the database, but has the author's name in the input. It's the one with \xC3\x85. |
| 11:18 |
Dyrcona |
Grr.... |
| 11:19 |
Dyrcona |
I've wasted most of my week on these records so far. |
| 11:20 |
Dyrcona |
Now, my dump program is complaining about wide character in print. It didn't before I set the encoding.... |
| 11:29 |
miker |
are you calling MARC::Charset->assume_unicode(1); before processing the records? (that's the "force the issue" option) |
| 11:34 |
Dyrcona |
miker: No. You can see the the program that I'm using to load the records. I haven't shared the preprocessor, yet. |
| 11:35 |
Dyrcona |
I was going to ask if anyone in here has used pymarc much. (I've looked at it.) Python usually has better charset handling that does Perl, and I wonder if anyone has used chardet to detect the charsets used by MARC records. |
| 11:35 |
Dyrcona |
I've found all kinds of crap in MARC from 3rd parties. |
| 11:36 |
miker |
right on. fwiw, many of our scripts and db functions use both assume_unicode(1) and ignore_errors(1). see the top part of Open-ILS/src/extras/import/marc_add_ids for instance |
| 11:38 |
Dyrcona |
Well, I've set the 09 in the leader to 'a' for this batch. When I open the file in Emacs it looks like UTF-8. |
| 11:39 |
Dyrcona |
I'm running it again in another db with a fresh copy of production. I reloaded them after yesterday's tests. |
| 11:40 |
jeff |
the last time I looked at pymarc was years ago, and I thought that there were a few broken things about it, especially with regard to encoding. |
| 11:40 |
Dyrcona |
jeff: I don't recall if I actually used it. I may just perused the repo or something like that. |
| 11:41 |
jeff |
It may have gotten better since then, or I may have been mistaken. I only remember that I had issues with a large set of changes that had recently gone into it, but don't recall more than that offhand. |
| 11:44 |
Dyrcona |
It looks like converting to unicode from marc8 would be cumbersome. However, It would be in keeping with chardet. I've gotten records where most fields are 1 charset, then some field has something else thanks to copy/paste cataloging. |
| 11:44 |
Dyrcona |
https://pymarc.readthedocs.io/en/latest/index.html#pymarc.marc8.marc8_to_unicode |
| 11:44 |
Dyrcona |
Looks like you're only expected to use it on output. |
| 11:45 |
Dyrcona |
The documentation needs to be updated or PyMarc does: "When I can require python 2.3, this will go away." |
| 11:47 |
Dyrcona |
I might play with this some time, but for now I'm sticking to Perl. |
| 11:50 |
Dyrcona |
It's funny that my preprocessor, using MARC::Record, has no problem with these records, but I guess I'm not asking it to do any charset conversion. Well, it has no problem since I fixed the double encoding bug. :) |
| 11:58 |
Dyrcona |
IIRC, I think I had to set the charset in these records yesterday, but I forgot when I ran the preprocessor after making changes to it this morning. |
| 11:59 |
Dyrcona |
Yeah, it has passed the author with the different characters for the first letter of the last name with no warnings or errors. |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:12 |
Dyrcona |
Well, there's "stuff" in the author's name in the database. I'm not sure it's correct. |
| 12:28 |
Dyrcona |
Looks good in my test catalog, so... I guess I'll load these into production. |
| 12:29 |
Dyrcona |
multiple-test-environments++ |
| 13:07 |
mantis |
Does anyone have suggestions for software that locks browsers into a kiosk mode for OPAC use? We used OpenKiosk for a while but it's causing a lot of white screening and timeouts on Linux OS. |
| 13:28 |
berick |
mantis: have you tried the kiosk mode options baked into most browsers? |
| 13:31 |
jeff |
I've heard good things about webconverger in the past, but it seems that they haven't updated in a while. We used to use OpenKiosk, but now I think we use Chrome/Chromium with a browser plugin called from a pruned-down xinitrc or the equivalent on some little linux boxes. |
| 13:32 |
jeff |
Biggest issue (other than it being somewhat cobbled together) is that the image doesn't do much to avoid writes, so the microSD cards tend to wear out often. |
| 13:33 |
jeff |
I don't think Chrome, Edge, or Firefox have stock "kiosk" mode options that would be suitable for an OPAC. Chrome OS does have a kiosk mode that you might look into, though. |
| 13:33 |
jeff |
It will likely require a management license for the Chrome OS device. |
| 13:45 |
mantis |
berick++ |
| 13:45 |
mantis |
jeff++ |
| 13:45 |
mantis |
thanks for the suggestions; I'm mostly speaking on behalf of our network services |
| 13:45 |
mantis |
I think they did try at one point using the Kiosk setting in Firefox but they liked OpenKiosk because it really locks the browser down |
| 13:46 |
mantis |
unrelated but where in the Boopac is the search courses module? This is my first time testing it |
| 13:49 |
Dyrcona |
So, why does "identical" css produce different results on different servers in the same browser? I seem to have a discrepancy between my devleopment VM and my training server, and git tells me the relevant files are the same.... |
| 13:51 |
|
JBoyer joined #evergreen |
| 13:53 |
Dyrcona |
I even emptied cache and hard reloaded..... |
| 13:56 |
Dyrcona |
Ok. Got it. There's a change on the development vm that didn't make int into git. :( |
| 14:00 |
Dyrcona |
ugh.... |
| 14:00 |
Dyrcona |
A stray file somehow got added. |
| 14:04 |
Dyrcona |
git add . :/ |
| 14:32 |
csharp_ |
@blame . |
| 14:32 |
pinesol |
csharp_: . crafted the perfect SHA-1 collision, breaking Git |
| 14:32 |
csharp_ |
pinesol: appropriate |
| 14:32 |
pinesol |
csharp_: uh huh.. please tell me more about that |
| 14:33 |
csharp_ |
@decide implicit or explicit |
| 14:33 |
pinesol |
csharp_: go with explicit |
| 14:35 |
Dyrcona |
I only have those git add problems when I add things to git on the servers. :) |
| 15:11 |
gmcharlt |
Dyrcona: re MARC::Charset, yes |
| 15:13 |
Dyrcona |
gmcharlt: I'm not sure it's a bug in MARC::Charset, now. It's bad data combined with user error/forgetfulness. |
| 15:13 |
gmcharlt |
Dyrcona: ah, OK |
| 15:13 |
Dyrcona |
I thought the records were specifying UTF-8, but they weren't, even though there were in fact encoded in UTF-8. |
| 15:14 |
Dyrcona |
s/there/they/ # It's getting late and the fingers are tired... :) |
| 15:59 |
Dyrcona |
JBoyer: "navigate the narrows?" |
| 16:08 |
jeff |
Dyrcona: if you're asking about the branch name... https://bugs.launchpad.net/evergreen/+bug/1724008/comments/22 |
| 16:08 |
pinesol |
Launchpad bug 1724008 in Evergreen "Web Client: Smallish screens obscure menus" [High,Confirmed] |
| 16:38 |
|
jvwoolf left #evergreen |
| 16:44 |
JBoyer |
I was thinking 2 things: 1, if the branch name doesn't matter it needn't be dull, and 2, I thought I'd heard reference to "the narrows" as narrow streams or rivers or something in some media somewhere. If not, all the better about point 1. :_ |
| 16:44 |
JBoyer |
:) |
| 16:47 |
Dyrcona |
JBoyer++ |
| 16:47 |
Dyrcona |
Yeah, that's what a narrows is. |
| 16:47 |
Dyrcona |
narrows are? is? I'm not gonna bother looking it up. |
| 16:58 |
pinesol |
News from commits: LP#1955931 Staff catalog show more details - add due date <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4e6fe743271992347686a113c390b208c162942b> |
| 17:07 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:19 |
|
Christineb joined #evergreen |
| 18:39 |
|
jihpringle joined #evergreen |
