| 01:15.57 | *** join/#asterisk-dev xpot-mobile (n=james@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 01:23.47 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 01:25.13 | *** join/#asterisk-dev vousb (n=irc@zeroday.stashed.org) |
| 01:34.14 | *** join/#asterisk-dev xbp (n=irc@tollfraud.siphack.com) |
| 02:13.29 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 02:21.26 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 03:35.33 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 05:09.56 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 05:14.29 | *** join/#asterisk-dev Dovid (n=annon@72-59-251-15.pools.spcsdns.net) |
| 05:19.48 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 05:27.38 | *** join/#asterisk-dev work|philipp64 (n=chatzill@mail.redfish-solutions.com) |
| 05:28.08 | work|philipp64 | Corydon76-dig: Got the sounds patch working for caching... https://issues.asterisk.org/view.php?id=15370 |
| 05:45.04 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.217) |
| 06:49.59 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:49.59 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:58.07 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:09.29 | *** join/#asterisk-dev WeazelON (n=deazel@mail2.tikalnetworks.com) |
| 07:13.02 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:49.33 | *** join/#asterisk-dev DarkRift (n=dark@65.92.171.252) |
| 08:11.57 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 08:11.57 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 09:17.44 | *** join/#asterisk-dev crazybyte (n=crzp@unaffiliated/crazypenguin/x-000001) |
| 10:23.41 | *** join/#asterisk-dev crazybyte (n=crzp@unaffiliated/crazypenguin/x-000001) |
| 10:52.46 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 10:57.49 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 11:01.08 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:06.15 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:06.15 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:31.25 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 11:39.44 | *** join/#asterisk-dev ctooley (n=ctooley@12.230.123.195) |
| 11:39.44 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 11:56.29 | *** join/#asterisk-dev festr_ (n=festr@ns.hiro.cz) |
| 12:00.41 | festr_ | hi. SVN-branch-1.4-r197562 problem: SIP softphone INVITEs asteirsk and asterisk sends back two 407 (because the first is unreplied). Soft client sends back ACK to the retransmitted INVITE but 491 Request Pending |
| 12:00.48 | festr_ | is sended from asterisk |
| 12:01.13 | festr_ | hope that I've explained it cleanly |
| 12:02.26 | snuff-home | festr_: it may be explained clearly.. but ppl that might look at it require more.. and they aren't in yet :) |
| 12:02.36 | snuff-home | festr_: best thing to do is the following. |
| 12:02.48 | snuff-home | post a bug on issues.asterisk.org |
| 12:03.03 | snuff-home | make sure you include a sip debug log |
| 12:03.26 | snuff-home | to give the devs a better idea as to why it might be the case |
| 12:03.35 | jsmith | festr_: Not only that, but if your question doesn't involve the Asterisk source code, it's probably a better question for #asterisk |
| 12:03.53 | snuff-home | ello jsmith :) |
| 12:04.06 | jsmith | Hello snuff-home |
| 12:06.32 | festr_ | ok thanks. sometimes it is faster to discuss these things on irc before duplicating some another bugs (which I could miss after searches) |
| 12:06.44 | snuff-home | how goes things with the trainin? |
| 12:08.07 | jsmith | festr_: Then ask in #asterisk-bugs |
| 12:08.12 | jsmith | snuff-home: Keeping busy |
| 12:09.50 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:09.50 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:10.36 | snuff-home | its the canadian :) |
| 12:10.48 | mvanbaak | quick, HIDE ! |
| 12:12.10 | snuff-home | mm i started on my 'remove excess headers'.. but not sure how deep to go.. atm i'm only going 1 lvl deep.. |
| 12:18.59 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:18.59 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:19.24 | jsmith | Morning eliel |
| 12:19.47 | eliel | good morning! |
| 12:21.46 | tzafrir_laptop | I'm having issues with echo software cancellation in dahdi and asterisk 1.4 (haven't yet had time to test asterisk 1.6 with the changes in the buffering policy) |
| 12:22.23 | tzafrir_laptop | this seems to be a regression with respect to zaptel |
| 12:22.51 | festr_ | tzafrir_laptop: which EC? |
| 12:22.54 | tzafrir_laptop | It is mostly noticable with oslec running is 256 samples |
| 12:23.03 | festr_ | you answered :) |
| 12:23.18 | festr_ | i'm going to switch to dahdi. good to know :) |
| 12:23.40 | tzafrir_laptop | I re-added the sampling code to oslec to get better data for David Rowe. |
| 12:24.02 | leifmadsen | jsmith: morn! |
| 12:24.03 | tzafrir_laptop | He pointed out that the inputs to the EC were a bit jittery |
| 12:24.59 | tzafrir_laptop | I'm trying to figure out what might cause the extra jitter in dahdi |
| 12:24.59 | jsmith | leifmadsen: Morning |
| 12:27.15 | snuff-home | eliel: i have that info |
| 12:27.56 | eliel | snuff-home: morning (or night for you) |
| 12:28.05 | eliel | snuff-home: what info? |
| 12:28.55 | snuff-home | http://pastebin.ca/1469801 |
| 12:29.48 | snuff-home | that help? remind u? |
| 12:31.36 | eliel | snuff-home: oooh, i remember now! |
| 12:33.49 | snuff-home | yer i dont know why it shouldn't work.. |
| 12:34.06 | eliel | hmmm |
| 12:34.32 | eliel | i think the problem is with glob() |
| 12:34.45 | eliel | it is not expanding the directories |
| 12:35.31 | eliel | maybe the glob parameters being passed are not suitable for solaris... |
| 12:36.17 | snuff-home | mm maybe.. |
| 12:36.37 | snuff-home | its system call yer? |
| 12:39.12 | eliel | an usage example of glob(7) in solaris could be helpful |
| 12:42.02 | tzafrir_laptop | Oh, and it might be interesting to look for 'Mark all buffers as empty' in the code of llatest version of zaptel from svn |
| 12:42.27 | snuff-home | http://docs.sun.com/app/docs/doc/802-1930-03/6i5u95tpl?l=en&a=view&q=glob |
| 12:42.30 | snuff-home | that help? |
| 12:43.14 | tzafrir_laptop | eliel, glob as used where? |
| 12:43.31 | tzafrir_laptop | in the xml docs? |
| 12:43.42 | eliel | tzafrir_laptop: yes |
| 12:43.44 | tzafrir_laptop | the usage of the non-standard { |
| 12:44.56 | eliel | tzafrir_laptop: there is something non-standard in the way i am using it?? |
| 12:46.53 | tzafrir_laptop | we use two non-standard flags and avoid using both of them if even one of them is not supported |
| 12:48.05 | eliel | which flags? |
| 12:48.25 | tzafrir_laptop | Those two are GLOB_BRACE and GLOB_NOMAGIC . My glob(3) man page lists them as GNU extensions |
| 12:50.46 | tzafrir_laptop | hmm... my mistake. That's just config.c's logic |
| 12:51.00 | tzafrir_laptop | MY_GLOB_FLAGS |
| 12:51.51 | snuff-home | tzafrir_laptop: technically solaris manual agrees with ur initial assesment |
| 12:52.57 | eliel | snuff-home: can you pastebin you autoconfig.h? |
| 12:53.25 | snuff-home | uhm not right now.. though maybe.. gimme 5 |
| 12:53.29 | snuff-home | vpn into work |
| 12:54.41 | eliel | snuff-home: thanks |
| 12:55.40 | snuff-home | mm this is goin to suck when i get back to work.. 2 screens of 1400x1200 onto 1024x768 |
| 12:59.00 | snuff-home | http://www.opengroup.org/onlinepubs/007908799/xsh/glob.html |
| 12:59.24 | snuff-home | thats the list the POSIX standard for glob |
| 12:59.42 | *** join/#asterisk-dev caio1982_ (i=caio1982@CAcert-br/caio1982) |
| 13:01.18 | snuff-home | grr.. lost my connection to work laptop :( |
| 13:01.23 | snuff-home | i was almost there |
| 13:03.01 | snuff-home | wow.. managed to reset my pc instead |
| 13:10.19 | snuff-home | ok eliel i can just 'read off' |
| 13:11.11 | snuff-home | have_glob = 1.. listed in comments.. have_glob_nobrace / have_glob_nomagic / have_glob_nomagic_version |
| 13:12.15 | eliel | HAVE_GLOB_BRACE is setted? |
| 13:12.30 | snuff-home | nope.. all others than GLOB are undef |
| 13:12.49 | snuff-home | HAVE_GLOB |
| 13:14.51 | tzafrir_laptop | you could use a second call with GLOB_APPEND |
| 13:15.21 | eliel | yes, i will try using that |
| 13:15.40 | snuff-home | http://pastebin.ca/1469835 |
| 13:15.41 | tzafrir_laptop | wonders if that one is optional in uclibc... |
| 13:16.01 | snuff-home | is the proper post.. after going through 3 layers of cut n paste :) |
| 13:17.27 | snuff-home | well i am off to bed v shortly.. |
| 13:19.22 | snuff-home | k i'm outta here.. will help test tomorrow if required |
| 13:25.55 | eliel | snuff-home: thanks!!!! |
| 13:41.02 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:41.02 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:54.51 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 13:54.51 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 14:22.27 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 14:34.59 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:34.59 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:39.17 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:39.17 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:52.18 | *** join/#asterisk-dev comradeb14ck (n=comradeb@72.37.252.50) |
| 14:52.28 | *** join/#asterisk-dev moy (n=moy@74.12.123.90) |
| 14:54.02 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:54.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:07.45 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 15:10.41 | seanbright | russellb: ping |
| 15:11.40 | russellb | seanbright: pong (with 5 minute delay request) |
| 15:12.22 | seanbright | i don't see the problem in cel_sqlite3_custom |
| 15:12.29 | seanbright | re: reload wonkiness. |
| 15:13.12 | seanbright | hmmm, though it is being used outside of a locked section. |
| 15:14.06 | russellb | yes, 2 problems. it is being used outside of the lock. also, the locking in a reload is kind of wonky |
| 15:14.12 | russellb | lock / free it / unlock |
| 15:14.16 | russellb | then lock / reload config / unlock |
| 15:14.28 | russellb | so even if you locked around usage, it could be NULL, and go boom |
| 15:15.34 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 15:16.10 | seanbright | ahhh. i see |
| 15:16.21 | russellb | so, those 2 problems exist in both the cdr and cel modules |
| 15:17.11 | seanbright | yeah. |
| 15:17.38 | seanbright | is passing a flag to free_config that indicates whether it should do it's own locking sufficient? |
| 15:17.51 | seanbright | and then just wrap everything in load_config in the lock? |
| 15:18.40 | russellb | i think locking should be taken out of free_config() completely |
| 15:18.43 | russellb | when is it needed? |
| 15:18.48 | russellb | or rather, when else is it used? |
| 15:19.31 | seanbright | well, it's basically the all-purpose-module-cleanup function |
| 15:19.48 | seanbright | if (failed_for_any_reason) free_config(); |
| 15:21.07 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 15:21.18 | russellb | every use of it needs to be inside the lock, except for in unload_module |
| 15:21.33 | russellb | where it should only be called when it is no longer possible for a callback to be executing that uses it |
| 15:21.41 | russellb | (after the unsubscribe) |
| 15:21.55 | russellb | as opposed to where it is now, which makes it possible to explode on unload |
| 15:22.39 | seanbright | alrighty. |
| 15:22.44 | seanbright | will take a stab at it. |
| 15:23.05 | seanbright | failure is a strong possibility. |
| 15:23.06 | seanbright | :) |
| 15:23.07 | russellb | awesome :-) |
| 15:24.24 | jameswf | In the words of my father... I am not afraid of failure... he is my son after all |
| 15:24.44 | jameswf | has dahdi issues |
| 15:26.27 | russellb | there are some more bugs in load_module ... |
| 15:26.34 | russellb | 2 places where it fails to unsubscribe in error handling blocks |
| 15:27.27 | seanbright | man |
| 15:27.41 | seanbright | who re-wrote this cdr module this way |
| 15:27.42 | seanbright | ? |
| 15:27.44 | seanbright | svn logs... |
| 15:27.51 | seanbright | oh. it was seanbright. what a douche. |
| 15:27.55 | seanbright | heh |
| 15:34.00 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:38.33 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:50.50 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 16:08.26 | russellb | seanbright: mnicholson ... ping |
| 16:08.39 | russellb | let's sync up on the cel todo list |
| 16:09.00 | russellb | so, seanbright is working on fixing the sqlite3 bug with reloads that i pointed out ... |
| 16:09.12 | russellb | mnicholson: what's left on your todo list? |
| 16:09.25 | russellb | cleaning up dummy channel usage around the tree to not report false CEL events |
| 16:09.34 | mnicholson | russellb, yup |
| 16:09.42 | mnicholson | russellb, that's the only thing right now |
| 16:09.48 | russellb | okay, cool |
| 16:09.49 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 16:10.13 | russellb | seanbright also had some documentation related items he wanted to do |
| 16:10.32 | seanbright | wanted to standardize the table layouts for the various DB backends |
| 16:10.32 | russellb | seanbright: maybe we can split up that task? |
| 16:10.45 | seanbright | document the create statments properly and such |
| 16:10.55 | russellb | documentation is good |
| 16:10.57 | seanbright | and maybe standardize the configuration file |
| 16:11.00 | seanbright | files* |
| 16:11.07 | russellb | speaking of documentation ... it would be nice to have a CEL chapter in doc/tex ... |
| 16:11.18 | seanbright | where is leif when you need him? :P |
| 16:11.24 | russellb | as for the config files, i'd like to stick everything in cel.conf unless there is a good reason not to |
| 16:11.34 | russellb | for example, cel_manager had a config file for a single config option, enable |
| 16:11.54 | seanbright | right. the only place that might be strange is with cel_adaptive_odbc |
| 16:12.04 | russellb | if it seems justified, i'm okay with it |
| 16:12.11 | russellb | just not for 1 config option :-) |
| 16:12.16 | seanbright | i personally like the single conf file option |
| 16:12.23 | seanbright | makes it easier to manage. |
| 16:12.33 | russellb | a little bit less future proof |
| 16:12.41 | russellb | like, if you end up wanting to add 100 new options to cel_manager ... |
| 16:12.46 | seanbright | true. |
| 16:12.49 | russellb | you only have 1 section for it in cel.conf |
| 16:12.56 | seanbright | well at minimum, i'd like to standardize the options |
| 16:12.57 | russellb | shrugs |
| 16:13.02 | russellb | nods |
| 16:13.11 | seanbright | like hostname vs. server |
| 16:13.18 | seanbright | though i'm not sure those are there |
| 16:13.19 | seanbright | heh |
| 16:13.35 | russellb | i understand the point |
| 16:14.59 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 16:15.07 | seanbright | ok, so celdriver.tex is going to need lots of love |
| 16:15.11 | seanbright | i can handle that bit. |
| 16:15.26 | russellb | is that file there already? |
| 16:15.38 | mnicholson | re: db backends, I think we should also standardize on the column types and make sure each DB backed is writing the correct type |
| 16:16.03 | mnicholson | numbers where numbers should be, dates where dates should be, text where text should be |
| 16:16.13 | russellb | I'd like to have this wrapped up by the end of the week. Seem like a reasonable goal? |
| 16:16.29 | seanbright | yeah, it's there. |
| 16:16.37 | mnicholson | russellb, end of the week sounds reasonable |
| 16:16.42 | seanbright | nods |
| 16:16.42 | russellb | xlnt. |
| 16:16.44 | russellb | seanbright: i don't see it! |
| 16:16.54 | seanbright | doc/celdriver.tex |
| 16:16.56 | russellb | oh, it's in doc, not doc/tex |
| 16:16.56 | seanbright | i see it |
| 16:17.01 | russellb | location fail |
| 16:17.13 | seanbright | `find` ftw. |
| 16:17.45 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 16:17.47 | seanbright | best typo ever from today: |
| 16:17.49 | seanbright | poopd |
| 16:17.58 | seanbright | (meant to do popd) |
| 16:18.54 | russellb | nice. |
| 16:20.33 | jameswf | I wonder if it would be overly geeky to implement a gphoto2 functions in to an asterisk module... dialplan s,1,Connect_camera() s,n,take_photo() |
| 16:20.55 | russellb | does it need to be an Asterisk module? |
| 16:21.07 | russellb | System() and AGI() are probably sufficient to use existing stuff |
| 16:21.20 | seanbright | just write an AIS agent |
| 16:21.27 | seanbright | for the camera |
| 16:21.31 | jameswf | well I wanna learn to write modules and what better way than to do something totally useless |
| 16:21.39 | russellb | heh |
| 16:21.57 | jameswf | I refer you to res_monkeys cric. 2008 |
| 16:22.04 | jameswf | :) |
| 16:22.10 | russellb | <3 |
| 16:22.24 | russellb | i think i removed that branch .... |
| 16:23.37 | jameswf | it was either tie the wiimote to asterisk or tie my SLR to asterisk and the camera probably more usefull than my wiimote.. |
| 16:23.50 | russellb | :-) |
| 16:24.18 | jameswf | though I did invision a paging system via wiimotes but it would be limited by bluetooth range |
| 16:24.20 | russellb | i think it would be neat to add a DBUS API to chan_console ... |
| 16:24.22 | seanbright | russellb: didn't you write a 3 parter blog entry about writing asterisk modules? |
| 16:24.39 | russellb | to have a nice IPC mechanism for using Asterisk as a desktop softphone backend |
| 16:24.47 | russellb | seanbright: yeah. |
| 16:24.51 | jameswf | read said blog to generate base template :) |
| 16:24.58 | russellb | neat |
| 16:25.14 | seanbright | ahh |
| 16:25.17 | denon | jameswf: you could rig the wiimote to asterisk, and use it to remotely abuse stupid users.. |
| 16:25.24 | russellb | may have just come up with his next free time project |
| 16:25.32 | denon | just need to rig it up to another interface on the other end .. perhaps an electrified earpiece |
| 16:25.47 | file | russellb: a robot that will unpack boxes! brilliant! |
| 16:25.51 | russellb | file: i wish |
| 16:26.17 | jameswf | file: do the box contents need to be in working order after the unpack? |
| 16:26.29 | file | jameswf: yes! that is a requirement/ |
| 16:26.45 | jameswf | puts away water canon |
| 16:28.13 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:35.42 | tzafrir_laptop | jameswf, maybe go for something more generic: a SANE channel driver |
| 16:35.56 | tzafrir_laptop | I don't think one exists ATM |
| 16:36.02 | russellb | troll! :-p |
| 16:44.25 | mnicholson | seanbright, both cel_sqlite3_custom and cdr_sqlite3_custom want to use the same file to do logging |
| 16:45.00 | seanbright | mnicholson: ahh. that is problematic. i am about to commit an unrelated fix to cel_sqlite3_custom and will change it during commit |
| 16:45.25 | seanbright | or i guess we could make it a configuration option |
| 16:47.07 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:47.07 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:47.28 | mnicholson | seanbright, actually is this even a problem at all? it seemed to cause locking issues. |
| 16:48.47 | russellb | AFAIK, it should work fine |
| 16:48.52 | seanbright | well |
| 16:48.55 | russellb | it's just more contention for the same db file |
| 16:49.24 | seanbright | the current method of "if it don't work try it a couple more times" is a little crappy |
| 16:49.34 | seanbright | that's a technical term |
| 16:49.41 | seanbright | it's trivial to add a configuration option |
| 16:49.55 | mnicholson | seanbright, ok, so the error messages when it fails to get a lock are mostly harmless |
| 16:50.14 | russellb | is there not a way to do a blocking exec() ? |
| 16:50.54 | seanbright | i don't want to do that |
| 16:51.14 | seanbright | if the cdr is on the losing end of that, the channel won't die |
| 16:51.31 | russellb | well it shouldn't block forever ... |
| 16:51.33 | russellb | unless something gets hosed |
| 16:51.59 | seanbright | meh... |
| 16:52.05 | russellb | ok :-) |
| 16:52.08 | seanbright | heh |
| 16:52.26 | seanbright | will look at it |
| 16:52.54 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 16:53.48 | seanbright | When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions. |
| 16:54.07 | seanbright | the whole "by another process" is the question mark |
| 16:54.18 | russellb | process/thread presumably |
| 16:54.19 | putnopvut | Someone just said my name in here... |
| 16:54.23 | putnopvut | oh, "question mark" |
| 16:54.39 | seanbright | heh |
| 16:54.45 | russellb | also, who knows what other processes people will have reading the db |
| 16:54.57 | seanbright | well reading wouldn't be a problem |
| 16:55.09 | seanbright | err |
| 16:55.11 | seanbright | right. |
| 16:55.19 | seanbright | heh... |
| 16:56.00 | russellb | lunch! |
| 16:56.04 | seanbright | Is SQLite threadsafe? |
| 16:56.11 | seanbright | "Threads are evil. Avoid them." |
| 16:56.20 | russellb | yes |
| 16:56.52 | russellb | actually i made that up, you should probably check |
| 16:56.56 | russellb | but I think so :-) |
| 17:00.49 | mnicholson | should someone be worried about this: http://pastebin.com/m5de50f4f |
| 17:01.26 | putnopvut | mnicholson: that's a "bad thing" |
| 17:05.08 | mnicholson | putnopvut, i think i found the problem |
| 17:05.32 | mnicholson | its possible for that function to return without unlocking the lock |
| 17:15.32 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 17:17.51 | *** join/#asterisk-dev outtolunc (n=me@adsl-76-242-26-21.dsl.pltn13.sbcglobal.net) |
| 17:26.55 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 17:30.22 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 17:34.19 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:47.56 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:47.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:54.26 | jsmith | Oooh, I think I found a problem with Asterisk's pattern matching |
| 17:54.38 | jsmith | Somebody wanna do a sanity check for me? |
| 17:55.52 | jsmith | [pattern-test] |
| 17:55.52 | jsmith | exten => _1XX,1,NoOp(Option 1) |
| 17:55.52 | jsmith | exten => _1[2-4]X,1,NoOp(Option 2) |
| 17:55.52 | jsmith | exten => _1NX,1,NoOp(Option 3) |
| 17:55.52 | jsmith | exten => _1[246]X,1,NoOp(Option 4) |
| 17:56.05 | jsmith | Add that to your dialplan, set your verbosity to 2 or lower, then issue a "dialplan reload" |
| 17:56.23 | jsmith | Notice the warning, then type "dialplan show pattern-test" |
| 17:56.34 | jsmith | Notice how that last extension (option 4) doesn't get loaded? |
| 18:00.06 | tzafrir_laptop | option 2 alone is enough to give this warning |
| 18:03.40 | work|philipp64 | Corydon76-dig: ping? |
| 18:04.24 | *** join/#asterisk-dev wierdo (n=jimmy@wifi-traf5.networx-bg.com) |
| 18:04.35 | work|philipp64 | seanbright: ping? |
| 18:05.58 | jsmith | tzafrir_laptop: Why would option 2 give the warning? |
| 18:06.40 | tzafrir_laptop | why is the good question. but you can rem-out 1 and 3 and repeat |
| 18:07.03 | jsmith | Sure... but what's throwing the WARNING is option 4, when it shouldn't |
| 18:07.20 | jsmith | The problem is that the Asterisk parser thinks option 4 is the same as option 2, when it's obviously not |
| 18:09.11 | work|philipp64 | but option 4 is partially obscured by option 2... |
| 18:10.09 | tzafrir_laptop | haveing [24] in option 2 and [26] in option 4 is also good enough |
| 18:10.19 | work|philipp64 | that being the case, though, so it option 3. |
| 18:10.19 | tzafrir_laptop | but the number has to be the same |
| 18:10.23 | work|philipp64 | hmm... |
| 18:10.39 | tzafrir_laptop | [234] and [24] are not "equal" |
| 18:12.20 | work|philipp64 | no, but they do overlap. |
| 18:12.22 | work|philipp64 | if the parser is trying to build a DFA, then it will hit an ambiguity... the same symbols (2 and 4) will generate more than one arc away from the same state node. |
| 18:12.22 | *** join/#asterisk-dev ehsjoar (n=ehsjoar@c-24-9-91-203.hsd1.co.comcast.net) |
| 18:12.37 | work|philipp64 | which wouldn't be a problem except both paths lead to terminal states... and hence conflict. |
| 18:13.14 | work|philipp64 | sigh... wish I could find someone to code review https://issues.asterisk.org/view.php?id=15370 for me... |
| 18:15.50 | *** join/#asterisk-dev xpot-mobile (n=james@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 18:17.25 | tzafrir_laptop | work|philipp64, why do you run 'dist-clean' if you don't want that effect? use 'make clean' |
| 18:20.03 | work|philipp64 | well, it's more complicated than that... |
| 18:20.43 | work|philipp64 | in our case, we have to zap everything down to nothingness.... it's a characteristic of how "buildroot" is set up. |
| 18:21.22 | work|philipp64 | so we actually do an "rm -rf build_$(ARCH)" each time... and dispense with having to call "make clean" on 300+ packages. |
| 18:21.53 | work|philipp64 | (a lot of poorly done makefiles don't implement "make clean" or don't zap their "configure" files, etc.) |
| 18:22.30 | work|philipp64 | for some platforms, we even have to rebuild the toolchain (gcc, binutils, ld, etc.) between makes if we're changing processor types. |
| 18:23.00 | work|philipp64 | we build 8 different images for every SVN version bump. |
| 18:23.28 | tzafrir_laptop | work|philipp64, the bug is actually here that you have a source which is beyond your control |
| 18:23.46 | work|philipp64 | don't follow you. |
| 18:24.05 | tzafrir_laptop | do you download the asterisk tarball in the makefile? |
| 18:24.11 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 18:24.58 | work|philipp64 | sort of. we have a download directory called "dl/" in the project root, and if it's there, we just use that... if it's not, we WGET it into there and then use that. |
| 18:25.04 | tzafrir_laptop | in your build system, that is |
| 18:25.24 | work|philipp64 | the first build pulls down everything... subsequent builds reuse the cached files. |
| 18:25.32 | tzafrir_laptop | asterisk is a relatively large tarball as well. on the order of magnitude of the sound files |
| 18:26.04 | tzafrir_laptop | you should just treat the asterisk sound files as a eparate package |
| 18:26.10 | tzafrir_laptop | download it separately |
| 18:26.36 | tzafrir_laptop | the ones you need, that is |
| 18:27.18 | work|philipp64 | see http://astlinux.svn.sourceforge.net/viewvc/astlinux/trunk/package/asterisk/asterisk.mk?view=markup |
| 18:28.07 | work|philipp64 | unfortunately that would be hard, because one package would have to query the other package to figure out what list of files it wants. |
| 18:28.32 | tzafrir_laptop | or treat the sound files as separate sources you download |
| 18:28.45 | work|philipp64 | lines 73-78... |
| 18:28.46 | tzafrir_laptop | your build system caches sources. |
| 18:28.51 | work|philipp64 | yup. |
| 18:29.12 | work|philipp64 | we use sha1sum's to tell if they've changed. sometimes version numbers lie. :-) |
| 18:31.30 | work|philipp64 | one nice thing about our system, though, is you can query it from scripts and makefiles to peer into its state... lines 236-252 of http://astlinux.svn.sourceforge.net/viewvc/astlinux/trunk/Makefile?view=markup |
| 18:32.36 | work|philipp64 | "make val.TARGET_CONFIGURE_OPTS" for instance gives me a whole lot of useful information. |
| 18:33.56 | tzafrir_laptop | and yet you trust the Asterisk Makefile to download the right files? |
| 18:35.17 | work|philipp64 | how do you mean? |
| 18:35.47 | tzafrir_laptop | <work|philipp64> we use sha1sum's to tell if they've changed. sometimes version numbers lie. :-) |
| 18:35.55 | work|philipp64 | it was already downloading the file previously... and it was supposedly doing the right thing. so what's not to trust? |
| 18:36.25 | work|philipp64 | ah... yeah... some projects are a little less rigorous than others. |
| 18:36.39 | work|philipp64 | Asterisk has been good about not tweaking published tarballs. |
| 18:37.05 | work|philipp64 | besides, sound files aren't super-critical. |
| 18:37.34 | tzafrir_laptop | famous last words |
| 18:38.54 | tzafrir_laptop | when someone replaces your standard greeting with tt-monkeys you'll start being more careful :-P |
| 18:39.04 | work|philipp64 | I'm wondering if it wouldn't have been better to have the rules just call a named script that did the work... and in the default case, the name pointed to a dumb wrapper for "wget" or whatever... then the developer could override the wrapper name and point it at something that did something more sophisticated with a look-aside cache, etc. |
| 18:39.10 | work|philipp64 | and sha1sum's, of course. :-) |
| 18:39.41 | work|philipp64 | gotta keep those monkeys and weasels in their place. |
| 18:40.19 | work|philipp64 | so... what do you think the chances are of the patch getting accepted? |
| 18:42.30 | *** join/#asterisk-dev outtolunc (n=me@adsl-76-242-26-21.dsl.pltn13.sbcglobal.net) |
| 18:42.35 | work|philipp64 | oh, that can't be good... :-( |
| 18:42.51 | seanbright | for 1.4? slim to none |
| 18:43.14 | seanbright | for trunk, pretty good, assuming it works on more than just linux. |
| 18:43.31 | seanbright | the bsds might be problematic if you use any whizbang gnu make features |
| 18:44.10 | work|philipp64 | seanbright: how so? I thought gmake was pretty portable. |
| 18:44.20 | work|philipp64 | what changes between linux and *bsd? |
| 18:44.26 | seanbright | older versions |
| 18:44.43 | work|philipp64 | what is going into 1.4 these days anyway? just security fixes? |
| 18:44.47 | tzafrir_laptop | work|philipp64, to save you some time writing that wrapper: http://updates.xorcom.com/astribank/bristuff/1.4/bristuff-current/download.sh |
| 18:44.54 | seanbright | no, bug & security fixes |
| 18:44.58 | seanbright | but it is feature frozen |
| 18:45.05 | seanbright | as are 1.6.0 and 1.6.1 |
| 18:46.42 | leifmadsen | seanbright: and 1.6.2 |
| 18:46.49 | leifmadsen | (but you knew that) |
| 18:46.58 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 18:47.03 | seanbright | oh right, yes. |
| 18:47.24 | work|philipp64 | tzafrir_laptop: the sounds are conspicuous in their absence. :-) |
| 18:48.00 | work|philipp64 | we can't move to 1.6 until we get eglibc working in place of uClibc. sigh. |
| 18:48.01 | tzafrir_laptop | this is a relic of 1.0 and 1.2 |
| 18:48.06 | work|philipp64 | not looking forward to that. |
| 18:48.35 | tzafrir_laptop | eglibc should be simpler, isn't it? glibc compatible |
| 18:48.42 | tzafrir_laptop | are there space issues? |
| 18:49.09 | work|philipp64 | yes, but ripping out uClibc, its required patches, and putting in eglibc instead will be no picnic. |
| 18:49.55 | tzafrir_laptop | Asterisk (on Debian) builds fine with eglibc. At least 1.6.1.0 |
| 18:50.35 | work|philipp64 | I'm not so much worried about the user-space stuff. it's the hardware drivers and low-level libraries that I'm worried about. |
| 18:57.09 | JunK-Y | some1 could explain me more the isdn code 102? http://networking.ringofsaturn.com/RemoteAccess/isdncausecodes.php is not really clear |
| 18:58.18 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 19:16.46 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:27.28 | *** join/#asterisk-dev alonzo (n=Miranda@79.111.163.192) |
| 19:37.36 | *** join/#asterisk-dev Greek-Boy (n=greek@41.222.89.77) |
| 19:54.49 | mnicholson | i am looking at acf_odbc_read and acf_odbc_write in func_odbc, and I am trying to understand the logic behind the creation of a bogus channel |
| 19:55.09 | mnicholson | is anyone familiar with that code? |
| 19:55.53 | mnicholson | it looks like the logic there is supposed to create a dummy channel to play with in the event that a channel is not passed to the function, although the logic appears to be faulty |
| 19:57.02 | russellb | only Tilghman probably ... |
| 19:58.22 | mnicholson | is he in today? |
| 20:00.04 | leifmadsen | he is out all week |
| 20:00.14 | leifmadsen | (vacation) |
| 20:00.52 | mnicholson | bah, ok |
| 20:01.44 | mnicholson | well, in general, are there any case where an asterisk dialplan function will be called with the chan parameter set to NULL? |
| 20:03.13 | Greek-Boy | mnicholson by logic are u referring to the algorithim? |
| 20:03.49 | mnicholson | Greek-Boy, i am referring to the login surrounding the creation of the dummy channel |
| 20:03.50 | Greek-Boy | mnicholson: the only reason why I ask because I am a newbie trying to learn programming. Lately I'm looking at code and trying to study it.. |
| 20:04.10 | Greek-Boy | mnicholson: ok |
| 20:06.20 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-0dc26bdfda3b5a9c) |
| 20:18.13 | putnopvut | mnicholson: I wonder if the "bogus_chan" argument is for when the function is called using something like setvar in a config file... |
| 20:18.41 | putnopvut | Not sure how acf_odbc_write would be used that way, but acf_odbc_read seems possible. |
| 20:19.37 | russellb | Action: SetVar from AMI |
| 20:20.33 | mnicholson | ok |
| 20:20.40 | putnopvut | mnicholson: I'd say that starting autoservice on a bogus channel seems weird imho. |
| 20:20.49 | russellb | pointless, in fact |
| 20:20.59 | mnicholson | putnopvut, russellb, indeed |
| 20:22.20 | putnopvut | in acf_odbc_write, anyway, it looks like the only thing that is done with the chan parameter is to pass it to pbx_builtin_setvar_helper and pbx_builtin_pushvar_helper. In either case, it really makes no sense to be setting vars on a bogus channel. |
| 20:22.52 | putnopvut | ah, I see now. |
| 20:22.58 | putnopvut | ast_str_substitute_variables. |
| 20:23.03 | putnopvut | I think that may require a channel. |
| 20:24.46 | mnicholson | I am going to clean some of this code up |
| 20:29.41 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 20:38.01 | seanbright | that's done in a lot of places, i believe |
| 20:38.09 | seanbright | a few of the CDR/CEL modules do it |
| 20:38.19 | jsmith | wonders whether or not to open a bug for his pattern-matching issue |
| 20:38.55 | seanbright | even though any value you get off of the channel (other than CDR(something)) will be completely bogus |
| 20:39.06 | seanbright | i.e. not for either channel being reported on in the CDR |
| 20:44.43 | seanbright | also... |
| 20:45.10 | seanbright | when using ast_dummy_channel_alloc() and associating a CDR with it, you need to ast_cdr_dup the cdr instead of assigning it directly |
| 20:45.50 | mnicholson | russellb, setvar requires a channel to given |
| 20:46.02 | seanbright | otherwise when ast_release_channel is called on the dummy channel, you are actually freeing the CDR associated with the original channel |
| 20:46.34 | mnicholson | russellb, nvm, it works without a channel |
| 20:47.09 | seanbright | is talking to himself |
| 20:47.35 | mnicholson | seanbright, :) |
| 20:52.27 | seanbright | ok, all of the CDR modules that use it are dup'ing in properly |
| 20:52.27 | seanbright | so nevermind! |
| 21:52.59 | russellb | reviewboard is going to be down for a few minutes while I upgrade to reviewboard 1.0 |
| 21:54.45 | seanbright | snazzy |
| 22:01.20 | russellb | done |
| 22:03.28 | leifmadsen | russellb: nice |
| 22:06.05 | Greek-Boy | in which source file is LOW_MEMORY defined? |
| 22:06.32 | russellb | it's referenced in a number of places |
| 22:06.51 | russellb | grep -r LOW_MEMORY * | grep -v svn |
| 22:13.29 | Greek-Boy | thanks |
| 22:44.46 | comradeb14ck | can someone explain to me why the AGI command get_full_variable always returns 200 result=1 <value> even if the variable you reference doesn't exist anywhere? |
| 22:44.59 | comradeb14ck | when it faills, the value is simply the variable name |
| 22:45.00 | seanbright | i feel like this was discussed recently |
| 22:45.08 | seanbright | either here or on the mailing lists |
| 22:45.23 | comradeb14ck | i'll google again D: |
| 22:45.47 | comradeb14ck | i should sign up for the mailing list |
| 22:47.12 | seanbright | 13:17 < b14ck> Hi all-- it seems to me as if the agi command GET FULL VARIABLE is bugged |
| 22:47.15 | seanbright | 13:17 < b14ck> has anyone else noticed this? even if you try to lookup a variable which doesn't exist, it returns result=1 |
| 22:47.18 | seanbright | 13:22 <@Corydon76-dig> b14ck: negatory |
| 22:47.19 | Qwell | There isn't a different between unset and empty |
| 22:47.21 | seanbright | 13:22 <@Corydon76-dig> b14ck: get full variable does a substitution routine. It always is successful unless the channel specified \ |
| 22:47.24 | seanbright | does not exist |
| 22:47.27 | seanbright | does that look familiar? |
| 22:47.49 | Qwell | seanbright: that was a different person |
| 22:47.51 | comradeb14ck | omg, i must be losing my marbles >< |
| 22:47.55 | seanbright | Qwell: no, it wasn't |
| 22:48.04 | Qwell | the nick is completely different! |
| 22:48.12 | Qwell | the last couple letters is just coincidence |
| 22:48.16 | seanbright | #asterisk-dev.06-19.log:21:22 < comradeb14ck> im going home now, but send me a pm if you need anything |
| 22:48.19 | seanbright | #asterisk-dev.06-19.log:21:22 < comradeb14ck> or pm b14ck (hes logged in on my home comp) |
| 22:49.06 | comradeb14ck | so it does a substitution routine? what does it substitute? |
| 22:49.07 | Qwell | hrm. bip log? |
| 22:49.31 | comradeb14ck | and sorry for repeating the question. i dont really remember asking that |
| 22:50.20 | seanbright | Qwell: egrep -r b14ck irclogs/FreeNode |
| 22:55.15 | *** part/#asterisk-dev ehsjoar (n=ehsjoar@c-24-9-91-203.hsd1.co.comcast.net) |
| 23:10.03 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:31.17 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 23:31.17 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:42.58 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |