| 03:44.23 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-stbgeckcvpjmppdc) |
| 05:30.31 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 05:30.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:44.01 | *** join/#asterisk-dev lumasepa (~gestoip@193.145.124.30.local.ull.es) |
| 07:15.05 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:27.16 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:44.55 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 07:44.55 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:30.58 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 08:41.33 | *** join/#asterisk-dev post-factum (~post-fact@vulcan.natalenko.name) |
| 08:41.46 | post-factum | guys, any luck to find out the state of SWP-8640? |
| 08:42.07 | post-factum | I'm the one who reported #25635 |
| 08:43.08 | wdoekes | post-factum: those internal tickets don't contain actual info as far as I'm told |
| 08:43.25 | wdoekes | if the public issue doesn't say any progress has been made, then no progress has been made |
| 08:44.23 | post-factum | wdoekes: okay, thanks |
| 08:44.47 | post-factum | could I reach Matt Jordan here? |
| 08:45.34 | wdoekes | not until the americans wake up |
| 08:45.56 | post-factum | thx |
| 08:46.09 | wdoekes | but yes, he's around every now and then |
| 08:46.25 | post-factum | "mjordan" or some another nick? |
| 08:46.31 | wdoekes | that's the one |
| 08:46.36 | post-factum | okay |
| 09:25.14 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 10:05.52 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 10:50.59 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 11:54.50 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 12:03.02 | file | definitely a Monday |
| 12:20.50 | *** join/#asterisk-dev [TK]D-Fender (~Joe@216-191-106-165.dedicated.allstream.net) |
| 12:50.37 | *** join/#asterisk-dev acidfu_ (~acidfoo@108.175.228.140) |
| 13:28.00 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 13:28.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 13:50.36 | *** join/#asterisk-dev WIMPy (~wimpy@85.183.95.26) |
| 13:59.21 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-duywcdsjhvfuoffs) |
| 14:32.50 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:32.50 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:36.41 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-mdulyvlrpsrnzhns) |
| 14:36.41 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:37.30 | file | I'm diagnosing gerrit being gerrit, and Java being Java |
| 14:43.06 | file | restarting! |
| 14:44.36 | file | k, I made a config tweak |
| 14:44.38 | file | we'll see if it helps |
| 14:56.42 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-vepnhallyynhbmcs) |
| 16:13.49 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-160-173.w92-135.abo.wanadoo.fr) |
| 16:33.22 | rmudgett | gtjoseph: ping |
| 16:41.27 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 16:41.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:20.28 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:20.28 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:04.54 | gtjoseph | rmudgett: pong |
| 18:06.19 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:06.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:07.42 | rmudgett | About the ast_calloc_with_stringfields change. I'm thinking that it is too much overhead to be worth it |
| 18:08.00 | gtjoseph | well, it does work now. |
| 18:08.20 | rmudgett | That overhead is going to be there for every struct that uses stringfields |
| 18:09.29 | gtjoseph | the proble is it will segv if someone tries anything fully with it. how about if i rever the original init call to call the internal one directly again |
| 18:10.59 | rmudgett | I thought it was originally attempting to setup an array of them but failing for more than one and not taking into account the necessary destruction |
| 18:11.12 | rmudgett | requirements |
| 18:12.14 | gtjoseph | true, i was thinking of the free but it dodn't do that originally. |
| 18:13.07 | gtjoseph | ok, so i'll direct the original ast_string_fidns_init to the internal version |
| 18:13.35 | gtjoseph | wait, nowe i'm confusing myself :) |
| 18:13.40 | gtjoseph | let me actually look. |
| 18:16.04 | rmudgett | What I was thinking of on the Friday/Saturday review was the programmer would have to supply the needed information to do the delete[] on the array pointer. |
| 18:16.30 | rmudgett | I also said that it was moot since the array feature wasn't used anyway. |
| 18:16.35 | gtjoseph | if they get it wrong, we cna't check and poof. |
| 18:16.55 | rmudgett | That's then the programmer's fault. :) |
| 18:17.37 | gtjoseph | yeah, i'll just go remove all the ast_assert's from the codebase then :) |
| 18:18.20 | gtjoseph | so, on the init, if you're not using calloc, it's just setting the extra int fields |
| 18:19.16 | gtjoseph | the free memory is just the original logic refactored. |
| 18:19.47 | gtjoseph | so the overhead is just the size of the 3 extra ints |
| 18:20.30 | rmudgett | I had always thought that ast_calloc_with_stringfields() was a convienience of allocating and initializing stringfields in one. I rarely remember that calloc is for initializing arrays of items. A feature I rarely use. :) |
| 18:21.11 | rmudgett | Three extra ints in a small allocated object for every struct that uses stringfields. That tends to add up. |
| 18:21.24 | gtjoseph | it's not used anywhere for multiples. ok, so i'll remove the loops and put an assert in calloc to check for num_structs == 1 |
| 18:22.08 | rmudgett | yes |
| 18:22.24 | gtjoseph | well, actually, maybe not if a third party module is trying to use it fo rmore than 1. |
| 18:22.58 | gtjoseph | what are the chances? |
| 18:23.09 | rmudgett | If they are, then they have a memory leak anyway. |
| 18:23.22 | gtjoseph | true but that they won't notice. :) |
| 18:23.55 | gtjoseph | proceed with the assert? |
| 18:24.08 | rmudgett | I think the chances of a third party using it to allocate an array is rather small. |
| 18:24.22 | gtjoseph | agreed. |
| 18:24.26 | rmudgett | yes assert |
| 18:24.29 | gtjoseph | loop out assert in. |
| 18:25.18 | rmudgett | Will you be making a follow up patch on master to eliminate the need for the small allocation block? |
| 18:26.05 | gtjoseph | yeah, i'll do it separately. i want to be able to cherry pick this one for a while. |
| 18:26.43 | rmudgett | That's why I was suggesting a followup patch. :) |
| 18:33.40 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:33.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:35.56 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@68-118-182-198.dhcp.asfd.ct.charter.com) |
| 19:01.44 | *** join/#asterisk-dev pc-m (~user@modemcable094.94-70-69.static.videotron.ca) |
| 19:39.44 | *** join/#asterisk-dev lnxslck (~lnxslck@av3-84-90-162-98.netvisao.pt) |
| 19:44.55 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:44.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:53.10 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 19:53.10 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 21:31.34 | *** join/#asterisk-dev klow (~textual@c-73-53-31-109.hsd1.wa.comcast.net) |
| 22:15.32 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-vtgkqezvlxsxwjmb) |
| 22:39.35 | file | gtjoseph, looks like MWI changes introduced a crash - https://jenkins.asterisk.org/jenkins/job/gate-asterisk-external-mwi/532/ - or 5 |
| 22:41.49 | gtjoseph | hmmm |
| 22:46.33 | gtjoseph | file: did that failure happen on what's was committed to 13 or on the pending reviews? |
| 22:46.36 | gtjoseph | i can't tell |
| 22:46.40 | file | what went in |
| 22:46.50 | gtjoseph | ok |
| 22:49.48 | *** join/#asterisk-dev acidfu_ (~acidfoo@108.175.228.140) |
| 22:54.55 | gtjoseph | damn. i forgot voicemail_extension wasn't a stringfield. |
| 23:02.08 | *** join/#asterisk-dev klow (~textual@c-73-53-31-109.hsd1.wa.comcast.net) |
| 23:05.58 | gtjoseph | file: fixes up. |
| 23:18.31 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-duywcdsjhvfuoffs) |
| 23:21.57 | gtjoseph | rmudgett: still around? really want to get rid of ast_string_field_free altogether? Still looks weird to have to call ast_string_field_init to free fields you allocated with ast_calloc_with_stringfields. |
| 23:22.38 | rmudgett | yes. Otherwise you are expanding to API changes. |
| 23:22.48 | gtjoseph | ok |
| 23:22.56 | file | as I say to rmudgett often |
| 23:22.59 | file | SCOPE CREEP |
| 23:23.16 | gtjoseph | it was 1 #define # |
| 23:23.23 | gtjoseph | :) |
| 23:23.30 | gtjoseph | that's not MUCH creep. |
| 23:23.48 | file | SCOPE CREEP |
| 23:23.53 | file | I should have a poster for that |
| 23:24.02 | file | except I'm running out of walls for framed posters |
| 23:24.18 | rmudgett | For all the creeps? |
| 23:24.20 | file | I still haven't hung my "Practice Reckless Optimism" poster... |
| 23:58.39 | rmudgett | gtjoseph: A couple simple fixes and that review should be done. |
| 23:59.30 | gtjoseph | uh huh |