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

[Pharo-project] Issue 3259 in pharo: Eliot Compiler Fixes Part one

by pharo＠googlecode.com

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.2 New issue 3259 by stephane.ducasse: Eliot Compiler Fixes Part one http://code.google.com/p/pharo/issues/detail?id=3259 Ancestors: Compiler-eem.154 Fix comment and computation of error temp push in BytecodeAgnosticMethodNode>>generate:. Remove a couple of unused methods. =============== Diff against Compiler-eem.154 =============== Item was changed: ----- Method: BytecodeAgnosticMethodNode>>generate: (in category 'code generation (new scheme)') ----- generate: trailer "The receiver is the root of a parse tree. Answer a CompiledMethod. + The argument, trailer, is arbitrary but is typically either the reference + to the source code that is stored with every CompiledMethod, or an + encoding of the method's temporary names." - The argument, trailer, is the reference to the source code that is - stored with every CompiledMethod." | primErrNode blkSize nLits literals stack method | self generate: trailer ifQuick: [:m | m literalAt: 2 put: encoder associationForClass; properties: properties. ^m]. primErrNode := self primitiveErrorVariableName ifNotNil: [encoder fixTemp: self primitiveErrorVariableName]. encoder supportsClosureOpcodes ifTrue: [self ensureClosureAnalysisDone. encoder rootNode: self. "this is for BlockNode>>sizeCodeForClosureValue:"]. blkSize := (block sizeCodeForEvaluatedValue: encoder) + + (primErrNode + ifNil: [0] + ifNotNil: [primErrNode sizeCodeForStore: encoder "The VM relies on storeIntoTemp: (129)"]). - + (primErrNode ifNil: [0] ifNotNil: [2 "We force store-long (129)"]). method := CompiledMethod newBytes: blkSize trailerBytes: trailer nArgs: arguments size nTemps: (encoder supportsClosureOpcodes ifTrue: [| locals | locals := arguments, temporaries, (primErrNode ifNil: [#()] ifNotNil: [{primErrNode}]). encoder noteBlockExtent: block blockExtent hasLocals: locals. locals size] ifFalse: [encoder maxTemp]) nStack: 0 nLits: (nLits := (literals := encoder allLiterals) size) primitive: primitive. nLits > 255 ifTrue: [^self error: 'Too many literals referenced']. 1 to: nLits do: [:lit | method literalAt: lit put: (literals at: lit)]. encoder streamToMethod: method. stack := ParseStack new init. primErrNode ifNotNil: [primErrNode emitCodeForStore: stack encoder: encoder]. stack position: method numTemps. block emitCodeForEvaluatedValue: stack encoder: encoder. stack position ~= (method numTemps + 1) ifTrue: [^self error: 'Compiler stack discrepancy']. encoder methodStreamPosition ~= (method size - trailer size) ifTrue: [^self error: 'Compiler code size discrepancy']. method needsFrameSize: stack size - method numTemps. method properties: properties. ^method! Item was removed: - ----- Method: TempVariableNode>>cleanUpForRegeneration (in category 'debugger access') ----- - cleanUpForRegeneration - remoteNode := nil. - definingScope := writingScopes := readingScopes := nil! Item was removed: - ----- Method: BytecodeEncoder>>schematicTempNamesOn:blockExtents:fromIndex: (in category 'results') ----- - schematicTempNamesOn: aStream blockExtents: blockExtents fromIndex: startIndex - "Print the locals in the blockExtent startIndex, recursing to print any locals in nested blockExtents. - Answer the index of the last blockExtent printed." - | blockExtent subsequentIndex | - blockExtent := blockExtents at: startIndex. - ((blockExtentsToLocals at: blockExtent) reject: [:local| local isRemote]) do: - [:local| - local isIndirectTempVector - ifTrue: [local remoteTemps do: - [:remoteLocal| aStream nextPut: remoteLocal key]] - ifFalse: [aStream nextPut: local key]]. - subsequentIndex := startIndex + 1. - [subsequentIndex <= blockExtents size - and: [(blockExtents at: subsequentIndex) last < blockExtent last]] whileTrue: - [aStream nextPut: (Array streamContents: - [:nestedTempStream| - subsequentIndex := self schematicTempNamesOn: nestedTempStream - blockExtents: blockExtents - fromIndex: subsequentIndex])]. - ^subsequentIndex!

Nov. 13, 2010

[Pharo-project] Monthly Pharo IRC or Chat meeting

by StÃ©phane Ducasse

Hi guys I would really like that we get a monthly IRC or Chat discussions to discuss a bit the directions, efforts..... What do you think about it? What do you think is a good set up? Stef

Nov. 13, 2010

Re: [Pharo-project] Issue 3224 in pharo: Migrating MethodReference to MethodReferenceWithSource

by pharo＠googlecode.com

Updates: Status: Fixed Comment #3 on issue 3224 by stephane.ducasse: Migrating MethodReference to MethodReferenceWithSource http://code.google.com/p/pharo/issues/detail?id=3224 We should get feedback on that.

Nov. 13, 2010

[Pharo-project] [update 1.2] #12239

by stephane ducasse

12239 ----- - Issue 2793: Compiler fixes. Thanks Eliot Miranda. - Issue 2771: should add PharoTreatedInbox to the list of repositories. (apparently did not work). Stef

Nov. 13, 2010

Re: [Pharo-project] Issue 2771 in pharo: should add PharoTreatedInbox to the list of repositories

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 2771 by stephane.ducasse: should add PharoTreatedInbox to the list of repositories http://code.google.com/p/pharo/issues/detail?id=2771 in 12238

Nov. 13, 2010

Re: [Pharo-project] Issue 2793 in pharo: Compiler fixes

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 2793 by stephane.ducasse: Compiler fixes http://code.google.com/p/pharo/issues/detail?id=2793 12239

Nov. 13, 2010

Re: [Pharo-project] Issue 2793 in pharo: Compiler fixes

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 2793 by stephane.ducasse: Compiler fixes http://code.google.com/p/pharo/issues/detail?id=2793 in slice-2793-CompilerFixes in inbox

Nov. 13, 2010

Re: [Pharo-project] Issue 2771 in pharo: should add PharoTreatedInbox to the list of repositories

by pharo＠googlecode.com

Updates: Status: Fixed Cc: marcus.denker Comment #4 on issue 2771 by stephane.ducasse: should add PharoTreatedInbox to the list of repositories http://code.google.com/p/pharo/issues/detail?id=2771 just perform cleanRepositories during the next integration phase.

Nov. 13, 2010

[Pharo-project] [update 1.2] #12238

by StÃ©phane Ducasse

12238 ----- - Update Regex to sync with latest version of lukas. http://source.lukas-renggli.ch/unsorted/ now up to 40 Stef

Nov. 13, 2010

Re: [Pharo-project] Issue 3254 in pharo: [Repackage] "Regular expressions" should be well structured

by pharo＠googlecode.com

Comment #8 on issue 3254 by stephane.ducasse: [Repackage] "Regular expressions" should be well structured http://code.google.com/p/pharo/issues/detail?id=3254 I just integrated the latest version available on lukas repository

Nov. 13, 2010