11 Dec
2008
11 Dec
'08
10:01 p.m.
It would be better to have different operators for strings and for
integers. Right now we have '+', '==' and '!=' that can be used
both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I think having perl like operators would help a lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
- 'eq' instead of == for strings, e.g.: $v eq "bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
We could support them right now in parallel with the old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
The question is how much are they used right now. While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and
'+'
is the most important anyway).
Note: we can still support '==' and '!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
Another advantage that this change would bring is better type checking
at startup (more errors flagged without having to run the script) and
possible implicit conversions (e.g. int to string or string to int) if
we decide to support them.
Any comments?
In the future it would also be much better to have typed script vars
(e.g. int $var1). This would help a lot in checking the script for
correctness. With the dynamic typed vars, one has to run the script to
find errors. It would also help in optimizing, but not so much if we
separate the operators, like above.
Andrei
11 Dec
11 Dec
10:25 p.m.
New subject: [SR-Dev] operators and variables
Hi Andrei!
Thanks for all this stuff.
IMO . instead of + for strings is fine.
I do not like eq/ne but if this is useful for optimization I can learn ;-)
I would not introduce too much compatibility stuff. If we (Kamailio)
switch to a new core IMO it would be OK to start with clear syntax
avoiding old style syntax which will be removed anyway.
Regarding strings. I think we also could address the NULL issue:
difference of empty string versus undefined string (e.g. an undefined
avp or a not existing pv like $hdr(Foo-Bar-XYZ)).
regards
klaus
Andrei Pelinescu-Onciul wrote:
It would be better to have different operators for
strings and for
integers. Right now we have '+', '==' and '!=' that can be used
both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I think having perl like operators would help a lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
- 'eq' instead of == for strings, e.g.: $v eq "bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
We could support them right now in parallel with the old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
The question is how much are they used right now. While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and
'+'
is the most important anyway).
Note: we can still support '==' and '!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
Another advantage that this change would bring is better type checking
at startup (more errors flagged without having to run the script) and
possible implicit conversions (e.g. int to string or string to int) if
we decide to support them.
Any comments?
In the future it would also be much better to have typed script vars
(e.g. int $var1). This would help a lot in checking the script for
correctness. With the dynamic typed vars, one has to run the script to
find errors. It would also help in optimizing, but not so much if we
separate the operators, like above.
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12 Dec
12 Dec
7:44 a.m.
New subject: [SR-Dev] operators and variables
Andrei Pelinescu-Onciul writes:
I think having perl like operators would help a lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
this is ok.
- 'eq' instead of == for strings, e.g.: $v eq
"bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
i'm not sure about these, because == and != are in very common use (c,
php, etc.).
typing of $var and $avp would be ok with me.
-- juha
2:04 p.m.
New subject: [SR-Dev] operators and variables
On Thursday 11 December 2008, Andrei Pelinescu-Onciul wrote:
It would be better to have different operators for
strings and for
integers. Right now we have '+', '==' and '!=' that can be used
both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I think having perl like operators would help a lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
- 'eq' instead of == for strings, e.g.: $v eq "bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
Hi Andrei,
first of all, thanks for the work you've done so far for the config scripting.
I understand the problem with the existing operators. But from the user POV i
doubt that changing this is really worth the effort. This would break
compatibility with all existing scripts, many documentation out there would
be obseleted and must be updated and so on.
I don't like the 'eq' and 'ne' that much, for me '==' and
'!=' is more
intuitive as its used in most other programming languages.
Can you estimate the performance benefit that would be possible with this
optimisations? If its in the range of a few percent, then we should not
bother about this. The server is really fast enough in my experience, and
CPUs getting more cores every year.
We could support them right now in parallel with the
old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
I'd prefer to not introduce too much compatibility layers, this makes
debugging and maintaining both the code and the config script more harder
then necessary in my experience.
The question is how much are they used right now.
While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and
'+'
is the most important anyway).
I think the '+' is also commonly used, althought not that much as == and !=, i
agree.
Note: we can still support '==' and
'!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
IMHO having different operators for different type of variables would be
confusing. The config script language is already quite complicated for
the "normal" administrator or system developer that don't have the luxury of
working the whole day with SER/ Kamailio.
[..]
In the future it would also be much better to have typed script vars
(e.g. int $var1). This would help a lot in checking the script for
correctness. With the dynamic typed vars, one has to run the script to
find errors. It would also help in optimizing, but not so much if we
separate the operators, like above.
Having this typed script vars would be ok, but i rather prefer keeping it
simple and compatible here too, if this brings not a substancial performance
benefit.
Cheers,
Henning
3:43 p.m.
New subject: [SR-Dev] operators and variables
On Dec 12, 2008 at 14:04, Henning Westerholt <henning.westerholt(a)1und1.de> wrote:
I think even more confusing is having errors at runtime due to type
mismatches. It's way better to have them at startup or when checking the
config (-cf ...) rather then at runtime (who tests all the possible
branches in his config?).
So the trade-off is having different operators for better performance and
better error detection at start-up/config check or using same operators
and having type mismatch errors at runtime.
It brings less performance then the operators changes, but it will allow
for detecting a lot more errors at start-up rather then at runtime
(which IMHO is a huge advantage).
Andrei
On Thursday 11 December 2008, Andrei Pelinescu-Onciul
wrote:
It depends on the complexity of the expressions. There are a lot of
optimizations which cannot be made right now => more work at runtime for
the expression evaluator.
It would be better to have different operators
for strings and for
integers. Right now we have '+', '==' and '!=' that can be used
both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I think having perl like operators would help a lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
- 'eq' instead of == for strings, e.g.: $v eq "bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
Hi Andrei,
first of all, thanks for the work you've done so far for the config scripting.
I understand the problem with the existing operators. But from the user POV i
doubt that changing this is really worth the effort. This would break
compatibility with all existing scripts, many documentation out there would
be obseleted and must be updated and so on.
I don't like the 'eq' and 'ne' that much, for me '==' and
'!=' is more
intuitive as its used in most other programming languages.
Can you estimate the performance benefit that would be possible with this
optimisations? If its in the range of a few percent, then we should not
bother about this. The server is really fast enough in my experience, and
CPUs getting more cores every year. We could support them right now in parallel with
the old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
I'd prefer to not introduce too much compatibility layers, this makes
debugging and maintaining both the code and the config script more harder
then necessary in my experience.
The question is how much are they used right now.
While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and
'+'
is the most important anyway).
I think the '+' is also commonly used, althought not that much as == and !=, i
agree.
Note: we can still support '==' and
'!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
IMHO having different operators for different type of variables would be
confusing. The config script language is already quite complicated for
the "normal" administrator or system developer that don't have the luxury
of
working the whole day with SER/ Kamailio. [..]
In the future it would also be much better to have typed script vars
(e.g. int $var1). This would help a lot in checking the script for
correctness. With the dynamic typed vars, one has to run the script to
find errors. It would also help in optimizing, but not so much if we
separate the operators, like above.
Having this typed script vars would be ok, but i rather prefer keeping it
simple and compatible here too, if this brings not a substancial performance
benefit. 
4:23 p.m.
New subject: [SR-Dev] operators and variables
On 12/12/08 16:43, Andrei Pelinescu-Onciul wrote:
It brings less performance then the operators changes,
but it will allow
for detecting a lot more errors at start-up rather then at runtime
(which IMHO is a huge advantage).
we should be careful and not get into extremes here. Performance shall
not ignore the complexity added in writing config -- ending to write the
config in C-like language should be avoided. While here are developers,
those using/administrating sip servers might be far from this
background. Easiness in understanding the config language and writing
the scripts by non-devels is very important to make it spread faster in
the market.
For operators, buying another server for one time 1-2k bucks is cheaper
than one full time developer that sits to optimize month by month.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
7:11 p.m.
New subject: [SR-Dev] operators and variables
On Dec 12, 2008 at 17:23, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 12/12/08 16:43, Andrei Pelinescu-Onciul wrote:
We are not talking about extremes, we are talking about making it more
perl like (which is a very common scripting language).
It brings less performance then the operators
changes, but it will allow
for detecting a lot more errors at start-up rather then at runtime
(which IMHO is a huge advantage).
we should be careful and not get into extremes here. Performance shall
not ignore the complexity added in writing config -- ending to write the
config in C-like language should be avoided. While here are developers,
those using/administrating sip servers might be far from this
background. Easiness in understanding the config language and writing
the scripts by non-devels is very important to make it spread faster in
the market.
For operators, buying another server for one time 1-2k bucks is cheaper
than one full time developer that sits to optimize month by month.
People would only need to use '.' for string and '+' for ints, they
don't need to do any optimization. The optimization will be done
automatically for them (already a lot of things are optimized), so I
fail to see your point.
In my opinion we should not aim to build a scripting language which is
easier then basic perl, especially since for us performance is much more
critical. I also fail to see the great concern about the extra
complexity a new operator would introduce. Any error will be reported
immediately and could be self explaining (like: wrong operator for
string, try '.').
Moreover as I already said this is not only about performance, is about
proper error checking before startup. I don't think anybody wants to
find bugs in his script in production, because he forgot that some avp
had int type and he tried to add it to a string... Right now this
script bug cannot be found. With the proposed changes it would be
reported immediately (sr -cf config will catch it, and also sr will
refuse to start if such an error is found).
If that's about compatibility with existing scripts, then let's leave
'+' for the next version and add '.' in parallel and at some future time
we'll obsolete '+' usage for strings.
The typed vars are for the future anyway.
Andrei
8:32 p.m.
New subject: [SR-Dev] operators and variables
On 12/12/08 20:11, Andrei Pelinescu-Onciul wrote:
On Dec 12, 2008 at 17:23, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Just to be sure there is no misunderstanding, by operators I meant
"sip/voip service operators". It is harder to get skilled personnel than
buying hardware, sip/voip is an area that lacks of good specialists,
adding more on top of that could turn against.
Although I agree with you in most of the aspects and like strict
checking (hehhh, C developer habits), I wanted to play devil's advocate,
not to fall in our own trap. I was one those pushing the config language
for flexibility, rather than embedding specific functionalities behind
some c-coded functions and make configuration easier.
However, today's complexity of the config language is well-known to be
heavy to digest for new comers. I admit, it is a trade off, but we need
to take in consideration the target users (voip sysadmins), where still
many have telco background rather than computer science.
On 12/12/08 16:43, Andrei Pelinescu-Onciul
wrote:
We are not talking about extremes, we are talking about making it more
perl like (which is a very common scripting language).
It brings less performance then the operators
changes, but it will allow
for detecting a lot more errors at start-up rather then at runtime
(which IMHO is a huge advantage).
we should be careful and not get into extremes here. Performance shall
not ignore the complexity added in writing config -- ending to write the
config in C-like language should be avoided. While here are developers,
those using/administrating sip servers might be far from this
background. Easiness in understanding the config language and writing
the scripts by non-devels is very important to make it spread faster in
the market.
For operators, buying another server for one time
1-2k bucks is cheaper
than one full time developer that sits to optimize month by month.
People would only need to use '.' for string and '+' for ints, they
don't need to do any optimization. The optimization will be done
automatically for them (already a lot of things are optimized), so I
fail to see your point.
In my opinion we should not aim to build a scripting
language which is
easier then basic perl, especially since for us performance is much more
critical. I also fail to see the great concern about the extra
complexity a new operator would introduce.
My comments were related to the general
topic, perhaps the text I left
in the message and commented by me got out of the context and didn't
suggest it properly. Actually, in this particular case, I was thinking
at types for variables, might be a bit too much for now...
As a matter of fact, I am in favor of "." for string concatenation, then
will be clear delimitation what are the string and arithmetic operators
(well, it is only one for strings). It will remove the ambiguity in some
cases:
$x . $y
$x + $y
There are (pseudo-)variables that can return string and int at same time
(e.g., port).
Mope my comments are more clear now!
Cheers,
Daniel
Any error will be reported
immediately and could be self explaining (like: wrong operator for
string, try '.').
Moreover as I already said this is not only about performance, is about
proper error checking before startup. I don't think anybody wants to
find bugs in his script in production, because he forgot that some avp
had int type and he tried to add it to a string... Right now this
script bug cannot be found. With the proposed changes it would be
reported immediately (sr -cf config will catch it, and also sr will
refuse to start if such an error is found).
If that's about compatibility with existing scripts, then let's leave
'+' for the next version and add '.' in parallel and at some future time
we'll obsolete '+' usage for strings.
The typed vars are for the future anyway.
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com
15 Dec
15 Dec
11:48 p.m.
New subject: [SR-Dev] operators and variables
Hello,
[...]
I agree here. Although we aim to have full compatibility with K and S
configs, I am looking at it more as functionality, not as syntax. I am
using this opportunity for doing cleanups and removing unused/useless
functions.
In K we dealt very good with big changes between major releases, by
having migration guides in the dokuwiki. There were not many complains
about syntax changes.
So if the decision is to go for "." in string concatenation expressions,
let's stick only to it. Same for other cases, provide onlye one (and
good) option. Anyhow will be a big update, and in this case everyone
does testing.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
We could support them right now in parallel with
the old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
I'd prefer to not introduce too much compatibility layers, this makes
debugging and maintaining both the code and the config script more harder
then necessary in my experience.
12 Dec
12 Dec
4:41 p.m.
New subject: [SR-Dev] operators and variables
On 11-12 22:01, Andrei Pelinescu-Onciul wrote:
It would be better to have different operators for strings and for
integers. Right now we have '+', '==' and '!=' that can be used
both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I would like to preserve the original behaviour for strings. They are used
much more often than integers. If you need to change anything then, please,
consider changing the behaviour of integer operators.
I think having perl like operators would help a lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
Yes, I like this one.
- 'eq' instead of == for strings, e.g.: $v eq
"bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
I don't like this. If there really is a need to have separate operators then
use 'eq' and 'ne' for integers and keep == and != for strings. Test (see
man
test) has string and integer operators this way.
We could support them right now in parallel with the
old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
The question is how much are they used right now. While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and
'+'
is the most important anyway).
I guess == and != are used most often with strings.
Note: we can still support '==' and
'!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
That would be inconsistent. if (method=="INVITE") would work, but
if ($abc=="foo") would not work if strings operators are replaced with
'eq'
and 'ne'.
Jan.
7:15 p.m.
New subject: [SR-Dev] operators and variables
On Dec 12, 2008 at 16:41, Jan Janak <jan(a)ryngle.com> wrote:
Yes, it would be, but I was thinking that most people use it only this
way and hence the change would not affect them immediately.
Andrei
On 11-12 22:01, Andrei Pelinescu-Onciul wrote:
I was using perl as a guideline (since we already have perl like stuff,
like ~=).
It would be better to have different operators for strings and for
integers. Right now we have '+', '==' and '!=' that can be used
both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I would like to preserve the original behaviour for strings. They are used
much more often than integers. If you need to change anything then, please,
consider changing the behaviour of integer operators.
I think having perl like operators would help a
lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
Yes, I like this one.
- 'eq' instead of == for strings, e.g.:
$v eq "bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
I don't like this. If there really is a need to have separate operators then
use 'eq' and 'ne' for integers and keep == and != for strings. Test
(see man
test) has string and integer operators this way. We could support them right now in parallel with
the old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
The question is how much are they used right now. While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and
'+'
is the most important anyway).
I guess == and != are used most often with strings.
Note: we can still support '==' and
'!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
That would be inconsistent. if (method=="INVITE") would work, but
if ($abc=="foo") would not work if strings operators are replaced with
'eq'
and 'ne'.
7:32 p.m.
New subject: [SR-Dev] operators and variables
On 12-12 19:15, Andrei Pelinescu-Onciul wrote:
Yes, it would be, but I was thinking that most people use it only this
way and hence the change would not affect them immediately.
I can neither confirm nor deny this, but at least in ser-oob.cfg operator ==
is used a lot with strings, so this config, at least, would be affected by such
change.
Jan.
On Dec 12, 2008 at 16:41, Jan Janak
<jan(a)ryngle.com> wrote:
Yeah, I know, my point was that in SER scripts I've seen we use these
operators with strings often and hence we should consider to preserve
the behavior for strings (as opposed to integers). I made the remark
about test to show that there are differences in existing scripts (perl
versus shell).
On 11-12 22:01, Andrei Pelinescu-Onciul wrote:
I was using perl as a guideline (since we already have perl like stuff,
like ~=).
It would be better to have different operators for strings and for
integers. Right now we have '+', '==' and '!=' that can be used
both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I would like to preserve the original behaviour for strings. They are used
much more often than integers. If you need to change anything then, please,
consider changing the behaviour of integer operators.
I think having perl like operators would help a
lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
Yes, I like this one.
- 'eq' instead of == for strings, e.g.:
$v eq "bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
I don't like this. If there really is a need to have separate operators then
use 'eq' and 'ne' for integers and keep == and != for strings. Test
(see man
test) has string and integer operators this way. We could support them right now in parallel with the
old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
The question is how much are they used right now. While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and
'+'
is the most important anyway).
I guess == and != are used most often with strings.
Note: we can still support '==' and
'!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
That would be inconsistent. if (method=="INVITE") would work, but
if ($abc=="foo") would not work if strings operators are replaced with
'eq'
and 'ne'.
5610
days inactive
5614
days old
11 comments
6 participants
participants (6)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Jan Janak -
jh＠tutpro.com -
Klaus Darilion