On 22.02.2009, at 19:31, Marcus Denker wrote: >>> >> ok, we shall add that to LPF, where is it? >> > > http://bugs.squeak.org/view.php?id=6426 > > The solution is to adopt vasilie's fix: > > http://blog.3plus4.org/2007/04/22/notnil-then-what/ >
I added a comment to the squeak bugtracker to suggest that this should be done. >> >> What would help though is if you told us what you are changing/ >> breaking >> so that we can do something about it. The Author class is another >> incompatibility issue that I expect to have to address via LPF. Are >> there any more? > > Thousands. Literally. > > I am highly skeptical about LPF. To clearify: I am not skeptical about the *intention* of LPF. I am only very sure that it is impossible to do. Especially considering complexity involved and the interdependencies of changesets. e.g. we will soon check this fix for the ifNotNil stuff: http://code.google.com/p/pharo/issues/detail?id=327 this for sure overrides code touched by the changeset of vasili. So, in turn, LPF can not just load the original changeset for pharo, as it will revert the fix. Then, do Lukas compiler changes for literal byte-arrays touch the same methods? They should not, but are you sure? So you need to check this, by hand.... As soon as there are changesets that touch the same code, it starts to get *very* messy. (it's the same reason why overrides do not work. I override a method, second package overrides same method. So my changes are reverted. Ups. So I fix my package to take the changes into account. Now two things happen: 1) dependency. my package can only be installed *after* the other package. 2) un-installing. Un-installing, even if you track the method's versions, can only be done in reverse-order of installation, and thus is useless for most cases). Inter-dependencies of changesets is something that I completely underestimated at first. Another thing that is true especially for Squeak is that changes have a very non-linear effect: everything is entangled. That means that things depend on each other in ways that are absolutely astonishing. You change something small, and it breaks something else in a way that you would bet your house on that it would have no effect. (like changing a method comment for a good joke braking compacting of the .changes, as we saw today). This means, there is nothing else that one can do then *testing*. And as sooner code is in general use, the sooner it will get more stable. There is no other way to work on Squeak than in tiny increments and "release early, release often". Everyting else *will* fail. Marcus -- Marcus Denker -- [email protected] http://www.marcusdenker.de _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
