| 00:18.21 | *** part/#asterisk-bugs zerohalo (n=zeroHalo@pool-72-70-79-233.bstnma.east.verizon.net) |
| 00:20.36 | *** join/#asterisk-bugs dlynes_ (n=dlynes@216.251.149.68) |
| 00:22.37 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 00:39.42 | *** join/#asterisk-bugs dlynes_laptop (n=dlynes@216.251.149.68) |
| 01:36.08 | *** join/#asterisk-bugs Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 04:01.12 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 04:01.12 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 05:17.30 | *** join/#asterisk-bugs mvanbaak (n=mafkees@vanbaak.xs4all.nl) |
| 06:52.44 | *** join/#asterisk-bugs dlynes_laptop (n=dlynes@d154-20-34-39.bchsia.telus.net) |
| 06:53.24 | *** join/#asterisk-bugs dlynes_laptop (n=dlynes@d154-20-34-39.bchsia.telus.net) |
| 09:34.18 | *** join/#asterisk-bugs pjezek (n=pj@193.85.164.154) |
| 09:36.26 | pjezek | hi, can anybody, that knows something about commit r78683 "Add support for using epoll instead of poll", look at bugreport http://bugs.digium.com/view.php?id=10497? this commin breaks chan_h323 usability in asterisk svn trunk, thx |
| 11:14.26 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:11.13 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:11.13 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 12:18.52 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:45.11 | *** join/#asterisk-bugs miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 13:26.29 | *** join/#asterisk-bugs JackEStorm (n=no@ip68-225-77-136.no.no.cox.net) |
| 14:02.58 | *** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 14:52.44 | *** join/#asterisk-bugs putnopvut (i=putnopvu@nat/digium/x-f7bedd9d060b20e1) |
| 14:52.44 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 15:18.21 | *** join/#asterisk-bugs kpfleming (i=kpflemin@nat/digium/x-b0edc15c4ef6ea25) |
| 15:18.21 | *** mode/#asterisk-bugs [+o kpfleming] by ChanServ |
| 15:23.46 | *** join/#asterisk-bugs pjezek (n=pj@193.85.164.154) |
| 15:31.04 | *** part/#asterisk-bugs pjezek (n=pj@193.85.164.154) |
| 15:52.02 | *** join/#asterisk-bugs pjezek (n=pj@193.85.164.154) |
| 16:13.02 | *** join/#asterisk-bugs miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 16:31.34 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 16:33.50 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:35.03 | *** join/#asterisk-bugs wunderkin (n=wunderki@ip72-208-16-104.ph.ph.cox.net) |
| 17:54.43 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:54.43 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 19:31.25 | *** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 19:34.46 | d1mas | Question - why AEL parser does not trim out all spaces? As result, 'a = 1;' becomes 'Set(a=$[ 1])' note the space. |
| 19:35.17 | d1mas | This causes alot of troubles. I wanted submit an issue but decided to check it here first |
| 19:47.32 | d1mas | hello? |
| 19:48.38 | codefreeze | d1mas: I find that Set( a =...) is different than Set(a =....) is diff than Set( a=...)... the spaces count as part of the name. |
| 19:49.39 | codefreeze | AEL doesn't allow spaces in names. And it's bad practice to make them so. |
| 19:50.22 | codefreeze | AND |
| 19:50.37 | codefreeze | $[ 1] should eval to 1... |
| 19:51.53 | codefreeze | the expression parser was upgraded to not care much about spaces, also.... unless... are you on 1.2 or something? |
| 19:52.11 | d1mas | 1.4 |
| 19:53.17 | d1mas | the problems I'm having are mostly with macro parameters. When I call macro I do something like &dispatch-voicemail(1000, u) - note the space. And that space hits me eventually |
| 19:54.23 | d1mas | The only solution is to make calls like &dispatch-voicemail(1000,u) - no spaces. But spaces add alot of readability to any program code, you know. And AEL dialplan is basically a program code |
| 19:58.28 | codefreeze | d1mas: sometimes, the space can hurt you. args are fed to macros as is, spaces included, and they can have an effect. Like NoOp(this has spaces, and that's good); |
| 19:59.21 | blitzrage | FYI: 'a lot' is 2 words |
| 19:59.24 | d1mas | absolutely. I'm only talking about leading & trailing spaces mostly |
| 19:59.37 | d1mas | I know. So what? :) |
| 19:59.59 | codefreeze | extensions.conf has no provision to indicate important spaces from non-important. So I try to pass them as I see them. AEL3 will solve some of these problems. |
| 20:00.05 | blitzrage | if you know, then why are you using incorrect grammar? 'alot' is one of my pet peeves |
| 20:01.10 | codefreeze | whatcha wanna us to do, blitzrage? type nuttin but grammatical-correct phrases? |
| 20:01.12 | d1mas | I always type 'alot' and Word fixes it for me in emails. Unfortunately it does not work this way in IRC. Bad habbit, sorry. |
| 20:01.41 | Qwell | ^ reason #1 that auto-correct is silly |
| 20:02.25 | d1mas | I would prefer reading silly but auto-corrected emails than not corrected ones :) |
| 20:02.31 | putnopvut | My pet peeve misspelling is "definately" because it absolutely baffles me how anyone could possibly think that is the correct spelling. |
| 20:02.51 | codefreeze | blitzrage must be having a bad grammatical day! Every one give him a big hug and include "a lot" somehow! ;) |
| 20:03.19 | d1mas | common guys, not everybody live in States. Not everybody is native speaker |
| 20:03.43 | codefreeze | and for putnopvut, say "definitely a lot" somewhere....! :D |
| 20:03.45 | blitzrage | I don't live in the states either |
| 20:04.12 | blitzrage | and I was trying to help someone out who may not be a native speaker, but you said you already knew, so I have no pity |
| 20:04.23 | putnopvut | d1mas: my experience is that the ones who live in the states are worse spellers than the ones who do not. |
| 20:04.28 | blitzrage | I definitely know a lot of things |
| 20:04.37 | blitzrage | but I definitely don't know a lot about everything |
| 20:04.41 | d1mas | :) |
| 20:05.08 | d1mas | codefreeze: where can I read something about AEL3 ? |
| 20:05.48 | codefreeze | AEL3 is in my mind at the moment. And even my wife admits that my mind is hard to read. |
| 20:05.56 | d1mas | blitzrage: I promise typing "a lot" when talking here :) |
| 20:06.28 | d1mas | my wife does not accept that my mind exists :) |
| 20:07.06 | codefreeze | lol; I bet few will admit that their husbands have one... |
| 20:10.47 | d1mas | codefreeze: so do I understand correctly that AEL parser does not read application/macro parameters separately but takes whole text between ( ) and puts it as application data? |
| 20:11.26 | d1mas | (I mean it does not read them individually separating by coma) |
| 20:13.54 | codefreeze | d1mas: no, I'd best not say that. It does watch for the commas, and builds a list, and counts the elements in the list. |
| 20:14.33 | codefreeze | As to exactly how it treats spaces in the mix, I'd have to read the code. Been a while since I wrote it. |
| 20:16.21 | codefreeze | Looks like it keeps the spaces, or you'd not be complaining....? |
| 20:16.43 | d1mas | oh... remoing leading/trailing comas won't work.... Because of the Noop you mentioned above - Noop(coma, which should remain). And parser has no idea if this coma separates parameters or just part of single parameter :( |
| 20:17.05 | d1mas | it definitely does keep them |
| 20:18.13 | d1mas | too bad. I used to put a lot of spaces and they hurt me one by one... |
| 20:28.05 | codefreeze | d1mas: if they are OK in extensions.conf, why would they.... hold on, let me check and see if the config file reader/pbx parser filters out leading/trailing blanks to args. Maybe I can too, if that's the case. |
| 20:31.54 | d1mas | no, when extensions.conf is parsed, spaces around application parameters are not removed. I have just checked it. |
| 20:35.10 | codefreeze | ok, so.... exactly what is AEL doing different? |
| 20:37.46 | d1mas | nothing. I was not saying it is doing something different. I only was saying that keeping spaces hurts. I do not use extensions.conf at all so I could not compare |
| 20:39.19 | d1mas | ok, I understand that it is not currently possible to trim spaces from parameters because there is no way to distinguish parameter separator from just part of text. That is pity. |
| 20:41.17 | codefreeze | d1mas: Be of good cheer-- AEL3 will allow them. (But every good thing has its price!) |
| 20:41.55 | d1mas | what price AEL3 will have? :) |
| 20:42.27 | Qwell | d1mas: $999.95 |
| 20:43.13 | d1mas | not bad :) |
| 20:43.40 | Qwell | per line of dialplan |
| 20:44.09 | d1mas | per caracter... afte space trimming :) |
| 20:44.13 | d1mas | character |
| 20:45.14 | codefreeze | d1mas: while I like Qwell's pricing structure, I meant that you'll have put strings in quotes. |
| 20:50.05 | d1mas | codefreeze: btw, when you will be thinking about AEL3, remember another thing which I think is very surprising in AEL2: when you write a = $b; you will have not what you really expect when $b contains some operation like plus or minus. In my case $b has a context name (like 'local-users') and a= $b; assigns zero to $a (if my memory serves me) |
| 20:51.04 | d1mas | so I had to put a="$b"; to fix that. |
| 20:51.54 | codefreeze | or a=${b}; ? |
| 20:54.19 | d1mas | $b => ${b} everywhere |
| 20:58.18 | d1mas | This is because assignment translates to Set(b=$[${a}]) and square brackets evaluate the "expression" |
| 21:01.57 | d1mas | sorry of course Set(a=$[${b}]). I'm asleep... |
| 21:13.20 | codefreeze | d1mas: you can say a=${b}; and you can also say Set(a=${b}); they will act slightly differently. |
| 21:26.53 | d1mas | I know. The problem is that a=${b}; does look like ordinary assignment and you do not expect that for some reason ${a} will receive value different from ${b}. I believe a lot of people with development background in any language find it strange when they get zero in the ${a} for the first time... |
| 22:17.23 | codefreeze | d1mas: I replied to 11086; you need to supply more info. |
| 22:18.38 | d1mas | codefreeze: hm.... have you tested it with trunk or 1.4 ? |
| 22:19.06 | codefreeze | d1mas: don't know. shouldn't matter in this case. |
| 22:19.21 | d1mas | oh. disregard it. Yes I have empty contexts |
| 22:20.17 | d1mas | What is the point in ignoring them? |
| 22:20.26 | codefreeze | d1mas: as to the above, people really do have to understand how $[] works, and how AEL wraps expressions -- at least, when it wraps expressions, with $[]. Without that knowledge, yes, people will be confused. |
| 22:21.46 | codefreeze | d1mas: as to ignoring empty contexts, you may have a point; I will do some investigation tomm. |
| 22:22.00 | d1mas | I totally agree, after I got that understanding, everything was clear. But before I started reading, it was a surprise |
| 22:22.48 | codefreeze | d1mas: and some say that 'ignorance is bliss'.... I say 'ignorance leads to nasty surprises!' |
| 22:24.22 | d1mas | just to let you know what is the point in having empty contexts :) - I have a cluster of boxes and most of dialplan is absolutely the same except for some "extension points" that is special context where site nodes can put their own extensions. So the "base" AEL dialplan on each box includes all these site-specific contexts while most of them are empty on sites |
| 22:42.20 | codefreeze | OK, I will keep your bug open, investigate, and most likely close it with that restriction lifted, or at least a good explanation of why not. |
| 22:43.51 | d1mas | thanks. |
| 23:01.53 | *** join/#asterisk-bugs implicit (n=implicit@ip72-197-20-157.sd.sd.cox.net) |
| 23:01.53 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |