[yast-devel] new YCP builtins
Hi YCP-Hackers,
I've used some ITO time to implement two new YCP builtins:
1. splitlist (var x, list, block using x)
Takes a list and a predicate function and splits the list where the
predicate function says so. Returns a list of lists.
Example:
list<string> l = [ "0", "a", "1", "2", "b", "3", "4" ];
splitlist(string s, l, { return isalpha(s); });
return is [ [ "0" ], [ "a", "1", "2" ], [ "b", "3", "4" ] ]
The difference to splitstring is that the 'delimiter' is included in the
result since that's the way I need it. If desired I could add a parameter
that tells whether the 'delimiter' should be added to the previous list,
the following list or not at all.
2. reducelist (var x, var y, initial value, list, block using x and y)
This is the standard reduce function known from Lisp (but also available in
e.g. C++, Python and Ruby). It takes a list and reduces it to a single
value by applying a function, see:
http://en.wikipedia.org/wiki/Reduce_%28higher-order_function%29
Examples:
// sum and product
integer sum = reducelist(integer x, integer y, 0, [ 1, 2, 3, 4 ], { return x + y; });
integer product = reducelist(integer x, integer y, 1, [ 1, 2, 3, 4 ], { return x * y; });
// min and max
list<integer> l1 = [ 1, 2, 3 ];
integer min = reducelist(integer x, integer y, l1[0]:nil, l1, { return x < y ? x : y; });
integer max = reducelist(integer x, integer y, l1[0]:nil, l1, { return x > y ? x : y; });
// mergestring
list<string> l2 = [ "hello", "openSUSE", "world" ];
string s = reducelist(string x, string y, "", l2, { return x + " " + y; });
// find longest string
string ls = reducelist(string x, string y, "", l2, { return size(x) > size(y) ? x : y; });
// find length of longest string (note: type of x and y differ)
integer ll = reducelist(integer l, string s, 0, l2, { return size(s) > l ? size(s) : l; });
Patch is attached. Still missing is documentation and testsuite. The patch
contains a binary incompatibility to libycp by adding the clear() function to
YCPList. If that's not wanted a workaround is included (maybe someone has a
better workaround). Bytecode compatibility is not touched.
It's not possible to add the functions to a module since they use the variable
type feature of YCP.
Please comment.
ciao
Arvin
--
Arvin Schnell,
Arvin Schnell wrote:
Hi YCP-Hackers,
I've used some ITO time to implement two new YCP builtins:
1. splitlist (var x, list, block using x)
Takes a list and a predicate function and splits the list where the predicate function says so. Returns a list of lists.
Example:
list<string> l = [ "0", "a", "1", "2", "b", "3", "4" ]; splitlist(string s, l, { return isalpha(s); });
return is [ [ "0" ], [ "a", "1", "2" ], [ "b", "3", "4" ] ]
The difference to splitstring is that the 'delimiter' is included in the result since that's the way I need it. If desired I could add a parameter that tells whether the 'delimiter' should be added to the previous list, the following list or not at all.
Hmm, and do you really see any possibility where *else* such a builtin could be used? What are the use-cases? Why should we have it? In my opinion: * The use-case is very limited, or almost none. * In conflict with the current /splitstring/ where the delimiter is not included. Bye Lukas
On Wed, Jun 04, 2008 at 04:04:15PM +0200, Lukas Ocilka wrote:
Arvin Schnell wrote:
Hi YCP-Hackers,
I've used some ITO time to implement two new YCP builtins:
1. splitlist (var x, list, block using x)
Takes a list and a predicate function and splits the list where the predicate function says so. Returns a list of lists.
Example:
list<string> l = [ "0", "a", "1", "2", "b", "3", "4" ]; splitlist(string s, l, { return isalpha(s); });
return is [ [ "0" ], [ "a", "1", "2" ], [ "b", "3", "4" ] ]
The difference to splitstring is that the 'delimiter' is included in the result since that's the way I need it. If desired I could add a parameter that tells whether the 'delimiter' should be added to the previous list, the following list or not at all.
Hmm, and do you really see any possibility where *else* such a builtin could be used? What are the use-cases?
Appart from my use in storage you could split logfiles, e.g. split y2log at lines containing 'genericfrontend.cc ... Launched YaST2 component' to present the individual runs. Or maybe even split /var/log/messages in several hierarchy and display the result in a tree widget so it's easy to fold/unfold messages you don't care about. But I understand that the use-cases are limited.
Why should we have it?
Code reuse. Onlt builtins can have variable types.
* In conflict with the current /splitstring/ where the delimiter is not included.
I consider that to be a limitation of splitstring and I could
improve splitlist to be compatible depending on a parameter.
ciao Arvin
--
Arvin Schnell,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arvin Schnell napsal(a): |> Hmm, and do you really see any possibility where *else* such a builtin |> could be used? What are the use-cases? | | Appart from my use in storage you could split logfiles, | e.g. split y2log at lines containing 'genericfrontend.cc ... | Launched YaST2 component' to present the individual runs. Or | maybe even split /var/log/messages in several hierarchy and | display the result in a tree widget so it's easy to fold/unfold | messages you don't care about. | | But I understand that the use-cases are limited. So it might be used for debugging YaST logs. Is YCP the best way how to read YaST logs? You might share such knowledge with us :) |> * In conflict with the current /splitstring/ where the delimiter is |> not included. | | I consider that to be a limitation of splitstring and I could | improve splitlist to be compatible depending on a parameter. Let's wait for others to comment. Adding new builtins is a good thing if more developers find them useful. Otherwise it just adds unneeded complexity to both core and YCP code and makes the code harder to read. L. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIRuYlVSqMdRCqTiwRAmOMAJ9WOitIpQLLmZR+gjoJPbaJoQ3jhwCdF0bS Du2BQfaAY/gWh8XO9y4YsQA= =QGFf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi, On Wed, Jun 04, 2008 at 08:59:49PM +0200, Lukas Ocilka wrote:
Let's wait for others to comment. Adding new builtins is a good thing if more developers find them useful. Otherwise it just adds unneeded complexity to both core and YCP code and makes the code harder to read.
I recognize that new functions make programming easier, so I would like to see more of them. On the other hand, new builtins come in the global namespace and thus create conflict with existing identifiers (it has been the case with every improvement to YCP: "default", "getenv"...). So we have to make a digression and put the new features into a "namespace" or whatever, so that the language stays backward compatible. I am thinking of allowing type names as namespaces for builtins: list<string> l = [ "0", "a", "1", "2", "b", "3", "4" ]; list<string> spl = list::split(string s, l, { return isalpha(s); }); list<integer> l1 = [ 1, 2, 3 ]; integer min = list::reduce(integer x, integer y, l1[0]:nil, l1, {return x < y ? x : y; }); Any other ideas how to solve this? Problems? It seems that I should prototype this pretty soon so that we can move forward. (See also these from my bug collection:) - bnc#198077 "how to introduce new builtins to YCP" - bnc#55163 list::findfirstof - bnc#58844 set::intersection, set::difference, set::symmetric_difference (any similarities with python are purely intentional) - bnc#231719 string::iregexpmatch, string::iregexpsub -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Jun 05, 2008 at 10:16:27AM +0200, Martin Vidner wrote:
I recognize that new functions make programming easier, so I would like to see more of them. On the other hand, new builtins come in the global namespace and thus create conflict with existing identifiers (it has been the case with every improvement to YCP: "default", "getenv"...).
So we have to make a digression and put the new features into a "namespace" or whatever, so that the language stays backward compatible.
Very true! That's infact the reason reducelist is called reducelist and not reduce: There is a variable in bootloader called reduce. I had the same problem when adding sublist and I didn't add floor and ceil due to that same reason.
I am thinking of allowing type names as namespaces for builtins:
It seems that I should prototype this pretty soon so that we can move forward.
Great, something for our ITO Friday :) ciao Arvin -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thursday 05 June 2008 10:16, Martin Vidner wrote:
Any other ideas how to solve this?
Provide a namespace YCP:: for ambiguous cases?
YCP::myWeirdBuiltIn( arg1, arg2 );
CU
--
Stefan Hundhammer
Dne Wednesday 04 of June 2008 19:57:36 Arvin Schnell napsal(a):
On Wed, Jun 04, 2008 at 04:04:15PM +0200, Lukas Ocilka wrote:
Why should we have it?
Code reuse. Onlt builtins can have variable types.
Don't understand what you mean here. Every function can have types of variables defined. Implementing the very same code in YCP should be pretty easy. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz
On Thu, Jun 05, 2008 at 09:40:50AM +0200, Jiri Srain wrote:
Dne Wednesday 04 of June 2008 19:57:36 Arvin Schnell napsal(a):
On Wed, Jun 04, 2008 at 04:04:15PM +0200, Lukas Ocilka wrote:
Why should we have it?
Code reuse. Onlt builtins can have variable types.
Don't understand what you mean here. Every function can have types of variables defined. Implementing the very same code in YCP should be pretty easy.
Not "types of variables" but "types that can vary". Arvin means the analogy of C++ templates, called "flex" types internally in libycp. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hello, On Jun 4 15:55 Arvin Schnell wrote (shortened):
I've used some ITO time to implement two new YCP builtins: [and some discussion about whether or not]
I have a general question regarding whatever changes in YCP: What is our official method so that I as a YCP user know what the current official YCP is? Currently - at least for me - the official YCP is exactly what I find for the particular product version on http://forgeftp.novell.com/yast/doc/ because this one is worldwide public available regardless of what might be currently actually installed on whatever particular user's system. Is this correct or is the "official YCP" e.g. only the current source code in SVN or only the actually installed documentation on whatever particular user's system or is the "official YCP" perhaps not defined at all? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Jun 05, 2008 at 08:16:33AM +0200, Johannes Meixner wrote:
What is our official method so that I as a YCP user know what the current official YCP is?
Currently - at least for me - the official YCP is exactly what I find for the particular product version on http://forgeftp.novell.com/yast/doc/ because this one is worldwide public available regardless of what might be currently actually installed on whatever particular user's system.
Yes. (Only I feel that "forgeftp" is not permanent enough so I would recommend the URL http://en.opensuse.org/YaST/Development#Documentation ) If there is anything wrong or missing, it is a bug that we have to fix. Please report it here or in Bugzilla. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (6)
-
Arvin Schnell -
Jiri Srain -
Johannes Meixner -
Lukas Ocilka -
Martin Vidner -
Stefan Hundhammer