| 05:43.10 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 05:43.10 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 05:45.11 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:45.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:01.09 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 11:01.09 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 15:04.29 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 15:04.29 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 15:30.17 | *** join/#asterisk-dev tzafrir (~tzafrir@37.26.146.240) |
| 15:30.17 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:39.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:39.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:40.53 | *** join/#asterisk-dev flapjacks (~flapjacks@wsip-70-166-201-90.ph.ph.cox.net) |
| 15:48.25 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 15:57.20 | *** join/#asterisk-dev [tpn]leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:57.20 | *** mode/#asterisk-dev [+o [tpn]leifmadsen] by ChanServ |
| 16:00.17 | mjordan | opticron: ping |
| 16:01.00 | opticron | pong |
| 16:01.20 | mjordan | so, linkedids are now going to be set by the bridging layer. |
| 16:01.37 | mjordan | and if a channel's linkedid changes, a new snapshot of the channel will be published |
| 16:01.44 | opticron | sounds good |
| 16:01.48 | mjordan | this means calling ast_cel_linkedid_ref is a bad idea |
| 16:02.02 | mjordan | since CEL should automagically get notified that the linkedid has changed anyway. |
| 16:02.29 | mjordan | i.e. - ast_cel_linkedid_ref should be private, and called by cel.c when it notices that the linkedid just changed |
| 16:03.01 | opticron | on a related note, I found the culprit responsible for the CEL crash... |
| 16:03.25 | mjordan | excellent! |
| 16:03.32 | mjordan | on a related note, why are we even tracking the linkedids in CEL? |
| 16:03.43 | file | on an unrelated note, TGIF |
| 16:03.53 | mjordan | ah, nm. When a linkedid gets retired. |
| 16:03.55 | mjordan | Silly. |
| 16:04.06 | mjordan | file: indeed. Fridays for all |
| 16:04.10 | opticron | that and they're logged |
| 16:04.19 | Corydon76-work | Fridays are logged? |
| 16:04.22 | mjordan | right, you have to publish at that point. |
| 16:04.28 | opticron | Corydon76-work, correct |
| 16:04.32 | opticron | in fact, every day is logged! |
| 16:04.33 | mjordan | Corydon76-work: like everything now ;-) |
| 16:04.47 | opticron | Friday is now certified tree-free |
| 16:05.18 | mjordan | opticron: if you want to go ahead and just monitor the channel snapshots for when a channel's linked id changes, that'd be great. I'm going to remove the call to ast_cel_linkedid_ref from channel.c |
| 16:09.22 | opticron | I'll work on that later today |
| 16:13.10 | Qwell | leedm777: in ARI, for fields that are required, swagger-UI is yelling at me if I don't put something in those fields. Is that swagger-UI kicking it back, or Asterisk? read: can I safely assume that those fields will be non-NULL in my code? |
| 16:13.47 | leedm777 | Swagger UI is the one kicking that back. |
| 16:14.10 | Qwell | So I must check for required fields? |
| 16:14.26 | leedm777 | Yes. |
| 16:14.31 | Qwell | k, thanks |
| 16:50.48 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-iqetreypssmrvtsh) |
| 17:02.47 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 17:06.14 | *** join/#asterisk-dev italoros_ (~italoross@187.60.66.11) |
| 18:02.41 | *** join/#asterisk-dev Victor_Yure (~victor_yu@unaffiliated/victoryure/x-837844) |
| 18:07.36 | mjordan | opticron: why are we giving dummy channels a topic? |
| 18:09.09 | Corydon76-work | So we can tell dummies that they're off-topic? |
| 18:10.42 | mjordan | indeed :-P |
| 18:14.48 | opticron | <_< |
| 18:14.50 | opticron | >_> |
| 18:15.03 | opticron | looks |
| 18:15.43 | mjordan | just sent you another CEL crash. The dummy channel one, however, is a bit weirder. I'm not sure why we'd ever set up a channel topic on a dummy channel. |
| 18:15.52 | file | nothing to see here, move along? |
| 18:15.57 | mjordan | That caused the crash in predial: http://bamboo.asterisk.org/artifact/TESTING-ASTERISKTRUNK/AST18CENTOS32/build-1368/testsuite/logs/predial/backtrace_441.txt |
| 18:15.58 | opticron | because it uses the same internal channel alloc function as real channels |
| 18:16.07 | mjordan | topics aren't set there |
| 18:16.10 | mjordan | topics are set in channel.c |
| 18:16.54 | mjordan | really a question for leedm777 as well :-) |
| 18:16.55 | mjordan | ^^^ |
| 18:17.24 | mjordan | is there any danger in not giving a channel a topic? |
| 18:17.30 | mjordan | particularly, the dummy one? |
| 18:18.26 | opticron | things would need to be adjusted |
| 18:21.05 | mjordan | such as? |
| 18:21.29 | opticron | ast_channel_topic() is currently guaranteed to return something non-null |
| 18:21.47 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-rmmtcsicmcaowuzf) |
| 18:22.09 | mjordan | well, someone somewhere has to start expecting NULL returns |
| 18:22.30 | mjordan | because clearly things are returning NULL - its either the publisher or the subscriber who has to handle it :-) |
| 18:57.05 | file | someone is doing cleanup *cough*putnopvut*cough* |
| 18:59.12 | putnopvut | nah |
| 19:04.52 | leedm777 | mjordan: If I interpret the situation correctly, having a topic on a dummy channel avoids a lot of pretty useless NULL checks. Sort of like the Null Object pattern. |
| 19:09.45 | mjordan | except someone apparently published to it |
| 19:10.23 | mjordan | and that channel appears to not be in the stasis-cache |
| 19:10.45 | mjordan | and - in general - getting published messages for dummy channels feels like a bad thing |
| 19:11.04 | leedm777 | publishing to it should be okay. hence the Null Object pattern. |
| 19:11.18 | leedm777 | So long as no one is subscribed to the channel, and the channel isn't forwarded anywhere. |
| 19:14.51 | leedm777 | Yeah; for dummy channels I wouldn't setup chan->forwarder in ast_channel_internal_setup_topics(). |
| 19:16.51 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:17.29 | mjordan | leedm777: right - the problem is the caching topic gets the subscribe/unsubscribe messages |
| 19:17.44 | leedm777 | mjordan: not if it's not forwarded. |
| 19:18.00 | leedm777 | <rephrases>only if it's forwarded</rephrases> |
| 19:34.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:34.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 21:27.53 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 21:56.07 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 21:58.29 | file | malcolmd, that should do it |
| 22:00.18 | malcolmd | file: zing! |
| 22:00.20 | malcolmd | *tests* |
| 22:09.52 | file | putnopvut, we don't have a User-Agent / Server header :D |
| 22:11.24 | putnopvut | nope |
| 22:46.23 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 22:48.48 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hlzyhgllpyqbvkdj) |
| 22:51.53 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 22:51.53 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 22:58.57 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-wbejkgfjjmrtcege) |
| 23:25.51 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |