| 00:11.12 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:17.53 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:32.05 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 01:04.12 | jameswf | wants to stab asteriskbot on the eye |
| 01:04.58 | sgriepentrog | why ON the eye. Why not in the eye? |
| 01:05.41 | jameswf | Auto correct protecting its software cousin |
| 01:06.21 | sgriepentrog | lol |
| 01:09.59 | sgriepentrog | It does need some exclusion rules, like never stl after asterisk. |
| 01:33.52 | jameswf | I was going to do the same style thing with freepbxbot then realized that that was a terrible idea. Went with a set of ifttt rules instead |
| 01:40.37 | *** join/#asterisk-dev stevePearPear (~stevePear@nusnet-228-27.dynip.nus.edu.sg) |
| 02:35.46 | tm1000 | jameswf: yes they do support UTF8 |
| 03:16.43 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 03:17.36 | *** join/#asterisk-dev stevePearPear (~stevePear@nusnet-235-102.dynip.nus.edu.sg) |
| 04:01.32 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-vhgjcxfhzbuewsbo) |
| 05:36.12 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 06:34.24 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:fd0c:f121:90ce:93b0) |
| 07:40.50 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 08:45.54 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:48.12 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:48.12 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:18.22 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 09:20.10 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 09:33.10 | *** join/#asterisk-dev wanna (~wanna@194.183.244.5) |
| 12:14.48 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:17.24 | *** join/#asterisk-dev stevePearPear (~stevePear@171.207.55.202) |
| 12:39.00 | *** join/#asterisk-dev stevePearPear (~stevePear@171.207.55.202) |
| 13:37.41 | opticron | I've got test-related reviews up if anyone is interested: https://reviewboard.asterisk.org/r/3916/ and https://reviewboard.asterisk.org/r/3924/ |
| 13:51.23 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-znnsrsuwcjohzurn) |
| 14:00.39 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-nvfkfevljtwwjkua) |
| 14:00.41 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:00.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:14.32 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ksrslmzydapyblhk) |
| 14:14.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:15.51 | mjordan | Qwell: did you ever get a chance to look at the patch on ASTERISK-24250? |
| 14:17.00 | Qwell | n'yet |
| 14:17.34 | seanbright | how about ASTERISK-20219? |
| 14:17.56 | seanbright | it's my patch, so naturally it's perfect |
| 14:18.04 | seanbright | it will just crash all unpatched asterisks |
| 14:18.08 | seanbright | NBD |
| 14:18.52 | mjordan | oh hey there. Had no idea you put a patch on it |
| 14:19.02 | seanbright | oh yes. |
| 14:19.03 | mjordan | lawl: "An important point I neglected to mention: if a peer is updated with the aforementioned patch and the user is not, the user will crash when initiating the call. |
| 14:19.03 | mjordan | " |
| 14:19.16 | seanbright | important point indeed |
| 14:26.41 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-yvdsszgpuhapmqei) |
| 14:26.49 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:28.25 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 14:41.29 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 14:42.55 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:42.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:58.33 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 15:11.21 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 15:22.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:03.58 | *** join/#asterisk-dev GameGamer43_ (sid5533@gateway/web/irccloud.com/x-kgpldvxflentlroh) |
| 16:07.51 | *** join/#asterisk-dev miguel3239 (~miguel323@2001:470:1f06:12c4::2) |
| 16:08.20 | jameswf | Crashes are like airbags.. they protect you from using bad code.... |
| 16:08.59 | jameswf | if we didn't crash your face would be in the windshield.... do you want your face in the windshield |
| 16:09.16 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:880e:1bed:70c5:3e1c) |
| 16:09.29 | *** join/#asterisk-dev Sjors (~sgielen@foo.kassala.de) |
| 16:09.46 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 16:09.46 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 16:37.03 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 16:40.13 | leifmadsen | jameswf: I'd prefer you just watch where you're driving |
| 16:40.24 | leifmadsen | jameswf: and use a proper vehicle like Go :D |
| 16:40.56 | jameswf | writes everything in BASIC |
| 16:41.05 | leifmadsen | nice moves |
| 18:21.15 | *** join/#asterisk-dev SGjunior (~sgjunior@out-pq-218.wireless.telus.com) |
| 18:37.49 | opticron | putnopvut, so I'm looking over https://reviewboard.asterisk.org/r/3951/ and I feel dumb for having to ask, but what's with the line starting with @? I don't recognize the notation and that config option isn't part of the outbound publish support that I can see |
| 18:38.19 | opticron | also, I didn't see any config samples for outbound publish support |
| 18:39.11 | putnopvut | opticron: that is part of sorcery's built-in extended options support. Options in a configuration file that start with @ are "extended" options. They don't get the type-safety of normal sorcery options, but it allows for modules to easily extend objects to have new options. |
| 18:39.30 | opticron | ok, I figured it was something like that |
| 18:40.07 | putnopvut | So in the case of the outbound publishes, event-specific options are configured as extended options so that each module that implements an event doesn't have to modify any sort of base file in addition. |
| 19:03.37 | tm1000 | mjordan: are you joking. I was just talking to some friends about Meyerriecksâ costume last week but I had no idea who it was |
| 19:04.26 | file | tm1000, :D |
| 19:04.34 | tm1000 | file: haha |
| 19:04.56 | opticron | he should wear it to astricon |
| 19:05.20 | Qwell | opticron: during a DAHDI talk |
| 19:05.25 | opticron | he'll fit right in with the rest of vegas |
| 19:07.37 | leifmadsen | oh crap! I booked my flight to Atlanta! |
| 19:08.06 | Marquis42 | Wait, Astricon isn't in Atlanta again? ;) |
| 19:08.49 | *** join/#asterisk-dev otherwiseguy (~otherwise@76.92.181.97) |
| 19:09.53 | file | leifmadsen, I hope you're joking |
| 19:09.55 | file | :P |
| 19:11.55 | leifmadsen | file: I knew you'd miss me |
| 19:12.14 | file | "miss" |
| 19:12.25 | Qwell | with every shot so far... |
| 19:16.21 | leifmadsen | I've built an immunity to ever poison he has used in the muffins so far |
| 19:16.25 | leifmadsen | every* |
| 19:29.17 | [TK]D-Fender | Iocane, I'd bet my life on it! |
| 19:35.19 | Marquis42 | So how are the .json files in rest-api/api-docs generated? In particular I'm looking at the different events, and some of them define an "extends" : "Event" and some do not even though all events are subtypes of Event. |
| 19:49.02 | leifmadsen | Marquis42: https://wiki.asterisk.org/wiki/display/AST/Create+a+new+resource+with+ARI <--- this page seems to kind of tell me that those json files are the master, and the C stubs are generated from there, so that those files are actually built by hand? |
| 19:49.28 | Marquis42 | Ah, ok, so the json files are the masters and are used to generate code and not the other way around? |
| 19:50.15 | leifmadsen | at least that's what this wiki seems to indirectly tell me :) I'm not sure what checks that they are in sync with the code though (as I presume after the stubs are built the code could diverge?) |
| 19:50.17 | leifmadsen | mjordan: ? |
| 19:50.27 | leifmadsen | pabelanger: or maybe you're familiar with this |
| 19:51.21 | opticron | there aren't any checks to ensure the json is in sync with the code, but anyone making changes to the json should run "make ari-stubs" after making changes |
| 19:51.36 | opticron | the generated files should never be changed directly and have DO NOT EDIT blocks at the top of them |
| 19:51.57 | leifmadsen | oh ok... so basically the logic is implemented somewhere other than the stubs? |
| 19:52.02 | leifmadsen | like extended or whatever |
| 19:52.04 | opticron | yep |
| 19:52.11 | leifmadsen | ok cool, so that indirectly keeps them in sync I guess :) |
| 19:52.16 | opticron | the stubs have calls out to predictable function names |
| 19:52.22 | Marquis42 | OK, gotcha. How about my question about the inconsistencies with the JSON in events.json? i.e., some of the events don't have the "extends" : "Event" on them. |
| 19:52.32 | opticron | hmmm |
| 19:52.37 | leifmadsen | perhaps an oversite/bug? |
| 19:52.37 | opticron | I don't know about that part |
| 19:52.52 | Marquis42 | The converse is fine, Events has all the applicable subtypes in its "subTypes" element. |
| 19:53.13 | leifmadsen | Marquis42: sounds like you have some editing to do? :) |
| 19:53.17 | opticron | is this in 13? |
| 19:53.19 | Marquis42 | Yes |
| 19:54.13 | opticron | probably an oversight |
| 19:54.58 | Marquis42 | Patches welcome? |
| 19:55.01 | Marquis42 | I assume |
| 19:55.32 | opticron | if david lee were floating around I'd ask him since he knows everything about the codegen |
| 19:57.12 | opticron | asks him anyway |
| 19:57.18 | mjordan | Marquis42: which event in particular? |
| 19:57.38 | opticron | lots of them |
| 19:57.40 | Marquis42 | There's a few, but DeviceStateChanged was the one I was looking at in particular just to figure out what was going on. |
| 19:57.42 | mjordan | ew |
| 19:57.43 | mjordan | yeah |
| 19:57.46 | mjordan | that's wrong |
| 19:57.52 | mjordan | patches welcome, but plz file a bug at least |
| 19:57.56 | mjordan | cus that's no bueno |
| 19:58.07 | Marquis42 | Will do both, I can operate the vim just fine. ;) |
| 19:58.31 | Marquis42 | I think there's at least one other instance of subtyping, I'll check that one too while I'm at it. |
| 19:58.41 | mjordan | if you do a 'make ari-stubs', it will regenerate all the C and wiki documents after you've updated the JSON |
| 19:58.59 | Marquis42 | OK, so that will change the generated code then too? |
| 19:59.59 | mjordan | yup |
| 20:00.27 | Marquis42 | Gotcha. Do you want me to do that and attach the full svn diff, or just a patch for the json file(s)? |
| 20:03.32 | opticron | FYI, the "extends" key value pairs should actually be removed |
| 20:03.37 | opticron | as per david lee |
| 20:03.48 | opticron | it's the old way of doing it and no longer applies |
| 20:04.11 | Marquis42 | Oh, ok. the 'new' way being 'subTypes' listed in the parent? |
| 20:04.15 | opticron | yes |
| 20:04.19 | Marquis42 | Gotcha |
| 20:04.32 | Marquis42 | Well I'll remove the ones that are there, then and provide a patch. |
| 20:04.48 | Marquis42 | Either way is fine with me, the inconsistency was what was annoying. :) |
| 20:05.27 | opticron | hooray for only maintaining the information in one place |
| 20:06.01 | Marquis42 | yes |
| 20:06.09 | Marquis42 | Having to change that all over the place would be much worse. |
| 20:14.20 | Marquis42 | OK, opened ASTERISK-24296 and attached patch. |
| 20:16.21 | mjordan | Marquis42: gracias |
| 20:16.28 | Marquis42 | np |
| 20:18.26 | leifmadsen | is it merged yet? |
| 20:18.28 | leifmadsen | ducks |
| 20:18.35 | Marquis42 | teehee |
| 20:27.05 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 20:29.43 | ipengineer | I have just noticed an issue.. And I am not sure if it is a bug or not but Asterisk queues do not emit an AMI event indicating âEXITWITHKEYâ. It shows up in the queuelog but AMI does not have any event to indicate a caller has left the queue with a key press. |
| 20:51.47 | WIMPy | would bet there will be newexten event. |
| 20:52.01 | mjordan | what AMI event, that exists today, do you think should contain that information? |
| 20:52.33 | mjordan | The queue log != AMI |
| 21:03.29 | ipengineer | mjordan: I agree but there is a QueueCallerAbandon event so I would think there should be a QueueCallerExit event or similiar. My use case: I am building a front-end dashbaord that shows users in a queue. When a QueueCallerJoin event gets triggered I add the call. I remove on QueueCallerConnect or QueueCallerAbandon if they exit on key there is no event and they get stuck. I dont see anything in the whole event dump t |
| 21:03.30 | ipengineer | us unique to this scenario |
| 21:04.58 | leifmadsen | ipengineer: there are certainly various things I've noticed are missing... one of them is even a JOINEMPTY log event in the queuelog which appears ot be an oversite |
| 21:05.16 | leifmadsen | so there is a good chance you've just found one of the edge cases where there is not a corresponding AMI and/or QueueLog event |
| 21:05.33 | mjordan | pretty much. It just doesn't exist. |
| 21:05.52 | mjordan | It'd be good to know what others don't exist, get a list on the wiki, and then get an issue to go make them. I'd still throw that under "Improvement" |
| 21:06.12 | mjordan | It's annoying that they aren't there, but a lot of times when features get added people don't consider all the edge cases of things |
| 21:06.19 | mjordan | or all the ways in which someone will use something |
| 21:08.10 | ipengineer | Alright. In the meantime I can work around this with a customer UserEvent in this case but like you said an edge case/oversite. My question is should I open an issue so someone doesnt have this problem down the road or leave it? |
| 21:08.27 | mjordan | It's an improvement, so it really should use a patch |
| 21:08.33 | leifmadsen | yeah, it's not a bug |
| 21:08.40 | mjordan | Ideally, it'd be nice if someone made some analysis about what is missing and e-mailed the -dev list |
| 21:08.42 | leifmadsen | unless there is a document that describes an event that isn't implemented |
| 21:08.42 | mjordan | as a start |
| 21:09.01 | mjordan | something comprehensive is more likely to get traction than a single annoyance |
| 21:09.11 | mjordan | and if it is just a single annoyance, that's actually a good data point to have too |
| 21:09.12 | leifmadsen | unless you want to provide the patch (which is probably fairly trivial) |
| 21:09.23 | leifmadsen | and what mjordan said :) |
| 21:09.27 | mjordan | patches are awesome-sauce |
| 21:09.38 | leifmadsen | not that it matters because it's all about externalizing apps anyways |
| 21:09.41 | leifmadsen | .trololo ? |
| 21:09.50 | mjordan | leifmadsen: time and progress man, time and progress |
| 21:09.53 | Marquis42 | haha yeah |
| 21:09.58 | ipengineer | Alright. Makes sense. I will keep track of everything on this end I run across and either have someone patch it or send an email. |
| 21:10.00 | leifmadsen | mjordan: don't I know it |
| 21:10.05 | mjordan | ipengineer: cool, thanks |
| 21:10.21 | Marquis42 | Unfortunately not nearly enough time, and thus not as much progress as I'd like. :) |
| 21:10.24 | ipengineer | leifmadsen: If you have an idea of some other events and you wouldnt mind sharing I could check those as well |
| 21:10.47 | leifmadsen | ipengineer: nothing off the top of my head |
| 21:10.57 | leifmadsen | I just notice them and fix them in our custom build then usually forget about them :) |
| 21:11.12 | leifmadsen | Marquis42: but we have ARI events on a bus! |
| 21:11.14 | leifmadsen | so that's something |
| 21:11.20 | Marquis42 | Indeed! |
| 21:11.42 | Marquis42 | And hopefully by the end of today we'll have some code generation based on the json files in the Asterisk source. :D |
| 21:12.00 | leifmadsen | that would also be hawt sauce |
| 21:12.10 | leifmadsen | I'm just learning Go so I can write apps when you get that far :) |
| 21:12.26 | leifmadsen | although sadly I'll need to head out soon to do family stuff ;) |
| 21:12.36 | leifmadsen | (only sad because I'm making much progress today) |
| 21:12.47 | Marquis42 | aye |
| 21:13.05 | Marquis42 | Not sure how late I can work today for the same reason, but I'll do what I can. Worse comes to worse, I'll finish up tomorrow. |
| 21:13.26 | ipengineer | Alright. Thanks for the help! |
| 21:25.37 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 21:25.37 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 21:42.36 | gtjoseph | file: got a sec for a sorcery question? |
| 21:42.44 | file | yes |
| 21:43.04 | gtjoseph | how do you unregister an object?? I.E. what's the cleanup for ast_sorcery_object_register |
| 21:43.17 | file | you can't, currently |
| 21:43.54 | gtjoseph | hmmm. that explains why you can unload then reload pjsip add-on modules that share the same sorvery |
| 21:44.03 | gtjoseph | sorcery |
| 21:45.50 | gtjoseph | file: so is it better to ignore the error from register that's already registered and let the module reload, or is it better to just not allow the module to fail on reload? reload being unload/load |
| 21:46.08 | gtjoseph | that didn't make sense |
| 21:46.35 | gtjoseph | better to ignore and let the load continue or error out and not let the module be loaded again. |
| 21:46.39 | file | it may or may not be safe to unload |
| 21:47.00 | gtjoseph | except for this problem, mine is. |
| 21:47.33 | file | the real fix would be to see how hard it would be to be able to have sorcery drop the object type |
| 21:47.56 | gtjoseph | i knew you were going to say that |
| 21:48.30 | gtjoseph | i think it's just unlinking it from the sorcery->types container. |
| 21:48.55 | gtjoseph | i was hoping not to touch sorcery though. :) |
| 21:49.21 | file | I generally opt for the real fixes, instead of optimism ^_6 |
| 21:49.23 | file | ^_^ |
| 21:49.56 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:50.04 | file | the thing about just unlinking is if the object type is externally accessible then something else may be using it |
| 21:51.16 | file | while the underlying objects won't be destroyed it still points to functions within the module you are unloading |
| 21:51.23 | gtjoseph | yep |
| 21:52.06 | gtjoseph | and there doesn't seem to be any ref manipulation |
| 21:52.48 | file | there is of the object type when doing things |
| 21:53.36 | gtjoseph | yeah, but no the type itself. i think it's always 2. |
| 21:54.04 | file | I don't know what you are referring to |
| 21:55.29 | gtjoseph | the actual ast_sorcery_object_type. no matter how many object of that type have been instantiated, the type definition isn't imcremented. |
| 21:55.51 | file | correct. |
| 21:56.03 | file | created objects have no reference back to it |
| 21:57.23 | gtjoseph | this is a bigger problem than i have time for now. maybe after i finish with phoneprov. |
| 21:57.53 | file | changing the universe when things in the universe are using it is hard |
| 21:59.25 | gtjoseph | :) |
| 22:00.21 | file | that's why in the Matrix you get that sense of dejavu... everyone is swapped to a new instance |
| 22:02.55 | gtjoseph | Hmmm. My cat just walked by twice. |
| 22:05.39 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-34-104.user.veloxzone.com.br) |
| 22:13.27 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:13.27 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:32.30 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:51.24 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-nvfkfevljtwwjkua) |
| 23:20.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:38.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:38.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:43.45 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:44.02 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:44.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |