January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Question about ImageSegment, Symbols and SmartRefStream

by Adrian Lienhard

On Jan 21, 2010, at 19:56 , Lukas Renggli wrote: >> Any ideas where this black magic comes from ? > > From what I know Symbols always end up in the out-pointers because > they are always referenced at least from the Symbol table. Not necessarily. The symbol table is a *weak* set and hence if you don't strongly hold onto the symbols they get into the segment array and not into the out pointers! This is a potential source of subtle problems because after loading the segment you end up with duplicated symbols (we run into this with Cmsbox...). The easiest solution is to create a temporary variable and assign "Symbol allSymbols" while creating a segment. > That means they are serialized by the reference stream, which means > that the not so black magic happens in ReferenceStream>>#readSymbol. Yep. Cheers, Adrian > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 21, 2010

Re: [Pharo-project] about bufferedFileStream

by Levente Uzonyi

On Thu, 21 Jan 2010, StÃ©phane Ducasse wrote: > Hi levente > > I was wondering why the bufferedFileStream made the system faster. > I mean are querying the same contents on several occasion? As Nicolas said, not all primitives have the same cost. The file primitives cost a lot more than primitive 65 or some smalltalk code. And as Igor said accessing the disk costs a lot more than accessing memory, but that only counts in rare cases. Here's an example showing that the file primitive costs almost the same if it reads 1 or 2000 bytes: #(1 2000) collect: [ :bufferSize | (1 to: 5) collect: [ :run | StandardFileStream readOnlyFileNamed: SourceFiles second name do: [ :file | | buffer fileID | fileID := file instVarNamed: #fileID. buffer := String new: bufferSize. Smalltalk garbageCollect. [ 1 to: 100000 do: [ :each | file primSetPosition: fileID to: 0; primRead: fileID into: buffer startingAt: 1 count: bufferSize ] ] timeToRun ] ] ] ===> #( #(458 466 463 466 467) #(482 484 492 483 484)) This means that a primitive send takes ~2.5 microseconds so it can be used ~400000 times/second. If you read one byte/primitive that means 400KB/sec, if you read 2000 bytes/primitive you get 800MB/sec (your disk may be slower of course). Using the buffer you get the following values: (1 to: 10) collect: [ :run | StandardFileStream readOnlyFileNamed: SourceFiles second name do: [ :file | Smalltalk garbageCollect. [ 1 to: 100000 do: [ :each | file next ] ] timeToRun ] ] ===> #(15 14 12 11 12 12 11 12 12 12) It takes ~12 milliseconds to read 100KB if you read the bytes one-by-one. That means 8.3MB/sec. This is far from 800MB/sec, but much better than the 400KB/sec. Why does it matter? Because MultiByteFileStream (which is the default FileStream) can only read (and convert) single bytes. Levente > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 21, 2010

Re: [Pharo-project] Question about ImageSegment, Symbols and SmartRefStream

by Lukas Renggli

> Any ideas where this black magic comes from ? >From what I know Symbols always end up in the out-pointers because they are always referenced at least from the Symbol table. That means they are serialized by the reference stream, which means that the not so black magic happens in ReferenceStream>>#readSymbol. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 21, 2010

[Pharo-project] Newbie Confusion

by Michael Litchard

Just to let you know, I think the problems I've been experiencing would scare away many newbies. I'm sticking around because I like smalltalk and I think the pharo project is worth investing in. Here's one I'm finding difficult to ignore. I'm using the Pharo By Example book to learn smalltalk. No matter what image I try I get the same problem. The O2 browser is not default, and I cannot change my default. Following the instructions in the book should result in getting a menu of options. I get nothing. The learning process is dead in the water now. What image should I be using? I trust future newbies won't be having to ask this question. Michael Litchard.

Jan. 21, 2010

Re: [Pharo-project] [squeak-dev] Cuis problem with blocks

by Eliot Miranda

On Thu, Jan 21, 2010 at 4:33 AM, Juan Vuletich <juan(a)jvuletich.org> wrote: > Thanks, Nicolas. You're right. I did include the preference in Cuis. By > default it is set not to allow assignment to block args. I recompiled the > whole system this way, removing any block arg assgnment left. I see no > reason to allow them, but the preference is there if someone needs it. > Agreed. I put in the preference for cases such as loading packages containing assignments to block temps. Without the preference it is additional work to load the package (unpacking the .mcz by hand and editing the source file). Once the package is loaded one can hunt down and rewrite those assignments. But how does one find them other than by resetting the preference and recompiling the package? And how does one find block argument assignments lurking in unpackaged code save recompiling the entire system? One abuses MessageNotUnderstood, that's how. Here's a hack implementation of SystemNavigation allBlockArgumentAssignations. It has just found 35 such abominations in my development image (shock, horror). Change set attached. Code in all its syntax coloured glory below. Enjoy. *SystemNavigation methods for query* allBlockArgumentAssignations "Answer all methods containing an assignment to a block argument." "SystemNavigation default browseMessageList: SystemNavigation default allBlockArgumentAssignations asSortedCollection name: 'Assignments to block arguments'" ^self allMethodsSelect: [:m| | d assignsToBlockArg scanner | assignsToBlockArg *:=* false. (d *:=* m blockpcsToBlockExtents) size >= 2 ifTrue: [scanner *:=* InstructionStream on: m. d keysDo: [:interval| | nArgs | (interval first ~= m initialPC and: [(nArgs *:=* m argumentCountForBlockAtPC: interval first) > 0]) ifTrue: [scanner pc: interval first. [scanner pc <= interval last] whileTrue: [[scanner interpretNextInstructionFor: nil] on: MessageNotUnderstood do: [:ex| ((#( popIntoTemporaryVariable: storeIntoTemporaryVariable:) includes: ex message selector) and: [ex message arguments first + 1 <= nArgs]) ifTrue: [assignsToBlockArg *:=* true]]]]]]. assignsToBlockArg] *CompiledMethod methods for debugger support* argumentCountForBlockAtPC: blockStartPC "Answer the argument count of the block whose first bytecode is startpc." (self pcPreviousTo: blockStartPC) ifNotNil: [:closureCreationPC| [(InstructionStream on: self) pc: closureCreationPC; interpretNextInstructionFor: nil] on: MessageNotUnderstood do: [:ex| ex message selector == #pushClosureCopyNumCopiedValues:numArgs:blockSize: ifTrue: [^ex message arguments at: 2]] ]. self error: 'pc is not a block start pc' blockpcsToBlockExtents "Answer a Dictionary of (Interval from startpc to lastpc) to (Interval of blockExtent), for the method and any blocks within it, using the identical numbering scheme described in and orchestrated by BlockNode>>analyseArguments:temporaries:rootNode:. This is a variation on startpcsToBlockExtents whcih only answers startpc to interval." | index | index *:=* 0. ^self blockRangesAndExtentsInto: Dictionary new from: self initialPC to: self endPC scanner: (InstructionStream on: self) numberer: [| value | value *:=* index. index *:=* index + 2 . value] blockRangesAndExtentsInto: aDictionary from: initialPC to: endPC scanner: scanner numberer: numbererBlock "Support routine for blockpcsToBlockExtents" | extentStart blockSizeOrLocator | self flag: 'belongs in DebuggerMethodMap'. extentStart *:=* numbererBlock value. [scanner pc <= endPC] whileTrue: [blockSizeOrLocator *:=* scanner interpretNextInstructionFor: BlockStartLocator new. blockSizeOrLocator isInteger ifTrue: [self blockRangesAndExtentsInto: aDictionary from: scanner pc to: scanner pc + blockSizeOrLocator - 1 scanner: scanner numberer: numbererBlock]]. aDictionary at: (initialPC to: endPC) put: (extentStart to: numbererBlock value). ^aDictionary p.s. its my birthday today. I should be doing something useful but this was too much fun, my present to myself. > Cheers, > Juan Vuletich > > > Nicolas Cellier wrote: > >> Writing to block arguments is considered bad practice. >> In most Smalltalk (all?), you cannot write method arguments. >> Since blocks are proper closures (introduced in Cuis 2.0) same rule >> now apply to block arguments. >> In squeak trunk, this behavior is driven by a Preferences, you can ask >> Juan if he applied same policy in Cuis. >> >> Anyway, [:sum :ea | sum := sum + ea] is completely useless since the >> variable sum cease to exist once the block closure finish execution. >> It has exactly same effect as [:sum :ea | sum + ea]. >> >> This pattern was the result of some bad understanding of block return >> value and particularly the way inject:into: works, even in the >> pre-closure world. >> >> Cheers >> >> Nicolas >> >> 2010/1/21 Phil (list) <pbpublist(a)gmail.com>: >> >> >>> I'm attempting to get some code running on Cuis 2.0 and am having a >>> problem >>> with some pretty simple blocks like: >>> >>> [:sum :ea | sum := sum + ea] value: 1 value: 2. >>> >>> resulting in an error: >>> >>> [:sum :ea | Cannot store into ->sum := sum + ea] value: 1 value: 2. >>> >>> However, this example works without a problem in both 3.10.2 as well as >>> 3.7. >>> Any idea what's going on? >>> >>> Thanks, >>> Phil >>> >>> >>> >> > >

Jan. 21, 2010

Re: [Pharo-project] about bufferedFileStream

by Schwab,Wilhelm K

Stef, Probably unrelated, some time back I noted that "long" methods pretty clearly draw twice, once in black and again with Shout's coloring. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Thursday, January 21, 2010 12:16 PM To: Pharo-project(a)lists.gforge.inria.fr Development Subject: [Pharo-project] about bufferedFileStream Hi levente I was wondering why the bufferedFileStream made the system faster. I mean are querying the same contents on several occasion? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 21, 2010

Re: [Pharo-project] Spell check test cases

by Lukas Renggli

I wonder if we shouldn't somehow trigger a different tokenizer depending on what we check, instead of using some magic? We have all this information. For example class names, variables, selectors, ... and comments, strings, ... could use a different tokenizer that knows about the specifics? Lukas 2010/1/21 Stan Shepherd <stan.shepherd414(a)gmail.com>: > > Hi Lukas, did you get a chance to look at this? > > Refactoring-Spelling-Tests-StanShepherd.7.mcz in > http://www.squeaksource.com/RBBugFixes/ is the present version of the tests. > > They will still need the tweaks in your parser or normalizer to run green. > > ...Stan > -- > View this message in context: http://n2.nabble.com/Spell-check-test-cases-tp4288633p4434232.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 21, 2010

Re: [Pharo-project] about bufferedFileStream

by Nicolas Cellier

2010/1/21 Igor Stasenko <siguctua(a)gmail.com>: > 2010/1/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi levente >> >> I was wondering why the bufferedFileStream made the system faster. >> I mean are querying the same contents on several occasion? >> > Because disk access is times slower than any "intense" memory access. > Depends how the file access is parameterized... Maybe the OS is buffering behind our back anyway. There is also a cost associated to the primitive (converting file ID into a C FILE*, consistency checks, etc...), and maybe one associated to fread() itself (would be worth testing that with a simple C program). Nicolas >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 21, 2010

[Pharo-project] [update 1.1] #11177

by StÃ©phane Ducasse

11177 ----- - fixing HostSystemMenu by adding worldMenu - fixing 1804 DebuggerMethodMap initialize

Jan. 21, 2010

Re: [Pharo-project] about bufferedFileStream

by Nicolas Cellier

2010/1/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi levente > > I was wondering why the bufferedFileStream made the system faster. > I mean are querying the same contents on several occasion? > > Stef > My interpretation is this one: Overhead time spent > core time required. Whether you read/write 1 byte or 2000 bytes, the cost of the primitive call + underlying system call (fread/fwrite) is almost the same (overhead time is dominating). If you issue 2000 primitive calls for reading bytes 1 by 1, or a single for reading all at once, the main difference is 1999*overhead. The buffer use a much faster primitive ByteString/ByteArray #at:/at:put:, so it does not count. Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 21, 2010