Mailinglist Archive: yast-devel (144 mails)

< Previous Next >
Re: [yast-devel] optimization opportunities in the ycp -> ruby conversion
1. procedural vs. object-oriented ruby


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

This was considered and rejected. Going this way would mean that either new code would also need to use Yast::String, Yast::Array, etc., or would have two parallel systems in one codebase. I found both highly undesirable -- much more than Ops.*, etc. Going with native classes is more future-oriented and simpler.

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?

We were operating under the constrain that we need to ship in openSUSE 13.1 (to be included into SLE12). No sophisticated static analysis leading to the optimizations you describe was possible in that time frame with our resources.

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 think we should forget YCP now and do any optimizations purely on Ruby code. That said, I don't know about any tools that could help us with that significantly.

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.

I agree and I would be against mass changes without help of some tools.

In reality, I think most code will stay in the current form because it is not touched too much. For active code, I suppose it will be converted into more Ruby-like style gradually as people will work on it.

David Majda
SUSE Studio developer
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >