The idea is that we want to reparse everything with gwenael and kick out some strange characters. Stef On Feb 22, 2009, at 8:22 PM, Gary Chambers wrote:
Evil legacy source code... I remember such "dodgy" characters (look like withespace)...
Regards, Gary ----- Original Message ----- From: Rob Rothwell To: Pharo-project@lists.gforge.inria.fr Sent: Sunday, February 22, 2009 3:01 PM Subject: Re: [Pharo-project] [update] #10241
Wow. I bow to the depths of the Squeak neural connections that must be going on in your brain...
I can only seem to find stuff like that in procedural languages when I don't know the system at all.
Anyway, you are right! All I did was recompile PluggableTextMorph>>drawOn: and Smallalk condenseChanges ran to completion.
I'm not quite sure how to test the Trait problems mentioned at the beginning of the thread to see if they are fixed by this, though...
Rob
On Sun, Feb 22, 2009 at 9:25 AM, Adrian Lienhard <adi@netstyle.ch> wrote: Found it...
PositionableStream>>#backChunk chokes on parsing the preamble of PluggableTextMorph>>#drawOn:. String>>#asCharacter is the method that comes just before #drawOn: in the changes file:
---------- !String methodsFor: 'converting' stamp: 'marcus.denker 2/20/2009 20:16' prior: 31206904! asCharacter "Answer the receiver's first character, or a strange round non-ascii character if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·]! ! !PluggableTextMorph methodsFor: 'drawing' stamp: 'marcus.denker 2/20/2009 16:30' prior: 27409324! drawOn: aCanvas ----------
When parsing #asCharacter, the UTF8 encoder fails with an errorMalformedInput because it seems to read back to the strange dot character.
The question is whether this character should not be used, or whether parsing is bogus. Looking at #backChunk and related methods, latter seems possible. Looks a bit fishy with sends to #oldBack, #oldPeekBack, but also to #back. Damien, can you verify your changes in these methods?
As a workaround recompiling PluggableTextMorph>>#drawOn: solves the problem (because then the source position of this method is moved away from the asCharacter method).
Adrian ___________________ http://www.adrian-lienhard.ch/
On Feb 22, 2009, at 14:18 , Adrian Lienhard wrote:
I'm debugging it right now.
What you see are only secondary symptoms because the debugger cannot read the sources anymore because the source pointers have already been modified but the sources file is still the old one...
To avoid this and still see the problem, modify #moveChangesTo: to not move the source (moveSource: false).
The actual problem seems to be related to UTF8 conversion or stream positioning (UTF8TextConverter>>errorMalformedInput). Backlog attached.
Adrian
<SqueakDebug.log>
On Feb 22, 2009, at 14:00 , Stéphane Ducasse wrote:
I added a trace in condenseChanges
PluggableTabBarMorph PluggableTabButtonMorph PluggableTextAttribute PluggableTextEditorMorph PluggableTextFieldMorph PluggableTextMorph (and is Undeclared) (See is Undeclared) (Unless is Undeclared) (works is Undeclared) (Portions is Undeclared) (Copyright is Undeclared)
Stef
On Feb 22, 2009, at 1:50 PM, Stéphane Ducasse wrote:
I tried - to recompile the method licenseString on Smalltalk - remove it completely from the system
I still get the same problem
Stef
On Feb 22, 2009, at 12:21 PM, Stéphane Ducasse wrote:
Adrian in 10241 when i did Smalltalk condenseChanges
I got a ClassDescription
syntax error on the license
" use and modification subject to a liberal open source license. See the main Squeak website for details. Unless stated to the contrary, works submitted for incorporation into or for distribution with Squeak shall be presumed subject to the same license.
Portions of Squeak are:
Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. Copyright (c) 1997-2001 Walt Disney Company, and/or Copyrighted works of many other contributors. All rights reserved. '
"
I think that fixing the condensing is the next key items since now we cannot work with Moose anymore. The changeset is getting too close to the limit.
Stef
On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote:
#10241
Issue 167: - Traits implementation refactoring (no sharing of compiled methods and source) - New tests for Traits MOP
Since this changes the handling of sources, the following issues with condensing changes may be resolved: http://code.google.com/p/pharo/issues/detail?id=466 http://code.google.com/p/pharo/issues/detail?id=470
Can somebody check these issues?
Adrian ___________________ http://www.adrian-lienhard.ch/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project_________... Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project