On Friday 14 September 2007 12:02, Klaus Kaempf wrote:
I've been wondering for a long time if we shouldn't seriously consider to handle the byte code the same way Perl does: Byte-compile "on the fly" and keep the byte code just in memory, never write it to disk. IMHO this would make handling YCP code _much_ easier.
What are the problems with the current way of pre-compiling exactly ?
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.
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. 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).
I'd also like to know more about the size of the mentioned problem.
Where have you been in the last couple of years? SCNR 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. 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. 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'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.
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.
Whats the effect on the developer ?
Less ulcers.
CU
--
Stefan Hundhammer