Stefan Hundhammer wrote:
Combining all the downsides of a compiler with most of the downsides of an interpreter. You have to explicitly byte-compile stuff you change. If you forget it, you are in trouble. And you might not even notice it. You can do changes all day long without any effect.
For example, that makes inst-sys debugging even more painful than it already is.
If you have to change a module, you have to remember to byte-compile all other modules (just the modules, not regular YCP files) that import it. And since there are a zillion dependencies between all of them, you have to do that in the right order. Otherwise you will have a lot of fun trying to debug upcoming problems.
I've been debugging update inst-sys' YCP modules for a while and I can't say that it would be so hard. Even compiling every single that uses the changed one is not needed (unless you need the new API, of course :) )
How to deal with syntax errors resulting in a failed load ?
Just like we do with syntax errors with all other (non-module) YCP code.
Having a pure interpreter does not obviate the need for proper development, for unit tests, for all kinds of tests you can do before the code hits the customer. Of course.
Bytecode prevents from making more errors (customer focus), because when compiling it, ycpc checks all the syntax (in a RPM-build-time at least). And I additionally like the speedup from pre-compiled modules. Simple syntax check on a quite big script is just "too much" (that's the reason why I had to split some installation scripts into more smaller ones). Once we check the syntax in a build-time, we don't need to check it anymore and it returns hundred times for every single installed system.
But since we are really inconsistent with our handling of byte code, exactly what's the difference? I could understand that concern if we byte-compiled everything. But we don't. We have more checks (due to byte compilation) for some code (the modules) and less checks for other code. Both kinds of code will affect the customer: If any does not work due to syntax errors, the customer will get a show-stopper (one or some YaST apps won't work for him).
Calling 'make package' should check the syntax of clients as well.
Building YaST2 is a pain. We all know that. Much of that pain comes from interdependencies of all the different parts of the code. We can't do very much about that for the C++ code, but it should really not hit us so badly for the YCP code, too. We've been throwing much of the advantage of having an interpreted language over board. Most of that is the result of having to byte-compile YCP code, and, worse, doing that in the correct build order.
Well, yes, the correct build order. But you'd need the correct YCP modules anyway and some cross-dependencies or loop-imports might appear later.
There are different approaches and different tools for that. Some developers simply hope they won't ever have to do it. That's OK for purely leaf packages. Other developers never leave their private sand box and simply never do "svn up" because when they do they are in big trouble.
My 10.2 has a new 10.3's libzypp and yast2-core installed because I always need the latest one (when developing or testing installation features).
Some use tools like "y2makeall" which essentially recreate much of autobuild's internal logic, including carefully hand-crafted exception rules to manually throw out cyclic or broken (sic!) dependencies.
I hope that 'zypper --upgrade' (or whatever) could help here a lot. My solution is to keep my YaST (and related) packages up-to-date with /work (FACTORY) and time to time compile something needed from SVN.
I'd really like to go back to the days when handling YCP code was as simple as having the Makefile call "install" for each file, just copying to its target location. That was _so_ much simpler and _so_ much less error-prone.
Honestly, I don't remember that so I can't compare :)))
Whats the effect on the customer when module compilation is done on-the fly?
That's what we have to find out, preferably in hard numbers, taken from real-life code.
Slower YaST, more errors that appear during the runtime instead of the compile-time. That's also why I prefer writing modules in YCP to writing them in Perl. Anyway, this mail doesn't mean "I wanted to have the opposite opinion to HuHa's" :) I just wanted to add pros and cons I feel we should consider too. Bye Lukas