| 00:06.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.155) |
| 00:10.47 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 01:01.43 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 01:06.39 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.176) |
| 01:16.15 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 02:06.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.102) |
| 02:35.45 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 02:35.45 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 03:06.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.186) |
| 03:36.59 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 03:37.00 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:06.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.132) |
| 04:13.59 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 04:13.59 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 05:04.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.160) |
| 06:50.02 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.137) |
| 07:05.24 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:26.55 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 09:33.23 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:20b5:ee27:16e9:48b) |
| 09:46.09 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:37.33 | *** join/#asterisk-dev danjenkins_ (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 11:41.48 | *** join/#asterisk-dev vlad_starkov (~vlad_star@93-80-25-36.broadband.corbina.ru) |
| 12:12.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@93-80-25-36.broadband.corbina.ru) |
| 12:20.53 | *** join/#asterisk-dev danjenkins_ (~dan@nat/digium/x-ikjtnjiummmmwlkh) |
| 12:21.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@93-80-25-36.broadband.corbina.ru) |
| 12:34.26 | *** join/#asterisk-dev danjenkins_ (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 12:34.27 | *** join/#asterisk-dev pc-m (~Thunderbi@modemcable094.94-70-69.static.videotron.ca) |
| 12:43.27 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 12:43.27 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 12:55.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@93-80-25-36.broadband.corbina.ru) |
| 13:22.45 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:56.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@93-80-25-36.broadband.corbina.ru) |
| 14:00.24 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:00.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:04.25 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:04.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:19.23 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:19.23 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:26.13 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 14:43.38 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-llmmgtcklgxvrfce) |
| 14:43.39 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:55.28 | *** join/#asterisk-dev danjenkins_ (~dan@nat/digium/x-hwhzqycidzldugyu) |
| 15:04.38 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:10.59 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-whuzeladostunabj) |
| 15:15.18 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:15.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:31.51 | hexanol | I need an ao2_container which is used only to link / unlink objects and apply a callback to all objects in it |
| 15:31.52 | hexanol | I was wondering what was the "best" parameter to create such a container |
| 15:31.52 | hexanol | I tought about "ao2_container_alloc(1, NULL, NULL)" |
| 15:31.52 | hexanol | Is it ok ? Should I use more than 1 bucket ? Should I use a hash function that hash on the pointer address ? |
| 15:31.52 | hexanol | (I already asked this question yesterday but got no answer, so I'm trying another time) |
| 15:33.34 | file | if you don't need to find stuff based on hash then that's fine, although the linkedlist macros would be faster |
| 15:34.36 | mjordan | I'd recommend the linkedlist macros as well - you can still use a linkedlist on ao2 objects if you still want to manage the lifetime of the object via references |
| 15:35.01 | mjordan | ao2_callback, while handy, isn't nearly as fast as the linkedlist macros, and if you don't need to look up the objects by a key field, you really don't need an ao2_container |
| 15:35.08 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:35.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:35.09 | hexanol | ok, I'll consider that |
| 15:35.23 | hexanol | it does make sense to me |
| 16:02.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.167) |
| 16:05.05 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:07.57 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.167) |
| 16:32.01 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.167) |
| 16:44.59 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:52.52 | leedm777 | jrose_atDigium: So, your dlclose() problems. |
| 16:53.26 | leedm777 | Like I was saying, dlclose() isn't required to actually remove the code used by the module. |
| 16:54.12 | leedm777 | I've seem weird cases, like taking the address of an exported function, or using a variable exported by the module, cause the module to be unloadable. |
| 16:55.57 | leedm777 | And by unloadable, I mean that dlclose() on that module will return success. Every. Time. |
| 16:56.14 | leedm777 | That's why we had to remove the while(!dlclose()); patterns from loader.c. |
| 16:57.41 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 16:57.48 | jrose_atDigium | unloadable or un-unloadable? |
| 16:57.59 | jrose_atDigium | In this case, it's that the module can't truly be unloaded. |
| 16:58.39 | jrose_atDigium | It's like... the unload function runs successfully, but the all the symbols remain, and apparently module loading is just looking for symbols rather than for loaded modules by name. |
| 16:58.58 | leedm777 | jrose_atDigium: that's exactly how it works. |
| 16:59.16 | leedm777 | it relies on the dynamic linker. |
| 17:00.12 | leedm777 | When you unload a module from the command line, Asterisk will run the unload_module() function and call dlclose(). |
| 17:00.31 | leedm777 | dlclose() may or may not remove the symbols, for whatever reasons it sees fit. |
| 17:01.47 | jrose_atDigium | Yeah, so the problem makes sense. It's just difficult for me to solve right now without doing something elaborate like making res_mwi_external provide an installable API or something instead of providing global symbols. |
| 17:02.45 | leedm777 | jrose_atDigium: I would prefer to fix the loader so that it's aware of these sorts of dependencies. |
| 17:03.04 | jrose_atDigium | mjordan was suggesting that if it couldn't be dealt with simply by changing the module flags that a big loader fixing project would need to be done at some point. |
| 17:03.07 | mjordan | I concur with leedm777 - we know we're going to need to do it for res_pjsip and other portions of ARI as well |
| 17:03.32 | leedm777 | Yeah. I bet all the PJSIP and ARI modules have similar behavior. We just haven't noticed it. |
| 17:03.51 | mjordan | res_pjsip just made itself basically unloadable |
| 17:04.08 | file | yup |
| 17:04.09 | mjordan | but in the long run, we're going to need to fix that |
| 17:04.23 | leedm777 | glances over at https://wiki.asterisk.org/wiki/x/WQifAQ |
| 17:06.15 | *** join/#asterisk-dev danjenkins_ (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 17:08.09 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 17:09.37 | mjordan | leedm777: \o/ |
| 17:10.40 | danjenkins | i wass talking to file earlier about how i unloaded a pjsip outbound registrations module but then wasnt allowed to load it again :( |
| 17:11.07 | mjordan | leedm777: excellent reference to the unused lavatory in the basement of the planning office |
| 17:11.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.228) |
| 17:11.36 | mjordan | danjenkins: that's a feature. You didn't really want to register again, did you? :-) |
| 17:11.46 | file | danjenkins, yeah I think that's a PJSIP-ism... not our module loader |
| 17:11.51 | danjenkins | nooooooo mjordan ;) |
| 17:12.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.228) |
| 17:13.12 | mjordan | leedm777: the one thing that could be difficult is completely removing the module priorities. For example, chan_sip *can* use app_voicemail, but it doesn't have to. It's a weak dependency, but you still want app_voicemail to load before chan_sip if it is being used |
| 17:13.38 | leedm777 | mjordan: then that would be <use type="optional"> |
| 17:14.01 | mjordan | we're going to have a lot of tags. |
| 17:15.05 | *** part/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 17:15.28 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-hmikdlroeuulioed) |
| 17:25.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.134) |
| 17:40.57 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.228) |
| 17:51.38 | Qwell | leedm777: Can we get rid of optional API too?! |
| 17:52.08 | leedm777 | Qwell: Probably not. Keep hoping, though. |
| 17:53.18 | file | leedm777, please? : |
| 17:53.19 | file | :( |
| 17:53.29 | Qwell | file: You have the powar! |
| 17:53.45 | file | Qwell, I choose throwing a grenade at media formats |
| 18:04.58 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 18:09.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.201) |
| 18:35.55 | *** join/#asterisk-dev danjenkins_ (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 18:39.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.102) |
| 18:48.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.136) |
| 19:01.30 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 19:27.34 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 19:48.33 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.102) |
| 19:55.56 | opticron | so I'm looking at ASTERISK-23051 in trying to add back in variables on origination and at the moment, I can only see two paths forward that could maintain ARI origination as a one-step process: |
| 19:56.55 | opticron | 1) Add the body method back in, but manually parse all query parameters (high duplication of code and possibility of desync between query and body parsing) |
| 19:57.16 | opticron | 2) Make variables a string with a defined format and parse variables from that |
| 19:58.09 | opticron | I strongly prefer 2 over 1 and neither is good |
| 19:59.28 | opticron | the biggest benefit of #1 is that it could be made transparent to the user of the API |
| 20:04.24 | mjordan | Then #1 is probably the correct option |
| 20:04.54 | mjordan | At the end of the day, experience of the user of the API trumps the vast majority of other concerns. The fact that we can autogenerate parsing in most places is nice, but that tool shouldn't dictate the API |
| 20:05.04 | opticron | fair enough |
| 20:05.30 | mjordan | I would write up a proposal for #1 and how you'd go about implementing it before writing too much code |
| 20:05.56 | mjordan | also, if anyone would like to poke at https://reviewboard.asterisk.org/r/3107/ one more time, that'd be appreciated ;-) |
| 20:06.14 | mjordan | opticron: and it may be worthwhile to ask that question on the -dev or -app-dev list. |
| 20:09.09 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-189-174.kc.res.rr.com) |
| 20:41.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.102) |
| 21:00.48 | pabelanger | mjordan, I'm 99% sure this is the issue I am having: DEBUG_THREADS |
| 21:00.49 | pabelanger | err |
| 21:00.56 | pabelanger | https://issues.asterisk.org/jira/browse/ASTERISK-21317 |
| 21:02.39 | mjordan | pabelanger: that issue has nothing to do with DEBUG_THREADS |
| 21:03.34 | pabelanger | no |
| 21:03.39 | mjordan | or a deadlock, for that matter |
| 21:03.42 | pabelanger | debug_treads was a typo |
| 21:03.49 | pabelanger | I actually think there is a lock |
| 21:03.56 | mjordan | there's no evidence of that in the issue |
| 21:03.58 | pabelanger | right |
| 21:04.01 | pabelanger | that is why I asked |
| 21:04.04 | mjordan | k. |
| 21:29.00 | *** join/#asterisk-dev terryw (~otherwise@172.56.11.199) |
| 21:31.53 | *** join/#asterisk-dev dfighter (~someone@arcemu/staff/dfighter) |
| 21:51.36 | blitzrage | confusion abounds! |
| 21:51.43 | putnopvut | or does it! |
| 21:55.44 | opticron | maybe! |
| 22:00.08 | jsmith | blitzrage: Well, that's because you're aroung :-p |
| 22:00.12 | jsmith | around, that is :-p |
| 22:00.21 | jsmith | blitzrage: See, you're confusing my typing already |
| 22:24.42 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-llmmgtcklgxvrfce) |
| 22:26.07 | *** join/#asterisk-dev Ta^3 (~tacvbo@fixed-203-252-140.iusacell.net) |
| 23:40.57 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:43.46 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-whuzeladostunabj) |