| 01:17.06 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 01:21.07 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:21.07 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 02:16.22 | snuff-work | mm.. that's something interesting.. |
| 02:17.06 | snuff-work | if i have an ami user.. with only 'read=reporting' and no 'write='... i cannot access DBget |
| 02:17.27 | snuff-work | if i have read=reporting + write=reporting .. i can access DBget cmd.. |
| 02:22.49 | snuff-work | must be misunderstand write :) |
| 02:23.09 | snuff-work | seems write = ability to use cmds.. read = event msgs |
| 05:04.18 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 05:04.18 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 06:12.59 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@109.128.139.161) |
| 06:13.00 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:15.39 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 06:15.39 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 06:18.58 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 07:06.04 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 07:42.57 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 08:46.17 | *** join/#asterisk-dev saghul (~saghul@ip3e830637.speed.planet.nl) |
| 10:34.56 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 11:06.55 | *** join/#asterisk-dev Skavin (~kevins@202-180-69-27.me.tranzpeer.net) |
| 11:39.02 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:39.02 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 11:55.16 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 12:33.03 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-136-163.user.veloxzone.com.br) |
| 13:27.29 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 13:34.00 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 13:40.13 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-136-163.user.veloxzone.com.br) |
| 13:55.34 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xwgbwpajpzrlwhom) |
| 14:48.47 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:48.47 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:57.27 | wdoekes | opticron: I'm referring to the swapping of the two field_set lines |
| 15:41.18 | opticron | woah...swapping the order results in test failure? |
| 15:41.21 | opticron | tests |
| 15:45.22 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:45.22 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:45.42 | opticron | wdoekes, interesting breakage |
| 16:12.39 | wdoekes | no |
| 16:13.57 | wdoekes | the heads only hold the data, not which field holds which data, right? |
| 16:14.19 | wdoekes | so storing string2 first would put that data first, or? |
| 16:14.44 | opticron | the string field pointers are bounded by the mgr and mgr_pool pointers |
| 16:14.57 | wdoekes | then we'd compare string1 against string2 of inst2 and vice versa |
| 16:15.24 | opticron | the order should be consistent in that area of the structure |
| 16:16.13 | opticron | I'm thinking I've got the code working at the wrong level of indirection |
| 16:18.11 | wdoekes | could you safely traverse the struct without worrying about the compiler ordering in some other fields in between? |
| 16:21.32 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-miqppejjfaoenamr) |
| 17:39.35 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:39.35 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:38.35 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:38.35 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:01.49 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:01.49 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:30.23 | seanbright | i demand someone review #2288 |
| 20:30.34 | seanbright | DEMAND |
| 20:30.41 | seanbright | or don't. whatever. |
| 20:34.01 | *** join/#asterisk-dev w9sh (~chatzilla@64.238.96.125) |
| 20:51.11 | putnopvut | seanbright: hey any particular reason you discarded review 2307? |
| 20:52.38 | seanbright | putnopvut: because it was broken |
| 20:52.57 | seanbright | putnopvut: worker_idle isn't an appropriate place for what i was trying to accomplish |
| 20:53.02 | putnopvut | okay |
| 20:53.17 | seanbright | from what i have been able to determine, i can't get a 'safe' count of active/idle threads there |
| 20:53.30 | seanbright | at least in the testing i had done |
| 20:53.55 | putnopvut | Yeah, the "shrink" operation is probably the best place to check if you're about to dip below the minimum. |
| 20:54.11 | putnopvut | That way you're running in the control queue and nothing else could be trying to change size at the same time as you. |
| 20:54.38 | putnopvut | Essentially the opposite of what is done in "grow" to be sure you aren't going above the maximum. |
| 20:54.59 | seanbright | right, but for minimum size, you want to control when idle threads naturally die |
| 20:56.15 | seanbright | i might be prematurely optimizing. i want to replace the threading in chan_iax2 with threadpools. |
| 20:56.34 | seanbright | i want to always keep 10 threads around to match the current behavior |
| 20:57.12 | seanbright | and it "feels" more efficient to always keep idle threads around, but i should probably measure it before i go down that path. |
| 21:02.25 | seanbright | OR i'm talking out of my ass |
| 21:02.27 | seanbright | :D |
| 23:22.51 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |