| 01:21.13 | *** join/#utah infobot (ibot@rikers.org) |
| 01:21.13 | *** topic/#utah is Utah-related discussion including user groups | logs @ http://infobot.rikers.org/%23utah/ | See also ##lds | To combat spam, you must register with NickServ if you wish to speak. This may or may not be temporary. |
| 01:21.13 | *** mode/#utah [+o infobot] by ChanServ |
| 02:59.40 | klys | ~slashdot |
| 03:08.02 | klys | AI Will Create New Jobs But Skills Must Shift, Say Tech Giants - Germany Says Government Network Was Breached - https://tech.slashdot.org/story/18/03/01/016238/youtubes-new-moderators-mistakenly-pull-right-wing-channels - Even With Double the Subscribers, Spotify Says Apple Will Always Have an Edge Owning the App Store - AI Cheats at Old Atari Games By Finding Unknown Bugs in the Code - Best Buy To Close All 250 of Its Smaller, Mobile Phone Stores - D |
| 04:12.45 | *** join/#utah cstead (sid219570@gateway/web/irccloud.com/x-ukfcnlfadhlhowbf) |
| 04:17.24 | *** join/#utah mindjuju (sid66062@gateway/web/irccloud.com/x-cponzjgdkhtdyvvg) |
| 04:18.58 | *** join/#utah yukaia (sid110254@gateway/web/irccloud.com/x-kenhblyqcgpqolko) |
| 05:40.06 | *** join/#utah tiwula (~lane@174-23-5-207.slkc.qwest.net) |
| 06:55.35 | *** join/#utah Bloodythorn (~Bloodytho@c-76-27-46-75.hsd1.ut.comcast.net) |
| 15:23.52 | *** join/#utah BitBandit (~BitBandit@50-198-187-221-static.hfc.comcastbusiness.net) |
| 15:47.09 | TodPunk | jfindlay: because more information is good. Knowing how both sides of the interview feel gives them leverage to understand and provide feedback neither party would normally receive. |
| 15:48.34 | TodPunk | For instance, I got turned down for a job last year and the recruiter said the company loved me, they just thought I would be bored (this is true and they are accurate in their assessment of me, but I don't think they should make that decision for me since I mentioned to them I am usually not challenged for long in programming positions, and that's fine with me) |
| 16:16.57 | *** join/#utah braxtron (~princessf@216.160.248.178) |
| 16:37.09 | *** join/#utah tiwula (~lane@70.89.246.241-Busname-UT.hfc.comcastbusiness.net) |
| 17:28.21 | *** join/#utah josephscott (~josephsco@50.225.82.170) |
| 17:43.38 | *** join/#utah SunSparc (~jonathan@45.56.57.85) |
| 17:51.40 | youtah | Any of you pika guru's with Rabbit MQ? |
| 18:05.52 | frostyfrog | youtah: I've toyed with it a little. It was great for distributing my video transcoding :3 |
| 18:07.00 | frostyfrog | likes the UI, personally. Much easier than learning all the CLI stuff. |
| 18:07.45 | youtah | part of one of my tests, the network connection goes away |
| 18:07.55 | youtah | and so the consumer/queue freaks out |
| 18:08.05 | youtah | That's the super long story short |
| 18:09.24 | frostyfrog | Sounds like the socket gets dropped, and there for, the consumer runs just fine but the queue thinks that the consumer is now lost, so it adds it back to the queue. Sound about right? |
| 18:09.45 | youtah | yup |
| 18:09.49 | youtah | which I am doing on purpose |
| 18:11.39 | frostyfrog | Well, it's one thing to drop the hard network connection, and it's another to drop a socket. By default, TCP sockets should allow for multiple seconds of lost packets when the link is broken (so long as the computer doesn't detect it has no network) |
| 18:13.10 | youtah | which is exactly what happens (on purpose) because we factory default the Device under test |
| 18:13.32 | frostyfrog | Now, if you're fine with potentially losing jobs, you could completely pull it off the queue. If you want some possibility of not losing data, you could read from queue A, put it on queue B stating who's working on it, then pull it off of queue A |
| 18:26.05 | SunSparc | exit |
| 18:27.07 | frostyfrog | ^D |
| 18:31.10 | TodPunk | youtah: you need to detect socket closing and re-open it, probably via exception handling unless pika does connect_ex() |
| 18:31.30 | TodPunk | In which case I have no idea how it's expected to be handled, but this is fairly common in network programming so I'm sure there's a way |
| 18:34.09 | TodPunk | youtah: apparently the exception pika throws is a "pika.exceptions.ConnectionClosed " |
| 18:42.27 | youtah | Yup |
| 18:42.33 | youtah | that's exactly what i am getting |
| 18:42.45 | youtah | pika.exceptions.ConnectionClosed: (-1, "error(104, 'Connection reset by peer')") |
| 18:43.36 | spangborn | I prefer Connection reset by beer |
| 18:44.07 | youtah | that happens sometimes |
| 20:26.09 | Migs | https://i.imgur.com/wH3FVcj.jpg |
| 20:27.41 | BigBen212 | Migs: before or after they eat tide pods? |
| 20:29.41 | Migs | during! |
| 20:43.19 | programmerq | dry ice challenge: https://www.youtube.com/watch?v=ihmNEChDU2A |
| 21:30.41 | Migs | I'm scared |
| 21:53.07 | programmerq | Molasses challenge: https://youtu.be/uT-ZTtUc5T4?t=13 |
