Squeak-dev March 2010

squeak-dev@lists.squeakfoundation.org

158 participants
767 discussions

The Trunk: Compiler-nice.129.mcz
by commits＠source.squeak.org 01 Mar '10

01 Mar '10

Nicolas Cellier uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-nice.129.mcz ==================== Summary ==================== Name: Compiler-nice.129 Author: nice Time: 1 March 2010, 11:24:30.271 pm UUID: a27b827d-1354-1147-bc1a-edeb6e1f0e97 Ancestors: Compiler-nice.128 Fix Compiler/Decompiler temporary slot mismatch http://bugs.squeak.org/view.php?id=7467 See also my comments in response to http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/145280.ht… Eliot, please check.... =============== Diff against Compiler-nice.128 =============== Item was changed: InstructionStream subclass: #Decompiler instanceVariableNames: 'constructor method instVars tempVars constTable stack statements lastPc exit caseExits lastJumpPc lastReturnPc limit hasValue blockStackBase numLocalTemps blockStartsToTempVars tempVarCount' classVariableNames: 'ArgumentFlag CascadeFlag CaseFlag IfNilFlag' poolDictionaries: '' category: 'Compiler-Kernel'! + !Decompiler commentStamp: 'nice 3/1/2010 19:56' prior: 0! - !Decompiler commentStamp: '<historical>' prior: 0! I decompile a method in three phases: Reverser: postfix byte codes -> prefix symbolic codes (nodes and atoms) Parser: prefix symbolic codes -> node tree (same as the compiler) Printer: node tree -> text (done by the nodes) instance vars: + constructor <DecompilerConstructor> an auxiliary knowing how to generate Abstract Syntax Tree (node tree) + method <CompiledMethod> the method being decompiled + instVars <Array of: String> the instance variables of the class implementing method + tempVars <String | (OrderedCollection of: String)> hold the names of temporary variables (if known) + NOTE: POLYMORPHISM WILL BE RESOLVED IN #initSymbols: + constTable <Collection of: ParseNode> parse node associated with byte encoded constants (nil true false 0 1 -1 etc...) + stack <OrderedCollection of: (ParseNode | String | Integer) > multipurpose... + statements <OrderedCollection of: ParseNode> the statements of the method being decompiled + lastPc <Integer> + exit <Integer> + caseExits <OrderedCollection of: Integer> - stack of exit addresses that have been seen in the branches of caseOf:'s + lastJumpPc <Integer> + lastReturnPc <Integer> + limit <Integer> + hasValue <Boolean> + blockStackBase <Integer> + numLocaltemps <Integer | Symbol> - number of temps local to a block; also a flag indicating decompiling a block + blockStartsToTempVars <Dictionary key: Integer value: (OrderedCollection of: String)> + tempVarCount <Integer> number of temp vars used by the method! - constructor - method - instVars - tempVars - constTable - stack - statements - lastPc - exit - caseExits - stack of exit addresses that have been seen in the branches of caseOf:'s - lastJumpPc - lastReturnPc - limit - hasValue - blockStackBase - numLocaltemps - number of temps local to a block; also a flag indicating decompiling a block! Item was added: + ----- Method: BlockNode>>makeTemporariesRemovable (in category 'code generation (closures)') ----- + makeTemporariesRemovable + "Utilities for when we want to remove some temporaries." + + temporaries isArray ifTrue: + [temporaries := temporaries asOrderedCollection].! Item was changed: ----- Method: BlockNode>>addRemoteTemp:rootNode: (in category 'code generation (closures)') ----- addRemoteTemp: aTempVariableNode rootNode: rootNode "<MethodNode>" "Add aTempVariableNode to my actualScope's sequence of remote temps. If I am an optimized block then the actual scope is my actualScopeIfOptimized, otherwise it is myself." - temporaries isArray ifTrue: - [temporaries := temporaries asOrderedCollection]. remoteTempNode == nil ifTrue: [remoteTempNode := RemoteTempVectorNode new name: self remoteTempNodeName index: arguments size + temporaries size type: LdTempType scope: 0. actualScopeIfOptimized ifNil: + [self addTempNode: remoteTempNode. - [temporaries addLast: remoteTempNode. remoteTempNode definingScope: self] ifNotNil: [actualScopeIfOptimized addHoistedTemps: { remoteTempNode }]]. remoteTempNode addRemoteTemp: aTempVariableNode encoder: rootNode encoder. "use remove:ifAbsent: because the deferred analysis for optimized loops can result in the temp has already been hoised into the root." + self actualScope removeTempNode: aTempVariableNode ifAbsent: []. - temporaries remove: aTempVariableNode ifAbsent: []. ^remoteTempNode! Item was added: + ----- Method: BlockNode>>addTempNode: (in category 'code generation (closures)') ----- + addTempNode: aTempVariableNode + "Utilities for when we want to add some temporaries." + + self makeTemporariesRemovable. + ^temporaries add: aTempVariableNode! Item was added: + ----- Method: BlockNode>>removeTempNode:ifAbsent: (in category 'code generation (closures)') ----- + removeTempNode: aTempVariableNode ifAbsent: aBlock + "Utilities for when we want to remove some temporaries." + + self makeTemporariesRemovable. + ^temporaries remove: aTempVariableNode ifAbsent: aBlock + !

1 0

Decompiler issues
by Levente Uzonyi 01 Mar '10

01 Mar '10

Hi, I recently ran into a new decompiler issue which doesn't allow the debugger to open. Details here: http://bugs.squeak.org/view.php?id=7467 So I thought it's time to revisit my decision of making DecompilerTests a subclass of LongTestCase, because I'm pretty sure noone is running these tests. According to my measurements 60-70% of their runtime is spent with garbage collecting. DecompilerTests >> #decompileClassesSelect: forces a full GC for every class in the image (>2000 in a clear trunk image). Is this GC still necessary? There are also two new methods besides EventSensor >> #eventTickler which give a Syntax Error when running these tests. The new methods are SHMCClassDefinition >> #withAllSuperclasses and SHMCClassDefinition >> #allInstVarNames. This problem occurs when a temporary is declared in an inlined block which is the receiver of #whileTrue, #whileTrue:, #whileFalse or #whileFalse and the variable is also referenced from a normal block. For example: [ | foo | [ foo := false ] value ] whileTrue will be decompiled as: [[_r1 := false] value] whileTrue. A lot of decompiler tests are failing, because the temporaries are indexed in a different order during the second decompilation. I hope someone with enough knowledge will fix these issues. Cheers, Levente

2 4

throwing my hat into the ring
by merlyn＠stonehenge.com 01 Mar '10

01 Mar '10

Yup. Third times a charm. I'll run for the SOB again. Position paper coming soon. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

1 0

how to use standalone teatime/tobjects?
by Lawson English 01 Mar '10

01 Mar '10

Hey all, millimetering ever-closer to a squeak plugin to SL. The pattern is quite simple: start second life. add a texture to a prim in SL that points to a localhost server with appropriate mime type. have a plugin available for SL that can share a memory buffer with a cobalt instance. Tell Cobalt to render into that instance with appropriate channels for mouse/keyboard I/O. Tada: Croquet/Cobalt on a prim. The Teatime architecture appears to be the ultimate P2P plugin tester, but its only being used for the rather huge Croquet/Cobalt use-case. Now, this is going to be fun, and possibly useful, but for most users of SL, Croquet isn't going to be all that attractive, at least at first. In order to get a foot in the door, I want to establish a TObject which renders to SL, accepts I/O from SL and broadcasts it to other TObjects connected to OTHER SL clients. This turns squeak into a media plugin prototyper for SL AND opens the door for more interesting plugins, such as ones that generate 3D data (not necessarily in Croquet format) for injection into SL. The same pattern could be added to any kind of chatroom. The ultimate form would be having a Croquet/Cobalt window embedded in an IRC or Google Wave window, but more limited object sharing should be quite useful (often more useful given the overhead of a complete Croquet world). So, my question is: how do I strip TObjects/Teatime away from the rather huge Croquet context, so that I could do a hello world example of a simple TObject rendering to a SL media plugin and sending updates to other TObjects connected to other SL clients via the media plugin? The sky is the limit for this functionality, IMHO. Croquet is only the sexiest example, but in fact, I don't think its the most practical. The hello world TObject is much easier to grasp the implications of, because "rendering" can be replaced with ANY object-state transfer to the target application (which could be anything, not just the Second Life client). Lawson

1 0

[OFF TOPIC] Brazil may be punished due to government supporting free software
by Casimiro de Almeida Barreto 01 Mar '10

01 Mar '10

This is off topic, but important to open software developers & supporters Brazil may be punished because government supports free software... IIPA is willing to put Brazil in the black list of copyrights because Federal & State governments support free software. According to IIPA, by supporting free software it shows Brazil has an inadequate policy against violations on intellectual property. IIPA... & its gangster supporters must be denounced now. Not only to local authorities but also to international organizations like the ICO. Full article (in Portuguese) can be found here: http://bit.ly/cxbqJO

1 0

I'll run for the Board
by Juan Vuletich 01 Mar '10

01 Mar '10

Hi Folks, I'll run for the Board this year. You can know a bit about me at http://www.jvuletich.org/aboutMe.html and about my view and objectives at www.jvuletich.org/Cuis/Index.html. Cheers, Juan Vuletich

2 1

Re: [etoys-dev] Packaging Etoys
by David T. Lewis 01 Mar '10

01 Mar '10

On Sun, Feb 28, 2010 at 06:47:58PM +0100, Karl Ramberg wrote: > Hi, > I have worked on packaging the Etoys image and saved them to > source.squeak.org/etoys. > I'm new to Monticello and hope I did not screw up too badly. Folks, Efforts are under way to synchronize Etoys with Squeak trunk. The Etoys developers have taken some first steps to save the Etoys image in Monticello archives (http://source.squeak.org/etoys). Since Monticello is being used to support this work, and since package naming conventions are important in Monticello, it will be helpful to all involved if the package names in trunk conform to the correct spelling of Etoys: http://lists.squeakland.org/pipermail/etoys-dev/2010-February/004397.html For this reason, I am about to post an update to Squeak trunk that changes all package names to from "EToys" to "Etoys" and changes all package overrides from "*eToys", "*EToys" and so forth to "*Etoys". As far as I know, this update requires no special changes to the trunk update stream. However, I've been wrong about this sort of thing before so if any problems appear in the update process, you can reasonably assume that it is my fault. Also, apologies in advance for the rather large update notification that may result from this change. Dave

4 3

Jump to page: