More problems with condenseSources

Hi Folks -

I just noticed that after executing #condenseSources the sources file
was very subtly broken. Digging into the issue I discovered the bug
reported at http://bugs.impara.de/view.php?id=3458

I'm posting this here too, since I need at least a workaround for this
issue. Any ideas?

Thanks,
   - Andreas

  Andreas,

  An ok "workaround" I think of is to use attached method from
#copyPreamble:from:at:

with a line like:

        (i _ last50 findLastOccuranceOfString: 'stamp:' startingAt: 1 after: '! !') > 0 ifTrue:


At Tue, 11 Apr 2006 14:06:45 -0700,
Andreas Raab wrote:

Andreas Raab <[hidden email]> wrote...

>I just noticed that after executing #condenseSources the sources file was very subtly broken. Digging into the issue I discovered the bug reported at http://bugs.impara.de/view.php?id=3458
>
>I'm posting this here too, since I need at least a workaround for this issue. Any ideas?

Hi, Andreas -

I don't have a good test-bed for this problem, but I suggest the following workaround...

In method
        PositionableStream>>copyPreamble: preamble from: aStream at: pos
replace...
        (i _ last50 findLastOccuranceOfString: 'stamp:' startingAt: 1) > 0 ifTrue:
                [stamp _ (last50 copyFrom: i+8 to: last50 size) copyUpTo: $'].
with...
        (i _ last50 findLastOccuranceOfString: 'stamp:' startingAt: 1) > 0 ifTrue:
                [stamp _ (last50 copyFrom: i+8 to: last50 size) copyUpTo: $'.
                "Catch the most likely invalid stamp..."
                (stamp includes: $!) ifTrue: [stamp _ String new]].

Hope this helps.

        - Dan

PS:  It's not a method to be proud of (that's why I felt compelled to respond ;-) but, since it's been around for a looong time, it may be that this workaround is good enough to be included as a bug fix.

Thanks Dan and Yoshiki. While digging around some of the code I ran into
#backChunk which was new to me and actually does the Right Thing (tm) by
merely reading the previous chunk instead of an arbitrary number of
characters (Yoshiki's fix failed in situations where we have short names
since when using MultiByteFileStream it's reading the last 100 chars
which might easily include more than a single method).

I'll post the fix I've developed as soon as I have verified it.

Cheers,
   - Andreas

Dan Ingalls wrote:

  Andreas,

> Thanks Dan and Yoshiki. While digging around some of the code I ran into
> #backChunk which was new to me and actually does the Right Thing (tm) by
> merely reading the previous chunk instead of an arbitrary number of
> characters (Yoshiki's fix failed in situations where we have short names
> since when using MultiByteFileStream it's reading the last 100 chars
> which might easily include more than a single method).

  Uh, because mine checks the last occurence of '! !' (which should be
at the end of each method), short names should be fine.  But,
#backChunk, though looks like slower, should do the right thing, yes.

-- Yoshiki

  Duh, forget about this.  I meant to loop to find the last occurence
of given argument in the method, but the implementation actually
doesn't do it...

-- Yoshiki

At Tue, 11 Apr 2006 15:48:16 -0700,
Yoshiki Ohshima wrote: