| 01:35.21 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 01:35.21 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 05:00.29 | *** join/#asterisk-bugs Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) [NETSPLIT VICTIM] |
| 05:00.29 | *** join/#asterisk-bugs snuff-work (i=1000@61.29.30.137) [NETSPLIT VICTIM] |
| 05:00.29 | *** join/#asterisk-bugs d3wayne (n=deeewayn@76.29.245.9) [NETSPLIT VICTIM] |
| 05:00.29 | *** mode/#asterisk-bugs [+o Juggie] by irc.freenode.net |
| 05:01.42 | *** join/#asterisk-bugs codefreeze (n=steve_mu@216.166.159.235) |
| 05:01.42 | *** join/#asterisk-bugs mbranca (i=daemon@mi-gw1.voismart.net) [NETSPLIT VICTIM] |
| 05:01.42 | *** join/#asterisk-bugs MuffinMan (n=muffins@neutrino.joshua-colp.com) |
| 05:01.42 | *** mode/#asterisk-bugs [+o codefreeze] by irc.freenode.net |
| 08:04.46 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 08:34.37 | *** join/#asterisk-bugs mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 09:07.40 | *** join/#asterisk-bugs sx|lappy (n=sxpert@lgit-1225.obs.ujf-grenoble.fr) |
| 13:28.55 | *** join/#asterisk-bugs miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 13:40.19 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 13:47.43 | *** join/#asterisk-bugs oej (n=olle@gw-sthlm01.rebtel.com) |
| 15:32.25 | *** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 15:57.13 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 15:57.13 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 16:17.32 | d1mas | file: hello.... :)I have the same question as usually :) |
| 16:20.51 | *** join/#asterisk-bugs JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 16:20.51 | *** mode/#asterisk-bugs [+o JunK-Y] by ChanServ |
| 16:32.01 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 16:38.06 | *** part/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 17:55.36 | *** join/#asterisk-bugs miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 18:24.42 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:42.47 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:07.45 | *** join/#asterisk-bugs snuff-home (i=1001@220-253-11-146.VIC.netspace.net.au) |
| 19:07.51 | snuff-home | :) |
| 19:08.01 | Qwell | snuff-home: sorry for leaving so abruptly last night, had to head home, and got caught up in some stuff |
| 19:08.41 | Qwell | snuff-home: is there anything "strange" about your setup on that bug? like sparc, or anything like that? |
| 19:08.41 | lmadsen | I need to shower too |
| 19:08.50 | Qwell | or is it straight x86(_64) Linux? |
| 19:08.56 | snuff-home | in 2 hrs i will be back proper |
| 19:09.04 | snuff-home | which one.. the zaptel? |
| 19:09.10 | Qwell | transcoder |
| 19:09.23 | snuff-home | nope straight centos 5 |
| 19:09.40 | snuff-home | might even still be cent4.4 actually.. |
| 19:09.47 | Qwell | hmm, ok |
| 19:10.45 | snuff-home | i do have a transcoder case open with digium about the hard kern crashes i mention in the bug.. |
| 19:10.51 | Qwell | k |
| 19:10.59 | Qwell | I doubt those are related |
| 19:11.01 | snuff-home | but they haven't replied for 2 weeks |
| 19:30.01 | *** join/#asterisk-bugs BBHoss (n=hoss@c-71-207-173-38.hsd1.al.comcast.net) |
| 19:53.12 | putnopvut | M11818 |
| 19:53.13 | MuffinMan | [feedback] [Asterisk] Channels/chan_zap 0011818: Deadlock in chan_zap between zt_request and do_monitor reported by michael-fig http://bugs.digium.com/view.php?id=11818 |
| 19:54.05 | putnopvut | If someone who feels comfortable/familiar with chan_zap could look at the patch I uploaded, I'd appreciate it if you could report if I've done anything that seems just obviously flawed/wrong. |
| 19:58.08 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 20:06.48 | *** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 20:32.46 | Qwell | mvanbaak: testing the rev before what file just said. |
| 20:33.19 | mvanbaak | ok |
| 20:33.35 | Qwell | A102272 |
| 20:33.37 | MuffinMan | [102272] Committed by file on 2008-02-04 11:16:05: Update handling of asyncgoto so it properly works on channels that are currently executing a PBX. |
| 20:33.40 | mvanbaak | just providing some boundries to the window you have to go through |
| 20:33.48 | Qwell | yeah |
| 20:34.29 | mvanbaak | it is nice to see that ppl actually run trunk in production |
| 20:34.43 | Qwell | it does seem a little weird though that the verbose message there is actually doing priority + 1 |
| 20:35.15 | mvanbaak | yeah, specially since the verbose line is correct |
| 20:35.32 | mvanbaak | erm, it isnt |
| 20:35.44 | mvanbaak | lol, all them traces make my mind overheat |
| 20:35.48 | Qwell | it matches what's actually happening, at least. heh |
| 20:35.50 | mvanbaak | coffee time |
| 20:36.10 | mvanbaak | this proves you cannot focus for more then 2 hours in a row |
| 20:36.31 | Juggie | its a mystery! :) |
| 20:38.33 | Qwell | file: 102272 :( |
| 20:38.51 | Qwell | that made it unhappy |
| 20:39.02 | file | what bug? |
| 20:39.07 | Qwell | M11929 |
| 20:39.08 | MuffinMan | [new] [Asterisk] Channels/General 0011929: The dialplan executes wrong, it skips a priority reported by falves11 http://bugs.digium.com/view.php?id=11929 |
| 20:39.37 | file | oh wait a second |
| 20:39.56 | Qwell | I think it's the second part of that change |
| 20:41.12 | file | this makes me sad |
| 20:41.43 | Qwell | oh? |
| 20:41.44 | file | OKAY |
| 20:42.13 | file | Qwell: revert that part, then adjust ast_async_goto to pass in priority-1 |
| 20:42.24 | file | or +1 |
| 20:42.39 | Qwell | just the second part, or all of 102272? |
| 20:43.05 | file | the one that took out AUTOLOOP |
| 20:43.10 | file | s/one/part/ |
| 20:43.13 | Qwell | kk |
| 20:43.45 | file | the PBX core used to be in another loop that made this just work |
| 20:45.36 | Qwell | file: there are two calls to ast_explicit_goto in ast_async_goto |
| 20:45.52 | Juggie | file: as spiderman would say 'everybody gets one' :) |
| 20:46.04 | Qwell | Juggie: file already had his today |
| 20:46.10 | Juggie | oh |
| 20:46.28 | putnopvut | Ah, I was looking at that issue independently...I should have checked this channel for discussion. |
| 20:46.40 | Juggie | that salty new brunswick air is finally driving him crazy |
| 20:47.27 | Qwell | file: I guess just in the chan->pbx case? |
| 20:47.49 | file | Qwell: yes |
| 20:49.51 | file | I should just not commit stuff this week |
| 20:50.15 | Qwell | file: <3 |
| 20:53.47 | Qwell | file: svn log -r102500 |
| 20:53.53 | file | I saw! |
| 20:53.56 | Qwell | :D |
| 20:54.13 | file | <3 |
| 21:16.12 | mvanbaak | meh |
| 21:16.19 | mvanbaak | if (option_verbose > 2) |
| 21:16.28 | mvanbaak | <PROTECTED> |
| 21:17.24 | JunK-Y | no need for option_verbose within ast_verb(), no>? |
| 21:17.56 | mvanbaak | indeed |
| 21:18.05 | mvanbaak | <--- running through all the code |
| 21:18.43 | JunK-Y | ok, good. |
| 21:27.43 | mvanbaak | hahahahahaha |
| 21:27.52 | mvanbaak | if (option_verbose > 4) |
| 21:28.08 | mvanbaak | <PROTECTED> |
| 21:28.48 | Corydon76-dig | mvanbaak: no comma |
| 21:29.18 | mvanbaak | yeah sorry |
| 21:29.28 | mvanbaak | converting all those to app_verb( |
| 21:29.33 | mvanbaak | and that one needs a comma |
| 21:37.25 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 23:01.56 | d1mas | Guys, yesterday I already asked this idea but no one else seem to have interest. So I retry :) I believe it would be Good Thing to make DONT_OPTIMZE on by default. Or how lmadsen suggested - replace DONT_OPTIMIZE with its opposite - OPTIMIZE and made it off by default. |
| 23:02.16 | d1mas | This would save alot of time for YOU on Mantis |
| 23:02.23 | lmadsen | d1mas: are you able to create a patch and submit it? |
| 23:03.12 | putnopvut | lmadsen: oh he definitely does :) |
| 23:03.18 | lmadsen | ya that's what I thought :) |
| 23:03.25 | putnopvut | but I have to say I disagree with the idea. |
| 23:03.31 | lmadsen | d1mas: I guess you're looking for some to agree/disagree |
| 23:03.32 | d1mas | lmadsen: Heh. If I were able to create a patch I would already submit it :) I do code, but I'm not familar with configure/Makefile/Makeopt |
| 23:03.38 | lmadsen | gotcha |
| 23:03.55 | d1mas | lmadsen: ok, if everybody agree, I could even TRY doing that :) |
| 23:04.32 | d1mas | putnopvut: why ? |
| 23:04.44 | putnopvut | I disagree because the idea is to be optimistic that people aren't going to encounter bugs, and having an optimized build is better for those people. |
| 23:05.15 | putnopvut | Optimized builds, if I understand correctly, are supposed to run somewhat faster than non-optimized builds. |
| 23:05.21 | d1mas | putnopvut: you can make it ON for .100 releases :) |
| 23:05.53 | d1mas | putnopvut: well, they should run faster but does anyone has an idea how much faster actually? |
| 23:06.05 | d1mas | if it is about 5% I do not think it worth it |
| 23:06.10 | lmadsen | putnopvut: I guess... but we DO run into bugs, and they are going to happen, and it sucks when you run into something that isn't easy to reproduce (or you have no idea how it happened at all to even attempt to reproduce it), then you end up with a useless core dump |
| 23:06.11 | putnopvut | Really, only that much? |
| 23:06.24 | lmadsen | I heard the amount of optimization (speed) you get is minimal |
| 23:06.44 | putnopvut | If it's only that much, then I agree that it should be off by default. |
| 23:06.53 | lmadsen | plus if someone is REALLY that concerned with the speed, then they can turn on OPTIMIZATION flag |
| 23:06.59 | d1mas | putnopvut: no. I had no idea really. It was just a guess. Too much depend on architecture and what exactly is being compiled |
| 23:07.01 | putnopvut | Plus optimization comes at the expense of producing a larger executable. |
| 23:07.29 | lmadsen | which on most systems isn't a big deal (i.e. embedded would be... but not my Dell 2950s) |
| 23:07.48 | lmadsen | HD's are cheap |
| 23:08.04 | d1mas | for embedded system you will have to tune options anyway - to turn off channels you do not want etc |
| 23:08.10 | putnopvut | lmadsen: what I meant was optimized builds have LARGER executables than non-optimized builds. It actually plays in favor of d1mas's idea. |
| 23:08.33 | putnopvut | At least that what Corydon76-dig said one time. |
| 23:09.04 | d1mas | putnopvut: well, it also depends on what is being compiled. Optimized build CAN be smaller |
| 23:09.18 | lmadsen | putnopvut: ah gotcha :) |
| 23:10.25 | lmadsen | and from the support side of things, when someone has asterisk crash, then calls digium for support (or whoever), then you already have a useful coredump, instead of having to tell someone how to turn on the DONT_OPTIMIZE flag, then recompile/reinstall, then wait again for it to happen |
| 23:10.38 | putnopvut | Okay, if it turns out that optimized builds contribute a negligible performance increase, then I would be in favor of the default enabling of DONT_OPTIMIZE. |
| 23:10.48 | d1mas | just took a look at makefile stuff. Boy, changing DONT_ to OPTIMIZE will be soooo easy.... |
| 23:10.56 | lmadsen | heh |
| 23:12.15 | Corydon76-dig | d1mas: optimized build is almost never smaller |
| 23:12.53 | Corydon76-dig | The issue is that gcc optimizes based upon execution time, which usually means loading up lookup tables into the executable instead of doing calculations |
| 23:13.51 | d1mas | Corydin76: if you take whole application then yes. Usually. But for specific pieces of code optimization sometimes gives smaller binary |
| 23:13.55 | Corydon76-dig | You can get a smaller executable if you use -Os, though |
| 23:14.15 | Corydon76-dig | d1mas: I've never seen that with gcc |
| 23:14.42 | Corydon76-dig | What DOES add to the executable size, though, is the -g3 that is default (adding very verbose debugging symbols) |
| 23:15.36 | d1mas | I'm not a guru in compilers but I believe debugging symbolsh should NOT affect performance / load time. |
| 23:15.53 | d1mas | (well I hope on that) |
| 23:15.58 | Corydon76-dig | Generally they don't |
| 23:16.24 | d1mas | Corydon-76: anyway, what to you think about the idea ? |
| 23:16.26 | Corydon76-dig | Well, not other than in miniscule ways (needing to refresh the cache more often) |
| 23:17.53 | Corydon76-dig | d1mas: I think we'll get more criticism for trying to do it than is worth our resources |
| 23:18.55 | Corydon76-dig | Or what might could happen is leave DONT_OPTIMIZE off in release versions, but turn it on by default in SVN versions |
| 23:19.12 | Corydon76-dig | And no, I'm not in favor of renaming it |
| 23:19.31 | Corydon76-dig | There's too much documentation that would need to be revised, including dead tree versions |
| 23:19.52 | d1mas | how easy is to make it ON for release and OFF for SVN ? |
| 23:20.09 | Corydon76-dig | Not difficult at all |
| 23:20.15 | d1mas | to me it looks like significantly more work than changing the default forever... |
| 23:20.59 | Corydon76-dig | You have to understand that there's community relations involved. You screw with the default optimization and people will get pissed, rightfully or not. |
| 23:21.07 | d1mas | I mean it is easy to patch & commit. But how to make it different for different versions? |
| 23:22.25 | d1mas | Well, I can live with default optimization - I turned it off on my systems and that is all. Story ends. But every day I see reports on Mantis where first response from one of you guys is "please recompile without optimization" |
| 23:22.29 | Corydon76-dig | d1mas: if you want to continue this discussion, please propose it on the -dev list |
| 23:22.54 | Corydon76-dig | When you're discussing policy changes like that, it needs a wider forum |
| 23:23.26 | d1mas | dev-null you mean? :) if I'm not wrong 6 my last emails just disappeared there :) |
| 23:23.34 | d1mas | no offence :) |
| 23:24.08 | d1mas | Corydon-76: anyway, I will email -dev list |
| 23:27.06 | mvanbaak | I'm in favor of having optimization enabled by default on releases |
| 23:27.47 | mvanbaak | not all machines are highend |
| 23:28.03 | mvanbaak | hack, I maintain a dozen of NET4501 pbx boxen |
| 23:29.54 | mvanbaak | those machines are limited (size, resources, storage) and I like to have stock installs on it |
| 23:30.18 | mvanbaak | we have a test setup and there we can run with custom options |
| 23:30.35 | mvanbaak | but production is always a clean untar && ./configure && make install |
| 23:31.00 | lmadsen | ya, in my production boxes I turn DONT_OPTIMIZE on so that when I get a coredump, it's useful |
| 23:31.05 | lmadsen | but that's just me :) |
| 23:32.09 | mvanbaak | on most production systems the CF is mounted RO |
| 23:32.16 | mvanbaak | so a coredump cannot be written |
| 23:32.19 | mvanbaak | ever tried that ? |
| 23:32.22 | mvanbaak | it's funny |
| 23:38.18 | d1mas | heh. Well, I guess no sense writing to list :) |
| 23:40.19 | lmadsen | I still think it'd be a useful discussion |
| 23:40.27 | lmadsen | no matter what the decision |
| 23:40.27 | mvanbaak | me too |
| 23:40.43 | mvanbaak | I'm just 1 person |
| 23:40.49 | lmadsen | mvanbaak: I'm still installing deps in order to try and satisfy as many modules as possible |
| 23:40.59 | lmadsen | I'm only 1 person, but my vote only counts for 2 |
| 23:41.02 | mvanbaak | and I'll adopt to whatever the way we go |
| 23:41.18 | mvanbaak | if it means I have to alter my scripts so be it |
| 23:41.32 | d1mas | got it |
| 23:42.32 | mvanbaak | lol lmadsen |
| 23:42.40 | mvanbaak | lmadsen++ |
| 23:42.54 | mvanbaak | <--- off to bed |
| 23:43.06 | mvanbaak | lmadsen: really looking forward to your audit of my branch |
| 23:43.21 | mvanbaak | if it's positive we should get it merged to trunk |
| 23:43.22 | lmadsen | mvanbaak: coolio -- hope to keep focused on it for the night and that I have something for when you wake up |
| 23:43.34 | lmadsen | aye... my hope is that it'll make it in this week |
| 23:43.41 | mvanbaak | mine too |
| 23:43.45 | lmadsen | then I'll post something to asterisk-dev / asterisk-users with documentation |
| 23:43.53 | mvanbaak | but it's up to the powers that be |
| 23:43.56 | lmadsen | aye |
| 23:44.02 | lmadsen | we'll see what happens! |
| 23:44.19 | mvanbaak | ^5 and thanks for all the work you already put into it |
| 23:44.25 | lmadsen | np, thank you! |
| 23:44.30 | mvanbaak | np :) |
| 23:44.34 | mvanbaak | zzzzzzzzzzzzzz time here |
| 23:44.39 | mvanbaak | Wed Feb 6 00:44:38 CET 2008 |
| 23:44.42 | lmadsen | night night |
| 23:44.47 | mvanbaak | 6AM is wakey wakey time |
| 23:46.50 | lmadsen | eeep |
| 23:46.55 | lmadsen | I thought 8:20am was going to be bad |
| 23:47.04 | lmadsen | but it IS only 6:46pm here :) |