Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
Item was changed: ----- Method: Base64MimeConverter class>>initialize (in category 'as yet unclassified') ----- initialize
FromCharTable := Array new: 256. "nils"
ToCharTable := ($A to: $Z) , ($a to: $z) , ($0 to: $9) , '+/'.ToCharTable keysAndValuesDo: [:ind :char |FromCharTable at: char asciiValue + 1 put: ind - 1].!
ToCharTable := Array new: 64.($A asciiValue to: $Z asciiValue) doWithIndex: [:val :ind |FromCharTable at: val+1 put: ind-1.ToCharTable at: ind put: val asCharacter].($a asciiValue to: $z asciiValue) doWithIndex: [:val :ind |FromCharTable at: val+1 put: ind+25.ToCharTable at: ind+26 put: val asCharacter].($0 asciiValue to: $9 asciiValue) doWithIndex: [:val :ind |FromCharTable at: val+1 put: ind+25+26.ToCharTable at: ind+26+26 put: val asCharacter].FromCharTable at: $+ asciiValue + 1 put: 62.ToCharTable at: 63 put: $+.FromCharTable at: $/ asciiValue + 1 put: 63.ToCharTable at: 64 put: $/.!Item was changed: ----- Method: Character class>>initializeClassificationTable (in category 'class initialization') ----- initializeClassificationTable " Initialize the classification table. The classification table is a compact encoding of upper and lower cases of characters with
- bits 0-7: The lower case value of this character. - bits 8-15: The upper case value of this character. - bit 16: lowercase bit (e.g., isLowercase == true) - bit 17: uppercase bit (e.g., isUppercase == true) " | ch1 | LowercaseBit := 1 bitShift: 16. UppercaseBit := 1 bitShift: 17. "Initialize the letter bits (e.g., isLetter == true)" LetterBits := LowercaseBit bitOr: UppercaseBit. ClassificationTable := Array new: 256. "Initialize the defaults (neither lower nor upper case)" 0 to: 255 do:[:i| ClassificationTable at: i+1 put: (i bitShift: 8) + i. ]. "Initialize character pairs (upper-lower case)" #( "Basic roman" ($A $a) ($B $b) ($C $c) ($D $d) ($E $e) ($F $f) ($G $g) ($H $h) ($I $i) ($J $j) ($K $k) ($L $l) ($M $m) ($N $n) ($O $o) ($P $p) ($Q $q) ($R $r) ($S $s) ($T $t) ($U $u) ($V $v) ($W $w) ($X $x) ($Y $y) ($Z $z) "International"
($Ä $ä) ($Å $å) ($Ç $ç) ($É $é)($Ñ $ñ) ($Ö $ö) ($Ü $ü) ($À $à)($à $ã) ($Õ $õ) ($Œ $œ) ($Æ $æ)
($Ä $ä) ($Å $å) ($Ç $ç) ($É $é)($Ñ $ñ) ($Ö $ö) ($Ü $ü) ($À $à)($à $ã) ($Õ $õ) ($Œ $œ) ($Æ $æ) "International - Spanish"
($Á $á) ($Í $í) ($Ó $ó) ($Ú $ú)
($Á $á) ($Í $í) ($Ó $ó) ($Ú $ú) "International - PLEASE CHECK"
($È $è) ($Ì $ì) ($Ò $ò) ($Ù $ù)($Ë $ë) ($Ï $ï)($Â $â) ($Ê $ê) ($Î $î) ($Ô $ô) ($Û $û)
($È $è) ($Ì $ì) ($Ò $ò) ($Ù $ù)($Ë $ë) ($Ï $ï)($Â $â) ($Ê $ê) ($Î $î) ($Ô $ô) ($Û $û) ) do:[:pair| | ch2 | ch1 := pair first asciiValue. ch2 := pair last asciiValue. ClassificationTable at: ch1+1 put: (ch1 bitShift: 8) + ch2
UppercaseBit. ClassificationTable at: ch2+1 put: (ch1 bitShift: 8) + ch2
LowercaseBit. ].
"Initialize a few others for which we only have lower caseversions."
#($ß $Ø $ø $ÿ) do:[:char|
#($ß $Ø $ø $ÿ) do:[:char| ch1 := char asciiValue. ClassificationTable at: ch1+1 put: (ch1 bitShift: 8) + ch1
- LowercaseBit. ]. !
Item was changed: ----- Method: String>>asCharacter (in category 'converting') ----- asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·]!
^ self size > 0 ifTrue: [self first] ifFalse:[$·]!Item was changed: ----- Method: Text>>printStringHtml:on: (in category 'html') ----- printStringHtml: aString on: aStream | html | html := aString. "" html := html copyReplaceAll: '&' with: '&'. html := html copyReplaceAll: '>' with: '>'. html := html copyReplaceAll: '<' with: '<'. ""
html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬®¬¨¦Ö' with: 'á'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬®¬¨¬©' with: 'é'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬®¬¶¦ë' with: 'í'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬®¬¶¦ü' with: 'ó'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬®¬¶¬ö' with: 'ú'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬®¬¨¬±' with: 'ñ'.
html := html copyReplaceAll: '�������鬨�����Ö' with: 'á'.html := html copyReplaceAll: '�������鬨�����©' with: 'é'.html := html copyReplaceAll: '�������鬨�����ë' with: 'í'.html := html copyReplaceAll: '�������鬨�����ü' with: 'ó'.html := html copyReplaceAll: '�������鬨�����ö' with: 'ú'.html := html copyReplaceAll: '�������鬨�����±' with: 'ñ'. ""
html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬Ž¬¶¦±' with: 'Á'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬Ž¬¨¬¢' with: 'É'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬Ž¬¶¦º' with: 'Í'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬Ž¬¨¬Æ' with: 'Ó'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬Ž¬¨¦©' with: 'Ú'.html := html copyReplaceAll: '¬¨¬®¬¨¬é¬¨¬Ž¬¨¬·' with: 'Ñ'.
html := html copyReplaceAll: '�������鬨�����±' with: 'Á'.html := html copyReplaceAll: '�������鬨�����¢' with: 'É'.html := html copyReplaceAll: '�������鬨�����º' with: 'Í'.html := html copyReplaceAll: '�������鬨�����Æ' with: 'Ó'.html := html copyReplaceAll: '�������鬨�����©' with: 'Ú'.html := html copyReplaceAll: '�������鬨�����·' with: 'Ñ'. "" html := html copyReplaceAll: '
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
Note that in-between, you can manually merge (I had no problem of encoding when merging)
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
If the MCZ works and the MCD does not, then whatever fix we make needs to be applied to our squeaksource server image, which generates the MCDs.
- Bert -
On 2013-07-30, at 14:59, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
A possible scenario: For some reason (?) the snapshot.bin fails. In that case, the server used the sources in .st format. But newly produced sources are in utf8 and the server is probably not utf8 aware... In which case the server re-interprets bad characters for building the .mcd and put them in patch.bin stone Makes sense?
Is it possible to backport the utf8 correction to the server ? I mean, is it going to cause forward compatibility problems ?
2013/7/30 Bert Freudenberg bert@freudenbergs.de
If the MCZ works and the MCD does not, then whatever fix we make needs to be applied to our squeaksource server image, which generates the MCDs.
- Bert -
On 2013-07-30, at 14:59, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
To me, the server should try and read in utf8, then fallback to old encoding like current trunk does. Then, whether it should continue to write with old encoding or utf8 is a question of how we want to support serving older images. Would it be possible to provide a hackish transition: create mcd with same encoding as mcz?
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
A possible scenario: For some reason (?) the snapshot.bin fails. In that case, the server used the sources in .st format. But newly produced sources are in utf8 and the server is probably not utf8 aware... In which case the server re-interprets bad characters for building the .mcd and put them in patch.bin stone Makes sense?
Is it possible to backport the utf8 correction to the server ? I mean, is it going to cause forward compatibility problems ?
2013/7/30 Bert Freudenberg bert@freudenbergs.de
If the MCZ works and the MCD does not, then whatever fix we make needs to be applied to our squeaksource server image, which generates the MCDs.
- Bert -
On 2013-07-30, at 14:59, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
FWIW, the server image is a Squeak 3.11alpha image #8824 with Monticello-bf.356. I'm afraid simply loading a current MC version is not going to work, but maybe the utf8 changes could be backported?
- Bert -
On 30.07.2013, at 22:26, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
To me, the server should try and read in utf8, then fallback to old encoding like current trunk does. Then, whether it should continue to write with old encoding or utf8 is a question of how we want to support serving older images. Would it be possible to provide a hackish transition: create mcd with same encoding as mcz?
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com A possible scenario: For some reason (?) the snapshot.bin fails. In that case, the server used the sources in .st format. But newly produced sources are in utf8 and the server is probably not utf8 aware... In which case the server re-interprets bad characters for building the .mcd and put them in patch.bin stone Makes sense?
Is it possible to backport the utf8 correction to the server ? I mean, is it going to cause forward compatibility problems ?
2013/7/30 Bert Freudenberg bert@freudenbergs.de If the MCZ works and the MCD does not, then whatever fix we make needs to be applied to our squeaksource server image, which generates the MCDs.
- Bert -
On 2013-07-30, at 14:59, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
Yes, it's a small change
2013/7/30 Bert Freudenberg bert@freudenbergs.de
FWIW, the server image is a Squeak 3.11alpha image #8824 with Monticello-bf.356. I'm afraid simply loading a current MC version is not going to work, but maybe the utf8 changes could be backported?
- Bert -
On 30.07.2013, at 22:26, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
To me, the server should try and read in utf8, then fallback to old encoding like current trunk does. Then, whether it should continue to write with old encoding or utf8 is a question of how we want to support serving older images. Would it be possible to provide a hackish transition: create mcd with same encoding as mcz?
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
A possible scenario: For some reason (?) the snapshot.bin fails. In that case, the server used the sources in .st format. But newly produced sources are in utf8 and the server is probably not utf8 aware... In which case the server re-interprets bad characters for building the .mcd and put them in patch.bin stone Makes sense?
Is it possible to backport the utf8 correction to the server ? I mean, is it going to cause forward compatibility problems ?
2013/7/30 Bert Freudenberg bert@freudenbergs.de
If the MCZ works and the MCD does not, then whatever fix we make needs to be applied to our squeaksource server image, which generates the MCDs.
- Bert -
On 2013-07-30, at 14:59, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
But Bert, where to find a Squeak 3.11alpha image #8824 ? The 3.11 stuff on http://ftp.squeak.org/ is declared obsolete, and I did find anything but Level Playing Field there... The updates (stream) stop at 7159 (3.10) with Monticello-edc.312 Then squeak4.1 starts at #9957 with Monticello-bp-387...
2013/7/31 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Yes, it's a small change
2013/7/30 Bert Freudenberg bert@freudenbergs.de
FWIW, the server image is a Squeak 3.11alpha image #8824 with Monticello-bf.356. I'm afraid simply loading a current MC version is not going to work, but maybe the utf8 changes could be backported?
- Bert -
On 30.07.2013, at 22:26, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
To me, the server should try and read in utf8, then fallback to old encoding like current trunk does. Then, whether it should continue to write with old encoding or utf8 is a question of how we want to support serving older images. Would it be possible to provide a hackish transition: create mcd with same encoding as mcz?
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
A possible scenario: For some reason (?) the snapshot.bin fails. In that case, the server used the sources in .st format. But newly produced sources are in utf8 and the server is probably not utf8 aware... In which case the server re-interprets bad characters for building the .mcd and put them in patch.bin stone Makes sense?
Is it possible to backport the utf8 correction to the server ? I mean, is it going to cause forward compatibility problems ?
2013/7/30 Bert Freudenberg bert@freudenbergs.de
If the MCZ works and the MCD does not, then whatever fix we make needs to be applied to our squeaksource server image, which generates the MCDs.
- Bert -
On 2013-07-30, at 14:59, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
2013/7/30 commits@source.squeak.org
> Nicolas Cellier uploaded a new version of Collections to project The > Trunk: > http://source.squeak.org/trunk/Collections-nice.527.mcz > > ==================== Summary ==================== > > Name: Collections-nice.527 > Author: nice > Time: 30 July 2013, 2:13:07.506 am > UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d > Ancestors: Collections-fbs.526 > > Simplify Base64MimeConverter class initialization with
Character>>to:
> > =============== Diff against Collections-fbs.526 ===============
Bert, I prepared a patch for a 3.10.2 image in two folds: - 1) decode UTF8 from mcz sources - 2) encode mcd and mcz sources in UTF8 I've rapidly tested, and the image seems OK after applying 1) or both. If only first one is applied, then old images can continue to read new Mcd from source.squeak.org I don't know if this is a real requirement If not, then you can load 2) too. In doubt, a bit of conservatism don't hurt.
As for loading that in a non official 3.11, then you'll have to test a bit...
Cheers
Nicolas
2013/8/1 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
But Bert, where to find a Squeak 3.11alpha image #8824 ? The 3.11 stuff on http://ftp.squeak.org/ is declared obsolete, and I did find anything but Level Playing Field there... The updates (stream) stop at 7159 (3.10) with Monticello-edc.312 Then squeak4.1 starts at #9957 with Monticello-bp-387...
2013/7/31 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Yes, it's a small change
2013/7/30 Bert Freudenberg bert@freudenbergs.de
FWIW, the server image is a Squeak 3.11alpha image #8824 with Monticello-bf.356. I'm afraid simply loading a current MC version is not going to work, but maybe the utf8 changes could be backported?
- Bert -
On 30.07.2013, at 22:26, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
To me, the server should try and read in utf8, then fallback to old encoding like current trunk does. Then, whether it should continue to write with old encoding or utf8 is a question of how we want to support serving older images. Would it be possible to provide a hackish transition: create mcd with same encoding as mcz?
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
A possible scenario: For some reason (?) the snapshot.bin fails. In that case, the server used the sources in .st format. But newly produced sources are in utf8 and the server is probably not utf8 aware... In which case the server re-interprets bad characters for building the .mcd and put them in patch.bin stone Makes sense?
Is it possible to backport the utf8 correction to the server ? I mean, is it going to cause forward compatibility problems ?
2013/7/30 Bert Freudenberg bert@freudenbergs.de
If the MCZ works and the MCD does not, then whatever fix we make needs to be applied to our squeaksource server image, which generates the MCDs.
- Bert -
On 2013-07-30, at 14:59, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote: > Hmm it looks like some UTF8 mess > I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
frank
> 2013/7/30 commits@source.squeak.org > >> Nicolas Cellier uploaded a new version of Collections to project The >> Trunk: >> http://source.squeak.org/trunk/Collections-nice.527.mcz >> >> ==================== Summary ==================== >> >> Name: Collections-nice.527 >> Author: nice >> Time: 30 July 2013, 2:13:07.506 am >> UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d >> Ancestors: Collections-fbs.526 >> >> Simplify Base64MimeConverter class initialization with Character>>to: >> >> =============== Diff against Collections-fbs.526 ===============
On 8/2/13 6:26 PM, "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com wrote:
Bert, I prepared a patch for a 3.10.2 image in two folds:
- decode UTF8 from mcz sources
- encode mcd and mcz sources in UTF8
I've rapidly tested, and the image seems OK after applying 1) or both. If only first one is applied, then old images can continue to read new Mcd from source.squeak.org http://source.squeak.org I don't know if this is a real requirement If not, then you can load 2) too. In doubt, a bit of conservatism don't hurt.
As for loading that in a non official 3.11, then you'll have to test a bit...
Cheers
Nicolas
Like to know how you get the closures logic into 3.10.2 or 3.11, as I work in both.
Edgar
I've deleted this commit from the update stream, just so that we unbreak the update stream.
Then we can test the change, and reapply it at a later point.
frank
On 2 August 2013 22:26, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Bert, I prepared a patch for a 3.10.2 image in two folds:
- decode UTF8 from mcz sources
- encode mcd and mcz sources in UTF8
I've rapidly tested, and the image seems OK after applying 1) or both. If only first one is applied, then old images can continue to read new Mcd from source.squeak.org I don't know if this is a real requirement If not, then you can load 2) too. In doubt, a bit of conservatism don't hurt.
As for loading that in a non official 3.11, then you'll have to test a bit...
Cheers
Nicolas
2013/8/1 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
But Bert, where to find a Squeak 3.11alpha image #8824 ? The 3.11 stuff on http://ftp.squeak.org/ is declared obsolete, and I did find anything but Level Playing Field there... The updates (stream) stop at 7159 (3.10) with Monticello-edc.312 Then squeak4.1 starts at #9957 with Monticello-bp-387...
2013/7/31 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Yes, it's a small change
2013/7/30 Bert Freudenberg bert@freudenbergs.de
FWIW, the server image is a Squeak 3.11alpha image #8824 with Monticello-bf.356. I'm afraid simply loading a current MC version is not going to work, but maybe the utf8 changes could be backported?
- Bert -
On 30.07.2013, at 22:26, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
To me, the server should try and read in utf8, then fallback to old encoding like current trunk does. Then, whether it should continue to write with old encoding or utf8 is a question of how we want to support serving older images. Would it be possible to provide a hackish transition: create mcd with same encoding as mcz?
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
A possible scenario: For some reason (?) the snapshot.bin fails. In that case, the server used the sources in .st format. But newly produced sources are in utf8 and the server is probably not utf8 aware... In which case the server re-interprets bad characters for building the .mcd and put them in patch.bin stone Makes sense?
Is it possible to backport the utf8 correction to the server ? I mean, is it going to cause forward compatibility problems ?
2013/7/30 Bert Freudenberg bert@freudenbergs.de
If the MCZ works and the MCD does not, then whatever fix we make needs to be applied to our squeaksource server image, which generates the MCDs.
- Bert -
On 2013-07-30, at 14:59, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I tried to debug late at night and it seems to come from the patch.bin member of a .mcd I'm not an expert of MC and I do not really know when a .mcd is used vs a .mcz, nor how this binary member is created. But presumably, there is an extra or missing utf8 conversion in some path... I had to stop to get some sleep... I suggest we keep trying a couple of days and solve the problem while under our hands.
Nicolas
2013/7/30 Frank Shearar frank.shearar@gmail.com > > On 30 July 2013 02:17, Nicolas Cellier > nicolas.cellier.aka.nice@gmail.com wrote: > > Hmm it looks like some UTF8 mess > > I did only change Base64MimeConverter... Did I break it? > > Yep, I'm afraid so. When it loads it throws a SyntaxError: > > asCharacter > "Answer the receiver's first character, or '*' if none. > Idiosyncratic, provisional." > > ^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected > ->] > > Is that supposed to be a middle dot just before "Argument" ? Note how > the original source doesn't show the A-with-caret. > > frank > > > 2013/7/30 commits@source.squeak.org > > > >> Nicolas Cellier uploaded a new version of Collections to project > >> The > >> Trunk: > >> http://source.squeak.org/trunk/Collections-nice.527.mcz > >> > >> ==================== Summary ==================== > >> > >> Name: Collections-nice.527 > >> Author: nice > >> Time: 30 July 2013, 2:13:07.506 am > >> UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d > >> Ancestors: Collections-fbs.526 > >> > >> Simplify Base64MimeConverter class initialization with > >> Character>>to: > >> > >> =============== Diff against Collections-fbs.526 ===============
I applied Nicolas' changes to the squeaksource server image and will temporarily un-delete the mcz for testing.
- Bert - (back from vacation now)
On 2013-08-05, at 19:48, Frank Shearar frank.shearar@gmail.com wrote:
I've deleted this commit from the update stream, just so that we unbreak the update stream.
Then we can test the change, and reapply it at a later point.
frank
On 2 August 2013 22:26, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Bert, I prepared a patch for a 3.10.2 image in two folds:
- decode UTF8 from mcz sources
- encode mcd and mcz sources in UTF8
I've rapidly tested, and the image seems OK after applying 1) or both. If only first one is applied, then old images can continue to read new Mcd from source.squeak.org I don't know if this is a real requirement If not, then you can load 2) too. In doubt, a bit of conservatism don't hurt.
As for loading that in a non official 3.11, then you'll have to test a bit...
Cheers
Nicolas
2013/8/1 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
But Bert, where to find a Squeak 3.11alpha image #8824 ? The 3.11 stuff on http://ftp.squeak.org/ is declared obsolete, and I did find anything but Level Playing Field there... The updates (stream) stop at 7159 (3.10) with Monticello-edc.312 Then squeak4.1 starts at #9957 with Monticello-bp-387...
2013/7/31 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Yes, it's a small change
2013/7/30 Bert Freudenberg bert@freudenbergs.de
FWIW, the server image is a Squeak 3.11alpha image #8824 with Monticello-bf.356. I'm afraid simply loading a current MC version is not going to work, but maybe the utf8 changes could be backported?
- Bert -
On 30.07.2013, at 22:26, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
To me, the server should try and read in utf8, then fallback to old encoding like current trunk does. Then, whether it should continue to write with old encoding or utf8 is a question of how we want to support serving older images. Would it be possible to provide a hackish transition: create mcd with same encoding as mcz?
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
A possible scenario: For some reason (?) the snapshot.bin fails. In that case, the server used the sources in .st format. But newly produced sources are in utf8 and the server is probably not utf8 aware... In which case the server re-interprets bad characters for building the .mcd and put them in patch.bin stone Makes sense?
Is it possible to backport the utf8 correction to the server ? I mean, is it going to cause forward compatibility problems ?
2013/7/30 Bert Freudenberg bert@freudenbergs.de > > If the MCZ works and the MCD does not, then whatever fix we make needs > to be applied to our squeaksource server image, which generates the MCDs. > > - Bert - > > On 2013-07-30, at 14:59, Nicolas Cellier > nicolas.cellier.aka.nice@gmail.com wrote: > > I tried to debug late at night and it seems to come from the patch.bin > member of a .mcd > I'm not an expert of MC and I do not really know when a .mcd is used > vs a .mcz, nor how this binary member is created. > But presumably, there is an extra or missing utf8 conversion in some > path... > I had to stop to get some sleep... > I suggest we keep trying a couple of days and solve the problem while > under our hands. > > Nicolas > > > 2013/7/30 Frank Shearar frank.shearar@gmail.com >> >> On 30 July 2013 02:17, Nicolas Cellier >> nicolas.cellier.aka.nice@gmail.com wrote: >>> Hmm it looks like some UTF8 mess >>> I did only change Base64MimeConverter... Did I break it? >> >> Yep, I'm afraid so. When it loads it throws a SyntaxError: >> >> asCharacter >> "Answer the receiver's first character, or '*' if none. >> Idiosyncratic, provisional." >> >> ^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected >> ->] >> >> Is that supposed to be a middle dot just before "Argument" ? Note how >> the original source doesn't show the A-with-caret. >> >> frank >> >>> 2013/7/30 commits@source.squeak.org >>> >>>> Nicolas Cellier uploaded a new version of Collections to project >>>> The >>>> Trunk: >>>> http://source.squeak.org/trunk/Collections-nice.527.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: Collections-nice.527 >>>> Author: nice >>>> Time: 30 July 2013, 2:13:07.506 am >>>> UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d >>>> Ancestors: Collections-fbs.526 >>>> >>>> Simplify Base64MimeConverter class initialization with >>>> Character>>to: >>>> >>>> =============== Diff against Collections-fbs.526 ===============
- Bert -
... and that has appeared to work fine (except for Character DNU #null).
So Collections-nice.527 is back, and the newly generated mcd works (I deleted the older mcds).
Great job, Nicolas! We're back in business.
- Bert -
On 2013-08-06, at 00:02, Bert Freudenberg bert@freudenbergs.de wrote:
I applied Nicolas' changes to the squeaksource server image and will temporarily un-delete the mcz for testing.
- Bert - (back from vacation now)
On 2013-08-05, at 19:48, Frank Shearar frank.shearar@gmail.com wrote:
I've deleted this commit from the update stream, just so that we unbreak the update stream.
Then we can test the change, and reapply it at a later point.
frank
On 2 August 2013 22:26, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Bert, I prepared a patch for a 3.10.2 image in two folds:
- decode UTF8 from mcz sources
- encode mcd and mcz sources in UTF8
I've rapidly tested, and the image seems OK after applying 1) or both. If only first one is applied, then old images can continue to read new Mcd from source.squeak.org I don't know if this is a real requirement If not, then you can load 2) too. In doubt, a bit of conservatism don't hurt.
As for loading that in a non official 3.11, then you'll have to test a bit...
Cheers
Nicolas
2013/8/1 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
But Bert, where to find a Squeak 3.11alpha image #8824 ? The 3.11 stuff on http://ftp.squeak.org/ is declared obsolete, and I did find anything but Level Playing Field there... The updates (stream) stop at 7159 (3.10) with Monticello-edc.312 Then squeak4.1 starts at #9957 with Monticello-bp-387...
2013/7/31 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Yes, it's a small change
2013/7/30 Bert Freudenberg bert@freudenbergs.de
FWIW, the server image is a Squeak 3.11alpha image #8824 with Monticello-bf.356. I'm afraid simply loading a current MC version is not going to work, but maybe the utf8 changes could be backported?
- Bert -
On 30.07.2013, at 22:26, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
To me, the server should try and read in utf8, then fallback to old encoding like current trunk does. Then, whether it should continue to write with old encoding or utf8 is a question of how we want to support serving older images. Would it be possible to provide a hackish transition: create mcd with same encoding as mcz?
2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com > > A possible scenario: > For some reason (?) the snapshot.bin fails. In that case, the server > used the sources in .st format. > But newly produced sources are in utf8 and the server is probably not > utf8 aware... > In which case the server re-interprets bad characters for building the > .mcd and put them in patch.bin stone > Makes sense? > > Is it possible to backport the utf8 correction to the server ? > I mean, is it going to cause forward compatibility problems ? > > > > > 2013/7/30 Bert Freudenberg bert@freudenbergs.de >> >> If the MCZ works and the MCD does not, then whatever fix we make needs >> to be applied to our squeaksource server image, which generates the MCDs. >> >> - Bert - >> >> On 2013-07-30, at 14:59, Nicolas Cellier >> nicolas.cellier.aka.nice@gmail.com wrote: >> >> I tried to debug late at night and it seems to come from the patch.bin >> member of a .mcd >> I'm not an expert of MC and I do not really know when a .mcd is used >> vs a .mcz, nor how this binary member is created. >> But presumably, there is an extra or missing utf8 conversion in some >> path... >> I had to stop to get some sleep... >> I suggest we keep trying a couple of days and solve the problem while >> under our hands. >> >> Nicolas >> >> >> 2013/7/30 Frank Shearar frank.shearar@gmail.com >>> >>> On 30 July 2013 02:17, Nicolas Cellier >>> nicolas.cellier.aka.nice@gmail.com wrote: >>>> Hmm it looks like some UTF8 mess >>>> I did only change Base64MimeConverter... Did I break it? >>> >>> Yep, I'm afraid so. When it loads it throws a SyntaxError: >>> >>> asCharacter >>> "Answer the receiver's first character, or '*' if none. >>> Idiosyncratic, provisional." >>> >>> ^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected >>> ->] >>> >>> Is that supposed to be a middle dot just before "Argument" ? Note how >>> the original source doesn't show the A-with-caret. >>> >>> frank >>> >>>> 2013/7/30 commits@source.squeak.org >>>> >>>>> Nicolas Cellier uploaded a new version of Collections to project >>>>> The >>>>> Trunk: >>>>> http://source.squeak.org/trunk/Collections-nice.527.mcz >>>>> >>>>> ==================== Summary ==================== >>>>> >>>>> Name: Collections-nice.527 >>>>> Author: nice >>>>> Time: 30 July 2013, 2:13:07.506 am >>>>> UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d >>>>> Ancestors: Collections-fbs.526 >>>>> >>>>> Simplify Base64MimeConverter class initialization with >>>>> Character>>to: >>>>> >>>>> =============== Diff against Collections-fbs.526 ===============
- Bert -
- Bert -
Good work
Karl
On Tue, Aug 6, 2013 at 12:24 AM, Bert Freudenberg bert@freudenbergs.dewrote:
... and that has appeared to work fine (except for Character DNU #null).
So Collections-nice.527 is back, and the newly generated mcd works (I deleted the older mcds).
Great job, Nicolas! We're back in business.
- Bert -
On 2013-08-06, at 00:02, Bert Freudenberg bert@freudenbergs.de wrote:
I applied Nicolas' changes to the squeaksource server image and will
temporarily un-delete the mcz for testing.
- Bert - (back from vacation now)
On 2013-08-05, at 19:48, Frank Shearar frank.shearar@gmail.com wrote:
I've deleted this commit from the update stream, just so that we unbreak the update stream.
Then we can test the change, and reapply it at a later point.
frank
On 2 August 2013 22:26, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Bert, I prepared a patch for a 3.10.2 image in two folds:
- decode UTF8 from mcz sources
- encode mcd and mcz sources in UTF8
I've rapidly tested, and the image seems OK after applying 1) or both. If only first one is applied, then old images can continue to read new
Mcd
from source.squeak.org I don't know if this is a real requirement If not, then you can load 2) too. In doubt, a bit of conservatism don't hurt.
As for loading that in a non official 3.11, then you'll have to test a bit...
Cheers
Nicolas
2013/8/1 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
But Bert, where to find a Squeak 3.11alpha image #8824 ? The 3.11 stuff on http://ftp.squeak.org/ is declared obsolete, and I
did
find anything but Level Playing Field there... The updates (stream) stop at 7159 (3.10) with Monticello-edc.312 Then squeak4.1 starts at #9957 with Monticello-bp-387...
2013/7/31 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Yes, it's a small change
2013/7/30 Bert Freudenberg bert@freudenbergs.de > > FWIW, the server image is a Squeak 3.11alpha image #8824 with > Monticello-bf.356. I'm afraid simply loading a current MC version
is not
> going to work, but maybe the utf8 changes could be backported? > > - Bert - > > On 30.07.2013, at 22:26, Nicolas Cellier > nicolas.cellier.aka.nice@gmail.com wrote: > > To me, the server should try and read in utf8, then fallback to old > encoding like current trunk does. > Then, whether it should continue to write with old encoding or utf8
is a
> question of how we want to support serving older images. > Would it be possible to provide a hackish transition: create mcd
with
> same encoding as mcz? > > > 2013/7/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com >> >> A possible scenario: >> For some reason (?) the snapshot.bin fails. In that case, the
server
>> used the sources in .st format. >> But newly produced sources are in utf8 and the server is probably
not
>> utf8 aware... >> In which case the server re-interprets bad characters for building
the
>> .mcd and put them in patch.bin stone >> Makes sense? >> >> Is it possible to backport the utf8 correction to the server ? >> I mean, is it going to cause forward compatibility problems ? >> >> >> >> >> 2013/7/30 Bert Freudenberg bert@freudenbergs.de >>> >>> If the MCZ works and the MCD does not, then whatever fix we make
needs
>>> to be applied to our squeaksource server image, which generates
the MCDs.
>>> >>> - Bert - >>> >>> On 2013-07-30, at 14:59, Nicolas Cellier >>> nicolas.cellier.aka.nice@gmail.com wrote: >>> >>> I tried to debug late at night and it seems to come from the
patch.bin
>>> member of a .mcd >>> I'm not an expert of MC and I do not really know when a .mcd is
used
>>> vs a .mcz, nor how this binary member is created. >>> But presumably, there is an extra or missing utf8 conversion in
some
>>> path... >>> I had to stop to get some sleep... >>> I suggest we keep trying a couple of days and solve the problem
while
>>> under our hands. >>> >>> Nicolas >>> >>> >>> 2013/7/30 Frank Shearar frank.shearar@gmail.com >>>> >>>> On 30 July 2013 02:17, Nicolas Cellier >>>> nicolas.cellier.aka.nice@gmail.com wrote: >>>>> Hmm it looks like some UTF8 mess >>>>> I did only change Base64MimeConverter... Did I break it? >>>> >>>> Yep, I'm afraid so. When it loads it throws a SyntaxError: >>>> >>>> asCharacter >>>> "Answer the receiver's first character, or '*' if none. >>>> Idiosyncratic, provisional." >>>> >>>> ^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument
expected
>>>> ->] >>>> >>>> Is that supposed to be a middle dot just before "Argument" ?
Note how
>>>> the original source doesn't show the A-with-caret. >>>> >>>> frank >>>> >>>>> 2013/7/30 commits@source.squeak.org >>>>> >>>>>> Nicolas Cellier uploaded a new version of Collections to
project
>>>>>> The >>>>>> Trunk: >>>>>> http://source.squeak.org/trunk/Collections-nice.527.mcz >>>>>> >>>>>> ==================== Summary ==================== >>>>>> >>>>>> Name: Collections-nice.527 >>>>>> Author: nice >>>>>> Time: 30 July 2013, 2:13:07.506 am >>>>>> UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d >>>>>> Ancestors: Collections-fbs.526 >>>>>> >>>>>> Simplify Base64MimeConverter class initialization with >>>>>> Character>>to: >>>>>> >>>>>> =============== Diff against Collections-fbs.526
===============
> > > > > >
- Bert -
- Bert -
On 30 July 2013 13:13, Frank Shearar frank.shearar@gmail.com wrote:
On 30 July 2013 02:17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hmm it looks like some UTF8 mess I did only change Base64MimeConverter... Did I break it?
Yep, I'm afraid so. When it loads it throws a SyntaxError:
asCharacter "Answer the receiver's first character, or '*' if none. Idiosyncratic, provisional."
^ self size > 0 ifTrue: [self first] ifFalse:[$·Argument expected ->]
Is that supposed to be a middle dot just before "Argument" ? Note how the original source doesn't show the A-with-caret.
So I removed the A-with-caret character and tried to proceed. I then get an MNU in String class(Behavior)>>basicAddSelector:withMethod: because the with withMethod: parameter is nil.
If I inspect the MethodAddition it looks malformed. The text is the "broken" original text. I'd expected that fixing the SyntaxError would correct the original source, or at least make later parts of the process use the corrected source.
Tim, is this kind've like the thing you were seeing with SyntaxErrors in load scripts?
frank
2013/7/30 commits@source.squeak.org
Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.527.mcz
==================== Summary ====================
Name: Collections-nice.527 Author: nice Time: 30 July 2013, 2:13:07.506 am UUID: 17e38fb5-76dd-499b-aa6d-bfe07045c28d Ancestors: Collections-fbs.526
Simplify Base64MimeConverter class initialization with Character>>to:
=============== Diff against Collections-fbs.526 ===============
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Edgar J. De Cleene -
Frank Shearar -
karl ramberg -
Nicolas Cellier