| 00:09.44 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 00:09.53 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 00:11.14 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 01:14.11 | *** join/#asterisk-dev outtolunc (n=me@c-71-198-197-201.hsd1.ca.comcast.net) |
| 01:23.57 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 01:23.57 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 01:34.28 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 01:34.28 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 02:43.36 | *** join/#asterisk-dev Zippoman (n=chatzill@adsl-69-234-110-253.dsl.irvnca.pacbell.net) |
| 02:50.19 | *** join/#asterisk-dev pmhaddad (n=pmhaddad@24-247-41-171.dhcp.mrqt.mi.charter.com) |
| 03:33.33 | *** join/#asterisk-dev dalbaech (n=dalbaech@knight.darkvoip.net) |
| 03:38.40 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 03:38.52 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 03:43.27 | *** join/#asterisk-dev CunningPike (n=arodgers@S01060014bf81366b.vc.shawcable.net) |
| 04:41.14 | *** part/#asterisk-dev Mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 04:43.04 | *** join/#asterisk-dev ZX81 (n=matt@202.20.97.211) |
| 04:43.30 | ZX81 | hey, quick question: |
| 04:43.43 | Corydon76-dig | The answer is 42 |
| 04:43.50 | ZX81 | :) |
| 04:43.56 | ZX81 | I think the bugtracker roadmap comes from tagged version |
| 04:44.14 | ZX81 | is this so far correct? |
| 04:44.21 | ZX81 | anyways |
| 04:44.23 | ZX81 | if so |
| 04:44.41 | ZX81 | what decides whether something is on a particular version for the upcoming road map |
| 04:45.16 | ZX81 | I saw that a cdr entry was in the list for 1.4.25 (and tagged as such) |
| 04:45.54 | ZX81 | so is russellb or someone tagging particular bugs as being roadblocks for particular versions |
| 04:45.56 | ZX81 | ? |
| 04:46.03 | ZX81 | it's not like I have a bug or anything |
| 04:46.06 | Corydon76-dig | lmadsen is |
| 04:46.09 | ZX81 | ah ok |
| 04:46.23 | ZX81 | cool |
| 04:46.25 | ZX81 | thanks |
| 04:46.25 | ZX81 | :) |
| 04:46.28 | ZX81 | just curious |
| 04:46.29 | ZX81 | :) |
| 04:47.24 | Corydon76-dig | "just curious" == "kinky" |
| 04:47.29 | ZX81 | :D |
| 04:47.43 | Corydon76-dig | imho |
| 04:48.34 | ZX81 | :) |
| 04:48.42 | ZX81 | it would be nice if you could see tagged entries |
| 04:48.51 | ZX81 | in the view issues page thingy |
| 04:49.11 | ZX81 | ooh |
| 04:49.12 | ZX81 | tags |
| 04:49.13 | ZX81 | :) |
| 04:49.44 | ZX81 | oh no |
| 04:49.49 | Corydon76-dig | It would be nice if I weren't too tired to try to understand what that means |
| 04:49.51 | ZX81 | i'm looking for target version |
| 04:49.59 | ZX81 | hehe |
| 04:50.10 | ZX81 | only 5:50pm here |
| 04:50.36 | ZX81 | spent last three days getting over my sister visiting - nearly back to normal |
| 04:51.12 | ZX81 | Heh, could have discovered that for myself: |
| 04:51.12 | ZX81 | 2009-02-26 17:22 lmadsen Target Version |
| 05:51.07 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 06:09.12 | *** join/#asterisk-dev fiddur (i=fiddur@c042.rit.se) |
| 07:04.29 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:04.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:43.35 | *** join/#asterisk-dev mosty (n=mosty@213-66-224-163-no22.tbcn.telia.com) |
| 08:07.22 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:07.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:07.59 | *** join/#asterisk-dev schmooze_tony (n=schmooze@rrcs-67-52-212-6.west.biz.rr.com) |
| 08:17.31 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:22.38 | *** join/#asterisk-dev wedhorn (n=nnwedhor@123-243-209-34.static.tpgi.com.au) |
| 08:30.48 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 08:50.42 | *** join/#asterisk-dev DarkRift (n=dark@65.92.166.190) |
| 08:54.30 | *** join/#asterisk-dev joelbryan (n=joelbrya@203.177.143.137) |
| 09:45.15 | *** join/#asterisk-dev dlu_dus (n=dlu@83.125.8.7) |
| 10:05.07 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 11:21.41 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 11:25.18 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 11:31.54 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:31.54 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:34.59 | *** join/#asterisk-dev juanjoc (n=juanjoc@200.69.219.113) |
| 11:35.16 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 11:35.16 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:39.16 | *** join/#asterisk-dev DarkRift (n=dark@65.92.166.190) |
| 11:40.52 | *** join/#asterisk-dev msetim (n=setim@200.195.162.210) |
| 11:50.18 | msetim | hi guys |
| 11:51.43 | msetim | I opened the bug 14642 and I found another that can be related to it (14515) and if it's true sorry for it. |
| 11:55.39 | kpfleming | just post a note on your new bug with that information, the bug marshals will handle it |
| 11:57.11 | snuff-home | may take a look shortly.. |
| 12:01.32 | msetim | kpfleming, ok, I attached extra information there |
| 12:16.04 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:03.08 | *** join/#asterisk-dev Mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 13:03.09 | *** mode/#asterisk-dev [+o Mog] by ChanServ |
| 13:18.48 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:18.49 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:26.27 | *** join/#asterisk-dev jjshoe (n=jjshoe@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 13:35.32 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 13:38.11 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 13:38.53 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) |
| 13:45.25 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:45.25 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:51.07 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 13:51.07 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 13:52.34 | *** join/#asterisk-dev davevg (n=davevg__@74.94.3.214) |
| 13:53.04 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 14:01.34 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:01.34 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:06.33 | kpfleming | eliel|away: you don't need to use ast_copy_string() when you know the destination buffer is adequate to hold the string you are copying. in the commit you just made, you are allocating the buffer then filling it, so you know it is large enough, you can just use strcpy() |
| 14:09.56 | putnopvut | kpfleming: that may be thanks to my comment on his review. Sorry about that! |
| 14:09.56 | seanbright | memcpy would be better |
| 14:10.13 | seanbright | micro-optimizations ftw! |
| 14:10.17 | seanbright | :P |
| 14:10.23 | putnopvut | oh seanbright, you card! |
| 14:10.30 | seanbright | teehee |
| 14:10.33 | seanbright | i'm a hater |
| 14:10.51 | seanbright | speaking of which |
| 14:11.08 | putnopvut | speaks of which |
| 14:11.11 | seanbright | i sent russellb a link yesterday... lemme find it |
| 14:11.27 | kpfleming | yes, memcpy would be even better, since you know the size to copy |
| 14:12.23 | seanbright | glibc's implementation of strlen() - http://tinyurl.com/cvn4ue |
| 14:12.46 | putnopvut | seanbright: ah, yes, russell shared that. it does seem a bit more complicated than one would expect. |
| 14:12.49 | seanbright | something to hurt your brain on a wednesday morning |
| 14:13.01 | seanbright | indeed |
| 14:14.11 | seanbright | i had joked that i could make an implementation of strlen() that ran twice as fast but caused a segfault half the time |
| 14:14.31 | seanbright | but they went and did it (effectively) 4 times faster |
| 14:14.40 | seanbright | without the segv |
| 14:14.44 | ScribbleJ | YIkes |
| 14:15.34 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 14:15.34 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 14:16.52 | seanbright | wonders if strcmp is similar |
| 14:17.28 | ScribbleJ | I try not to be so clever in my code, it makes it hard for less intelligent people to debug/maintain. |
| 14:17.40 | ScribbleJ | OK, that's really just what I tell myself, of course... I'm not /capable/ of being so clever. |
| 14:17.44 | ScribbleJ | Heh |
| 14:18.06 | seanbright | well if your code was running in literally every app that ran under linux |
| 14:18.09 | seanbright | you'd take the time :) |
| 14:18.16 | ScribbleJ | That's absolutely true. |
| 14:18.48 | putnopvut | I didn't even bother trying to understand that code. |
| 14:18.53 | seanbright | and no, strcmp appears to be a more traditional implementation |
| 14:18.55 | ScribbleJ | I'm an even worse programmer than I alreayd thought, that's what the code there tells me. |
| 14:19.15 | seanbright | you aren't a worse programmer |
| 14:19.26 | seanbright | but everytime you think you're a great programmer, remember code like that :) |
| 14:19.32 | seanbright | it's like watching COPS |
| 14:19.32 | ScribbleJ | Hahaha, fair enough |
| 14:20.07 | seanbright | no matter how bad you have it, some poor bastard in a bbq stained wife beater is getting arrested for domestic abuse on network television |
| 14:20.19 | seanbright | that always makes me feel better |
| 14:20.23 | jjshoe | hahaha |
| 14:20.37 | ScribbleJ | Yes, that reminds me of a similar "helpful phrase" I learned from a friend back in school. |
| 14:20.58 | ScribbleJ | "No matter how hot a chick is, some dude somewhere is sick of putting up with her shit." |
| 14:21.11 | seanbright | ah yes |
| 14:21.12 | seanbright | a classic |
| 14:24.07 | seanbright | i've always heard it as "some dude is tired of <blank>ing her" |
| 14:25.48 | jjshoe | yeah, me too |
| 14:34.54 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:34.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:41.44 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:32.21 | ScribbleJ | I guess I shouldn't feel bad yet that no one's looked at my ticket on bugs.digium.com, since there are a few that are much older. |
| 15:32.46 | ScribbleJ | When I get to be the oldest, though, then I will feel real bad. |
| 15:32.54 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 15:34.42 | *** join/#asterisk-dev jcollie_ (n=jcollie@fedora/jcollie) |
| 15:39.39 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 15:44.47 | *** part/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 15:53.24 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:06.04 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 16:12.18 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 16:12.58 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 16:23.15 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:23.15 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:24.33 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:24.33 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:41.28 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 16:41.28 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 16:42.02 | eliel | kpfleming: you are right |
| 16:42.26 | kpfleming | yay! |
| 16:49.49 | kpfleming | declare that PCI Express x1 connectors are mechanically lame |
| 16:50.10 | putnopvut | they're too small |
| 16:54.00 | msetim | I'm trying to test patch 14515 at 1.4.23.1 and I'm getting an error. res_features.c.rej: http://pastebin.com/m42d051c0 |
| 16:54.14 | lmadsen | M14515 |
| 16:54.16 | MuffinMan | [closed] [Asterisk] Resources/res_features 0014515: [patch]Timeout settings in features.conf don't work as intended reported by sodom (Karma: +2.75) http://bugs.digium.com/view.php?id=14515 |
| 16:55.08 | lmadsen | msetim: why not just check out latest 1.4 branch which has that patch already in it? |
| 16:55.23 | msetim | lmadsen, yes... i'm trying to apply 14515 to test if it fix the problem of 14642 :) |
| 16:55.46 | putnopvut | msetim: sometimes the patch utility isn't smart enough to figure out how to apply a diff. In that case, your best bet is to manually apply the changes in the .rej file or do as lmadsen suggests and update to a revision with the fix already in it. |
| 16:56.02 | msetim | humm I was thinking that it was writted to 1.4.23.1 :) I will try branch |
| 16:56.16 | lmadsen | you just need to apply the patch by hand |
| 16:56.41 | lmadsen | just replace the line with the - with the line with the + |
| 16:56.45 | lmadsen | if (config->feature_timer && (!f || f->frametype == AST_FRAME_DTMF_END)) { |
| 16:57.19 | msetim | ok I will try it |
| 16:57.33 | lmadsen | it seems pretty straight forward :) |
| 17:00.57 | msetim | all right ;) |
| 17:06.51 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.56.203) |
| 17:17.39 | *** join/#asterisk-dev jandark (n=milad@unaffiliated/slackark) |
| 17:18.05 | msetim | applied manally, thks |
| 17:18.25 | msetim | manually* |
| 17:30.24 | *** join/#asterisk-dev albertoandrade (n=albertoa@200.195.162.210) |
| 18:01.41 | *** join/#asterisk-dev bkw_ (n=brian@freeswitch/developer/bkw) |
| 18:04.23 | kpfleming | is anyone here familiar with librt? i've seen a few apps that need it, only on particular platforms, but i have no idea what it is for |
| 18:05.25 | russellb | no idea what it is |
| 18:05.39 | putnopvut | kpfleming: "librt is a small general programming library (lists, hash table, socket functions, notification subsystem, etc.) which can be built with debugging instrumentation and you don't have to redefine the world to use it. " |
| 18:05.47 | putnopvut | <PROTECTED> |
| 18:06.06 | kpfleming | huh |
| 18:06.08 | putnopvut | so...sounds kind of like an STL for C? |
| 18:06.09 | mvanbaak | gheh |
| 18:06.15 | file | I don't think that is it. |
| 18:06.16 | mvanbaak | was about to paste that as well |
| 18:06.27 | file | ibrt, libposix4 POSIX.1b Realtime Extensions library |
| 18:06.39 | putnopvut | hmm |
| 18:06.46 | kpfleming | yeah, that sounds more like it |
| 18:06.56 | putnopvut | damn you google! |
| 18:07.05 | mvanbaak | putnopvut: amen |
| 18:07.49 | mvanbaak | gheh, what file posted is the 6th hit on google |
| 18:07.58 | mvanbaak | that's why my irc bot did not show it ;) |
| 18:08.03 | file | yup |
| 18:13.09 | eliel | Who is the "owner" of the idea about 'data get' and 'data put' API for gsoc? |
| 18:14.08 | russellb | nobody officially yet |
| 18:14.10 | russellb | but you can start with me |
| 18:14.44 | russellb | a number of people have been involved in the "pinemango" concept development |
| 18:16.04 | eliel | Do you have something else to say about what the api should look like? i was thinking about something like ("channels/sip/option", "value") for reading, this is what you are thinking? |
| 18:16.53 | russellb | potentially. My thoughts so far have been to structure requests and responses in a tree like form (think XML, but not actually in XML) |
| 18:17.00 | russellb | i even have a branch with some concept code somewhere ... |
| 18:17.39 | russellb | http://svn.digium.com/view/asterisk/team/russell/data_retrieval/include/asterisk/data.h?view=markup |
| 18:17.52 | russellb | that, main/data.c, and a little bit of stuff in chan_sip.c |
| 18:17.59 | eliel | ok, the api won't be restricted to just "atomic" values |
| 18:18.00 | russellb | but, that was just an idea ... not sure if it's the right route or not |
| 18:18.37 | russellb | i'm not sure what you mean |
| 18:19.07 | russellb | but we might be able to do something using the XML API |
| 18:19.23 | russellb | since it provides similar (and more flexible probably) data structures as to what i was proposing in that code |
| 18:19.44 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:19.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:20.03 | eliel | I like the idea... |
| 18:20.38 | russellb | and I had only addressed "data get" in my concept ... not data put |
| 18:21.03 | russellb | but I think it makes sense to think about them together, as they are very related, obviously |
| 18:22.43 | eliel | Yes, I think the project should be 'data get' and 'data put' together... |
| 18:23.47 | russellb | I was just afraid that it might get too big for a summer project, depending on the student |
| 18:23.50 | russellb | so i listed them separately |
| 18:26.35 | eliel | hmmm... maybe i am underestimating the work to be done |
| 18:27.24 | Corydon76-dig | Once we have a model that works for the most complex modules, the remaining could be janitor projects |
| 18:28.26 | Corydon76-dig | so get/put could be the same project, as long as the project doesn't require complete conversion of the entire codebase |
| 18:29.12 | russellb | nods |
| 18:29.22 | russellb | i certainly only intended the project proposal to be for the infrastructure |
| 18:29.37 | russellb | not conversion of the codebase |
| 18:29.37 | eliel | yes me too |
| 18:29.49 | russellb | although, I seriously suspect that the conversion will be non-trivial |
| 18:29.50 | Corydon76-dig | Yes, but it also MUST include conversion of the most complex modules |
| 18:29.51 | eliel | just a simple example |
| 18:30.15 | Corydon76-dig | otherwise, there's no proof that the infrastructure meets the needs of the codebase |
| 18:30.20 | russellb | nods |
| 18:30.55 | russellb | i don't know, it's something that we'd have to play by ear depending on how fast things progress |
| 18:31.14 | russellb | it may be just a single module instead of all of the most complex modules. |
| 18:31.31 | eliel | Corydon76-dig: I am thinking about a generic api with a generic xml communication protocol for reading and writing... and then some helpers for retrieving the data from the xml. |
| 18:31.31 | Corydon76-dig | Design always requires a back and forth there |
| 18:31.33 | russellb | all of them seems a bit ambitious for a summer |
| 18:31.59 | Corydon76-dig | eliel: XML is an interchange format, and it should NOT be an internal format |
| 18:32.10 | russellb | not in text form, anyway |
| 18:32.23 | Corydon76-dig | eliel: XML can certainly be one of the external formats, though |
| 18:32.31 | russellb | but the data structures that support representing XML seem like a good fit |
| 18:32.35 | eliel | what about using the dom? |
| 18:33.00 | Corydon76-dig | russellb: I'm not against that |
| 18:33.08 | russellb | cool |
| 18:33.32 | Corydon76-dig | russellb: we're really talking about a hierarchy, anyway. |
| 18:33.48 | kpfleming | four dimensional heirarchy :-) |
| 18:34.00 | Corydon76-dig | XML happens to implement a hierarchy, but calling it XML internally doesn't make sense |
| 18:34.11 | russellb | fair enough :-) |
| 18:34.36 | russellb | but if the XML API already exists and does exactly what is needed ..... |
| 18:34.37 | eliel | we could abstract the use of xml |
| 18:34.39 | russellb | shrugs |
| 18:34.45 | russellb | right, something like that |
| 18:34.58 | russellb | places kpfleming in the 3.14159th dimension |
| 18:35.09 | kpfleming | my favorite place to be |
| 18:35.16 | russellb | mmmm, pie |
| 18:35.16 | eliel | going to a meeting. |
| 18:35.23 | russellb | eliel: enjoy! |
| 18:35.24 | Corydon76-dig | prefers the 2.718281828th dimension |
| 18:35.30 | file | likes it here |
| 18:35.33 | *** join/#asterisk-dev msetim (n=setim@200.195.162.210) |
| 18:35.33 | kpfleming | in that dimension, pi is actually 3.2, so all round objects are slightly larger |
| 18:36.56 | russellb | is working on the proposed application format for students applying to our project ... |
| 18:37.04 | kpfleming | C, silly |
| 18:37.05 | russellb | "WHAT ... is your FAVORITE COLOR?!?" |
| 18:37.44 | russellb | kpfleming: :-p |
| 18:37.56 | Corydon76-dig | "WHAT... is the wingspeed of an African swallow?" |
| 18:38.37 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 18:38.46 | russellb | How much wood could a woodchuck chuck if a woodchuck could chuck wood? |
| 18:39.00 | putnopvut | Corydon76-dig: aw man, you messed it up... s/African/unladen/ |
| 18:39.37 | Corydon76-dig | putnopvut: NERD! |
| 18:39.38 | file | "If you were stranded on an isolated island for the rest of your life but were allowed to take one person with you... what did you have for lunch?" |
| 18:39.51 | russellb | heh |
| 18:39.55 | putnopvut | Definitely falafel |
| 18:40.13 | *** join/#asterisk-dev djbelieny (n=djbelien@32.176.76.100) |
| 18:40.26 | *** part/#asterisk-dev djbelieny (n=djbelien@32.176.76.100) |
| 18:43.04 | russellb | contents so far ... http://pastebin.ca/1358383 ... thoughts? |
| 18:43.36 | putnopvut | reads |
| 18:44.16 | putnopvut | Seems good so far. |
| 18:44.22 | putnopvut | I'll think of other useful questions. |
| 18:44.25 | russellb | It feels short, but I"m not sure what else to ask .. |
| 18:44.39 | russellb | What editor do you use? |
| 18:44.41 | putnopvut | Well, you could ask about experience with Linux, gcc, C? |
| 18:44.44 | putnopvut | That sort of stuff. |
| 18:44.53 | putnopvut | But that sort of is covered by the final question. |
| 18:45.10 | russellb | Yeah ... it's open ended, but would hopefully give us an idea of that stuff |
| 18:45.11 | putnopvut | What editor do you use? "emacs" gtfo |
| 18:45.19 | russellb | :-D |
| 18:45.45 | Corydon76-dig | russellb: "Do you have any developer in mind that you would most like to work with?" |
| 18:45.47 | russellb | If you were to describe yourself in a single C statement, what would it be? |
| 18:45.54 | putnopvut | break; |
| 18:46.08 | file | putnopvut: ooh |
| 18:46.13 | JunK-Y | linux driver class next semester, sounds like cool :) |
| 18:46.25 | russellb | Corydon76-dig: thanks, will add! |
| 18:47.42 | Corydon76-dig | russellb: "Is there any future direction you think the Asterisk project should take? (This may or may not involve your project.)" |
| 18:48.58 | Corydon76-dig | It's basically a "describe your programming philosophy" question, though couched in other terms |
| 18:50.34 | Corydon76-dig | "Describe your ideal programming environment. Include any GUIs, debugging tools, IDEs, or other tools that help your programming proficiency." |
| 18:51.03 | kpfleming | "soft drinks, snacks, household pets" |
| 18:51.39 | jsmith | kpfleming: "ideal temperatures and lighting conditions, white/pink noise generators" |
| 19:00.10 | Corydon76-dig | The_Boy_Wonder: if you wanted to filter out one of your clueless classmates, what is something that a potential interviewer could ask that would differentiate them? |
| 19:01.09 | The_Boy_Wonder | clueless just in general? |
| 19:01.50 | Corydon76-dig | There's gotta be someone who graduated with your same degree who you think probably skated |
| 19:02.52 | Corydon76-dig | unless UT Cookeville was just awesome at weeding those out |
| 19:03.19 | The_Boy_Wonder | of coarse. if i were interviewing them for a telecommunications i'd ask them to describe what they knew about the osi model |
| 19:03.59 | Corydon76-dig | russellb: ^^^ |
| 19:04.00 | The_Boy_Wonder | umm. programming, i'd probably ask about what a deep copy is. and who to achieve it in C |
| 19:04.08 | The_Boy_Wonder | how* |
| 19:05.08 | Corydon76-dig | That works |
| 19:06.57 | jsmith | The_Boy_Wonder: Ask them to write a simple function that takes two strings and an integer as arguments. The function should concatenate the first string, the integer, and the second string together and return the concatenated string. |
| 19:07.12 | jsmith | The_Boy_Wonder: It sounds simple, but it's always worked for me. |
| 19:07.53 | mosty | jsmith, in C? i almost can't imagine how anyone would get that wrong |
| 19:08.26 | jsmith | mosty: Well, I give them the benefit of the doubt. I let them do it in *any* reasonable programming language. |
| 19:08.37 | jsmith | mosty: (and you wouldn't believe how many people still fail) |
| 19:08.43 | putnopvut | What could be tricky about that problem in C is making sure not to return a pointer to stacked data. |
| 19:08.51 | putnopvut | I imagine a C novice would make that mistake. |
| 19:09.09 | jsmith | mosty: I've probably interviewed close to 500 people for programming jobs, and less than 10% have come close to a correct answer. |
| 19:09.34 | jsmith | putnopvut: But in Perl or PHP or Python, you'd think they'd be able to do it, right? |
| 19:09.36 | mosty | jsmith, in their preferred language? wow |
| 19:09.51 | putnopvut | jsmith: yeah in those languages it's *really* easy. |
| 19:10.02 | jsmith | mosty: Yeah... and in about 40% of the interviews I've done, they didn't do it in the language they specified as their preferred language |
| 19:10.11 | putnopvut | lol |
| 19:10.52 | mosty | heh, now that is depressing |
| 19:15.45 | The_Boy_Wonder | what do they usually mess up?! is it just syntax? |
| 19:15.53 | Qwell | jsmith: can I use bash? |
| 19:18.58 | jsmith | Qwell: I said "reasonable" programming language... If you can argue that bash is reasonable, then yes! |
| 19:19.52 | Qwell | oh, it's reasonable. |
| 19:23.46 | jsmith | Qwell: Then you can use it! |
| 19:24.01 | Qwell | echo $1$2$3 |
| 19:26.33 | putnopvut | Qwell: is that really "returning" the string? :P |
| 19:27.24 | Qwell | A C program can't return a string. |
| 19:28.00 | jsmith | Qwell: I'd accept a pointer to a character buffer, if that makes you any happier |
| 19:28.09 | *** join/#asterisk-dev dwayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 19:28.13 | putnopvut | dwayne: !! |
| 19:29.39 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 19:40.23 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 19:40.23 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 19:40.55 | tzanger | grr |
| 19:41.17 | file | tzanger: moo. |
| 19:41.24 | tzanger | I have code path that is protected by a mutex. |
| 19:41.42 | tzanger | it is shared between an ISR and workqueue. |
| 19:41.57 | tzanger | obviously the ISR can't sleep, so I use a state machine and trylock() in the ISR |
| 19:42.04 | tzanger | the workqueue can sleep, and thus uses down_interruptible() |
| 19:42.18 | tzanger | this works *great* over thousands of bytes and lots of time |
| 19:43.02 | tzanger | I added a third path to this code, also using down_interruptible() since it's from userspace (via ioctl()) |
| 19:43.20 | tzanger | this third code path *always* crashes out with "sleeping function called from invalid context" |
| 19:47.10 | tzanger | which blows my mind, becuase that means that my lock is being called either with interrupts disabled or in atomic context... and I have no idea how either are true when coming from an ioctl() syscall |
| 19:48.11 | kpfleming | how bizarre |
| 19:49.29 | tzanger | very |
| 19:49.45 | russellb | The_Boy_Wonder: Corydon76-dig ... I can't really put questions like that. This is an open book test. :-) |
| 19:49.51 | file | there's a song for that. |
| 19:50.06 | file | it is called... How Bizarre |
| 19:50.43 | kpfleming | tzanger: it is complaining about down_interruptible(), right? it's not something else in the code path? |
| 19:51.31 | tzanger | well the code path is a LITTLE more complex than that, but only because I'm emitting messages to gather stats about locking |
| 19:51.37 | tzanger | actually it is crashing because irqs are disabled |
| 19:51.40 | tzanger | in_atomic():0, irqs_disabled():1 |
| 19:51.57 | kpfleming | how did an ioctl get called with IRQs disabled? |
| 19:52.13 | tzanger | basically the function that is crashing does a down_trylock() first. if it fails, it printk()s something to tell me (for stats) and then down_interruptible()s |
| 19:52.16 | tzanger | since it can sleep |
| 19:54.01 | kpfleming | well, that's certainly beyond my linux kernel knowledge :-( |
| 19:54.03 | Corydon76-dig | russellb: putting jsmith's question is even better, then. If they fail that on an open book test, that would be major suckage |
| 19:54.04 | tzanger | http://pastebin.com/d1683e1e4 |
| 19:54.07 | tzanger | that's the partial stack trace |
| 19:54.12 | tzanger | the stuff under it is not needed |
| 19:55.03 | tzanger | but basically dahdi_ioctl calls the chanconfig, chanconfig calls hdlc_start, which calls hfc_reset_fifo_pair, whcih calls waitbusy, which will call b400m_setreg which has the lock |
| 19:55.21 | tzanger | the whole code path originates in userspace, and should be able to sleep just fine |
| 19:57.00 | tzanger | weird. |
| 19:57.28 | kpfleming | yes indeed. |
| 20:08.31 | *** join/#asterisk-dev flujan (n=flujan@189-039-010-068.static.spo.ctbc.com.br) |
| 20:15.16 | dwayne | putnopvut, hello |
| 20:21.23 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-45-243.dyn.grandenetworks.net) |
| 20:21.28 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-45-243.dyn.grandenetworks.net) |
| 20:21.48 | sruffell | tzanger: Unfortunately, your chanconfig callback currently needs to assume it is being called in atomic context. In the dahdi_ioctl, the channel lock is grabbed with irqs disabled before calling the callback. |
| 20:22.34 | kpfleming | ahh |
| 20:23.11 | sruffell | I was just dreaming about no spinlocks held across calls through function pointers yesterday... |
| 20:23.39 | kpfleming | so ioctl calls in dahdi can't sleep? ouch |
| 20:24.31 | sruffell | some can, some can't. I have it on my todo list to understand which locks are protecting which parts of which data structures. But I don't have a complete understanding of that yet. |
| 20:25.02 | kpfleming | so that presumably is being done because there are interrupt handlers that need to modify those structures and can't take locks (because they can't sleep) |
| 20:25.13 | kpfleming | if you disable interrupts, that issue is avoided |
| 20:27.20 | sruffell | presumably, but I'm not sure that the callbacks need to be called with interrupts disabled. Do they need to make changes to the structures atomically with changes made in the main ioctl or not... |
| 20:29.32 | kpfleming | right |
| 20:32.02 | *** join/#asterisk-dev eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 20:32.02 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 20:38.06 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 20:42.29 | tzanger | sruffell: aha |
| 20:42.33 | tzanger | sruffell: thank you |
| 20:42.38 | tzanger | that little tidbit will allow me to fix this |
| 20:46.09 | tzanger | I would have figured that anything coming from userspace (i.e. any code being called from an ioctl) MUST understand that it might sleep |
| 20:46.14 | sruffell | tzanger: You might want to also rethink using the down_trylock in a loop with a semaphore shared in process context. The problem is that on a uniprocessor system, the user process can acquire the mutex, is then interrupted, and the system is locked by the interrupt handler waiting for the the semaphore to free up. |
| 20:46.45 | sruffell | and since the user process will never run again while in the interrupt handler, it will never free the lock. |
| 20:47.03 | sruffell | if you really need to synchronize those parts, spin_lock_irqsave is your best bet. |
| 20:47.04 | tzanger | I was certainly coding that way |
| 20:47.36 | tzanger | sruffell: I don't think I have that issue... the ISR is a state machine |
| 20:47.39 | tzanger | one state is to acquire the lock |
| 20:47.50 | kpfleming | just deprecate uniprocessor systems and it's all good |
| 20:48.01 | tzanger | it does not progress past that state until the lock is acquired, and at that point it knows it can continue through until the last state, which puts it back |
| 20:48.20 | sruffell | so when it can't acquire the lock, the interrupt handler returns and doesn't run again until the next interrupt? |
| 20:48.23 | tzanger | at least for this particular driver |
| 20:48.28 | tzanger | sruffell: exactly correct |
| 20:48.32 | sruffell | ok... |
| 20:48.36 | tzanger | it doesn't spin |
| 20:48.56 | sruffell | so then you're buffering up data in the interrupt handler to all be processed when you acquire the lock? |
| 20:49.08 | sruffell | or what happens if the lock isn't acquired for tens of milliseconds? |
| 20:54.52 | *** join/#asterisk-dev {Sean} (n=sean@adsl-99-49-211-86.dsl.sfldmi.sbcglobal.net) |
| 21:00.59 | tzanger | the isr is OnLy used for status polling |
| 21:01.56 | tzanger | i read only a couple registers in ythe isr |
| 21:02.35 | tzanger | if i see anything worthwhile, i schedule the bottom half, which can sleep |
| 21:02.52 | tzanger | it works really well so far |
| 21:03.22 | tzanger | my biggst concern is all four spans with lots of dchan traffic |
| 21:03.54 | tzanger | which i am trying to get to a point where i can test |
| 21:04.08 | sruffell | ok..cool. Sounds like you're working on something similar to the stuff being done in the dahdi-linux-cmdqueue branch. |
| 21:04.28 | kpfleming | umm... you can't have 'lots' of d-chan traffic, they are 16kbps each |
| 21:04.30 | tzanger | single dchan is no problem |
| 21:04.51 | tzanger | kpfleming: unfortunately i can |
| 21:05.44 | tzanger | i can onlu read 1 byte per ms, but im working on reading 4 per ms if necessary |
| 21:06.22 | tzanger | i already boosted reads by 100% with spi register caching |
| 21:06.48 | tzanger | where i do not write the reg addreas if it is already selected |
| 21:06.58 | tzanger | anyway back home time |
| 21:07.41 | *** part/#asterisk-dev flujan (n=flujan@189-039-010-068.static.spo.ctbc.com.br) |
| 21:12.41 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 21:17.36 | *** join/#asterisk-dev strk (n=strk@ip-123-78.static.adsl.cheapnet.it) |
| 21:18.55 | strk | are there plans to support --prefix ? |
| 21:19.14 | strk | seems currently ignored |
| 21:20.11 | putnopvut | --prefix is supported... |
| 21:21.37 | strk | make cleans to be sure |
| 21:23.32 | Qwell | strk: How are you trying to use it? |
| 21:23.57 | jjshoe | I just wasted an hour on a if (a = b) typo... shoot me now. |
| 21:25.01 | kpfleming | there are compiler warnings to catch those. turn them on. |
| 21:25.09 | jjshoe | kpfleming wasn't in c. |
| 21:25.14 | kpfleming | oh. sorry. |
| 21:25.34 | jjshoe | if it only it had been... i was off in a far far worse language... |
| 21:25.51 | putnopvut | let's see...java? |
| 21:26.39 | strk | mkdir: cannot create directory `/var/lib/asterisk': Permission denied |
| 21:26.39 | strk | configured with --prefix=/extra/asterisk-trunk |
| 21:26.39 | strk | make: *** [datafiles] Error 1 |
| 21:27.26 | putnopvut | permission denied |
| 21:27.26 | jjshoe | putnopvut now tack a script on the end. |
| 21:27.35 | putnopvut | jjshoe: ah |
| 21:28.10 | jjshoe | there's only so much firebug can help :\ |
| 21:28.21 | putnopvut | jjshoe: some of us were briefed on the === and !== operator by one of our GUI guys earlier today. |
| 21:28.58 | *** join/#asterisk-dev strk (n=strk@ip-123-78.static.adsl.cheapnet.it) |
| 21:29.38 | *** join/#asterisk-dev telecos (n=sergio@34.166.219.87.dynamic.jazztel.es) |
| 21:34.34 | Corydon76-dig | Heh. Speex to ILBC transcoding takes less time than Slin16 to iLBC |
| 21:35.10 | jjshoe | putnopvut hrm? === equiv to == just more obvious? |
| 21:35.22 | putnopvut | jjshoe: apparently === takes the type into account, too. |
| 21:35.27 | JunK-Y | Corydon76-dig: with or without sse optimization for speex? |
| 21:35.32 | putnopvut | so 1 == '1' is true but 1 === '1' is not |
| 21:35.39 | jjshoe | putnopvut nice |
| 21:35.45 | Corydon76-dig | JunK-Y: no idea |
| 21:36.01 | russellb | it's the resampling .. |
| 21:36.05 | Corydon76-dig | JunK-Y: still seems funny, though |
| 21:36.27 | russellb | resampling ain't cheap! |
| 21:36.42 | JunK-Y | try ./configure --enable-sse in ur speex dir and recompile it. |
| 21:36.55 | Corydon76-dig | http://bugs.digium.com/view.php?id=14532 |
| 21:36.59 | JunK-Y | Jean-Marc Valin told us it increases upto 30% |
| 21:37.03 | Corydon76-dig | I pasted the translation matrix |
| 21:38.47 | putnopvut | Corydon76-dig: that's pretty sweet |
| 21:39.33 | *** join/#asterisk-dev moy (n=chatzill@74.12.124.89) |
| 21:39.42 | putnopvut | Corydon76-dig: only question I have about that is why you call floor() on the log10 operation if you're going to set an int to its value. Wouldn't floor() be implied? |
| 21:39.54 | strk | http://bugs.digium.com/view.php?id=8605 <---- my --prefix bug is known, closed ?? it's still there |
| 21:40.45 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 21:40.53 | russellb | M8605 |
| 21:40.54 | MuffinMan | [closed] [Asterisk] Core/Configuration 0008605: ./configure --prefix... ignored. reported by arkadia (Karma: +21.75) http://bugs.digium.com/view.php?id=8605 |
| 21:44.02 | strk | M9034 |
| 21:44.03 | MuffinMan | [closed] [Asterisk] Core/General 0009034: makeopts file missing ${prefix} reported by CrashHD (Karma: neutral) http://bugs.digium.com/view.php?id=9034 |
| 21:44.42 | Corydon76-dig | putnopvut: I originally had ceil in there |
| 21:45.03 | strk | all closed, but the bug persists |
| 21:47.48 | russellb | surely the bugs list the reason they were closed. |
| 21:48.38 | putnopvut | russellb: it appears to be a bit circular...one was closed because there was a newer issue opened and the newer one was closed because it was a duplicate of the older one. |
| 21:48.49 | lmadsen | putnopvut: I noticed that too |
| 21:48.53 | russellb | heh |
| 21:48.54 | putnopvut | But the first issue seemed to have the proper workarounds described in them. |
| 21:49.01 | lmadsen | just because there is a dupe, doesn't mean you can close them all :) |
| 21:49.03 | putnopvut | localconfdir and sysconfdir... |
| 21:49.11 | lmadsen | otherwise I'd just file a lot of dupes :) |
| 21:50.18 | russellb | if two people have the same bug, nobody gets a fix |
| 21:50.21 | russellb | that's our policy |
| 21:50.52 | russellb | it's in the guidelines |
| 21:51.01 | strk | it is localstatedir not being set using prefix |
| 21:51.37 | strk | I'm the third, so we don't match that policy :) |
| 21:52.01 | russellb | s/two people have/more than one person has/ |
| 21:52.02 | russellb | :-p |
| 21:53.03 | strk | configure.ac:60 |
| 21:53.06 | strk | if test ${localstatedir} = '${prefix}/var'; then localstatedir=/var |
| 21:53.08 | strk | fi |
| 21:53.15 | strk | ^^^^ that's the bug |
| 21:53.30 | strk | ${prefix}/var is the correct behaviour |
| 21:53.37 | Qwell | No it isn't. |
| 21:53.42 | strk | no comments in configure.ac to justify that change |
| 21:53.42 | russellb | some of that stuff was intentionally done that way |
| 21:53.48 | strk | well, ./configure --help says it is |
| 21:53.53 | russellb | so that we get the results _we_ expect :-) |
| 21:53.55 | strk | if it isn't, --help shouldn't tell it |
| 21:53.59 | Qwell | What are you setting prefix to? |
| 21:54.06 | russellb | and to maintain compatibility with all of the installation paths that we were using before autoconf |
| 21:54.15 | russellb | --help is automatically generated by autoconf, unfortunately |
| 21:54.21 | russellb | so some of it isn't exactly what we do. |
| 21:54.41 | strk | russellb: could add a WARNING or something near that override |
| 21:54.52 | russellb | we certainly don't want to put stuff in /usr/var/lib/asterisk ... |
| 21:55.02 | strk | why not ? |
| 21:55.06 | russellb | yeah, i suppose so. Making it more clear what is going on would be a good thing |
| 21:55.10 | russellb | because :-p |
| 21:55.13 | Qwell | because /usr/var/ exists nowhere. It is wrong. |
| 21:55.25 | Qwell | strk: What are you passing to prefix? |
| 21:55.25 | strk | depends on usage patterns |
| 21:55.32 | Qwell | No, it's wrong always. |
| 21:55.33 | strk | Qwell: /extra/asterisk-trunk |
| 21:55.59 | strk | Qwell: as long as asterisk knows where it is, it's not wrong |
| 21:56.00 | Qwell | and what exactly is it doing? |
| 21:56.20 | strk | make install is trying to install something in /var (ie: out of --prefix) |
| 21:56.35 | strk | my goal is to have multiple versions of asterisk installed, and possibly running |
| 21:56.42 | strk | for debugging/testing/hacking purposes |
| 21:56.55 | strk | and being able to uninstall by simply rm -Rf /extra/asterisk-<version> |
| 21:57.01 | russellb | so can't you specify localstatedir directly? |
| 21:57.06 | russellb | that would be a workaround for you. |
| 21:57.07 | strk | sure I can |
| 21:57.42 | strk | ofc, just tought it was worth pointing out that this requirements defeats the purpose of a standard auto-based configuration :) |
| 21:57.49 | strk | and isn't documented or warned about |
| 21:58.12 | russellb | point taken |
| 21:59.00 | strk | thanks |
| 21:59.17 | russellb | feel free to file a bug report regarding the lack of clear info about what it does |
| 21:59.20 | russellb | and we'll add some docs |
| 21:59.34 | russellb | sorry for the trouble. |
| 22:00.58 | strk | np |
| 22:02.56 | strk | now wgetting on install (which is fun) -- ofc it's stalling, for murphy's law |
| 22:10.05 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 22:10.05 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:18.46 | Qwell | fixed. it was wrong. |
| 22:19.06 | Qwell | which is why I was trying to get info from you :P you weren't answering the right question |
| 22:22.37 | strk | M14645 |
| 22:22.38 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0014645: LOCALSTATEDIR default doesn't include PREFIX as documented by ./configure --help reported by strk (Karma: neutral) http://bugs.digium.com/view.php?id=14645 |
| 22:23.04 | strk | Qwell: fixed really ? wow, I tought you were being really contrary :) |
| 22:23.05 | russellb | commit asterisk 181436 |
| 22:23.09 | strk | updates |
| 22:23.10 | MuffinMan | [181436] Committed by qwell on 2009-03-11T22:18:42.586507Z: Allow prefix to set localstatedir (when used and different from the default). |
| 22:23.10 | MuffinMan | .. |
| 22:23.10 | MuffinMan | ..This is similar to the /etc change that was made for the non-FreeBSD case. |
| 22:23.10 | MuffinMan | .. |
| 22:23.11 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=181436 |
| 22:23.21 | Qwell | strk: I was being contrary. In some cases, the code IS correct. |
| 22:23.24 | russellb | thanks, Qwell |
| 22:24.12 | strk | thanks! |
| 22:24.12 | russellb | Qwell: rawr for having to do a rebuild! |
| 22:24.12 | Qwell | russellb: pwnt |
| 22:25.04 | strk | got build errors by the end of that long long wget, strongly hoping it won't take a second wget on next install |
| 22:26.12 | strk | no errors on 'make', btw, only on 'make install', and *build* ones, which doesn't sound right (you shouldn't build at 'install' time, right?) |
| 22:27.02 | Qwell | strk: if things change, sure. install calls the all target |
| 22:27.06 | strk | anyway, on next 'make install' (after svn update) no wget occurred (thanks) and no errors (uhm, dubious about this) |
| 22:29.56 | strk | mmm.. can't I followup to my bug to confirm qwell fix ? (can't find how, if I can) |
| 22:30.47 | strk | never mind |
| 22:32.01 | strk | now testing the CLI interface (while reading the Asterisk book) |
| 22:32.07 | lmadsen | yay :) |
| 22:32.20 | lmadsen | note that the CLI interface will be different in 1.6/trunk than what is documented in the book |
| 22:32.21 | strk | is it normal that the text color changes to a very light gray after first command ? (sip show peers) |
| 22:32.28 | lmadsen | since the book is based on 1.4 |
| 22:32.31 | strk | oh |
| 22:32.34 | lmadsen | fyi |
| 22:32.55 | lmadsen | and jsmith still need to update to the 3rd edition for 1.6 |
| 22:32.56 | strk | thanks, I'll keep it in mind. is there another document/tutorial you'd suggest ? |
| 22:33.03 | lmadsen | not at this time really |
| 22:33.27 | strk | that's a good book, btw. Thanks for writing it :) |
| 22:33.40 | lmadsen | however you can look in the res_aliases.conf (I think that's what it's called) file for a decent list of aliases between 1.4 and 1.6 |
| 22:33.54 | lmadsen | (assuming you have something beyond 1.6.0.x) |
| 22:34.40 | strk | i'm still a starter, so could as well use the built-in helps atm, if it only was readable :) [ light gray over white is hell ] |
| 22:34.49 | strk | does sound as a curses bug really |
| 22:35.32 | lmadsen | there were some colour changes to allow a white background... I can't remember exactly how to make that work, but you could try asterisk -h to see if there is a startup command to make it use the console colours |
| 22:36.14 | strk | yep, -W does the trick |
| 22:36.34 | lmadsen | hawt |
| 22:36.42 | lmadsen | likes when he remembers stuff... even if vaguely |
| 22:38.06 | Qwell | strk: it's fixed, I test it ;p |
| 22:38.27 | Qwell | you'll also note that I brought up that issue in...some other bug |
| 22:38.36 | Qwell | M13093 |
| 22:38.37 | MuffinMan | [closed] [Asterisk] Core/BuildSystem 0013093: ./configure --prefix=/usr/local fails to set sysconfdir properly. reported by pabelanger (Karma: +36.50) http://bugs.digium.com/view.php?id=13093 |
| 22:43.53 | lmadsen | wonders aloud if his E71 can be used as a SIP video client.... |
| 22:45.30 | lmadsen | comes back to reality :) |
| 22:49.33 | mvanbaak | lmadsen: no |
| 22:49.42 | mvanbaak | lmadsen: I tried |
| 22:50.37 | mvanbaak | lmadsen: but I did find out 'Sun diamond dishwasher powder' is a _GREAT_ substance to clean your tonguepiercing |
| 22:54.18 | lmadsen | interesting........ |
| 22:54.31 | strk | sip.conf reports: ; sip set debug Show all SIP messages |
| 22:54.40 | strk | but: No such command 'sip set debug' (type 'core show help sip set debug' for other possible commands) |
| 22:54.44 | lmadsen | sip set debug on |
| 22:54.46 | lmadsen | sip set debug off |
| 22:55.01 | strk | sip.conf needs a fix (thanks) |
| 22:55.08 | lmadsen | strk: can you open a bug for that? |
| 22:55.17 | lmadsen | I won't remember because I'm going out for dinner very shortly |
| 22:55.29 | strk | k |
| 22:55.46 | strk | can I only fill "Summary" ? :) |
| 22:55.58 | lmadsen | it doesn't need to be long |
| 22:56.07 | lmadsen | just fill in the relevant info |
| 22:56.10 | mvanbaak | assign it to mvanbaak |
| 22:56.38 | mvanbaak | I'm fixing it as we speak |
| 22:56.43 | lmadsen | heading out to dinner with some friends now, ttyl! |
| 22:56.50 | mvanbaak | have fun |
| 22:56.59 | mvanbaak | dont forget to clean your piercing ;) |
| 22:57.00 | lmadsen | will do |
| 22:57.02 | lmadsen | :D |
| 22:57.22 | strk | mvanbaak: can you save me from reporting the bug ? |
| 22:57.36 | snuff-work | report it anyway.. |
| 22:57.47 | mvanbaak | no, report it |
| 22:57.48 | strk | oh boy, karma freaks eh ? :) |
| 22:57.50 | snuff-work | that way there is a history somewhere other than changelog |
| 22:58.01 | mvanbaak | what snuff-work said |
| 22:58.48 | strk | category ? |
| 22:58.51 | mvanbaak | strk: and that way I know in what version I have to fix it ;) |
| 22:59.00 | mvanbaak | channels/chan_sip |
| 22:59.10 | strk | too late, core/configuration |
| 22:59.20 | snuff-work | i can change it.. |
| 22:59.22 | mvanbaak | cool as well |
| 22:59.28 | mvanbaak | me too ;) |
| 23:03.09 | strk | http://bugs.digium.com/view.php?id=14646 |
| 23:03.27 | mvanbaak | thanks |
| 23:03.35 | snuff-work | mm i think it sits better in core\config actually :) |
| 23:03.53 | mvanbaak | yup |
| 23:04.07 | snuff-work | but with cli_alias module whatever u want can set debug :P |
| 23:04.14 | mvanbaak | lol |
| 23:04.26 | mvanbaak | I like my alias 'die die die you moron' |
| 23:05.46 | snuff-work | ;) |
| 23:06.57 | mvanbaak | hhmm, my ibook does not have the repotools installed |
| 23:08.15 | mvanbaak | ugh, why do we have awstats there |
| 23:09.27 | mvanbaak | svn rm awstats -m 'we should use svn:externals for this kind of stuff' |
| 23:11.27 | mvanbaak | damn, svn co still running |
| 23:12.06 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 23:13.05 | *** join/#asterisk-dev msetim (n=setim@200.195.162.210) |
| 23:15.06 | mvanbaak | strk: fixed in 181499 |
| 23:20.08 | mvanbaak | ugh, origsvn is giving me timeouts |
| 23:20.20 | mvanbaak | today is a bad day for my svn usage |
| 23:21.14 | strk | it's being slow for me too |
| 23:22.00 | mvanbaak | ok, merged to 1.6.0 and 1.6.1 as well |
| 23:22.03 | mvanbaak | karma added |
| 23:22.05 | mvanbaak | all done |
| 23:23.30 | mvanbaak | osx is nice as desktop, but it sux as development system |
| 23:46.02 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu2.dynamic.dsl.tele.dk) |