| 00:15.00 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-yphpjsrtezntebpq) |
| 06:15.42 | *** join/#asterisk-dev goddva (~goddva@77.40.154.242) |
| 07:02.02 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:57.24 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:57.57 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 07:57.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:08.44 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:14.50 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:14.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:18.49 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 10:32.02 | *** join/#asterisk-dev aurs (~aurs@51.84-48-191.nextgentel.com) |
| 10:36.38 | aurs | app_queue.c seems to be logging EXITEMPTY events twice for the same call. Discovered this in 1.8, but it looks like it's the same on 13 as well (line 5289 and 7938 in 13.6.0) in wait_our_turn and queue_exec. One of those ast_log lines should probably be removed? |
| 13:23.33 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:39.28 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 14:25.37 | *** join/#asterisk-dev goddva (~goddva@2a02:fe0:c510:e300:2ab2:bdff:feef:adf8) |
| 15:00.57 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-ybiqyhqtdkqeygil) |
| 15:02.07 | *** join/#asterisk-dev matesstar (d4478a32@gateway/web/freenode/ip.212.71.138.50) |
| 15:10.36 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:21.15 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-qtmjvfzqncyofsbb) |
| 15:30.53 | *** join/#asterisk-dev goddva (~goddva@cm-84.209.8.215.getinternet.no) |
| 15:38.29 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-vxnujkotpadnzqrr) |
| 15:38.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:39.31 | file | Reminder: Today is Tuesday. Taco Tuesday/ |
| 15:39.48 | file | my cold shaking hands caused that typing mistake |
| 15:41.51 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-cibpsnhlfvrmgabo) |
| 15:51.12 | gtjoseph | file: i'm looking at the remaining dup messages in 13. looks like they're messages that are channel related and specific to an endpoint like "endpoints.PJSIP.1174.channels" |
| 15:51.19 | *** join/#asterisk-dev stkoch (~stefan@p2003005C2E65C3000222FBFFFE665270.dip0.t-ipconnect.de) |
| 15:51.26 | stkoch | hi |
| 15:51.33 | stkoch | I am at porting the chan_lantiq from asterisk 1.8 to asterisk 11 (and then 13) |
| 15:51.42 | stkoch | This is chan_lantiq for asterisk 1.8: http://paste.debian.net/360127/ |
| 15:51.54 | stkoch | The problem are the AST_FORMAT_ULAW, ... specifiers |
| 15:51.56 | file | gtjoseph, I wonder what caused us to diverge though... |
| 15:52.02 | stkoch | There is a table rtpPTConf.nPTup[IFX_TAPI_COD_TYPE_MLAW] = AST_FORMAT_ULAW; |
| 15:52.09 | stkoch | but these does not allow values greater than int8_t |
| 15:52.15 | gtjoseph | yeah good question. i'm doing a diff on the related modules now |
| 15:52.16 | stkoch | So that it work it is needed to change #define AST_FORMAT_INC 100000 to #define AST_FORMAT_INC 100 |
| 15:52.36 | stkoch | but thats not a beautiful solution... |
| 15:52.54 | stkoch | What do you think? |
| 15:53.32 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-giqdhoftifalwezo) |
| 15:53.46 | stkoch | If the define will not changed asterisk gives messages like |
| 15:53.47 | stkoch | channel.c:4301 __ast_read: Dropping incompatible voice frame on TAPI/1 of format unknown since our native format has changed to (ulaw) |
| 16:04.09 | tzafrir | Should it be possible to build asterisk with parallel (-j) build? |
| 16:04.36 | tzafrir | I'm getting errors (with 13.6) and don't ave time to look into them |
| 16:06.27 | gtjoseph | tzafrir: absolutely. I use -j16 |
| 16:19.11 | coreyfarrell | gtjoseph: I have another few patches for pbx.c, I think it's about the last of the easy moves. |
| 16:19.51 | gtjoseph | cool. lots of progress! |
| 16:21.27 | coreyfarrell | yeah after these might be a good time to pause. past what I have locally is likely to conflict with any fix for the deadlock issue. plus I think these patches are the last of the easy moves. |
| 16:21.40 | gtjoseph | mjordan: the duplicate events patch for 13/stasis_cache_pattern is different than master/stasis_cache_pattern. Do you remember why? |
| 16:21.45 | gtjoseph | coreyfarrell: agreed. |
| 16:22.44 | coreyfarrell | most of what remains is intimate with code that manages struct ast_context. |
| 16:23.14 | gtjoseph | that should probably stay there anyway |
| 16:26.26 | coreyfarrell | with the use of linked-lists by objects linked into ast_context probably right.. but if they were linked with vectors some of those objects could be opaque in their own file - ast_ignorepat, ast_include, ast_sw for example. |
| 16:27.27 | coreyfarrell | haven't fully evaulated if vector's would be appropriate for those lists.. also that would be pushing it for changes appropriate in 13 |
| 16:27.46 | mjordan | gtjoseph: hrm. I'm not sure what is happening there. |
| 16:28.00 | coreyfarrell | even though everything is already opaque and there would be no ABI changes, it would require actual code/logic changes so yeah.. |
| 16:28.34 | mjordan | coreyfarrell: I think once we get into those kinds of changes, we should probably be targeting master |
| 16:28.45 | gtjoseph | mjordan: no worries. i'm tracking it down. |
| 16:29.41 | file | I'll also add on the PBX front that we don't really have that many unit/testsuite tests which specifically target the PBX core - it gets used in tests, but nothing to exercise everything |
| 16:29.41 | coreyfarrell | mjordan: yup that's what I'm thinking. |
| 16:32.11 | coreyfarrell | anyone have thoughts about performance of vector's vs linked lists for pbx.c? specifically getting rid of the 'next' field of ast_ignorepat, ast_sw, ast_include and having ast_context keep them in vectors. |
| 16:36.08 | gtjoseph | +1 for vectors |
| 16:39.58 | coreyfarrell | gtjoseph: it would remove the need for ast_context code to know about the internals of those structures. context code needs to iterate those structs which currently requires reading the next field |
| 16:40.08 | gtjoseph | file: mjordan backporting stasis_cache_pattern from master to 13 fix the remaining dups. i'm running all the tests now. |
| 16:40.41 | gtjoseph | coreyfarrell: that would be a good thing. |
| 16:41.02 | mjordan | gtjoseph: odd. I wonder what the diffs were |
| 16:41.48 | coreyfarrell | gtjoseph: I'm thinking performance of vectors should be fine since the lists are read frequently and written rarely (constant read as PBX is running, only written during dialplan reload)? just not sure how that would really be tested. |
| 16:45.21 | mjordan | coreyfarrell: I'd write a mini-unit test that looks at the perf of both using a similar kind of object being stored |
| 16:47.28 | coreyfarrell | mjordan: as far as the vector is concerned the type of object being stored is no different from 'void *'. it seems like the usage pattern of the PBX core would be more important than what is being stored. |
| 16:52.13 | mjordan | coreyfarrell: true. I would think then that you'd mostly want to write a producer/consumer kind of test that mimics pbx.c usage, which, really, should be 99% consumer |
| 16:52.31 | mjordan | the only time dialplan changes is during a reload or a targetted addition/deletion, which should be a relatively rare event |
| 16:53.02 | mjordan | the only exception to all of that is the manipulation of hints/watchers |
| 16:53.16 | mjordan | but those are already ao2-ified, and I'd hold back from touching that code |
| 16:53.31 | file | mjordan, agreed |
| 16:53.43 | mjordan | did that once. Still has scars. |
| 16:54.45 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-spvsxjxhiggbgahs) |
| 16:54.45 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:55.26 | coreyfarrell | mjordan: yeah the hints/watchers code was not even on my radar yet |
| 16:57.17 | *** join/#asterisk-dev sgriepentrog (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 17:21.00 | coreyfarrell | kharwell: looks like my latest list of commits do conflict with your old review for pbx.c deadlock fix. I do not want to get in the way of a deadlock fix, I can take those latest reviews back if they will hinder you? |
| 17:24.12 | coreyfarrell | btw these are all for 13 and master, I just haven't posted the changes for 13 yet since I saw the conflict on gerrit. |
| 17:25.51 | kharwell | coreyfarrell: it should be fine and we can work around any conflicts. I am currently going down a different path with regards to the deadlock fix, so the stuff that is currently up is essentially getting reverted |
| 17:26.42 | kharwell | [the current stuff is] not going to b e implemented might be a better description |
| 17:30.24 | coreyfarrell | kharwell: ok just wanted to make sure I don't hold up a release :) |
| 17:33.46 | kharwell | don't worry when something goes wrong I just usually blame file |
| 17:34.27 | file | truth |
| 17:34.43 | coreyfarrell | kharwell: ha that was actually decided a few days ago when file said the first commit shouldn't conflict with your work! |
| 18:54.05 | *** join/#asterisk-dev elguero (cf9a22a3@gateway/web/freenode/ip.207.154.34.163) |
| 19:25.40 | *** join/#asterisk-dev opticron (~opticron@75.76.201.152) |
| 19:25.40 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 20:01.27 | gtjoseph | mjordan: any reason ASTERISK_REGISTER_FILE couldn't be backported to 13? It'd make it easier to add new files to 13 without having to have a different version for master. |
| 20:04.24 | rmudgett | gtjoseph: Doing that is guaranteed to cause any third party modules to no longer compile on v13. |
| 20:04.44 | gtjoseph | let me rephrase... |
| 20:04.55 | gtjoseph | ...without removing the existing macro |
| 20:05.22 | gtjoseph | or are they mutually exclusive |
| 20:13.43 | file | provided existing functionality is kept and modules built against 13 continue to load then it should be fine... |
| 20:14.48 | rmudgett | Looking at the definitions, you could define ASTERISK_REGISTER_FILE() in terms of ASTERISK_FILE_VERSION() in v13. That way new files could use ASTERISK_REGISTER_FILE(). |
| 20:15.13 | gtjoseph | that was the idea |
| 20:15.46 | gtjoseph | i was just looking at the differences between the 2 implementations |
| 20:16.23 | coreyfarrell | gtjoseph: +1 I was thinking the same thing earlier when I was changing that one line in my patches |
| 20:16.38 | gtjoseph | yeah, that's what triggered it. :) |
| 20:17.26 | rmudgett | I'd say go for it. That macro was mainly for use under svn anyway. |
| 20:17.54 | gtjoseph | sounds good. |
| 20:23.58 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 20:23.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:40.17 | gtjoseph | so are we doing ANY substitution in source files today? |
| 20:45.02 | coreyfarrell | gtjoseph: what do you mean? |
| 20:45.30 | gtjoseph | I.E. is anyone replacing things like $Revision$ any more. |
| 20:45.57 | gtjoseph | i can't find any but i was just checking |
| 20:56.38 | coreyfarrell | gtjoseph: I don't think we're doing any. |
| 20:57.03 | gtjoseph | me netiher |
| 21:04.16 | gtjoseph | we need a spell-check gerrit hook. at least for my commits. |
| 21:07.01 | gtjoseph | actually rmudgett has been my spell-check hook. |
| 21:08.28 | rmudgett | AFAIK git does not support substitutions such as $Revision$. |
| 21:09.28 | gtjoseph | it doesn't but i just thought there might be something wacky in the build deploy process somewhere |
| 21:10.00 | gtjoseph | doens't matter. $Revision$ is ignored by ASTERISK_FILE_VERSION now anyway |
| 21:10.37 | rmudgett | git revisions are rather hard to keep track of. |
| 21:10.58 | rmudgett | Does ac13f89 come before 8129d72? |
| 21:10.59 | gtjoseph | when i see messages from "SVN commits to the Asterisk project" though I get a little scared. |
| 21:11.11 | gtjoseph | :) |
| 21:48.58 | gtjoseph | rmudgett: it's unlikely we'll be adding new files to 11 but I can backport if you want. Can't just cherry-pick though. |
| 21:49.36 | rmudgett | I thought it would cherry-pick |
| 21:49.50 | gtjoseph | pbx_functions and pbx_builtins don't exist in 11 |
| 21:49.54 | coreyfarrell | gtjoseph: what if you remove the changes to main/pbx_*.c? |
| 21:50.05 | gtjoseph | yep, it's easy enough |
| 21:50.23 | gtjoseph | if it makes sense, i'll do it |
| 21:50.29 | coreyfarrell | also BTW I have no plans of updating the open pbx-split reviews to use the new macros |
| 21:50.50 | gtjoseph | didn't expect that. i juse needed to make sure it worked |
| 21:51.07 | gtjoseph | i'll back port to ll. it'll only take a minute |
| 21:51.10 | gtjoseph | 11 |
| 21:52.25 | coreyfarrell | gtjoseph: I'll +1 it when I get back from dinner |
| 21:52.35 | gtjoseph | thanks |
| 21:53.45 | rmudgett | Don't forget to remove the last commit message paragraph when removing the pbx_*.c changes. :) |
| 21:53.56 | gtjoseph | yes thank you. :) |
| 22:08.17 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |