May 2013 - Pharo-dev - lists.pharo.org

[update 3.0] #30162

by Esteban Lorenzano

30162 ----- 10710 DefaultCommandLineHandler class>>#startUp: cleanup https://pharo.fogbugz.com/f/cases/10710 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-EstebanLor…

May 23, 2013

Re: [Pharo-dev] MC should really write snaphsot/source.st in UTF8

by Nicolas Cellier

The snapshot/source.st does not contain a mix of ByteString and WideString because a single String is written during the process (all code is written into a String new writeStream which will make the String wide at first wide Character), so it should work. 2013/5/23 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > On 23.05.2013 00:06, Nicolas Cellier wrote: > >> That sounds good. We could even try to fallback to UT-32 if we encounter >> zeros (but his should be very rare...). >> >> For write, ZipArchive are un-aware of any encoding... They use latin1. >> In Squeak, I could place some squeakToUTF8 sends in MCMczWriter, and >> equivalent UTF8TextConverter in Pharo #serializeDefinitions:, maybe this is >> needed in some other serialize* (version, dependencies who knows...) >> > That won't work, if the file contained sources for both widestring and > bytestring sourced methods. > In which case the file would contain code stored BOTH as latin1 bytes, and > (same endianness as platform saved from) UTF32. > Which means you'd have to detect and handle jumps back and forth in > encoding when reading... > IMHO, just consider those files lost beyond hope. > > Cheers, > Henry > >

May 23, 2013

Re: [Pharo-dev] FileSystem inconsistency

by Sean P. DeNigris

stephane ducasse wrote > deleting an nonexisting file should raise an error +1. This was the reason for #ensureDeleted to begin with... with one you care whether it's there or not, and the other you don't ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-FileSystem-inconsistency-tp4689205p4689391.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 23, 2013

Re: [Pharo-dev] Opening Settings browser is really slow

by Marcus Denker

On May 23, 2013, at 11:49 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > in the latest 30 opening the setting browser is slow. > I could not find if it was already reported. > 10633 SettingsBrowser is *extremely* slow https://pharo.fogbugz.com/f/cases/10633/SettingsBrowser-is-extremely-slow > Any idea why? > I guess related to the changed done on the TreeMorph recentlyâ¦ Marcus

May 23, 2013

[Fuel] SubscriptOutOfBounds: 27

by roberto.minelli＠usi.ch

Hi, While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. Thanks in advance, Roby ############################################################################################ ######################################### STACK#1 ########################################### ########################################################################################### CompiledMethod(Object)>>errorSubscriptBounds: CompiledMethod(Object)>>at: InstructionStream>>interpretNextInstructionFor: CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... BlockClosure>>on:do: CompiledMethod>>abstractBytecodeMessageAt: BlockClosure>>blockCreationBytecodeMessage BlockClosure>>endPC BlockClosure>>abstractBytecodeMessagesDo: BlockClosure>>isClean BlockClosure>>shouldBeSubstitutedByCleanCopy BlockClosure>>fuelAccept: FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... FLLargeIdentityDictionary>>at:ifAbsent: FLFullGlobalMapper>>mapAndTrace: FLPluggableSubstitutionMapper>>mapAndTrace: FLPluggableSubstitutionMapper>>mapAndTrace: FLAnalysis>>mapAndTrace: FLAnalysis>>run FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... FLAnalyzer>>analysisFor: FLSerialization>>analysisStep FLSerialization>>run DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] BlockClosure>>ensure: FLEncoder class>>on:globalEnvironment:do: DFSerializer(FLSerializer)>>serialize:on: ############################################################################################ ######################################### STACK#2 ########################################### ############################################################################################ Decompiler(Object)>>error: Decompiler>>decompileBlock: BlockClosure>>decompile BlockClosure>>printOn: BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] String class(SequenceableCollection class)>>streamContents:limitedTo: BlockClosure(Object)>>printStringLimitedTo: BlockClosure(Object)>>printString BlockClosure>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... BlockClosure>>on:do: SmalltalkEditor>>evaluateSelectionAndDo: SmalltalkEditor>>evaluateSelection PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] TextMorphForEditView(TextMorph)>>handleEdit: PluggableTextMorph>>handleEdit: PluggableTextMorph>>doIt SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] BlockClosure>>cull: BlockClosure>>cull:cull: BlockClosure>>cull:cull:cull: KMCategoryTarget>>completeMatch:buffer: KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] Array(SequenceableCollection)>>do: KMKeymap>>notifyCompleteMatchTo:buffer: KMKeymap>>onMatchWith:notify:andDo: KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... Set>>do:

May 23, 2013

Re: [Pharo-dev] could we rename ensureDeleted into ensureDelete?

by Sean P. DeNigris

Norbert Hartl wrote > It should be called ensureFileExists. I guess that would be more descriptive, but ensureFile never bothered me. Like so many of our selectors, it seems like a reasonable shorthand i.e. "ensure that this reference points to an existing file" -> ensureFileExists -> ensureFile. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-could-we-rename-ensureDeleted-into-ensureDe… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 23, 2013

Re: [Pharo-dev] could we rename ensureDeleted into ensureDelete?

by Sean P. DeNigris

stephane ducasse wrote > I disagree and this is not coherent with the ensureFile and > ensureDirectory Yes, you disagreed in the original discussion. But the consensus seemed to be that ensureDeleted was the least of all evils - ensureDelete is misleading, deleteIfExists is unwieldly... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-could-we-rename-ensureDeleted-into-ensureDe… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 23, 2013

Re: [Pharo-dev] MC should really write snaphsot/source.st in UTF8

by Henrik Sperre Johansen

On 23.05.2013 00:06, Nicolas Cellier wrote: > That sounds good. We could even try to fallback to UT-32 if we > encounter zeros (but his should be very rare...). > > For write, ZipArchive are un-aware of any encoding... They use latin1. > In Squeak, I could place some squeakToUTF8 sends in MCMczWriter, and > equivalent UTF8TextConverter in Pharo #serializeDefinitions:, maybe > this is needed in some other serialize* (version, dependencies who > knows...) That won't work, if the file contained sources for both widestring and bytestring sourced methods. In which case the file would contain code stored BOTH as latin1 bytes, and (same endianness as platform saved from) UTF32. Which means you'd have to detect and handle jumps back and forth in encoding when reading... IMHO, just consider those files lost beyond hope. Cheers, Henry

May 23, 2013

Re: [Pharo-dev] [squeak-dev] Re: MC should really write snaphsot/source.st in UTF8

by Henrik Sperre Johansen

On 23.05.2013 03:59, Yoshiki Ohshima wrote: > For Pharo, I'd guess so, too. > > (I heard that the Japanese support is pretty much dropped in Pharo.) > > -- If you mean using leadingChar to indicate WideStrings using non-unicode encoding, and Bitmapped fonts with multiple sets for non-latin1 ranges taking it into account when selecting glyph, then yes, it's pretty much been dropped. If you have a TrueType font with unicode -> japanese glyphs, it should still work though. Cheers, Henry

May 23, 2013

Re: [Pharo-dev] MC should really write snaphsot/source.st in UTF8

by Henrik Sperre Johansen

On 23.05.2013 00:06, Nicolas Cellier wrote: > That sounds good. We could even try to fallback to UT-32 if we > encounter zeros (but his should be very rare...). > > For write, ZipArchive are un-aware of any encoding... They use latin1. > In Squeak, I could place some squeakToUTF8 sends in MCMczWriter, and > equivalent UTF8TextConverter in Pharo #serializeDefinitions:, maybe > this is needed in some other serialize* (version, dependencies who > knows...) > > > > 2013/5/22 Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> > > > > Am 22.05.2013 um 23:16 schrieb Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com > <mailto:nicolas.cellier.aka.nice@gmail.com>>: > >> First thing would be to simplify #setConverterForCode and >> #selectTextConverterForCode. >> Do we still want to use a MacRomanTextConverter, seriously? I'm >> not even sure I've got that many files with that encoding on my >> Mac-OSX... >> Do we really need to put a ByteOrderMark for UTF-8, seriously? >> See http://en.wikipedia.org/wiki/Byte_order_mark, it's valueless, >> and not recommended. It were a Squeak way to specify that a >> Squeak source file would use UTF-8 rather than MacRoman, but now >> this should be obsolescent. > > A BOM for utf-8 does not make sense. It could act as a switch > between legacy encoding and utf-8. But it would also be a decision > that will be regretted shortly after. Most files in monticello are > 7bit so there wouldn't be a problem changing the default encoding. > For every other file an exception will be thrown. So reading utf-8 > and on exception reading the same thing in legacy might be a way > to go. > A BOM does make sense in this case, explicitly to act as a legacy switch, just like how the current .st works. Notice any non-ascii files will (should) be written in utf8 after a switch, just as for regular .st. Do we need to use a MacRomanTextConverter? No, we don't, not for MC. For regular .st MacRoman makes sense, since that was the encoding using for ByteStrings before WideStrings were invented, and as such, any legacy non-ascii .st sources written would be in that encoding. For MC .st files, the equivalent fallback legacy encoding for maximum compatability would be Latin1. End result: Written by Readable in Old Readable in New Old ascii: yes yes Old non-ascii, <256 yes yes Old non-ascii, >256 no no New ascii: yes yes New non-ascii: no yes Find attached the minor changeset I wrote a long time ago doing this, IIRC, the main problems remaining were how to handle writing source to internal streams, for which you can't specify encoding; this is done in quite a few tests. Not sure if it's better to just disallow that case, or another approach should be taken. Cheers, Henry

May 23, 2013