| 00:31.38 | *** join/#asterisk-dev pabelanger_ (~pabelange@CPE0013f7abc09a-CM0013f7abc096.cpe.net.cable.rogers.com) |
| 00:42.54 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:42.54 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 00:47.38 | *** join/#asterisk-dev diegomad (mad@186.81.138.100) |
| 01:04.41 | *** join/#asterisk-dev moy (~moy@bas1-unionville55-1177733627.dsl.bell.ca) |
| 01:17.41 | *** join/#asterisk-dev pabelanger_ (~pabelange@CPE0013f7abc09a-CM0013f7abc096.cpe.net.cable.rogers.com) |
| 01:34.46 | seanbright | so what is the difference between lumenvox and vestec? |
| 01:36.07 | file | what is the difference between verizon pstn service and bell pstn service? |
| 01:37.03 | kpfleming | yeah |
| 01:37.46 | seanbright | sorry i asked |
| 01:37.48 | seanbright | kthx! |
| 01:38.12 | file | don't be sorry, but that's the best answer I got |
| 01:38.21 | kpfleming | they are completely different |
| 01:38.26 | kpfleming | but the provide the same service |
| 01:38.28 | kpfleming | that's about it |
| 01:38.32 | seanbright | they are both sold on your site |
| 01:38.42 | kpfleming | yep |
| 01:38.48 | seanbright | and there is no discernable difference between the two from a marketing standpoint |
| 01:38.51 | seanbright | except one is cheapter |
| 01:38.55 | kpfleming | yep |
| 01:38.56 | seanbright | cheaper* |
| 01:39.19 | file | one engine is probably better than the other in certain situations |
| 01:40.07 | file | background noise, accents, more finely tuned acoustic model |
| 01:40.14 | file | is just making that up really since he has no idea |
| 01:40.28 | kpfleming | or not |
| 01:40.43 | kpfleming | honestly, we have no idea of the qualitative differences (if any) between them |
| 01:40.55 | seanbright | alright. thanks,. |
| 01:41.04 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 01:41.04 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 01:41.23 | file | kpfleming: oh! I know I know! vestec is 6 letters and lumenvox is 8 letters! that's a difference |
| 01:41.52 | kpfleming | and one company is based in san diego and the other is not |
| 01:42.14 | file | that reminds me, they owe me licensing details |
| 01:43.24 | seanbright | i thought lumenvox was a digium product? |
| 01:43.30 | seanbright | see. that's how little research i do. |
| 01:43.31 | seanbright | heh |
| 01:43.45 | file | Lumenvox is a company based out of San Diego, CA that provides speech recognition stuffage. |
| 01:44.00 | kpfleming | www.lumenvox.com |
| 01:44.10 | kpfleming | www.vestec.com |
| 01:44.12 | kpfleming | www.digium.com |
| 01:44.16 | kpfleming | all different :-) |
| 01:46.51 | seanbright | yup |
| 01:46.52 | seanbright | thanks |
| 01:47.01 | file | seanbright: the bill is in the mail. |
| 01:48.22 | seanbright | file: ok |
| 01:48.45 | kpfleming | so... how do i make an ubuntu system stick at karmic and stop offering the upgrade to lucid? |
| 01:48.50 | file | that's all I get on a Sunday night? 'ok'? I'm disappointed |
| 01:49.24 | seanbright | kpfleming: why don't you want to upgrade? |
| 01:49.35 | kpfleming | it's my wife's laptop... not ready for that yet |
| 01:49.39 | seanbright | ah. |
| 01:51.49 | seanbright | google isn't helpful |
| 01:51.54 | seanbright | something about removing update-notifier |
| 01:52.01 | seanbright | which doesn't exist anymore |
| 01:52.15 | kpfleming | it does in karmic, at least on this system |
| 01:52.16 | kpfleming | that might work |
| 01:52.49 | pabelanger_ | you can disable the pop up |
| 01:52.49 | pabelanger_ | gconftool -s --type bool /apps/update-notifier/auto_launch false |
| 01:52.59 | pabelanger_ | not sure if that helps |
| 01:53.18 | seanbright | or just sudo do-release-upgrade |
| 01:53.24 | seanbright | it will stop telling you to upgrade after that |
| 01:53.26 | kpfleming | pabelanger: this is kde, not gnome |
| 01:53.27 | seanbright | heh |
| 01:53.32 | kpfleming | thanks, troll :-) |
| 01:53.53 | file | seanbright: did you go to trollcademy? |
| 01:54.11 | pabelanger_ | kpfleming: not sure then |
| 01:54.34 | seanbright | file: ok |
| 01:54.48 | *** kick/#asterisk-dev [seanbright!~file@asterisk/developer-and-muffin-lover/file] by file (NOT OK!) |
| 01:54.48 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 01:54.48 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 03:50.56 | *** join/#asterisk-dev jtodd (jyc1l5tlkv@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 03:50.56 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 03:56.48 | seanbright | is 260521 |
| 03:56.51 | seanbright | err |
| 03:57.01 | seanbright | is 260521 bad for API compat? |
| 04:05.55 | Corydon76-dig | Yeah, he probably should have used the optional_api defines |
| 05:16.54 | *** join/#asterisk-dev jtodd (hvy7gvrxxe@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 05:16.54 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 07:18.27 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:24.42 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:24.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:14.24 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-155-51.cinci.res.rr.com) |
| 10:44.57 | *** join/#asterisk-dev ManxPower (~manxpower@216.186.151.147) |
| 10:45.29 | ManxPower | wishes someone would write a patch to indicate the actual state of the VPM |
| 10:49.43 | tzafrir | ManxPower, doesn't this appear on the sysfs interface of voicebus? |
| 10:51.34 | ManxPower | tzafrir, it does not appear in dahdi_cfg -vvv |
| 10:52.28 | tzafrir | ManxPower, the sysfs interface adds some entries somewhere under sysfs. Not sure if it is enabled by default, though |
| 10:53.31 | ManxPower | then it does not appear to be enabled |
| 10:53.58 | ManxPower | I get three items under voicebus, none obviously having to do with EC |
| 10:54.37 | ManxPower | I wonder what would cause it to not be enabled. I'll torture support. |
| 10:56.49 | ManxPower | I am out of the maint window in 4 mins anyway |
| 10:59.47 | ManxPower | Ah! I see support is torturing customer right back |
| 11:14.53 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:14.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:29.25 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 11:29.25 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:22.43 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:23.35 | *** part/#asterisk-dev ManxPower (~manxpower@216.186.151.147) |
| 12:38.46 | *** join/#asterisk-dev Dovid (~annon@213.8.118.62) |
| 12:57.59 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 12:57.59 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 13:04.40 | pabelanger | morning |
| 13:05.00 | Dovid | morning |
| 13:05.34 | Dovid | pabelanger: ever had time to look at the updates on my ticket? https://issues.asterisk.org/view.php?id=17180 |
| 13:07.31 | pabelanger | Dovid: I haven't look at issue yet this morning. At work right now, working on my own customers right now :) |
| 13:08.27 | Dovid | ok. thats always more important ;) |
| 13:21.16 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 13:21.16 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 13:40.27 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:40.27 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:51.04 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:51.04 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:58.06 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 13:59.56 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:59.56 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:11.03 | *** join/#asterisk-dev CunningPike (~CunningPi@S01060014bf81366b.vc.shawcable.net) |
| 14:14.42 | pabelanger | jmls: ping |
| 14:28.59 | *** join/#asterisk-dev moy (~moy@bas1-unionville55-1177733627.dsl.bell.ca) |
| 14:29.39 | *** join/#asterisk-dev mnick86 (~Matthias@whhem00016.cip.uni-regensburg.de) |
| 14:32.10 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:32.10 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:34.49 | *** join/#asterisk-dev jtodd (b17bakfuv8@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 14:34.49 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 14:43.13 | russellb | eliel: at this rate you're going to finish your project before it officially starts :-) |
| 14:45.49 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 14:48.00 | eliel | russellb: we always have something to add :) |
| 14:48.12 | *** join/#asterisk-dev CunningPike (~CunningPi@S01060014bf81366b.vc.shawcable.net) |
| 14:48.14 | eliel | there are a lot of providers to be done |
| 14:48.22 | russellb | nods |
| 14:48.36 | russellb | I think it would be a good idea to do code review / merging on them as you go |
| 14:48.45 | russellb | so you don't have to deal with merge conflicts and one massive code review at the end |
| 14:49.25 | eliel | russellb: i agree with that, once i finished the unit testing for each add provider i will submit the first review. |
| 14:49.51 | russellb | sounds good |
| 14:50.13 | eliel | russellb: i have simplified the search code that was needed to add inside each data provider so now it is easy to create one. |
| 14:50.41 | russellb | awesome |
| 14:51.19 | *** join/#asterisk-dev drachenfels2 (~king@91.142.36.77) |
| 14:51.23 | mnick86 | hi, how can I log all the manger-events sent by asterisk ? |
| 14:51.30 | mnick86 | ups, wrong chan |
| 14:54.59 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:54.59 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:55.22 | drachenfels2 | I'm trying to find out what's going on with this bug https://issues.asterisk.org/view.php?id=16936 |
| 14:55.58 | russellb | M16936 |
| 14:56.00 | MuffinMan | [acknowledged] [Asterisk] Channels/chan_sip/General 0016936: [patch] Qualify frequency has big pauses. Asterisk stops sending SIP OPTIONS to keep NAT alive reported by ib2 https://issues.asterisk.org/view.php?id=16936 |
| 14:56.12 | drachenfels2 | I've been looking at the scheduling code, and from what I can tell, I think that items are not in time order |
| 14:56.30 | drachenfels2 | the items on the queue that is |
| 14:56.46 | drachenfels2 | I have this entry: [May 2 15:11:13] DEBUG[23318] sched.c: |1448 | 0x1afe19 | 0xb751a380 | -000027 : 589093 | |
| 14:57.00 | drachenfels2 | that should have been getting run -27 secs ago. |
| 14:57.18 | russellb | there is a unit test to ensure the entries are ordered properly |
| 14:57.32 | drachenfels2 | I put a few extra debuggin lines in, and I can see that chan_sip is running it's queue |
| 14:57.34 | russellb | in trunk anyway |
| 14:57.58 | drachenfels2 | but it's not running this item when it should |
| 14:57.59 | russellb | and main/sched.c is identical between trunk and 1.6.2 ... |
| 14:58.04 | russellb | odd |
| 14:58.19 | pabelanger | drachenfels2: looks like a patch was posted, but the users licenses agreement was rejected. |
| 14:58.23 | drachenfels2 | looking at the code, the only reason I can see that this would happen, is if the queue is out of order |
| 14:59.01 | drachenfels2 | I know... doesn't help me though... so I'm having to work it out myself. I have a customer that is going crazy, |
| 14:59.03 | russellb | did you put in a call to ast_sched_dump() ? |
| 14:59.10 | drachenfels2 | yes. |
| 14:59.20 | russellb | can you pastebin the whole dump? |
| 15:02.18 | drachenfels2 | there's a LOT of data, so I'm going to just paste some of it... |
| 15:03.16 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:03.16 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:03.21 | russellb | actually, you know what ... they aren't going to be in order in that dump |
| 15:03.31 | russellb | the only thing guaranteed and expected is that the one at the very top is the next one to run |
| 15:03.38 | russellb | from there it's going to look a bit random |
| 15:04.08 | putnopvut | yay for a heap |
| 15:06.41 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:06.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:07.07 | drachenfels2 | it is supposed to be in order though... |
| 15:07.17 | russellb | not in 1.6.2 and trunk |
| 15:07.54 | russellb | it uses a max heap to store the scheduler entries |
| 15:08.21 | drachenfels2 | What seems to be happening, is that the device qualify for each device goes into the queue |
| 15:08.42 | drachenfels2 | but if they are out of order, certain qualifies are being executed late, |
| 15:08.58 | drachenfels2 | and so the device suddenly appears to go offline |
| 15:09.40 | russellb | well given a scheduler dump, if there is an entry somewhere not first that should run before the one that is first, that would confirm it |
| 15:09.48 | russellb | is that what you see? |
| 15:11.23 | drachenfels2 | hold on a sec, I've got a 4.5 GB log file to go through..... |
| 15:12.10 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:12.10 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:12.31 | drachenfels2 | In the example I'm trying to grab, the following happens: |
| 15:12.33 | drachenfels2 | [May 2 15:10:41] DEBUG[23318] sched.c: |1448 | 0x1afe19 | 0xb751a380 | 000005 : 590408 | |
| 15:12.33 | drachenfels2 | [May 2 15:10:49] DEBUG[23318] sched.c: |1448 | 0x1afe19 | 0xb751a380 | -000003 : 841314 | |
| 15:12.53 | drachenfels2 | I'm just trying to grab the bits inbetween atm |
| 15:17.09 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 15:31.21 | *** join/#asterisk-dev jtodd (beu2d64ofo@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 15:31.22 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 15:32.16 | drachenfels2 | right, here you go: http://pastebin.com/eedcbuXV |
| 15:33.25 | drachenfels2 | the first block is the particular task, 1448 that isn't run on time, showing the count down to when it should, the second block is what is going on during this time that it should have run |
| 15:34.44 | drachenfels2 | it should have been run at May 2 15:10:46 |
| 15:38.53 | drachenfels2 | instead it runs at [May 2 15:11:13] DEBUG[23318] sched.c: time of callback id:1448 1272809473:357302 |
| 15:38.53 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: end time of callback id:1448 1272809473:357342 |
| 15:39.28 | drachenfels2 | 27 secs late |
| 15:44.32 | drachenfels2 | as far as I understand, the way maxheaps work, all the entries in a maxdump should be in order. If this isn't the case, then the code used to check what needs executing next in the heap is incorrect. |
| 15:45.19 | drachenfels2 | as this assumes the first item on the heap is the next to be executed. if it isn't ready to be executed, it doesn't bother checking anything else in the heap |
| 15:46.06 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 15:47.25 | russellb | looks |
| 15:47.39 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 15:48.12 | russellb | yes. the item at the top of the heap is the next one to execute |
| 15:48.13 | russellb | always |
| 15:48.27 | russellb | it's everything beyond that which is not guaranteed to be in order |
| 15:49.09 | kpfleming | umm... in the scheduler, is there a separate heap for each context? |
| 15:49.35 | russellb | yes |
| 15:49.41 | kpfleming | i assumed so |
| 15:49.49 | drachenfels2 | I'm just reading up on them on wikipedia atm, so, that being the case, is there a problem with the implementation of the maxheap in the scheduler code? |
| 15:50.14 | russellb | as far as I am aware, it's fine |
| 15:50.17 | russellb | but you're saying there is a problem |
| 15:50.40 | kpfleming | he and i were looking into this on saturday, and he has a repeatable issue where a scheduler entry gets missed |
| 15:50.46 | *** join/#asterisk-dev ccesario_ (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 15:51.14 | drachenfels2 | I think it's the cause of the bug I've been looking at |
| 15:51.41 | drachenfels2 | and possibly a few other bugs I've looked at, that have been logged recently. |
| 15:52.36 | file | ummm, in 1.6.2 scheduler items are run in the same thread that handles incoming network traffic and dialog destruction |
| 15:52.37 | file | so depending on things it's possible for those to take some time |
| 15:52.41 | russellb | file: that's the case for all versions still |
| 15:52.59 | kpfleming | drachenfels2: are you seeing *other* entries from the same context being executed in the interval when the missed entry was supposed to be run? |
| 15:53.02 | file | so don't forget to keep that in mind when thinking about this |
| 15:53.31 | drachenfels2 | http://pastebin.com/eedcbuXV |
| 15:53.36 | drachenfels2 | yes |
| 15:53.45 | kpfleming | as file says, the scheduler is supposed to guarantee that the *next* item to execute is the next one executed, but it does not guarantee it will be run on time |
| 15:54.13 | drachenfels2 | I put a few extra statements in, so I can tell when the schduler is being told to run the queue by chan_sip |
| 15:54.30 | drachenfels2 | which item ID it's running, and the time taken for the item. |
| 15:56.00 | drachenfels2 | The id of the item in this case is 1448, it should execute at 15:10:46, the only item that executes at this time is ID:1442 |
| 15:56.23 | kpfleming | but 1442 was put into the queue before 1448 |
| 15:56.33 | kpfleming | what time was it scheduled for relative to 1448? |
| 15:57.45 | drachenfels2 | ID : Sec : Usecs |
| 15:57.45 | drachenfels2 | 1442: 000005 : 271557 |
| 15:57.45 | drachenfels2 | 1448: 000005 : 592312 |
| 15:57.59 | kpfleming | so 1442 is supposed to be run before 1448 then |
| 15:58.23 | drachenfels2 | yes. |
| 15:58.45 | kpfleming | so then you haven't seen a bug, except that scheduler entries are being run late |
| 15:58.48 | kpfleming | but not out of order |
| 15:59.15 | drachenfels2 | then a second later chan_sip tells the queue to run again, but 1448 is not on top, and it should be |
| 15:59.45 | drachenfels2 | that's the only reason I can think of, that it's not running it |
| 15:59.50 | kpfleming | what is on top at that point? |
| 16:00.36 | drachenfels2 | ID : Sec : Usecs |
| 16:00.36 | drachenfels2 | 1448: 000005 : 592312 |
| 16:00.36 | drachenfels2 | 1454: 000006 : 385713 |
| 16:00.44 | drachenfels2 | 1454 is the next item to be executed |
| 16:01.05 | drachenfels2 | not 1448 that should have been |
| 16:01.25 | russellb | but you're showing 1448 above 1454? |
| 16:02.04 | drachenfels2 | sorry, it's just the way I pasted it, 1454 is above 1448 |
| 16:02.15 | russellb | and 1454 is at the very top of the dump? |
| 16:02.51 | drachenfels2 | it must be, otherwise it would get executed at that time. |
| 16:04.42 | russellb | k, well i see the broken entry in your dumps in pastebin now ... |
| 16:06.33 | russellb | this is not going to be fun at all to find ... |
| 16:06.40 | *** join/#asterisk-dev Tim_Toady (~moi@193.92.246.150.dsl.dyn.forthnet.gr) |
| 16:06.53 | drachenfels2 | being very rusty at c, and being new to maxheaps I'm a bit stuck at where to look.... |
| 16:07.26 | drachenfels2 | or even, how to look. got any pointers for me? |
| 16:07.28 | russellb | is sad that all of the unit tests for both the scheduler and heap have not exposed this |
| 16:07.58 | russellb | you could hack tests/test_heap.c until you can make it happen on demand :-) |
| 16:08.10 | drachenfels2 | oh great... |
| 16:08.19 | drachenfels2 | hehe |
| 16:08.22 | drachenfels2 | :( |
| 16:08.46 | leifmadsen | but if you can do that, then you know the tests will find any regressions in that area in the future :) |
| 16:09.02 | russellb | test2() pushes a million random elements on to a heap, makes sure it was constructed properly, and then verifies that the pop back off in the right order |
| 16:09.03 | russellb | :-/ |
| 16:09.29 | russellb | so I suppose one thing that is different is that chan_sip is doing a constant mix of both additions and removals |
| 16:11.10 | kpfleming | yeah... a different use case |
| 16:13.32 | russellb | well thanks for pointing it out |
| 16:13.59 | *** join/#asterisk-dev frawd (~francois@219.Red-83-63-209.staticIP.rima-tde.net) |
| 16:14.38 | frawd | Hello all, anyone knows where I could find that nice guy named "dimas"? |
| 16:56.03 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-hvfdtgtbepqcdvjo) |
| 17:17.49 | drachenfels2 | I think I've got a heap test to demonstrate the bug I've been looking at. |
| 17:18.47 | drachenfels2 | http://pastebin.com/2zV098RU |
| 17:18.52 | *** join/#asterisk-dev diegomad (~mad@190.146.200.120) |
| 17:19.10 | russellb | awesome! |
| 17:19.11 | drachenfels2 | I'm very rusty at c, so could someone have a quick once over? |
| 17:19.37 | russellb | your removal loop looks problematic a bit |
| 17:19.50 | russellb | you could be removing stuff that has already been removed, etc |
| 17:20.03 | drachenfels2 | no, I'm re-adding straight after |
| 17:20.07 | russellb | ah sure enough |
| 17:20.29 | russellb | can you post that as a patch to mantis? |
| 17:20.44 | drachenfels2 | it's failing the ast_heap_verify |
| 17:20.56 | drachenfels2 | I'll give it a go... |
| 17:21.37 | drachenfels2 | I suppose a I should do a similar test for sched as well... |
| 17:21.52 | russellb | yeah, would be good |
| 17:22.07 | russellb | but the bug here is definitely heap code |
| 17:28.22 | *** part/#asterisk-dev hurdman (~ngeek@ys.antredugeek.fr) |
| 17:40.00 | drachenfels2 | could it be in the max_heapify function you think? |
| 17:40.11 | drachenfels2 | it get called after the remove |
| 17:46.38 | russellb | probably |
| 17:49.59 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 17:49.59 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 17:56.11 | drachenfels2 | bug logged, with patch for the test (that currently fails) M17277 |
| 17:59.08 | pabelanger | +1 for test cases! |
| 18:02.18 | drachenfels2 | russell, what is max_heapify supposed to do exactly? |
| 18:02.40 | drachenfels2 | I assume it's to do any re-ordering? |
| 18:07.57 | *** join/#asterisk-dev elguero (~miguel323@h-68-167-124-171.cmbrmaor.static.covad.net) |
| 18:08.19 | Corydon76-dig | Russell is in a meeting at the present time and will return later |
| 18:40.54 | russellb | pulls out his algorithms book to compare code to the algorithm |
| 18:45.18 | kpfleming | oooh |
| 18:46.03 | drachenfels2 | I've already checked the max_heapify function, and it looks correct |
| 18:46.56 | drachenfels2 | I adjusted my test slightly, so that I remove 1 item at a time, and call heap_verify |
| 18:47.08 | drachenfels2 | after 4 calls it heap_verify said it was bad |
| 18:47.18 | drachenfels2 | calls to remove that is. |
| 18:47.43 | drachenfels2 | when pushing and poping, it always does this to element index 1 |
| 18:47.58 | drachenfels2 | however in my test, it is calling element x for removal |
| 18:48.46 | drachenfels2 | although, I'm not testing if element x is actually the correct element to be removed mind... |
| 18:49.06 | drachenfels2 | sorry - if element x is the item I expect to be removed. |
| 18:50.26 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 18:51.22 | drachenfels2 | although, one thing I did think about - on the removal, we pass an index to max_heapify |
| 18:51.39 | drachenfels2 | when pushing and poping, this is always 1 |
| 18:51.54 | drachenfels2 | however, on a random item, it is x |
| 18:52.23 | drachenfels2 | since, we've removed the element x, should we be passing this to max_heapify still ? |
| 18:53.27 | leifmadsen | jmls: I am sad that while writing these release announcements that I have not seen your name in any of the ChangeLogs yet! :) |
| 18:59.43 | pabelanger | r630 |
| 18:59.48 | MuffinMan | [R630] CLI command 'manager show settings' [Pending] Submitted by pabelanger => https://reviewboard.asterisk.org/r/630/ |
| 19:00.08 | pabelanger | I'd like to see if I could merge this into trunk. Russell gave it a +1 |
| 19:03.11 | eliel | R642 |
| 19:03.16 | MuffinMan | [R642] SIP peers & IAX2 users/peers AstData providers and unit testing. [Pending] Submitted by eliel => https://reviewboard.asterisk.org/r/642/ |
| 19:03.41 | eliel | ^ Corydon76-dig, russellb here is the first review request. |
| 19:10.11 | pabelanger | leifmadsen: ping |
| 19:10.15 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 19:10.20 | leifmadsen | pabelanger: ong?! |
| 19:10.23 | pabelanger | m15370 |
| 19:10.26 | MuffinMan | [ready for review] [Asterisk] Core/BuildSystem 0015370: [patch] Repeatedly building the asterisk directory repeatedly downloads the sounds files reported by pprindeville https://issues.asterisk.org/view.php?id=15370 |
| 19:10.45 | leifmadsen | yes sir? |
| 19:11.02 | pabelanger | just a heads up, I think there is a few more things we can do to this patch. There is alot of _manual_ steps required to get it to work properly. |
| 19:11.55 | pabelanger | going to try and submit something night or tomorrow for it. |
| 19:12.14 | leifmadsen | pabelanger: ya, I think you're right -- I'm actually going to drop it back down to Confirmed |
| 19:12.34 | pabelanger | leifmadsen: roger |
| 19:12.53 | pabelanger | I do like the idea of it. |
| 19:13.26 | leifmadsen | agreed |
| 19:17.24 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:22.30 | *** join/#asterisk-dev ccesario_ (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 19:44.03 | philipp64 | leifmadsen: I disagree. What's required is creating the cache directory, and passing in an extra argument to configure. that's it. |
| 19:44.17 | leifmadsen | philipp64: ok, so then you agree with me |
| 19:44.32 | philipp64 | further, Tilghman said these would be useful. not required. |
| 19:44.55 | philipp64 | leifmadsen: no, you think it's not ready, and I think it is. so I don't agree with you. |
| 19:45.20 | leifmadsen | philipp64: I don't like the idea that there could be manual steps required |
| 19:45.33 | leifmadsen | philipp64: if there are things missing, then they are missing, and we should make the patch as feature complete as possible |
| 19:45.50 | philipp64 | It's a *BUILD*. of course there are manual steps. |
| 19:46.00 | philipp64 | why else would configure have about 50 options? |
| 19:46.13 | leifmadsen | 302 redirects to pabelanger |
| 19:46.42 | philipp64 | it's a caching strategy. the problem with caches are they are prone to becoming *stale*. |
| 19:47.01 | philipp64 | therefore, the user needs to explicit acknowledge that he accepts this risk. |
| 19:47.45 | philipp64 | the easiest way to do that is to have an configure flag that's *optional*. this is what we've done. |
| 19:48.10 | philipp64 | read back through the notes that Tilghman put. everything he's written has been addressed, as he's said it should be. |
| 19:48.46 | philipp64 | if pabelanger disagrees with Corydon76-dig's reasoning, he first needs to explain *why*. |
| 19:49.02 | leifmadsen | passes philipp64 a chill pill |
| 19:49.30 | leifmadsen | pabelanger: please add a note for your reasoning on the issue with a list of items that you feel need to be resolved prior to commit |
| 19:50.05 | philipp64 | I don't need a chill pill, I need pabelanger to make comments when the issues are being discussed... not months afterwards when we're seeing some glimmer of progress. |
| 19:50.31 | philipp64 | otherwise, we'll just discuss it to death and never make any progress. |
| 19:50.40 | leifmadsen | welcome to open source |
| 19:50.54 | leifmadsen | if someone has a comment on something he feels that can make something better, I am willing to listen |
| 19:51.17 | leifmadsen | if he does not comment in a reasonable period of time, then we'll place it back in the previous status |
| 19:51.24 | philipp64 | it was a lot easier in the early 80's when there were about 5 people in the whole world who actually cared about what you were working on at any given time. |
| 19:52.03 | philipp64 | burden of proof: I say leave it "ready for review" unless his argument suggests otherwise. |
| 19:53.16 | leifmadsen | honestly, the status in this case pretty much means nothing |
| 19:53.16 | leifmadsen | if tilghman wanted to commit the issue, it'd have already been done |
| 19:53.19 | leifmadsen | spending another couple of hours in Confirmed status isn't going to kill any kittens |
| 19:53.33 | philipp64 | good point. Tilghman? anything you see that's missing that you've not yet annotated? |
| 19:53.48 | pabelanger | waves to leifmadsen |
| 19:53.49 | leifmadsen | tilghman went home for the day to deal with massive flooding in and around his area |
| 19:53.50 | pabelanger | sup! |
| 19:53.54 | pabelanger | ;) |
| 19:54.00 | pabelanger | m15370#121233 |
| 19:54.03 | MuffinMan | [15370#0121233] Commented by pabelanger on 2010-04-30 at 11:41: Few updates / suggestions. |
| 19:54.03 | MuffinMan | .. |
| 19:54.03 | MuffinMan | ..- Create ./configure option to disable/enable caching for sounds. |
| 19:54.03 | MuffinMan | .. |
| 19:54.03 | MuffinMan | ..- Default SOUNDS_CACHE_DIR=cache with the ability to override. |
| 19:54.06 | MuffinMan | .. |
| 19:54.08 | MuffinMan | ..- Is copying the .tar.gz from the CACHE_DIR back to sounds really required? Simply install sounds directly from CACHE_DIR (trivial change to save HDD space). |
| 19:54.09 | leifmadsen | pabelanger: hey :) please comment on the issue about what else you feel needs resolving |
| 19:54.11 | MuffinMan | .. |
| 19:54.14 | MuffinMan | ..- Enable build_tools/prep_tarball to use this logic (more to help with people building software packages [IE: dpkg]) |
| 19:54.48 | pabelanger | My comments / suggestions are in the issue. |
| 19:55.25 | pabelanger | could we not create a toggle flag to enable / disable caching of the sound files? |
| 19:56.10 | pabelanger | Which would then set the cache_dir |
| 19:56.35 | pabelanger | Also, do we really need to copy the .tar.gz from the cache_dir back into the asterisk dir? |
| 19:57.02 | pabelanger | I know it is trivial, but it does save some HDD space |
| 19:57.10 | philipp64 | How is ./configure SOUNDS_CACHE_DIR=xxx not a togglable flag? I truly don't understand what you're asking for. |
| 20:00.52 | philipp64 | there are side-effects to using "copy-outs" or links that make diagnosing things difficult and interfere with reproducibility. |
| 20:01.08 | philipp64 | the point of this bug was to save *bandwidth*, and allow on to build offline. |
| 20:01.13 | philipp64 | it does exactly that. |
| 20:01.37 | philipp64 | if you want to file a separate bug that claims that building asterisk takes too much room, then that's your perrogative. |
| 20:09.57 | philipp64 | for what it's worth, we also use the same sounds cache when building several builds in parallel. |
| 20:10.29 | philipp64 | using symlinks would exponentially increasing the probability that two parallel builds would corrupt the same sound file. |
| 20:11.03 | philipp64 | we're going for reproducibility here. |
| 20:15.13 | pabelanger | philipp64: So, I go back to my original question. Why do we have to copy the .tar.gz from the CACHE_DIR back into the Asterisk source directory? Simple check the .sha1 file against the .tar.gz file, then uncompress |
| 20:17.26 | philipp64 | pabelanger: have you looked at the patch? |
| 20:17.43 | philipp64 | it's basically a rewrite of about 50% of that makefile. |
| 20:18.12 | philipp64 | it introduces a layer of abstraction by using a length macro, with a fair amount of conditional expansion. |
| 20:18.46 | philipp64 | it is *very* easy to get wrong, and I was happy to be able to get it right the first time. |
| 20:19.39 | philipp64 | doing what you're suggesting would add a new potential pathology (two different builds trying to update the same cache at the same time). |
| 20:20.14 | philipp64 | it would also mean that you couldn't do a "cp -a" of a snapshot, or a "tar", and move it elsewhere, and expect it to build. |
| 20:21.21 | philipp64 | I was trying to solve a very specific, very limited problem. I was not trying to perfect or optimize the build system in all scenarios, because I'd probably overlook a scenario and end up introducing unintended consequences and breaking things for someone else. |
| 20:21.32 | philipp64 | I was trying to keep it as simple as possible. |
| 20:22.05 | pabelanger | philipp64: I would suggest a proxy server, simple. |
| 20:22.36 | philipp64 | now there are probably smarter people on this list than me that could have solved my issue, your issue, and 5 other ones we haven't even discussed... |
| 20:23.00 | philipp64 | but I drew the short straw, so I fixed it with the resources and knowledge I have. without a doubt someone else could have done it better. |
| 20:23.16 | philipp64 | but "the best is the enemy of the good", and this is good enough. |
| 20:24.01 | pabelanger | philipp64: I agree with you, caching sounds is a good thing. I don't understand the problem of enhancing it. |
| 20:24.20 | philipp64 | and I don't understand the problem with fixing two different issues in two different patches. |
| 20:24.46 | philipp64 | I'm just trying to KISS. |
| 20:25.12 | philipp64 | no one has ever had an issue with my trying to over simplify things. |
| 20:25.55 | pabelanger | Either way, I'll play with it more over the next few day and submit a patch when I can. |
| 20:34.00 | philipp64 | I'm sorry, a patch for what? |
| 20:36.27 | philipp64 | what's is "wrong" with the patch as it stands now... other than it doesn't address a separate issue of disk space which you're bringing up? |
| 20:38.06 | philipp64 | and equally, why is "phased, incremental change" not a good methodology to pursue here? |
| 20:41.15 | philipp64 | well, it's hard to address issues when those issues aren't being stated. |
| 20:41.40 | seanbright | pabelanger: ^^^ |
| 20:46.04 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 20:49.40 | pabelanger | RL aggro, wait one. |
| 20:55.37 | pabelanger | philipp64: ok, resubmit your patch against trunk and I will retest it. Currently your 2 patches are against different asterisk versions. I can retest your patch tonight, I'll create a new issue for improved functionality, assuming we merge it. |
| 20:57.36 | eliel | Corydon76-dig: russellb: google docs spreadsheet update with the "complete" idea of what i am going to complete in the gsoc |
| 21:06.11 | *** part/#asterisk-dev mnick86 (~Matthias@whhem00016.cip.uni-regensburg.de) |
| 21:09.46 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 21:09.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:16.07 | russellb | drachenfels2: see the mantis issue |
| 21:16.10 | russellb | i attached a patch |
| 21:24.46 | philipp64 | pabelanger: I can't. We have issues building in trunk that we've been waiting for Russell to have free cycles to address. |
| 21:25.32 | philipp64 | so I could ensure that the patch applies to trunk, but don't have an easy way to do a build and verify it. |
| 21:25.47 | *** join/#asterisk-dev Dovid (~annon@213.8.121.90) |
| 21:27.41 | philipp64 | just tried the 1.6.2 patches... they apply to trunk just fine. |
| 21:31.21 | kpfleming | philipp64: you don't have any linux systems available with normal toolchains to try compiling with? |
| 21:32.01 | philipp64 | I could build one... |
| 21:32.12 | kpfleming | what do you build astlinux on? |
| 21:32.21 | philipp64 | FC12. |
| 21:32.43 | kpfleming | which has a toolchain... which means you don't really need to build a separate system :-) |
| 21:33.05 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 21:33.05 | philipp64 | (a very skinny FC12... we remove a lot of utilities so they don't conflict with the cross-compilation versions) |
| 21:33.10 | kpfleming | ahh |
| 21:33.29 | philipp64 | otherwise, pkgconfig bites us in the butt. |
| 21:33.31 | *** part/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 21:34.05 | philipp64 | butt I can install into a chroot'd fedora. |
| 21:34.17 | philipp64 | *but ... damn I need a new keyboard |
| 21:34.43 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 21:34.44 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 21:41.12 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 21:41.12 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 21:45.02 | philipp64 | kpfleming: building now in a chroot. |
| 21:45.06 | philipp64 | seeing: build_tools/make_build_h: line 6: -un: command not found |
| 21:45.09 | philipp64 | is that a known issue? |
| 21:46.18 | philipp64 | seems like ${ID} isn't being set... |
| 21:46.44 | philipp64 | <PROTECTED> |
| 21:47.03 | *** join/#asterisk-dev Ta^3 (~tacvbo@189.146.183.88) |
| 21:51.24 | seanbright | i feel like that was recently fixed by Qwell |
| 21:52.11 | kpfleming | he removed setting of ${ID} completely.. but i bet he didn't realize it was needed for construction of the version string |
| 21:53.34 | kpfleming | he has left for the day to take care of some of things, so he won't see this |
| 21:58.11 | seanbright | ${ID} rm -rf / |
| 21:58.16 | seanbright | that'll fix it |
| 21:58.29 | seanbright | (that was a joke - do not attempt) |
| 21:58.43 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 22:09.23 | *** join/#asterisk-dev pabelanger (~pabelange@CPE0013f7abc09a-CM0013f7abc096.cpe.net.cable.rogers.com) |
| 22:17.43 | *** join/#asterisk-dev akshayb (~b49531e2@gateway/web/freenode/x-yzrzhybjxfklsddz) |
| 22:26.35 | philipp64 | btw: I'm seeing bad checksums... |
| 22:26.37 | philipp64 | Bad checksum: asterisk-moh-opsound-ulaw.tar.gz |
| 22:27.13 | philipp64 | did anyone update the files and forget to deposit fresh checksums? |
| 22:27.44 | philipp64 | can someone else verify that this one, and asterisk-moh-opsound-wav.tar.gz, are incorrect? |
| 22:29.05 | philipp64 | hmmm... actually, the unversioned files don't have checksums. is that an oversight? |
| 22:30.28 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 22:30.53 | kpfleming | the unversioned files are just symlinks to the current versioned file |
| 22:43.32 | philipp64 | would it make sense to have symlinks to the accompanying checksums in that case? |
| 22:44.28 | kpfleming | no, i don't think so |
| 22:44.42 | kpfleming | because if someone downloads it, the corresponding file could change, since it's not versioned |
| 22:44.51 | kpfleming | people who care about that stuff really should be using the versioned files |
| 22:45.22 | philipp64 | fyi: as was suggested, I patched trunk, ran my "rm configure ; ./bootstrap.sh ; mkdir sc ; ./configure SOUNDS_CACHE_DIR=`pwd`/sc ; make ; make sounds ; make clean ; make ; make sounds" |
| 22:45.32 | philipp64 | it worked fine. |
| 22:46.19 | philipp64 | at the time that I wrote the patch, I don't think the opsound files were versioned. |
| 22:46.31 | kpfleming | very possible |
| 22:48.22 | philipp64 | actually, the extra sounds and the core sounds are versioned in sounds/Makefile, but the opsound/MOH sounds aren't. |
| 22:48.34 | philipp64 | so... you kind of have to have symlinks for the checksums. |
| 22:53.02 | philipp64 | should I file a bug? |
| 22:53.24 | philipp64 | to have versioning introduced for MOH files in sounds/Makefile, I mean... |
| 22:59.19 | kpfleming | we intentionally did not bother, because there will likely never be new versions of them. they are what they are. |
| 23:08.57 | philipp64 | I'm confused... so why is it symlinked then? |
| 23:13.19 | kpfleming | because the actual files live in releases/ but there are people who want to access them from the directory above |
| 23:14.50 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 23:14.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:31.11 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 23:36.09 | *** join/#asterisk-dev lmsteffan (~lmsteffan@reef.ac-noumea.nc) |
| 23:42.11 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 23:42.11 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:46.46 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |