| 00:52.20 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-uohajugtyhjarhcn) |
| 00:54.39 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xdboojsipgiecpdh) |
| 00:54.39 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:08.15 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-orgpaezeufvspgbz) |
| 01:24.56 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:24.57 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:43.17 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-uohajugtyhjarhcn) |
| 02:43.25 | *** join/#asterisk-dev drmessano^ (~nonya@pdpc/supporter/active/drmessano) |
| 03:03.18 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 03:03.18 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 05:49.00 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 06:58.17 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 06:58.17 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 08:07.04 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 08:07.05 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 09:43.42 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:5a2:40e2:1beb:810a) |
| 10:28.05 | *** join/#asterisk-dev hehol (~Adium@ip-78-94-14-150.unitymediagroup.de) |
| 11:03.00 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 11:26.36 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:38.59 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-68-43-254-216.hsd1.mi.comcast.net) |
| 12:26.30 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 12:47.44 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 12:49.52 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 12:55.28 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-tgokykfzpszpeplu) |
| 13:34.34 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:34.34 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:38.41 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ljopvbknzuihjzrx) |
| 13:38.41 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:39.19 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:39.19 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:51.26 | pabelanger | for some odd reason, I don't think starpy supports reconnects if it loses connection to asterisk |
| 13:51.40 | pabelanger | I know the twisted protocol supports it, but don't think we set it up in starpy |
| 14:04.31 | mjordan | pabelanger: I'd be fine with that so long as it was optional |
| 14:07.08 | pabelanger | mjordan: yup, trying to figure out the best way to expose it |
| 14:07.17 | pabelanger | clientConnectionLost has some cool features |
| 14:11.05 | mjordan | yup |
| 14:11.37 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 14:15.25 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-ruatfwjeohurjimc) |
| 14:15.32 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-ruatfwjeohurjimc) |
| 14:17.11 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-ruatfwjeohurjimc) |
| 14:18.42 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:18.42 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:20.17 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:20.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:42.28 | file | the hills are alive... with the sound of zombies |
| 14:42.50 | mjordan | all they want to do is eat your brains |
| 14:42.55 | mjordan | it's not unreasonable |
| 14:43.02 | mjordan | I mean, they're not going to eat your eyes |
| 14:43.05 | putnopvut | My brain is very tasty |
| 14:43.22 | file | putnopvut, so that leak... |
| 14:43.24 | putnopvut | I would be a good diversion in a zombie apocalypse |
| 14:43.37 | putnopvut | file: yessss |
| 14:43.47 | file | putnopvut, I *think* I narrowed it down to something to do with the digest authenticator |
| 14:44.13 | Corydon76-work | mjordan: I know while I was at Digium, we never took this extraordinary step, though we contemplated it several times: http://www.postgresql.org/message-id/14040.1364490185@sss.pgh.pa.us |
| 14:44.15 | putnopvut | So the initial fix you put in didn't do the trick? |
| 14:44.22 | file | no, that was only part of it |
| 14:44.25 | putnopvut | ah |
| 14:44.29 | file | this is something with pjsip |
| 14:44.38 | file | it seems as though when it challenges it leaks 4 kilobytes |
| 14:44.45 | putnopvut | ouch |
| 14:44.59 | putnopvut | You think the leak may be somewhere in the pjsip code? |
| 14:45.24 | file | or the way we are going about things |
| 14:45.50 | mjordan | Corydon76-work: interesting. |
| 14:46.43 | Corydon76-work | We always considered that the window between committing the fix and getting new downloads out to just be a couple hours, so the potential window wasn't that great... |
| 14:46.44 | putnopvut | file: are you thinking that maybe our usage of thread-local storage is the culprit? |
| 14:46.55 | file | putnopvut, I don't have an idea at the moment |
| 14:46.59 | putnopvut | mkay |
| 14:47.01 | mjordan | not sure it was warranted in this case, but I can see that as possibly being needed |
| 14:48.38 | file | putnopvut, all I know is unload res_sip_authenticator_digest.so and memory usage stays constant for my phones that are registering... load it and up it goes for each challenge |
| 14:48.44 | Corydon76-work | I thought it was sufficiently interesting to merit consideration in the future |
| 14:48.58 | putnopvut | file: gotcha. I'll have a look and see if I can see what's up. |
| 15:12.13 | pabelanger | mjordan: NoOp,foo|bar ? |
| 15:12.19 | pabelanger | where can you use that? |
| 15:13.33 | putnopvut | in Asterisk |
| 15:13.57 | Qwell | pabelanger: extensions.conf - exten => 1234,1,SomeApp,arg1|arg2 |
| 15:14.15 | pabelanger | serious? |
| 15:14.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:15.11 | *** join/#asterisk-dev spditner (~simon@206-248-134-4.dsl.teksavvy.com) |
| 15:16.31 | *** join/#asterisk-dev outtolunc (~me@50-193-41-213-static.hfc.comcastbusiness.net) |
| 15:51.18 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:8d50:520a:123a:992f) |
| 16:04.16 | mjordan | elguero: I don't think opticron is watching the commit IRC. :-) |
| 16:05.13 | elguero | mjordan: gotcha...looks like he has already done a lot of work |
| 16:05.35 | elguero | I will have to check out that branch |
| 16:06.52 | opticron | <_< |
| 16:06.54 | opticron | >_> |
| 16:07.21 | opticron | be aware of the phrase "entirely untested" |
| 16:07.32 | opticron | it compiles and that's all I'm willing to promise |
| 16:07.49 | file | I *could* test it |
| 16:08.22 | elguero | :-) I will... I was thinking I could help out with testing and debugging... that is where I was left off in my attempts to add IPv6 to IAX2 |
| 16:14.29 | file | it does not work |
| 16:15.23 | file | ast_netsock_bind only binds to IPv4 |
| 17:03.15 | file | I would like it known that putnopvut gets a gold star today! |
| 17:03.27 | putnopvut | yay! |
| 17:03.32 | putnopvut | why? |
| 17:03.34 | sruffell | wow…congrats man! |
| 17:03.46 | file | it's made of chocolate. |
| 17:03.57 | file | putnopvut, for fixing a memory leak! |
| 17:04.05 | putnopvut | one that I caused! WOO! |
| 17:04.36 | file | it comes full circle |
| 17:06.04 | *** join/#asterisk-dev ibk (~quassel@108.161.133.32) |
| 17:11.53 | file | putnopvut, all better |
| 17:12.55 | putnopvut | good good |
| 17:52.17 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 18:06.14 | file | soft kitty warm kitty little ball of fur |
| 18:06.37 | leifmadsen | +1 |
| 18:37.07 | leedm777 | opticron mjordan: so, about subscribing to cache updates for a single channel... |
| 18:37.25 | opticron | feels like a stasis_caching_message_router is in order |
| 18:38.59 | leedm777 | possibly. |
| 18:39.44 | opticron | but then that starts getting into the internals of the caching system since you'd need the id getter function that the caching topic creator supplied |
| 18:40.29 | leedm777 | yeah, a content based router, essentially. |
| 18:40.54 | opticron | that function is stored in the caching topic anyway, so that's fine |
| 18:42.22 | leedm777 | interesting. basically, for a caching topic, subscribe to a particular id. |
| 18:42.41 | opticron | though if I wanted to do that with channel snapshots, I'd have to create a snapshot from the channel, and then pass that into the hypothetical content-based router so it can use the get_id function on it and create the subscription |
| 18:43.10 | leedm777 | not if you know the id string. |
| 18:43.15 | leedm777 | you could just use that directly. |
| 18:43.29 | opticron | I was thinking about that as well |
| 18:44.03 | opticron | in some cases, the ID string is generated dynamically, but I think that should work and make sense in most cases |
| 18:45.18 | leedm777 | takes a look |
| 18:45.33 | opticron | mwi and device state come to mind |
| 18:45.54 | opticron | with MWI, it's box@context for the ID string |
| 18:46.21 | opticron | and there are special rules for the context portion (if it's blank, it's really 'default') |
| 18:47.30 | leedm777 | Still, though, it's a consistent identifier. Should work well enough, even then. |
| 18:47.43 | opticron | I guess I'll work toward that |
| 18:49.09 | leedm777 | wonders aloud if there's a better way, not knowing what that better way might be. |
| 18:50.54 | opticron | considered another terrible way to manage this kind of functionality, but won't mention it |
| 18:52.19 | leedm777 | opticron: so here's a crazy thought. what if we split the cache from the caching topic? |
| 18:52.36 | leedm777 | wonders that that's the terrible way opticron was thinking |
| 18:52.53 | opticron | a single caching topic for every single channel :) |
| 18:53.08 | leedm777 | yes, but a single cache for all the snapshots. |
| 18:53.41 | leedm777 | the per-channel caching topics can still forward to a single all-channels-cached topic |
| 18:54.02 | leedm777 | and querying the cache is still basically the same as it is now. |
| 18:58.01 | file | caches the cache |
| 18:59.17 | leedm777 | caches file |
| 18:59.35 | Marquis42 | Now are you caching the cache or the cache of the cache? |
| 20:03.13 | *** join/#asterisk-dev wrbishop (~chatzilla@wrbishop.com) |
| 20:56.44 | snuff-home | lookin for lil help with new ast config framework/sorcery.. getting lovely segfault when trying to load doco |
| 20:58.01 | Qwell | snuff-home: If you're on trunk, I would recommend reverting r384452, for now. |
| 20:59.21 | snuff-home | i'm on 384406 |
| 20:59.39 | Qwell | Oh, that's totally not my fault then. |
| 21:00.40 | snuff-home | getting this sort of thing.. [Mar 31 11:29:01] WARNING[2549]: config_options.c:916 xmldoc_update_config_type: Cannot update type '(null)' in module 'res_sip' because it has no existing documentation! |
| 21:00.40 | snuff-home | Segmentation fault (core dumped) |
| 21:08.47 | snuff-home | no ideas? :( |
| 21:10.21 | putnopvut | snuff-home: I see that error but get no segfault on startup. It may be unrelated to your segfault |
| 21:11.21 | snuff-home | yes u will see that error on startup.. cause atm there is no doco to read in res_sip.. once u add some boom :) |
| 21:12.46 | snuff-home | http://pastebin.com/J5ru8q3e |
| 21:13.11 | putnopvut | Ah I hadn't realized you had added some. |
| 21:13.26 | snuff-home | part of my other todo / help stuff ;) |
| 21:13.41 | putnopvut | can you pastebin a diff? |
| 21:18.19 | snuff-home | http://pastebin.ca/2347221 |
| 21:18.37 | snuff-home | as u can see most is 'placeholder' for descriptions as i get to them |
| 21:18.49 | putnopvut | righty-right |
| 21:20.03 | snuff-home | most of the 'setup' work for sorcery stuff seems to be inside res/res_sip/include/sip_private.h (i think its called) |
| 21:24.03 | snuff-home | tried to follow something similar to chan_motif.. since sorcey is like a more refined object of the 'ast config framework' |
| 21:30.12 | putnopvut | snuff-home: well, I'm at a loss right now. It specifically appears to be a problem when iterating over the "type" field for an "auth". It may be due to the fact that all of the documentation you have is grouped under a single config object instead of having different config objects for endpoints, auth, identify, etc. |
| 21:32.37 | file | adding documentation to sorcery like that has not been attempted/verified to work yet |
| 21:33.04 | file | so I'm not overly surprised at the crash |
| 21:34.00 | snuff-home | :( |
| 21:48.37 | *** part/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 21:52.37 | mjordan | snuff-home: is that pb the full diff/ |
| 21:53.01 | snuff-home | yes.. i know i'm probably missing something |
| 21:57.33 | mjordan | snuff-home: whoops. Nope, you're not. |
| 21:58.18 | snuff-home | tried making 'type' diff on each lot.. aka 'atype/btype' etc incase didn't like a clash or something |
| 21:58.26 | snuff-home | didn't help |
| 21:58.51 | mjordan | nope. Sorcery isn't registering the aco_type name |
| 21:59.03 | mjordan | which means that iterating over the aco_types and trying to do name comparisons == explosion |
| 21:59.17 | snuff-home | k good to know |
| 21:59.38 | mjordan | I think I know where it needs to be fixed, but I'm not 100% |
| 22:00.02 | mjordan | snuff-home: line 487 of sorcery.c |
| 22:00.11 | mjordan | object_type->type.name = "FOO"; |
| 22:00.21 | mjordan | that should keep it from blowing up, although your documentation won't work |
| 22:01.29 | mjordan | pretty sure if you set it to object_type->type.name = name; it will just work |
| 22:01.46 | mjordan | er, object_type->type.name = type; |
| 22:02.59 | snuff-home | adding that last line.. meant it actually started up :) |
| 22:03.26 | mjordan | well, that's good. Assignment actually won't work since you need to do a string copy there. |
| 22:04.36 | mjordan | ponders for a bit. |
| 22:04.48 | mjordan | I'm not sure we ever really thought that an aco_type wouldn't be statically defined. |
| 22:56.56 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ljopvbknzuihjzrx) |
| 23:17.18 | *** join/#asterisk-dev moy_ (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 23:24.36 | newtonr | elguero: just tried to apply your patch for ASTERISK-21305 , compilation fails with "app_meetme.c: In function ?recordthread?: |
| 23:24.37 | newtonr | app_meetme.c:5168:32: error: expected ?;? before ?{? token" |
| 23:25.38 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 23:37.20 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |