| 00:26.26 | *** join/#asterisk-dev elguero (~miguel323@17.140.211.66.inaddr.G4.NET) |
| 01:25.42 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.27.116.157.dynamic.adsl.gvt.net.br) |
| 01:32.51 | *** join/#asterisk-dev elguero (~miguel323@17.140.211.66.inaddr.G4.NET) |
| 01:52.01 | *** join/#asterisk-dev cVsup (~cVsup@189.12.6.232) |
| 04:06.49 | *** join/#asterisk-dev guilhermebr (~Guilherme@187.116.160.61) |
| 04:15.17 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 04:41.27 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:41.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 06:05.24 | *** join/#asterisk-dev apten (~apten@carbon.gonicus.de) |
| 06:08.34 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 06:28.53 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:28.56 | schmidts | good morning |
| 06:31.18 | schmidts | any devs allready awake or still on? |
| 06:32.54 | schmidts | i am now working here http://www.asterisk.org/doxygen/trunk/astobj2_8c.html#0729988ba8cb20751ea05efeb17459d4 cause i have seen there is a lot of potential to improve the callbacks |
| 06:33.56 | schmidts | what i have seen in my tests that there are around 30 to 50 % of non object calls to ao2_callback which means the function iterates over all buckets until it finds an object |
| 06:35.16 | schmidts | my idea was to add a linklist of buckets to the container which will be used for non hashable objects and move the bucket where an object is found to the first position. this will not change the normal hash buckets but IMHO this should improve the speed of accessing objects in the hash which we cant hash |
| 06:35.23 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 06:35.24 | schmidts | any other ideas for this? |
| 06:41.23 | Corydon76-home | schmidts: everything can be hashed, or it wouldn't be there in the first place |
| 06:42.04 | Corydon76-home | schmidts: some of those calls don't terminate after a single match, either |
| 06:42.45 | Corydon76-home | The latest item to be put into the hash should be at the head of the linked list anyway |
| 06:43.22 | Corydon76-home | And a reordering shouldn't improve the general case, because the general case is for ANY of the entries |
| 06:44.30 | Corydon76-home | A reorder just ensures that you'll almost never find an item at the beginning of the list |
| 06:45.21 | Corydon76-home | If you've got too many items in the linked list at the end of the hash, then the best thing to do would be to improve the hashing, generally by increasing the number of hash buckets |
| 06:53.04 | schmidts | corydon76-home you are right about the hashing itself but if you take a look at the callback function you will see only objects will be searched against the hash by using the hash function. |
| 06:53.55 | schmidts | there are several other callbacks which will not be hashable and have to be searched by iterating through all buckets |
| 06:55.06 | schmidts | and a reorder improves it cause normaly the hash isnt very well spreaded (sorry bad englisch i know ;) what i mean is that normally you have several empty buckets too |
| 06:55.20 | Corydon76-home | schmidts: This is true, but that's only because the code only allows a single datapoint to be hashed and stored that way per container. If need be, you can specify multiple containers and multiple hash functions |
| 06:55.49 | schmidts | thats true |
| 06:55.52 | Corydon76-home | If you aren't searching on the hashed datapoint, but on some other data, then you cannot use the hash |
| 06:56.00 | schmidts | i know |
| 06:56.39 | Corydon76-home | So it depends upon what you're doing... Maybe there are good places where we should be using multiple containers to improve search speed |
| 06:57.08 | schmidts | thats a good idea and i will take a look if this could be the better way |
| 06:58.19 | Corydon76-home | There are certainly places where it probably won't help, though, like on binary values... like pruning realtime entries on reload |
| 06:59.26 | Corydon76-home | Maybe, though... all of the realtime entries would be restricted to one of two buckets... |
| 07:00.47 | Corydon76-home | There is a massive chance of deadlock if you aren't careful, though... like one operation removing an object from container A and trying to lock/remove from container B, while the opposite is occurring with a different operation |
| 07:01.05 | Corydon76-home | You'd need a definitive locking order to ensure that that's not a problem |
| 07:01.33 | schmidts | there is allready a locking order in the internal_ao2_callback i think |
| 07:01.57 | Corydon76-home | But not for a single object in different containers |
| 07:02.11 | schmidts | right |
| 07:03.46 | Corydon76-home | That requirement of locking order may erase all speed gains of using multiple containers, but you'd have to test it out to be sure |
| 07:03.50 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:04.30 | Corydon76-home | Well, no, I guess not. But it's definitely a possible pitfall |
| 07:05.07 | schmidts | thats right |
| 07:05.39 | Corydon76-home | As long as insertion and deletion follow a specific order among the containers, you should be fine |
| 07:28.01 | *** part/#asterisk-dev apten (~apten@carbon.gonicus.de) |
| 07:44.42 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:4ddc:dc75:641e:385) |
| 07:48.26 | *** join/#asterisk-dev asterisk-learner (~chatzilla@77.42.241.114) |
| 08:17.48 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.206.10) |
| 08:32.13 | *** join/#asterisk-dev CoderForLife (~Miranda@unaffiliated/coderforlife) |
| 11:26.11 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:26.11 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:33.46 | *** join/#asterisk-dev Dovid (~Dovid@213.8.121.90) |
| 11:59.18 | Dovid | hi all |
| 12:03.13 | *** join/#asterisk-dev Mw3 (mw3@mw3.hu) |
| 12:56.42 | *** join/#asterisk-dev elguero (~miguel323@17.140.211.66.inaddr.G4.NET) |
| 13:20.08 | *** join/#asterisk-dev elguero (~miguel323@17.140.211.66.inaddr.G4.NET) |
| 13:20.57 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 13:20.57 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 13:49.30 | *** join/#asterisk-dev bklang_ (~bklang@tesla.alkaloid.net) |
| 14:05.29 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:05.29 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:11.55 | *** join/#asterisk-dev asterisk-learner (~chatzilla@77.42.241.114) |
| 14:30.58 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 14:39.57 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:39.57 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:40.02 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-hllngwklgyvvmqha) |
| 14:45.26 | asterisk-learner | Hello, can anyone tell me if WaitForSilence() waits for total silence or continuous silence ? |
| 14:47.30 | *** join/#asterisk-dev moy (~moy@CPE002719f00364-CM0026f3a1701d.cpe.net.cable.rogers.com) |
| 14:47.34 | leifmadsen | continuous |
| 14:50.44 | asterisk-learner | leifmadsen: I suspect that, but yesterday someone on asterisk channel told me told me total |
| 14:50.49 | asterisk-learner | thx anw :-) |
| 14:50.52 | russellb | they were wrong! |
| 14:50.59 | russellb | unless the code is broken |
| 14:51.00 | russellb | which is possible. |
| 14:51.07 | asterisk-learner | russellb :-) |
| 14:51.13 | asterisk-learner | :-S ? |
| 14:51.39 | asterisk-learner | eventually waitforsilence calls : __ast_dsp_silence() |
| 14:51.58 | asterisk-learner | which adds the silence : dsp->totalsilence += len/8; |
| 14:53.17 | asterisk-learner | but if i add a print statement just before this line (when silence is found) , priting dsp->totalsilence |
| 14:53.32 | asterisk-learner | it gets reset when a noise occurs after a silence |
| 14:54.00 | asterisk-learner | (tried it on a hardphone by muting the speaker and unmuting it). |
| 14:56.54 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:56.54 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:00.25 | *** join/#asterisk-dev moy (~moy@CPE003048b11058-CM00222d6b4d65.cpe.net.cable.rogers.com) |
| 15:11.16 | Deeewayne | M19260 |
| 15:11.18 | MuffinMan | [assigned] [Asterisk] Core/ManagerInterface 0019260: Manager eventfilter blacklisting does not filter blacklisted events reported by dhubbard https://issues.asterisk.org/view.php?id=19260 |
| 15:12.38 | Deeewayne | anyone know how eventfilter is supposed to work when blacklisting multiple events ? I'm debugging a potential 1.8.4 issue and I'm not sure if this is user error or not. Can anyone that knows about eventfilter (specifically blacklist specification) read my comments in -bugs ? |
| 15:26.51 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:26.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:57.59 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 16:25.31 | *** join/#asterisk-dev moy (~moy@CPE002719f00364-CM0026f3a1701d.cpe.net.cable.rogers.com) |
| 16:39.15 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 16:39.27 | *** part/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 17:02.26 | Deeewayne | w/ 1.8.4, adding #define REF_DEBUG 1 to manager.c immediately before the #include "asterisk/astobj2.h" (and recompiling) doesn't result in the /tmp/refs file being created. |
| 17:03.05 | Deeewayne | am I missing a step or should it be that easy? |
| 17:06.41 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.206.10) |
| 17:34.17 | Corydon76-home | Deeewayne: it's generally only that easy when dealing with modules. With core files, it's a question of initialization order, I believe |
| 17:35.45 | Deeewayne | Corydon76-home, thanks, I moved on to another way to do the debug. I was trying to make the actual event filter value the ao2 ref debug comment (arg3) |
| 17:38.06 | Deeewayne | Corydon76-home, I also tried defining REF_DEBUG before asterisk.h as well as after asterisk.h but before the other asterisk includes but it doesn't compile in those cases |
| 17:39.15 | Deeewayne | manager.c:3065: undefined reference to `__ast_dummy_channel_alloc' |
| 18:25.39 | Deeewayne | leifmadsen, if someone with commit access merged revision 306432 into the 1.8 branch, M19260 would be resolved. |
| 18:25.41 | MuffinMan | [assigned] [Asterisk] Core/ManagerInterface 0019260: [patch] Manager eventfilter blacklisting does not filter blacklisted events reported by dhubbard https://issues.asterisk.org/view.php?id=19260 |
| 18:56.44 | *** join/#asterisk-dev mpe (~mpe@91.100.62.248.generic-hostname.arrownet.dk) |
| 19:10.12 | *** part/#asterisk-dev mpe (~mpe@91.100.62.248.generic-hostname.arrownet.dk) |
| 19:30.37 | pabelanger | r1213 |
| 19:30.44 | MuffinMan | [R1213] support gmime-2.4 [Pending] Submitted by pabelanger => https://reviewboard.asterisk.org/r/1213/ |
| 19:30.53 | pabelanger | If anybody has some free time |
| 19:32.10 | russellb | pabelanger: you should review :-) |
| 19:32.15 | russellb | if you're not sure, research |
| 19:32.51 | pabelanger | russellb: are we doing code review wednesday? |
| 19:33.09 | russellb | yes |
| 19:33.22 | russellb | except i have meetings all day :-( |
| 19:33.33 | pabelanger | Okay then, I'll dive into it tomorrow |
| 19:35.58 | leifmadsen | rgagnon: ping?! |
| 19:36.14 | leifmadsen | russellb: :( |
| 19:36.19 | leifmadsen | I dislike your meetings |
| 19:38.01 | leifmadsen | rgagnon: I think twilson was looking for your feedback on a refcount issue, which I believe is.... |
| 19:38.03 | leifmadsen | M17255 |
| 19:38.09 | MuffinMan | [assigned] [Asterisk] Core/General 0017255: [patch] UDP ports not freed/ports leaking reported by kvveltho https://issues.asterisk.org/view.php?id=17255 |
| 19:38.19 | leifmadsen | ...prior to committing |
| 19:41.22 | rgagnon | I will re-read... I havent seen any new emails |
| 19:47.27 | rgagnon | lmadsen: what is the timeline for the commit? |
| 19:47.44 | rgagnon | just wondering if I need to push more testing, now, or tomorrow |
| 19:48.21 | leifmadsen | rgagnon: Ideally I'd really like to get RCs out this week |
| 19:48.31 | rgagnon | k |
| 19:48.36 | leifmadsen | I would prefer to have a release go out Thursday |
| 19:49.57 | rgagnon | should not be an issue |
| 19:50.47 | leifmadsen | awesome thanks! |
| 19:51.36 | rgagnon | np.. I think he may also be reviewing r1210 for the 1.8 branch (which I made from the 1207 diff) |
| 20:24.09 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 20:31.23 | leifmadsen | alecdavis: ping |
| 20:31.45 | leifmadsen | what is the mantis issue number of your *8 issue? (channel pickup?) |
| 20:33.41 | leifmadsen | ah 18654 |
| 20:37.02 | tzafrir | pabelanger, the gmime patch breaks older versions? |
| 20:37.16 | tzafrir | The old code should remain unchanged |
| 20:59.17 | alecdavis | sorry leif, wasn't here. |
| 20:59.39 | leifmadsen | alecdavis: no worries |
| 20:59.52 | alecdavis | But I have a question for you, 18654 is on the roadmap for 1.4 and 1.6.2, I don't believe it affects them. |
| 21:00.56 | alecdavis | great to see it get so additional love :) |
| 21:01.48 | leifmadsen | alecdavis: I moved it there because someone reported the same issue on 1.6.2.17.2 |
| 21:01.59 | leifmadsen | you'll see the duplicate issue as closed and related to that issue |
| 21:02.08 | leifmadsen | it may be possible they selected the wrong field? |
| 21:08.17 | alecdavis | 18654 and it's reviewboard 1185, started off focusing on the deadlock with playing the pickupbeep, but as always, fix one thing, find another. |
| 21:09.42 | alecdavis | Now that I have the sip_pickup in a thread, like sip_park, I do think it will fix the 1.6.2.17 issue, as that was locking in the channel search. yet to be verified. |
| 21:09.54 | *** join/#asterisk-dev mpe (~mpe@212.45.120.202) |
| 21:18.24 | *** join/#asterisk-dev miguel3239 (~miguel323@17.140.211.66.inaddr.G4.NET) |
| 21:24.04 | *** join/#asterisk-dev joshaidan (~brianj@24.109.210.41) |
| 21:34.44 | *** join/#asterisk-dev CoderForLife (~Miranda@unaffiliated/coderforlife) |
| 22:06.58 | *** join/#asterisk-dev moy (~moy@CPE003048b11058-CM00222d6b4d65.cpe.net.cable.rogers.com) |
| 22:09.05 | tzafrir | Why is there a need to use autoconf-2.6.2 on FreeBSD? |
| 22:09.16 | tzafrir | What is 'autoconf' there? |
| 22:19.55 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 22:28.11 | rgagnon | its after 5, but someone might still be here. (cuz it's 5:00 somewhere right?) |
| 22:28.48 | rgagnon | lmadsen: I read up more and tested twilson's r1207 patch, and put my "ship it!" comment on there. |
| 22:29.05 | rgagnon | r1207 |
| 22:29.15 | MuffinMan | [R1207] chan_sip refcount cleanup derived from rgagnon's review 1101 [Pending] Submitted by twilson => https://reviewboard.asterisk.org/r/1207/ |
| 22:38.02 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 22:39.38 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 22:40.59 | alecdavis | what does 5 matter, don't we all work way past that??? just for love. |
| 22:46.59 | *** join/#asterisk-dev moy (~moy@CPE003048b11058-CM00222d6b4d65.cpe.net.cable.rogers.com) |
| 22:52.23 | leifmadsen | heh, I worked till 6:15pm :) |
| 22:52.32 | leifmadsen | then I went to dinner, and now I'm back for a cpl mins |
| 23:00.59 | *** join/#asterisk-dev moy (~moy@CPE002719f00364-CM0026f3a1701d.cpe.net.cable.rogers.com) |