| 00:05.50 | auntie | mmm... for some reason, the twisted processEnded() override isn't being called, which prevents _stop_deferred from being raised |
| 00:06.51 | auntie | also, there is suspicious vestigal code in __process_stopped that raises _stop_deferred, but __process_stopped isn't used anywhere |
| 00:07.43 | auntie | For now, I have a hack that fixes the testsuite hanging for me. I'll look into why processEnded() isn't working, and also what happened to __process_stopped |
| 01:09.39 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 01:42.13 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 02:53.58 | *** join/#asterisk-dev mjordan (~mjordan@199.119.131.162) |
| 02:53.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:53.57 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 04:53.57 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 05:05.52 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 05:24.51 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 05:24.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:45.35 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 06:54.55 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 07:35.19 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:35.19 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:50.56 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:11.41 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:52.16 | *** join/#asterisk-dev dustinm (~dustinm@105.ip-167-114-152.net) |
| 08:59.47 | *** join/#asterisk-dev oej (~oej@2.69.245.72.mobile.tre.se) |
| 08:59.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:08.53 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 09:08.53 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Hell hath frozen over: Asterisk is moving to Git -=- Follow on Twitter at @AsteriskDev |
| 10:00.26 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 10:23.28 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 11:51.12 | *** join/#asterisk-dev hehol (~hehol@locanet.dyndns.org) |
| 12:14.33 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:17.15 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-vhxtvxalugnlwyxf) |
| 12:48.48 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 12:56.10 | *** join/#asterisk-dev mjordan (~mjordan@104-145-12-182.dedicated.allstream.net) |
| 12:56.10 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:18.49 | mjordan | file: for https://gerrit.asterisk.org/#/c/306 - is this a general problem with callbacks? |
| 13:19.10 | mjordan | ah, nm. |
| 13:19.12 | file | yes, but it was already fixed in res_pjsip itself for requests sent through that |
| 13:19.27 | mjordan | Only res_pjsip_outbound_registration calls pjsip_regc_create |
| 13:19.33 | file | right |
| 13:19.42 | mjordan | should we avoid using that? |
| 13:20.01 | file | it would require rearchitecting the module |
| 13:20.05 | file | and implementing it ourselves |
| 13:20.15 | mjordan | hm. |
| 13:20.19 | mjordan | that seems annoying. |
| 13:20.35 | mjordan | it is disappointing that it calls the callback even when something has failed |
| 13:20.46 | file | yes |
| 13:21.33 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 13:28.27 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-irdlbhlvvrvnquhk) |
| 13:43.16 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 14:01.20 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 14:02.53 | *** join/#asterisk-dev spditner (~simon@69-165-156-137.dsl.teksavvy.com) |
| 14:03.51 | *** join/#asterisk-dev Corydon76 (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 14:03.51 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 14:05.59 | mjordan | so, here's something interesitng |
| 14:06.19 | mjordan | some Asterisk systems have a tendency to generate a lot of hints... |
| 14:06.24 | mjordan | as in, over 20k |
| 14:06.35 | mjordan | we aren't very efficient with the ao2_containers in the pbx core |
| 14:07.02 | mjordan | and with 20k hints, the ao2 container with 563 buckets gets a few collisions. |
| 14:07.09 | Marquis42 | mjordan: That seems... less than ideal. |
| 14:07.13 | Corydon76 | Heh |
| 14:07.43 | mjordan | It'll be a chunk of memory to allocate something with enough buckets for that kind of number of hints |
| 14:07.50 | Corydon76 | Sounds like we could do with code that regenerates the container when the size exceeds a certain number |
| 14:09.11 | Corydon76 | 2n, perhaps? |
| 14:09.50 | mjordan | possibly |
| 14:10.03 | mjordan | what caused me to look at this was some extremely long reload times - several minutes |
| 14:10.19 | mjordan | I'm not sure if regenerating the container would just re-introduce some of the problems, but it may be worth poking at that |
| 14:11.25 | file | where is the time spent? |
| 14:11.44 | file | adding the hints to the linked list in each bucket? |
| 14:12.15 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:12.15 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:12.19 | mjordan | file: well, originally, no |
| 14:12.31 | mjordan | we have two containers, hints and devices => hints |
| 14:12.41 | mjordan | the devices => hints is nonunique, in that a single device can map to many hints |
| 14:12.47 | file | aye |
| 14:12.48 | mjordan | however, when we dispose of a hint, we had no way to find its devices |
| 14:12.55 | mjordan | this caused an ao2_callback on the entire hintdevices container |
| 14:13.01 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-idjfmupjjengeadj) |
| 14:13.02 | mjordan | during a reload, that took 5 minutes |
| 14:13.26 | mjordan | caching the devices associated with a hint on the ast_hint (just the name) let me do an actual decent lookup on the container |
| 14:13.35 | mjordan | that shaved it down to about 45 seconds |
| 14:13.52 | mjordan | so now I'm just looking at what else is messy, and the number of collisions was sort of an obvious next point |
| 14:14.32 | file | I think pbx.c in general is an answer to what else is messy |
| 14:14.46 | mjordan | truth |
| 14:16.07 | mjordan | file: but yes, from what I can tell right now from just looking at thread backtrace captures, we spend a lot of time walking the container trying to insert/lookup items |
| 14:16.12 | mjordan | in the hints container |
| 14:16.14 | file | nods |
| 14:16.22 | mjordan | granted, 20k hints is kind of excessive, but it's not impossible |
| 14:16.51 | file | it adds up, I ran some tests for fun when I made res_sorcery_config intelligent about bucket size |
| 14:17.04 | file | you can shave it down to a near constant |
| 14:17.08 | mjordan | yeah |
| 14:17.20 | mjordan | the problem is I can't make those containers intellligent |
| 14:17.23 | mjordan | intelligent even |
| 14:17.55 | mjordan | so I'd have to do what Corydon suggested |
| 14:18.23 | mjordan | look to see the number of items in the container, and if it exceeds a certain amount, make a temp container that's larger, copy the elements over, and set the pointer to the new container |
| 14:18.28 | mjordan | but that copy might be pretty expensive |
| 14:20.14 | Corydon76 | Oh, it definitely will be expensive. Maybe we only do that on a reload. |
| 14:20.53 | mjordan | I'll play around with it and see what happens |
| 14:21.00 | Corydon76 | We'd be dumping all the hints anyway; might as well rebuild it more efficiently |
| 14:22.33 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 14:23.31 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-cfeqvnooporvksmc) |
| 14:23.31 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:27.25 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 14:27.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:39.54 | mjordan | so here's something interesting. We have a particular container of extension state callbacks in pbx.c that stores extension state callbacks *not* associated with a hint - that is, there is no context/extension associated with the extension state callback. |
| 14:40.01 | mjordan | does anyone know how that can be generated? |
| 14:40.27 | mjordan | Ah |
| 14:40.29 | mjordan | app_queue |
| 14:40.31 | mjordan | nevermind! |
| 14:41.33 | file | it's app_queue, in the core, with the knife |
| 14:42.45 | mjordan | yeah |
| 14:42.51 | mjordan | tis a strange ao2_container, bucket size of 1 |
| 14:42.57 | mjordan | but there's only app_queue and manager that use it |
| 14:43.00 | mjordan | so no big worries |
| 14:47.41 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 14:55.05 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 15:00.32 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:11.39 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-vifwhshbjobwtnxj) |
| 15:25.37 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 15:25.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:28.53 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 15:58.25 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 15:59.57 | mjordan | I wish 11 had ast_vector |
| 16:00.16 | file | mjordan, you could... erm... backport |
| 16:00.26 | gtjoseph | yeah, it's all macros isn't it? |
| 16:00.33 | file | I believe so, yes |
| 16:01.03 | mjordan | it would make https://gerrit.asterisk.org/#/c/312 much easier |
| 16:01.06 | mjordan | to backport to 11 |
| 16:01.11 | mjordan | which you may not be able to see... |
| 16:01.22 | file | I know what it is, but not the contents |
| 16:01.49 | mjordan | there it goes |
| 16:01.59 | mjordan | I'm using AST_VECTOR to store char *s |
| 16:02.01 | gtjoseph | git checkout 11 && git checkout 13 -- include/asterisk/vector.h && echo :) |
| 16:02.10 | mjordan | lol |
| 16:02.28 | mjordan | it would be nice to have it, as it is a lot easier to use vectors for certain things over linked lists |
| 16:02.44 | mjordan | that's why I used it for that patch ^^^, as that way I didn't have to wrap a char * in another struct |
| 16:03.17 | file | yup |
| 16:04.48 | mjordan | huh |
| 16:04.55 | mjordan | I thought we had unit tests for vector somewhere |
| 16:06.54 | file | apparently not |
| 16:07.37 | file | mjordan, 312 is not visible |
| 16:07.45 | file | the 13 version of it |
| 16:08.09 | mjordan | er |
| 16:08.24 | mjordan | ah |
| 16:08.27 | mjordan | ready versus publish |
| 16:14.00 | mjordan | file: at some point, we should probably write some for that. |
| 16:14.10 | file | mjordan, aren't you going to be on a plane soon? |
| 16:16.44 | mjordan | nope, friday |
| 16:17.22 | file | that's tomorrow, that's soon enough |
| 16:17.27 | mjordan | true |
| 16:17.38 | mjordan | bah |
| 16:17.48 | mjordan | Asterisk 11 is the new Asterisk 1.8 |
| 16:47.12 | leifmadsen | Asterisk 14 is the new Asterisk 13 because we skipped that version right? |
| 16:47.15 | leifmadsen | ducks |
| 16:48.05 | zerohalo | funny how that was such a non-issue in the end |
| 16:48.12 | leifmadsen | yep |
| 16:48.18 | leifmadsen | we spent far too much time talking about it |
| 16:48.25 | leifmadsen | mjordan, should have put his foot down sooner :D |
| 16:48.31 | zerohalo | indeed |
| 16:48.43 | mjordan | bike shedding |
| 16:48.48 | leifmadsen | although Qwell's comment was totally worth the wait |
| 16:49.20 | leifmadsen | mjordan, that analogy is no good, because colours really do matter for marketing purposes |
| 16:49.22 | leifmadsen | :D |
| 16:49.27 | mjordan | lol |
| 17:02.08 | file | mjordan, there you go |
| 17:02.11 | auntie | What asterisk version string should I use for my new testsuite tests? |
| 17:03.13 | auntie | Also, the testsuite seems to be calculating my version as less than 1.6.0, but I set the version to "13.0.0" |
| 17:04.19 | auntie | wait, I set it all the way to 15.0.0 |
| 17:04.31 | auntie | for the forced-version string |
| 17:10.36 | auntie | ah, actually... the forced-version string isn't even used. it's getting the version for my asterisk binary |
| 17:10.57 | auntie | which currently is an "unknown and unsupported version" |
| 17:11.17 | Corydon76 | mjordan: I prefer when bikes don't shed. It's impossible to get that stuff out of the carpet. |
| 17:18.28 | auntie | the oreily book has a huge, several page explanation about just the asterisk version scheme, and how it came full circle in the end ;) |
| 17:37.51 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 17:42.49 | leifmadsen | :) |
| 17:47.49 | *** join/#asterisk-dev spditner (~simon@69-165-156-137.dsl.teksavvy.com) |
| 17:49.44 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 17:49.44 | *** join/#asterisk-dev Corydon76 (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 17:49.44 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 17:49.44 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 17:49.44 | *** mode/#asterisk-dev [+o Corydon76] by hobana.freenode.net |
| 17:55.40 | auntie | wooo, with the version set, my tests pass without having to kill asterisk manually |
| 17:55.58 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-rbqqpqbrqssavdra) |
| 18:05.59 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 18:37.04 | file | hrm |
| 18:59.59 | file | well huh |
| 19:00.59 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:01.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:04.08 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 19:04.12 | file | coreyfarrell, the master version of your ARI dependencies change broke the build |
| 19:04.43 | file | specifically the addition of ".$(1).moduleinfo: $(2)" to Makefile.moddir_rules |
| 19:22.33 | coreyfarrell | file: I'm checking it out now |
| 19:22.59 | file | coreyfarrell, seems to be from the addons directory |
| 19:23.47 | coreyfarrell | thanks, I probably would have tested with the menuselect defaults and found nothing (again) |
| 19:24.15 | file | all I did was a make distclean and then make menuselect, which complained about format_mp3 |
| 19:24.20 | file | and then a build also fails afterwards |
| 19:24.25 | file | Bamboo caught it |
| 19:25.11 | coreyfarrell | oh crap, format_mp3 uses sources that don't exist. :( |
| 19:25.36 | coreyfarrell | don't know why it didn't complain when I tested it though |
| 19:26.08 | coreyfarrell | trying with distclean |
| 19:30.51 | coreyfarrell | file: I just ran: make distclean;./configure --enable-dev-mode; make menuselect, no complaints |
| 19:30.59 | file | in master? |
| 19:31.51 | coreyfarrell | yep, did a git pull first too |
| 19:32.21 | file | my make menuselect does complete but I get no addons section |
| 19:33.03 | coreyfarrell | I'll do 'git clean -fxd' and try again |
| 19:34.18 | coreyfarrell | the error does make sense, I don't understand why I'm not getting it |
| 19:34.53 | file | dunno! |
| 19:36.04 | coreyfarrell | ok that did it |
| 19:36.37 | coreyfarrell | no idea why 'make distclean' would leave something behind, but git clean -fxd made the error happen. |
| 19:40.03 | file | I blame Canada |
| 19:42.40 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-246-193.try.wideopenwest.com) |
| 19:44.34 | coreyfarrell | file: https://gerrit.asterisk.org/320 |
| 19:45.27 | file | nifty |
| 19:45.54 | coreyfarrell | yeah glad wildcard worked.. not sure how else this could be done :) |
| 19:54.27 | mjordan | Gr. Darn you vectors. |
| 19:54.33 | mjordan | Why must you do what you were implemented to do. |
| 20:06.13 | putnopvut | Do what I want, not what the code says! |
| 20:11.21 | mjordan | putnopvut: yeah, some of your suggestions felt like they should work, but at least one does not appear to |
| 20:11.32 | mjordan | putnopvut: for whatever reason, the while loop likes to try to go past the end of the vector |
| 20:11.33 | mjordan | shrugs |
| 20:11.47 | putnopvut | that's weird |
| 20:12.06 | file | blame Canada |
| 20:12.35 | mjordan | file: I do, but I found the chest under my bed |
| 20:12.49 | putnopvut | Like a human chest? |
| 20:13.35 | file | shhhhhhhh |
| 20:15.47 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-syvvcsaqbhjfpqut) |
| 20:21.07 | file | and with that, I can now chill |
| 20:25.35 | Corydon76 | like a villain? |
| 20:37.38 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 20:51.08 | mjordan | putnopvut: I'm surprised we didn't run into 322 sooner |
| 20:51.35 | putnopvut | The dial masquerade fixup code is relatively new |
| 20:51.56 | mjordan | true; I was thinking more of the blonde transfer tests |
| 20:52.25 | putnopvut | I don't think the blond transfer tests will catch this because the transfer target typically answers the call rather than rejecting it. |
| 20:57.37 | mjordan | ah |
| 21:03.06 | mjordan | so, with that patch I have up, a full core reload with 20k or so hints happens in about 2:30 - 2:45. Without, it takes 4:19 |
| 21:03.31 | mjordan | the part that it improves goes from taking 20 - 30 seconds to 120 seconds |
| 21:19.08 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ysnikpdberfdbwxw) |
| 21:37.39 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 21:38.06 | putnopvut | mjordan: Looking at patchset 4, the loop starting at 1164 seems off to me. The vector is shrinking, but i keeps increasing, so you presumably are only inspecting about half of the vector each time. |
| 21:38.47 | putnopvut | At least that's how it appears to me. |
| 21:40.51 | *** join/#asterisk-dev sgriepentrog (~sgriepent@162-239-32-132.lightspeed.brhmal.sbcglobal.net) |
| 21:42.36 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:51.12 | mjordan | hum |
| 21:51.39 | mjordan | putnopvut: I can say the while loop just asserts |
| 21:51.59 | mjordan | putnopvut: I'm not sure the vector current is being decremented how we think |
| 21:53.29 | putnopvut | mjordan: By "vector current" are you talking about the size of the vector? |
| 21:54.03 | putnopvut | Also, kudos to me for breaking out of the comment box on gerrit accidentally. I'd really like it if I could edit the comment. |
| 21:54.20 | mjordan | putnopvut: looking at AST_VECTOR_REMOVE_UNORDERED, vec->elems[__idx] is set to vec->elems[--(vec)->current] |
| 21:54.34 | mjordan | er |
| 21:54.45 | mjordan | I'll bet --(vec)->current doesn't decrement current |
| 21:55.38 | mjordan | yeah, it isn't. |
| 21:55.43 | putnopvut | What does it decrement? |
| 21:55.50 | mjordan | vec |
| 21:55.50 | putnopvut | ugh |
| 21:55.54 | mjordan | yes. |
| 21:55.58 | putnopvut | Why isn't this causing blow-ups everywhere?! |
| 21:56.03 | mjordan | which explains why the vector looked really weird in my crashes. |
| 21:56.11 | mjordan | because you will end up doing something hilarious |
| 21:56.32 | mjordan | or rather... you might. |
| 21:56.44 | mjordan | putnopvut: http://en.cppreference.com/w/c/language/operator_precedence |
| 21:56.59 | mjordan | unless I'm crazy, -- and -> are at the same level of precedence, and that will be evaluated left to right |
| 21:57.12 | putnopvut | Read more closely, prefix decrement comes after -> |
| 21:57.22 | mjordan | ah |
| 21:57.26 | mjordan | yes. |
| 21:57.26 | putnopvut | -> is at precedence 1, and prefix -- is at 2 |
| 21:57.29 | mjordan | SO |
| 21:57.33 | putnopvut | So it is decrementing vec->cur |
| 21:57.35 | mjordan | I still don't know why current wasn't decrementing then. |
| 21:57.42 | mjordan | perhaps, but your while loops asserts |
| 21:57.52 | putnopvut | Where does it assert? |
| 21:57.58 | mjordan | it goes past current |
| 21:58.18 | mjordan | i.e., it does not decrement current, and as a result, we end up reading past the number of elements in the vector |
| 21:58.26 | mjordan | current was still '4' when I had read 4 elements out of the vector |
| 21:58.33 | mjordan | but I'll give it another go |
| 21:58.40 | mjordan | could be crazy |
| 22:08.02 | mjordan | putnopvut: http://pastebin.com/jniwctC1 |
| 22:09.02 | putnopvut | mjordan: can you pb the code? |
| 22:09.07 | mjordan | sure |
| 22:09.15 | putnopvut | Just want to see what's at pbx.c:1177 |
| 22:09.25 | putnopvut | well and the whole loop for that matter |
| 22:09.32 | mjordan | http://pastebin.com/Npxx5pi2 |
| 22:09.46 | putnopvut | ah there's your problem. |
| 22:09.54 | putnopvut | Don't use i and don't increment it |
| 22:09.58 | putnopvut | Just always get the item at 0 |
| 22:10.01 | mjordan | doh |
| 22:10.09 | mjordan | I should probably stop writing code. |
| 22:10.11 | putnopvut | and always remove that one too |
| 22:10.53 | mjordan | yeah |
| 22:11.11 | file | blame the end of the day |
| 22:13.41 | mjordan | putnopvut: yay. |
| 22:13.45 | mjordan | I'll update the various reviews. |
| 22:13.51 | putnopvut | yippee |
| 22:24.55 | mjordan | putnopvut: thanks for the reviews |
| 22:25.07 | mjordan | I think I may stay out of pbx.c for awhile |
| 22:25.13 | putnopvut | good idea |
| 22:25.19 | putnopvut | that place will mess with your sanity |
| 22:25.54 | file | mjordan, what will you dive into next? |
| 22:26.02 | mjordan | probably something happy and func |
| 22:26.05 | mjordan | er, fun. |
| 22:26.10 | mjordan | I was cleaning up HTTP caching. |
| 22:26.24 | mjordan | huh |
| 22:26.29 | mjordan | who shipped the chan_dahdi patch? |
| 22:27.29 | mjordan | it kind of doesn't matter |
| 22:27.36 | mjordan | I just think we should probably write a test for it |
| 22:27.39 | mjordan | but that's going to be a challenge |
| 22:28.34 | file | rmudgett, does challenge adequately describe it? |
| 22:29.17 | rmudgett | yes |
| 22:29.58 | rmudgett | mjordan: That chan_dahdi patch should go in certified. correct? |
| 22:30.42 | mjordan | rmudgett: yes |
| 22:31.07 | mjordan | I have about half of libpri in python bindings. Kind of. Just suppppperrrrrrrrrrrr boring. |
| 22:31.13 | rmudgett | 13.1 at least. 11.6? |
| 22:33.50 | mjordan | I'd say just 13.1 |
| 22:33.52 | mjordan | personally. |
| 22:37.17 | *** part/#asterisk-dev mjordan (~mjordan@104-145-12-182.dedicated.allstream.net) |
| 23:12.38 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 23:14.02 | file | gtjoseph, sorry for being a party pooper :P |
| 23:14.09 | gtjoseph | no reason to be |
| 23:14.15 | gtjoseph | they're good points |
| 23:15.03 | gtjoseph | you've seen too many complicated solutions where a simple one would do and I've seen too many point solutions that can't be reused. :) |
| 23:15.18 | file | yup |
| 23:15.35 | gtjoseph | I'm proposing a middle ground now. |
| 23:15.58 | file | I don't even know if I want to entertain a proposal - I'd just like to know what the problems are, the areas of concern, that sort of thing |
| 23:16.21 | gtjoseph | it's hard to do that though because the problems are very specific |
| 23:17.00 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 23:17.00 | gtjoseph | i'll be finished typing in a few minutes and you can look. |
| 23:17.54 | *** join/#asterisk-dev pchero (~pchero@0x555140b5.adsl.cybercity.dk) |
| 23:18.00 | file | I may look at it tomorrow, I'm nearing 13 hours of poking at work stuff |
| 23:18.23 | gtjoseph | no worries. |
| 23:24.01 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-syvvcsaqbhjfpqut) |
| 23:26.42 | file | dreams of sun |
| 23:26.44 | coreyfarrell | gtjoseph: BTW thanks for recommending ccache... how do you tell configure to use it? I use CC="ccache gcc-4.8" ./configure, but I'm probably going to put the CC var into my bash profile. |
| 23:27.26 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 23:27.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 23:27.35 | file | coreyfarrell, I use export PATH=/usr/lib/ccache:$PATH |
| 23:27.42 | gtjoseph | depends on the distro. on rpm based systems, installing the package automatically configures it for all incocations of gcc |
| 23:27.49 | gtjoseph | invocations |
| 23:28.34 | coreyfarrell | yeah doesn't seem to do so on linux mint (ubuntu based) |
| 23:28.45 | file | yeah, on Ubuntu you have to do it manually |
| 23:28.48 | coreyfarrell | file: ccache is already in my path (/usr/bin) |
| 23:29.20 | file | coreyfarrell, ccache has symlinks (gcc, g++, etc) in /usr/lib/ccache |
| 23:29.47 | file | coreyfarrell, the symlinks are to ccache which then invokes the real compiler - since it's at the front in the path the symlinks get used which means ccache gets used automagically |
| 23:30.25 | coreyfarrell | ah I see. one thing about that I read in the manual that the symlink method has problems with libtool builds.. I guess I can test it but I use libtool on one of my own projects |
| 23:31.35 | gtjoseph | ah yeah, I have a /etc/profile.d/ccache.sh that does the path munging. |
| 23:33.43 | file | go go ccache |
| 23:33.57 | file | superscrat, do you use ccache? |
| 23:34.28 | coreyfarrell | I wish I the fixes for buildopts.h could have gone to 11/13 :( |
| 23:34.36 | file | I don't know why I asked her - I can see in my IM that she's idle >_> |
| 23:35.06 | gtjoseph | coreyfarrell: why didn't they? |
| 23:35.23 | coreyfarrell | it changes the calculation for AST_BUILDOPT_SUM |
| 23:35.51 | gtjoseph | and that's bad? |
| 23:36.03 | coreyfarrell | I think that's an ABI issue anyways, binary modules getting rejected for incorrect checksum? |
| 23:36.25 | gtjoseph | gotcha |
| 23:36.26 | coreyfarrell | IE if res_digium_fax.so is built against 13.0, then run against 13.next, the checksum wouldn't match |
| 23:36.30 | file | potentially |
| 23:39.13 | coreyfarrell | unless binary modules are build will blank buildoptsum, that would skip the check and make it ok? sgriepentrog I know one of my previous patches caused ABI issues for something you work with, what do you think? |
| 23:39.31 | file | I'll err on "potentially" |
| 23:39.45 | file | can check tomorrow |
| 23:41.38 | *** join/#asterisk-dev roramirez (~rodrigo@186-107-235-175.baf.movistar.cl) |
| 23:41.42 | coreyfarrell | now that I think of it AST_BUILDOPT_SUM in 11 and 13 changes if you enable or disable app_cdr (or any other module that another depends on).. |
| 23:42.00 | file | I *think* it should be fine |
| 23:42.28 | roramirez | hi |
| 23:42.35 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |