| 01:23.25 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:23.25 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 02:15.54 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 02:15.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:16.04 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip184-182-52-160.ph.ph.cox.net) |
| 05:59.43 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip184-182-52-160.ph.ph.cox.net) |
| 07:42.16 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:42.16 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:55.27 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:1dd7:b42:3b85:c2f5) |
| 08:00.08 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 08:22.18 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:35.16 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:19.56 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:52.59 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 12:00.44 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip184-182-52-160.ph.ph.cox.net) |
| 12:33.38 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.36) |
| 12:43.56 | *** join/#asterisk-dev jkroon_ (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 13:18.24 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 13:18.24 | *** mode/#asterisk-dev [+o ChanServ] by verne.freenode.net |
| 13:45.40 | seanbright | so re: astdb, i am giving up |
| 13:47.01 | seanbright | the current implementation "cheats" by always having a transaction open and only periodically committing |
| 13:48.09 | seanbright | that being said, i don't think that the "perftest" unit test that we have is particularly useful, because it doesn't mimic any actual usage of the API. there is no other place in the code where we iterate 100k times inserting data without taking a breath. |
| 13:50.09 | seanbright | now, we could add a v2 API that allowed us to pass around a handle/context object that could store transaction state and all that jazz, but i don't particularly want to do that personally. |
| 13:50.23 | seanbright | so i throw my hands up... and they stay thereeee, and they say yayyy |
| 13:53.09 | gtjoseph | seanbright: too bad. i was looking forward to seeing your implementation. |
| 13:53.29 | seanbright | gtjoseph: and if it actually improved things, you would |
| 13:54.46 | seanbright | profiling astdb today is a bit misleading, because if you aren't profiling the sync thread you are only getting half the story |
| 13:55.12 | file | on an unrelated note, I hope to have a non-sucky OPTIONS implementation this week |
| 13:55.37 | seanbright | we COULD turn on WAL and change the synchronization policy and squeeze some more performance out of what we have today, but because a lot of it is happening on a background thread, you might not actually see any read/write benefits |
| 13:56.08 | seanbright | file: fix for ASTERISK-26806? |
| 13:56.41 | file | it should, yes |
| 13:56.46 | gtjoseph | nice |
| 13:56.48 | seanbright | does it obsolete my changes? |
| 13:56.57 | seanbright | r7477? |
| 13:57.25 | seanbright | that's a dumb question, they aren't directly related |
| 13:57.34 | file | it doesn't obsolete them |
| 13:57.49 | seanbright | what have you narrowed down said suckiness to? |
| 13:58.12 | file | all of it |
| 13:58.17 | seanbright | go on... |
| 13:58.35 | file | the support itself has just grown and grown, bandaids everywhere |
| 13:58.53 | file | so I deleted the file. |
| 13:59.04 | file | :P |
| 13:59.10 | seanbright | heh, that's one way to do it |
| 13:59.46 | file | I can't "fix" what exists. |
| 13:59.51 | seanbright | right |
| 14:00.07 | file | will what's in my head work? I dunno, we'll see |
| 14:00.14 | seanbright | i sure hope so |
| 14:00.46 | seanbright | well, try to use sorcery_astdb_retrieve_prefix() somehow please |
| 14:01.20 | file | kk |
| 14:04.11 | seanbright | well now i don't have anything to work on |
| 14:04.12 | seanbright | heh |
| 14:17.00 | file | ACHOO |
| 14:41.32 | tsearle | it's cold |
| 15:06.04 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-pkrmseciisxykttj) |
| 15:06.05 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:09.23 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:09.23 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:14.13 | *** join/#asterisk-dev Deeewayne (~dwayne@c-68-35-189-134.hsd1.al.comcast.net) |
| 15:14.14 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:28.34 | AsteriskRoss | file: is there any chance that the re-write could include the option to not authenticate OPTION pings from endpoints? chan_sip replies without needing auth but chan_pjsip appears to always require auth? |
| 15:28.46 | file | nope |
| 15:28.50 | AsteriskRoss | ok |
| 15:44.38 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:44.38 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:01.15 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:38.50 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-fnzagcdfduxmfaeg) |
| 16:38.51 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 18:38.47 | *** join/#asterisk-dev Deeewayne (~dwayne@c-68-35-189-134.hsd1.al.comcast.net) |
| 18:38.48 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:53.42 | coreyfarrell | rmudgett: do you know anything about the algorithm complexity of ao2_find (full key search with functional hash_fn)? For example finding a string in a linked list averages O=N/2 strcmp's. |
| 18:54.29 | rmudgett | That depends upon the type of container. |
| 18:55.02 | rmudgett | A hash container is supposed to be O(1) if there are no collisions. |
| 18:56.12 | coreyfarrell | AsteriskRoss: is there a issue open for supporting non-authenticated OPTION pings? we have a tracker issue for chan_sip -> chan_pjsip feature parity, I'd like to link the options auth. |
| 18:59.56 | gtjoseph | coreyfarrell: it's getting late in the UK. |
| 19:00.06 | coreyfarrell | rmudgett: yeah I wasn't talking about a list container. so assuming a reasonable number of buckets most ao2_find using full key would be O(1)? Am I correct to assume that lookup by partial key requires a full container scan? |
| 19:01.31 | gtjoseph | it'd have to since a hash of a partial key won't match anything |
| 19:01.53 | coreyfarrell | cool |
| 19:02.32 | rmudgett | Yes a lookup in a hash container with a partial key requires a full container search. That's because we cannot calculate the hash where the object is stored in the container. |
| 19:04.48 | rmudgett | The channels container is a hash container. When I had several hundred channels in the container the longest bucket collision list was 3. |
| 19:19.29 | coreyfarrell | one of the things I've recently checked was startup time for a couple different dialplans. 1 context with 10k extens (1 prio each) took 3 seconds for startup and shutdown. with 100k extens it took 9 minutes, 17 seconds. |
| 19:21.33 | coreyfarrell | mainly because contexts have linked lists of all extensions, adding an extension involves checking for duplicate so it's O=N*N/2 comparisons. |
| 19:35.50 | kharwell | reg https://gerrit.asterisk.org/#/c/7478/ - I'm thinking now this should be master only as it affects ami/ari event output. Or enough to add a note to the CHANGES file? |
| 19:38.38 | file | hum de dum |
| 19:38.56 | file | probably master only, as it does change public exposing stuff |
| 19:39.27 | gtjoseph | well, it's a cli change only though |
| 19:40.03 | gtjoseph | and NO ONE should be parsing CLI output :) |
| 19:40.33 | kharwell | I checked the ami ContactStatus event and it outputted "NonQualified" (what I changed the description to) for the status |
| 19:40.54 | gtjoseph | perfect |
| 19:41.12 | gtjoseph | i'd vote for all branches then |
| 19:41.26 | gtjoseph | it's one less thing that's different |
| 19:41.32 | gtjoseph | among them all |
| 19:42.00 | kharwell | but that changes the AMI event value. Before it was Unknown or Created |
| 19:42.18 | kharwell | might break people who parse that value |
| 19:42.28 | gtjoseph | oh |
| 19:42.36 | gtjoseph | i thought it was a CLI only |
| 19:43.05 | gtjoseph | well, if you can, how about just using NonQual for the CLI only |
| 19:43.14 | kharwell | I thought so too at first, but I went back and double checked the AMI output and it showed the updated description |
| 19:43.22 | gtjoseph | figures |
| 19:44.43 | rmudgett | Should mention in UPGRADE.txt too. |
| 19:45.10 | rmudgett | in addition to CHANGES |
| 19:45.14 | kharwell | I thought about CLI only, but 1) that makes the descriptions differ, 2) the original linked fix changing Unknown to Created still affects both. Meaning before someone might have seen Unknown, but now Created |
| 19:48.23 | cresl1n | kharwell: I'd second the master only vote |
| 19:48.35 | cresl1n | Do we *need* it in non-master? |
| 19:49.19 | kharwell | nah it was just an attempt to make the status more consistent and descriptive of its state |
| 19:50.29 | cresl1n | On a separate note, for https://gerrit.asterisk.org/#/c/7494/2/apps/app_voicemail.c |
| 19:50.46 | cresl1n | since it's only against master, I don't think we need to recommend an AMI version bump at this point, no? |
| 19:51.35 | cresl1n | and whenever master becomes 16, at that point it'll get a completely new AMI major version |
| 19:52.02 | cresl1n | a.k.a. the version-numbers-in-master-are-meaningless interpretation? |
| 19:52.48 | rmudgett | cresl1n: yes. Also the C++ style comments need to be fixed. |
| 19:52.55 | cresl1n | aww crap |
| 19:52.58 | cresl1n | forgot about those |
| 19:53.18 | cresl1n | I've never been super strict on the C++ style comment removal stuff |
| 19:53.22 | cresl1n | need to up my game I guess |
| 19:53.50 | kharwell | cresl1n: correct the version in master is meaningless. No version bump necessary unless he wants to cherry pick and add tests |
| 19:53.59 | cresl1n | Cool |
| 19:54.02 | cresl1n | that's what I was thinking too |
| 19:55.36 | AsteriskRoss | <PROTECTED> |
| 19:56.29 | coreyfarrell | AsteriskRoss: thanks. |
| 20:00.47 | *** join/#asterisk-dev Qwell (~north@asterisk/developer/Qwell) |
| 20:00.47 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 20:04.17 | AsteriskRoss | coreyfarrell: ASTERISK-27477 has been created |
| 20:04.49 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d009c2580fa25ecc48f.ipv6.abo.wanadoo.fr) |
| 20:20.14 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00ad8deb7da38cbe37.ipv6.abo.wanadoo.fr) |
| 20:33.03 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00e0af3475f8dfe828.ipv6.abo.wanadoo.fr) |
| 20:42.00 | seanbright | coreyfarrell: i thought dialplan used a trie |
| 20:42.54 | seanbright | oh. i guess it's all the same config loader. |
| 20:43.21 | coreyfarrell | seanbright: only if it's enabled (it's not by default). and yes we always build structures for new and old pattern matching. |
| 20:45.10 | seanbright | when i originally was working on https://gerrit.asterisk.org/#/c/7408/ i added a ternary search tree (a trie but with a binary tree at each node instead of a fixed array) and it did speed up name lookups significantly |
| 20:45.32 | seanbright | the "problem" is that you can have 100 categories with the same name |
| 20:45.44 | seanbright | so you have to do collision detection regardless |
| 20:46.13 | seanbright | and order has to be maintained so you end up maintaining two separate data structures |
| 20:46.47 | seanbright | that being said, 100k extensions in a single contact is not common |
| 20:46.53 | seanbright | context* |
| 20:46.55 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 20:46.55 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 20:47.26 | rmudgett | One or the other structure is used. The trie structure has to be enabled but is buggy. |
| 20:47.46 | seanbright | the matching itself, not the data structure, right? |
| 20:47.51 | seanbright | that is my recollection at least |
| 20:48.00 | rmudgett | It has been in there since 1.4 as experimental. It never really left that status. :) |
| 20:48.15 | seanbright | gotcha. doesn't really solve the config loading issue though. |
| 20:48.31 | seanbright | and i say "issue" loosely |
| 20:48.48 | rmudgett | The trie structure was meant to speed things up for really large dialplans. |
| 20:49.15 | seanbright | right. |
| 20:50.03 | seanbright | but main/config.c parses the file before pbx/pbx_config.c get it's hands on it |
| 20:51.12 | seanbright | and i assume the dup check is happening in config.c |
| 20:51.58 | coreyfarrell | seanbright: in my test it was main/pbx.c that was the bottleneck, the function which adds an extension. |
| 20:52.07 | seanbright | ahhh, ok |
| 20:53.23 | coreyfarrell | when testing 10k extensions callgrind reported 10 million 'IR' for the call to ast_config_load2, 1.15 billion IR for the 10k calls to ast_add_extension2. |
| 20:54.02 | seanbright | IR = instruction... word? |
| 20:54.20 | coreyfarrell | I think it stands for instrumentation records.. |
| 20:55.09 | seanbright | 1.15B sounds like a big number |
| 20:55.11 | coreyfarrell | seanbright: for comparison res_pjsip load_module took 20 million IR.. |
| 20:56.03 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00a1abadf3527fff32.ipv6.abo.wanadoo.fr) |
| 20:56.25 | coreyfarrell | on my system 1.15B is about 3 seconds in real time (when the test is rerun outside callgrind obviously) |
| 20:56.33 | seanbright | well, clearly a LL is not the right structure if we're primarily searching by name |
| 20:57.37 | seanbright | ao2_container might be less than ideal too if the number of buckets is fixed |
| 20:57.43 | seanbright | what about the RB tree container? |
| 20:57.51 | seanbright | that's a thing, right? |
| 20:58.38 | coreyfarrell | the other thing to consider is that lookup isn't always with full key. obviously LL vs ao2 container would make no difference for that (ao2 would add insignificant overhead to the full scan lookup). |
| 20:59.11 | seanbright | well, a trie or TST would be ideal for that |
| 20:59.38 | coreyfarrell | also the ao2 container would be no benefit for extension patterns. |
| 20:59.48 | seanbright | tries are more memory efficient assuming your alphabet has a low cardinality |
| 21:00.03 | seanbright | TST are better for high cardinality (unicode) |
| 21:00.40 | seanbright | but TSTs have worst case O(n) in the pathological case |
| 21:00.52 | seanbright | if you put everything in sorted |
| 21:15.05 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00dc32744d838b8934.ipv6.abo.wanadoo.fr) |
| 21:27.58 | seanbright | coreyfarrell: simple tst i started working on if you were interested: https://gist.github.com/seanbright/df046daf3e5e424bc2d6e1b523936936 |
| 21:28.26 | seanbright | there's some debug code in there that dumps out a .dot file which you can process with graphviz to get a pretty picture of the data structure |
| 21:28.53 | seanbright | also: the code may or may not be broken :D |
| 21:30.45 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d006dd7203b730abc91.ipv6.abo.wanadoo.fr) |
| 21:32.38 | coreyfarrell | seanbright: I'll have to take a look at it later.. wouldn't it become a lot more complicated once you support pattern matching? |
| 21:33.48 | seanbright | potentially. i haven't really looked at how we do that today. |
| 21:33.59 | coreyfarrell | for now I'm probably going to defer any work on pbx.c though.. I just don't feel like poking that hornets nest yet. |
| 21:34.17 | seanbright | the trie implementation (broken or not) must have tried to figure that out |
| 21:34.57 | seanbright | what we should do is build a state machine for every possible extension and merge them in a massive DFA |
| 21:35.01 | seanbright | trivial... |
| 21:52.32 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00694fe303bb182dab.ipv6.abo.wanadoo.fr) |
| 21:58.10 | cresl1n | Hey guys, it's my turn at public issue triage and I haven't done this in a long time |
| 21:58.10 | cresl1n | https://issues.asterisk.org/jira/browse/ASTERISK-27469 |
| 21:58.10 | cresl1n | His patch looks good |
| 21:58.11 | cresl1n | Do I need to do something special to move it out of the triage queue? |
| 21:58.15 | file | you have to decide if you want to turn it into an SWP on our side, if so then do the needful |
| 21:58.15 | jsmith | cresl1n: The patch looks reasonable to me too -- I can't speak to the Gerrit workflow |
| 21:58.15 | file | if you want to accept then Acknowledge it |
| 21:58.15 | cresl1n | Thanks file :-) |
| 21:58.15 | cresl1n | howdy jsmith! |
| 21:58.15 | jsmith | cresl1n: Howdy! Now that I'm actually able to get on IRC during ${DAYJOB} hours again, you'll probably see more of me here :-) |
| 21:58.54 | *** join/#asterisk-dev Deeewayne (~dwayne@c-68-35-189-134.hsd1.al.comcast.net) |
| 21:58.55 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 21:58.58 | cresl1n | great! |
| 21:59.32 | kharwell | cresl1n: also there are some canned/prewritten responses that you might find helpful. Like in that case, the "patch- generic code review" response has all the links to docs about submitting a code review if they wish to speed up the process |
| 22:00.32 | cresl1n | thanks kharwell :-) |
| 22:07.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00519bd81271bf3995.ipv6.abo.wanadoo.fr) |
| 22:19.49 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00cd5637cf87528146.ipv6.abo.wanadoo.fr) |
| 22:34.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0034069b543cc723b7.ipv6.abo.wanadoo.fr) |
| 22:47.39 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0041d9fec5b399a386.ipv6.abo.wanadoo.fr) |
| 23:02.29 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00a4ffdcaf302fea86.ipv6.abo.wanadoo.fr) |
| 23:17.25 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d009d7622e0185f36ff.ipv6.abo.wanadoo.fr) |
| 23:30.15 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00386ac6c7a392b3ad.ipv6.abo.wanadoo.fr) |
| 23:45.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00b040fcf21649be5d.ipv6.abo.wanadoo.fr) |
| 23:57.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00a56c97a7274c8c72.ipv6.abo.wanadoo.fr) |
| 23:58.40 | *** join/#asterisk-dev DanQuinney (sid18169@gateway/web/irccloud.com/x-nrmmndxvpcxdfbzt) |