| Time |
Nick |
Message |
| 08:08 |
|
BDorsey joined #evergreen |
| 08:16 |
|
collum joined #evergreen |
| 08:45 |
|
redavis joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:02 |
|
mantis1 joined #evergreen |
| 09:04 |
|
dguarrac joined #evergreen |
| 09:45 |
|
mmorgan joined #evergreen |
| 09:50 |
|
smayo joined #evergreen |
| 09:56 |
smayo |
Anyone have tips for debugging perl in evergreen? |
| 09:57 |
smayo |
Thus far my search for a step-by-step debugger like is available for javascript in browsers hasn't been successful |
| 09:58 |
smayo |
All the search results seem to assume that the perl you want is a script that you could run as an individual file |
| 10:00 |
smayo |
When usually I want to pause and see what values all the variables have after a net request from the frontend |
| 10:03 |
Dyrcona |
smayo: If you're trying to debug the Perl backend, this used to work: https://drive.google.com/drive/folders/0B1R9Iilpi7wzbDFNLWZEcngyRXc?resourcekey=0-YMr4MegoFZwred8A-1XhOA |
| 10:03 |
Dyrcona |
I have NOT had success with those steps in a long time, however. |
| 10:05 |
Dyrcona |
If you can't access that, let me know. I have another copy that I can share. That one is owned by kivilahtio, who hangs out in #koha over at oftc.net. |
| 10:06 |
smayo |
I can't access it xd |
| 10:07 |
Dyrcona |
I pasted the wrong link. That's a floder. |
| 10:07 |
Dyrcona |
Try this: https://docs.google.com/document/d/1sh2foeH-00yoz4K3FZLWlkI1W2-6ekRhWg1CvY4FRss/edit?usp=sharing |
| 10:08 |
|
berick joined #evergreen |
| 10:08 |
smayo |
That one works, thanks! I'll have a looksee |
| 10:10 |
berick |
smayo: for me it's $logger / print / warn / die |
| 10:10 |
Dyrcona |
smayo: Here's the original with (hopefully) my comments: https://docs.google.com/document/d/1CGMPWG2Pb5_mhnnEzXywfkQTnp8OeCdMivjd9Pap_ow/edit |
| 10:13 |
Dyrcona |
yeah, adding warn/die can help narrow down where the problems occur. Using the debug tutorial, I figured out that something happens twice during renewals that only needs to happen once, but I never put it on Lp. I should make a note to update the Evergreen debugging instructions for more recent Perl and put it on the dokuwiiki. |
| 10:14 |
smayo |
Dyrcona++ |
| 10:15 |
Dyrcona |
smayo: If you get something working, keep a record of the steps you did. We could collaborate on a new set of debugging instructions. |
| 10:16 |
* Dyrcona |
goes back to figuring out why his PHP Fieldmapper doesn't work with fleshed objects. |
| 10:16 |
Bmagic |
scottangel was struggling with this too, most helpful! Dyrcona++ eeevil++ berick++ |
| 10:17 |
Dyrcona |
Bmagic: As I mentioned earlier, those steps stopped working for me somewhere around Ubuntu 16 and whatever Perl version that was. I never figured out if it was changes in Perl or OpenSRF, but I suspect changes in Perl. |
| 10:17 |
Bmagic |
I know everyone was on break, but I wonder if any one noticed my post in here on Dec 23rd? |
| 10:19 |
Dyrcona |
For those who don't want to hunt: http://irc.evergreen-ils.org/evergreen/2023-12-23 |
| 10:22 |
Dyrcona |
We used to deal with that by blocking whole swatches of IP addresses in the firewall. Don't know what you can do on Google. |
| 10:23 |
Dyrcona |
@decide swatches or swathes |
| 10:23 |
pinesol |
Dyrcona: go with swatches |
| 10:23 |
Dyrcona |
Heh. Poetry. |
| 10:26 |
Dyrcona |
"packets dropping. Console locking. Now the boss is knocking... GigE port's down...." |
| 10:27 |
Dyrcona |
Funny how that parody of Chumbawumba "Tub Thumping" comes up now. |
| 10:27 |
Bmagic |
:) |
| 10:27 |
Dyrcona |
"gige posts down. but now they're up again. gotta find a se to blame." |
| 10:29 |
Dyrcona |
https://www.youtube.com/watch?v=9k6A0ZlhTyw |
| 10:30 |
Bmagic |
lol! I love it |
| 10:30 |
Bmagic |
pinging with no reply... |
| 10:30 |
Dyrcona |
And after that "Aces High" by Iron Maidrn. |
| 10:31 |
Dyrcona |
Ok. Back to debugging PHP... |
| 10:35 |
Dyrcona |
So maybe my problem is that I'm using the links to map fleshed fields. I'll just iterate over the fields to see if that works. |
| 10:39 |
Dyrcona |
Links should have worked... |
| 10:44 |
Dyrcona |
Nifty! |
| 10:45 |
|
briank joined #evergreen |
| 10:45 |
Dyrcona |
"$value instanceof stdClass" is returning false, but if I try to echo it, I get: Fatal error: Uncaught Error: Object of class stdClass could not be converted to string |
| 10:45 |
Dyrcona |
Ah... namespaces... |
| 10:46 |
Dyrcona |
So, I think adding a \ fixes it.... |
| 10:48 |
Dyrcona |
Yeah.. I forgot that classes and namespaces in PHP are a pain. I had to change the line to "$value instanceof \stdClass". Without the \ PHP was looking for \Evergreen\stdClass. |
| 10:58 |
Dyrcona |
This is pretty easy/cool. |
| 11:14 |
Dyrcona |
I should try updating objects to see if that works. |
| 11:33 |
Dyrcona |
$object->flattenFields() works. :) |
| 11:52 |
|
jihpringle joined #evergreen |
| 12:00 |
Dyrcona |
Bmagic: I'm going to review the commits in the vars.yml files in the apps repo. I'm going to pull them all into user/dyrcona/cwmars_custom_rel_3_7_4 in the working repository and use the commit hashes from that branch. |
| 12:00 |
Bmagic |
coolio |
| 12:01 |
Dyrcona |
We'll likely want to do an update sometime later this month or next. We've got changes for Aspen to put in, but I won't add those commits today. |
| 12:03 |
Dyrcona |
I may not finish, or event start, today. |
| 12:04 |
Bmagic |
sounds good to me |
| 12:10 |
Dyrcona |
Oof. Incompatibilities with PHP 7.4 and PHP 8.2... |
| 12:15 |
Dyrcona |
Right. pcurd updates require a transaction... I should maybe make a utility function for that. |
| 12:22 |
|
jvwoolf joined #evergreen |
| 12:50 |
|
redavis joined #evergreen |
| 12:50 |
|
jvwoolf joined #evergreen |
| 13:17 |
Dyrcona |
Bmagic: I made the changes and pushed all of the relevant branches. |
| 13:17 |
Dyrcona |
The custom commits in vars.yml all reference the user/dyrcona/cwmars_custom_rel_3_7_4 in the working repository. |
| 13:34 |
|
smayo joined #evergreen |
| 13:38 |
Dyrcona |
My goodness. Feels like it should be later in the day. |
| 13:49 |
Dyrcona |
"What do a I know? What do I know?" |
| 13:53 |
|
collum joined #evergreen |
| 13:59 |
|
jvwoolf left #evergreen |
| 14:04 |
* Dyrcona |
hunts for pcrud transaction examples through gateway v1. |
| 14:07 |
|
Guest92 joined #evergreen |
| 14:09 |
Dyrcona |
When I do open-ils.pcrud.transaction.begin, I get back a string that appears to be the transaction id, but I don't know how to use that. None of the pcrud examples that I see use it, and if I try the update, I get an error about 'no active transaction.' I'm starting to think it isn't possible with gatevway v1. |
| 14:12 |
berick |
Dyrcona: it has to be within a connected session. gateway v1 can't do it. |
| 14:12 |
Dyrcona |
I see. I probably should find OpenSRF.ClientSession. |
| 14:12 |
Dyrcona |
berick++ I was just getting there. |
| 14:17 |
Dyrcona |
I should probably rename Evergreen\Utils\Session to Evergreen\Utils\AuthSession in case I ever implement OpenSRF\Session. |
| 14:18 |
Dyrcona |
or maybe rename it to Evergreen\AuthSession... I'm still figuring out the API. |
| 14:30 |
Dyrcona |
I also question how useful this code is going to be for its original purpose: Testing changes to Aspen. My Fieldmapper is a lot more sophisticated than what Aspen does. |
| 14:31 |
Dyrcona |
hah! |
| 14:31 |
Dyrcona |
The song that's starting now: "Watch out! You might get what you're after..." Burning Down the House by Talking Heads. |
| 14:31 |
berick |
heh |
| 14:32 |
Dyrcona |
Don't think I'll burn this code. I'll keep it and improve it. |
| 14:35 |
Dyrcona |
berick: Can osrf-http-translator handle connected sessions or do I need websockets? |
| 14:36 |
Dyrcona |
You'd expect that I should know by now.... :) |
| 14:39 |
berick |
Dyrcona: it can, but I suspect it will go away some day |
| 14:40 |
Dyrcona |
berick++ Thanks again! |
| 14:46 |
Dyrcona |
"Track 01" Artist: Unknown.... :) |
| 14:47 |
Dyrcona |
Seems like a comedy song about copyright. And, that sandwiched in between two pieces by Erik Satie. |
| 14:48 |
Dyrcona |
Playing my music on shuffle truly is "random." |
| 14:53 |
Dyrcona |
https://imgflip.com/i/8b3o3w |
| 15:07 |
|
mantis1 left #evergreen |
| 16:20 |
csharp_ |
@blame 2023 |
| 16:20 |
pinesol |
csharp_: (blame [<channel>] [<id>] <who|what> [for <reason>]) -- Blames <who|what> (for <reason>, if given). If <id> is given, uses that specific blame. <channel> is only necessary if the message isn't sent in the channel itself. |
| 16:20 |
csharp_ |
uhhh |
| 16:20 |
Dyrcona |
@blame 12 |
| 16:20 |
pinesol |
Dyrcona: (blame [<channel>] [<id>] <who|what> [for <reason>]) -- Blames <who|what> (for <reason>, if given). If <id> is given, uses that specific blame. <channel> is only necessary if the message isn't sent in the channel itself. |
| 16:20 |
Dyrcona |
@blame get 12 |
| 16:20 |
pinesol |
Dyrcona: Blame #12: "$who is NOT CONNECTED TO THE NETWORK!!!" (added by csharp at 12:31 PM, July 23, 2013) |
| 16:20 |
csharp_ |
pinesol: blame pinesol |
| 16:20 |
pinesol |
csharp_: It's all itself's fault! |
| 16:21 |
berick |
heh |
| 16:21 |
Dyrcona |
@blame "2023" |
| 16:21 |
pinesol |
Dyrcona: (blame [<channel>] [<id>] <who|what> [for <reason>]) -- Blames <who|what> (for <reason>, if given). If <id> is given, uses that specific blame. <channel> is only necessary if the message isn't sent in the channel itself. |
| 16:21 |
csharp_ |
@blame the year 2023\ |
| 16:21 |
pinesol |
csharp_: the year 2023\ was monkeying around too much on the prod servers! |
| 16:21 |
csharp_ |
ah |
| 16:21 |
Dyrcona |
huh... |
| 16:21 |
csharp_ |
pinesol: blame requires text and not an integer I guess |
| 16:21 |
pinesol |
csharp_: requires text and not an integer I guess is NOT CONNECTED TO THE NETWORK!!! |
| 16:22 |
csharp_ |
pinesol: blame someone else |
| 16:22 |
pinesol |
csharp_: Your failure is now complete, someone else. |
| 16:22 |
Dyrcona |
pinesol: blame 2023 |
| 16:22 |
pinesol |
Dyrcona: (blame [<channel>] [<id>] <who|what> [for <reason>]) -- Blames <who|what> (for <reason>, if given). If <id> is given, uses that specific blame. <channel> is only necessary if the message isn't sent in the channel itself. |
| 16:22 |
Dyrcona |
@lbame \2023 |
| 16:22 |
pinesol |
Dyrcona: have you tried local mean solar time for the named city as the reference point? |
| 16:22 |
csharp_ |
pinesol: what I want to blame a number |
| 16:22 |
pinesol |
csharp_: your password is too secure |
| 16:22 |
csharp_ |
s/what/but/ |
| 16:22 |
Dyrcona |
@blame \2023 |
| 16:22 |
pinesol |
Dyrcona: \2023 crafted the perfect SHA-1 collision, breaking Git |
| 16:23 |
csharp_ |
heh |
| 16:23 |
csharp_ |
@dunno add if you type "google" into Google, you'll break the internet |
| 16:23 |
pinesol |
csharp_: The operation succeeded. Dunno #84 added. |
| 16:23 |
Dyrcona |
This year is off to a wild start; Earthquake in Japan and California, plane crash in japan, and gas explosion in South Korea. |
| 16:23 |
csharp_ |
yeah, poor Japan |
| 16:24 |
Dyrcona |
@blame "The Stars" |
| 16:24 |
pinesol |
Dyrcona: I know it was you, The Stars. You broke Dyrcona's heart. You broke Dyrcona's heart. |
| 16:41 |
Bmagic |
does memcached actively delete keys that are expired? Or does it only do that when it's starving for memory? |
| 16:41 |
Bmagic |
I'm trying to craft a zabbix alert for the output of this: memcdump --servers `grep '\-l' /etc/memcached.conf |awk '{print $2}'`|grep "EGWEB\-MAX\-SEARCH\-IP"|wc -l |
| 16:42 |
Dyrcona |
Well, what do you see in your output? |
| 16:42 |
Bmagic |
I'm noticing that there are still over 22k unique IP's, which include the IP block that I blocked last week |
| 16:43 |
Bmagic |
I blocked it at the firewall, so their packets wouldn't/shouldn't have made their slimely way to memcached |
| 16:44 |
Dyrcona |
I suspect memcached only deletes keys when it needs to. |
| 16:44 |
Bmagic |
that's what I'm thinking |
| 16:45 |
Bmagic |
I've been graphing the word count output of that command over the last week and it's not going down much, just up |
| 16:46 |
Bmagic |
which is too bad, because it would seem that unless we restart memcached, it will continue to infinity, making any kind of alert moot |
| 16:46 |
Dyrcona |
You can delete the keys. I forget the exact command syntax, but I have done it in the past. |
| 16:47 |
Dyrcona |
If you're trying to restrict access by IP or something like that, I think memcached is not the best place to find out. I'd monitor Apache or nginx for that. |
| 16:47 |
Bmagic |
that might be what I need to do |
| 16:48 |
Bmagic |
not wanting to restrict per se. Just want to know when we get DDOSed potientially |
| 16:48 |
Bmagic |
like, when the number of unique IP's spikes suddenly, that'd be something I'd want to know about |
| 16:49 |
Bmagic |
I'll look at deleting the keys nightly |
| 16:49 |
Bmagic |
I don't suppose there's an issue with that? As far as Evergreen is concerned? |
| 16:49 |
Dyrcona |
I would think that google would have something for that available to their hosted customers. |
| 16:50 |
Dyrcona |
you can probably ask memcached to delete expired keys. Doing that once a day should be OK. |
| 16:50 |
Bmagic |
this one is on AWS, but same idea. I've looked into different cloudwatch metrics. I haven't found one for the load balancer that meets this criteria exacly. However, I've not spent as much time on that aspect. I'm latched onto memcached because it's there |
| 16:54 |
Dyrcona |
Well, good luck! I'm signing out for the day. |
| 16:54 |
Bmagic |
later! |
| 17:09 |
|
mmorgan left #evergreen |
