| 00:15.34 | Corydon76-dig | codefreeze: pong |
| 00:20.57 | Damin | anyone ever see zaptel Watchdog lock up a server before? |
| 00:22.20 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 00:31.09 | codefreeze | Corydon76-dig: did you see Vadim's letter on speedups? |
| 00:38.49 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.20.243.195.user.ajato.com.br) |
| 00:47.11 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 00:50.34 | codefreeze | Corydon76-dig: it could be that substitute_variables is running slow, because the size of the buffer that it memsets to 0 is 8K! |
| 01:03.21 | snuff-work | mm that's pretty sizable |
| 01:06.09 | codefreeze | ha, for 4 million iterations, it'll zero out almost 33Gbytes of data. |
| 01:06.17 | snuff-work | heh |
| 01:06.44 | snuff-work | var_buf_size is def'ed at 4k in trunk |
| 01:08.00 | codefreeze | must not be using it; I used gdb and broke in the subst. func to see how big the buffer was. |
| 01:10.04 | codefreeze | ah, EXT_DATA_SIZE |
| 01:17.10 | snuff-work | mm go codefreeze u can solve anything.. |
| 01:19.30 | codefreeze | snuff-work: compliments will get you... hmmm..... ran out of money! |
| 01:22.19 | *** join/#asterisk-dev ksteward (n=ksteward@71.174.94.169) |
| 01:23.47 | snuff-work | mmm |
| 02:21.51 | *** join/#asterisk-dev dlynes (n=dlynes@d154-20-9-152.bchsia.telus.net) |
| 03:01.35 | *** join/#asterisk-dev ZX81 (n=matt@202.49.106.158) |
| 03:43.43 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 03:55.12 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 05:03.20 | *** join/#asterisk-dev lukus (n=luke@202.172.122.210) |
| 05:17.49 | codefreeze | question: when I declare char str[1024] = ""; -- will all 1024 elements get zeroed, or just the first? |
| 05:21.19 | Corydon76-dig | All |
| 05:21.42 | codefreeze | Corydon76-dig: very, very interesting. |
| 05:23.13 | Corydon76-dig | Is the memset actually taking up many CPU cycles? |
| 05:23.38 | Corydon76-dig | My perception was that the compiler used a native x86 instruction to zero memory |
| 05:24.07 | Corydon76-dig | Hence making it extremely fast |
| 05:26.52 | codefreeze | Corydon76-dig: well, it might be fast, but the magnitude of it in the benchmark is overwhealming: over 4 million its, 8192 byte buffers, will have it memseting like 32 Gig of buffer. |
| 05:27.39 | codefreeze | Oh, and I forget: It possibly also sets another 4K buffer on top of that; add another 16 gig. |
| 05:28.40 | Corydon76-dig | Yes, but zeroing that memory should still be quite fast |
| 05:30.30 | codefreeze | Well, eliminating the need to memset before a substitute_variables_helper_full, speeds up the benchmark from like 88K pips to 97k pips.... |
| 05:31.51 | codefreeze | about 10% speedup, I guess |
| 06:06.28 | snuff-work | Corydon76-dig: i replied about 11125 |
| 06:51.38 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 07:08.15 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:44.31 | *** join/#asterisk-dev jmls (n=jmls@62.49.235.130) |
| 08:14.02 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 08:36.20 | *** join/#asterisk-dev agx (n=badpengu@81-174-47-185.dynamic.ngi.it) |
| 09:16.48 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 09:38.12 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 10:02.31 | *** join/#asterisk-dev roadies (n=chrislro@stun.cmf.nrl.navy.mil) |
| 10:03.04 | roadies | Qwell: are U on line? |
| 10:03.33 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:18.37 | *** join/#asterisk-dev eurodrew555 (n=eurodrew@83-244-164-130.cust-83.exponential-e.net) |
| 10:20.36 | *** join/#asterisk-dev UVSoft (n=jnk467@motorola154-31.ip.PeterStar.net) |
| 10:20.44 | UVSoft | hi |
| 10:21.47 | UVSoft | can anyone explain me what are the relationships between asterisk/trunk and asterisk/branches/1.4? |
| 10:23.58 | UVSoft | let say we have the revision X, will these two contain the same sources? |
| 10:26.25 | tzafrir | no. Those are two development branches |
| 10:28.22 | eurodrew555 | Hi tzafrir, would it be possible to consider running asterisk/trunk in a production environment, or is it strictly for development + testing only ? |
| 10:29.18 | tzafrir | It is technically possible. But I'm not the one to ask about this |
| 10:29.33 | eurodrew555 | ok thanks |
| 10:35.47 | agx | file, ping |
| 10:38.56 | agx | about http://bugs.digium.com/view.php?id=11091, someone can tell me what kind of logs are needed? i really do not understand :-((((( i've already provided full verbose+debug+sip debug |
| 10:39.30 | UVSoft | there's a nice branch asterisk/team/bbryant/sip-tcptls that brings SIP over TCP support, and i wonder how to get this functionality in asterisk-1.4.13 |
| 10:40.46 | tzafrir | agx, he seems to ask for some more context |
| 10:40.56 | tzafrir | at least that's my reading of it |
| 10:43.13 | agx | tzafrir, ah, i've to go to the office to pickup a new log then.... later |
| 10:50.21 | *** join/#asterisk-dev _ys (i=ys@91.151.196.254) |
| 11:04.49 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:51.29 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 12:07.28 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:07.28 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 12:21.29 | *** join/#asterisk-dev dlynes (n=dlynes@d154-20-9-152.bchsia.telus.net) |
| 12:22.12 | *** join/#asterisk-dev lirakis (n=eric@65.200.191.253) |
| 12:26.28 | blitzrage | morning all! |
| 12:39.31 | lirakis | morning |
| 12:40.43 | lirakis | blitzrage: thats not you who's tatooed is it? |
| 12:40.50 | blitzrage | it is :) |
| 12:40.53 | _ys | hi |
| 12:41.10 | _ys | please assign trivial 0011125 to branch-1.4 |
| 12:41.14 | Corydon76-dig | Eh? Tattoo? |
| 12:41.32 | lirakis | blitzrage: ha ha.. i didnt think jsmith was that tatoo type... |
| 12:41.40 | blitzrage | http://farm2.static.flickr.com/1386/1429670303_9823c7261e.jpg?v=0 |
| 12:41.44 | blitzrage | ya... he's not :) |
| 12:41.56 | Corydon76-dig | Heh |
| 12:42.15 | Corydon76-dig | That's not exactly the most painless place, either |
| 12:42.31 | blitzrage | ya, not so much :) |
| 12:42.43 | blitzrage | some spots were better than others |
| 12:42.49 | Corydon76-dig | Yep |
| 12:42.53 | blitzrage | I have one on my upper back that hurt less :) |
| 12:43.03 | blitzrage | actually... they were pretty comparable |
| 12:43.14 | blitzrage | both had sensitive spots, and both had pretty much numb spots |
| 12:43.28 | blitzrage | surprisingly, right on the spine is pretty much numb |
| 12:43.34 | Corydon76-dig | What's on your back? |
| 12:43.44 | blitzrage | calabi-yau |
| 12:43.53 | blitzrage | let me find a pic |
| 12:43.53 | Corydon76-dig | Besides me, when I'm around? ;-) |
| 12:44.20 | blitzrage | http://www.facebook.com/photo.php?pid=44720&l=354f3&id=512680761 |
| 12:44.27 | blitzrage | Corydon76-dig: ooooooooooooo burn :) |
| 12:44.53 | *** join/#asterisk-dev oej (n=olle@64.251.114.2) |
| 12:44.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:44.55 | Corydon76-dig | I think you've shown me that one before, actually |
| 12:45.00 | blitzrage | more than likely |
| 12:45.03 | blitzrage | I've had it for a while |
| 12:45.20 | Corydon76-dig | Yah... and I've shown you my penguin... |
| 12:46.39 | *** join/#asterisk-dev oej_ (n=olle@64.251.114.2) |
| 12:49.05 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.138.80) |
| 12:59.09 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:12.32 | *** join/#asterisk-dev eliel (n=eliel@host172038.metrored.net.ar) |
| 13:20.58 | eliel | ping Tilghman |
| 13:23.12 | IgorG | hello, good evening |
| 13:33.43 | *** join/#asterisk-dev michael-i (n=michael-@W88f2.w.pppool.de) |
| 13:38.21 | *** join/#asterisk-dev eurodrew555 (n=eurodrew@83-244-164-130.cust-83.exponential-e.net) |
| 13:42.09 | *** join/#asterisk-dev kpfleming (i=kpflemin@nat/digium/x-1b3e9defbcaade3c) |
| 13:42.09 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:42.20 | file | kpfleming: you! dance! now! |
| 13:42.52 | kpfleming | no... no. that would be quite horrible indeed. |
| 13:43.11 | file | and would drive everyone away? |
| 13:43.35 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:43.35 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 13:52.34 | De_Mon | M11125 |
| 13:52.35 | MuffinMan | [closed] [Asterisk] Core-General 0011125: [patch] Check before trying to free in utils.c reported by snuffy http://bugs.digium.com/view.php?id=11125 |
| 13:55.20 | *** join/#asterisk-dev mog (n=mog@c-71-207-231-41.hsd1.al.comcast.net) |
| 13:55.20 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:03.18 | tzanger | morning |
| 14:08.54 | blitzrage | howdy |
| 14:22.28 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 14:27.18 | eliel | M0011138 |
| 14:27.18 | MuffinMan | [new] [Asterisk] PBX/pbx_dundi 0011138: [patch] use ast_free() instead of free(). reported by eliel http://bugs.digium.com/view.php?id=0011138 |
| 14:27.43 | eliel | please don't give me karma for this trivial patches I feel guilty, I though this janitor was closed. |
| 14:29.08 | blitzrage | karma is a good thing to get -- and it's ok, because it can't be traded in for prizes or anything |
| 14:30.47 | _ys | chan_sip.c is also used free() instead of ast_free() :) |
| 14:32.31 | _ys | and chan_iax2.c etc.... |
| 14:32.46 | eliel | _ys: done |
| 14:36.45 | eliel | I think this is "new code" after the janitor was finished... |
| 14:37.46 | *** join/#asterisk-dev allankardec (n=root@20150068138.user.veloxzone.com.br) |
| 14:53.36 | *** join/#asterisk-dev ivanfm (n=ivanfm@c906b486.virtua.com.br) |
| 14:53.53 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 14:55.15 | UVSoft | hey guys, when is 1.6 going to come out? |
| 14:56.59 | blitzrage | when it does probably |
| 14:57.31 | MasterYoda | when it does most certainly |
| 14:57.41 | blitzrage | indeed |
| 14:58.40 | UVSoft | is there a timetable or something? |
| 14:58.48 | kpfleming | it will be released just a few moments after we make the releass |
| 14:59.32 | blitzrage | this is open source... there is no timetable :) |
| 14:59.38 | blitzrage | and there is no spoon |
| 15:01.08 | eliel | and there are no bugs... just simple ways to generate core dumps... |
| 15:01.22 | UVSoft | ) |
| 15:01.34 | blitzrage | heh |
| 15:01.44 | blitzrage | since 1.6 will come from trunk, you can use the code right now |
| 15:03.34 | *** join/#asterisk-dev putnopvut (i=putnopvu@nat/digium/x-98a1f7b0089ab97d) |
| 15:03.35 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:04.30 | UVSoft | does anybody know which version Asterisk Business Edition includes? |
| 15:05.08 | blitzrage | 1.2 until C.1 is released (in beta now) |
| 15:05.12 | blitzrage | C.1 will be 1.4 |
| 15:23.25 | *** join/#asterisk-dev zerohalo (n=zeroHalo@pool-71-255-162-167.bstnma.east.verizon.net) |
| 15:23.56 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 15:24.28 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:24.28 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:27.19 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 15:32.02 | roadies | are the configuration files for the AADK dynamically generated at boot time or can they be manually edited (outside the web interface). IF so where, how are they edited so turning them PBX off they are retained |
| 15:32.29 | *** join/#asterisk-dev ajohnson (n=ajohnson@63.147.46.186) |
| 15:40.43 | *** join/#asterisk-dev lvl- (n=lvl@a80-126-67-38.adsl.xs4all.nl) |
| 15:51.43 | lvl- | is there anyone around who could take a look at a backtrace? |
| 15:51.59 | lvl- | i'm experiencing semi-random crashes, and im having a hard time figuring out what's causing it |
| 15:54.13 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:54.30 | putnopvut | lvl-: have you looked on bugs.digium.com to see if your problem already has a bug open? |
| 15:54.44 | putnopvut | That came out weird. |
| 15:55.04 | putnopvut | What I meant is: Have you looked to see if there's already a similar issue on bugs.digium.com? |
| 15:55.46 | russellb | or you can just post the backtrace to pastebin.ca |
| 15:59.13 | lvl- | i've checked it out, but i didnt find anything that seemed related |
| 15:59.22 | lvl- | let me upload them |
| 16:01.20 | lvl- | http://s1.talkto.nl/asterisk/ |
| 16:01.56 | Qwell | lvl-: You're going to need to build asterisk unoptimized |
| 16:02.11 | lvl- | hm, i thought i did so |
| 16:02.55 | lvl- | enabled dont_optimize and debug_threads in the menuconfig |
| 16:05.56 | lvl- | that didnt go through correctly? |
| 16:06.21 | putnopvut | Did you make asterisk before or after selecting those options in menuselect? |
| 16:06.38 | lvl- | after. did a make clean/make/make install |
| 16:08.38 | lvl- | i can make it again, if i messed up somewhere |
| 16:11.10 | putnopvut | lvl-: Yes, please. The backtrace you provided isn't helpful since so much information was optimized out. |
| 16:11.51 | putnopvut | The crash.txt file is hellpful though. It at least gives a good starting point. |
| 16:12.14 | lvl- | ok, recompiling |
| 16:13.10 | lvl- | it always appears to crash in the neighbourhood of those events (the first 3 lines) |
| 16:13.41 | lvl- | though it can run for quite a while (showing that same sequence) without crashing at all |
| 16:22.57 | lvl- | hrm; i've recompiled it and ran into another crash, but the output from gdb seems pretty much the same |
| 16:26.00 | lvl- | is there a way to check wether it correctly compiled with the DONT_OPTIMIZE flag? |
| 16:40.20 | *** join/#asterisk-dev JackEStorm (n=no@ip68-225-77-136.no.no.cox.net) |
| 16:42.11 | *** join/#asterisk-dev lvl`home (n=lvl@101.248.dhcp.lht.hhs.nl) |
| 16:47.40 | *** join/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 16:47.40 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 16:48.27 | bweschke | /me waves to file! |
| 16:50.42 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 16:54.29 | roadies | Qwell: can you manually edit AADK extensions.conf file and retain the information? IF so how |
| 16:55.15 | Qwell | roadies: well, you could, but if you want the GUI to still work, you'll have to stick within it's guidelines. |
| 16:55.25 | Qwell | I don't know much about how the GUI works, so..I'm not really the person to ask. |
| 16:57.17 | lvl- | well, i'll brb from home.. please let me know if you have any ideas |
| 16:57.54 | MasterYoda | roadies: you should be able to manually edit the extensions.conf, the gui reads the file when ever it needs to change it |
| 16:58.09 | MasterYoda | roadies: also it only changes lines it needs to and leaves the rest intact |
| 16:58.57 | roadies | MasterYoda: the problem is how does the GUI save the new changes off so at boot time they are restored since the system is run from ramfs |
| 16:59.35 | Qwell | roadies: the save_config script backs up all of the configs (which is what the GUI runs when you click save) |
| 16:59.50 | Qwell | well, not *all* of the configs, but you get the point I think |
| 17:00.13 | Qwell | roadies: how did that CF thing end up working out BTW? |
| 17:00.21 | Qwell | hopefully well? |
| 17:02.13 | roadies | Qwell, thanks I'll look at that script, to see whats going on. As for the CF thing, help desk said they would mail me a new CF but first they had to check with someone, they never got back to me to get my mailing address. But I figure its no big deal, management has ordered me some 4G CFs which is better than what would be supplied. So unless it comes with data on it I dnt really need it |
| 17:05.01 | *** join/#asterisk-dev msetim (n=marcos@200.195.161.164) |
| 17:05.56 | msetim | hi |
| 17:06.07 | msetim | where can I read about asterisk deadlocks, I would like to undersdant it :) |
| 17:06.47 | russellb | msetim: there isn't anything special about asterisk deadlocks |
| 17:06.56 | russellb | if you search for "deadlocks" you can learn about what a deadlock is in general |
| 17:06.57 | mvanbaak | ast_do_deadlock() |
| 17:06.58 | mvanbaak | ;) |
| 17:07.10 | bweschke | you guys ever get that mutex presentation from Astricon up online ? |
| 17:07.15 | bweschke | that's probably a decent starting pt |
| 17:07.24 | russellb | bweschke: who gave that one? |
| 17:07.37 | msetim | russellb, I know how to works database relational deadlocks, it's same concept? |
| 17:07.39 | russellb | whatever got sent to me was sent for posting |
| 17:07.46 | msetim | mvanbaak, :-P tks |
| 17:07.50 | russellb | msetim: probably so, yeah |
| 17:08.07 | russellb | it's all about acquiring exclusive access to multiple resources |
| 17:08.18 | mvanbaak | msetim: yeah, those deadlocks are mostly the same concept |
| 17:08.19 | russellb | file: i don't think you sent me your astricon stuff :-p |
| 17:08.38 | file | hrm, I thought I did |
| 17:08.43 | file | I'll search for the USB key later |
| 17:08.55 | mvanbaak | gheh, about USB keys |
| 17:09.01 | mvanbaak | my boss walked in halfway the day |
| 17:09.04 | msetim | right guys... thanks |
| 17:09.07 | mvanbaak | just returned from a congres |
| 17:09.13 | mvanbaak | he did some talks there |
| 17:09.24 | mvanbaak | but starting the last talk |
| 17:09.31 | mvanbaak | all of a sudden his USB key was empty |
| 17:09.47 | mvanbaak | some fucker had an infected laptop with some nice worm on it |
| 17:10.11 | mvanbaak | as soon as you connect USB removable media to it, it wipes the media and puts this virus on it |
| 17:10.34 | blitzrage | oooooooooouch |
| 17:10.42 | putnopvut | That's horrible. |
| 17:10.57 | mvanbaak | yeah |
| 17:11.34 | mvanbaak | now I remember why I have an USB key with a physical switch on it to set it read-only |
| 17:11.35 | *** join/#asterisk-dev dlynes (n=dlynes@d154-20-9-152.bchsia.telus.net) |
| 17:12.45 | Damin | What is the general take on Hyperthreading with Asterisk 1.2? |
| 17:12.51 | Damin | Enable? Or Disable? |
| 17:12.56 | russellb | enable! |
| 17:13.16 | Damin | russellb: Why? |
| 17:13.21 | russellb | why not? |
| 17:13.22 | Corydon76-vcch | Depends on whether you're running with Zaptel hardware or not |
| 17:13.38 | Corydon76-vcch | If you're running with Zaptel hardware, I would tend to turn off hyperthreading |
| 17:13.43 | Damin | Corydon76-vcch: I'm running w/ Zaptel hardware.. |
| 17:14.14 | Damin | And I think I may have pushed the traffic limits on this box to the point where the interrupt issues are much more noticable.. |
| 17:14.34 | Corydon76-vcch | Hyperthreading just increases some contention for the CPU. If there's any chance of missing an interrupt, I'd turn it off |
| 17:14.55 | Damin | I am now starting to see jitter, delay and dropped packets on SIP to SIP calls.. and on SIP to TDM calls the outbound leg headed to the PSTN seems to be an issue.. |
| 17:15.07 | Corydon76-vcch | Is hyperthreading on? |
| 17:15.14 | Damin | We're getting dropouts on the outbound audio to the PSTN.. |
| 17:15.21 | Damin | And yes.. hyperthreading is enabled.. |
| 17:15.30 | Corydon76-vcch | I would turn it off and try that again |
| 17:15.32 | Damin | We have a maintenance window scheduled tonight to disable it.. |
| 17:17.20 | Corydon76-vcch | Without Zaptel hardware, I'd agree with Russell... turning it on wouldn't hurt |
| 17:18.19 | Damin | So what is the general consensus on multiple processors? Aren't you going to run into the same issues as w/ Hyperthreading? |
| 17:18.22 | *** join/#asterisk-dev bkruse (i=bkruse@nat/digium/x-4eba4c0444defb72) |
| 17:18.38 | dlynes | Damin: hyperthreading is cpu emulation, not a real cpu |
| 17:19.02 | Corydon76-vcch | Less so, because you have true parallelism with multiple processors |
| 17:19.06 | dlynes | Damin: that's why it causes issues...you don't have real interrupts with a fake cpu |
| 17:19.17 | Damin | dlynes: Right.. but when you have an SMP enabled kernel, and you are running IRQ balance, don't you have to schedule interrupts on both the CPUs? |
| 17:19.30 | Damin | Ahh.. that makes sense.. |
| 17:19.34 | Damin | Or more sense rather.. |
| 17:19.36 | Damin | So.. |
| 17:19.54 | Corydon76-vcch | but that's exactly why 2 2.5GHz processors is not the same speed as having a single 5.0 GHz processor... you'll lose a little bit with bus contention issues, for example |
| 17:20.03 | anonymouz666 | chan_zap.c: Failed to read gains: Invalid argument - Does this have solution ? Is a known bug ? Even in Digium support forum there's no reply... -users... |
| 17:20.10 | dlynes | Damin: I don't know if Digium hardware allows you to do it, or not, but Sangoma allows you to place the card on a specific CPU, also |
| 17:20.17 | bkruse | anonymouz666: what are your gain settings? |
| 17:20.29 | Damin | If you had the choice of Dual Processor 2.8 Ghz Xeon or Single processor 3 Ghz Xeon, and you had to run Zaptel hardware, which would you choose? :) |
| 17:20.33 | anonymouz666 | http://pastebin.ca/757671 |
| 17:20.44 | dlynes | Damin: the dual, obviously :) |
| 17:21.32 | Corydon76-vcch | Damin: yeah, the performance degradation isn't THAT bad. ;-) |
| 17:21.53 | anonymouz666 | bkruse: there's nothing wrong, I think |
| 17:21.54 | Corydon76-vcch | You lose approximately 5-10% with each CPU added to the system |
| 17:22.12 | Damin | Cool.. quad quad core it is then! :) |
| 17:22.15 | Corydon76-vcch | but that can be remedied with multiple interfaces to the bus |
| 17:22.23 | Qwell | Can somebody explain to me when exactly sleep() is acceptable? |
| 17:22.38 | Damin | Qwell: When you are really tired and can't continue? |
| 17:22.38 | Corydon76-vcch | Qwell: when you don't have a channel to maintain |
| 17:22.40 | Qwell | (or usleep(), or...) |
| 17:22.41 | dlynes | Qwell: how about a yield(), instead? |
| 17:22.42 | *** join/#asterisk-dev seanbright (n=elixer@65.207.74.18) |
| 17:22.44 | blitzrage | putnopvut: I can't reproduce any of his issues at all --everything works perfect |
| 17:22.54 | putnopvut | Well, good. |
| 17:22.57 | putnopvut | And crap, too. |
| 17:22.58 | Qwell | Corydon76-vcch: so, say, during a reload? |
| 17:22.58 | Corydon76-vcch | usleep(1) is effectively the same as pthread_yield() |
| 17:23.11 | Corydon76-vcch | Qwell: in a monitoring thread? sure |
| 17:23.30 | Qwell | called from a CLI command, zap_restart, specifically |
| 17:23.35 | Corydon76-vcch | or sched_yield(), for that matter |
| 17:24.00 | Corydon76-vcch | Qwell: realize that the CLI won't get back control during that time |
| 17:24.06 | Qwell | yep |
| 17:25.31 | Corydon76-vcch | sleep() is also somewhat dangerous on some platforms, owing to its implementation with a SIGALRM handler |
| 17:25.40 | Corydon76-vcch | and Linux is one of those platforms |
| 17:25.48 | Qwell | eh? |
| 17:26.03 | Corydon76-vcch | sleep() is implemented with a signal |
| 17:26.05 | Qwell | like, it's interuptable? |
| 17:26.16 | Qwell | interruptible* |
| 17:26.20 | Corydon76-vcch | Yes, it is |
| 17:26.58 | Corydon76-vcch | I think sleep is implemented so that's handled, but you basically can only have a single sleep() call per process |
| 17:27.13 | Qwell | single simultaneous sleep()? |
| 17:27.15 | Corydon76-vcch | because a second call changes the interrupt handler |
| 17:27.42 | Corydon76-vcch | Right, simultaneous |
| 17:27.48 | Qwell | interesting |
| 17:28.05 | bweschke | Qwell: you've adapted yourself to Huntsville living already |
| 17:28.14 | Qwell | bweschke: howso? |
| 17:28.19 | Qwell | I'm not sure if that's an insult or not ;) |
| 17:28.37 | bweschke | Qwell: $50 doesn't even get my wife and I more than a round of drinks in NY metro area |
| 17:28.41 | Qwell | ahh |
| 17:29.25 | bweschke | /me contemplates the thought of an open source micro-brewery |
| 17:29.53 | Qwell | there is one! |
| 17:29.56 | Qwell | sort of |
| 17:30.03 | Qwell | free (as in freedom) beer |
| 17:30.27 | bweschke | /me runs in circles while googling it |
| 17:30.48 | Qwell | saw it on slashdot probably 18 months ago |
| 17:30.57 | blitzrage | putnopvut: I wrote a nice big note :) |
| 17:31.05 | putnopvut | Awesome, I can't wait to read it. |
| 17:31.17 | blitzrage | I'm tempted to close the issue.... |
| 17:31.28 | blitzrage | but I'll give him a chance to reply today |
| 17:31.35 | putnopvut | Heh. Yeah, but I'm sure that dude will be pissed if you do that. |
| 17:31.48 | Corydon76-vcch | Qwell: we might start down the road of using nanosleep() in preference to usleep(). |
| 17:31.58 | putnopvut | Ooh, nanosecond resolution? |
| 17:32.03 | blitzrage | ya well, I'm pissed I've had to pull teeth |
| 17:32.18 | blitzrage | :) |
| 17:32.23 | Corydon76-vcch | No, same thing, but nanosleep() is a POSIX interface |
| 17:32.23 | blitzrage | and I hate the dentist |
| 17:33.01 | Corydon76-vcch | meaning its behavior is well-defined |
| 17:33.12 | putnopvut | So, then why the hell is it called nanosleep? |
| 17:34.01 | Corydon76-vcch | No, I meant that in the common usage, it's just a pthread_yield() |
| 17:34.48 | Corydon76-vcch | nanosleep is a kernel call, whereas usleep is a libc call |
| 17:35.16 | Corydon76-vcch | So nanosleep is also a bit more direct |
| 17:36.29 | seanbright | res_telepathy gets released this month! score! |
| 17:36.52 | *** topic/#asterisk-dev by Qwell -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@misery.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release expected December 2007 -=- Tier 2 and Tier 3.14159 support is in #asterisk -=- New Digium Building: http://flickr.com/photos/kpfleming/sets/72157602339837221/ |
| 17:36.59 | Qwell | who saw that coming? |
| 17:37.03 | Qwell | I did! |
| 17:37.04 | seanbright | heh |
| 17:37.12 | putnopvut | I can one-up that. |
| 17:37.12 | seanbright | well, me too. |
| 17:37.14 | seanbright | i set you up |
| 17:37.22 | *** topic/#asterisk-dev by putnopvut -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@misery.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- New Digium Building: http://flickr.com/photos/kpfleming/sets/72157602339837221/ |
| 17:37.28 | putnopvut | There |
| 17:37.28 | Qwell | eep |
| 17:37.29 | *** join/#asterisk-dev ManxPower (n=manxpowe@120.sub-75-201-68.myvzw.com) |
| 17:37.31 | Qwell | putnopvut: the other way |
| 17:37.39 | russellb | o.O |
| 17:37.41 | Qwell | Corydon76-vcch: firewall |
| 17:38.04 | seanbright | or you could just say "next month" |
| 17:38.04 | Qwell | (there is a real fire wall between our offices) |
| 17:40.09 | Corydon76-vcch | It's always one month away? |
| 17:40.19 | seanbright | i think that's the idea |
| 17:40.51 | seanbright | i'm sure someone could code up a tcl script or something to handle that |
| 17:41.21 | seanbright | ah, but chanserv is the only bot |
| 17:41.23 | seanbright | oh well |
| 17:41.35 | eliel | Corydon76-vcch: Hello, I would like to know why you didn't use my patch in 0011136 for checking the alloc's, this is just to learn... |
| 17:44.56 | *** join/#asterisk-dev oej (n=olle@64.251.114.2) |
| 17:44.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:46.24 | Corydon76-vcch | eliel: you changed some lines unnecessarily |
| 17:46.44 | Corydon76-vcch | eliel: I went with the minimum number of lines that needed to be changed |
| 17:49.03 | eliel | Corydon76-vcch: Ok, thanks |
| 17:49.58 | codefreeze | Is anyone going to get mad if I go ahead and commit my fast-ast3 performance improvements into trunk? |
| 17:50.44 | blitzrage | I'll be furious |
| 17:51.50 | codefreeze | furious? fuming? fumious? |
| 17:51.58 | bweschke | /me is related to the slowsky's.. he's very much opposed to performance improvements... anywhere |
| 17:52.24 | *** part/#asterisk-dev mog (n=mog@c-71-207-231-41.hsd1.al.comcast.net) |
| 17:53.05 | putnopvut | codefreeze: what's the final word on performance increases? |
| 17:53.30 | codefreeze | By definition, there will never be a final word in perf incs. |
| 17:53.39 | *** join/#asterisk-dev kannan (n=kannan@61.11.72.127) |
| 17:53.41 | putnopvut | Quite true. |
| 17:53.53 | bweschke | I actually thought the whole dive into that particular issue was really, really cool.. that you could get that much of a performance increase overall |
| 17:54.04 | putnopvut | To rephrase: What performance benefits have you witnessed in your fast-ast3 branch? |
| 17:54.16 | eliel | Corydon76-vcch: but I think that allocating memory and then checking some conditions that could break the normal flow of the function is not the "best" way of programming, we could first check those conditions and the allocate the memory that is being used in the body of the function. Just a suggestion. |
| 17:54.38 | bweschke | didn't he get like almost a 20k+ PIP performance increase ? |
| 17:54.41 | blitzrage | codefreeze: yes! |
| 17:54.42 | bweschke | or just short of 20k ? |
| 17:55.06 | eliel | Corydon76-vcch: with this, when the "error" condition occurs we have avoided the allocs and free's |
| 17:55.27 | Corydon76-vcch | eliel: the error condition should never occur |
| 17:55.41 | codefreeze | bweschke: I moved it from around 76k pips (on my machine) to 100K pips with two tweaks to the code. |
| 17:56.12 | eliel | Corydon76-vcch: ok |
| 17:56.13 | bweschke | codefreeze: again, all kidding aside, that's pretty impressive |
| 17:56.34 | Corydon76-vcch | eliel: that error condition can only happen with a corrupted lock, in which case, we're about to crash, anyway |
| 17:57.00 | codefreeze | bweschke: many thanks. |
| 17:57.16 | Corydon76-vcch | Hence why I didn't bother freeing the memory in there, either |
| 17:57.40 | Corydon76-vcch | So technically, you're correct, but practically, it makes no difference |
| 17:58.14 | eliel | Corydon76-vcch: yes you are right! thanks |
| 17:58.15 | Corydon76-vcch | However, you WERE correct, that I should have been checking for the calloc failures, so I went ahead and corrected that |
| 17:59.22 | codefreeze | putnopvut: I made two tweaks to improve the speed: 1. merge the calls to exists_extension and spawn_extension when they are called in sequence. 2. made substitute_variables_helper_full write a null byte after its evaluation, and remove the requirement to zero out the buffer you pass it. |
| 18:00.22 | putnopvut | I saw you mention those on the list, but I hadn't heard any numbers yet regarding how much performance increased. |
| 18:00.44 | putnopvut | Oh, wait I see. |
| 18:00.50 | putnopvut | It was in your longer note. |
| 18:00.55 | putnopvut | Up to 100K. Awesome! |
| 18:01.24 | codefreeze | putnopvut: about 25% in speed. To counter the ~20% slowdown since last year. |
| 18:01.43 | putnopvut | That's impressive. |
| 18:02.49 | seanbright | codefreeze: now make it twice as fast. annnnnnnnnnd GO! |
| 18:03.27 | codefreeze | Well, I'd like to have these tweaks in trunk in prep for the fast-ast2 performance mods; For a large dialplan, they will give from 4X to 23x speedups. |
| 18:04.00 | seanbright | crazy |
| 18:04.25 | seanbright | does app arguments get parsed and sub'd every time the app is called? |
| 18:04.32 | seanbright | s/does/do/ |
| 18:04.37 | russellb | seanbright: yes. |
| 18:04.46 | seanbright | m'kay |
| 18:05.38 | codefreeze | I'll attack that in AEL3. Should have an execution engine then, as efficient as perl's. |
| 18:06.30 | seanbright | wow |
| 18:06.34 | seanbright | can i quote you on that? ;-) |
| 18:07.00 | file | seanbright: that costs $$$ |
| 18:07.23 | codefreeze | seanbright: sure, especially if I get royalties! |
| 18:07.27 | seanbright | ahhh |
| 18:08.31 | codefreeze | I'm sure file will be send you an invoice from telcomjoshvoxmartindustriesincorporated, or whatever |
| 18:09.00 | seanbright | i actually own that domain name, strangely enough |
| 18:09.23 | Corydon76-vcch | Squatter! |
| 18:09.48 | codefreeze | I don't think it's strange enough! But, I'm pretty strange myself, and have high expectations. |
| 18:10.12 | seanbright | well my middle name is Joshvoxmartin |
| 18:10.16 | seanbright | so i'm allowed |
| 18:10.18 | seanbright | heh |
| 18:10.19 | bweschke | lol |
| 18:11.00 | bweschke | it would be mildly interesting to see how much a performance increase would be gained by some sort of "app arg parsing cache" .. obviously - |
| 18:11.03 | bweschke | that's driven by |
| 18:11.09 | Corydon76-vcch | codefreeze: you, strange? It's not like you have a 99 item IVR for telemarketers or anything... |
| 18:11.24 | codefreeze | lol |
| 18:11.38 | bweschke | how many times the same thing is getting called over and over again |
| 18:11.51 | seanbright | bweschke: i was mulling it over last night, not sure you'd get that much out of it |
| 18:11.54 | codefreeze | it appears I even have evidence to back my claims! |
| 18:12.33 | bweschke | I think time would be better spent trying to reduce the number of core calls walking the entire channel list |
| 18:12.42 | bweschke | or is that in ast2obj already ? |
| 18:12.48 | seanbright | bweschke: you'd have to maintain a list or tree structure |
| 18:13.04 | codefreeze | bweschke: every time from scratch. But because args have var refs, you can't just cache them. You have to use a parse tree. |
| 18:13.04 | bweschke | I know he was working on it.. |
| 18:13.18 | bweschke | did it make it into trunk ? |
| 18:13.49 | Corydon76-vcch | Not just var refs. Some people actually have the gall to store more than one argument in a single variable |
| 18:14.01 | seanbright | ugh |
| 18:14.03 | seanbright | oh yeah |
| 18:14.03 | codefreeze | No, when I make a working grammar for AEL3, I'll open a new branch for it, and wail away on it. |
| 18:14.24 | file | bweschke: not yet, complex stuffz |
| 18:14.42 | bweschke | I would have to believe app_queue performance got significantly better moving stuff into ast2obj as well |
| 18:14.56 | bweschke | eliminating the walking of the interface and queue/members lists |
| 18:16.54 | codefreeze | bweschke: amen. |
| 18:19.07 | codefreeze | Corydon76-dig: a variable can hold a tree... a very interesting thought for the future. |
| 18:22.01 | codefreeze | Well, ok, no big cries of objection.... let's see how many subtle bugs show up from this one.... |
| 18:27.51 | Qwell | bweschke: 11/1? |
| 18:28.13 | bweschke | Qwell: ?? |
| 18:28.19 | Qwell | stop.date="1"? |
| 18:28.38 | bweschke | I don't think that implies mday to them |
| 18:28.46 | bweschke | I believe it implies the week of the month |
| 18:28.53 | bweschke | silly Pcom config files |
| 18:28.54 | Qwell | start.date="8" |
| 18:29.12 | bweschke | ugh.. |
| 18:29.17 | bweschke | you're gonna make me sling out the PDF now |
| 18:29.22 | bweschke | lol |
| 18:30.54 | Qwell | for the record, it's what we have on our phones too. just curious what it means |
| 18:31.01 | bweschke | one sec |
| 18:31.05 | bweschke | looking it up in the PDF |
| 18:31.31 | bweschke | strange too.. |
| 18:31.40 | bweschke | my reply still hasn't echo'd back to me yet |
| 18:31.43 | bweschke | on the list |
| 18:32.34 | bweschke | oooo.. internal links in the new PDF documentation.. nice |
| 18:36.18 | bweschke | 8 = the second occurrence of a given day-of-week in a month for start.date |
| 18:36.35 | Qwell | what is it, a flag? |
| 18:36.42 | bweschke | yep |
| 18:36.48 | Qwell | silly polycom |
| 18:36.53 | *** join/#asterisk-dev msetim (n=marcos@200.195.161.164) |
| 18:36.58 | bweschke | only applicable if fixedDayEnable is 0 |
| 18:37.02 | Qwell | right |
| 18:37.08 | Qwell | hmm |
| 18:37.23 | Qwell | what if it stops on a specific date, and starts on a specific day of week? |
| 18:37.27 | bweschke | and stop.date |
| 18:37.30 | bweschke | is NOT a flog |
| 18:37.33 | bweschke | flag |
| 18:37.33 | Qwell | wtf |
| 18:37.38 | bweschke | oh ya |
| 18:37.46 | Qwell | so, what is it? week #? |
| 18:37.59 | bweschke | Day of month to stop DST, period. |
| 18:38.07 | Qwell | so...today? |
| 18:38.30 | bweschke | wow |
| 18:38.34 | bweschke | this documentation is a mess |
| 18:39.04 | bweschke | k |
| 18:39.04 | bweschke | so |
| 18:39.19 | bweschke | for stop.dayofWeek.lastinMonth |
| 18:40.06 | bweschke | "if set to 1 and fixeddayenable set to 0, DST stops on the last day (specified by stop.dayofWeek) of the week in the month The stop.date is ignored" |
| 18:40.42 | blitzrage | Qwell: you should be! |
| 18:40.47 | bweschke | if we had conf files that looked like this the community would be roasting us at the stake - or handing out shrooms so everyone would "get it" |
| 18:41.49 | bweschke | and you all thought it was easy for me to reverse engineer their ACD login/logout functionality... :) |
| 18:47.19 | roadies | Qwell, another mild stone but a bug found with the AADK..... success: called from AADK analog phone thru PSTN to analog phone. bugs: the Calling Rules "delete" doesnt delete. And the number of digits needs to equal the number required to dial, aka 993037071234 must equal _99XXXXXXXXXX, despite the "!" |
| 18:47.21 | bweschke | /me doesn't need any reverse engineering.. he likes things OPEN |
| 18:50.53 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 18:51.39 | codefreeze | bweschke: your '/me' isn't working right |
| 18:51.44 | mvanbaak | reverse engineered bweschke: papa_bweschke & mama_bweschke |
| 18:52.11 | bweschke | codefreeze: how so ? |
| 18:52.18 | mvanbaak | 19:47 <@ bweschke> /me doesn't need any reverse engineering.. he likes things OPEN |
| 18:52.37 | bweschke | oh... interesting.. I'm using an IRC transport on a wildfire server and it appears correct in the conf room |
| 18:52.38 | bweschke | cute |
| 18:53.22 | bweschke | ya - I'm sure it's the transport messing it up |
| 18:53.32 | putnopvut | I see it fine. |
| 18:53.46 | mvanbaak | is see the actual /me |
| 18:53.54 | mvanbaak | as normal channel text |
| 18:53.57 | mvanbaak | instead of channel action |
| 18:54.14 | putnopvut | I guess my client just interprets a /me for me then. |
| 18:54.19 | bweschke | could be.. |
| 18:54.23 | bweschke | shucks.. |
| 18:54.36 | bweschke | just when I thought I had everything consolidated all nice into one "chat" client |
| 18:54.56 | codefreeze | bweschke: tell me about it. The name's Murphy. |
| 18:55.08 | bweschke | codefreeze: noted. |
| 18:56.16 | mvanbaak | bweschke: I use irssi to connect to various irc servers and to my bitlbee server |
| 18:56.24 | mvanbaak | bitlbee is doing all the IM stuff |
| 18:56.49 | mvanbaak | that way you can have 1 client for many different chat protocols as well |
| 18:56.59 | bweschke | mvanbaak: I heard about bitlbee.. haven't tried it yet.. this is really the first issue I've found with Openfire and Psi as a client |
| 18:57.03 | bweschke | well |
| 18:57.04 | mvanbaak | and since irssi is the best client ever... |
| 18:57.30 | bweschke | that and the fact that the chat logging historical UI leaves something to be desired with Psi |
| 18:58.02 | mvanbaak | ssh + screen + irssi + mutt + vim |
| 18:58.06 | mvanbaak | what more does one need |
| 19:00.25 | bweschke | I'm with you on ssh + screen + vim |
| 19:00.48 | bweschke | I like my Thunderbird and minus the one flaw with IRC - I still like Psi |
| 19:03.39 | tzafrir | what I miss, and what xchat and gaim are very good at, is alerting me of new messages |
| 19:03.46 | tzafrir | in a very useful way |
| 19:04.24 | De_Mon | irssi for the win |
| 19:05.52 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 19:06.43 | tzafrir | I mean: I get an alert "window" to switch to the desktop for gaim (or xchat) and to the exact window where the chat is |
| 19:07.52 | tzafrir | I actually use xchat+bitllbee for some instant-messangers :-) |
| 19:09.01 | tzafrir | (and irssi as a backup if I ever need to connect from a friend's house) |
| 19:15.04 | tzanger | irssi in screen, the only way to fly |
| 19:16.50 | *** join/#asterisk-dev mog (n=mog@c-71-207-231-41.hsd1.al.comcast.net) |
| 19:16.50 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 19:23.06 | mvanbaak | tzanger: irssi will make the window number bold and pink if your name is said in that window by default |
| 19:23.06 | mvanbaak | of course you can theme it ;) |
| 19:23.06 | tzanger | yep I know |
| 19:23.47 | mvanbaak | oops |
| 19:23.54 | mvanbaak | freaking lookalikes you 2 |
| 19:24.04 | mvanbaak | it was meant to say: tzafrir |
| 19:24.05 | mvanbaak | ;) |
| 19:24.08 | tzanger | haha |
| 19:25.07 | tzafrir | mvanbaak, but can you make the xterm of irsii alert as well as xchat does? |
| 19:25.42 | mvanbaak | with a bit of scripting that should be possible yeah |
| 19:26.05 | tzafrir | It adds a blinking "window" on the taskbar in the current desktop. When you switch to that window, you switch to the desktop of xchat |
| 19:26.24 | mvanbaak | ah |
| 19:26.30 | mvanbaak | I dont have a taskbar |
| 19:26.36 | tzanger | tzafrir: in a konsole screen session when something's trying to get my attention the shell icon turns to a bell (and if I have sound on it'll bong at me) |
| 19:26.44 | tzafrir | This seems to be some standard window-manager-level stuff, as my icewm understands it as well |
| 19:28.32 | tzafrir | tzanger, but what if you're in a different desktop altogether? |
| 19:28.45 | tzanger | tzafrir: the taskbar usually has something to tell you about it |
| 19:28.49 | tzanger | I don't use multiple desktops myself |
| 19:28.57 | tzanger | I have multiple montiors on my workstation |
| 19:29.54 | mvanbaak | me too |
| 19:30.00 | mvanbaak | but still I need multiple desktops :) |
| 19:30.01 | tzafrir | tzanger, the thing is that simply the next alt-tab will switch to that alerting window |
| 19:30.25 | mvanbaak | I bet it wont work with ion3 |
| 19:31.33 | tzafrir | never got the hang of ion. I use icewm for "10 desktops of mostly xterms" |
| 19:33.42 | _ys | multiple desktops, first step to multiple wifes :) |
| 19:34.42 | tzanger | tzafrir: *nods* I'm sure you can do something similar, just never set it up |
| 19:34.47 | tzanger | multiple desktops always got me lost |
| 19:40.57 | *** join/#asterisk-dev agx (n=badpengu@81-174-47-187.dynamic.ngi.it) |
| 19:44.31 | *** join/#asterisk-dev jgoo (n=249fe70a@77.49.246.143) |
| 19:44.38 | jmls | three days my adsl has been down. the PPP authentication is failing, but they *insist* that they must send an engineer around to make sure it's not my equipment. |
| 19:44.58 | mvanbaak | argh |
| 19:45.04 | mvanbaak | moving servers is annoying |
| 19:45.14 | mvanbaak | now my automerge stuff is not working |
| 19:45.16 | mvanbaak | blegh |
| 19:45.16 | De_Mon | jmls not using windows are you ;) |
| 19:45.34 | jmls | nah, it's the draytek router that is not connecting |
| 19:45.46 | jmls | or the belkin router. |
| 19:45.52 | jmls | or the netgear. |
| 19:45.56 | jmls | or the linksys |
| 19:46.07 | De_Mon | you've tried them all? shesh |
| 19:46.15 | jmls | yup |
| 19:46.21 | De_Mon | sounds like some problems weve been having with timwarner |
| 19:46.28 | jmls | and they all fail with "permission denied" |
| 19:46.37 | jmls | or "incorrect user name or password" |
| 19:46.44 | jmls | and no, it's not incorrect. |
| 19:46.45 | De_Mon | not with authentication, just general failure to stay connected. |
| 19:46.45 | jmls | ;) |
| 19:47.05 | jmls | so, I'm sort of back online. |
| 19:47.49 | De_Mon | shoot, i forgot what I was doing before I got interupted |
| 19:47.58 | jmls | heh |
| 19:48.06 | De_Mon | oh yeah sql |
| 19:49.32 | De_Mon | bah i hate mysql, it doesnt support postgresql date time syntax |
| 19:50.04 | mvanbaak | THANK GOD FOR BACKUPS ! |
| 19:50.46 | jmls | mmm. three new crashes for peoples perusal ... |
| 19:50.49 | jmls | http://pastebin.com/m75d5bf11 |
| 19:52.12 | De_Mon | this in trunk? |
| 19:52.37 | jmls | http://pastebin.com/m3cfd1620 |
| 19:52.40 | jmls | nope. 1.4 |
| 19:52.41 | putnopvut | jmls: Interesting that you have a stringfield crash, since rizzo has been working on that. |
| 19:52.53 | putnopvut | I'm not sure he's made any commits to 1.4 yet though. |
| 19:54.05 | jmls | and http://pastebin.com/mb5d09aa |
| 19:55.06 | jmls | strange thing is that we ran all week without a single crash, and then *wham* three in a row on a single day. Nothing is different, same people, same tasks, same phones, same software, same hardware |
| 19:55.47 | Corydon76-vcch | Different customers |
| 19:55.59 | jmls | nope. |
| 19:56.28 | jmls | different day, I'll grant you .. ;) |
| 19:57.50 | putnopvut | So, the second crash you reported has led me to app_dial, and I have to ask who came up with the variable name "toast" and why. |
| 19:58.06 | bweschke | roflol |
| 19:58.08 | jmls | because it crashes and burns .. |
| 19:58.15 | bweschke | muhahahaha.... "toast" |
| 19:58.15 | Corydon76-vcch | Different temperature in the office |
| 19:58.49 | Corydon76-vcch | or humidity |
| 19:58.58 | *** part/#asterisk-dev agx (n=badpengu@81-174-47-187.dynamic.ngi.it) |
| 19:59.01 | jmls | Corydon76-dig: nope. isolated server room with 2 aircon units, one as backup. temp a constant 18. |
| 19:59.05 | putnopvut | jmls: The second crash you have reported is one that blitzrage had recently too and which last I checked codefreeze was working on. |
| 19:59.28 | Corydon76-vcch | 18? Don't you think you should keep it above 32F? |
| 19:59.33 | putnopvut | That is, it occurred in the same place, but for different reasons. |
| 19:59.37 | jmls | Go, devs ;) |
| 19:59.45 | bweschke | lol Corydon76-vcch: you beat me to it |
| 19:59.46 | jmls | 18C. |
| 19:59.58 | codefreeze | which crash is we speakin' bout? |
| 20:00.22 | Corydon76-vcch | Well, if the temperature is 18, it obviously should be 17 |
| 20:00.30 | putnopvut | codefreeze: remember blitzrage's crash where he was setting a RINGCYCLE variable or something? |
| 20:00.39 | jmls | oh, wait, |
| 20:00.45 | Corydon76-vcch | and if it was 17, it obviously should have been 18 |
| 20:00.47 | putnopvut | It was crashing in pbx_builtin_setvar_helper in the same place as jmls's second crash. |
| 20:00.52 | codefreeze | oh, the 64 bit thing. |
| 20:00.58 | putnopvut | Yeah, that one. |
| 20:01.16 | jmls | keep 'em on their toes ;) |
| 20:01.37 | jmls | putnopvut: um, I'm on 32-bit .. |
| 20:02.25 | codefreeze | WHAT??? my pc says it's 1:00, and my unix boxes say 2:00; when does dst end now? |
| 20:02.29 | jmls | putnopvut: and the third crash ? Who's working on that one ? :p |
| 20:02.37 | putnopvut | Not sure about the third one. |
| 20:02.44 | jmls | pc is running windows ? |
| 20:02.53 | codefreeze | yes, vista |
| 20:02.56 | Qwell | codefreeze: next week |
| 20:02.59 | Qwell | erm, this weekend |
| 20:03.03 | Qwell | whichever |
| 20:03.06 | putnopvut | And regarding the 64-bit vs 32 bit thing...he only experienced the crash on a 64-bit machine. |
| 20:03.49 | blitzrage | howdy |
| 20:03.53 | putnopvut | But it's on the same line, so it makes me think there's some sort of memory corruption going on in the variable list maybe. |
| 20:04.05 | jmls | sshhhh. He's here ... |
| 20:04.06 | putnopvut | Ah, blitzrage, nice of you to drop by! |
| 20:04.10 | codefreeze | putnopvut: and if mem serves me, only on ***blitzrage's** 64 bit machine(s)... others were not bothered. |
| 20:04.16 | blitzrage | thx! |
| 20:04.22 | jmls | whoa. cause and effect .. |
| 20:04.27 | blitzrage | ya... asterisk hates me |
| 20:04.32 | blitzrage | I find too many segfaults |
| 20:04.45 | blitzrage | I gotta run though -- need to catch a train in 40 mins |
| 20:05.51 | Corydon76-vcch | blitzrage: run faster |
| 20:06.06 | blitzrage | I just got back from running for 20 mins :) |
| 20:06.09 | blitzrage | back later tonight! |
| 20:06.13 | Corydon76-vcch | blitzrage: what are you going to do to it once you catch it? |
| 20:06.31 | blitzrage | make it my bitch |
| 20:06.36 | jmls | eat it |
| 20:12.48 | Corydon76-vcch | The opening scene from 'Music Man' comes to mind |
| 20:12.57 | De_Mon | codefreeze all my pcs (linux, xp, vista) say the same time, and the old dst rules would have kicked in a few days ago |
| 20:13.06 | De_Mon | 1:00 is wrong :) |
| 20:20.47 | putnopvut | Corydon76-vcch: I was wondering if you had been working on 11071 (no audio on agentcallback channels), because if not, I was going to do some work on it myself. |
| 20:21.42 | Corydon76-vcch | go for it |
| 20:21.52 | putnopvut | All right. Thanks. |
| 20:27.21 | bweschke | file: ping |
| 20:28.54 | file | bweschke: pong |
| 20:29.47 | bweschke | hey - school me about audiohooks-1.4 branch.. I saw some discussion about it on the list.. is it "experimental" ? is it expected to cure all that there is to cure with current imlementation of spies in 1.4? |
| 20:30.16 | file | *hopefully* |
| 20:30.41 | Qwell | so, if it does, are we going to replace chanspy? |
| 20:30.42 | bweschke | is the intent for it to get merged into 1.4 as was with the ast2obj move ? |
| 20:30.45 | Qwell | does work, that is |
| 20:30.51 | file | it if it does fix the issues, then yes |
| 20:30.54 | Qwell | sweet |
| 20:31.23 | bweschke | k - so.. for the time being then - if I open a new branch to try to start porting the polycom acd stuff again with 1.4, I should do it based on the straight up 1.4 branch ? |
| 20:31.29 | file | yes |
| 20:31.38 | bweschke | schweet. thx.. that's what I needed to know |
| 20:44.43 | *** part/#asterisk-dev lirakis (n=eric@65.200.191.253) |
| 20:50.25 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 20:50.25 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 21:39.50 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177581830.dsl.bell.ca) |
| 22:03.20 | *** join/#asterisk-dev wwalker (n=wwalker@pdpc/supporter/sustaining/wwalker) |
| 22:03.25 | Damin | You don't have permission to access /digium-switchvox-free_8634.iso on this server. |
| 22:04.07 | Damin | Server is dl1.digium.com/digium-switchvox-free_8634.iso |
| 22:04.54 | *** join/#asterisk-dev moy (n=moyhu@189.169.50.222) |
| 22:06.22 | wwalker | meetme write temp recordings (your name for entry and exit announcements) into /var/spool/asterisk/meetme by default. I agree with that. If you record the actual conference, it stores it directly in /var/lib/asterisk/. I think it should go under /var/spool/asterisk/somewhere. Before I go write a patch and stuff, does anyone |
| 22:06.41 | wwalker | know of a reason for it to not default to /var/spool instead of /var/lib? |
| 22:09.26 | ManxPower | wwalker: /etc/asterisk/asterisk.conf or compile flags |
| 22:11.50 | wwalker | that would be to move astdatadir. I don't want to break everything in asterisk, I just want the recordings to not mix themselves with the sound files. |
| 22:12.57 | wwalker | s#/var/lib/asterisk/#/var/lib/asterisk/sounds/# |
| 22:14.52 | ManxPower | wwalker: uh, why not just specify the full filename? |
| 22:15.47 | Corydon76-vcch | wwalker: or make a subdirectory called custom, into which you place all your custom sounds |
| 22:16.19 | mvanbaak | Qwell: oops |
| 22:16.23 | Qwell | ? |
| 22:16.28 | mvanbaak | you copied the props as well |
| 22:16.32 | Qwell | d'oh |
| 22:16.49 | Qwell | and, there go all the automerge conflict emails |
| 22:17.02 | mvanbaak | yay ! |
| 22:18.45 | wwalker | ManxPower: because then asterisk isn't assigning the room number and user number in the file name |
| 22:19.32 | wwalker | Corydon76-vcch: sure, but even then, asterisk won't put them there unless I provide the full filename from outside the meetme application |
| 22:20.17 | Corydon76-vcch | Don't need the full filename, just a name, relative to custom, i.e. custom/foo |
| 22:20.18 | wwalker | What I'd like is to either patch for MEETME_DATA_DIR or for MEETME_FILENAME_FORMAT |
| 22:20.28 | ManxPower | can't you just System(mv /wrong/path/to/file /right/path/to/file) after the meetme ends |
| 22:21.29 | wwalker | Corydon76-vcch: I'm talking about files that meetme creates during a call. meetme expects me to pass in a full file name at a point in the dialplan where I can't know what the file name is |
| 22:22.34 | wwalker | So what I'm hearing is there is no reason to not patch it. Just some work arounds that will work in certain situations but not mine. |
| 22:23.42 | ManxPower | Corydon76-vcch: he wants the user and room number encoded into the file name, which for some reason he can't do. |
| 22:24.35 | Corydon76-vcch | wwalker: I agree with ManxPower |
| 22:24.49 | Corydon76-vcch | wwalker: rename it afterwards, if you need to |
| 22:25.39 | Corydon76-vcch | wwalker: we like functionality, but when there's a perfectly good way to do something already, hardcoding a new method is bad, mmmkay? |
| 22:26.41 | wwalker | not a solution that works when 1. asterisk crashes (still happens alot when you are running more than 600 channels) 2. an external app shouldn't need to rename files after the fact, they should get created in the c9orrect location in the first place |
| 22:26.57 | Qwell | who defines "correct"? |
| 22:27.03 | Damin | Qwell: I do. |
| 22:27.12 | Damin | Qwell: And you sir, are incorrect! |
| 22:28.23 | kpfleming | Qwell: does this mean we can remove all the GNUTLS stuff from the configure script? |
| 22:28.31 | Qwell | good question |
| 22:29.05 | Corydon76-vcch | wwalker: maybe you should look into why it's crashing, then |
| 22:29.25 | Qwell | there are still some #ifdef HAVE_GNUTLS lines in gtalk/jingle.. let me look at those |
| 22:29.50 | Corydon76-vcch | It's kind of silly to say that it MUST do something, and overlook the crashes |
| 22:30.37 | wwalker | When it crashes once a month, only under heavy load, very hard to locate the crash problem. |
| 22:31.22 | Qwell | kpfleming: Still uses GCRY_THREAD_OPTION_PTHREAD_IMPL and gcry_control. |
| 22:31.25 | mvanbaak | wwalker: make sure you run asterisk compiled with dont_optimize and grab a coredump once it dies |
| 22:31.31 | Qwell | will try to figure out why |
| 22:32.12 | kpfleming | i bet those are not needed any more, they are probably just used to configure the GNUTLS library |
| 22:32.33 | mvanbaak | I think so too |
| 22:34.09 | Qwell | it's lib init stuff, yeah |
| 22:40.37 | Damin | Anyone know if you need ZAPTEL_WATCHGUARD enabled to collect irc misses? |
| 22:40.41 | Damin | Er.. irq misses? |
| 22:41.37 | De_Mon | I was sitting there wondering how zaptel and irc worked |
| 22:41.46 | De_Mon | till I noticed your correction |
| 22:43.10 | Damin | De-Mon: Didn't you hear? Lumenvox and Sphinx can be teamed up to create chan_irc |
| 22:44.40 | mvanbaak | chan_irc would be cool though |
| 22:44.54 | mvanbaak | asterisk: enable voicemail |
| 22:45.02 | mvanbaak | asterisk: disable voicemail |
| 22:45.05 | mvanbaak | stuff like that |
| 23:04.23 | De_Mon | meh |
| 23:07.12 | mvanbaak | asterisk: originate ....... |
| 23:26.14 | Qwell | SO, that ALSO means we can eventually move away from iksemel |
| 23:26.27 | Qwell | I should look into that |
| 23:43.31 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:43.31 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:50.03 | mvanbaak | zzzzzzzzzzzzzzzzzzzzz time |
| 23:50.05 | mvanbaak | latero |
| 23:50.10 | putnopvut | Good night. |
| 23:51.36 | MasterYoda | for those that were curious, my pbx_lua code is now on the bug tracker as bug 0011140 (http://bugs.digium.com/view.php?id=11140) |
| 23:53.00 | *** part/#asterisk-dev zerohalo (n=zeroHalo@pool-71-255-162-167.bstnma.east.verizon.net) |
| 23:53.11 | lvl`home | does anyone know if i can check wether asterisk was properly compiled with the DONT_OPTIMIZE flag? |
| 23:56.30 | mvanbaak | MasterYoda: you are using git ? |
| 23:57.23 | mvanbaak | oh wait, I was going to bed ;) |
| 23:58.15 | *** part/#asterisk-dev jmls (n=jmls@62.49.235.130) |
| 23:59.12 | MasterYoda | mvanbaak: monotone |
| 23:59.17 | mog | MasterYoda, |
| 23:59.26 | mog | WAAAH WAAAH |
| 23:59.26 | MasterYoda | mog, |
| 23:59.31 | mog | your computer still make that noise |
| 23:59.35 | MasterYoda | YAAAAY YAAAAY |
| 23:59.45 | MasterYoda | that's the noise it makes |
| 23:59.48 | mog | heh |
| 23:59.57 | mog | you should switch to git |
