| Time |
Nick |
Message |
| 01:49 |
|
hopkinsju joined #evergreen |
| 01:49 |
|
Bmagic joined #evergreen |
| 01:49 |
|
dluch joined #evergreen |
| 04:27 |
|
edoceo joined #evergreen |
| 05:37 |
|
edoceo joined #evergreen |
| 06:30 |
|
geoffsams joined #evergreen |
| 07:54 |
|
JBoyer joined #evergreen |
| 07:58 |
|
rjackson_isl joined #evergreen |
| 08:08 |
|
collum joined #evergreen |
| 08:19 |
|
ericar joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:48 |
|
jwoodard joined #evergreen |
| 08:55 |
|
mmorgan1 joined #evergreen |
| 09:04 |
|
Newziky joined #evergreen |
| 09:10 |
|
mrpeters joined #evergreen |
| 09:17 |
|
mrpeters joined #evergreen |
| 09:25 |
|
mmorgan joined #evergreen |
| 09:41 |
|
mmorgan1 joined #evergreen |
| 09:42 |
|
yboston joined #evergreen |
| 10:06 |
* bshum |
looks left |
| 10:07 |
* bshum |
looks right |
| 10:07 |
* bshum |
crosses the street to see what was on the other side |
| 10:12 |
* jwoodard |
ponders why bshum crossed the road instead of the chicken |
| 10:20 |
miker |
bshum: do not try to cross the road, that is impossible. instead only try to realize the truth; there is no road. then you will see that it is not the chicken that crosses the road, it is only yourself. |
| 10:21 |
* gmcharlt |
ponders why bshum crossed the road instead of the penguin |
| 10:21 |
|
Dyrcona joined #evergreen |
| 10:23 |
bshum |
gmcharlt: Haha, the penguin is going to be more famous than me at the rate he's going. |
| 10:24 |
Dyrcona |
heh |
| 10:24 |
jwoodard |
miker: that was to deep for me this morning. I'm running on 1 cup of tea. |
| 10:31 |
bshum |
miker: And your lucky numbers are 54, 16, 45, 51, 7, 11 |
| 10:34 |
|
Bmagic joined #evergreen |
| 10:43 |
|
Christineb joined #evergreen |
| 11:25 |
|
sandbergja joined #evergreen |
| 11:44 |
|
Christineb joined #evergreen |
| 11:53 |
|
ericar joined #evergreen |
| 12:12 |
Bmagic |
has anyone got the hatch printing software running on OSX? |
| 12:14 |
|
brahmina joined #evergreen |
| 12:14 |
jeff |
when i upgrade from snow leopard, i'm planning on trying it! :-) |
| 12:15 |
Bmagic |
oh, is there an OSX version requirement? |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:16 |
jeff |
JRE requirement. |
| 12:16 |
|
mmorgan joined #evergreen |
| 12:17 |
jeff |
$ java -version |
| 12:17 |
jeff |
java version "1.6.0_65" |
| 12:18 |
* bshum |
goes screaming for the hills at the sight of java here :( |
| 12:19 |
Dyrcona |
Hatch is a "bad" name. |
| 12:19 |
Dyrcona |
If I Google "evergreen hatch," I get Evergreen Hatch Works, a machine shop. :) |
| 12:20 |
Dyrcona |
evergreen ils hatch is a better search. |
| 12:20 |
Dyrcona |
If anyone cares. |
| 12:22 |
Dyrcona |
IIRC, hatch requires JDK8 and JavaFX, yes? |
| 12:23 |
Dyrcona |
I was trying to find a citation for that. |
| 12:36 |
Dyrcona |
Yeah, the README specifies JDK8. |
| 12:38 |
jeff |
Dyrcona: http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:dev_notes is what i thought of |
| 12:38 |
Dyrcona |
jeff: I was skimming that. |
| 12:39 |
Dyrcona |
Yes, it says in that document. |
| 12:39 |
Dyrcona |
"For printing HTML, we are using the brand new JDK version 8." |
| 12:39 |
Dyrcona |
And, yeah, the classes are part of JavaFX. |
| 12:40 |
Dyrcona |
What I've seen, playing with JavaFX 8, is that there are differences between Oracle's JDK and OpenJDK. |
| 12:40 |
Dyrcona |
The README specifies it has not been tested with OpenJDK. |
| 12:59 |
|
bmills joined #evergreen |
| 13:03 |
|
Callender_ joined #evergreen |
| 13:12 |
|
wjr joined #evergreen |
| 13:13 |
|
mrpeters joined #evergreen |
| 13:24 |
|
ericar_ joined #evergreen |
| 13:48 |
jeff |
Sorry |
| 13:48 |
jeff |
We weren't able to complete your booking. Please wait a moment and try again. |
| 13:54 |
|
jihpringle_ joined #evergreen |
| 14:04 |
|
berick joined #evergreen |
| 14:07 |
Bmagic |
Just had a call about "Browse the catalog" on the opac. People are using it? We dont, but it's there. Has anyone had requests for that list to ignore commas when sorting alphabetical? |
| 14:14 |
* jeff |
eyes the input "Twitter/IRC handle" |
| 14:37 |
jeff |
okay, all registered and travel booked. |
| 14:37 |
jeff |
phew. |
| 14:42 |
kmlussier |
Bmagic: We've had requests for it to ignore ending punctuation and differences in capitilizations to reduce duplicate entries. I haven't heard anything about ignoring commas in sorting, but it sounds reasonable. |
| 14:43 |
Bmagic |
so it's a bug? |
| 14:43 |
Dyrcona |
@decide bug or feature |
| 14:43 |
pinesol_green |
Dyrcona: go with feature |
| 14:44 |
mmorgan |
Bmagic: Here's one bug: lp 1350831 |
| 14:44 |
pinesol_green |
Launchpad bug 1350831 in Evergreen "Browse index punctuation causing multiple entries" [Medium,Confirmed] https://launchpad.net/bugs/1350831 |
| 14:48 |
jeff |
@decide bug or bad data |
| 14:48 |
pinesol_green |
jeff: go with bug |
| 14:49 |
Dyrcona |
@decide hug or coffee |
| 14:49 |
pinesol_green |
Dyrcona: That's a tough one... |
| 14:49 |
Dyrcona |
ha! |
| 14:49 |
jeff |
lovely. |
| 14:50 |
Bmagic |
kmlussier: mmorgan: http://catalog.library.ks.gov/eg/opac/browse?blimit=10&qtype=title&bterm=wood&locg=1 |
| 14:52 |
kmlussier |
Is that really a comma issue or is it an issue where it's not treating "wood" as a different word than "woodard"? |
| 14:53 |
Bmagic |
click next |
| 14:55 |
Bmagic |
it seems that all of the "Wood"'s should be next to eachother and all of the "Wooden" should be clustered up, etc |
| 14:55 |
Bmagic |
it seems to ignore the space |
| 14:55 |
kmlussier |
Bmagic: Yes, that's what I was trying to say. It's ignoring the space. |
| 14:55 |
kmlussier |
Bmagic: I don't see that happening in the C/W MARS catalog. |
| 14:56 |
Bmagic |
oh? so it's just us |
| 14:56 |
kmlussier |
When I browse for wood, I get http://bark.cwmars.org/eg/opac/browse?blimit=40&qtype=title&bterm=wood&locg=1 |
| 14:57 |
kmlussier |
I don't get to woodall until I do this search - http://bark.cwmars.org/eg/opac/browse?blimit=40&qtype=title&bterm=wooda&locg=1 |
| 14:58 |
Bmagic |
ha, that is just what I was doing |
| 14:59 |
Bmagic |
it certainly seems to be working more appropriately for you |
| 14:59 |
Bmagic |
I wonder what it could be. We are on 2.9.1 |
| 15:00 |
kmlussier |
Bmagic: C/W MARS is on 2.8.something, but I just checked NOBLE's, which is on 2.9.something, and it's the same as what I see in the C/W MARS catalog. |
| 15:00 |
Bmagic |
clues clues |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:22 |
miker |
Bmagic: may want to check your version of the evergreen.naco_normalize function ... that's used to produce what goes into metabib.browse_entry.sort_value, which is used for sorting browse entries |
| 15:22 |
Bmagic |
ah, I will |
| 15:55 |
|
jlitrell joined #evergreen |
| 15:59 |
|
mmorgan joined #evergreen |
| 16:09 |
|
vlewis joined #evergreen |
| 16:26 |
Bmagic |
when running autogen on multiple app servers, am I supposed to get the exact same hash result on each one? |
| 16:28 |
JBoyer |
Bmagic I believe so; if memory serves all of the data that makes it up should be coming from the db at some point. I may have outdated data on that one though. |
| 16:31 |
Bmagic |
hmmm |
| 16:31 |
tsbere |
I thought it wrote actual files, but don't know if those files include any date/time info for the hash. |
| 16:32 |
tsbere |
As such, while the data may be identical, the hash may vary based on that alone |
| 16:32 |
tsbere |
And, if writing out json results, who knows if they are ordered the same way, so while *effectively* the same they may actually be in a different order... |
| 16:34 |
|
vlewis joined #evergreen |
| 16:37 |
|
brahmina joined #evergreen |
| 16:41 |
jeff |
the hash value is often different for the reasons that tsbere described. |
| 16:41 |
jeff |
i'd be interested in making the order predictable. |
| 16:41 |
jeff |
there are... benefits. |
| 16:41 |
|
vlewis_ joined #evergreen |
| 16:46 |
|
vlewis joined #evergreen |
| 16:52 |
Bmagic |
I am wondering if that might be part of the issue we are having |
| 16:53 |
Bmagic |
we just added a branch, ran autogen and got different hashes on 8 servers. Then started getting reports from folks getting weird JS errors on different parts of the UI |
| 16:53 |
Bmagic |
but.. it might be that they needed to restart the staff client too.... so Im not totally sure |
| 16:54 |
tsbere |
Bmagic: Given how many things are cached at login in the staff client a restart sounds like a good idea |
| 16:54 |
tsbere |
And if the changes extend to the staff client they may even need an update, depending on the changes |
| 16:54 |
miker |
the hash shouldn't be different ... it uses the date, IIRC, but not the time |
| 16:55 |
Bmagic |
hmm, well, the hashes are definitely different every time I run autogen |
| 16:56 |
tsbere |
miker: You do not remember correctly, it hashes each output file to MD5, concats all of those, and then hashes that |
| 16:56 |
pastebot |
"miker" at 64.57.241.14 pasted "how hashes happen" (10 lines) at http://paste.evergreen-ils.org/10 |
| 16:57 |
* tsbere |
missed the fact the date command was in there, but for "all autogens run on the same date" that doesn't matter |
| 16:57 |
Bmagic |
we used to have /openils/var/web/images /openils/var/web/opac /openils/var/web/css all on NFS shares for the app servers, and autogen would produce the same hash when each server ran it at the same time (mostly) |
| 16:58 |
* tsbere |
packs up to head home |
| 16:58 |
miker |
if all the files are generated in the same way, and on the same date, and the time on the servers is correct ... not sure how you'd get a different hash |
| 16:58 |
Bmagic |
laters tsbere! |
| 16:59 |
Bmagic |
miker: yeah, that is perplexing |
| 16:59 |
miker |
the intent, certainly, is for them to be the same |
| 16:59 |
tsbere |
miker: I believe there are a number of json outputs from perl hashes, so variable hash order would break that. |
| 16:59 |
* tsbere |
actually walks away from IRC now ;) |
| 17:00 |
miker |
that's a new-perl problem, sure... using wheezy, we don't see that. |
| 17:00 |
miker |
Bmagic: so, obviously, the solution is "use wheezy" ;) |
| 17:00 |
jeff |
yeah, it's a not-ancient-perl thing. :-) |
| 17:01 |
jeff |
also, a "worked before by accident" thing :-) |
| 17:02 |
Bmagic |
so, if a staff client gets connected to app1 and downloads the JS upon login, then later ends up talking to app2 (who had a different hash from autogen) - there wouldn't be a problem in theory? |
| 17:04 |
jeff |
in theory, it would just make your client side caching less efficient for some things. |
| 17:06 |
Bmagic |
I saw a problem with specifically "Add Volume" command from the holdings screen "error in global_utils.js,ses() data.list.au[0].ws_ou is not a function" |
| 17:07 |
miker |
for autogen, if we trust our code, we could set PERL_PERTURB_KEYS to 0 and PERL_HASH_SEED to a known value, just for autogen's purposes, I think |
| 17:07 |
miker |
ref: http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks |
| 17:09 |
|
mmorgan left #evergreen |
| 17:11 |
jeff |
Bmagic: if you added an org unit and didn't restart the client i'd suspect that first before eg_cache_hash disagreement. |
| 17:11 |
jeff |
Bmagic: the XUL staff client caches things like aou and aout objects at start. |
| 17:12 |
Bmagic |
right |
| 17:12 |
jeff |
And by "caches", I mean "retrieves and stores and does not update until next login" |
| 17:12 |
Bmagic |
I'll be sure and announce to the members when the need to be sure and restart the staff clients |
| 17:13 |
jeff |
If you have the expectation that staff clients are not left running overnight, you can add org units off-hours and know that everyone will have a fresh start the next morning. :-) |
| 17:13 |
jeff |
I suspect that this is only an issue in the XUL staff client and is not an issue in the web staff client. |
| 17:22 |
Bmagic |
agreed |
| 17:23 |
Bmagic |
it's a side affect of downloading those JS files once upon login. WBSC relys on the browser to decide when to re-download the scripts (which could be a problem if the scripts change) |
| 19:37 |
|
bmills joined #evergreen |
| 19:44 |
|
kitteh___ joined #evergreen |
| 21:41 |
|
gsams joined #evergreen |
