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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <[hidden email]> wrote:


--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Marcus Denker wrote: 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 22.02.2009, at 19:04, Keith Hodges wrote:

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  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> I am highly skeptical about LPF.

Sorry if I missed some emails.
What is LPF?

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 22.02.2009, at 19:31, Marcus Denker wrote:
I added a comment to the squeak bugtracker to suggest that this should  
be done.

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  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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?

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  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project