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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
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
On Dec 12, 2008 at 14:04, Henning Westerholt henning.westerholt@1und1.de wrote:
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.
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.
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.
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.
[..] 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.
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 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
On Dec 12, 2008 at 17:23, Daniel-Constantin Mierla miconda@gmail.com wrote:
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.
We are not talking about extremes, we are talking about making it more perl like (which is a very common scripting language).
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
On 12/12/08 20:11, Andrei Pelinescu-Onciul wrote:
On Dec 12, 2008 at 17:23, Daniel-Constantin Mierla miconda@gmail.com wrote:
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.
We are not talking about extremes, we are talking about making it more perl like (which is a very common scripting language).
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.
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.
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
[...]
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.
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
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.
On Dec 12, 2008 at 16:41, Jan Janak jan@ryngle.com wrote:
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.
I was using perl as a guideline (since we already have perl like stuff, like ~=).
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'.
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 12-12 19:15, Andrei Pelinescu-Onciul wrote:
On Dec 12, 2008 at 16:41, Jan Janak jan@ryngle.com wrote:
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.
I was using perl as a guideline (since we already have perl like stuff, like ~=).
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).
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'.
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.
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Jan Janak -
jh＠tutpro.com -
Klaus Darilion