[squeak-dev] [Chronology] removing line feeds, fix underscores

I did some housekeeping on some classes in Squeak Chronology that had
line feed characters embedded in method source and class comments. Along
the way I updated the underscore assignments to := and made some trivial
cosmetic fixes. I retained the original author initials and method
timestamps throughout, because all changes involve either the adding
or removing of non-printable control characters, or the removal of
an unnecessary $. at the end of a method (this was to trick Montecello
into accepting the changes).

If you are updating your image through the update stream, these fixes
are effective as of Kernel-dtl.176.mcz in source.squeak.org/trunk.

This is intended to resolve Mantis 5229: "Linefeeds in 22 Methods in
3.9g-7061" and Mantis 5675: "Many method sources and class comments
have been contaminated with Character lf".

Dave

David T. Lewis wrote: Sorry David, Andreas,

I know you are patting yourselves on the back at how finally things are
moving forward. But I think that this is illustrative of the problem I
have with this process. What use is trunk to me now?

The process of building a new release relies upon existing external
packages being updated to their latest versions. Those latest versions
have been written to work in 3.10.2 not trunk.

So it is not a good idea to base the build process of the next release
upon trunk, especially because the build process out of necessity starts
with 3.10.2 and is geared to providing a 3.10.3 as well as a 3.11

Every commit to trunk is more stuff that has to be redone in another
form to be useful.

Keith

On Sat, Jul 11, 2009 at 10:55:25PM +0100, Keith Hodges wrote:
> >  
> Sorry David, Andreas,
>
> I know you are patting yourselves on the back at how finally things are
> moving forward. But I think that this is illustrative of the problem I
> have with this process. What use is trunk to me now?

All I did was remove some <lf> characters from the method sources. This
hardly constitutes evidence of "things moving forward" ;)

Dave

David T. Lewis wrote: A task that scans the whole image and performs this tidy up would be cool

Keith

David T. Lewis wrote: The plan for Chronology is to have a Kernel-Chornology.knl a kernel
version of Chronology, and the rest as an externally loaded package.

Keith

On Sat, Jul 11, 2009 at 11:23:58PM +0100, Keith Hodges wrote:
> David T. Lewis wrote:
> >
> > All I did was remove some <lf> characters from the method sources. This
> > hardly constitutes evidence of "things moving forward" ;)
> >  
> A task that scans the whole image and performs this tidy up would be cool

Sure, and thanks to Ned Konz we have:
  SystemDictionary class>>removeAllLineFeeds

And thanks to Bert Freudenberg we have:
  FixUnderscores class>>fixPackage:

In the case of line feed removal, the tricky thing was to convince
Monticello to see the methods as "changed" to make the fix stay fixed.
I did this manually with a vi editor (sorry, it's crude but it worked).
The class comments were worse. I resorted to saving the updates with
an extra (bogus) class variable to make it look like the classes had
changed, followed by another update to get rid of the bogus class
variables. Nothing elegant about it, but hopefully the fixes will stick
now that they are saved in an archive.

Dave
 

Hi Keith,

Bernhard Pieber wrote: Because the fixes that will be applied have all been developed and
submitted relative to 3.10. The packages that you update to the latest
versions will all have been developed against 3.10.

Using your method you would have to generate the new image, without the
latest of anything, or the fixes, and then wait for everyone to sift
through the fixes and make them relative to your version, which kind of
defeats the object. It is already risky enough applying fixes en-masse
for testing, since there may be clashes.

If you do follow you plan, the fixes in mantis are now against some
indeterminate version, and cant be used by existing 3.10 users in their
existing 3.10 images. This leaves production images and forks based upon
3.10 without fixes that they can apply.

Secondly the knowledge that you are putting into trunk is not organised
into separate portions, it is effectively ad-hoc. Therefore I don't know
what I am adding and what I am not. Documentation of the changes is is
not automatically generatable, and furthermore I cant publish this
knowledge in a form that is useful to Cobalt, or any of the other squeak
forks.

This leaves the Cobalt guys to plough through the history of 40+
packages to findout what you have done. This wont happen so the forks
wont get much closer together.

Thirdly, it would be better for everyone if the same effort was put into
picking a specific project or subsystem that is worked on as an
engineered task, plans, specs, defined interfaces etc, in such a way as
all forks could benefit.

regards

Keith

Hi David,

Thanks for the cleanup.

Am 12.07.2009 um 01:00 schrieb David T. Lewis:
> In the case of line feed removal, the tricky thing was to convince
> Monticello to see the methods as "changed" to make the fix stay fixed.
> I did this manually with a vi editor (sorry, it's crude but it  
> worked).
I wonder why? Does Monticello not compare the method source but the  
compiled method?

> The class comments were worse. I resorted to saving the updates with
> an extra (bogus) class variable to make it look like the classes had
> changed, followed by another update to get rid of the bogus class
> variables.

Does someone know if this is fixed in Monticello 1.6? I was looking  
for overview about what bugs were fixed but did not find anything on  
the Swiki.

Cheers,
Bernhard

I would rather see the process as integrating selected elements of the
trunk to a release. The trunk is community development after all. It
does not go under the same preparation as a release, which is, most
likely, to be frozen and moved to a release repository. Now, why we
don't use 3.11 as the trunk... I have no clue...

There should be some way to integrate one to another.

Regardless, tests should still have a meaningful place in 3.11 as well as 3.10.

Ian.

--
http://mecenia.blogspot.com/

Bernhard Pieber wrote:
> I am not sure if I understand correctly what you mean by "developed
> against 3.10". Do you mean a certain image
> like Squeak3.10.2-7179-basic? You probably don't mean that if I want
> to fix or improve something I should always do that in a certain
> image, do you? I thought you were deemphasizing that everyone uses the
> same image.
The idea of a release is a little bit broader than it was before. It is
more of a conceptual entity than simply an image. The release does
consist of the image, but it also includes the set of packages that will
load and unload from that image. In effect it is a snapshot of the
entire state of our fork at a particular time. The release team will
release an image, but at the same time, all of the derived distros will
also be available.

When you publish a fix, it has to be against a known quantity, because
those looking to harvest your fix into another fork of squeak, need to
know the starting point in order to see exactly what you did and why in
order to determine how to apply that fix to their fork. If the fix is a
new bit of API, for example 5669, then perhaps the underlying code will
be different for them. Another most important thing to capture is design
intent, and having some discussion recorded in mantis can help with that. Bob can build a new image every time the status of a fix changes in
mantis if we want. But you wouldn't necessarily need to download this
image immediately since bob will run the tests as well, and you will be
able to see the test results remotely.
> Sorry, it seems my misunderstanding is even bigger than I realised. I
> am trying hard not to be dense. ;-) So, how often would you take a new
> image in your proposed process?
It depends upon what you are working on.

Since you are developing stuff against the fixed point, you only really
need 3.10.2-build which is the base that everyone is working to.

If you want to see the final integration, then you can take a new build
daily if you want.

If you are working on a project of your own then you might prefer to run
your own bob server, that could build the latest with your project included.
> Would Bob be one central server, or would everyone have his own Bob?
Both... the individual tasks that bob is working are published
publically so anyone can subscribe their own bob to any build.

If you want to define a build without running bob locally you simply
need to get the centralised/public Bob(s) to subscribe to your task that
you upload to Bob/Tasks-Distros or Bob/Tasks-Releases
> As every package version has a comment it seems certainly possible to
> generate all the changes in trunk. What am I missing?
I am assuming that any significant refactoring which includes both
subsystem and client code is unlikely to be restricted to a single
package. We need to capture the knowledge of changes to both
I very much doubt that the majority of packages are mergeable simply.
The client code for any package API change could be all over the place.

does that help make things clearer?

Keith
>
> Sorry but I am still confused. ;-)
>
> Cheers,
> Bernhard
> ------------------------------------------------------------------------
>
>
>