| 19:31.14 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 19:31.14 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- http://www.xkcd.org/664/ |
| 19:33.47 | russellb | TheDavidFactor: done |
| 19:34.47 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:40.25 | atis_work | umm, what would be correct realtime requirement for int(10) unsigned? |
| 19:41.04 | atis_work | i'm trying ("cdr", "duration", RQ_UINTEGER4, 11, NULL) and it says it can't be integer |
| 19:41.16 | *** join/#asterisk-dev dwayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 19:41.19 | Corydon76-lap | RQ_INTEGER4 |
| 19:42.01 | Corydon76-lap | problem with a RQ_UINTEGER4 is that you need an INTEGER8 to get the highest values of an unsigned integer4 |
| 19:42.26 | atis_work | umm, why.. if i set length 10 and unsigned, it should fit |
| 19:43.01 | Corydon76-lap | length is only for character-based types |
| 19:43.33 | atis_work | res_config_mysql checks/uses them also for integers |
| 19:44.02 | atis_work | umm, now i get two warnings: column 'duration' may not be large enough for the required data length: 10 (detected stringtype) / column 'duration' cannot be type 'int(10) unsigned' (need char) |
| 19:44.07 | Corydon76-lap | If you're obsessed with making it unsigned, use RQ_UINTEGER3 |
| 19:44.45 | atis_work | ah, i had two requires |
| 19:45.10 | atis_work | well, i'm not obsessed but generally i like to use unsigned columns whenever value is not supposed to be negative |
| 19:45.23 | atis_work | that way you can fit twice as much data range |
| 19:45.25 | Corydon76-lap | Then specify your column type as unsigned |
| 19:45.55 | Corydon76-lap | If your requirement is unsigned and your column is signed, then you're missing the upper half of the range of the uint |
| 19:46.51 | Corydon76-lap | Same as if you specify signed and you use unsigned... you're missing the negative portion |
| 19:46.52 | atis_work | did you mean that it gets cut in realtime module? |
| 19:47.13 | atis_work | well, yeah, but for duration and billsec everybody should use unsigned |
| 19:47.29 | Corydon76-lap | Heh |
| 19:47.30 | atis_work | and if there's no table realtime module should create it unsigned |
| 19:47.47 | atis_work | is writing cdr_realtime |
| 19:48.12 | Corydon76-lap | Uh, best as I can remember, realtime doesn't create tables |
| 19:48.25 | atis_work | well, alter at least |
| 19:48.31 | atis_work | it could create in future :p |
| 19:48.48 | Corydon76-lap | why cdr_realtime, when you can use cdr_adaptive_odbc? |
| 19:49.08 | atis_work | why use odbc? i don't like additional software in my farm |
| 19:49.10 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 19:49.31 | atis_work | res_config_mysql is working great, and i just added master-switching support to it |
| 19:49.48 | Corydon76-lap | cdr_mysql also has adaptive support. :-P |
| 19:50.28 | atis_work | well, the idea is - why maintain separate modules for cdr_<dbengine> and res_config_<dbengine> |
| 19:50.47 | atis_work | it's basically the same |
| 19:50.57 | Corydon76-lap | Not with adaptive, it isn't |
| 19:51.18 | TheDavidFactor | russellb, thanks! |
| 19:51.36 | Corydon76-lap | res_config_* works with knowable columns. Cdr adaptive works with unknowable columns (at compile time) |
| 19:52.13 | atis_work | umm, well.. i guess that part could be moved to cdr_realtime |
| 19:52.24 | atis_work | i haven't yet gone that far |
| 19:52.52 | Corydon76-lap | Same basic technique, but two wildly different purposes |
| 19:53.47 | atis_work | well, i'm just looking the following way: i added master-switching to res_config_mysql, why should i copy the code to cdr_mysql |
| 19:54.01 | atis_work | and opposite: cdr_mysql has ssl support, but res_config_mysql doesn't |
| 19:54.21 | Corydon76-lap | Hence why you should use ODBC |
| 19:54.45 | atis_work | uff, that's another layer that could fail |
| 19:54.54 | Corydon76-lap | Feature set that has parity on both ends |
| 19:55.24 | Corydon76-lap | Uh, the fact that you think it's a layer that can fail suggests that you really don't understand the ODBC layer |
| 19:55.56 | Corydon76-lap | It's only a code-abstraction layer, not a runtime separate layer |
| 19:56.08 | atis_work | probably. i never used it, but i know that it sits in the middle between server and client, right? |
| 19:56.18 | Corydon76-lap | No, not really |
| 19:56.33 | atis_work | a lot of people don't understand, so they would like single place where to set up mysql/pgsql/etc |
| 19:56.46 | Corydon76-lap | It's a code abstraction layer. It's like saying that you refuse to use C++ because it's another layer that can fail |
| 19:57.38 | Corydon76-lap | It really can't. There aren't really any more layers there at runtime |
| 19:57.39 | atis_work | goes to wikipedia/odbc |
| 19:58.45 | *** join/#asterisk-dev correcaminos (n=laguilar@201.199.12.190) |
| 19:59.37 | Corydon76-lap | You can say the abstractions are braindead or useless, but you cannot say there's another layer to fail. There isn't. |
| 20:01.25 | Corydon76-lap | And given that you're using MySQL, you're going to run into TONS of library-related bugs in the implementation. That's not ODBC, just the MySQL client library |
| 20:01.45 | Corydon76-lap | If you want solid performance, you'd be using Postgres |
| 20:02.00 | atis_work | heh, thanks.. we're used to mysql :) |
| 20:02.13 | atis_work | it's great if you know how to use it :) |
| 20:02.59 | atis_work | and there's a person in the office who knows half of it's bugs, so he writes general client API's and we just use that |
| 20:03.43 | Corydon76-lap | I do know how to use it; I was a MySQL DBA at a previous job. MySQL isn't the problem; it's the crummy client library and how it acts in regard to persistent connections |
| 20:04.14 | Corydon76-lap | Or rather, the MySQL server isn't the problem, but persistent connections with the client library |
| 20:04.35 | atis_work | afaik we don't use persistent connections, somehow that's faster |
| 20:04.46 | atis_work | but i really can't tell you why |
| 20:05.19 | Corydon76-lap | Perl CGI? |
| 20:05.24 | Corydon76-lap | or AGI? |
| 20:05.37 | atis_work | uff, generally we use php\ |
| 20:05.57 | Corydon76-lap | Yeah, there's a much bigger problem when you use C with a persistent process |
| 20:06.22 | atis_work | and you say that odbc solves all of it? |
| 20:06.32 | Corydon76-lap | You'd be better off writing a cdr_agi that hooks into a separate process |
| 20:06.52 | Corydon76-lap | I didn't say odbc solves it; I said it's no worse using ODBC |
| 20:07.47 | atis_work | heh, i could do the same with cdr_realtime/res_config_curl :p |
| 20:07.58 | Corydon76-lap | Now if you're using Postgres, there's no problem whatsoever using ODBC, because the developers have been very careful in the past with thread-safety |
| 20:08.12 | atis_work | anyway i think there shouldn't be duplicated db libraries :) |
| 20:08.29 | Corydon76-lap | There aren't |
| 20:09.05 | Corydon76-lap | Both cdr_adaptive_odbc and res_config_odbc use the connection pooling in res_odbc |
| 20:09.41 | atis_work | ok, so the same should be done for mysql/pgsql |
| 20:10.13 | Corydon76-lap | Possibly, but that's work that hasn't been a priority |
| 20:10.40 | atis_work | ah, but you still need separate configs for cdr_adaptive_odbc/res_config_odbc? |
| 20:11.05 | Corydon76-lap | Uh, the config for res_config_odbc is extconfig.conf |
| 20:11.07 | atis_work | so, why not keep mysql connection information in res_mysql.conf only |
| 20:11.38 | Corydon76-lap | And all cdr_adaptive_odbc needs for a minimal configuration is a pointer to a cdr table |
| 20:12.17 | Corydon76-lap | It may be a good idea, but we have higher priorities right now |
| 20:12.35 | atis_work | well, i'm just writing cdr_realtime |
| 20:12.48 | atis_work | so it could have field/mappings and adaptive support in it |
| 20:12.49 | Corydon76-lap | Heh |
| 20:13.25 | Corydon76-lap | For someone who hates additional layers, that's quite a contortion. |
| 20:13.42 | atis_work | i'm not sure how to create adaptive support, but probably it could be added to res_config_mysql |
| 20:14.00 | atis_work | hehe, well that's well known and used module |
| 20:14.01 | Corydon76-lap | It's already there |
| 20:14.08 | atis_work | however odbc.. it has to be installed |
| 20:14.31 | atis_work | i'm not sure how it will work with master-switching |
| 20:19.25 | Corydon76-lap | Are you saying mysql doesn't need to be installed? |
| 20:19.31 | Corydon76-lap | or configured? |
| 20:19.55 | atis_work | heh, our sysadmin does that, and he said no for odbc :p |
| 20:20.27 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121-72-157-85.dsl.telstraclear.net) |
| 20:20.35 | atis_work | mysql is simple the same commands stay the same everywhere :) |
| 20:20.50 | atis_work | and everyone here knows them :) |
| 20:21.56 | atis_work | well, i've googled for odbc some 5 minutes and so far haven't found any simple manuals and descriptions |
| 20:22.09 | atis_work | it's just too full of unknown terms and words |
| 20:22.36 | Corydon76-lap | Heh. ODBC isn't a user layer. It's a programming abstraction layer. |
| 20:22.51 | Corydon76-lap | Please search for a simple guide to C++ for me and tell me how you do |
| 20:22.52 | atis_work | i.e. i have to find some driver, etc.. and there are tons of them. so which should i choose? |
| 20:23.06 | Corydon76-lap | UnixODBC/MyODBC |
| 20:41.31 | atis_work | ok, back to the ast_realtime_require_field |
| 20:42.06 | atis_work | i do RQ_UINTEGER3, 6 and still get error " cannot be type 'int(10) unsigned' (need char)" |
| 20:44.34 | *** join/#asterisk-dev nd- (n=nd-@xes-mad.com) [NETSPLIT VICTIM] |
| 20:44.34 | *** join/#asterisk-dev mohawk (n=ross@host217-40-110-153.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 20:44.34 | *** join/#asterisk-dev Amorsen (n=Amorsen@94.127.50.7) [NETSPLIT VICTIM] |
| 20:44.34 | *** join/#asterisk-dev Katty (n=asterisk@mail.copi-rite.com) [NETSPLIT VICTIM] |
| 20:49.53 | *** join/#asterisk-dev ticoit (n=ticoit@190.241.180.89) |
| 20:56.38 | *** join/#asterisk-dev correcaminos (n=laguilar@201.199.12.190) |
| 20:57.21 | *** join/#asterisk-dev alecdavis (n=alec@202.36.76.21) |
| 21:04.57 | alecdavis | Busydetect tripped by DTMF, now fixed, needs testing, mantis bug M16389. Conceptually simple fix, each time DTMF UP is detected, flush the historicsilence and historicnoise buffers, which are used by the busydetector. Just by pressing redial, managed to get unpatched system to incorrectly hangup! Was hard to trip it, but managed to do it. |
| 21:05.14 | DocAwesome | M16389 |
| 21:06.34 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 21:25.22 | *** join/#asterisk-dev puzzled_ (n=foobar@puzzled.xs4all.nl) |
| 21:33.21 | alecdavis | M16389 |
| 21:33.24 | MuffinMan | [acknowledged] [DAHDI-linux] dahdi (the module) 0016389: [patch] busydetect incorrectly hangs up incoming call due to incoming DTMF seen as busy pattern. reported by alecdavis (Karma: +80.50) https://issues.asterisk.org/view.php?id=16389 |
| 22:07.04 | *** join/#asterisk-dev xpot-mobile (n=xpot@173-14-232-121-Utah.hfc.comcastbusiness.net) |
| 22:34.29 | *** join/#asterisk-dev mpe (n=mpe@0x4dd624b2.adsl.cybercity.dk) |
| 22:57.06 | Qwell | Since when do we require prompts for language submissions? |
| 22:57.10 | Qwell | That seems silly, at best. |
| 22:58.41 | russellb | we do? |
| 22:58.46 | Qwell | apparently |
| 22:58.49 | russellb | link? |
| 22:58.52 | Qwell | M15053 |
| 22:58.53 | Qwell | see comments |
| 22:58.54 | MuffinMan | [ready for testing] [Asterisk] Applications/app_voicemail/NewFeature 0015053: [patch] Vietnamese support for Voicemail reported by dinhtrung (Karma: neutral) https://issues.asterisk.org/view.php?id=15053 |
| 22:59.14 | Corydon76-lap | Qwell: since people interpret given prompts differently, they then disagree on correct grammar |
| 22:59.27 | russellb | that's not the point |
| 22:59.33 | Qwell | Corydon76-lap: I mean *audio* of the scripts |
| 22:59.41 | russellb | We have requirements for if we accept prompts, we get all of them, etc |
| 22:59.50 | russellb | We do not require prompts to get the code in |
| 22:59.56 | Corydon76-lap | Qwell: that seems odd |
| 23:00.04 | Qwell | comment 114074, #2 |
| 23:00.11 | Corydon76-lap | We shouldn't require actual audio |
| 23:00.24 | russellb | I think he was just seeing if that was an option |
| 23:00.33 | russellb | since we do have a process for that, if they were willing |
| 23:00.34 | Qwell | Then he shouldn't have used the word "need" :D |
| 23:01.32 | Corydon76-lap | He may have misinterpreted the specified need |
| 23:02.14 | Qwell | I speak English natively (though that could be argued), and I also misinterpreted it, apparently |
| 23:02.38 | Corydon76-lap | I meant John, not the reporter |
| 23:02.42 | Qwell | oh |
| 23:03.48 | Qwell | mutters something about pronouns |
| 23:05.32 | Corydon76-lap | mutters something about native English speakers |
| 23:05.51 | Qwell | it's the en_US that gets me. |
| 23:06.03 | Qwell | If everybody spoke en_QWELL, things would be fine |
| 23:06.13 | Corydon76-lap | I prefer en_THEM |
| 23:06.46 | putnopvut | My friend Will confided in me that he has a horrible fear of mispronouncing the word "indefatiquable." I assured him that he could probably find at least five less esoteric synonyms and no one would think less of him. |
| 23:07.02 | atis_work | any special tool to get nicely-formatted commit messages? |
| 23:07.04 | putnopvut | s/indefatiquable/indefatiguable/ |
| 23:07.44 | kpfleming | atis_work: emacs :-) |
| 23:08.40 | atis_work | ok, so i'll use my favourite - mcedit :p |
| 23:12.24 | atis_work | huh, my first commit.. now just find out how to operate with svnmerge |
| 23:15.34 | atis_work | atis@lap:/work/digium-asterisk-svn-trunk$ /work/digium-repotools/svnmerge merge --revision 233577 https://origsvn.digium.com/svn/asterisk/branches/1.6.1 |
| 23:16.01 | atis_work | svnmerge: "https://origsvn.digium.com/svn/asterisk/branches/1.6.1" is not a subversion working directory |
| 23:17.16 | putnopvut | atis_work: don't use the URL of the branch, use the path to the working copy on your machine. |
| 23:17.59 | atis_work | ah, i don't have working copy :D |
| 23:18.05 | atis_work | just trunk |
| 23:18.07 | putnopvut | yeah that would be a problem :) |
| 23:18.24 | atis_work | ok, checking out |
| 23:19.09 | atis_work | well, normally i could operate with urls. ie copy etc |
| 23:24.33 | atis_work | svnmerge: no integration info available for path "/trunk" |
| 23:24.55 | atis_work | i know it's more easy to just commit, but i wanted to get know repotools |
| 23:26.35 | atis_work | ah, apparently i need some properties |
| 23:34.54 | atis_work | umm, ok, i now read in http://www.asterisk.org/developers/svn-branching-merging that i should commit to oldest release first, however i've seen that most commits go to the trunk first |
| 23:34.58 | atis_work | any hints? :p |
| 23:35.51 | russellb | ideally you would have done 1.4 first |
| 23:35.53 | russellb | but it's all good |
| 23:36.02 | russellb | from trunk, go to each 1.6.X, and run mergetrunk6 <rev> |
| 23:36.07 | russellb | you can go back and commit to 1.4 later |
| 23:36.13 | russellb | and then go to trunk and do block4trunk <rev> |
| 23:58.07 | atis_work | so, i do bolck4trunk first and then commit to 1.4, right? |
| 23:58.56 | atis_work | or block4trunk on rev commited in 1.4? |