Mailinglist Archive: yast-devel (144 mails)

< Previous Next >
[yast-devel] optimization opportunities in the ycp -> ruby conversion

two topics re y2r (i know i'm horribly late to the party).

1. procedural vs. object-oriented ruby

the generated ruby code consists, to a large degree, of function
calls emulating semantics of basic ycp operations: Builtins.foreach,
Ops.add, etc. these functions are @deprecated, meaning we should go
and replace them with native ruby equivalents after checking that
the conversion is safe.

the point of these emulations is that ycp's nil is a NullObject, you
can iterate it like an empty hash or list, you can add it to a number
(you'll get nil back), you can concat it with a string or list
(same), whereas in ruby you need to if/else around it as stuff like
nil.each generates NoMethodError exceptions.

but, after perusing ops.rb, builtins.rb, and a few .rb files in
yast-installation/, it seems to me that we could have a much more
natural-looking ruby code if, instead of having Ops.add all over the
place we went for Yast::String#+, Yast::Array#+, etc. it seems
there's not so many places where we "return nil", and we could
"return", "return" etc in such

2. optimization/simplification opportunities in y2r

this might not be a representative example, i haven't seen it all.
i looked through yast-installation/src/clients/desktop_finish.rb
for opportunities to remove some Builtin.foreach calls. it took
me about 30 minutes (first encounter with builtins.rb, ops.rb etc)
to realize that there's *no reason* for @desktop_order to be pulled
through Builtins.foreach: it's always an array. the next thing on
my mind was: if *i* can see this, why not the transpiler?

the questions here are: is it too late now? if yes, is ther a tool
that would let us transform the ruby code? (pls no sed(1) jokes ;)
i can see how adding such optimization phases to y2r could require
slight changes (hints) to the ycp code, and i don't expect it to do
inter-module analysis (though that would enable most gains).

i'm afraid that we're going to get stuck with most of the generated
code for the next 10 years. there's ~9k lines with Ops.add alone
across the generated code, total number of uses of these @deprecated
methods will be quite a bit higher, and if we're going to do the
analysis (as opposed to a computer), it'll take a very long time,
and we're bound to introduce more bugs than the computer would.

- @desktop_order is initialized with the array literal, so we know
the type
- it has no getter/setter, so no problems from those
- it is reassigned by Builtins operations called on itself; they are
guaranteed to return Array if they received one

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >