| Time |
Nick |
Message |
| 06:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:15 |
|
kmlussier joined #evergreen |
| 08:36 |
|
collum joined #evergreen |
| 08:36 |
|
jvwoolf joined #evergreen |
| 08:36 |
|
Jillianne joined #evergreen |
| 08:51 |
csharp |
@quote randome |
| 08:51 |
pinesol_green |
csharp: Yeah, well, you know, that's just, like, your opinion, man. |
| 08:51 |
csharp |
@quote random |
| 08:51 |
pinesol_green |
csharp: Quote #87: "<jeff> responsive XUL isn't really a thing." (added by bshum at 02:49 PM, July 30, 2014) |
| 08:57 |
|
bos20k joined #evergreen |
| 09:08 |
|
yboston joined #evergreen |
| 09:13 |
|
Dyrcona joined #evergreen |
| 09:17 |
|
mmorgan joined #evergreen |
| 09:53 |
csharp |
@band add Responsive XUL |
| 09:53 |
pinesol_green |
csharp: Band 'Responsive XUL' added to list |
| 10:02 |
|
rlefaive joined #evergreen |
| 10:11 |
|
rlefaive joined #evergreen |
| 10:16 |
csharp |
okay, still working on testing bug 1691269 's fix (understanding that it has been committed to master)... |
| 10:16 |
pinesol_green |
Launchpad bug 1691269 in Evergreen "web client: copy templates created on XUL not displayed" [Medium,Fix committed] https://launchpad.net/bugs/1691269 - Assigned to Galen Charlton (gmc) |
| 10:17 |
jeff |
csharp: found more issues? |
| 10:17 |
csharp |
first finding is that my previously-existing XUL client templates do not show up in the web client - not sure if that's expected or not |
| 10:18 |
csharp |
second, after clearing out my existing XUL templates (via DB delete), then importing a XUL template file exported from a 3.0.1 XUL client, they do not show up for me in the web client |
| 10:18 |
csharp |
if I create a new template in XUL, it *does* show up in the web client as expected |
| 10:19 |
csharp |
but imported templates aren't working for us |
| 10:19 |
jeff |
hrm. odd. i haven't followed closely enough to give advice on what to try next. |
| 10:19 |
csharp |
(to clarify, I imported the XUL file into the 3.0.1 XUL client and the templates showed up within the XUL client) |
| 10:19 |
jeff |
if you can reproduce with an exported template file attaching that to the bug (or a new bug?) might give others something to go on. |
| 10:20 |
csharp |
probably a new bug |
| 10:20 |
csharp |
since that one has been accepted |
| 10:20 |
|
jvwoolf joined #evergreen |
| 10:20 |
jeff |
if you can reduce it to a smaller test case that might help also. |
| 10:20 |
csharp |
yeah - this is complex no matter how you slice it :-/ |
| 10:21 |
jeff |
also, you probably already know for certain, but i think there's at least one part where no further attempts are made to migrate templates after it's been "done once" for a given user/workstation/whatever. |
| 10:21 |
jeff |
(as long as you're not running into that in testing, or are accounting for it already) |
| 10:21 |
csharp |
oh wait - let me make sure everything was gone - I know the browser stored pref was deleted |
| 10:21 |
* mmorgan |
did some testing on that bug at one point, and did see existing xul templates imported to the web client successfully, but if any had been created in the web client, it didn't work. |
| 10:22 |
csharp |
right - you have to remove any setting already in the DB |
| 10:22 |
csharp |
*and* the browser-side stored pref |
| 10:23 |
mmorgan |
What setting needs to be removed from the DB? |
| 10:23 |
csharp |
mmorgan: 'webstaff.cat.copy.templates' |
| 10:24 |
mmorgan |
Ah. ok. |
| 10:24 |
* mmorgan |
may have tested an earlier version. |
| 10:24 |
csharp |
I can confirm that my user doesn't have that setting set |
| 10:24 |
csharp |
so we're as pristine as we can be when I attempt this |
| 10:25 |
csharp |
I haven't looked closely at the code that makes the conversion, though, maybe something about the XUL file is unexpected |
| 10:26 |
jeff |
right, especially if it has vestiges of some older syntax quirk that is preserved by the export/import process but not generated on newly created templates in the current XUL client. |
| 10:26 |
jeff |
any errors in the javascript console at the time when the templates would normally be converted in webby? |
| 10:27 |
csharp |
yes, actually :-) |
| 10:27 |
csharp |
https://pastebin.com/WBbytZdJ |
| 10:28 |
csharp |
oh - I just realized I didn't apply gmcharlt 's additional fixes for that |
| 10:28 |
csharp |
lemme do that and try again |
| 10:28 |
csharp |
"that" == "that bug" |
| 10:32 |
jeff |
can you share the exported template file? |
| 10:32 |
jeff |
and possibly the database value of your xul templates user setting after importing it? |
| 10:33 |
jeff |
(feel free to just do that in the bug, actually -- i don't mean to waste your time here when you'll probably want to put it in the bug also) |
| 10:34 |
|
rlefaive joined #evergreen |
| 10:35 |
jeff |
tmp_val.match not being a function implies that you're hitting a non-string value where the xul template conversion code isn't expecting it. |
| 10:40 |
csharp |
jeff: thanks - I'mma test this again with the further fixes then open a bug if it's still happening |
| 10:40 |
|
rlefaive joined #evergreen |
| 10:41 |
csharp |
and yes, I would expect lots of potential "garbage" in these templates - I expect many of them have been around since The Beginning™ |
| 10:41 |
jeff |
looks like at a minimum, shelving location in older xul templates can contain a non-string field value, like "Shelving Location":{"value":527,"type":"attribute","field":"location"} |
| 10:41 |
jeff |
and i think that breaks the current conversion code where it assumes a value will be a string. |
| 10:42 |
csharp |
jeff: the file: |
| 10:42 |
csharp |
https://pastebin.com/VS9d4dEz |
| 10:42 |
jeff |
on a newer (2.10 at least) template, you'll have something like "Location/Collection":{"value":"1012","field":"location","type":"attribute"} |
| 10:42 |
csharp |
oh - so it's just the quotes then? |
| 10:44 |
jeff |
it's that the lack of quotes means that in javascript that value is a number and not a string. |
| 10:44 |
jeff |
and number objects don't have a match method. |
| 10:44 |
csharp |
right - I just changed the file to quote the numbers as strings |
| 10:45 |
jeff |
so var foo = 1; foo.match(/^1/); will error. |
| 10:45 |
csharp |
gonna try again there too |
| 10:45 |
jeff |
it's possible that not all of those numbers need to be strings, and in fact it's possible that changing them all to strings may break things in a slightly different way, but i'll be interested to see what you find. :-) |
| 10:46 |
jeff |
the stat cats seem to be fine if they're numbers or strings, for example. |
| 10:46 |
csharp |
heh - yep - now the XUL client won't import it |
| 10:46 |
jeff |
because they're just passed as arguments to parseInt |
| 10:47 |
jeff |
hah! |
| 10:50 |
jeff |
csharp: try this one -- left the stat cats as numbers, changed location and status to strings: https://pastebin.com/SEkD8WMF |
| 10:56 |
csharp |
jeff: thanks - imported correctly - now to try the conversion |
| 11:04 |
|
jwoodard joined #evergreen |
| 11:05 |
|
rlefaive joined #evergreen |
| 11:09 |
csharp |
well this time no error, but the templates aren't there either - gonna try and see what's going on |
| 11:16 |
|
drigney joined #evergreen |
| 11:16 |
|
Christineb joined #evergreen |
| 11:16 |
jeff |
was webstaff.cat.copy.templates set to anything after that attempt? |
| 11:16 |
csharp |
jeff: nope |
| 11:16 |
jeff |
(and... just to be sure, it was deleted before the attempt?) |
| 11:16 |
jeff |
hrm. |
| 11:16 |
csharp |
yes it was deleted |
| 11:17 |
jeff |
do you have a hatch item cat.copy.templates? |
| 11:17 |
csharp |
no |
| 11:18 |
jeff |
weird that it silently failed / returned nothing. |
| 11:21 |
|
rlefaive joined #evergreen |
| 11:35 |
csharp |
ok - got the original "tmp_val.match is not a function" error after trying again |
| 11:36 |
csharp |
if ( tmp_val.match(/^[-0-9.]+$/) && !(field_name.match(/(?:loan_duration|fine_level)/))) { |
| 11:39 |
csharp |
JBoyer++ # "Groovy" makes finding this code easy :-) |
| 11:40 |
jeff |
interesting. only non-string values should have been stat cats. |
| 11:40 |
csharp |
gonna add some console.log statements to see into what's going on |
| 11:40 |
jeff |
maybe i missed one. :-) |
| 11:43 |
jeff |
i missed one. |
| 11:43 |
jeff |
"value":67,"field":"circ_lib","type":"attribute" |
| 11:43 |
csharp |
ah |
| 11:44 |
jeff |
fixed, if you didn't have it already: https://pastebin.com/3qiN68rC |
| 11:45 |
jeff |
i think that one has no numbers ourside of stat cats. |
| 11:45 |
jeff |
should import in XUL okay, and hopefully converts okay. |
| 11:45 |
csharp |
imports fine |
| 11:46 |
csharp |
jeff++ # worked! |
| 11:47 |
csharp |
so... the solution is to further check for number vs. string in the converter? |
| 11:51 |
* csharp |
runs off for a lunch break - back later :-) |
| 11:52 |
jeff |
yes. the solution is to not call .match() on a value that we don't know is a string. |
| 12:02 |
jeff |
lots of possible solutions. not sure which is best / most consistent with existing code: wrap in try/catch (possibly more than one), test for string/number (or existence of .match) using typeof, or... something else i've forgotten. |
| 12:02 |
jeff |
another concern is if the native web template code expects/handles/generates numbers vs strings. |
| 12:04 |
jeff |
be great if the template conversion had the beneficial side effect of normalizing the templates. |
| 12:04 |
|
rlefaive joined #evergreen |
| 12:04 |
jeff |
there are likely to be other quirks about existing templates. anyone want to volunteer up theirs, anonymized or otherwise? :-) |
| 12:07 |
|
rlefaive_ joined #evergreen |
| 12:08 |
|
sandbergja joined #evergreen |
| 12:09 |
miker |
how about tmp_val.toString().match() |
| 12:15 |
jeff |
+1 |
| 12:16 |
jeff |
works as long as value isn't null, and we can either handle that or hope that we never see one. |
| 12:17 |
jeff |
(none in the wild in our db, and i'm pretty sure the XUL code can't generate any (which is why we have "<HACK:KLUDGE:NULL>") |
| 12:21 |
|
_adb joined #evergreen |
| 12:30 |
|
khuckins joined #evergreen |
| 12:32 |
|
jihpringle joined #evergreen |
| 12:57 |
|
jvwoolf joined #evergreen |
| 12:58 |
|
rlefaive joined #evergreen |
| 13:05 |
|
rlefaive joined #evergreen |
| 13:19 |
csharp |
toString() appears to fix the problem |
| 13:19 |
csharp |
miker++ |
| 13:19 |
csharp |
jeff++ |
| 13:19 |
csharp |
gonna open a bug for it |
| 13:28 |
mmorgan |
csharp++ |
| 14:07 |
* mmorgan |
just stumbled upon the new survey data in concerto :) |
| 14:07 |
mmorgan |
csharp++ |
| 14:14 |
csharp |
:-) |
| 14:46 |
csharp |
probably a silly question, but where is the repo for Hatch? |
| 14:47 |
csharp |
http://git.evergreen-ils.org/?p=Hatch.git;a=shortlog;h=refs/heads/master looks quite old |
| 14:47 |
berick |
csharp: you get 1 gues |
| 14:48 |
berick |
csharp: there's some newer stuff in working/Hatch |
| 14:49 |
csharp |
aha - cool - thanks |
| 14:52 |
* csharp |
is training a new PINES library on local admin stuff and realized he hasn't even installed hatch recently :-/ |
| 14:52 |
csharp |
training is Thursday morning, so I have some time :-) |
| 14:53 |
berick |
we need to get mine and jason's patches merged.. |
| 14:56 |
csharp |
berick: I'm testing from the chrome store, so this'll be a good smoke test |
| 14:56 |
csharp |
I'll look at JBoyer's branch too if I get a chance |
| 14:57 |
* csharp |
forgets what it's like to use Windows natively |
| 14:58 |
csharp |
nice - that's very easy |
| 14:59 |
csharp |
install Java, install extension, open web client and click the checkboxes |
| 14:59 |
berick |
csharp: be sure to use this installer https://bugs.launchpad.net/evergreen/+bug/1708757/comments/2 |
| 14:59 |
pinesol_green |
Launchpad bug 1708757 in Evergreen "Publish Hatch to Chrome web store" [Wishlist,New] - Assigned to Galen Charlton (gmc) |
| 14:59 |
berick |
at least until we build another one based on jason's changes.. |
| 15:00 |
berick |
csharp: also, i suggest only clicking the 'use for printing' option |
| 15:00 |
berick |
offline doesn't do anything and settings storage is likely going away down the road |
| 15:02 |
csharp |
yep - that's what I used to install |
| 15:02 |
* berick |
will look at bug 1733692 soon |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:02 |
pinesol_green |
Launchpad bug 1733692 in Evergreen "Hatch Windows installer doesn't follow best practices" [High,New] https://launchpad.net/bugs/1733692 |
| 15:03 |
csharp |
(actually I just searched "Hatch" in the chrome store and went from there) |
| 15:03 |
berick |
csharp: to be clear, i'm talking about the windows installer part, not the extension |
| 15:03 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1708757/+attachment/5007318/+files/Hatch_Installer_0.1.2.exe |
| 15:03 |
csharp |
oh |
| 15:03 |
pinesol_green |
Launchpad bug 1708757 in Evergreen "Publish Hatch to Chrome web store" [Wishlist,New] - Assigned to Galen Charlton (gmc) |
| 15:04 |
berick |
still 2 separate steps, but it looks like bug 1733692 might boil it down to 1 step (if i'm reading that right) |
| 15:04 |
pinesol_green |
Launchpad bug 1733692 in Evergreen "Hatch Windows installer doesn't follow best practices" [High,New] https://launchpad.net/bugs/1733692 |
| 15:05 |
|
rlefaive joined #evergreen |
| 15:06 |
csharp |
ok, so install Java, then run .exe |
| 15:07 |
berick |
right |
| 15:09 |
csharp |
then install from web store |
| 15:27 |
|
jvwoolf1 joined #evergreen |
| 15:42 |
|
hbrennan joined #evergreen |
| 16:17 |
Dyrcona |
parts-- # The same copy can be on different parts on different bib records. When you try to merge those two bib records, kaboom! |
| 16:46 |
Dyrcona |
yay....db2 crashed because not enough space on the postgresql partition. |
| 16:46 |
* Dyrcona |
thinks a bit of lvm magic is overdue. |
| 16:51 |
|
mmorgan joined #evergreen |
| 16:54 |
csharp |
yowza |
| 16:55 |
Dyrcona |
Well, the main db has about 3x the capacity of the secondary db, and I'm not sure which array was originally meant for db storage on the secondary. |
| 16:56 |
Dyrcona |
Somebody else set it up with Ubuntu 16.04 after it had run Debian something before. |
| 16:57 |
Dyrcona |
So, I'm thinking I might steal a couple hundred gig from the / partition and add it to the db partition. |
| 16:57 |
Dyrcona |
It crashed during the last upgrade/reingest for lack of space. |
| 16:59 |
Dyrcona |
This was just everyday use, however. |
| 17:00 |
|
mmorgan left #evergreen |
| 17:00 |
Dyrcona |
Note to self: The replicant should be identical to the main production db server. |
| 17:00 |
csharp |
if it runs reports queries, maybe an unreasonably large report query filled it up |
| 17:00 |
Dyrcona |
Next time, I won't name it Prys. :) |
| 17:00 |
csharp |
that used to happen to us before we had a sane setup :-) |
| 17:00 |
Dyrcona |
Well, maybe, not sure how that works in a read only db. |
| 17:01 |
csharp |
the select creates a huge temp table for itself internally to do sorting, etc. |
| 17:02 |
csharp |
pg_top provides some visibility for that |
| 17:03 |
Dyrcona |
Nov 28 16:15:08 db2 postgres[5944]: [16-1] 2017-11-28 16:15:08 EST [5944-15] FAT |
| 17:03 |
Dyrcona |
AL: could not extend file "base/22531435/28190571.4": wrote only 4096 of 8192 b |
| 17:03 |
Dyrcona |
ytes at block 615117 |
| 17:03 |
Dyrcona |
Nov 28 16:15:08 db2 postgres[5944]: [16-2] 2017-11-28 16:15:08 EST [5944-16] HIN |
| 17:03 |
Dyrcona |
T: Check free disk space. |
| 17:03 |
csharp |
eww |
| 17:04 |
csharp |
well at least postgres knows how to handle that - once you give it the space again it will try to catch up without a lot of fuss |
| 17:04 |
Dyrcona |
Nov 28 16:15:08 db2 postgres[5944]: [16-3] 2017-11-28 16:15:08 EST [5944-17] CONTEXT: xlog redo Btree/SPLIT_R: level 0, firstright 367 |
| 17:04 |
Dyrcona |
Nov 28 16:15:08 db2 postgres[5943]: [3-1] 2017-11-28 16:15:08 EST [5943-4] LOG: startup process (PID 5944) exited with exit code 1 |
| 17:04 |
Dyrcona |
Yes, it seems to be OK now. |
| 17:05 |
csharp |
postgresql++ |
| 17:05 |
Dyrcona |
It is only 'bout half an hour behind. |
| 17:05 |
csharp |
streaming replication is like the best thing ever |
| 17:05 |
Dyrcona |
I caught it, 'cause I wanted to run a query against the database and my connection was refused. |
| 17:05 |
Dyrcona |
Yes, indeed. |
| 17:05 |
Dyrcona |
It's up there. |
| 17:06 |
csharp |
so much resiliency - things that would have been hours of work recovering with slony are just automatically solved |
| 17:06 |
csharp |
(as long as you have the space for the full db) |
| 17:07 |
* csharp |
looks forward to the newer features (9.6? 10?) that allow tailored replication |
| 17:08 |
Dyrcona |
Looks like it is caught up already. |
| 17:08 |
Dyrcona |
Well, we usually have the space.... |
| 17:10 |
|
khuckins joined #evergreen |
| 17:10 |
csharp |
Dyrcona: I think temp_file_limit is what I'm looking for, but there's a setting you can set to cap the file size for reports/select queries, etc. |
| 17:11 |
Dyrcona |
OK. I'll have a look at that. |
| 17:11 |
Dyrcona |
I'm not sure if the problem came from the main db being temporarily too big or from a report. |
| 17:17 |
Dyrcona |
More fun with parts, that copy I mentioned above can be deleted, too, so staff can't really deal with it. |
| 17:56 |
_adb |
is it possible to call API methods that expect a hash reference (for example 'open-ils.circ.money.payment') from the osrf http gateway? i tried encoding the parameter as a JSON object, but this didn't work; it says "Can't use string (\"{'patron_credit':1,'userid':1057\"...) as a HASH ref while \"strict refs\" in use at /usr/local/share/perl/5.18.2/OpenILS/Application/Circ/Money.pm line 259.\n\n","status":500} |
| 17:56 |
_adb |
am i doing something wrong, or should this just not be done? |
| 17:59 |
Dyrcona |
_adb: It should work, but I don't usually use the gateway. |
| 18:00 |
Dyrcona |
Have you tried it without quotes around the JSON object? |
| 18:01 |
_adb |
that throws errors in gateway.log: "Expected quotation mark to begin hash key; didn't find it" |
| 18:03 |
_adb |
i can work around this by registering my own service/method that doesn't require a hash reference to wrap money.payment. |
| 18:06 |
Dyrcona |
There should be some examples in JavaScript. Acquisitons uses the osrfhttp gateway, IIRC. |
| 18:09 |
_adb |
i think you were right. removing the quotes around the json object helped. looks like my "expected quotation mark..." error was because my json was invalid :-/ (was using ' instead of ") |
| 18:10 |
_adb |
thank you for your help! |
| 18:10 |
_adb |
Dyrcona++ |
| 18:10 |
Dyrcona |
Cool. Glad my suggestion helped you figure it out. |
| 18:10 |
* Dyrcona |
goes to cook some dinner. |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:41 |
jeffdavis |
Are located URIs working in 3.0? On a test server the acts_as_copy flag set to true and a record with a located URI owned by BR1, the record does not show up in search results at any search scope. |
| 18:48 |
miker |
jeffdavis: JBoyer and I addressed an issue with located URI search during the hack-a-way, should be in tomorrow's release. (not at a computer to look for a commit hash ATM) |
| 18:50 |
jeffdavis |
ah, thanks miker |
| 18:57 |
jeffdavis |
5a187c81 looks like the relevant commit |
| 18:57 |
pinesol_green |
jeffdavis: [evergreen|Mike Rylander] LP#1723977: Move no-LURIs test to be a peer of no-copies test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5a187c8> |
| 19:17 |
csharp |
7c3cdbbd |
| 19:17 |
pinesol_green |
csharp: [evergreen|Mike Rylander] LP#1706107: Offline mode - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7c3cdbb> |
| 20:28 |
* csharp |
wonders if the existence of hatch will make a difference in the speed of inserting 1.6M rows into the lovefield DB |
| 20:37 |
miker |
csharp: nopers :( |
| 20:39 |
miker |
jeffdavis: I don't know for sure that that's relevant, but it may be... |
| 20:59 |
csharp |
miker: is there a way to just read from the file instead of needing to import it into the DB? |
| 21:01 |
* csharp |
has never studied the XUL version of this to see how it's currently handled |
| 21:05 |
miker |
xulrunner has fs access, but browsers, not so much |
| 21:08 |
miker |
when hatch was a local websockets server, the plan was to have it download the file and have offline talk to it. but then it became an extension with a host service, and that killed that. there might still be a way to leverage hatch, but time and 3.0 waited for no man |
| 21:09 |
csharp |
miker: makes sense |
| 21:10 |
miker |
basically, when hatch moved away from the original design, I had to scramble for a replacement. enter lovefield |
| 21:12 |
csharp |
gotcha |
| 21:13 |
miker |
I'm not clear on whether the local websockets stuff was actually killed by the browsers, or just threatened to be killed, but the hatch change may very well have been required |
| 21:16 |
miker |
if we end up switching from upup to some other service worker framework, as dbs has suggested, then that could probably absorb the lovefield bits, and manage the block list in the background |
| 21:17 |
miker |
but that's all theoretical until some has the tuits for research :( |
| 21:19 |
csharp |
thanks for the update - I'll provide a link to your comments here in the bug |
| 22:11 |
jeff |
local websockets hasn't been killed yet. |
| 22:11 |
jeff |
but there are still certificate challenges. |
| 22:13 |
jeff |
i'm not sure that the current design of hatch rules out making offline faster, though. |
| 22:13 |
hbrennan |
omg, night people! Hi! |
| 22:14 |
jeff |
hi! |
