| 00:03.40 | rmudgett | The clean_exten would certainly simplify some comparisons. However ABI is likely to get in the way. LUA most likely. |
| 00:13.35 | coreyfarrell | struct ast_exten is private to pbx.c! :) |
| 00:41.15 | *** join/#asterisk-dev raspberrypifan (~raspberry@cpe-69-204-232-211.nyc.res.rr.com) |
| 01:01.21 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 04:47.18 | *** join/#asterisk-dev piling_ (~piling@unaffiliated/piling) |
| 05:10.36 | *** join/#asterisk-dev klow (~textual@c-67-161-106-89.hsd1.wa.comcast.net) |
| 06:32.45 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 06:44.42 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:02.19 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:34.28 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:34.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:21.00 | *** join/#asterisk-dev raspberrypifan (~raspberry@cpe-24-90-144-225.nyc.res.rr.com) |
| 08:22.50 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 08:32.42 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 11:02.47 | seanbright | "Upcoming features will require the generation and persistence of a UUID" - which features are those? |
| 11:08.23 | file | the kind that if we could mention it would be mentioned there :D |
| 11:09.07 | file | stay tuned, same bat channel! |
| 11:09.35 | Marquis42 | file: Ooooh, mysterious! :D |
| 11:12.31 | file | or something |
| 11:14.26 | seanbright | hmm |
| 11:14.35 | seanbright | i am not satisfied by your response |
| 11:18.49 | file | I am also not satisfied with my response, but it is what it is |
| 11:19.52 | Marquis42 | haha |
| 11:22.32 | file | there was an ambulance and 2 RCMP vehicles at the house on the other side of my side street |
| 11:22.35 | file | odd |
| 11:22.51 | Marquis42 | yikes |
| 11:23.18 | file | every house around me has had an ambulance at it |
| 11:23.23 | file | at least once |
| 11:23.42 | Marquis42 | That's a worrying trend. |
| 11:23.47 | file | a bit... |
| 11:25.30 | file | how is everyone this morning? |
| 11:26.57 | Marquis42 | I'm sure I could complain about something, but it wouldn't help. :D |
| 11:27.01 | Marquis42 | But really, all is well. |
| 11:35.16 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 12:43.13 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-drbmclllzbfiadzw) |
| 12:43.13 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:32.41 | file | nods to newtonr |
| 13:33.54 | gtjoseph | file: Ha! debug takes the same arguments as "pjsip set logger" which can be yes, no or a hostname. if the debug option is blank, it's treated as a hostname which matches everything. |
| 13:34.06 | file | that be a bug yo |
| 13:34.15 | gtjoseph | :) |
| 13:35.57 | gtjoseph | need to add 14 to jira |
| 13:36.49 | newtonr | hay hay |
| 13:37.47 | file | it has been done |
| 13:38.00 | file | there is now a 14.0.0 |
| 13:38.18 | file | and a b1 |
| 13:43.16 | gtjoseph | while you're at it, can you change SVN to master? |
| 13:43.28 | gtjoseph | or GIT-master |
| 13:43.33 | gtjoseph | or GIT |
| 13:43.42 | file | not GIT. |
| 13:43.48 | file | maybe GIT. |
| 13:43.58 | file | navigates the maze that is JIRA |
| 13:43.59 | gtjoseph | anything but SVN :) |
| 13:48.06 | file | GIT is added, SVN is archived |
| 13:58.44 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:58.44 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:06.10 | file | putnopvut, are you... home? |
| 14:06.24 | file | or was IRC being lame |
| 14:08.26 | putnopvut | Yeah I'm home |
| 14:08.31 | file | oic |
| 14:08.56 | putnopvut | So, running mkrelease with nothing special, it says that it's creating 14.0.0-beta1 starting history at 13.0.0-rc1, with previous version 13.0.0 |
| 14:09.02 | putnopvut | On one hand, that seems right. |
| 14:09.17 | putnopvut | Like, for making a release, that seems right. |
| 14:09.56 | putnopvut | I hesitated to move forward with it though just in case the previous version or history starting point should be different. |
| 14:10.49 | file | putnopvut, that does seem right |
| 14:11.09 | file | it logically seems right. |
| 14:11.38 | putnopvut | Yeah. I figure that with changelog generation, that sort of logic might show some "new" things that are actually in incremental versions of 13. But for the actual tag generation, though, that seems correct. |
| 14:11.51 | file | yeah |
| 14:11.53 | putnopvut | So I'll move forward with that. |
| 14:12.04 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-bncqsahjxbswyejz) |
| 14:19.05 | *** join/#asterisk-dev acidfu_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 14:33.21 | putnopvut | mkrelease takes quite a while longer when it has two years worth of content to go through |
| 14:33.45 | file | putnopvut, yeah... |
| 14:47.44 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-mwvfyboaqywtitnq) |
| 14:55.45 | file | putnopvut, I see you. |
| 14:56.31 | putnopvut | I see what looksl ike you |
| 15:12.06 | *** join/#asterisk-dev alex2grad (~alex2grad@38.117.100.40) |
| 15:13.02 | file | putnopvut has beautiful hair today |
| 15:13.10 | file | majestic |
| 15:14.03 | *** join/#asterisk-dev raspberrypifan (~raspberry@cpe-24-90-144-225.nyc.res.rr.com) |
| 15:33.17 | putnopvut | Aw poop on a stick! The mkrelease.py script hit an error. |
| 15:33.25 | putnopvut | Welp, this will be fun to track down! |
| 15:35.03 | file | putnopvut, may the force be with you |
| 15:35.09 | putnopvut | Thank you |
| 15:35.15 | file | and hopefully a tasty lunch |
| 15:39.06 | putnopvut | I think I see what the problem was. For whatever reason, we apparently never made RCs of 13.0.0. We went straight from beta3 to 13.0.0. So mkrelease is trying to use 13.0.0-rc1 as a marker and can't find that. So I just need to tell it to use 13.0.0 as the time marker instead. No biggie, but it does likely mean a couple of hours of the script re-running. |
| 15:39.17 | file | aha |
| 16:05.10 | alex2grad | Where can I read about asterisk's taskprocessor ideology? It seems if one module (for example app_voicemail) reached high water mark on own taskprocessor queue then only one victim is PJSIP stack which checks taskprocessor alert and ignores incoming requests. I think the better way is to not pop task from queue taskprocessor queue if the queue reached high water. |
| 16:05.22 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 16:09.22 | gtjoseph | Alexei!! You're on IRC! |
| 16:09.39 | gtjoseph | i don't think there's anything really to read. |
| 16:10.15 | gtjoseph | you're correct though, only the pjsip distributor checks to see if the high warer mark has been reached |
| 16:11.15 | gtjoseph | rmudgett is probably the best authority especially involving the distributor. |
| 16:13.26 | gtjoseph | i think the issue with popping them off is that we only want the distributor to stop processing, not everything else and it's the taskprocessor itself that de-queues the tasks. |
| 16:14.02 | gtjoseph | ----- |
| 16:14.16 | gtjoseph | Di8d we always have an issue with compact_headers not matching on both sides? |
| 16:14.20 | rmudgett | Correct. The serializers must not be stopped. Instead work needs to stop being added to them. |
| 16:16.30 | file | gtjoseph, I don't understand the question |
| 16:17.18 | gtjoseph | pbxa has compact_headers=yes... pbxb has compact_headers=no. calls from a to b fail |
| 16:17.29 | rmudgett | Simply blocking tasks from being put onto the serializers is worse. Some things must be done by serializers before other things can complete. If those critical things are simply discarded then threads just get blocked forever. |
| 16:18.02 | gtjoseph | file: PJSIP syntax error exception when parsing 'Request Line' header on line 12 col 1: |
| 16:18.27 | file | gtjoseph, interesting! I wouldn't expect it to do that - unless PJSIP's configuration controls not just sending but also receiving... |
| 16:18.48 | gtjoseph | actuakky it looks like there's no compact equivalent to one of the headers. checking now |
| 16:19.01 | gtjoseph | oh, rpid and pai |
| 16:19.26 | gtjoseph | the line looks like this... : "Alice" <sip:1171@192.168.0.1> |
| 16:19.34 | file | ew |
| 16:19.43 | rmudgett | pjsip better not choke on receiving compact headers if it is configured to not send them. |
| 16:20.05 | gtjoseph | it's the sender. |
| 16:20.18 | gtjoseph | the receiver was ok up until the rpid header |
| 16:20.19 | file | yeah, that's broken on the sender side |
| 16:20.41 | gtjoseph | how'd we not find that? |
| 16:21.03 | gtjoseph | maybe we should change a few of the testsuite tests to use compact_headers. |
| 16:21.05 | file | I don't think we have any compact header tests, and it's not something most poeple turn on |
| 17:20.02 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 17:31.40 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 17:38.08 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 17:55.53 | putnopvut | oh wow. Latest mkrelease.py failure: git.exc.GitCommandNotFound: [Errno 12] Cannot allocate memory |
| 17:56.03 | file | well. |
| 17:56.10 | putnopvut | yep |
| 17:56.22 | file | I'm not sure what to say to that. |
| 17:56.55 | rmudgett | Add 256G of memory? |
| 17:57.08 | rmudgett | That ought to be enough |
| 17:58.18 | putnopvut | heh |
| 17:58.45 | putnopvut | I think lunkwill might only have 512 MB of RAM on it. |
| 17:59.04 | file | dear god |
| 17:59.05 | file | you're right |
| 17:59.51 | file | putnopvut, do you have access to the host to up its allocation? |
| 18:00.07 | putnopvut | I'm not sure which host lunkwill is on. |
| 18:00.13 | putnopvut | I'll look it up and see. |
| 18:00.25 | file | bangbang is what the wiki says |
| 18:00.40 | putnopvut | Yeah, just saw that. |
| 18:00.58 | putnopvut | And I don't think I have access to bangbang, but I can certainly try it and see. |
| 18:02.31 | putnopvut | Should bangbang be administratable via a web browser? |
| 18:02.46 | file | dunno |
| 18:03.33 | file | vSphere client needed? |
| 18:04.02 | putnopvut | Found a link that should have let me at least browse the datastores in my webbrowser. I couldn't log in though. |
| 18:04.59 | file | k |
| 18:05.02 | putnopvut | So, I don't believe I have access to alter lunkwill |
| 18:05.13 | file | I'm enlisting a wild dlee |
| 18:05.41 | putnopvut | all righty |
| 18:06.00 | putnopvut | The other option would be for me to just have access to a different server with more memory, set it up, and make the release on it. |
| 18:06.31 | file | putnopvut, yeah... |
| 18:07.02 | putnopvut | Thanks for helping out. |
| 18:07.28 | putnopvut | I imagine there's probably some specific reason for using lunkwill instead of some other machine though... |
| 18:07.36 | file | it's set up and we know it works |
| 18:07.54 | seanbright | i want bang bang shrimp now |
| 18:08.26 | file | putnopvut, he is seeing what he can do |
| 18:09.11 | putnopvut | Cool beans. Thanks invisible leedm<numbers> |
| 18:13.18 | file | he's practicing dark magic |
| 18:21.29 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 18:26.23 | file | putnopvut, may have to use another VM indeed |
| 18:26.40 | kharwell | putnopvut: off the top of my head I can't think of any reason it wouldn't run on another machine. Now that machine makes it easier to do the announcement but that is a separate task |
| 18:28.41 | putnopvut | My goal for today is just to successfully create the tag. The announcement is a separate battle and could potentially work on lunkwill anyway. |
| 18:28.59 | putnopvut | So, any good candidates for which VM to use instead? |
| 18:29.14 | file | not really - but dlee just had a potentially clever idea |
| 18:29.35 | kharwell | copy the vm to another host? |
| 18:30.07 | file | no |
| 18:31.51 | file | much worse |
| 18:33.10 | file | we've figured out how much memory is available |
| 18:33.14 | file | so that's good |
| 18:33.32 | file | changing it... |
| 18:33.39 | acidfu_ | from a struct sip_peer *peer object, is it possible to find the "sip registration timeout" and cancel it ? I presume that when an SIP register arrive in Asterisk , Asterisk start a timer, I would like to cancel that timer, any idea in what corner should I look ? :) thanks ! |
| 18:35.30 | file | putnopvut, lunkwill now has 4GB of RAM |
| 18:38.44 | acidfu_ | oh, stop_session_timer() might be what I'm looking for (in chan_sip) |
| 18:38.44 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 18:38.54 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:39.31 | file | putnopvut, so you "should" be good to go |
| 18:42.11 | seanbright | i like rmudgett |
| 18:42.24 | seanbright | "hey richard... see those C files over there? FIX THEM" |
| 18:42.32 | seanbright | and he does |
| 18:42.34 | seanbright | it's like magic |
| 18:43.02 | file | seanbright, sorta |
| 18:43.45 | putnopvut | I'm having real trouble doing the review for the DTMF twist change. I have looked up several documents and they appear to contradict each other. Some say that the low frequency being higher amplitude than the high frequency is normal twist, and some say that's reverse twist. |
| 18:43.45 | file | walks home |
| 18:44.11 | putnopvut | So when the review hinges on changing the twist values around like that, I have no authority on whether the change is actually correct. |
| 18:44.55 | rmudgett | It makes sense that the high frequencies would need the boost since a phone line attenuates the upper frequencies. |
| 18:45.14 | putnopvut | Yep |
| 18:46.12 | putnopvut | Here, I'll link four docs. Two of them agree that A(lF) > A(hF) is normal: http://www.britishtelephones.com/dtmf.htm http://www.cypress.com/file/140766/download |
| 18:46.35 | putnopvut | And then these two say the opposite: http://www.cypress.com/file/140766/download http://www.ti.com/lit/an/spra096a/spra096a.pdf |
| 18:46.59 | putnopvut | The two that say the opposite say that reverse twist is the common case. |
| 18:47.08 | putnopvut | so if it's common, why isn't that just "normal" then? |
| 18:47.44 | putnopvut | Oh, I linked the same thing twice. |
| 18:48.03 | putnopvut | http://what-when-how.com/voip/dtmf-detection-voip/ is one that says A(lF) > A(hF) is called reverse twist |
| 19:00.00 | *** join/#asterisk-dev snuff-work (~snuff-wor@203.87.61.22) |
| 19:00.00 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:02.45 | rmudgett | putnopvut: The dsp.conf.sample also defines normal/reverse twist but the code did the opposite. |
| 19:04.06 | putnopvut | ah okay. As long as we're being internally consistent, I suppose we can call the twists whatever we want. |
| 19:04.24 | putnopvut | That's good to know. I'll take another look at the review in a bit. |
| 19:06.34 | rmudgett | I also looked for what was normal/reverse to see if the values were used in the right way. I didn't see the contrary definitions you found. |
| 19:06.36 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 19:06.56 | rmudgett | Though it was getting rather late last night. |
| 19:18.04 | rmudgett | putnopvut: The first three links you gave all said 8dB row over column power levels and 4dB column over row power levels. They were inconsistent in what it was called. |
| 19:20.01 | rmudgett | I'm going to have to rework two of those reviews because the row frequencies are now defaulting to the opposite power limits. |
| 19:21.00 | rmudgett | The row should allow a higher power limit regardless of what the twist name is. |
| 19:27.30 | *** join/#asterisk-dev piling (~piling@unaffiliated/piling) |
| 19:58.04 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 20:15.32 | file | putnopvut, how's the release going? |
| 20:17.15 | putnopvut | Still churning |
| 20:17.31 | putnopvut | It had been going for over 3 hours before when I ran out of memory that time. |
| 20:17.47 | putnopvut | It'll probably not complete until after I'm done for the day. We'll see. |
| 20:21.03 | file | good times |
| 20:23.30 | *** join/#asterisk-dev corretico (~luis@200.91.143.99) |
| 20:42.49 | putnopvut | I kind of wish I had run mkrelease.py under time so I could see just how long it takes. |
| 20:43.44 | file | it's using 9.5% of memory |
| 20:45.49 | file | it was started at 13:58 |
| 20:48.27 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 20:58.26 | putnopvut | So we're right at the 2 hour mark then |
| 21:02.46 | file | 11.4% memory usage |
| 21:17.10 | putnopvut | omg the script actually reached tag creation time |
| 21:17.33 | file | sweet |
| 21:17.48 | file | sees it |
| 21:18.05 | file | putnopvut, did you tag it beta1? |
| 21:18.31 | putnopvut | The script claimed it was creating beta1 when it started. |
| 21:18.31 | file | >_> |
| 21:18.36 | putnopvut | Let's see what it actually got called... |
| 21:18.44 | file | 14.0.0 |
| 21:19.13 | putnopvut | #&*$&@*(#$& |
| 21:19.25 | putnopvut | The first two times I ran the script I actually did 14.0.0-beta1 |
| 21:19.35 | putnopvut | And the last time, when it actually succeeded, I left the beta1 off. |
| 21:19.47 | file | well we know more RAM helps! |
| 21:20.17 | putnopvut | Well, I'm going to back out the pending stuff and the tag, and then re-run the script in non-interactive mode so that it gets recreated this evening. |
| 21:20.21 | putnopvut | And yes! Yay for RAM |
| 21:20.31 | kharwell | can't you just rename the tag in git? |
| 21:20.55 | file | kharwell, that doesn't change the contents of the tarballs and stuff |
| 21:21.28 | kharwell | hrm yeah prob more trouble than it is worth |
| 21:28.54 | gtjoseph | kharwell: did oyu mean to -1 file's realtime fixes without comment? |
| 21:29.02 | file | he did comment previously |
| 21:29.09 | gtjoseph | ah |
| 21:29.22 | gtjoseph | didn't see any |
| 21:29.42 | kharwell | yeah wasn't initially sure if that was the case so didn't -1. Once confirmed I gave it a -1 so someone wouldn't accidentally push it in |
| 21:29.52 | file | it was regex related |
| 21:30.13 | file | and if someone can produce a regex which will get everything before an unescaped ; I'd be happy |
| 21:30.42 | file | hates regular expressions with a passion |
| 21:41.49 | gtjoseph | challenge accepted |
| 22:21.39 | gtjoseph | file: |
| 22:21.41 | gtjoseph | #!/bin/python |
| 22:21.41 | gtjoseph | import re |
| 22:21.41 | gtjoseph | line = "abc \;def\; x; x; x" |
| 22:21.41 | gtjoseph | match = re.match(r'.*?([^\\];)', line) |
| 22:21.42 | gtjoseph | if match: |
| 22:21.43 | gtjoseph | print line[0:(match.end()-1)] |
| 22:21.45 | gtjoseph | else: |
| 22:21.46 | gtjoseph | print line |
| 22:21.51 | file | you are 5th in line |
| 22:21.58 | file | (not even kidding) |
| 22:22.38 | gtjoseph | doesn't count if not posted in irc |
| 22:23.54 | file | gtjoseph, SHIP IT! |
| 22:25.00 | file | gtjoseph, so I assume that line at the end is abc \;def\; x |
| 22:25.21 | gtjoseph | correct "abc \;def\; x" |
| 22:25.28 | file | yeah, perfect |
| 22:25.49 | file | and abc \;def results in abc \;def? |
| 22:27.17 | gtjoseph | yep |
| 22:27.25 | file | cool! |
| 22:27.33 | gtjoseph | no match on unescaped ; so just prinbt line |
| 22:28.21 | gtjoseph | the non-greedy initial pattern is the key ".*?" |
| 22:36.31 | *** join/#asterisk-dev acidfu_ (~acidfoo@198-48-218-90.cpe.pppoe.ca) |
| 22:44.49 | file | oh say can you seeeeeeee, Wednesday approaching weeeeeee |
| 23:09.53 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-bncqsahjxbswyejz) |
| 23:09.57 | *** join/#asterisk-dev raspberrypifan (~raspberry@cpe-24-90-144-225.nyc.res.rr.com) |