| 00:31.14 | *** join/#asterisk-dev michael_work (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 00:50.36 | WIMPy | Ooops. I exist twice. |
| 01:24.51 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 02:41.40 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 02:41.40 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:24.25 | *** join/#asterisk-dev debianlv (~User_Name@ip68-108-94-112.lv.lv.cox.net) |
| 03:24.29 | *** part/#asterisk-dev debianlv (~User_Name@ip68-108-94-112.lv.lv.cox.net) |
| 04:34.36 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-xhuqkpqtersylucm) |
| 07:30.54 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:04.22 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:04.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:44.31 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:301c:7723:939f:5957) |
| 09:18.12 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:21.30 | *** join/#asterisk-dev michael_work (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 09:29.40 | *** join/#asterisk-dev oej (~Adium@static-212-247-176-202.cust.tele2.se) |
| 09:29.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:03.23 | *** join/#asterisk-dev slavon (2e94e596@gateway/web/freenode/ip.46.148.229.150) |
| 12:03.40 | slavon | Hello all |
| 12:04.43 | slavon | <PROTECTED> |
| 12:05.57 | slavon | i must create one issue or may different? |
| 12:12.57 | slavon | i create ASTERISK-24551 |
| 13:09.14 | *** join/#asterisk-dev oej (~Adium@static-212-247-176-202.cust.tele2.se) |
| 13:09.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:15.29 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:25.18 | *** join/#asterisk-dev cosmicwombat (sid10687@gateway/web/irccloud.com/x-wuufqfhixjjqtflk) |
| 13:25.43 | *** join/#asterisk-dev moy (uid47040@gateway/web/irccloud.com/x-dcdxumqcoqjccvhs) |
| 13:26.50 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-iwzbcmkjgwpxjiuq) |
| 13:26.59 | *** join/#asterisk-dev fornax (~fornax@87-126-210-21.btc-net.bg) |
| 13:33.34 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-jhldzymdpcmjivkj) |
| 13:46.46 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 13:47.15 | file | Monday, Monday, gotta get down on Monday |
| 13:49.38 | leifmadsen | My virgin eyes! |
| 13:51.13 | jameswf | Coding and coding yeah.... Coding an coding yeah.... Forgot a semicolon.... |
| 13:53.04 | leifmadsen | also have a typo |
| 13:53.44 | leifmadsen | also your ellipsis' are too long |
| 13:53.59 | leifmadsen | code review: -1 |
| 13:54.00 | leifmadsen | :D |
| 13:54.04 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:54.09 | Marquis42 | leifmadsen: You pluralized ellipsis wrong :P |
| 13:54.13 | Marquis42 | It's ellipses |
| 13:54.21 | leifmadsen | ah so it is |
| 13:54.29 | leifmadsen | stupid english |
| 13:54.48 | Marquis42 | Indeed |
| 13:56.10 | wdoekes | shouldn't that be "wrongly"? since it's an adverb |
| 13:56.28 | jameswf | I Dont speak English, we are (I is) not in England. I talk Merican cause this is Merica |
| 13:56.46 | *** join/#asterisk-dev oej (~Adium@static-212-247-176-202.cust.tele2.se) |
| 13:56.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:57.16 | Marquis42 | jameswf: lol |
| 13:58.26 | leifmadsen | 'mer'ca! |
| 13:58.44 | leifmadsen | wdoekes: you're not wrong :) |
| 13:59.03 | jameswf | My daddy said there are to places, merica and not merica. If you live in not merica then you are wrong. |
| 13:59.25 | leifmadsen | to what place? |
| 14:00.01 | jameswf | leifmadsen: quit being a commie |
| 14:00.16 | leifmadsen | I promise nothing |
| 14:00.24 | jameswf | OK back to something that resembles productivity |
| 14:00.30 | leifmadsen | pffft |
| 14:00.31 | leifmadsen | it's Monday |
| 14:00.46 | jameswf | On a 3 day week no less |
| 14:01.05 | leifmadsen | Thanksgiving was last month, when travel was more reasonable |
| 14:01.19 | jsmith | leifmadsen: So you're going to work on Thursday? |
| 14:01.28 | leifmadsen | jsmith: technically yes :) |
| 14:01.34 | leifmadsen | I mean, I'll be logged into IM |
| 14:01.38 | leifmadsen | so clearly I'll be "working" |
| 14:03.22 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:35.15 | file | awww no gtjoseph |
| 14:37.53 | *** join/#asterisk-dev oej (~Adium@static-212-247-176-202.cust.tele2.se) |
| 14:37.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:49.00 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-mzvtiweyykpbqwmn) |
| 14:51.14 | skrusty | afternoon |
| 14:51.55 | file | skrusty, yo |
| 14:55.26 | skrusty | good weekend? |
| 14:55.53 | file | it was not bad |
| 14:55.56 | file | how was yours? |
| 14:56.32 | skrusty | ok - my little lad (19months) had a tummy bug, still unwell :( |
| 14:56.40 | leifmadsen | :( |
| 14:56.43 | skrusty | so not had much sleep |
| 14:56.44 | leifmadsen | my kid had a fever yesterday |
| 14:56.46 | leifmadsen | same |
| 14:56.57 | skrusty | ahte seeing him unwell |
| 14:56.59 | skrusty | hate |
| 14:57.08 | leifmadsen | they do tend to recover pretty quickly at least |
| 14:57.22 | skrusty | yeah, funny thing is, most of the time he's full of energy |
| 14:57.31 | skrusty | and then every now and then he seems really unwell |
| 14:57.40 | leifmadsen | yea mine is back up and running again already today after 2 bad days |
| 14:57.54 | skrusty | fingers crossed he's better by tomorrow :) |
| 14:57.57 | leifmadsen | skrusty: might want to look into probiotics for kids if he has stomach issues |
| 14:58.07 | leifmadsen | that's what we give my 22 mth old |
| 14:58.14 | leifmadsen | just mix a little in with his milk |
| 14:58.24 | skrusty | leifmadsen: cheers for the tip! he likes fromage frais |
| 14:58.40 | skrusty | (not the same think i know) |
| 14:59.15 | skrusty | but they often taste, and i find they taste similar |
| 14:59.30 | skrusty | erm, that made no sense |
| 14:59.34 | skrusty | see, no sleep! |
| 14:59.39 | leifmadsen | understand :) |
| 15:02.22 | skrusty | moved my ari framework over to github last night (from codeplex) |
| 15:03.00 | skrusty | easier then i assumed it would be - and now workign on my reworked ARI dialer |
| 15:04.24 | skrusty | which reminds me, need to (maybe) raise a bugon asterisk 12.5 - need to dig out the log but got some error about magic numbers |
| 15:06.37 | skrusty | astobj2.c: bad magic number |
| 15:07.45 | file | yeah that usually means that something is being accessed after it has been freed, or it's accessing ungood memory in general |
| 15:07.58 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-jsfthfosceoydgeg) |
| 15:07.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:08.12 | skrusty | hmm, ok |
| 15:08.33 | skrusty | should it cause a segfault? |
| 15:08.48 | file | it may |
| 15:08.50 | skrusty | ok |
| 15:11.09 | skrusty | mjordan: wouldyou accept examples for other frameworks for the ari-examples project on github? |
| 15:11.27 | mjordan | skrusty: sure |
| 15:11.35 | mjordan | skrusty: make a pull request to the repo |
| 15:11.41 | skrusty | will do, thanks |
| 15:15.06 | skrusty | still new to git :) |
| 15:15.32 | skrusty | (lame question) do i need to fork the repo to make a pull request? |
| 15:15.34 | skrusty | :/ |
| 15:15.47 | leifmadsen | this git hub? then yes |
| 15:15.57 | mjordan | yes, and yes |
| 15:16.07 | leifmadsen | you fork to your account, create a branch, push to the branch, then create a pull request back to the owner |
| 15:16.11 | skrusty | hehe :) |
| 15:16.26 | skrusty | was just checking, thanks |
| 15:17.10 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 15:17.10 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:19.14 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-itghjdkfrghpzpks) |
| 15:19.14 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:32.38 | *** join/#asterisk-dev linetrace (~linetrace@65.19.81.126) |
| 15:49.39 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-aknvcroysnlzssnq) |
| 15:56.17 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:14.27 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:23.31 | file | LUNCH |
| 16:49.07 | jsmith | file: Great idea! |
| 16:49.13 | jsmith | should do that every few days... |
| 16:49.22 | leifmadsen | omg it's almost that time already.. |
| 16:49.39 | jsmith | Guess I won't get a second breakfast in today :-( |
| 16:51.19 | leifmadsen | sadness |
| 16:51.26 | leifmadsen | unless you have breakfast food for lunch! |
| 16:51.28 | leifmadsen | GENIUS! |
| 16:55.35 | jsmith | leifmadsen: No, I have meetings for lunch... |
| 16:55.47 | jsmith | leifmadsen: My Monday schedule is horrific :-( |
| 16:56.11 | leifmadsen | yea I hear that |
| 16:56.16 | leifmadsen | my monday morning is mostly meetings |
| 17:19.25 | gtjoseph | file: need some clarification on your "An API call to sorcery that allows you to add a wizard to an instance BUT return the wizard that was added." statement. |
| 17:20.09 | file | gtjoseph, so if you have the wizard and the wizard data... you can directly manipulate it (ie: create/delete) |
| 17:20.13 | file | that was a thought of mine |
| 17:20.54 | gtjoseph | true but there's only 1 instance of any wizard. If I modify the config wizard that will modify it for all users. |
| 17:21.28 | gtjoseph | it's not like I can do a 'new ResSorceryConfig()" |
| 17:21.32 | file | you can't modify the config wizard |
| 17:21.55 | file | I mean add an in-memory wizard for each type, if you have a direct handle to THAT instance then you can create/delete on it |
| 17:21.59 | file | and not duplicate the implementation |
| 17:22.51 | gtjoseph | hmmm |
| 17:24.22 | gtjoseph | so i'd create a memory wizard, then overload it's load/reload functions |
| 17:24.55 | file | it doesn't have load/reload functions |
| 17:25.20 | gtjoseph | it will need them |
| 17:25.22 | file | you wouldn't have to overload anything - you'd just call the defined wizard interface on it to manipulate it |
| 17:25.36 | file | why? |
| 17:27.16 | gtjoseph | this is where I started. let me think some more. |
| 17:40.53 | gtjoseph | file: what if I created an ast_sorcery_wizard_get(name) api which returns the structure of an existing wizard, then clone it, override some functions, then register it using a new name. |
| 17:41.17 | file | uh |
| 17:41.18 | gtjoseph | register the clone, that is |
| 17:41.19 | file | why? |
| 17:41.35 | gtjoseph | to not suplicate the code |
| 17:41.39 | gtjoseph | duplicate |
| 17:41.53 | file | I still don't understand why you need to override some functions |
| 17:42.28 | gtjoseph | i have to synthesize the pjsip objects from the pjsip_wizard object. |
| 17:42.35 | file | sure |
| 17:43.18 | gtjoseph | when sorcery calls load for identify, I have to get the wizards and synthesize the identifies |
| 17:43.46 | file | not really - you can do that at any time and in fact you can add an observer to know when that should happens |
| 17:43.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 17:44.10 | gtjoseph | true but i don't want to do that on the fly every time someone asks for an identify |
| 17:44.34 | gtjoseph | and I need to be reload-aware |
| 17:44.48 | file | observers can do that |
| 17:46.14 | gtjoseph | i can't register an observer on something that doesn't exist and by the time it exists it's too late to apply the wizard. |
| 17:46.40 | file | you don't have to be a wizard |
| 17:46.47 | file | you can load far far later |
| 17:46.51 | gtjoseph | yeah, ok |
| 17:47.11 | file | when you load - register as an observer for future notification, and then set stuff up and populate the objects |
| 17:48.06 | gtjoseph | i think that's way more complicated than what I've got now but let me working on it a little |
| 17:49.48 | file | I think when all is said and done it would actually be simpler, and if stuff like this gets done elsewhere then it would be useful there as well |
| 17:51.19 | file | but yarrr the devil is always in the details |
| 17:51.54 | gtjoseph | maybe but i'm still not seeing how an observer is going to help. there's nothing to observe until i've created the object but i can't create it until someone tells me to. |
| 17:52.19 | file | observers can observe load/reload |
| 17:52.33 | file | so you know when something has triggered load/reload of an object type of blah |
| 17:52.36 | gtjoseph | hmmm. looking for that. |
| 17:53.24 | gtjoseph | ddoesn't the observer then need to be registered before someone calls ast_soercery_load_object()? |
| 17:54.23 | file | let me ask this |
| 17:54.25 | file | what do you need? |
| 17:55.41 | gtjoseph | the bottom line is that I need the pjsip infrastructure to not know the difference between discrete objects it got from pjsip.conf and those synthesized from the pjsip-wizard. |
| 17:55.58 | gtjoseph | all of that exists using the sorcery wizard method |
| 17:56.19 | gtjoseph | just like astdb and realtime |
| 17:56.48 | gtjoseph | reload needs to work as does the special processing like starting registrations and wualifies. |
| 17:56.55 | gtjoseph | qualifies |
| 17:57.59 | gtjoseph | and it has to be relatively immune to the peculiarities of the module loader |
| 17:58.18 | file | right - and you went with a wizard because that was the only way to get yourself in there |
| 17:58.25 | gtjoseph | correct |
| 17:58.52 | file | but because of that you had to modify everywhere else to apply it |
| 17:59.17 | gtjoseph | yep, or rely on sorcery.conf to add the wizard |
| 17:59.27 | gtjoseph | which isn't a good idea |
| 17:59.37 | gtjoseph | as you pointed out a while back |
| 18:00.27 | file | so - the one problem I could see with my suggestion is that if a module is subsequently loaded which a wizard could be used for, you wouldn't know it |
| 18:01.11 | gtjoseph | correct |
| 18:01.39 | file | but I'm not oppossed to something to provide that |
| 18:02.15 | file | hum hum hum |
| 18:02.19 | gtjoseph | but still the only way to register an observer is between ast_sorcery_object_register and ast_sorcery_object_load |
| 18:02.33 | file | currently, yes |
| 18:02.49 | gtjoseph | and that all happens in each module's load_module() |
| 18:02.51 | file | because observers exist on an object type, there are no observers presently at the sorcery instance level |
| 18:04.32 | gtjoseph | it's all in the timing |
| 18:07.11 | file | see - the fact you had to modify the other modules to do this just screams at me |
| 18:08.34 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 18:08.48 | gtjoseph | i understand but it's a trivial change compared to the work required to change the infrastructure. |
| 18:09.01 | file | it's a trivial change for now |
| 18:09.10 | file | well, it'll always be a trivial change |
| 18:09.20 | file | but I think long term and bigger picture ^_6 |
| 18:09.59 | file | having the needed primitives to do such things is valuable or else if something similar gets done then it's copying again |
| 18:10.41 | gtjoseph | maybe i could create a "future observer" capability in sorcery so you can register an observer and have it automatically applied on creation of future object types. |
| 18:11.12 | file | I'd opt for a sorcery instance observer that allows you to get notified of object type registration, global load/reload |
| 18:11.45 | gtjoseph | that might not be too bad. |
| 18:12.31 | gtjoseph | ast_sorcery_register_instance_observer(instance_name)? |
| 18:12.47 | gtjoseph | ast_sorcery_register_instance_observer(instance_name, observer) |
| 18:13.19 | file | one for name... one for specific pointer |
| 18:13.54 | file | ultimately my questions were for this - how can we make sorcery better and give the tools not just to allow this to be done but for further use down the road |
| 18:14.06 | gtjoseph | yep, agreed. |
| 18:14.22 | file | and I completely understand that your implementation works for you :D |
| 18:14.51 | file | train of thought = gone |
| 18:14.54 | gtjoseph | how about... ast_soercery_instance_observer(observer) to observe any instance... |
| 18:15.27 | gtjoseph | ast_sorcery_instabnce_observer(instance *, observer) to observe a specific existing instance |
| 18:15.34 | file | I wouldn't go that far - observing the world without understanding it can be... problematic |
| 18:16.08 | gtjoseph | true but then you have to know the exact instance |
| 18:16.19 | gtjoseph | so observe by name or pointer? |
| 18:16.28 | gtjoseph | well, both |
| 18:16.41 | file | both |
| 18:17.05 | gtjoseph | and the observe by name can be called before an instance is created |
| 18:17.16 | gtjoseph | you just have to know the module name |
| 18:18.20 | gtjoseph | so for my case i'd have to call ast_sorcery_instance_observer_register("res_pjsip", me) before res_pjsip loads. |
| 18:19.12 | coreyfarrell | mjordan: still no joy on refleaks-summary on bamboo. can I see how the script is being run? |
| 18:19.33 | file | gtjoseph, sure |
| 18:20.19 | gtjoseph | ok, I can deal with that. |
| 18:20.48 | file | I think with those... my reusable in-memory wizard... is possible |
| 18:21.12 | gtjoseph | yep, i think you're right. |
| 18:21.18 | file | rawr |
| 18:21.22 | file | I hate gmail. |
| 18:21.35 | coreyfarrell | mjordan: maybe we can reduce that job to just run a single test (one that leaks), that way we can run it multiple times if needed to get it working? |
| 18:21.37 | file | or maybe something else. |
| 18:21.46 | gtjoseph | i'll work on the observer mods today and get something up in the next day or so. should be pretty straightforward. |
| 18:21.58 | file | gtjoseph, cool cool |
| 18:57.46 | linetrace | gtjoseph: curious if you ever got a chance to test the kqueue timing interface on os x |
| 18:58.48 | gtjoseph | linetrace: i didn't. i had some power/cooling issues this weekend. I'll give it a shot this afternoon. |
| 19:07.28 | linetrace | gtjoseph: no worries. thanks, interested to hear your results |
| 19:15.06 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-qmdkzxpcopvfiqhf) |
| 19:50.21 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.152.163) |
| 19:59.51 | gtjoseph | file: for the callbacks i'm thinking instance_created, instance_destroyed, object_type_registered, object_type_loaded, object_type_reloaded, object_field_registered all called after their default actions. |
| 19:59.59 | gtjoseph | anything else? |
| 20:17.35 | gtjoseph | file: also noticing the use of taskprocessor. are the current observers notified asynchronously? If so, that's a problem. Take registration... the load-triggered observer might not be finished before registration starts it's scheduling. |
| 20:24.21 | *** join/#asterisk-dev otherwiseguy (~otherwise@24.27.227.0) |
| 20:26.40 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 20:36.56 | *** join/#asterisk-dev danjenkins__ (~dan@nat/digium/x-fmjfydogefonaeqo) |
| 20:48.31 | file | gtjoseph, hrm true |
| 20:49.49 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 20:50.16 | hexanol | while looking at cel.h of asterisk 13 |
| 20:50.57 | hexanol | there's a "todo" comment near the top saying that the CONF_ENTER, CONF_EXIT, etc events have been defined here but are unused |
| 20:51.14 | hexanol | they are not defined anymore in cel.h in these versions |
| 20:51.19 | hexanol | as far as I can see |
| 20:51.38 | hexanol | so, the comment could be removed I guess ? |
| 20:52.23 | hexanol | I know this is kind of unimportant detail, but I just stumble upon it |
| 20:52.40 | hexanol | while looking at the ast11 - ast13 differences |
| 21:16.00 | mjordan | hexanol: yup, the comment wasn't updated when CEL was. |
| 21:31.57 | skrusty | mjordan: just mocked up the channel-state example, does this look like it'son the right lines? https://gist.github.com/skrusty/b0baca28b2c943959fe3 |
| 21:32.36 | skrusty | used the .js asthe basis for my cs example |
| 21:32.58 | mjordan | heh |
| 21:33.03 | mjordan | I'm going to have to go dust off my C# knowledge |
| 21:33.31 | skrusty | heh, sorry |
| 21:33.40 | linetrace | my latest issue w/asterisk 12.7.0 on OS X 10.10.1 is a crash in app_voicemail's notify_new_message() (crash report: https://gist.github.com/morgant/0d7c32c5520965a84292) |
| 21:34.34 | mjordan | skrusty: np. Why not use a timer instead of thread.sleep? |
| 21:34.49 | mjordan | particularly since (I think) that would block the console |
| 21:35.03 | skrusty | it would block the thread the message was raised on |
| 21:35.24 | skrusty | each new message is raised on a new thread (from a pool) |
| 21:35.45 | mjordan | linetrace: you'll need to generate a back trace using the instructions on the wiki. The fact that it *appears* as if you're blowing up while fork'ing, however, is probably not a good sign. |
| 21:36.11 | mjordan | linetrace: your best bet, once you have a backtrace generated per the instructions, is to file an issue on the issue tracker. |
| 21:36.20 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace |
| 21:36.25 | linetrace | mjordan: thanks, will do |
| 21:36.41 | mjordan | skrusty: gotchya. Couldn't remember what the delegates are called on. |
| 21:38.16 | skrusty | it'sok - you've made me think about thread.sleep now, in terms of how efficient it is :) |
| 21:39.25 | skrusty | compared to using a timer |
| 21:42.05 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 21:47.37 | coreyfarrell | skrusty: I think it depends on the design of AsterNET.ARI... if it can run in an event loop then using a timer provided by the loop would probably be faster, in that case you would be running less threads (possibly just a single thread).. otherwise I'm not sure it would make a big difference |
| 21:54.15 | skrusty | coreyfarrell: it uses delegate.Begininvoke with an AsyncCallback. so each event it fired on a anew thread from a threadpool |
| 21:55.24 | skrusty | im consulting in #c# for educational purposes too :) |
| 21:57.42 | mjordan | in which case thread.sleep is fine. A timer is just going to do the same thing, more or less. |
| 22:00.55 | skrusty | :) |
| 22:01.47 | coreyfarrell | depending on the number of threads you end up with.. the other thought is if you are able to return quicker from ari_OnStasisStartEvent you would reduce the total number of threads (by returning them to the threadpool quicker). then you'd get more overhead from the threadpool so it would be a trade-off |
| 22:03.53 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:03.57 | skrusty | true |
| 22:04.18 | coreyfarrell | assuming return from ari_OnStasisStartEvent would release the current thread.. if you got 100 calls per second to ari_OnStasisStartEvent, you would have 600 sleeping threads before old ones started cleaning up |
| 22:05.14 | skrusty | agreed, normally i wouldn't create a production app that way, but it seemed to be a more succinct way for the example |
| 22:34.39 | gtjoseph | file: any further thoughts on the observer/taskprocessor issue? |
| 22:35.01 | file | not as of this time |
| 22:35.33 | file | you can drop that for now, I'll review some more and if I come up with a response respond |
| 22:36.01 | gtjoseph | i don't mind doing it anyway. |
| 22:36.37 | gtjoseph | if the async processing doesn't impact other uses |
| 22:43.34 | linetrace | where do core files get saved when running `asterisk -fg`? |
| 22:44.08 | gtjoseph | usually based on sysctl |
| 22:44.34 | gtjoseph | kernel.core_pattern for linux |
| 22:44.45 | gtjoseph | otherwise the working directory |
| 22:47.47 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 22:47.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:48.15 | linetrace | gtjoseph: ah, thanks kern.corefile on os x |
| 22:48.34 | gtjoseph | no prob |
| 22:51.49 | linetrace | sadly, getting "no core file handler recognizes format" when trying to generate the backtrace |
| 22:52.19 | gtjoseph | that usually means the pattern is invalid. |
| 22:52.26 | gtjoseph | what are you using? |
| 22:53.33 | linetrace | gdb 7.7.1 |
| 22:54.27 | gtjoseph | is the core file actually written? |
| 22:56.43 | linetrace | appears to be 616MB |
| 22:58.40 | gtjoseph | that's a lot of core file. mine are usually about 100M |
| 22:58.49 | gtjoseph | on linux anyway |
| 23:00.02 | linetrace | i haven't gone through and really pruned unused modules yet, so that may be part of it |
| 23:00.51 | gtjoseph | does it have an ELF header and a bunch of LOAD and CORE sections? |
| 23:07.07 | linetrace | not sure, but `file` says "Mach-O 64-bit core x86_64" |
| 23:09.49 | gtjoseph | gdb's support for Mach-O is a little iffy. Google for gdb Mach-O |
| 23:14.35 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-jsfthfosceoydgeg) |
| 23:14.47 | linetrace | oh, yeah, this is looking messy |
| 23:15.35 | linetrace | is it worth submitting the ticket with just the crashreport attached and adding the backtrace if/when I can or is that unlikely to get looked at without the latter? |
| 23:17.17 | gtjoseph | sure, just note the issue with getting the bt. |
| 23:27.20 | linetrace | okay, thanks, i'll do some more debugging and try to get the backtrace again in the morning, then finish the ticket for the app_voicemail crash |
| 23:28.07 | gtjoseph | does the same crash happen under linux? |
| 23:29.30 | linetrace | i don't currently have access to linux for testing, but likely will try to build a VM or something soon |
| 23:30.08 | gtjoseph | ok, give me the issue number and I can try to reproduce. |
| 23:31.41 | linetrace | cool, will pass it along tomorrow⦠i've got to obfuscate my extensions.conf & voicemail.conf a bit before submitting |
| 23:32.00 | gtjoseph | gotcha |
| 23:32.42 | linetrace | thanks again |
| 23:59.47 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-mzvtiweyykpbqwmn) |