| 00:23.54 | tzanger | yaaaaaaaaaaaaay |
| 00:29.57 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-246.hsd1.al.comcast.net) |
| 00:29.57 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 00:50.55 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 00:50.55 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 00:56.18 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 00:56.18 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 01:01.10 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 02:39.01 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 03:04.12 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 08:26.51 | *** join/#asterisk-dev Pazzo (n=ugelt@sadsl-246059.rol.raiffeisen.net) |
| 09:45.28 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:45.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:09.05 | *** join/#asterisk-dev shido6 (n=shido6@96-28-34-156.dhcp.insightbb.com) |
| 14:41.20 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:41.20 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:54.30 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 15:32.59 | *** join/#asterisk-dev outtolunc (n=me@c-71-198-197-201.hsd1.ca.comcast.net) |
| 15:55.42 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 16:03.20 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 17:08.35 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 17:08.52 | *** join/#asterisk-dev eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 17:08.52 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 17:44.21 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 18:14.52 | *** join/#asterisk-dev bkruse (n=bkruse@76.73.154.120) |
| 18:14.53 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 18:23.48 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 19:14.41 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 19:45.13 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 20:22.15 | *** part/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 20:34.25 | *** join/#asterisk-dev tamiel (n=tamiel@ip-176.net-89-2-117.rev.numericable.fr) |
| 21:16.39 | *** join/#asterisk-dev NirS (n=NirS@77.127.107.162) |
| 21:16.45 | NirS | Hi all |
| 21:16.57 | NirS | anybody home ? |
| 21:17.39 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 21:17.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:17.58 | NirS | hi olle |
| 21:18.36 | oej | Night, Nir! |
| 21:19.07 | NirS | Olle, say, are you familiar with main/pbx.c ? |
| 21:19.42 | NirS | I getting utterly pissed at the fact that there is no Inc/Dec functions in Asterisk |
| 21:19.47 | NirS | so I've decided to add these |
| 21:20.03 | NirS | my logic says this should be a part of main/pbx.c, however, I think I'm reading something wrong in there |
| 21:21.41 | seanbright | you should take a look at funcs/ |
| 21:22.05 | oej | there's an atomic fetch add something in the API |
| 21:22.09 | oej | check utils.c |
| 21:24.13 | NirS | ok, I think I missed something in that |
| 21:24.27 | NirS | I looked at functions, however, I believe the proper place would be in pbx.c |
| 21:24.34 | NirS | as this isn't really a math fuction |
| 21:24.37 | NirS | function even |
| 21:26.05 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 21:26.10 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 22:57.47 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:09.11 | snuff-home | :q |
| 23:11.11 | NirS | hey snuff |
| 23:12.36 | snuff-home | ello |
| 23:12.55 | tzafrir_laptop | you use vimirc? |
| 23:13.04 | NirS | no, I'm using xchat |
| 23:13.18 | NirS | tzafrir, I just added a new feature code contribution for branch 1.4 |
| 23:13.22 | NirS | it's in the bug tracker |
| 23:13.44 | NirS | but I'm having a small problem in there with a pointer initialization |
| 23:13.47 | NirS | care to assist for a sec ? |
| 23:13.50 | tzafrir_laptop | what bug number? |
| 23:14.02 | NirS | 0014880 |
| 23:14.31 | NirS | it's a really stupid feature, but very useful if you write IVRs and use loops in the dialplan |
| 23:14.32 | tzafrir_laptop | looking |
| 23:14.34 | snuff-home | no irssi.. was playin in vim ;) |
| 23:15.44 | tzafrir_laptop | NirS, is it a function or a dialplan app? |
| 23:15.50 | NirS | function |
| 23:15.54 | NirS | inside main/pbx.c |
| 23:16.05 | NirS | it's not a func_dec or something like that |
| 23:16.24 | tzafrir_laptop | actually application |
| 23:16.37 | tzafrir_laptop | (just to get your terminology right) |
| 23:16.50 | NirS | well, in that case, then it's an application, yes |
| 23:19.16 | tzafrir_laptop | also: what do you need the string newvalue for? |
| 23:20.12 | NirS | well, the thing is that when I tried to use the value as the return for the sprintf, Asterisk produced inconsistent output, as if the pointer location is being over written |
| 23:20.24 | NirS | so I decided to go about and simply create a new variable |
| 23:20.40 | NirS | newvalue is being assigned via the sprintf functoin |
| 23:20.43 | NirS | function |
| 23:20.45 | tzafrir_laptop | a string value instead of an int? what for? |
| 23:20.48 | snuff-home | NirS: a new feature wont be added to 1.4 as u know.. to be 'accepted' into asterisk is has to be made against trunk.. |
| 23:21.10 | NirS | snuff, I'll create a patch for SVN 1.6 no problem there |
| 23:21.21 | tzafrir_laptop | also, I wonder if locking is required. e.g.: can you guarantee that a global var still exists by the time you set it? |
| 23:21.26 | snuff-home | ;) |
| 23:21.26 | NirS | I started with 1.4 as that what I had running on my box in the dev |
| 23:21.47 | NirS | well, the setvar_helper is incharge of the locking |
| 23:22.10 | NirS | and also the getvar_helper handles locking of the mutex, so that the channel variable is locked during the operation |
| 23:22.26 | NirS | at least, that's what I think it does - unless I misunderstood the documentation |
| 23:22.51 | tzafrir_laptop | so if two of those run "at the same time" on a global, they may both increment it to the same value |
| 23:23.38 | NirS | in general, I believe you are correct |
| 23:23.39 | tzafrir_laptop | In 1.6 it gets even worse, as other channels get to modify your local variables |
| 23:23.41 | NirS | that's a good question |
| 23:25.13 | NirS | I didn't really try that |
| 23:26.20 | NirS | actually, looks like something that I copied half way will prevent a global variable to be incremeneted or decremented via my functions |
| 23:26.53 | tzafrir_laptop | also, on trunk application command-line handling should be generally simpler |
| 23:26.55 | NirS | or not |
| 23:27.15 | NirS | ok, looks like I'll download the 1.6 trunk and start again |
| 23:27.21 | NirS | let's see if that makes life simpler |
| 23:29.24 | NirS | the thing is this, I couldn't find any functions or applications in Asterisk (or maybe I'm wrong) that manipulate a variable autonomously |
| 23:29.47 | NirS | which means, without returning a variable, just modifying the variable and returning the result to the same variable |
| 23:35.17 | NirS | is !$%!#%!#$@%!^!#^!#^!%!#$!# |
| 23:36.59 | NirS | ok, looks like my head had been well into version 1.4 for too long |
| 23:37.22 | NirS | I'm looking at 1.6 trunk, and the code looks like chinese |
| 23:37.28 | NirS | at least, compared to 1.4 |
| 23:39.59 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 23:40.04 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 23:41.10 | *** join/#asterisk-dev smbrienz (n=guest@host202-204-dynamic.1-87-r.retail.telecomitalia.it) |