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

[Pharo-project] [ANN 1.1] prebuilt Core#11177
by Marcus Denker Jan. 21, 2010

Jan. 21, 2010

http://gforge.inria.fr/frs/download.php/25338/PharoCore-1.1-11177-UNSTABLE.… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] O2: tester wanted!
by Alexandre Bergel Jan. 21, 2010

Jan. 21, 2010

Dear All, For people who do not know, O2 is the browser David has implemented in the last few years. It replaces class-categories on the left-hand side pane with a list of packages. We are still away from having packages as real first class entities, but this is a good step toward. Note that some people find O2 a bit slower than other available code browsers. David and I spent some time on fixing O2. O2 has now no dependencies to OB anymore. We would like that people try it and submit bug reports on the google bug tracker. In a fresh 10505, you can load O2 by evaluating: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfO2'; load. (Smalltalk at: #ConfigurationOfO2) perform: #loadDefault O2 does not need OB whatsoever. O2 loads in a Core (I tried in a 11165). Before and after loading O2, running OB tests give "548 run, 547 passes, 1 failures" [*]. Cheers, Alexandre [*] the test have been loaded using (ConfigurationOfOmniBrowser project version: '1.1') load: 'Dev Tests' -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

11 16

[Pharo-project] Grrrrrrr the problem of always...... not finding a version when merging
by Mariano Martinez Peck Jan. 21, 2010

Jan. 21, 2010

The other day, we were with stef doing some merge, and we were speaking about a recurrent problem. I don't undetstand completely the problem, maybe I am wrong. When merging with MC, it searches the complete history of the package. But, actually, I don't care. I just want the last one to merge....Ok, the problem is that if a version is not found. For example, now, I am trying to merge my slice about cleanup and fixes of ImageSegments, and I have this error when merging: "Error: Could not find version 'CompilerTests-MarcusDenker.24'. Maybe you need to add a repository?" I added http://www.squeaksource.com/PharoTreatedInbox but I got the same results. I attach PharoDebug. Any ideas how to fix this ? I cannot merge :( Should I open an issue ? Mariano

1 0

[Pharo-project] Question about ImageSegment, Symbols and SmartRefStream
by Mariano Martinez Peck Jan. 21, 2010

Jan. 21, 2010

Hi folks. I am writing some ImageSegment tests and there is something I don't know how it is done. I create a segment with a root (array) that has symbols inside. Then, I export the segment using the method ImageSegment >> writeForExportOn: which uses a SmartRefStream to serialize itself and write it to a file. Now...the situation is like this: I hold the symbols so that they go to outPointers instead of wordarray. When I export the segment using writeForExportOn: the objects from outPointers should be exported also. Case 1) I export the segment and then load it in an image where the symbols are not present, and after the load, the symbols are present (and they came from the outPointers)...This is correct Case 2) I export the segment and then load it in an image where the symbols ARE ALREADY present, and after the load, the symbols ARE NOT duplicated...Ok..this is cool. But how does this magic happens ? Why I don't have two symbols equal ? If need the unit tests of both cases, I can past it here. Any ideas where this black magic comes from ?

3 5

Re: [Pharo-project] [squeak-dev] Cuis problem with blocks
by Eliot Miranda Jan. 21, 2010

Jan. 21, 2010

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 >>> >>> >>> >> > >

1 0

[Pharo-project] [update 1.1] #11177
by StÃ©phane Ducasse Jan. 21, 2010

Jan. 21, 2010

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

1 0

[Pharo-project] [ANN] ConfigurationOfProfStef in MetacelloRepository
by laurent laffont Jan. 21, 2010

Jan. 21, 2010

ProfStef is an interactive Smalltalk tutorial. To load it: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfProfStef'; load. ((Smalltalk at: #ConfigurationOfProfStef) project version: '1.0') load. Cheers, Laurent Laffont

4 6

Jan. 21, 2010

Finally :) 11176 ----- - Issue 1553: Buffer the StandardFileStream inputs Thanks levente

1 0

[Pharo-project] Monticello remove methods
by Stan Shepherd Jan. 21, 2010

Jan. 21, 2010

-- View this message in context: http://n2.nabble.com/Monticello-remove-methods-tp4433742p4433742.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 3

Jan. 21, 2010

11175 ----- - preparing buffered file stream: integrating multibyteFileStream from Squeak trunk

1 0