| 00:04.13 | *** join/#asterisk-dev fakhir (n=Fakhir@unaffiliated/fakhir) |
| 00:09.08 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 01:32.47 | *** join/#asterisk-dev mitcheloc (n=mitchel@adsl-68-120-230-95.dsl.irvnca.pacbell.net) |
| 01:59.11 | *** join/#asterisk-dev kpfleming|laptop (n=kpflemin@64-60-73-2.static-ip.telepacific.net) |
| 01:59.11 | *** mode/#asterisk-dev [+o kpfleming|laptop] by ChanServ |
| 02:06.02 | Corydon76-dig | Morning, Kevin |
| 02:06.25 | kpfleming|laptop | morning? |
| 02:06.27 | kpfleming|laptop | ouch |
| 02:10.02 | Corydon76-dig | Ah, good day, then |
| 02:12.11 | Skyelar | kpfleming|laptop: manage to sneak in your session with ADT at some point? |
| 02:12.34 | JunK-Y | the new version is ready? |
| 02:13.14 | Corydon76-dig | TFOT2 should be in your local bookstore shortly, if it is not already there |
| 02:13.14 | kpfleming|laptop | Skyelar: not yet, will be on wed morning it appears |
| 02:13.35 | kpfleming|laptop | Corydon76-dig: not a great day... just travel day |
| 02:13.53 | Corydon76-dig | Ah... |
| 02:14.09 | Skyelar | kpfleming|laptop: cool. Sorry to bug you about it, but have a box that's supposed to go in next Monday that needs it :) |
| 02:15.30 | kpfleming|laptop | yeah |
| 02:15.56 | kpfleming|laptop | too many people taking vacations and other trips that overlap... can't get the right people in place at the right time |
| 02:16.12 | kpfleming|laptop | i want to get it fixed, believe me |
| 02:17.06 | Skyelar | yeah. I suspect it's caused problems for more than just me - I saw a message on -users a few days back that looked suspiciously similar |
| 02:17.41 | Skyelar | you manage to reproduce it locally yourself? |
| 02:18.02 | JunK-Y | Corydon76-dig: great, will see that after astricon. |
| 02:18.20 | kpfleming|laptop | Skyelar: yep |
| 02:18.30 | Skyelar | sweet. I'm not crazy then :-) |
| 02:24.41 | Corydon76-dig | You're not? |
| 02:25.19 | Skyelar | well, ok, I am. Just not about this thing. |
| 02:26.05 | Corydon76-dig | jmls: up late? or is it early for you? |
| 02:29.40 | kpfleming|laptop | 1 million iPhones sold already? incredible |
| 02:29.55 | snuff-work | mm what a waste.. iphone pfft ;) |
| 02:31.05 | Corydon76-dig | snuff-away: I dunno, being tethered to a phone, period... |
| 02:32.13 | Corydon76-dig | Utility is when you have one telephone, luxury is when you have two, opulence is when you have three--and paradise is when you have none. --Doug Larson |
| 02:35.32 | kpfleming|laptop | mmmm... quad-core opteron |
| 02:36.09 | snuff-work | pretty true.. i have to carry 2 mobiles atm :( |
| 02:37.12 | Corydon76-dig | I could almost get away with carrying none... I rarely receive calls. |
| 02:37.40 | Corydon76-dig | I do like having it around for emergency communication, though |
| 02:38.28 | snuff-work | i must admit i get very few calls.. if one of them rings generally means 'bad stuff' so that one can stay quiet :) |
| 02:43.58 | snuff-work | mm shame bout the new amd.. numbers dont look that impressive vs intel |
| 02:44.40 | JT | actually they seem to kick intel in a number of areas, but it does depend on the application |
| 02:45.37 | Skyelar | I hope they put in more DSP-like instructions.... SSSE3 has some nice toys, but still not enough of them |
| 02:51.01 | snuff-work | mm main thing i've seen is amd had less power draw then intel.. least pre g0 stepping |
| 02:52.48 | snuff-work | Yesterday, Steve Jobs announced to the Apple faithful that those that purchased iPhones before the price drop would be given $100US of in-store credit to the Apple Store |
| 02:58.59 | Corydon76-dig | That's just silly |
| 03:15.21 | *** join/#asterisk-dev tuxd00d (n=tuxinato@128.187.129.156) |
| 03:32.31 | *** join/#asterisk-dev netson99 (n=netson99@202.153.241.206) |
| 03:38.26 | snuff-work | mm is trunk broken atm? |
| 03:38.54 | *** join/#asterisk-dev Juggie (n=Juggie@CPE0013460a7821-CM001371886eee.cpe.net.cable.rogers.com) |
| 03:39.05 | snuff-work | my solaris build not working |
| 03:44.11 | snuff-work | http://www.pastebin.ca/691291 |
| 03:56.12 | snuff-work | damn solaris.. not picking up pthread support it seems.. |
| 03:56.25 | snuff-work | most annonying thing is.. i haven't changed a single package |
| 03:59.08 | snuff-work | mm.. must have changed somethin in my configure.. svn revert = friend |
| 04:06.06 | snuff-work | grr.. |
| 04:06.41 | snuff-work | what gives.. configure script picks it up fine as -pthread.. yet when it gets to that spot in pastebin.. its using -lpthread |
| 04:15.20 | snuff-work | any ideas? |
| 04:20.19 | Juggie | -lpthread should be right? that just means link against the pthread library |
| 04:20.55 | snuff-work | yer.. but in solaris its not.. configure script detects correctly.. as 'pthread' |
| 04:21.22 | snuff-work | not 'lpthread' |
| 04:21.32 | Juggie | l means library. |
| 04:21.38 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 04:21.47 | snuff-work | yer.. but solaris is evil :) |
| 04:22.05 | snuff-work | solaris u must have -pthread NOT -lpthread |
| 04:23.08 | Juggie | are you sure, why would gcc change behaviour in solaris |
| 04:23.17 | snuff-work | it used to work |
| 04:23.33 | snuff-work | works correctly with 1.4.10.. just dies with trunk |
| 04:24.59 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 04:26.11 | *** join/#asterisk-dev docelmo (n=vircuser@c-76-99-153-242.hsd1.de.comcast.net) |
| 04:26.37 | Juggie | is hashtest in 1.4.10? |
| 04:27.01 | docelmo | Say can anyone tell me if the channel structure is passed to cdr_addon_mysql when its called? |
| 04:27.15 | docelmo | Im looking but I only see the cdr struct being passed |
| 04:27.43 | Juggie | docelmo, no, not unless its in the cdr struct |
| 04:27.55 | codefreeze | docelmo: that's theoretically all it needs is the cdr struct... |
| 04:28.23 | docelmo | Ya but I am making it do something it wasnt orignally designed to do and I need access to the channel structure to pull channel variables out |
| 04:28.55 | Juggie | the struct has two channels |
| 04:28.55 | codefreeze | docelmo: then you need to set the cdr variables... |
| 04:29.29 | codefreeze | .... or, at least, the names of two channels... |
| 04:29.34 | docelmo | The variables I am pulling out are not associated with the CDR structure |
| 04:29.43 | docelmo | but I found I can use cdr->channel |
| 04:29.48 | Juggie | codefreeze, i havnt forgotten about no-loss cdr i've just been too busy to even touch it, right now i am on travel for a wedding. |
| 04:29.51 | docelmo | I think |
| 04:29.57 | Juggie | might have some time now before *-con. |
| 04:30.16 | docelmo | no.. crap thats not the structure.. grr |
| 04:30.23 | Juggie | the core is pretty much done, i need to modify some channel drivers. |
| 04:30.26 | Juggie | er, sorry, cdr drivers. |
| 04:30.28 | docelmo | I did it before but I will be damned if I remember how I did it. |
| 04:30.53 | codefreeze | Juggie: its OK, keep hackin' as the opportunities afford...! |
| 04:31.37 | codefreeze | docelmo: don't know what to say.... pack what you need on the CDR when you have the chance... |
| 04:32.13 | Juggie | codefreeze, my wifi router died this week too just after i left |
| 04:32.21 | docelmo | Well I am trying to just make it simple.. basicly once the CDR is about to be cut pull the channel variables out and put them in the insert statement. |
| 04:32.24 | Juggie | so i coudnt access anything at my house :( |
| 04:32.54 | codefreeze | Juggie: sounds so much like "Murphy's Law" to me! ;) |
| 04:33.24 | codefreeze | docelmo: If you have a place to pull the chan vars, copy them to the cdr instead... |
| 04:34.45 | codefreeze | docelmo: life'll go simpler for you if you do. Don't fight the "future"... |
| 04:35.04 | docelmo | Well I am using AGI to populate the variables then pull them back out of the channel with the cdr engine.. The funny thing is I have done this before and I dont remember how the hell I did it. I know I used the channel structure but I dont remember the channel struct not being there |
| 04:35.21 | docelmo | I know I know.. But this is a one off.. And the last think I need to do before the damn project is complete.. :) |
| 04:36.07 | codefreeze | docelmo: yes, I know... so close... yet so far away....! |
| 04:36.15 | docelmo | tell me about it. |
| 04:37.16 | codefreeze | docelmo: somehow, someway, try to imagine the bridge from here to there is.... the struct cdr! |
| 04:37.59 | JunK-Y | Juggie: hotel is reserved for astricon. |
| 04:38.09 | codefreeze | If not the bridge, it's your handy pack animal, with big bags strapped on, ready to carry.... data? |
| 04:38.36 | docelmo | If I rewrote the AGI in C then I would.. but eh.. it would be overkill for what its doing |
| 04:38.59 | codefreeze | docelmo: like my dad often said.... |
| 04:39.06 | codefreeze | "Anything worth doing.... |
| 04:39.15 | codefreeze | " ... is worth over-doing!" |
| 04:40.24 | JunK-Y | wow, we're 9/11 |
| 04:40.44 | Juggie | JunK-Y, cool, mine too |
| 04:41.13 | JunK-Y | that will be great to be there :) |
| 04:42.30 | Juggie | ya for sure... should be fun. |
| 04:43.32 | JunK-Y | i had to fight with a teacher today to miss a mini-exam during astricon. |
| 04:43.40 | Juggie | :( |
| 04:43.47 | Juggie | i had to book the hotel.... twice. |
| 04:44.00 | Juggie | i booked it once @ before it moved, then again after it moved |
| 04:44.11 | Juggie | they were supposed to move over the registrations but they didnt, at least not mine. |
| 04:44.19 | snuff-work | dodgey |
| 04:45.01 | JunK-Y | Juggie: 2 reservations here |
| 04:45.06 | Juggie | ya |
| 04:45.10 | Juggie | for sure |
| 04:45.14 | Juggie | hopefully its a nice hotel |
| 04:45.16 | JunK-Y | one at sokol price, and the other one at more expensive |
| 04:45.29 | JunK-Y | since the numbers of rooms that sokol reserved were full. |
| 04:45.40 | JunK-Y | apparently its close to the desert |
| 04:46.05 | docelmo | Junk-Y, Juggie quick q.. if I use Set(CDR(MyFavoriteSong)=Hero) to set a CDR variable how would I access this variable in C? |
| 04:46.45 | docelmo | since codefreeze has a good point.. |
| 04:47.05 | Juggie | the usual way of reading channel variables i would assume |
| 04:47.10 | Juggie | i dont know the function off the top of my head |
| 04:47.40 | Juggie | JunK-Y, it will be like 35c+ every day |
| 04:48.37 | docelmo | where can I find the doxygen docs for asterisk? |
| 04:48.56 | Juggie | www.asterisk.org/doxygen |
| 04:54.52 | docelmo | thanks J |
| 04:56.19 | JunK-Y | ast_cdr_getvar |
| 04:56.40 | JunK-Y | im not sure you can use CDR(MyFavoriteSong)=Hero thought |
| 04:58.50 | outtolunc | JunK-Y, when i attempted to check room rates earlier today, using the link from astricon.net it said they had no more rooms left (just fyi) |
| 05:02.27 | *** join/#asterisk-dev mog (n=mog@c-71-207-200-130.hsd1.al.comcast.net) |
| 05:02.27 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 05:03.29 | JunK-Y | outtolunc: i know, i booked yesterday |
| 05:03.32 | JunK-Y | call the hotel directly |
| 05:03.40 | JunK-Y | and make a reservations |
| 05:03.50 | JunK-Y | its more expensive, but u will be at the rigth hotel. |
| 05:15.20 | outtolunc | crossing my fingers, things are tight right now, and it seems i need to look for a new job soon. (present company is falling apart) |
| 05:17.42 | outtolunc | hmm shouldn't 'help' info like 'commands' 'short desc' be separated with a delimiter like : |
| 05:19.34 | outtolunc | also, if a user is connected, 'manager show user <user>' info should show the user and being connected (and hopefully with its ip) |
| 05:28.04 | *** join/#asterisk-dev steliosk (n=Stelios@ipa226.211.tellas.gr) |
| 05:37.49 | JunK-Y | outtolunc: isnt already the case for users? |
| 05:45.25 | outtolunc | manager show users is just a 'list of configured' |
| 05:45.46 | outtolunc | manager show connected is 'username' 'ip' of ones currently connected |
| 05:46.09 | outtolunc | manager show user <user> shows user info.. but nothing about if they are currently connected |
| 05:52.25 | outtolunc | nevermind, 2 diff structs |
| 05:56.15 | JunK-Y | correct. |
| 05:56.59 | JunK-Y | maybe we could show live stat (connected or not) in manager show users and connected could disapear one day, whatcha think? |
| 06:03.05 | outtolunc | i think it would be really nice if 'manager show users' would actually show a table summary, including current ip (and hell, mod the session struct and add a timestamp) <G> |
| 06:03.46 | JunK-Y | for previous sessions? |
| 06:03.55 | outtolunc | for active sessions |
| 06:04.17 | outtolunc | so you can determine how long a session has been open |
| 06:04.31 | JunK-Y | so just add the timestamp in fact? |
| 06:05.05 | outtolunc | yes, timestamp would be an add, there isn't one currently (unless i'm blind again <G>) |
| 06:05.32 | JunK-Y | no theres not at this time. |
| 06:05.58 | JunK-Y | but just an int would be better, no? for seconds. |
| 06:06.09 | JunK-Y | like: opened for: 34 sec. |
| 06:07.39 | outtolunc | no biggie on how it is stored, as long as it handles the *usual* time length |
| 06:08.07 | outtolunc | which can be under 1 sec, till heck days |
| 06:08.34 | JunK-Y | so a time_t. |
| 06:09.49 | outtolunc | might as well, since there is a 'timestampevents' option which already gets it that way |
| 06:20.06 | JunK-Y | timestampevents is always for something else. |
| 07:06.59 | JunK-Y | outtolunc: something like: |
| 07:06.59 | JunK-Y | rabbit*CLI> manager show connected Username IP Address Opened flash 127.0.0.1 9 |
| 07:07.10 | JunK-Y | <PROTECTED> |
| 07:07.11 | JunK-Y | <PROTECTED> |
| 07:17.18 | outtolunc | yep |
| 07:24.47 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 07:25.02 | JunK-Y | see my post on -dev |
| 07:33.21 | outtolunc | mine was similar |
| 07:34.58 | *** join/#asterisk-dev Juggie (n=Juggie@wlanportal.aliant.net) |
| 07:37.53 | JunK-Y | good night. |
| 07:38.08 | outtolunc | <PROTECTED> |
| 07:38.08 | outtolunc | <PROTECTED> |
| 07:38.10 | outtolunc | gnight |
| 07:38.48 | JunK-Y | session started is better then opened :) |
| 07:40.23 | outtolunc | next will have session start, and elapsed time |
| 07:42.40 | outtolunc | <PROTECTED> |
| 07:42.40 | outtolunc | <PROTECTED> |
| 07:43.02 | outtolunc | it is a good start, i am getting tired also |
| 07:46.01 | outtolunc | http://dynx.net/ASTERISK/diff-patches/manager.c.sessionstart.diff incase anyone wants to play with it |
| 07:59.57 | *** join/#asterisk-dev dseeb_ (n=dcb@CPE-124-179-242-169.vic.bigpond.net.au) |
| 08:00.15 | outtolunc | updated, for cleaner output |
| 08:02.43 | snuff-work | mm.. outtolunc generally for us to play with code etc you should have a license that's OK on bugs.digium |
| 08:03.28 | outtolunc | k |
| 08:03.57 | outtolunc | probably should clean out that old fiasco crap |
| 08:09.32 | outtolunc | done |
| 08:18.59 | dseeb_ | ~ seen phokz |
| 08:19.00 | jbot | dseeb_: i haven't seen 'phokz' |
| 09:30.20 | *** join/#asterisk-dev qdk (n=qdk@213.150.62.32) |
| 09:30.52 | *** join/#asterisk-dev ManxPower (n=manxpowe@156.sub-75-203-66.myvzw.com) |
| 09:39.21 | *** join/#asterisk-dev ManxPower (n=manxpowe@156.sub-75-203-66.myvzw.com) |
| 09:45.42 | *** join/#asterisk-dev LukinoVoip (n=LukinoVo@gw.abanet.it) |
| 10:21.59 | *** part/#asterisk-dev LukinoVoip (n=LukinoVo@gw.abanet.it) |
| 11:16.53 | *** join/#asterisk-dev michael-i (n=michael-@W9d63.w.pppool.de) |
| 11:58.04 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:02.16 | *** join/#asterisk-dev Shido6 (n=shido6@204.126.120.132) |
| 12:18.48 | *** part/#asterisk-dev dseeb_ (n=dcb@CPE-124-179-242-169.vic.bigpond.net.au) |
| 12:24.47 | *** join/#asterisk-dev HarryR (n=harryr@77.240.56.18) |
| 12:37.15 | *** join/#asterisk-dev agx (n=AGX@88.34.216.63) |
| 12:37.43 | agx | hello, is STUN support in trunk? |
| 13:14.39 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.25.25.53) |
| 13:26.38 | agx | anyone know why snom phones does not resend subscriptions until they are rebooted? |
| 13:30.42 | tzafrir | agx, someone at #asterisk , maybe? |
| 13:33.23 | *** join/#asterisk-dev Corydon76-dig (i=ten@pdpc/supporter/sustaining/Corydon76-home) |
| 13:33.23 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.25.25.53) |
| 13:33.23 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 13:33.23 | *** mode/#asterisk-dev [+oo Corydon76-dig file] by irc.freenode.net |
| 13:33.32 | *** join/#asterisk-dev akirch_ (n=akirch@umcc-pdc.ultimatemedium.com) |
| 13:35.22 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 13:39.19 | agx | tzafrir, will try, will be hard with all that noise |
| 13:39.22 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:39.22 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 13:39.31 | *** part/#asterisk-dev agx (n=AGX@88.34.216.63) |
| 13:44.48 | *** join/#asterisk-dev mog (i=mog@nat/digium/x-0dc59284f58f8dbb) |
| 13:44.48 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 13:57.04 | russellb | Corydon76-dig: i'm looking over your app_queue changes. Is there a good reason to keep the membercount var, or can it simply be replaced with ao2_container_size() (or whatever it is) ? |
| 13:58.27 | Corydon76-dig | Dunno, I'd have to check |
| 13:58.48 | russellb | k, no rush. if they don't have the same meaning, i'd like to document it, that is all. |
| 13:59.04 | Corydon76-dig | I think you're correct, though |
| 13:59.41 | Corydon76-dig | I was kinda focused on making as little changes as possible in 1.4, though |
| 14:00.07 | putnopvut | I wrote the membercount stuff for app_queue. It and ao2_container_count() would be exactly the same. |
| 14:00.13 | putnopvut | It's the number of members logged in. |
| 14:00.23 | russellb | then it isn't the same |
| 14:00.26 | putnopvut | Which is the same as the number of members in memory. |
| 14:00.32 | putnopvut | russellb: actually it is. |
| 14:00.47 | Corydon76-dig | Why wouldn't it be the same? |
| 14:00.48 | *** join/#asterisk-dev davevg-btwtech (n=davevg@nj-67-76-177-147.sta.embarqhsd.net) |
| 14:00.49 | russellb | you can have an agent listed in memory that isn't logged in, right? |
| 14:00.54 | russellb | chan_agent that is |
| 14:01.02 | Corydon76-dig | Not on the queue, no |
| 14:01.03 | putnopvut | They're not in memory. |
| 14:01.15 | russellb | even if you have member => Agent/100 in queues.conf ? |
| 14:01.25 | putnopvut | I'll do a quick check... |
| 14:01.57 | russellb | k, forgive me being pedantic, but i just wanted to give these changes an extra look since i was wanting to do a release fairly soon, and it's of the more invasive changes ... |
| 14:02.48 | Corydon76-dig | One of the reporters on that bug did test it on 5k calls before we applied it... |
| 14:02.57 | russellb | oh, nice |
| 14:03.06 | russellb | thanks for letting me know |
| 14:03.12 | russellb | i should have looked |
| 14:03.36 | Corydon76-dig | No, I was extra paranoid on the invasive change. ;-) |
| 14:04.57 | Corydon76-dig | russellb: you over your cold yet? |
| 14:05.07 | russellb | better than yesterday, but still feeling crappy |
| 14:05.18 | Corydon76-dig | Ah. Best not to share, then |
| 14:05.22 | putnopvut | russellb: My quick test shows you are correct. Agent types will be counted by the membercount even if they are not logged in. |
| 14:05.48 | *** join/#asterisk-dev dioedu (n=dioedu@c915230f.virtua.com.br) |
| 14:05.50 | putnopvut | However, this is incorrect behavior, and it means I should edit membercount. |
| 14:06.01 | putnopvut | So ao2_container_count would actually be more accurate. |
| 14:06.12 | russellb | i don't think so |
| 14:06.29 | russellb | what you're saying is that it is now the same thing as container_count, but you don't want it to be |
| 14:06.46 | russellb | because the agent will be in the container, but you don't want that reflected in the membercount (number logged in) |
| 14:06.50 | snuff-away | <PROTECTED> |
| 14:06.50 | *** join/#asterisk-dev jsmith (n=jsmith@atelka.info) |
| 14:07.00 | putnopvut | russellb: you're right. |
| 14:07.08 | russellb | k, thanks :) |
| 14:07.35 | Corydon76-dig | I dunno, I think worrying about whether an agent is logged in in app_queue violates containerization |
| 14:08.04 | Corydon76-dig | You shouldn't know and it shouldn't make any difference from that vantage point |
| 14:08.11 | putnopvut | Well... |
| 14:08.18 | putnopvut | Here's where it makes a slight difference. |
| 14:08.39 | putnopvut | The membercount is used as an index for how many phones to ring if a person uses rrmemory strategy and the n option |
| 14:09.53 | putnopvut | So if they have agents and regular queue members, it could result in queue members being rung more than once on a call when the n option says that they'll only be rung once. |
| 14:10.30 | putnopvut | Oh, geez, I just noticed the date... |
| 14:10.49 | Corydon76-dig | putnopvut: it's election day here in Nashville |
| 14:11.13 | Corydon76-dig | I get to go choose between Tweedledee and Tweedledum in the runoff race for mayor |
| 14:11.18 | putnopvut | It was 6 years ago in NYC too. |
| 14:12.23 | snuff-away | mm what date.. its just gone 12th here ;) |
| 14:13.34 | snuff-away | mmm.. zzz's going to get the better of me.. |
| 14:14.10 | Corydon76-dig | snuff-work: it's the 6 year anniversary of some Middle Eastern guys making new real estate in NYC |
| 14:14.20 | snuff-away | yes i do remember |
| 14:14.37 | snuff-away | thought it was a movie.. whe i 1st heard |
| 14:14.48 | *** join/#asterisk-dev mog (i=mog@nat/digium/x-93f601d06513c9ea) |
| 14:14.48 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:15.34 | Corydon76-dig | I was already at work and saw the second plane live on camera, and I knew immediately what was up |
| 14:16.12 | russellb | i was in high school, heh |
| 14:16.15 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.104.36) |
| 14:16.23 | snuff-away | if anyone could think of why 'configure' script gets it right with '-pthread' yet when it goes to compile at least 'hashtest' it wants to use '-lpthread' let me know ;) |
| 14:16.56 | russellb | snuff-away: i'll fix in a second |
| 14:17.09 | snuff-away | nice.. didn't know where to fix :) |
| 14:17.50 | Corydon76-dig | snuff-work: odd, I'm still having trouble with flock |
| 14:18.03 | snuff-away | yer.. flock.. i have that one too :) |
| 14:18.09 | snuff-away | u can get around flock.. |
| 14:18.16 | snuff-away | by adding -lucb |
| 14:18.22 | Corydon76-dig | Ah... |
| 14:18.52 | snuff-away | that was the issue i was having the other day :) |
| 14:19.10 | snuff-away | but now it failed earlier |
| 14:19.36 | russellb | forgive this paste bomb, but i am feeling very lazy ..... |
| 14:19.38 | russellb | Index: utils/Makefile |
| 14:19.38 | russellb | =================================================================== |
| 14:19.38 | russellb | --- utils/Makefile (revision 82236) |
| 14:19.38 | russellb | +++ utils/Makefile (working copy) |
| 14:19.41 | russellb | @@ -132,7 +132,7 @@ |
| 14:19.43 | russellb | <PROTECTED> |
| 14:19.46 | russellb | <PROTECTED> |
| 14:19.48 | russellb | <PROTECTED> |
| 14:19.51 | russellb | - $(CC) -g -O0 -o hashtest2 hashtest2.o astobj2.o utils.o md5.o sha1.o strcompat.o -lpthread |
| 14:19.54 | russellb | + $(CC) -g -O0 -o hashtest2 hashtest2.o astobj2.o utils.o md5.o sha1.o strcompat.o $(PTHREAD_LIBS) |
| 14:19.57 | russellb | <PROTECTED> |
| 14:19.59 | russellb | <PROTECTED> |
| 14:20.02 | russellb | try that |
| 14:20.11 | snuff-away | ah.. |
| 14:20.22 | file | dialtone! the dialtone! |
| 14:26.42 | snuff-away | tried that russ.. did no extra's.. you sure 'pthread_libs' is defined in that makefile? |
| 14:27.00 | snuff-away | gcc -g -O0 -o hashtest2 hashtest2.o astobj2.o utils.o md5.o sha1.o |
| 14:27.11 | snuff-away | that's what it did after change ;) |
| 14:27.23 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 14:29.50 | snuff-away | even when i include -pthreads.. still dies same place |
| 14:29.59 | *** join/#asterisk-dev elixer (i=elixer@65.207.74.18) |
| 14:30.03 | russellb | it may not be |
| 14:30.09 | russellb | i can't really look at it right now |
| 14:30.31 | snuff-away | np... least i know i'm not going insane ;) |
| 14:30.58 | russellb | heh |
| 14:31.11 | snuff-away | time for zzz's anyway.. |
| 14:31.13 | snuff-away | The Date is: 12/09/2007 and it is now: 00:31:43 |
| 14:31.17 | russellb | g'night |
| 14:31.28 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 14:31.42 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@c-24-0-209-5.hsd1.nj.comcast.net) |
| 14:31.42 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 14:31.46 | *** join/#asterisk-dev HarryR (n=harryr@77.240.56.18) |
| 14:31.52 | snuff-away | bye all |
| 14:32.05 | file | bweschke: boo! |
| 14:32.13 | bweschke | morning ! |
| 14:34.28 | *** join/#asterisk-dev Laureano (n=chatzill@host172038.metrored.net.ar) |
| 14:35.31 | file | silly jsmith... asking me stuff in front of everyone while I'm reading an email |
| 14:46.15 | russellb | putnopvut: i have another membercount question. |
| 14:46.24 | russellb | i see some code that looks fishy. |
| 14:46.57 | putnopvut | What's that? |
| 14:47.10 | russellb | there are a couple of iterator loops where realtime members are marked as "dead". One of them increments the membercount for *every* member in the container, while the other doesn't touch membercount at all |
| 14:47.24 | russellb | my first guess is that it shouldn't touch it at all ... |
| 14:47.24 | putnopvut | Right. I know what you're talking about. |
| 14:47.35 | russellb | so it's correct? |
| 14:47.38 | putnopvut | Yes. |
| 14:47.42 | russellb | alright, thanks. |
| 14:47.53 | putnopvut | I can explain if you'd like... |
| 14:48.07 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 14:48.08 | codefreeze | russellb: looks like my hashtest2 line in the makefile is giving people the fits? |
| 14:49.18 | russellb | codefreeze: on solaris i think, but i don't know the right fix. the issue is that the pthread CFLAGS/LDFLAGS are different per platform |
| 14:49.46 | russellb | the configure script supposedly checks to find out what the right settings are, but main/Makefile still adds other things, so it's not clear what is right |
| 14:50.03 | russellb | so i wouldn't worry about it right now ... |
| 14:50.23 | codefreeze | but it'd be "righter" if I put in the $(PTHREAD) ref instead, wouldn't it? |
| 14:50.47 | codefreeze | er, PTHREAD_LIBS, I guess... |
| 14:51.56 | russellb | well, i tried that and he said it didn't work ... |
| 14:52.09 | *** join/#asterisk-dev UVSoft (n=jnk467@motorola154-31.ip.PeterStar.net) |
| 14:52.13 | UVSoft | hi there |
| 14:54.24 | UVSoft | does anybody know whether chan_gtalk depends on libjingle from google? |
| 14:54.51 | tzafrir | It doesn't |
| 14:55.37 | UVSoft | hmmm... so how does it work than...? |
| 14:55.45 | UVSoft | without it |
| 14:56.23 | UVSoft | chan_gtalk provides its own implementation of this library? |
| 14:59.32 | *** join/#asterisk-dev lbow (n=lbow@41-195-77-184.access.uunet.co.za) |
| 15:00.30 | jmls_is_awake | hey! stop updating 1.4 - I'm trying to do an up-to-date build here. Every time I finish compiling, some bugger commits another change ! |
| 15:00.34 | jmls_is_awake | ;) |
| 15:13.47 | putnopvut | What did it do? |
| 15:13.58 | russellb | it's not taking dollars |
| 15:14.03 | putnopvut | That jerk! |
| 15:14.09 | Qwell | wiki it! |
| 15:14.13 | russellb | i'm going to post a sign on the machine |
| 15:15.01 | file | "Anyone who wants to insert a dollar into this machine give it to Russell Bryant instead. You may or may not get your beverage." |
| 15:15.28 | Qwell | We could have them mail a SASE to file |
| 15:15.51 | file | Qwell: oh, any update re: Redbull Astricon-stuff? |
| 15:16.04 | Qwell | rockstar? no, he ignored my last email :P |
| 15:16.13 | Qwell | I called his bluff. |
| 15:16.22 | file | lame |
| 15:18.00 | JunK-Y | redbull, hummmm |
| 15:18.42 | *** join/#asterisk-dev ctooley_ (n=ctooley@209.33.109.249) |
| 15:22.20 | bweschke | I don't think I've had a RedBull since Dallas last yr |
| 15:22.21 | bweschke | lol |
| 15:52.22 | *** join/#asterisk-dev Corydon76-dig (n=tilghman@pdpc/supporter/sustaining/Corydon76-home) |
| 15:52.22 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 15:54.40 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 16:08.01 | *** join/#asterisk-dev dlynes (n=dlynes@d154-20-9-152.bchsia.telus.net) |
| 16:10.32 | *** join/#asterisk-dev marta (n=aaa@87.19.202.200) |
| 16:10.37 | marta | hi |
| 16:11.46 | Corydon76-dig | Hi |
| 16:11.56 | Corydon76-dig | Marta, as in Carbone? |
| 16:12.26 | marta | yes |
| 16:12.30 | russellb | hi :) |
| 16:12.41 | marta | :) |
| 16:12.43 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 16:12.43 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 16:12.53 | Corydon76-dig | We love your work |
| 16:12.59 | russellb | you may be the first female to join #asterisk-dev, haha ... |
| 16:13.15 | Corydon76-dig | Nah, Diana of yate used to hang out here |
| 16:13.19 | russellb | ah. |
| 16:13.22 | russellb | but yeah, astobj2 is great |
| 16:13.26 | Qwell | hypa came in here a few times too |
| 16:14.14 | marta | tnx :) |
| 16:14.23 | Corydon76-dig | I suspect Diana still has ops in #asstricks, too |
| 16:15.18 | *** join/#asterisk-dev jtodd (n=jtodd@204.11.231.198.static.etheric.net) |
| 16:16.13 | russellb | marta: when are we having another developer conference in Pisa? :) |
| 16:19.13 | marta | I don't know |
| 16:19.29 | Qwell | you know...I should really get a passport or something |
| 16:20.54 | russellb | Qwell: that would be a good idea. you don't want to scramble to get one when you actually need it. |
| 16:20.58 | Qwell | yeah |
| 16:21.09 | Qwell | they take like 6 weeks to get now, heh |
| 16:21.28 | putnopvut | You can actually bribe the State Department to get it done quicker. |
| 16:21.38 | Qwell | that 6 week figure is with the bribe |
| 16:21.38 | putnopvut | Something like $60 I think. |
| 16:21.42 | putnopvut | Oh. |
| 16:21.51 | Qwell | consumerist.com <3 |
| 16:22.02 | Qwell | http://consumerist.com/consumer/congress/expedited-passports-now-take-3-weeks-to-arrive-not-3-days-291040.php |
| 16:22.03 | Qwell | 3 weeks |
| 16:22.03 | Corydon76-dig | putnopvut: yeah, that's not the overnight bribe... |
| 16:22.30 | Netgeeks | Qwell, Actually the passport folks just recently announced that they had worked through the backlog finally, and the normal wait was back to two weeks, and expedites were good for 2-3 days again |
| 16:22.35 | Corydon76-dig | I'm sure if you pull the right strings, you can get it done overnight |
| 16:22.46 | Qwell | Netgeeks: sure, for now - but they changed the policy |
| 16:23.05 | Netgeeks | there is no better time than now to get one then! ;) |
| 16:23.32 | putnopvut | And they're good for what, 10 years? |
| 16:23.34 | putnopvut | More? |
| 16:23.49 | Qwell | no idea |
| 16:24.21 | Corydon76-dig | The renewal process is supposed to be significantly easier, though |
| 16:24.40 | Qwell | Corydon76-dig: When you did those config changes in trunk recently, to check whether the file has been updated or not... |
| 16:24.54 | Qwell | Corydon76-dig: do you recall changing chan_sip to not destroy peers until after the config was read? |
| 16:24.56 | Netgeeks | yeah, 10 years sounds right, I don't have mine handy to check |
| 16:25.10 | Corydon76-dig | Qwell: I believe so, yes |
| 16:25.14 | Qwell | (I ask, because I may need to pull that sip change back to 1.4) |
| 16:25.26 | Qwell | do you recall having any problems with it? |
| 16:25.43 | Qwell | or recall any others that may have needed to be changed like that? |
| 16:26.02 | Corydon76-dig | I recall that at one point, my sip peers doubled, but when I tried tracking it down, it mysteriously disappeared |
| 16:28.34 | Qwell | What's y'alls (yes, I just said y'alls) opinion on a #include failing? Should it make the rest of the config fail? |
| 16:28.35 | Qwell | M10690 |
| 16:28.38 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/General 0010690: sip peer with missing close bracket causes all subsequent sip peers not to load reported by dtyoo http://bugs.digium.com/view.php?id=10690 |
| 16:29.06 | Qwell | if a #include is malformed, it could potentially lead to some pretty serious problems |
| 16:29.27 | Qwell | simply because you can #include mid-context... |
| 16:31.24 | caio1982 | make the rest of the config fail isn't too much? maybe ignoring that whole context content and logging a error with a 'misformed' message? |
| 16:31.43 | Qwell | for instance... [5555] username=bob #include bobspassword.conf allow=all |
| 16:31.50 | Qwell | if bobspassword is malformed...that could be bad |
| 16:32.35 | Qwell | caio1982: if it's malformed like in the bug above, how do you know when the current context ends and the next begins? |
| 16:34.09 | Qwell | I don't honestly think it should be up to us to figure out what the problem might be, and try to fix it |
| 16:34.23 | Qwell | if we fix it wrong...it will be disastrous |
| 16:36.12 | caio1982 | quite true... but I was assuming the config parser expects a closing bracket after it parsed an opening one, so if it would ignore everything from this point (the wrong closing brackt from the bug report) until it reaches a new context opening bracket... anyway, that could be done but indeed is really hard to prevent such cases and handle it instead of just aborting it all |
| 16:36.32 | Qwell | the difficulty isn't the problem |
| 16:36.45 | caio1982 | the size of the solution i meant |
| 16:37.19 | caio1982 | there are too many ways a config file might be written wrong, if I understood what you said :) |
| 16:37.24 | Qwell | I think I convinced myself on the #include thing.. if one fails, I'm just going to abort |
| 16:37.28 | Qwell | caio1982: yeah, basically |
| 16:37.51 | Qwell | I think the solution he proposed on the bug is the right way to go |
| 17:10.03 | *** join/#asterisk-dev yannj_fr (n=yannj@vpn.intelunix.fr) |
| 17:34.18 | jtodd | I'm surprised there hasn't been any commentary on the Session-Timers stuff for SIP. Damn near every ITSP should be falling over themselves for this patch, since it keeps them from bleeding themselves dry on bogus calls. |
| 17:36.32 | file | jtodd: I'm not... probably just grabbed it, tested it, and didn't bother to comment |
| 17:36.53 | Netgeeks | hey, is there a limit to the macro depth you should or call call? in other words can I safely call a macro, from within another macro ad infintum? |
| 17:37.04 | file | Netgeeks: no, which is why gosub exists |
| 17:37.20 | Netgeeks | :s/or call call/or can call/ |
| 17:38.02 | Netgeeks | Gosub is equivalent to Macro(x,1,2,3)? |
| 17:38.16 | Netgeeks | for depth purposes? |
| 17:38.21 | *** join/#asterisk-dev jsmith (n=jsmith@atelka.info) |
| 17:38.30 | file | I defer that to Corydon* |
| 17:39.06 | Netgeeks | I'm just trying to figure out this stack corruption bug |
| 17:39.33 | file | that sounds like Macro being called too much... but that is not one of my specialty areas I fear |
| 17:45.32 | jsmith | Not that again... |
| 17:46.31 | Corydon76-dig | Netgeeks: Gosub in trunk has arguments |
| 17:46.46 | Corydon76-dig | And yes, you will run out of thread stack space with Macro |
| 17:47.27 | Corydon76-dig | Depending on usage, you may have between 5 and 20 invocations of Macro before it will segfault. |
| 17:47.38 | *** join/#asterisk-dev yannj_fr (n=yannj@vpn.intelunix.fr) |
| 17:47.48 | Corydon76-dig | We therefore limit it to 7, although we're looking into other ways to determine the limit on the fly |
| 17:48.07 | Netgeeks | hrm, I'm not seeing a segfault, I'm seeing corruption |
| 17:48.20 | Qwell | corruption can lead to segfaults |
| 17:48.23 | *** join/#asterisk-dev ctooley_ (n=ctooley@209.33.104.36) |
| 17:48.38 | Qwell | free()ing a corrupted allocation can be bad |
| 17:48.59 | russellb | usually it will just crash if you call a function that runs over the allocated stack space ... |
| 17:49.03 | Corydon76-dig | Right. Realize that what you're doing when you overflow thread stack is overwriting part of another thread's stack |
| 17:51.31 | Netgeeks | this limit does or doesn't apply to gosub? |
| 17:51.36 | russellb | does not |
| 17:51.38 | Qwell | in trunk it does not |
| 17:51.46 | Qwell | well, it doesn't anywhere |
| 17:51.53 | Qwell | but it's not a useful replacement for macro in 1.4 |
| 17:52.09 | Corydon76-dig | I believe codefreeze tested Gosub to something like 20,000 levels with no problems |
| 17:52.25 | Qwell | I think it was more along the lines of 100,000 or 1,000,000 |
| 17:52.37 | Corydon76-dig | Oh, 100,000 then |
| 17:52.44 | Qwell | but, whatever |
| 17:52.57 | Qwell | even 100 is more than anybody should ever need |
| 17:52.57 | Netgeeks | so If I limit my macro depth to 4 in 1.4, I should be safe? |
| 17:53.02 | Corydon76-dig | Beyond the limits of what anybody is likely to do |
| 17:53.07 | Qwell | right |
| 17:53.12 | Corydon76-dig | Netgeeks: hopefully |
| 17:53.13 | Qwell | unless they have a severe logic flaw, heh |
| 17:53.24 | Corydon76-dig | Again, it depends on what all you're doing |
| 17:53.30 | *** join/#asterisk-dev tsurko (n=tsurko@78.90.100.214) |
| 17:53.39 | russellb | recursive algorithms in dialplan ftw |
| 17:54.04 | Corydon76-dig | We've also replaced MacroExclusive in trunk with a dialplan lock |
| 17:54.06 | Netgeeks | well, shit, I'm doing alot of that recursive algorithms too |
| 17:54.15 | tzafrir | hmmm.... why are (almost) all zaptel module parameters non-readable to anybody who's not root? |
| 17:54.35 | russellb | tzafrir: no good reason. |
| 17:54.47 | russellb | tzafrir: feel free to post to the -dev list to make sure nobody disagrees, and then we can changte them. |
| 17:54.55 | Netgeeks | ah, never mind, I'm even getting the corruption in a simple dialplan |
| 17:55.02 | tzafrir | Time for a nice little parameters macro |
| 17:55.10 | russellb | no kidding |
| 17:55.21 | tzafrir | russellb, check the one in xpp |
| 17:55.46 | Corydon76-dig | Netgeeks: number of parameters will also affect the amount of stack used |
| 17:55.58 | tzafrir | <PROTECTED> |
| 17:55.58 | tzafrir | parm: prefmaster:Do we want to be zaptel preferred sync master [default 0] (bool) |
| 17:56.14 | tzafrir | the "default" there is automatically set to the build-time default |
| 17:56.35 | Netgeeks | ah, here is a hint, the corruption only appears to be occuring when I'm in a macro one deep and a leg hangs up, the h extension gets called, and I call a macro from the h, extensions.. corruption randomly occurs here, the macro I'm calling has no args |
| 17:58.42 | Netgeeks | gosub would work fine in that case, since I'm not sending or receiving arguments in the macro I call from the h extension |
| 17:59.29 | Netgeeks | and that thought leads me to another question concerning stack and flow... |
| 18:00.21 | Netgeeks | if a macro is called form some dialplan extension that has an h extension, is the h extension inhereted by the marco or will it be executed on hangup in the macro as we work our way back through the stack? |
| 18:05.33 | Corydon76-dig | When you get a hangup event, every Macro immediately exits |
| 18:05.55 | Corydon76-dig | Not so with Gosub |
| 18:07.37 | jmls | somethings changed with queues and realtime members |
| 18:08.12 | jmls | If I use local channels, "show queue XXX" always shows |
| 18:08.15 | jmls | <PROTECTED> |
| 18:08.33 | jmls | when Agent-09 has answered at least 50 in the current session |
| 18:08.44 | Netgeeks | Corydon76: so currently if you are three deep in macros (and not stack corrupted), you will exit out of them in order, then execute the h extension in the original context that called the first macro? Whereas in gosub, you will execute the h extension in the gosub context? or are you saying something else when you said not so with gosub? |
| 18:08.49 | putnopvut | jmls...hmmm |
| 18:08.52 | jmls | in a previous 1.4, the number of calls was shown |
| 18:09.09 | jmls | it's all working, just the numbers aren't right |
| 18:09.11 | Corydon76-dig | Netgeeks: that's correct |
| 18:09.14 | putnopvut | jmls: what version of 1.4 are you using now? |
| 18:09.28 | jmls | latest svn as of about 30minutes ago |
| 18:09.30 | jmls | :) |
| 18:09.35 | jmls | (1.4 svn that is) |
| 18:09.37 | putnopvut | All right. |
| 18:09.37 | Netgeeks | Corydon76: ah, thanks, that helps alot |
| 18:09.37 | Corydon76-dig | Netgeeks: the difference is that Macro never exits while it is running, whereas Gosub exits immediately |
| 18:09.59 | putnopvut | I'll have a look at it. It could be something I did. |
| 18:10.31 | Corydon76-dig | Gosub saves the return addresses in a linked list in memory, which is how it knows where to return when you execute an explicit Return |
| 18:10.40 | jmls | putnopvut: thanks ;) |
| 18:11.02 | jmls | I suspect you're re-reading the rt members, and cleaning out the stats |
| 18:11.03 | Corydon76-dig | This is also why Gosub doesn't have the issue with recursive calls |
| 18:11.14 | putnopvut | jmls: Quite possibly. |
| 18:11.37 | putnopvut | And this worked properly before? |
| 18:11.57 | jmls | yup |
| 18:12.27 | Netgeeks | And the only problem with Gosub in 1.4, is that you have no arguments available to pass..... Is the gosub space protected or does it share variable space with the main thread? |
| 18:12.48 | putnopvut | jmls: can you recall which version was the latest that worked properly? |
| 18:13.06 | jmls | 77571 works |
| 18:13.18 | jmls | 82240 is broken |
| 18:13.28 | putnopvut | I'll have a look. |
| 18:14.03 | putnopvut | jmls: is the queue realtime or just the members? |
| 18:14.08 | jmls | both |
| 18:14.19 | putnopvut | All right. |
| 18:14.37 | jmls | using an odbc connection |
| 18:15.56 | *** join/#asterisk-dev lbow (n=lbow@41-195-77-184.access.uunet.co.za) |
| 18:21.39 | putnopvut | jmls: just an update. I've reproduced the behavior. using some debug, the call count is being reset on each call but it's not obvious why. |
| 18:21.55 | putnopvut | I have a suspicion, and I'll update when I've confirmed/debunked it. |
| 18:23.58 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 18:25.27 | *** join/#asterisk-dev qdk (n=qdk@0x50c627be.bynxx11.adsl-dhcp.tele.dk) |
| 18:25.32 | *** join/#asterisk-dev agx (n=badpengu@81-174-8-228.dynamic.ngi.it) |
| 18:27.45 | putnopvut | jmls: I believe I have found the revision that caused the problem. |
| 18:27.53 | putnopvut | But I am not sure WHY it caused the problem. |
| 18:28.12 | putnopvut | Corydon76-dig: the member refcounting seems to have caused the problem jmls is talking about. |
| 18:28.48 | Corydon76-dig | Eh? |
| 18:29.23 | putnopvut | Apparently member's calls count is getting zeroed out somehow. |
| 18:29.47 | putnopvut | Wait... |
| 18:29.54 | putnopvut | I may have jumped to conclusions. |
| 18:30.03 | jmls | putnopvut: also the number of seconds since the last call is missing |
| 18:30.06 | putnopvut | Back in a sec. |
| 18:30.06 | mvanbaak | gotta love DST ;) |
| 18:30.14 | Corydon76-dig | Are we talking about trunk or 1.4? |
| 18:30.17 | jmls | mvanbaak: why ? |
| 18:30.19 | jmls | Corydon76-dig: 1.4 |
| 18:30.30 | Corydon76-dig | jmls: dunno why it would do that, then |
| 18:30.34 | putnopvut | Corydon76-dig: I think I'm wrong. |
| 18:30.43 | Qwell | mvanbaak: dang it, I was just going to check that |
| 18:30.46 | Qwell | but my polycom is being stupid |
| 18:30.47 | Corydon76-dig | I figured there might have been a problem with the merge or something like that |
| 18:30.48 | mvanbaak | jmls: http://bugs.digium.com/view.php?id=10531 |
| 18:31.03 | Qwell | Running "sip.ld"... |
| 18:31.05 | Qwell | any time now |
| 18:31.15 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-88-154-177-39.red.bezeqint.net) |
| 18:31.16 | jmls | eeeew |
| 18:31.23 | Qwell | grr, I could have booted this 7970 faster than this |
| 18:31.33 | mvanbaak | Qwell: see, stick to cisco dude |
| 18:31.38 | Qwell | "Welcome!" |
| 18:33.52 | jtodd | file: you might want to add an example or description on that "registertrying" value you just inserted into sip.conf - all you included was the option name. :-) |
| 18:35.11 | russellb | bad file. |
| 18:35.19 | file | at least I put it in CHANGES! |
| 18:35.27 | russellb | tsck tsck! |
| 18:35.48 | jsmith | file: Sure, just act like you don't care about documentation! |
| 18:35.52 | jtodd | yes, at least there was non-zero documentation. |
| 18:36.08 | Qwell | grr, why are packets not making it from my polycom to my desktop? |
| 18:36.14 | Netgeeks | mvanbaak: cisco blows.... ask generalhan why |
| 18:36.17 | jtodd | <grandmother voice> But file, we know you can do so much MORE!</grandmother voice> |
| 18:36.46 | mvanbaak | Netgeeks: I really like my cisco phones |
| 18:38.08 | file | yay |
| 18:38.21 | Netgeeks | I like them too, but cisco as a company..... basically yhey just told generalhan that since he let his 7960 support contract expire, and the phone has been end-of-lifed he can no longer get a contract, and therefore cannot run the updates firmware legally (nor can he download it), even though they will still fix bugs in the code |
| 18:39.29 | *** join/#asterisk-dev roxy_ (n=roxy_@4.249.97-84.rev.gaoland.net) |
| 18:40.01 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 18:40.38 | jtodd | I think that is a foolish Cisco rep that he talked to. The 2501's I have were EOL'ed years ago, but I can still download the software for them with a general account on Cisco's site. |
| 18:42.12 | mvanbaak | jtodd: same here with the 7950 and 7905 |
| 18:42.30 | Qwell | 7950? O.o |
| 18:43.12 | file | I will provide you recipes for said potato for 3 years |
| 18:43.20 | file | and no other potato |
| 18:43.23 | mvanbaak | +10 |
| 18:43.24 | mvanbaak | ;) |
| 18:44.45 | jtodd | But I can buy other potatoes? Deal. |
| 18:45.08 | jtodd | file: thanks for the update to sip.conf |
| 18:45.58 | Corydon76-dig | mvanbaak: what is the output of: hwclock -r --utc |
| 18:46.20 | Corydon76-dig | and is the output your local time? |
| 18:46.41 | mvanbaak | asterisk:~# hwclock -r --utc |
| 18:46.42 | mvanbaak | asterisk:~# |
| 18:46.53 | Corydon76-dig | Huh? |
| 18:47.00 | mvanbaak | xen domU |
| 18:47.08 | Corydon76-dig | Oh, weird |
| 18:47.17 | mvanbaak | no hwclock :) |
| 18:47.31 | Corydon76-dig | What does it output on your base system? |
| 18:47.38 | mvanbaak | and yes, I'm in Europe/Amsterdam |
| 18:47.52 | roxy_ | Hi, I want to install ldap auth on asterisk 1.4.11. I download debian source, copied res_config_ldap.c into it, but but can't compile because of incompatibility in other functions. What would be the proper way to do ? |
| 18:48.09 | mvanbaak | Ifrid:~# hwclock -r --utc |
| 18:48.10 | mvanbaak | Tue 11 Sep 2007 08:47:23 PM CEST -0.384431 seconds |
| 18:48.10 | mvanbaak | Ifrid:~# |
| 18:48.18 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.109.249) |
| 18:48.18 | file | jtodd: you may not. |
| 18:48.19 | mvanbaak | Ifrid:~# date |
| 18:48.19 | mvanbaak | Tue Sep 11 20:48:13 CEST 2007 |
| 18:49.21 | Corydon76-dig | Okay, can't use that to discover the difference, then |
| 18:49.36 | Corydon76-dig | mvanbaak: I can't replicate the issue on my systems |
| 18:49.49 | mvanbaak | all xen domU's and my base system use ntp to sync time with ntp.bit.nl |
| 18:50.01 | mvanbaak | timezone on all systems is Europe/Amsterdam |
| 18:50.01 | Qwell | Corydon76-dig: for some reason, ${STRPTIME()} appears to deadlock asterisk on me O.o |
| 18:50.12 | Corydon76-dig | Eh? |
| 18:50.29 | Qwell | using the example junky posted on the bug is...ugly |
| 18:51.45 | mvanbaak | I used the sample he posted in his last comment |
| 18:51.56 | Corydon76-dig | mvanbaak: as did I |
| 18:52.20 | jmls | stupid question, maybe, but what does " Blocking in: ast_waitfor_nandfds" mean in a zap call that seems to be hung ? |
| 18:52.23 | Corydon76-dig | I don't know what the difference is, but I'm getting the same results on Mandriva and Ubuntu |
| 18:52.31 | mvanbaak | both before and after the patch it tells me 11:23 pm |
| 18:52.42 | jmls | sorry, that's from "show channel zap/33-1" |
| 18:52.57 | Corydon76-dig | mvanbaak: I wouldn't mess with the patch, since it made no difference |
| 18:52.58 | mvanbaak | I dont have asterisk on OpenBSD right now, so cant test there |
| 18:53.24 | mvanbaak | I can compile it on OpenBSD tomorrow if you want me to test it there |
| 18:53.50 | Corydon76-dig | Well, it doesn't seem to have anything to do with platform, but with something within the platform |
| 18:54.07 | Corydon76-dig | You're welcome to try to track down what the difference is, though |
| 18:54.11 | jmls | sorry for A) wrong window |
| 18:54.14 | jmls | B) being stupid |
| 18:54.21 | mvanbaak | Corydon76-dig: then I will test it |
| 18:54.32 | mvanbaak | my OpenBSD boxen use Europe/Amsterdam as well |
| 18:54.42 | Qwell | 1187828639 is 22:23:59 GMT-2:00 |
| 18:54.54 | Qwell | surely America Montreal isn't GMT-2:00 |
| 18:54.55 | jmls | my test system is playing music to a voicemail box. Which I presume is waiting for the "music" extension to hang up |
| 18:54.57 | jmls | heh |
| 18:54.58 | Corydon76-dig | Qwell: can you reproduce? |
| 18:54.59 | Qwell | America/Montreal rather |
| 18:55.07 | Qwell | not with the strptime... |
| 18:55.13 | Qwell | I mean, I can't even test that |
| 18:55.30 | Corydon76-dig | Qwell: dunno why not |
| 18:56.00 | Qwell | date -d "2007-08-22 22:23:59 GMT-2:00" +%s |
| 18:56.00 | Qwell | 1187828639 |
| 18:57.00 | putnopvut | Corydon76-dig: bad news. After testing several revisions, it appears that 82155, the revision where queue members started being refcounted IS the revision which is causing member stats to be cleared on each call. |
| 18:57.15 | Corydon76-dig | Sweet |
| 18:57.17 | putnopvut | And no, I'm not sure why. |
| 18:57.22 | *** join/#asterisk-dev yannj_fr (n=yannj_fr@vpn.intelunix.fr) |
| 18:57.24 | *** join/#asterisk-dev denon (n=denon@208.122.43.201) |
| 18:57.39 | roxy_ | was there a stable release after ast_variable_new went from 2 to 3 args ? |
| 18:58.09 | russellb | roxy_: no |
| 18:58.26 | Corydon76-dig | In fact, it's still 2 args in 1.4 |
| 18:58.42 | russellb | roxy_: res_config_ldap is not supported at all |
| 18:58.51 | russellb | there is a good reason it still hasn't made it into trunk :) |
| 18:58.58 | russellb | much less a release |
| 18:59.53 | russellb | i went through and re-wrote half of the module but lost the desire to work on it. |
| 19:00.22 | roxy_ | russellb: so the only way is to compile the group branch ? (and not think about puting the result into prod ) |
| 19:00.43 | russellb | you can try putting it into production, but just don't expect much help if you have a problem .. |
| 19:01.13 | russellb | i don't meant to be rude, i'm just trying to make sure you know exactly what you're getting in to |
| 19:01.24 | russellb | s/meant/mean/ |
| 19:01.34 | jmls | putnopvut: would "if (mem->calls)" work if the number of calls was > 1 ? |
| 19:01.44 | russellb | jmls: yes |
| 19:01.57 | russellb | jmls: that's the same as if (mem->calls != 0) |
| 19:02.21 | jmls | yeah, I would like to see if (mem->calls > 0) :) |
| 19:02.32 | Qwell | Corydon76-dig: I may be able to reproduce O.o |
| 19:02.43 | Qwell | 1187828639|America/Montreal is giving me 8:23pm |
| 19:02.44 | roxy_ | russellb: I am just trying to get a proof of concept for integrating asterisk/webhuddle in our esb. I am no sys ad or C programer so not a chance I put it into prod. Would the group branch be able to run ? |
| 19:03.06 | russellb | roxy_: it should run, yeah |
| 19:03.22 | roxy_ | russellb: ok, thanks for your help |
| 19:03.28 | russellb | np |
| 19:04.20 | Corydon76-dig | Qwell: I get 8:23 as well |
| 19:04.32 | Qwell | he's claiming it should say 7 |
| 19:06.43 | Corydon76-dig | Okay |
| 19:06.44 | Qwell | oh, he's saying the problem is in strptime |
| 19:13.07 | Qwell | looks like it's hanging inside ast_mktime() or something... |
| 19:13.23 | Corydon76-dig | Sweet |
| 19:13.39 | Corydon76-dig | on what, though? |
| 19:13.46 | Qwell | haven't gotten that far yet |
| 19:14.57 | *** join/#asterisk-dev russellb (i=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 19:14.57 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 19:15.09 | Qwell | time1(), heh |
| 19:15.37 | Corydon76-dig | putnopvut: I wonder if the realtime queue member is getting destroyed after each call |
| 19:15.52 | Corydon76-dig | putnopvut: that would certainly reset the stats |
| 19:16.30 | *** part/#asterisk-dev agx (n=badpengu@81-174-8-228.dynamic.ngi.it) |
| 19:16.32 | *** join/#asterisk-dev blitzrage (i=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:17.13 | Corydon76-dig | putnopvut: according to the code, the queue gets destroyed when the last caller leaves |
| 19:18.10 | Corydon76-dig | and that would certainly blank out the stats |
| 19:18.22 | Corydon76-dig | blitzrage: ping |
| 19:18.32 | jmls | Corydon76-dig: I have callers waiting in the queue when I see this problem |
| 19:18.33 | blitzrage | Corydon76-dig, pong |
| 19:18.50 | Corydon76-dig | blitzrage: do you also have an inking irregularity on pages 552, 558? |
| 19:19.04 | blitzrage | Corydon76-dig, hrmm... I don't have my copy here unfortunately |
| 19:19.04 | yannj_fr | shoudl I always use ast_copy_string instead of strcpy ? |
| 19:19.16 | Corydon76-dig | blitzrage: also, there's an error in the chart on page 279 |
| 19:19.44 | russellb | yannj_fr: in most cases, yes |
| 19:19.47 | Corydon76-dig | yannj_fr: No. You should always use ast_copy_string in place of strncpy |
| 19:20.11 | putnopvut | Corydon76-dig: So it sounds like for realtime queue members, we should probably put some logic in the destructor to write stats to realtime. |
| 19:20.12 | Corydon76-dig | strcpy is fine when you've specifically sized the buffer to accomodate all of the data |
| 19:20.26 | Corydon76-dig | putnopvut: that's what I'm thinking |
| 19:20.47 | putnopvut | Which, conveniently enough, there is a simple function to call to do such a thing now :) |
| 19:20.55 | putnopvut | update_realtime_member_field |
| 19:21.09 | jmls | putnopvut: if I have callers waiting, why would the queue be destroyed ? |
| 19:21.19 | putnopvut | It's not the queue, it's the member. |
| 19:21.28 | yannj_fr | ok but in this case I need to declare a dst char [] with fix lenght instead of char* ?? |
| 19:21.42 | jmls | so why is the member being destoyed every tine ? |
| 19:21.44 | jmls | (time) |
| 19:21.53 | putnopvut | That I'm not so sure about. |
| 19:21.59 | putnopvut | Oh, I know. |
| 19:22.03 | jmls | ;) |
| 19:22.20 | jmls | isn't that not efficient ... |
| 19:22.24 | putnopvut | Wait, it shouldn't though. |
| 19:22.36 | putnopvut | Becaues the container should still have a reference. |
| 19:23.07 | putnopvut | I'm going to add some debugging and see what's going on. |
| 19:24.34 | Corydon76-dig | jmls: are these members stats that are getting lost or queue stats? |
| 19:25.19 | putnopvut | Corydon76-dig: they're member stats. |
| 19:28.59 | putnopvut | The member isn't getting destroyed every time. |
| 19:29.35 | Qwell | Corydon76-dig: while (days < 0 || days >= (long) year_lengths[yleap = isleap(y)]) { |
| 19:29.46 | Qwell | I think that's where it's looping... |
| 19:30.23 | Corydon76-dig | Qwell: ack, two different problems |
| 19:40.39 | Corydon76-dig | Qwell: if you run a compile test of sizeof(time_t), what do you get? |
| 19:40.53 | Qwell | let's see |
| 19:41.40 | Qwell | 8 |
| 19:43.11 | Corydon76-dig | Aha |
| 19:43.41 | Corydon76-dig | I know what the problem is |
| 19:43.46 | Qwell | excellent |
| 19:43.55 | Corydon76-dig | it'll just take a little while to fix it |
| 19:45.01 | Qwell | want me to create a bug? |
| 19:47.21 | Corydon76-dig | It's 64-bit related. I just need to go to the source and apply all the fixes they've already applied |
| 19:47.31 | Qwell | ahh.. |
| 19:53.45 | blitzrage | I'm having an issue where a customer is getting hung channels on my system for some reason. One of the channels I'm looking at is in a state of: Blocking in: ast_waitfor_nandfds, and has an uptime of 97 hours. The state is Down (0), but Asterisk isn't destroying it for some reason. Any suggestions of where to look to debug this? |
| 19:55.37 | jsmith | blitzrage: SIP channel by chance? |
| 19:55.54 | blitzrage | We have multiple vPBX's on this box, and only this customer is getting these hung channels it seems... so it maybe is something to do with the way they are replying to the msg's? |
| 19:56.00 | blitzrage | jsmith-teaching, of course SIP :) |
| 19:58.13 | Netgeeks | blitzrage: are you using reinvites? |
| 20:02.10 | Netgeeks | we've had stuck channels on 1.4 due to a bad (out of order) response from one of our carriers, resulting in asterisk getting a re-invite with no media description, and the channel would get stuck, and we'd see a message on the ui about a bye for a channel that no longer exists... |
| 20:02.50 | Netgeeks | we eventually just turned off re-invite for that endpoint, and it fixed everything.. dunno if that has anything to do with what you are seeing |
| 20:03.58 | blitzrage | Netgeeks, hrmmmm... I have seen that bad BYE message before as well. But this customer has NAT enabled and reinvites off.... although I do have P2P enabled |
| 20:04.12 | blitzrage | but canrenvite=no is on for the peer's phone |
| 20:04.47 | Netgeeks | okay, seems like not the same |
| 20:05.13 | blitzrage | I guess I need to destroy these channels and turn SIP history on to see if I can find out what the issue is... |
| 20:05.50 | blitzrage | I wish a ray gun was an option at this point :) |
| 20:06.09 | blitzrage | technically I'm on sabbatical, but no one else is around to deal with the issue -- luckily I have Internet access and a computer today :) |
| 20:06.21 | Qwell | luckily... |
| 20:06.22 | blitzrage | well... 'luckily' is relative I guess, hehehe |
| 20:06.25 | Qwell | :p |
| 20:06.57 | jcmoore | doesn't being needed feel nice? |
| 20:07.20 | blitzrage | jcmoore, baskets of wine and muffins are nicer though |
| 20:07.43 | blitzrage | at least I have this mamosa |
| 20:09.19 | Netgeeks | debugging + sip history + mamosa = danger |
| 20:09.29 | putnopvut | Don't drink and SIP. |
| 20:09.38 | Qwell | Don't <anything> and SIP |
| 20:10.43 | codefreeze | so, the opposite of SIP is CHUG? |
| 20:11.06 | file | I feel like I'm in school again |
| 20:11.46 | Netgeeks | because of the momosa? |
| 20:16.22 | yannj_fr | file : this is not a shame to be in school ! |
| 20:22.58 | *** join/#asterisk-dev deeperror (n=deeperro@69-215-202-195.ded.ameritech.net) |
| 20:23.47 | deeperror | anyone familiar with zt_exception and why it would get caught into an endless loop filling log files in minutes? |
| 20:23.55 | deeperror | from chan_zap.c |
| 20:26.59 | tzafrir_laptop | endless loop or actually many events get sent? |
| 20:27.14 | deeperror | well it seems to get stuck at the very bottom of the function |
| 20:27.28 | deeperror | We're Zap9-1 Not !@#! |
| 20:27.43 | deeperror | and when i look at the logs the junk after Not is crazy characters not really ascii |
| 20:28.24 | deeperror | something like this |
| 20:28.25 | deeperror | http://pastebin.ca/692375 |
| 20:28.29 | *** join/#asterisk-dev festr_ (n=festr@ns.regnet.cz) |
| 20:28.31 | deeperror | but 1000+ lines a second |
| 20:29.02 | festr_ | hello, in my logs there are a lot of "Attempted to delete nonexistent schedule entry 0!". is it bad? it starts around 1.4.11 |
| 20:29.20 | deeperror | and sometimes it shows in the line We're Zap9-1 Not 8001231234 with the number being what I set as my CID |
| 20:29.35 | Qwell | deeperror: are you using the latest versions of asterisk and zaptel? |
| 20:29.53 | deeperror | zap was 1.2.19 just updated to 1.2.20.1 |
| 20:30.08 | deeperror | everything else is current |
| 20:30.10 | deeperror | 1.2.24 |
| 20:30.14 | Qwell | 1.2 isn't supported anymore.. |
| 20:30.29 | deeperror | when i went to 1.4 i had more issues than this |
| 20:30.36 | Qwell | Did you report them? |
| 20:31.16 | tzafrir_laptop | Qwell, I believe that there's an open bug for this. I can't recall |
| 20:31.20 | deeperror | they seemed to be issues related to service provider and equipment and how they worked with 1.4 |
| 20:31.34 | deeperror | i saw someone else with the same issue from 2004 but it was closed with no resolution |
| 20:31.58 | deeperror | i think it has something to do with 3way calling |
| 20:32.31 | deeperror | some combination of callee hanging up during a transfer but i'm unable to duplicate it...just happens after a few hours of running |
| 20:32.34 | tzafrir_laptop | I think it is somehing related to a rather bad state machine in some cases in 1.2, and greatly improved in 1.4 |
| 20:32.45 | deeperror | very hard to get any debug info from cli it fills my buffer to max in seconds |
| 20:33.43 | deeperror | is there anyway to get better or more verbose debugging into messages or any file that could help to see what this might be? |
| 20:33.47 | tzafrir_laptop | deeperror, do you notice runing channels that are listed in state "Ringing" well after the call has started? |
| 20:33.53 | deeperror | or do you just suggest to upgrade to 1.4 and go from there |
| 20:34.03 | snuff-away | you can def log it in /var/log/asterisk.. |
| 20:34.15 | tzafrir_laptop | If you have an easy way to test 1.4, try |
| 20:34.16 | snuff-away | just forget where the optionis.. think its in 'logger.conf' |
| 20:34.51 | deeperror | snuff-away: good one there i'll look into that more |
| 20:35.05 | deeperror | i have 3 agents that run on it all day |
| 20:35.14 | deeperror | so i'll run back to 1.4 configuation and see how that works tomorrow |
| 20:35.45 | deeperror | i've updated to 1.2.20.1 just a few minutes ago and haven't had the issue so i'm gonna see if that fixed it any |
| 20:35.49 | deeperror | if not i'll be @ 1.4 |
| 20:46.32 | blitzrage | Netgeeks, which version of Asterisk are you running per chance? Are you still seeing those hung channels on 1.4.11? (although you said you're not seeing them anymore since you turned off reinvites) |
| 20:47.14 | jtodd | <beep> Netgeeks will be with you in just a moment, as soon as the QA people leave his office. <beep> |
| 20:47.16 | Netgeeks | I saw them on 1.4.5. |
| 20:48.13 | Netgeeks | We upgraded to 1.4.11 and I tried testing wthe issue, but I ran into the far more serious macro stack corruption issue, and didn't have a chance to test the sip reinvite issue |
| 21:00.39 | putnopvut | jmls_sleeping: I think I found the issue with the realtime stats getting reset. |
| 21:00.47 | putnopvut | Sorry to find it right as you start sleeping. |
| 21:01.15 | putnopvut | When you wake up, it should be working properly. |
| 21:08.16 | snuff-away | gotta love that an issue gets fixed and all you have to do is sleep on it :) |
| 21:30.51 | *** part/#asterisk-dev deeperror (n=deeperro@69-215-202-195.ded.ameritech.net) |
| 21:38.29 | Corydon76-dig | Holy monkeys, there's a bug in glibc's strptime |
| 21:38.50 | Corydon76-dig | It's not setting tm_isdst correctly |
| 21:41.34 | file | wow, really? |
| 21:42.34 | codefreeze | "Holy Monkeys"? no cows, etc? |
| 21:42.45 | Qwell | what? |
| 21:42.59 | Qwell | Corydon76-dig: seriously? is that what's causing my problem? |
| 21:43.21 | Qwell | or, junkys? |
| 21:43.30 | blitzrage | jtodd, :D |
| 21:43.38 | blitzrage | jtodd, you gonna make it to AstriCon this year again? |
| 21:43.45 | Qwell | blitzrage: he better :D |
| 21:43.53 | Qwell | in fact, he should also /j #astricon |
| 21:43.57 | Corydon76-dig | Qwell: not all of it, but that's a good part of it |
| 21:44.09 | blitzrage | oh ya? is he being advertised to speak? :) |
| 21:44.10 | Corydon76-dig | Qwell: your problem is that you're running on 64-bit, primarily |
| 21:44.13 | Qwell | oh |
| 21:44.20 | Qwell | blitzrage: dunno, but he better go :p |
| 21:44.26 | blitzrage | indeed! |
| 21:44.34 | blitzrage | if jtodd isn't going, I'm not going either |
| 21:44.44 | Qwell | if blitzrage isn't going, then...well, I'm still gonna go |
| 21:44.55 | Qwell | but I will make some idle threats! |
| 21:44.57 | blitzrage | speaking of going... I'm outta here :) |
| 21:45.09 | blitzrage | peas out homies |
| 21:45.20 | file | be gone |
| 21:46.58 | *** join/#asterisk-dev Stormfr (n=Stormfr@sgc91-2-82-237-76-2.fbx.proxad.net) |
| 21:52.44 | *** join/#asterisk-dev Stormfr (n=Stormfr@sgc91-2-82-237-76-2.fbx.proxad.net) |
| 22:15.26 | snuff-work | codefreeze: if u want to help me fix that solaris compile of 'hashtest' i'm availible for 30min |
| 22:15.44 | Netgeeks | blitzrage: jtodd is going to astricon this year |
| 22:16.00 | codefreeze | snuff-work: your'e on! what can I do? |
| 22:16.33 | snuff-work | k basically it doesn't seem to matter if i have '-pthreads' it still throws same error as in the pastebin |
| 22:16.48 | snuff-work | http://www.pastebin.ca/691291 |
| 22:17.08 | snuff-work | how should we go bout getting more info from gcc etc? |
| 22:17.51 | file | that's an old copy |
| 22:18.37 | snuff-work | old copy as in svn or? |
| 22:18.43 | file | svn |
| 22:19.15 | snuff-work | k will update again |
| 22:20.09 | codefreeze | snuff-work: what gcc --version say? |
| 22:20.21 | snuff-work | its 3.4.6 from memory |
| 22:21.16 | snuff-work | 3.4.3 |
| 22:21.31 | codefreeze | half of it is the inet_ptoa, etc., and is from two very common things included in the link line in solaris, but I can't remember what they are. -lsomething and -lsomething. |
| 22:21.41 | snuff-work | now it still has errors.. only with gethosybyname_r and inet_pton/ntop |
| 22:21.56 | file | progress. |
| 22:22.46 | codefreeze | I've played with solaris for years, but it was years since I've toyed. Can't remember those two -l opts...! Let me go look. |
| 22:24.05 | Qwell | -lsocket and -lnsl? |
| 22:24.46 | snuff-work | worked now :) |
| 22:25.22 | codefreeze | Bingo!!! Throw Qwell a couple tasty muffins!!! |
| 22:26.01 | codefreeze | Is there any useful way to make sure those are included in a solaris link? |
| 22:26.37 | codefreeze | In other words, oh, you build experts, what var are these hidden in? |
| 22:26.58 | Qwell | codefreeze: in asterisk, ASTCFLAGS |
| 22:27.08 | Qwell | erm, maybe |
| 22:27.22 | file | that stuff is still involving Makefile magic |
| 22:27.51 | Qwell | AC_SEARCH_LIBS(gethostbyname_r, [socket nsl]) |
| 22:27.51 | codefreeze | Right, this is in the utils/Makefile, that we need to put this magic var, on the link line... |
| 22:28.55 | Qwell | it looks like it's adding it to LIBS |
| 22:31.06 | codefreeze | I added $(LIBS) to the gcc cmd in utils/Makefile, in non-solaris env, and it was empty. So the link goes OK in non-solaris-ville. |
| 22:31.43 | codefreeze | so, snuff-work, try adding $(LIBS) to your gcc cmd for hashtest2 and see if you can build.... |
| 22:33.08 | snuff-work | k |
| 22:34.48 | snuff-work | hash compiled :) |
| 22:35.45 | codefreeze | snuff-work: OK, I'll commit this then, and we hopefully have it solved! |
| 22:36.23 | snuff-work | mm least this one is.. now to fix other issue i think i know how to fix it |
| 22:38.04 | codefreeze | oops. darn it. gotta back out config.c |
| 22:38.48 | bmd | codefreeze: I'm curious to see what the performance differences between astobj and hashtab turn out to be. Any conclusion on that yet? |
| 22:39.48 | codefreeze | bmd: I suspect some obscure, but solveable prob in the astobj2 locking. I'm sure they'll solve it and then there won't be much diff. |
| 22:40.34 | russellb | codefreeze: question about your test ... are you keeping the container locked around the entire traversal in both cases? |
| 22:40.37 | bmd | yeah, I anticipate it being some sort of novel, "I didn't know that!", sort of thing |
| 22:41.14 | russellb | by default in astobj2, you don't have to keep the container locked for the entire duration of a traversal |
| 22:41.35 | russellb | also, if you have a lot of adds/removals during the traversal, the speed of the traversal will suffer |
| 22:41.45 | russellb | (in the case where you don't keep it locked) |
| 22:41.47 | codefreeze | russellb: you mean my test of astobj2? no, I don't do any explicit locking. I just create the tab, add, del, search, and traverse the living scrud out of it. |
| 22:42.22 | codefreeze | russellb: any locking, is internal to the operation of the astobj2 stuff. |
| 22:42.26 | russellb | right |
| 22:42.41 | russellb | but if you wanted to keep the container locked for the duration of the traversal, you could do so |
| 22:42.49 | russellb | anyway, i'll just look at your test code later |
| 22:44.01 | codefreeze | russellb: I'm sure I could; but the test doesn't need anything explicit. I don't think, anyway. If there were a prob, usually things will just crash. |
| 22:44.35 | codefreeze | or lock. |
| 22:44.43 | russellb | i suspect that is where the speed difference comes from |
| 22:44.59 | russellb | in the hashtab version, the traversal has the container locked for the entire duration |
| 22:45.08 | russellb | as opposed to only for a short time while getting the next element |
| 22:45.17 | russellb | let me try something in hashtest2 real quick... |
| 22:45.49 | Qwell | codefreeze: there was a bit of "extra" stuff in your commit |
| 22:45.55 | codefreeze | true, but hashtabs run 52-53 sec on my machine, whether a read-lock or write-lock was taken; |
| 22:45.56 | Qwell | stuff in config.c |
| 22:46.08 | Qwell | oh, nevermind, you already said that |
| 22:46.21 | codefreeze | Qwell: ugh, got carried away. I'll back that out real quick. sorry. |
| 22:46.52 | marta | I've tried to use a callback instead of the iterator, and it's better |
| 22:47.59 | marta | and el = ao2_find(glob_hashtab, &lookup, OBJ_POINTER | OBJ_UNLINK); to find and unlink (avoiding to lock the container two time in hashtest2) |
| 22:49.12 | Qwell | marta: you're one of Rizzo's students or something, right? |
| 22:49.22 | Qwell | because if so, you should totally get an A :p |
| 22:49.22 | russellb | Qwell: correct |
| 22:51.26 | codefreeze | marta: has my little test helped? I was hoping it would. |
| 22:52.46 | marta | yes, I am |
| 22:52.54 | marta | codefreeze: are you murf? |
| 22:53.00 | codefreeze | somebody beat me to fixing config.c. Just what I wanted, except I wanted to add a comment about the code I didn't back out... oh, well... |
| 22:53.08 | codefreeze | marta, yes, I am murf |
| 22:53.19 | JunK-Y | mr. murphy! |
| 22:53.47 | marta | codefreeze: yes, it helped so much :) |
| 22:54.02 | codefreeze | marta: excellent! |
| 22:54.24 | marta | I'm doing some test to improve the iterator, but until now no good news :) |
| 22:55.23 | codefreeze | marta: sleep on it... sometimes inspiration for problems hit me as I'm waking up... :) |
| 22:55.36 | JunK-Y | marta: just for curiosity, whats the topic for ur thesis? |
| 22:58.02 | marta | JunK-Y: efficient data structure for asterisk |
| 22:58.49 | JunK-Y | great, that will be great to read this when completed. |
| 22:59.41 | codefreeze | Bless Luigi and Marta! He who thinks a good hash table in a multi-threaded env is easy, is not thinking! |
| 23:01.06 | codefreeze | The whole community will gain great advantage by your work, Marta! |
| 23:01.30 | marta | JunK-Y: but it's already finished (one years ago) and I'm sorry but it's in italian. But it describes the astobj2 structure and some example of use |
| 23:03.40 | marta | it's time to sleep, see you |
| 23:04.10 | Corydon76-dig | marta: come on back, it's good to have you here |
| 23:04.11 | JunK-Y | marta: i left all my italian in my other life :) |
| 23:04.22 | JunK-Y | yeah, take it easy marta. |
| 23:04.58 | JunK-Y | Corydon76-dig: regarding the bug with STRPTIME, try to set ur timezone to NY, you will see. |
| 23:05.23 | Corydon76-dig | JunK-Y: Not with the current code. I'm working on updating it |
| 23:05.28 | codefreeze | marta: some of that iteration time was because of internal walking: when I reduced the table size from like 800K to 180K, the traversal time dropped a few minutes. |
| 23:06.01 | Corydon76-dig | JunK-Y: I can reproduce the error after I update the imported code to current, but I'm messing with that right now |
| 23:06.06 | JunK-Y | Corydon76-dig: excellent news boy! |
| 23:07.05 | Corydon76-dig | Basically, I ran the patches and I got the error, but I couldn't figure it out, so I'm running a full import |
| 23:07.16 | marta | I will do other test tomorrow, thanks |
| 23:07.23 | Qwell | import of what, the localtime stuff? |
| 23:07.51 | Corydon76-dig | Correct, I'm getting the latest source from the US govt |
| 23:07.59 | JunK-Y | Qwell: were taling about 10531 |
| 23:08.01 | JunK-Y | M10531 |
| 23:08.04 | Qwell | yeah, I know |
| 23:08.06 | MuffinMan | [new] [Asterisk] Core-General 0010531: bug in time-zone with daylight saving time reported by junky http://bugs.digium.com/view.php?id=10531 |
| 23:08.12 | Qwell | Corydon76-dig: Is that who wrote that? O.o |
| 23:08.28 | Corydon76-dig | Yeah, it's the reference implementation for timezone support |
| 23:08.32 | Qwell | neat |
| 23:08.51 | Corydon76-dig | plus the stuff I added to support multiple zones at once |
| 23:08.52 | Qwell | I suppose if they maintain the timezone files, they should also have code for it... |
| 23:08.54 | JunK-Y | Qwell: have you been able to reproduce it? |
| 23:09.00 | Qwell | JunK-Y: no, I found a different bug, heh |
| 23:09.04 | Qwell | infinite loop ;) |
| 23:09.17 | JunK-Y | on which specific test? |
| 23:09.27 | Qwell | just using strptime |
| 23:09.49 | JunK-Y | Qwell: no beer for corydon huh! |
| 23:10.26 | Qwell | it's in the localtime stuff |
| 23:10.29 | *** join/#asterisk-dev ssokol (n=ssokol@216.64.24.250) |
| 23:10.35 | Qwell | so, in theory, if he updates everything, it'll fix my problem too |
| 23:10.39 | JunK-Y | btw, qwell 10661 isnt related to the one you thought. |
| 23:10.49 | Qwell | M10661 |
| 23:10.50 | MuffinMan | [new] [Asterisk] Core/PBX 0010661: [patch] fix the redirect thru the ami reported by junky http://bugs.digium.com/view.php?id=10661 |
| 23:10.53 | Qwell | oh, yeah |
| 23:11.03 | Qwell | and that branch isn't gone, it's in group |
| 23:11.35 | JunK-Y | great, maybe we can update it at astricon, together, whatcha think? |
| 23:11.46 | JunK-Y | to support the new ast_verb() and ast_debug() macros. |
| 23:12.07 | Corydon76-dig | Qwell: I know that your problem will be fixed, and now that I've reproduced the issue in the bug, that will be fixed, too |
| 23:12.13 | Qwell | k |
| 23:12.15 | Qwell | cool |
| 23:12.29 | Qwell | I wonder why nobody has run into it before |
| 23:12.45 | Qwell | ast_mktime is used in a bunch of places, isn't it? |
| 23:13.10 | JunK-Y | Corydon76-dig: let me know when you get it done, will test that on some machine here. |
| 23:13.17 | *** part/#asterisk-dev bweschke (n=BJ_Wesch@c-24-0-209-5.hsd1.nj.comcast.net) |
| 23:13.35 | Qwell | oh, maybe it isn't |
| 23:13.42 | Corydon76-dig | Qwell: yes, but people generally do not run 64-bit machines in production |
| 23:13.59 | Corydon76-dig | Not until relatively recently anyway |
| 23:14.07 | Qwell | func_strings is actually the only thing that calls it directly in 1.4 |
| 23:14.19 | Qwell | s/directly// |
| 23:14.33 | *** join/#asterisk-dev netson99 (n=netson99@210.210.181.48) |
| 23:26.41 | JunK-Y | Qwell: so the cli filtering is confirmed for the first days, right? |
| 23:29.49 | *** join/#asterisk-dev adker (n=chatzill@74-33-199-190.br1.glv.ny.frontiernet.net) |
| 23:34.39 | snuff-work | mm bad solaris.. thought i could fix flock error |
| 23:36.39 | codefreeze | silly snuff-work! ;) |
| 23:37.05 | snuff-work | yer i know how i should be able to fix it though.. just must not have the right 'magic' |
| 23:41.49 | snuff-work | basically to get the 'flock()' it needs llib-lucb and /usr/ucbinclude/sys/file.h but when u include ucb library it goes apes**** |
| 23:43.04 | snuff-work | if i change app.c to use file.h from ucb it at least compiles but no 'flock' function |
| 23:48.04 | snuff-work | also have 2 places that need fix for compiler warnings |
| 23:52.09 | snuff-work | will post those on bugs.digium |