[Pharo-project] What about #ifNotNil and #ifNotNilDo:
Hi, is there a way to get the #ifNotNilDo: behavior to write compatible Squeak and Pharo code? Bye -- Damien Cassou http://damiencassou.seasidehosting.st
On 21.02.2009, at 18:31, Damien Cassou wrote:
Hi,
is there a way to get the #ifNotNilDo: behavior to write compatible Squeak and Pharo code?
-> do not use ifNotNilDo: -> use ifNotNil: without the argument. The real fix of course would be for Squeak adopting the optinal args changeset (this is from 2007...) Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Yeah, simply don't use #ifNotNilDo: and friends. If you follow the coding conventions of Seaside your code will basically run anywhere <http://www.seaside.st/community/conventions>. Slime also contains rules to automatically refactor non-portable code, for example: ansiCompatibilityConditionals ^ self rewrite: #( " kill abnormalities " ('``@boolean ifNotNilDo: ``@block' '``@boolean ifNotNil: ``@block') ('``@boolean ifNotNilDo: ``@block1 ifNil: ``@block2' '``@boolean ifNotNil: ``@block1 ifNil: ``@block2') ('``@boolean ifNil: ``@block1 ifNotNilDo: ``@block2' '``@boolean ifNil: ``@block1 ifNotNil: ``@block2') " normalize arguments " ('``@boolean ifNotNil: [ | `@temps | ``@body ]' '``@boolean ifNotNil: [ :arg | | `@temps | ``@body ]') ('``@boolean ifNotNil: [ | `@temps | ``@body ] ifNil: ``@block ' '``@boolean ifNotNil: [ :arg | | `@temps | ``@body ] ifNil: ``@block') ('``@boolean ifNil: ``@block ifNotNil: [ | `@temps | ``@body ]' '``@boolean ifNil: ``@block ifNotNil: [ :arg | | `@temps | ``@body ]')) methods: false name: 'ANSI Compatibility: Conditionals' Cheers, Lukas On Sun, Feb 22, 2009 at 10:22 AM, Marcus Denker <denker@iam.unibe.ch> wrote:
On 21.02.2009, at 18:31, Damien Cassou wrote:
Hi,
is there a way to get the #ifNotNilDo: behavior to write compatible Squeak and Pharo code?
-> do not use ifNotNilDo: -> use ifNotNil: without the argument.
The real fix of course would be for Squeak adopting the optinal args changeset (this is from 2007...)
Marcus
-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Marcus Denker wrote:
On 21.02.2009, at 18:31, Damien Cassou wrote:
Hi,
is there a way to get the #ifNotNilDo: behavior to write compatible Squeak and Pharo code?
-> do not use ifNotNilDo: -> use ifNotNil: without the argument.
The real fix of course would be for Squeak adopting the optinal args changeset (this is from 2007...)
Marcus
ok, we shall add that to LPF, where is it? You see the purpose of LPF is to be able to make these changes in such a way as to liberate pioneers such as yourselves to move forward. We can offer this fix to the majority of squeak users, and this preserves the backward compatability, in a forward thinking way. 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? cheers Keith
On 22.02.2009, at 19:04, Keith Hodges wrote:
Marcus Denker wrote:
On 21.02.2009, at 18:31, Damien Cassou wrote:
Hi,
is there a way to get the #ifNotNilDo: behavior to write compatible Squeak and Pharo code?
-> do not use ifNotNilDo: -> use ifNotNil: without the argument.
The real fix of course would be for Squeak adopting the optinal args changeset (this is from 2007...)
Marcus
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/
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. Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
I am highly skeptical about LPF.
Sorry if I missed some emails. What is LPF? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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:
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 -- denker@acm.org http://www.marcusdenker.de
Hi all! Marcus Denker wrote:
On 22.02.2009, at 19:31, Marcus Denker wrote: As soon as there are changesets that touch the same code, it starts to get *very* messy.
Which is one of the things that Deltas (in DeltaStreams) tries to deal better with. Let me explain quickly for those that do not know the idea: A Delta is "ChangeSet improved". It is an *ordered* list of changes instead of a Set. So ChangeList would be another good name. :) But that is not all it is, it also: - Models each kind of change using a unique class in much finer detail. Like "AddInstVarChange" for example. This creates the potential to be much "smarter". - Each change captures the "before state". This is very important - it doesn't only hold the "new method" but also the old one. (a diff could of course also work, that is just implementation details) - A Delta can be loaded into the image *before* it is installed. Thus you can operate on a Delta and analyse it before applying it. This is VERY important. - A Delta is *fully self contained*. It does not just "point to a method" like ChangeSet does. Thus, no matter how much the image changes - the Delta is totally isolated and totally independent of the image. - It can also be unapplied. Now... one use case that I wanted to be able to do with Deltas is to be able to load 100s of Deltas into an image (remember - they are not *installed* when only being loaded) and then *analyse* them in tons of ways like for example: - Can they be "cleanly applied"? One definition of "clean" is that the "before state" matches the image. - Can they be "dirtily" applied? One definition of "dirty" is that the before state does NOT match, but we can still apply it. Given say a Delta with a single method change - and the whole class is missing - then we can't apply it at all. But if the class exists - but with a DIFFERENT version of the method than the captured "before state" - we can apply, although possibly overwriting other changes. Since Deltas can be applied and unapplied we can start playing with "patch queues" like Mercurial and other systems have. So let's say you load 42 Deltas from some strange places - perhaps totally independent of each other. You look at them, the tool tells you that well, 37 can be cleanly applied "one by one" and 2 can be dirtily applied, and 3 are dead ducks. Ok, so you tell the tool to fine, group them by developer and sort them chronologically and analyze them in groups one by one. Then it might say that, sure first 2 groups from Marcus comprising 23 Deltas would apply fine - then it get's stuck on one of the dead ducks in group 2 from Andreas :). So you feel brave and tell the tool to fine - apply those first 2 groups of 23 (in total) so we can run tests being touched by those 23. The tool should be able to figure out a reasonable Set of tests that are affected given classes being modified and referenced by tests. Perhaps some tests turn red, so you tell the tool to unapply Deltas *one by one* (until the tests are green again, perhaps it ends up with 17 applied but the 18th caused the problem. It could even do a binary search. :) The dead ducks may be because of class renames. Tool could again try to find the right class for you. I am blabbering, but as you can see having working Deltas could enable a whole *range* of interesting tools that can operate *regardless* of history. Just writing about it makes me want to pick it up again where we left off. And no, this is not purely hype-code - a lot of stuff actually works today, including unapply. regards, Göran
Hi,
is there a way to get the #ifNotNilDo: behavior to write compatible Squeak and Pharo code?
-> do not use ifNotNilDo: >> -> use ifNotNil: without the argument. >> >> The real fix of course would be for Squeak adopting the optinal args >> changeset >> (this is from 2007...) 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.
Marcus Hello Marcus,
I don't think that you understand, LPF is only about providing a leg up for the older code, a migration path for fundamental stuff, like Monticello. You appear to have adopted the view that LPF ( http://installer.pbwiki.com/LevelPlayingField ) is supposed to make the whole image up to the same level for everyone. It isn't, it works for what it was intended to do, that is to provide Installer/MC/MCC/Sake/Packages/PackageInfo for all images. In this case, I do hope that Pharo hasn't made thousands of changes which prevent code from loading and compiling in Squeak. That is the issue that ifNotNil: [ :a | ] and Author raises, Syntax errors on loading. I am sure that LPF can help there in the majority of cases. Most projects are built in layers, the fundamental layers, once ported may support other layers across all images. LPF is primarily about loading code across images. Getting that code to work is another problem entirely which LPF may help with, but is not expected to solve. Perhaps a concrete example might help illustrate what the issues really are: You guys developed your Monticello for 3.9, and it wasn't compatible with 3.8, 3.8 code loaded into 3.9 but not the other way around, and the 3.9 Monticello implementation itself was never designed to be loaded in 3.8. In short the 3.8 Monticello became dead to innovation (a fork by default rather than by design), and unmaintained overnight, as did a lot of 3.8 code. This is the issue that LPF was designed to address. The purpose of LPF is to help prevent projects getting completely stuck on one image, particularly to enable projects stuck in 3.8 to move to 3.10. When you want to port a large commercial project from one image to another you want to support your existing users in the old image at the same time as working on the next version in the new base image.. You want to continue to manage your packages simply without having to keep two separate branches. MC in 3.9 would not save mcz files that would load into 3.8, and this fact alone was a real barrier to moving things forward. The new 3.11 development process, aims to address this. Tools, fixes, and API's that may be included in 3.11, will be developed and usable in 3.10. So both the current user base in 3.10, and the early adopters in 3.11 are able to use identical API's and Tools, and migration is both possible and probable. The traditional approach that Pharo is using produces a new image, developed by a new team as a complete break from the past, and everyone is forced to code to a moving target. This is the process that squeak has been using since before the flood, and it is this process that I have identified as the problem. (I accept that I may be wrong) I myself haven't adopted Pharo, not because you aren't making good changes, or making things better, but because your development process guarantees that there will be problems down the line. Not only do you make it difficult for me to port my current deployments to Pharo with anything other than a step change, since that is your avowed intent. But also Pharo 2 will inevitably be incompatible with Pharo1 and so on, due to the process. I thank the pharo team for performing lots of useful research on behalf of the squeak community, I expect that we will be able to adopt most of your innovations, but this will take time, and will be carefully considered, with the backward compatabiity issue in mind. regards Keith
On 22.02.2009, at 22:42, Keith Hodges wrote:
The traditional approach that Pharo is using produces a new image, developed by a new team as a complete break from the past, and everyone is forced to code to a moving target. This is the process that squeak has been using since before the flood, and it is this process that I have identified as the problem. (I accept that I may be wrong)
So nobody is actually *using* 3.11? (would 4.1 the name of it now?) The problem I see here is that this 3.11 will not have been tested at all. Is that correct?
I myself haven't adopted Pharo, not because you aren't making good changes, or making things better, but because your development process guarantees that there will be problems down the line. Not only do you make it difficult for me to port my current deployments to Pharo with anything other than a step change, since that is your avowed intent. But also Pharo 2 will inevitably be incompatible with Pharo1 and so on, due to the process.
Yes. Beeing incompatible with the past is the only way to make progress.
I thank the pharo team for performing lots of useful research on behalf of the squeak community, I expect that we will be able to adopt most of your innovations, but this will take time, and will be carefully considered, with the backward compatabiity issue in mind.
Pharo is not Research. Research you can find here (for example): http://www.iam.unibe.ch/~denker/mdpubs.cgi?byCategory Enabeling Software Evolution one of the themes of that Research, interestingly. The direction this is going might get clearer from a quote from http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Nier08a : Backward compatibility is the enemy of forward-evolvability. Nevertheless, we cannot live in a world were the old is ignored. A snapshot of an old Windows machine can run on a virtual machine forever, whereas keeping an operating system compatible forever will be bound to fail. Programming languages for eternal systems should provide backwards compatibility in the same way: we need a first class description of the history of all code of the system, freeing the present from being compatible with the past while at the same time providing the possibility to go back in time easily. The system should provide complete, runnable snapshots of the system at any point in the past. Eternal systems need languages that support continuous development and evolution. But there is another aspect to the language: to think that we can envision the perfect language to realize all future systems is to treat language design like a finite game. Thus a language suited for implement- ing ever-evolving, eternal software systems needs to be itself an eternal program. An eternal language must evolve to incorporate new ideas and practices while it is used. It needs to be extensible and growable from within. Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
participants (6)
-
Alexandre Bergel -
Damien Cassou -
Göran Krampe -
Keith Hodges -
Lukas Renggli -
Marcus Denker