| 00:32.17 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:32.17 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 00:44.02 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 00:47.59 | *** join/#asterisk-dev snuff-work (n=aaa@120.17.137.143) |
| 00:47.59 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:26.47 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 01:43.03 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/professional/jeffg) |
| 03:12.22 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 03:23.27 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/professional/jeffg) |
| 03:40.50 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:40.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:43.48 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 03:43.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 03:45.44 | *** join/#asterisk-dev DarkRift (n=dark@modemcable015.68-200-24.mc.videotron.ca) |
| 04:29.00 | *** join/#asterisk-dev DarkRift (n=dark@modemcable015.68-200-24.mc.videotron.ca) |
| 05:27.05 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 05:27.05 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 05:31.22 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 05:31.22 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 06:02.45 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 06:09.44 | *** join/#asterisk-dev errotan (n=errotan@a1726.adsl.pool.eol.hu) |
| 06:45.22 | *** join/#asterisk-dev natlonehat (n=natloneh@202.170.42.67) |
| 07:02.43 | *** join/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 08:09.36 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:17.58 | *** join/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 11:00.42 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:00.42 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:06.45 | *** join/#asterisk-dev DarkRift (n=dark@modemcable015.68-200-24.mc.videotron.ca) |
| 11:16.19 | *** join/#asterisk-dev msetim (n=setim@189.4.48.141) |
| 11:25.44 | atis_work | good morning |
| 11:25.53 | atis_work | does anybody knows something about "ERROR[4305]: acl.c:472 ast_ouraddrfor: Cannot create socket" |
| 11:39.50 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 12:09.21 | snuff-home | atis_work: did u check the number of sockets currently in use when that occurred? |
| 12:10.30 | snuff-home | like.. netstat -anp | grep asterisk | wc -l |
| 12:32.20 | atis_work | snuff-home: unfortuneately no |
| 12:32.39 | atis_work | but restarting asterisk solved it |
| 12:32.46 | atis_work | i was looking for some issue and possible progress |
| 12:32.47 | snuff-home | mm worth a look next time |
| 12:32.52 | atis_work | sure :) |
| 12:33.19 | snuff-home | there is that unclosed issue about hung sockets.. which falves said was 1/2 fix |
| 12:33.31 | snuff-home | by a patch on the issue |
| 12:34.28 | atis_work | you probably mean 15627 |
| 12:34.35 | atis_work | i found it so far |
| 12:34.42 | snuff-home | probably.. |
| 12:34.46 | snuff-home | M15627 |
| 12:34.50 | MuffinMan | [ready for review] [Asterisk] Core/Netsock 0015627: [patch] Asterisk runs out of sockets reported by falves11 (Karma: -1.5) https://issues.asterisk.org/view.php?id=15627 |
| 12:34.56 | snuff-home | yer that's it |
| 12:35.22 | snuff-home | looks @ his unloved patch for fixing xmldocs on non *nix platforms |
| 12:35.59 | atis_work | does the people on non *nix platforms read docs at all? |
| 12:36.37 | atis_work | snuff-home: should i try your patch: bug15714_ver1.6.2.diff |
| 12:36.52 | snuff-home | well its solaris.. unsure if osx / bsd suffer same issue |
| 12:37.23 | atis_work | isn't solaris and bsd considered *nix? |
| 12:37.42 | snuff-home | yes.. but they dont end in nix ;) |
| 12:38.31 | atis_work | wow, this is cool: http://upload.wikimedia.org/wikipedia/commons/d/d9/Unix_history-simple.en.svg |
| 12:39.12 | snuff-home | is that the one with the SVG showing how SVR4 / SYSV branched? |
| 12:40.11 | atis_work | i don't understand all the arrows, but it shows System III and System V |
| 12:40.24 | snuff-home | mm :) |
| 12:40.55 | snuff-home | basically u can see how they progressed to their current state :) |
| 12:41.27 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/professional/jeffg) |
| 12:47.22 | atis_work | snuff-home: i have `p->needdestroy = 1;` instead of `pvt_set_needdestroy(p, "autodestruct");` that's why it rejects |
| 12:49.22 | snuff-home | k well u can alter urself :) |
| 12:49.25 | atis_work | yeah |
| 12:49.36 | atis_work | it's cool to see how many times that changed between versions :D |
| 12:50.26 | snuff-home | i didn't make the original patches.. dont often do |
| 12:50.46 | snuff-home | just provide updates to possible unloved issues to make it work |
| 12:50.53 | snuff-home | and patch cleanly |
| 12:51.18 | snuff-home | i think the biggest one i took on was the enhancement of ENUM |
| 13:52.10 | atis_work | umm, any ideas about this one? http://pastebin.ca/1659521 |
| 13:52.30 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:54.04 | atis_work | what's the "alert pipe" doing? |
| 14:19.01 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/professional/jeffg) |
| 14:31.21 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:31.21 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:43.36 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:43.36 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:45.17 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@81.218.155.145) |
| 14:45.17 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 14:57.27 | atis_work | Corydon76-dig: ping |
| 14:57.33 | Corydon76-dig | pong |
| 14:58.53 | atis_work | Corydon76-dig: this seems to be related to queue, i wonder if it could be related to refcount you're trying to fix in M15982 |
| 14:59.12 | atis_work | Corydon76-dig: http://pastebin.ca/1659586 |
| 14:59.13 | Corydon76-dig | atis_work: are you using chanspy? |
| 14:59.18 | atis_work | yes |
| 15:00.44 | Corydon76-dig | I've seen these problems before, as has jpeeler. It's not necessarily chanspy, but what's behind ChanSpy, the audiohooks, which are causing this issue |
| 15:01.34 | leifmadsen | M16169 |
| 15:01.36 | MuffinMan | [feedback] [Asterisk] Channels/chan_local 0016169: full system crash every other day reported by moshe (Karma: neutral) https://issues.asterisk.org/view.php?id=16169 |
| 15:01.41 | leifmadsen | Corydon76-dig: is that related at all? |
| 15:01.54 | leifmadsen | oops |
| 15:01.56 | leifmadsen | M16196 |
| 15:01.58 | MuffinMan | [feedback] [Asterisk] Core/General 0016196: Core dump in audio_audiohook_write_list reported by atis (Karma: +18.00) https://issues.asterisk.org/view.php?id=16196 |
| 15:02.00 | leifmadsen | that one |
| 15:02.10 | Corydon76-dig | leifmadsen: Yes, verry possible |
| 15:02.19 | leifmadsen | Corydon76-dig: should I relate it to any other issues? |
| 15:02.35 | leifmadsen | I'm not sure the issue number you're workin on |
| 15:02.36 | Corydon76-dig | leifmadsen: Let's not go there yet |
| 15:02.39 | leifmadsen | ok sounds good |
| 15:02.46 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:02.46 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:02.52 | leifmadsen | omg jpeeler! |
| 15:02.57 | Corydon76-dig | Solve the problem in THAT issue, then see if the solution fixes others |
| 15:03.14 | leifmadsen | works for me |
| 15:03.49 | jpeeler | leifmadsen: morning sir |
| 15:03.58 | atis_work | umm, sorry, did i missed anything? |
| 15:04.04 | Corydon76-dig | I find that when you relate too many issues initially, it gets distracting to solve any particular one |
| 15:04.09 | atis_work | i can try running tests without chanspy |
| 15:04.38 | leifmadsen | fair enough! |
| 15:04.42 | Corydon76-dig | atis_work: while that would tell us definitively that that's where the problem lies, I think we've already determined that |
| 15:05.00 | Corydon76-dig | atis_work: but I'd like you to try that patch, if you haven't already |
| 15:05.20 | atis_work | M16169? |
| 15:05.22 | Corydon76-dig | I have yet to read my email yet this morning; you caught me before then |
| 15:05.32 | atis_work | oh, ok |
| 15:05.34 | leifmadsen | atis_work: no, that issue was just a typo and totally unrelated |
| 15:05.40 | atis_work | hehe, ok :) |
| 15:06.04 | atis_work | you type them manually? |
| 15:08.46 | atis_work | Corydon76-dig: so, any idea about _IO_vfprintf_internal - is it related to queue refcounts, or should i open completely new issue? |
| 15:09.07 | leifmadsen | atis_work: I type the M##### manually, yes |
| 15:10.02 | Corydon76-dig | atis_work: No idea |
| 15:15.09 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 15:15.10 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:15.50 | atis_work | leifmadsen: you just had to ask for "technologies invloved" heh :p |
| 15:15.59 | leifmadsen | of course :) |
| 15:16.13 | leifmadsen | more information is useful; less information is useless |
| 15:16.16 | atis_work | it's too much of everyting.. queue, local channels, answer macros, monitor, chanspy |
| 15:16.32 | atis_work | i can probably think some more.. |
| 15:16.44 | leifmadsen | well, Corydon76-dig thinks he kinda knows where the issue may lie, so when he has a fix, then you can test his patches and see if it resolves the issue |
| 15:16.55 | atis_work | oh, great :) |
| 15:17.02 | atis_work | it comes up every 10-20 minutes now |
| 15:17.33 | leifmadsen | my work here is done |
| 15:21.12 | atis_work | don't worry, i have some 5 more different backtraces :) |
| 15:23.34 | *** join/#asterisk-dev moy (n=moy@74.12.130.190) |
| 15:26.42 | atis_work | I wonder is it worth to post rare backtraces at all |
| 15:26.51 | atis_work | if i can't reproduce them.. |
| 15:27.51 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:27.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:32.47 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:39.06 | atis_work | I have two more coredumps that were occuring only once so far.. http://pastebin.ca/1659627 |
| 16:03.24 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:03.24 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:13.12 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 16:13.12 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 16:18.10 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:24.20 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:30.20 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:32.13 | atis_work | Corydon76-dig: some timestamps in /tmp/refs would be nice.. not it's one big file with lot of different info |
| 16:32.34 | Corydon76-dig | atis_work: there ARE timestamps, actually |
| 16:32.48 | atis_work | how do i read them and relate to crash? |
| 16:32.58 | Corydon76-dig | They are in epoch time |
| 16:33.06 | atis_work | and hex.. huh\ |
| 16:33.42 | Corydon76-dig | Or maybe not |
| 16:33.49 | Corydon76-dig | I'm thinking of some other debug file |
| 16:33.59 | atis_work | doesn't look like |
| 16:34.40 | atis_work | i have already 2 gigabytes in it |
| 16:35.18 | Corydon76-dig | holy |
| 16:38.42 | atis_work | ok, i have out-of-sockets issue again |
| 16:38.57 | atis_work | however /proc/net/sockstat shows 1007 UDP used |
| 16:39.13 | atis_work | acl.c:472 ast_ouraddrfor: Cannot create socket |
| 16:43.54 | Corydon76-dig | What's your file descriptor limit? |
| 16:44.10 | Corydon76-dig | (ulimit -n) |
| 16:44.43 | atis_work | hmm, that could be it.. it's 1024 |
| 16:45.15 | atis_work | Corydon76-dig: i'll add some timestamps to /tmp/refs and retry again later |
| 16:49.56 | *** join/#asterisk-dev manick_ (n=mnick@nat/digium/x-hfccbiivhzywyzhw) |
| 16:54.07 | *** join/#asterisk-dev jtodd (i=l01ch5z2@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 16:54.08 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 17:04.47 | russellb | Corydon76-dig: ping |
| 17:05.45 | Corydon76-dig | pong |
| 17:06.38 | russellb | I was looking around on reviewboard, and I noticed that the data API code review hadn't been updated. DId you forget to publish your review? |
| 17:07.12 | Corydon76-dig | Mmm, probably |
| 17:08.34 | Corydon76-dig | Is it related to some session cookies? |
| 17:08.47 | TheDavidFactor | leifmadsen, ping |
| 17:08.47 | russellb | No, it's just tied to your user. |
| 17:09.05 | leifmadsen | TheDavidFactor: pong |
| 17:09.36 | Corydon76-dig | Doesn't seem to work that way, here |
| 17:09.46 | russellb | What do you mean? |
| 17:09.51 | leifmadsen | TheDavidFactor: please leave your message after the tone, and a support engineer will respond as soon as humanly possible |
| 17:09.58 | Corydon76-dig | I don't have a publish button |
| 17:10.06 | Corydon76-dig | I've restarted since then |
| 17:10.12 | leifmadsen | bbiab, just need to grab lunch and do about 15 mins of running around (in circles) |
| 17:10.28 | russellb | Corydon76-dig: When you go to that code review, you should see something telling you that you have a pending review. |
| 17:10.45 | Corydon76-dig | I do not |
| 17:10.47 | TheDavidFactor | I just has a chat with manick and he brought up an issue with ExternalIVR that I had not run into before. It would require a non-backwards compatable, but I believe minor, fix. What is the proper way of working through this? |
| 17:11.30 | *** part/#asterisk-dev ricko73 (n=dhartman@wilug/newlug/ricko73) |
| 17:12.25 | russellb | Corydon76-dig: well they go into the database as you work on the review. There is nothing in the database from you. |
| 17:13.11 | Corydon76-dig | I'll rework it then |
| 17:14.03 | *** join/#asterisk-dev outtolunc (n=me@98.248.96.110) |
| 17:16.29 | TheDavidFactor | this something that the reviewboard should be used for? |
| 17:16.48 | russellb | I think ReviewBoard is fine |
| 17:16.57 | russellb | the tough part on that issue is just deciding what to change (if anything) |
| 17:18.12 | Corydon76-dig | Well, revert the internal rework of app_queue and keep just the data export part |
| 17:18.52 | russellb | that was to TheDavidFactor, heh, sorry Corydon76-dig |
| 17:18.56 | Corydon76-dig | It was a good way to verify that the API was sound, but it's not the most efficient scheme for core internals |
| 17:19.07 | russellb | Corydon76-dig: agreed |
| 17:19.33 | Corydon76-dig | but otherwise, I'm happy with the result |
| 17:19.39 | TheDavidFactor | well we came up with two options. First, the DTMF tones A-D are not used in normal telco operations and most telcos in fact block them. (I believe this is why it's never been raised as a bug) so we both thought that adding another tag X (eXtended DTMF) and sending the A-D DTMF as the data part of the the X tag. The other is documenting the fact that if a D tag doesn't have a data field then... |
| 17:19.41 | TheDavidFactor | ...it is a DTMF digit. |
| 17:21.23 | TheDavidFactor | I lean toward the additional tag because it removes the tag collision and I have strong suspision that no one would be affected by that. |
| 17:21.34 | russellb | okay :-) |
| 17:21.37 | ctooley | TheDavidFactor, X is already in use |
| 17:22.15 | TheDavidFactor | not according to the documentation |
| 17:22.21 | ctooley | TheDavidFactor, I'm not sure if it's "in use" in what's already committed to Trunk, but I have a large number of changes to commit that I have been working on in my "copious free time" |
| 17:22.23 | TheDavidFactor | I haven't searched the code |
| 17:22.30 | russellb | *gasp* |
| 17:23.26 | TheDavidFactor | that's another question, I guess, should code match documentation or should documentation match code? |
| 17:23.39 | manick_ | what if we use 'DTMF' as datavalue ? |
| 17:23.44 | ctooley | let me look at a clean Digium tree. I think X might have been re-implemented at Digium under another tag |
| 17:24.02 | ctooley | manick_, What do you mean by datavalue? |
| 17:24.22 | manick_ | maybe dtmf-A is sent > A, timestamp, DTMF |
| 17:24.49 | ctooley | russellb, did svn web browsing ever get turned back on? |
| 17:24.57 | russellb | yes |
| 17:25.11 | atis_work | huh, silly question: how do i include ast_localtime in astobj2.c |
| 17:25.26 | russellb | atis_work: grep ast_localtime include/asterisk/* |
| 17:25.27 | atis_work | #include "asterisk/localtime.h" doesn't seem to work |
| 17:25.37 | TheDavidFactor | X is used and a command, but not an event |
| 17:25.43 | TheDavidFactor | I just checked the source ;-) |
| 17:25.51 | TheDavidFactor | *as a command |
| 17:26.26 | Corydon76-dig | atis_work: I don't know why it wouldn't |
| 17:26.38 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 17:26.38 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 17:27.22 | ctooley | TheDavidFactor, Correct. What are you trying to solve? |
| 17:28.06 | ctooley | notes that X is "deprecated" in favor of E. |
| 17:28.11 | TheDavidFactor | when * get's a DTMF and ExternalIVR sends it as an event, it send (DTMF),timestamp |
| 17:28.30 | TheDavidFactor | so the D DTMF gets sent as D,1234... |
| 17:29.03 | TheDavidFactor | D is also used to indicate a droped file, which is sent as D,1234...,file |
| 17:29.30 | ctooley | TheDavidFactor, yeah, original design flaw. :-) |
| 17:29.58 | ctooley | looks around whistling. :-) |
| 17:30.13 | TheDavidFactor | well A-D are not normally used. in fact most telcos block them because they can be used for signaling |
| 17:30.31 | ctooley | TheDavidFactor, I wouldn't tell that to my military customers. :-) |
| 17:30.47 | TheDavidFactor | I recognize that :-) |
| 17:31.03 | TheDavidFactor | but how many military customers are using ExternalIVR? |
| 17:32.09 | ctooley | Well, we could use some sort of extended dtmf signaling to pass those, but to keep to the protocol standard it would need to be a single character. |
| 17:33.06 | ctooley | TheDavidFactor, betweeen 100K and 200K calls/day for one product, depending on the day. |
| 17:33.34 | TheDavidFactor | I'm suggesting X,timestamp,(DTMF) so for A you would see X,1234....,A for D X,1234....,D |
| 17:34.03 | ctooley | one sec |
| 17:34.48 | TheDavidFactor | the alternative is to simply document the collision |
| 17:34.53 | ctooley | Well, there's technically a bug in the deprecated X command |
| 17:35.27 | TheDavidFactor | you can use the same tag for an event and a command that's not an issue |
| 17:35.29 | ctooley | It should behave like the E command and send an E event to acknowledge the exit. |
| 17:36.01 | ctooley | See the difference between X at line 754 and E at line 759 |
| 17:36.37 | TheDavidFactor | I don't have a problem looking at that, but that's not really the issue with DTMF tones that we're discussing right now is it? |
| 17:37.11 | ctooley | Well, it is if we use the X event, I'd suggest using a different event tag. |
| 17:38.18 | atis_work | aha, the problem is building utils/hashtest2 which includes astobj2 but can't find asterisk/localtime.h |
| 17:38.44 | ctooley | Technically it works fine, from a documentation standpoint it works fine, from the standpoint of someone not constantly looking at the documentation the X command has a bug (because it doesn't respond with the appropriate X event) and we're going to send an X event for a different reason. Confusing to the developer. |
| 17:38.46 | TheDavidFactor | there are already cases where you have an event and a command that are completely separate. Take H & E for example |
| 17:39.19 | ctooley | E and H are Exit and Hangup in both directions |
| 17:39.28 | TheDavidFactor | well, X is deprecated, should it be maintained? |
| 17:39.36 | TheDavidFactor | E & H aren't |
| 17:40.51 | ctooley | Where is E sent when it isn't an Exit event or H sent when it's not a Hangup event? |
| 17:41.03 | TheDavidFactor | ok, I see your point |
| 17:41.55 | ctooley | X is deprecated, it could be removed, but I'd still vote for another event tag for DTMF since I'd prefer to see at least one major rev where X is gone before it got reused. |
| 17:42.20 | ctooley | Otherwise it "works", just in a broken manner. |
| 17:42.33 | TheDavidFactor | That makes sense |
| 17:44.01 | TheDavidFactor | are you supporting clients using ExternalIVR? |
| 17:44.09 | *** join/#asterisk-dev ecrane (n=ecrane@o1-69-19-166-10.static.o1.com) |
| 17:44.27 | leifmadsen | he's the only other person I know who uses it :) |
| 17:44.36 | TheDavidFactor | hehe |
| 17:44.45 | russellb | he was part of getting it written in the first place :-) |
| 17:45.00 | ctooley | TheDavidFactor, Unfortunately it pains me to admit I was one of the two original designers that contracted Digium to build it originally. I have implemented most of the features since then, though people at Digium clean up the mess I make of it. |
| 17:45.46 | ctooley | We needed it for a specific purpose and under a horrid time constraint that led to poor design decisions and bad naming. :-) |
| 17:46.11 | TheDavidFactor | well, there was support for socket support built in but never completed. Do you use the socket side of it? |
| 17:46.34 | ctooley | But, I run roughly 500K calls/day through it in it's intended manner and 25M calls/day through it by making use it in a non-traditional manner. |
| 17:46.50 | ctooley | TheDavidFactor, Again, my poor work is at fault. |
| 17:47.14 | russellb | 25M calls/day ... *head explodes* |
| 17:47.21 | ctooley | I wrote the socket code, though I don't believe it was ever updated to make use of the TCP code that's in asterisk. |
| 17:47.28 | TheDavidFactor | well you beat the pants of my company. we only run maybe 1000 calls through it |
| 17:47.31 | ctooley | russellb, Griffin routing engine, no audio. |
| 17:47.39 | russellb | still, awesome anyway :-) |
| 17:48.13 | TheDavidFactor | well, I've got patches out there that fix the socket stuff |
| 17:48.21 | ctooley | 500K calls/day where it's actually an IVR, 25M calls a day where it's a glorified conduit from SIP to TCP. |
| 17:48.24 | TheDavidFactor | we're using it in socket mode |
| 17:48.32 | ctooley | TheDavidFactor, that would be awesome |
| 17:48.49 | TheDavidFactor | I was just wondering if it had ever worked |
| 17:49.26 | ctooley | TheDavidFactor, Everything we run is still going through a highly modified 1.4.19.1 |
| 17:49.50 | ctooley | HIGHLY modified. ;-) |
| 17:49.56 | TheDavidFactor | ;-) |
| 17:50.58 | ctooley | russellb, we have 6 routing servers each plugging along at around 200 calls/sec of routing at peak. At the moment one of them is down so we're doing a little more per server. |
| 17:51.13 | russellb | That's pretty awesome. :-) |
| 17:51.36 | TheDavidFactor | russellb is going to let me maintain ExternalIVR so I want to make sure I don't blow up any current users and don't do anything stupid. |
| 17:52.02 | ctooley | TheDavidFactor, that's cool. If you send me over the patches you have I can put them through some paces. |
| 17:52.28 | TheDavidFactor | M16147 |
| 17:52.30 | MuffinMan | [assigned] [Asterisk] Applications/app_externalivr 0016147: [patch] ExternalIVR does not return event for file when file playing is interrupted reported by thedavidfactor (Karma: neutral) https://issues.asterisk.org/view.php?id=16147 |
| 17:52.33 | ctooley | We have a test environment that lets us run 2-300 calls per second through it. |
| 17:53.02 | TheDavidFactor | M16174 |
| 17:53.04 | MuffinMan | [ready for testing] [Asterisk] Applications/app_externalivr 0016174: [patch] ExternalIVR does not handle arguments in a consistant manner reported by thedavidfactor (Karma: neutral) https://issues.asterisk.org/view.php?id=16174 |
| 17:53.16 | TheDavidFactor | M16121 |
| 17:53.19 | MuffinMan | [ready for review] [Asterisk] Applications/app_externalivr 0016121: [patch] ExternalIVR TCP client functionality does not work reported by thedavidfactor (Karma: neutral) https://issues.asterisk.org/view.php?id=16121 |
| 17:53.24 | TheDavidFactor | M16123 |
| 17:53.26 | MuffinMan | [ready for review] [Asterisk] Applications/app_externalivr 0016123: [patch] ExternalIVR trapping non-existant files does not work reported by thedavidfactor (Karma: neutral) https://issues.asterisk.org/view.php?id=16123 |
| 17:54.26 | TheDavidFactor | some of the patches are a little hokey as far as having the proper path, but I was waiting until I could modify issues before I corrected the patches. I haven't had time yet today |
| 17:54.29 | manick_ | 16147, I've a patch sofar, currently testing |
| 17:54.42 | ctooley | TheDavidFactor, The TCP code needs to use the standard TCP support in Asterisk, I don't think it ever got updated to use that. |
| 17:55.46 | TheDavidFactor | I believe it was in revision 225445 |
| 17:56.31 | TheDavidFactor | or 151101 |
| 17:57.30 | ctooley | TheDavidFactor, What are you running through EIVR? |
| 17:57.47 | TheDavidFactor | Data collection IVRs |
| 17:58.22 | ctooley | We have open sourced our IVR engine that is built around using EIVR. Have you taken a look at that? |
| 17:59.12 | TheDavidFactor | no, got a URL? |
| 17:59.24 | russellb | simplified.org! |
| 17:59.27 | TheDavidFactor | M16174 |
| 17:59.28 | ctooley | Though manick_ pointed out that the "release" version download is broken, the SVN is there. |
| 17:59.30 | MuffinMan | [ready for testing] [Asterisk] Applications/app_externalivr 0016174: [patch] ExternalIVR does not handle arguments in a consistant manner reported by thedavidfactor (Karma: neutral) https://issues.asterisk.org/view.php?id=16174 |
| 17:59.37 | ctooley | russellb, you remembered, how nice. |
| 17:59.45 | TheDavidFactor | any chance of getting this patched? |
| 17:59.47 | russellb | ctooley: yeah, it's a nice URL, I'm surprised I remembered :-) |
| 18:00.23 | TheDavidFactor | the socket interface in EIVR depends on it, if it's connecting to an IP not a domain name |
| 18:00.31 | TheDavidFactor | *FQDN |
| 18:01.04 | Corydon76-dig | Why do we use FQDN when we really mean FQHN |
| 18:01.07 | Corydon76-dig | ? |
| 18:01.30 | ctooley | TheDavidFactor, I'm looking at it now. |
| 18:01.50 | TheDavidFactor | well I think the FQ means a domain that completely references a specific ip |
| 18:02.13 | Corydon76-dig | but a domain name doesn't do that. A host name does that. |
| 18:03.07 | TheDavidFactor | The FQDN therefore uniquely identifies the device |
| 18:03.08 | ctooley | TheDavidFactor, What does this make the entire command structure look like? |
| 18:03.31 | TheDavidFactor | oops, sorry |
| 18:03.32 | Corydon76-dig | TheDavidFactor: actually, not always. |
| 18:03.40 | TheDavidFactor | http://en.wikipedia.org/wiki/Fully_qualified_domain_name |
| 18:03.55 | manick_ | by the way: have you ever noticed line 706 and 730: ast_fileexists(...) == -1 ?? it must be == 0 ! |
| 18:04.01 | TheDavidFactor | ctooley, what are you referring to? |
| 18:04.03 | Corydon76-dig | TheDavidFactor: what about a FQDN that round robins a group of machines? |
| 18:04.31 | Corydon76-dig | like www.google.com ? |
| 18:04.38 | TheDavidFactor | true true, but wouldn't the host name also do the same thing? |
| 18:05.19 | Corydon76-dig | The point of a FQDN is that it's absolute, rather than a host name, which could be relative or merely the first part |
| 18:06.00 | Corydon76-dig | mahal or mahal.pcstore, rather than mahal.pcstore.vanderbilt.edu |
| 18:06.02 | ctooley | TheDavidFactor, 16174 |
| 18:06.45 | ctooley | Corydon76-dig, mahal or mahal.pcstore wouldn't be considered fully qualified unless they were not part of pcstore or vanderbuilt.edu |
| 18:07.32 | ctooley | The fact that they're part of a larger hierarchy means that the fully qualified name would have to be mahal.pcstore.vanderbilt.edu and mahal or mahal.pcstore would be just hostnames. |
| 18:07.37 | Corydon76-dig | ctooley: no, but they are hostnames. Which goes back to why isn't the abbreviation FQHN? |
| 18:09.10 | ctooley | Corydon76-dig, because the definition of a domain is the issue. Technically edu, vanderbilt.edu, pcstore.vanderbilt.edu, and mahal.pcstore.vanderbilt.edu are all domains and domain names. It's a matter of scope. |
| 18:10.00 | ctooley | There's a perfectly legitimate argument that mahal.pcstore.vanderbilt.edu contains a scope in which it is encompassing it's own domain of information. |
| 18:10.07 | ctooley | Therefore that is the name of the domain. |
| 18:10.29 | Corydon76-dig | Troll successful. |
| 18:11.33 | TheDavidFactor | ctooley, http://asterisk.pastebin.com/d187477c |
| 18:13.24 | ctooley | That doesn't reference 16174, that references 16147 |
| 18:15.06 | TheDavidFactor | dyslexic |
| 18:15.08 | ctooley | TheDavidFactor, And as to 16147, it shouldn't send a "D" in that scenario, it should send a T |
| 18:15.29 | TheDavidFactor | It does send a T too, sorry I left it out |
| 18:15.37 | ctooley | T: the play list was interrupted (see below) |
| 18:16.27 | ctooley | 'S'etting the queue should result in an interruption which causes the T. |
| 18:16.41 | TheDavidFactor | http://asterisk.pastebin.com/d74ca63a0 |
| 18:16.52 | TheDavidFactor | that is actually what happens |
| 18:16.56 | ctooley | Right |
| 18:17.45 | ctooley | We keep a "queue" on the Armstrong side. When an F comes in, the file is removed from the queue, when a T is received the "top" of the queue is what is playing and can be removed. When a D is received it removes the file listed in the data second. |
| 18:17.49 | ctooley | errr data section |
| 18:18.38 | *** join/#asterisk-dev msetim (n=setim@201.86.1.166.dynamic.adsl.gvt.net.br) |
| 18:19.20 | TheDavidFactor | we use the queuing capability of EIVR to keep up with the prompts and simply send it all the prompts to play and the wait on F and D tags. If a T occurs there's no way to know for sure which prompt it was on |
| 18:19.26 | ctooley | The reason there isn't a file in the data section is that not every time there's an interruption is there a file to be interrupted. |
| 18:19.37 | TheDavidFactor | actually there is |
| 18:19.57 | *** join/#asterisk-dev vally (n=vally@valentin-manthei.de) |
| 18:20.06 | TheDavidFactor | if it interrupts silence it doesn't generate a T |
| 18:20.35 | vally | hi everyone. i had a look at the rtmp branch and compiled the source. when starting asterisk i get an error while loading the module: undefined symbol: av_audio_resample_init. thats a ffmpeg method he obviously can't find. do i have to link it somewhere else? i am confused because i linked the ffmpeg libs in the configure script and it built successfully. anyone? :) |
| 18:21.22 | russellb | you'll likely have to contact the author directly |
| 18:21.29 | russellb | I don't think he hangs out here |
| 18:21.40 | leifmadsen | I guess that means to comment on the issue itself |
| 18:21.56 | TheDavidFactor | ctooley, I really appreciate being able to discuss this with you. I've got to go for now, if you'd like to continue off-irc my email is my user id at gmail |
| 18:22.06 | leifmadsen | M15484 |
| 18:22.09 | MuffinMan | [ready for testing] [Asterisk] Channels/NewFeature 0015484: [branch] RTMP support in Asterisk reported by phsultan (Karma: +56.50) https://issues.asterisk.org/view.php?id=15484 |
| 18:22.45 | ctooley | emailed you |
| 18:23.55 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 18:23.55 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 18:24.46 | vally | his name is phsultan.. but my question is in fact a thing that don't really depends on the specific integration. |
| 18:25.21 | leifmadsen | vally: he responds pretty quickly usually, so you might still be able to ask him the question, otherwise you can try asterisk-dev mailing list |
| 18:25.56 | vally | is there a mail address available anywhere? |
| 18:26.07 | Qwell | vally: no, just comment on the issue and he'll see it |
| 18:26.15 | vally | okay, ty. |
| 18:28.28 | vally | i will drop a message there. but i try to ask a general question to maybe fix it myself: does linking an external library require that library available somewhere at runtime? |
| 18:28.57 | ctooley | vally, yes |
| 18:30.50 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 18:30.50 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 18:30.57 | eliel | Hello |
| 18:31.03 | eliel | Corydon76-dig: thanks for the review |
| 18:31.19 | vally | ctooley: where would asterisk look for those libs? |
| 18:31.34 | Corydon76-dig | eliel: yay! |
| 18:31.37 | eliel | next week i will remove the app_queue code and add the documentation |
| 18:31.45 | Corydon76-dig | Sounds good |
| 18:31.56 | ctooley | vally, where ld has been told told to |
| 18:32.16 | Corydon76-dig | eliel: I'm guessing you've been really busy with schoolwork |
| 18:32.37 | ctooley | vally, see ld.so.conf and http://linux.about.com/cs/linux101/g/ldconfig.htm |
| 18:33.10 | ctooley | vally, you can pass in more information manually, but you're better off learning that. |
| 18:33.33 | vally | thanks so far. |
| 18:33.36 | eliel | Corydon76-dig: i was very drunk this days to connect to irc hehe, and ooh, yes, "schoolwork" |
| 18:33.41 | ctooley | vally, also, to check that it's all working learn "ldd" |
| 18:35.08 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:35.30 | vally | thats information that i looked for. thanks :) |
| 18:38.11 | mnicholson | if a dialplan function has .read and .read2 defined, which is used? |
| 18:40.51 | Corydon76-dig | read2 |
| 18:41.06 | Corydon76-dig | Well, depends upon which API call is used |
| 18:41.27 | Corydon76-dig | but read2 is more memory-efficient |
| 18:42.48 | Corydon76-dig | pbx_substitute_variables_* use the read function, while ast_str_substitute_variables* uses read2 |
| 19:07.59 | mnicholson | hmm, ok |
| 19:15.10 | TheDavidFactor | ctooley, ping |
| 19:15.21 | ctooley | TheDavidFactor, pong |
| 19:15.43 | TheDavidFactor | M16147 |
| 19:15.45 | MuffinMan | [assigned] [Asterisk] Applications/app_externalivr 0016147: [patch] ExternalIVR does not return event for file when file playing is interrupted reported by thedavidfactor (Karma: neutral) https://issues.asterisk.org/view.php?id=16147 |
| 19:16.27 | TheDavidFactor | on this one, after talking to you, does adding the extra D event (for the currently playing file) break anything you're doing? |
| 19:16.50 | TheDavidFactor | *after talking to you I've been thinking |
| 19:18.48 | Corydon76-dig | Don't think too hard. |
| 19:18.58 | Corydon76-dig | It's Friday, after all. |
| 19:19.24 | TheDavidFactor | true :-) |
| 19:19.49 | TheDavidFactor | I'm out of here (the office) in an hour |
| 19:20.05 | TheDavidFactor | doubt I'll be able to stay off IRC all weekend ;-) |
| 19:20.15 | Corydon76-dig | I'm never far from this office.... I work from home... |
| 19:20.47 | TheDavidFactor | that's always nice |
| 19:20.58 | TheDavidFactor | in general |
| 19:21.00 | ctooley | I'd suggest something other than that. |
| 19:21.40 | TheDavidFactor | ctooley, would extending the T event to return the file interrupted cause you heartburn or grief? |
| 19:21.53 | ctooley | No |
| 19:21.57 | ctooley | that would be ok |
| 19:22.19 | ctooley | Let's pick an event for the DTMF as well, |
| 19:22.31 | TheDavidFactor | well, I'm willing to leave that as is |
| 19:22.58 | TheDavidFactor | If there is data with a D tag, then it's a drop event, otherwise it's a DTMF event |
| 19:23.15 | TheDavidFactor | I would update the docs instead of changing the code |
| 19:25.01 | TheDavidFactor | does that seem reasonable to you? |
| 19:27.10 | manick_ | I'd be okay with this :) |
| 19:27.21 | ctooley | I'd honestly prefer to see the "D"eleted changed to "R"emoved. |
| 19:27.59 | TheDavidFactor | yea, but that breaks backward compat. worse then just about anything else. |
| 19:28.30 | TheDavidFactor | we might be able to deprecate D and add R and then remove D in a release or two? |
| 19:29.16 | TheDavidFactor | There appears to be nothing in the doc or code that prevents multiple events for the same thing |
| 19:29.39 | ctooley | TheDavidFactor, there isn't anything in there preventing that, it's just not a good path to go down. |
| 19:29.41 | TheDavidFactor | applications written for EIVR should be ignoring things that they don't use any way |
| 19:31.25 | ctooley | TheDavidFactor, The protocol has undergone "cleanup" before, it's realistically time that it be done again. |
| 19:32.58 | TheDavidFactor | so how big a deal is being non-backwards compatible? And, leifmadision or russellb, how is non-backwards compatible updates handled in SVN? |
| 19:33.47 | TheDavidFactor | I hosed the spelling of leif's name, but he's not here anyway so please don't tell him ;-) |
| 19:34.23 | russellb | non-backwards compatible is bad. |
| 19:34.27 | manick_ | TheDavidFactor, added a new patch for 16147 without having new a new List, can you look over it ? |
| 19:35.27 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:35.27 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 19:35.42 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:36.05 | TheDavidFactor | russellb, can you comment on what we're discussing about how to handle changing an event type in EIVR? |
| 19:38.13 | russellb | not right now, sorry |
| 19:38.28 | russellb | propose something and throw it on reviewboard and i'll look when i can |
| 19:38.30 | TheDavidFactor | hey, no prob, thanks for all the help |
| 19:39.24 | TheDavidFactor | manick_, so you're leaving the pointer in the list until it finishes, the only problem is that is will still generate an additional D event which would cause ctooley problems. Might be able to pull the first pointer off the list and send it as the data element of the T event and then process the rest of the list as D events |
| 19:40.30 | ctooley | TheDavidFactor, None of these changes will go into 1.4, so it's not an issue, there are already significant changes that would require me to change my stuff to upgrade to 1.6/trunk. |
| 19:41.20 | TheDavidFactor | well, I was told by leifmadsen that I would need to patch 1.4, 1.6 and trunk with these patches. |
| 19:41.37 | leifmadsen | TheDavidFactor: not all the time -- not everything goes into all versions |
| 19:41.48 | leifmadsen | sometimes only trunk, sometimes only 1.6.2 and trunk, etc.... |
| 19:41.58 | leifmadsen | depends where a specific feature was first put in, etc... |
| 19:42.03 | ctooley | 1.4 shouldn't get touched by any of these unless it truly is a 'bug' |
| 19:42.11 | TheDavidFactor | ok |
| 19:42.23 | ctooley | And only if it's a bug that already exists in 1.4. |
| 19:42.36 | ctooley | which is hard with this protocol as the entire thing could be considered a "bug". :-) |
| 19:43.07 | TheDavidFactor | well, the sockets stuff is a bug, but if anyone was trying to use it there should have been bug reports. |
| 19:43.23 | ctooley | TheDavidFactor, it shouldn't exist in 1.4 anyway |
| 19:43.54 | TheDavidFactor | who decides what should be where? |
| 19:44.13 | TheDavidFactor | or updated in which versions, I guess |
| 19:44.18 | *** join/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 19:46.34 | leifmadsen | TheDavidFactor: it's based on the release policy, in which case releases do not get new features; only bug fixes. 1.2 is security only right now -- so no bug fixes even, just security fixes. 1.0 is entirely unsupported. |
| 19:46.38 | ctooley | The socket code doesn't exist in 1.4 as far as I remember. The 'D' has been a bug since pre-1.0, it shouldn't be changed in 1.4 either. |
| 19:48.52 | TheDavidFactor | where is the release policy documented, is in some of those links you gave be before? |
| 19:50.46 | russellb | http://www.asterisk.org/doxygen/trunk/DevDoc.html |
| 19:51.26 | TheDavidFactor | ok, I didn't have that one |
| 19:55.30 | TheDavidFactor | according to that, 1.4 - 1.6.1 is in full support, 1.6.2 is not mentioned and only trunk is in full development (as expected) I'm going to try to split the issues out in to things that enhance operation and things that fix bugs and then fix the bugs and discuss the enhancements, how does that sound ctooley and manick_? |
| 19:56.43 | ctooley | TheDavidFactor, That's fine, but anything that goes into a release version has to go through the review board fist |
| 19:56.48 | ctooley | s/fist/first/g |
| 19:57.19 | manick_ | TheDavidFactor, I am fine with that |
| 19:57.41 | TheDavidFactor | ok, I'll try to start the review board process early next week. |
| 19:58.29 | ctooley | I don't have the stuff set up to automatically notify me of ExternalIVR changes in mantis or the review board. If you'd like me to look over them, please CC me. |
| 19:59.32 | TheDavidFactor | sure thing, I'll let you know |
| 19:59.41 | Corydon76-dig | ctooley: as long as you have a Mantis account, you can be copied directly from the reviewboard page, if he adds you to the review "people" section |
| 19:59.56 | TheDavidFactor | ok, that sound good |
| 19:59.59 | russellb | only if you have logged in to reviewboard |
| 20:00.06 | russellb | it's weird. |
| 20:00.17 | russellb | because the auth backed is a hack :-p |
| 20:00.54 | Corydon76-dig | Yay hacks! |
| 20:00.56 | ctooley | I "think" I have logged in. :-) |
| 20:02.03 | Corydon76-dig | Go go gadget tooley |
| 20:02.44 | TheDavidFactor | manick_, the fileexists test that you added to the patch under 16147, is fixed in the patch under 16123 which creates a problem that is also fixed as noted in 16123 |
| 20:03.28 | TheDavidFactor | I didn't notice it when I read through the patch, I saw it because of the note you added |
| 20:03.38 | manick_ | TheDavidFactor, oh okay, I just looked at latest trunk version |
| 20:04.05 | TheDavidFactor | yea, none of these issues have been committed yet. |
| 20:11.12 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:11.12 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:06.34 | *** join/#asterisk-dev tamiel (n=tamiel@ip-1.net-81-220-19.versailles.rev.numericable.fr) |
| 21:11.03 | snuff-home | mm.. anyone else get crashes when 'stopping gracefully' |
| 21:12.23 | snuff-home | 0 0x08160f62 in ast_timer_ack (handle=0x876eb68, quantity=1) at timing.c:169 |
| 21:12.26 | snuff-home | 169 handle->holder->iface->timer_ack(handle->fd, quantity); |
| 21:22.46 | leifmadsen | that's just a quick stop |
| 21:22.49 | leifmadsen | :) |
| 21:23.04 | putnopvut | snuff-home: I haven't seen that myself. Does it happen every time? Does a call need to be up? |
| 21:24.27 | putnopvut | Oh, also what Asterisk version? |
| 21:25.01 | snuff-home | its trunk.. generally... i am only using the 'console dial' command then quitting after testing my new memcache function |
| 21:25.25 | snuff-home | *hugs* the person that made console dial.. i think it was russell.. |
| 21:25.26 | putnopvut | I'll try enabling res_timing_pthread and see if I can make it happen too. |
| 21:26.20 | snuff-home | best thing about chan_oss module.. it still loads even when there is no audio device.. allowing me to test on my vm with no sound |
| 21:27.18 | russellb | snuff-home: i made one of the 3 versions of it, heh |
| 21:27.21 | russellb | the 3rd one ... |
| 21:27.25 | snuff-home | ah :) |
| 21:28.23 | snuff-home | uploads his module progress |
| 21:28.37 | putnopvut | russellb: that was ... chan_console? |
| 21:28.41 | russellb | putnopvut: yes |
| 21:29.06 | russellb | i wanted a channel driver that worked on my mac |
| 21:29.30 | russellb | so I used Asterisk+chan_console as my soft phone |
| 21:29.52 | russellb | still do sometimes, but usually I just use skype. |
| 21:35.41 | *** join/#asterisk-dev errotan (n=errotan@a1612.adsl.pool.eol.hu) |
| 21:38.27 | snuff-home | mm.. i think my ssl cert has expired |
| 21:39.39 | Corydon76-dig | snuff-home: it's generally good for 1 year only |
| 21:39.50 | Corydon76-dig | send an email to russell asking for a new cert |
| 21:40.22 | snuff-home | yer need to remember the how |
| 21:40.25 | snuff-home | :) |
| 22:10.05 | putnopvut | snuff-home: Well, I got a crash in the timing API when stopping gracefully, although it appears to be in a different spot from where you observed it. I'll do a valgrind run. |
| 22:11.08 | file | I wanna say there's an issue open about it |
| 22:12.36 | putnopvut | I'll use the handy-dandy google search bar on mantis to see if I can find it :) |
| 22:13.20 | putnopvut | yep: |
| 22:13.22 | putnopvut | M16062 |
| 22:13.25 | MuffinMan | [confirmed] [Asterisk] General 0016062: Asterisk crashes after "core stop gracefully" reported by alexanderheinz (Karma: neutral) https://issues.asterisk.org/view.php?id=16062 |
| 22:15.33 | putnopvut | That is just an evil for loop. |
| 22:18.03 | putnopvut | Heh, and you of course have no idea what for loop I'm talking about :) |
| 22:30.40 | snuff-home | goes n finds the last email about ssl certs from russell to begin the process again |
| 22:31.26 | russellb | snuff-home: i don't need any info from you, just something in my inbox as a reminder |
| 22:31.28 | russellb | russell@digium.com |
| 22:32.13 | russellb | i'm really lazy with doing certs, because it's kind of a pain |
| 22:32.54 | russellb | but if it's in my inbox, i won't forget and will get it done |
| 22:35.50 | snuff-home | hehe k |
| 22:37.07 | snuff-home | done |
| 23:00.03 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 23:09.45 | *** join/#asterisk-dev atis_home (n=atis@193.238.213.215) |
| 23:09.56 | atis_home | Corydon76-dig: you still there? |
| 23:15.33 | Corydon76-dig | Yes, but not much longer |
| 23:18.51 | atis_home | heh, i got /tmp/refs for the interval of one run which had _IO_vprintf crash |
| 23:19.13 | atis_home | but its 55 megs, gzipped to 2.5 and i can't upload |
| 23:19.36 | atis_home | do you have any script to run on it? |
| 23:20.06 | atis_home | or i could just write some to count when there's +1, next time that address should have larger value? |
| 23:21.14 | atis_home | Corydon76-dig: oh, you gan grab it here: http://193.238.212.236/tmp/refs.asterisk-dev-mc-2009-11-07T00:13:56+0200.8145.log.gz |
| 23:21.33 | atis_home | will you also need backtrace for this one? |
| 23:23.46 | Corydon76-dig | No, I won't |
| 23:27.53 | vally | can you recommend a development environment for the asterisk trunk on windows? |
| 23:28.49 | putnopvut | vally: I'm pretty sure that there is not a single person in this channel developing Asterisk in Windows. |
| 23:29.21 | atis_home | putty ;) |
| 23:29.51 | putnopvut | In fact, getting Asterisk to compile in windows probably requires the use of cygwin so that you can use gcc. |
| 23:30.01 | putnopvut | Or maybe mingw will work. I don't know actually. |
| 23:30.33 | vally | i just for modifying the source. i will compile it on the server asterisk should run on |
| 23:30.39 | Qwell | notepad |
| 23:30.42 | vally | *its just |
| 23:30.58 | vally | but project functionality would be nice |
| 23:31.48 | putnopvut | ah, gotcha. If I were using Windows, I'd probably just use Visual Studio Express (the free one). If I were a masochist, I'd do like Qwell suggested and use notepad :) |
| 23:32.00 | vally | ;) |
| 23:32.23 | Qwell | VS would likely do stupid things to the code. |
| 23:32.32 | atis_home | when i was still on windows i used putty and mcedit on remote server :p |
| 23:33.15 | atis_home | but Konsole is just much more comfortable than putty |
| 23:40.50 | Corydon76-dig | VMWare server with a Linux install within is probably the way to go, in terms of a development environment on Windows |
| 23:49.08 | *** join/#asterisk-dev tzafrir__laptop (n=tzafrir@212.179.75.202) |
| 23:49.08 | *** mode/#asterisk-dev [+o tzafrir__laptop] by ChanServ |
| 23:58.32 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 23:58.32 | *** mode/#asterisk-dev [+o file] by ChanServ |
