Vm-dev June 2011

vm-dev@lists.squeakfoundation.org

35 participants
141 discussions

VM Maker: VMMaker-oscog-IgorStasenko.89.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 29 Jun '11

29 Jun '11

Igor Stasenko uploaded a new version of VMMaker-oscog to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-oscog-IgorStasenko.89.mcz ==================== Summary ==================== Name: VMMaker-oscog-IgorStasenko.89 Author: IgorStasenko Time: 1 January 2001, 1:12:22 am UUID: 89539a1b-1a5b-4dca-abcf-8786cba00da7 Ancestors: Summary of merge VMMaker.oscog-eem.88 with VMMaker-oscog-IgorStasenko.68 - preserving ClipboardExtendedPlugin Float class>>fromIEEE64BitWord: anInteger ??? use of methodReturnValue: is cool preserved #primitiveImageFormatVersion (most probably will remove it as well) typo in #primitiveMPEG3GetTime: fileHandle # result , instead of #result (parser doesn't barks however) (whole Mpeg3Plugin is cleaner in .dtl branch) storeImageSegmentInto: segmentWordArray outPointers: outPointerArray roots: arrayOfRoots copied from ObjectMemory to NewObjectMemory.. why? this feature is broken anyways.. so i cannot care less ccgValBlock: valString still contains #fixTemps in Eliot's branch - new finalization is still not integrated in Eliot's branch - readImageFromFile: f HeapSize: desiredHeapSize StartingAt: imageOffset still using old sqAllocateMemory() in Eliot's branch instead of #allocateMemory:minimum:imageFile:headerSize: added by Esteban - primLoadModule and primitiveDisableModuleLoading are not integrated in Eliot's branch VMMakerTool class>>initialize menu registration fix from Mariano are not integrated in Eliot's branch

3 3

VM Maker: VMMaker.oscog-eem.88.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 28 Jun '11

28 Jun '11

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker.oscog-eem.88.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.88 Author: eem Time: 28 June 2011, 11:02:51 am UUID: 364d19cb-0842-41b5-bf54-bbd79b230bf6 Ancestors: VMMaker.oscog-eem.87 Slang: fix TAssignmentNode for as argument (enclose in parentheses). VMMaker: provide option: method tag to filter-out ceDynamicSuperSend:to:numArgs:. Eliminte cogit: method tag in favour of <option: #SomeKey>

1 0

Re: [Pharo-project] Re Please test Pharo 1.3!
by Mariano Martinez Peck 28 Jun '11

28 Jun '11

Checking dump file it looks like a known crash with Cog. Several times I saw crashes related to "CompiledMethod(Object)>becomeForward: 123450824: a(n) CompiledMethod" Stack: Smalltalk stack dump: 0x936f6c M CompiledMethod(Object)>becomeForward: 123450824: a(n) CompiledMethod 0x936f98 I CompiledMethod>setSourcePointer: 123450824: a(n) CompiledMethod 0x936fb4 M CompiledMethod>setSourcePosition:inFile: 123450824: a(n) CompiledMethod 0x936fdc M CompiledMethod>putSource:fromParseNode:inFile:withPreamble: 123450824: a(n) CompiledMethod 0x937004 M CompiledMethod>putSource:fromParseNode:class:category:withStamp:inFile:priorMethod: 123450824: a(n) CompiledMethod 0x937038 M Metaclass(ClassDescription)>logMethodSource:forMethodWithNode:inCategory:withStamp:notifying: 123252764: a(n) Metaclass 0x93706c I MethodAddition>writeSourceToLog 123434384: a(n) MethodAddition 0x93708c I MethodAddition>createCompiledMethod 123434384: a(n) MethodAddition 0x9370b0 I MCMethodDefinition>addMethodAdditionTo: 117453400: a(n) MCMethodDefinition 0x9370d0 M [] in MCPackageLoader>tryToLoad: 121841256: a(n) MCPackageLoader 0x8f48c0 M BlockClosure>on:do: 123434340: a(n) BlockClosure 0x8f48e8 I MCPackageLoader>tryToLoad: 121841256: a(n) MCPackageLoader 0x8f4904 M [] in MCPackageLoader>basicLoad 121841256: a(n) MCPackageLoader 0x8f493c M [] in OrderedCollection(Collection)>do:displayingProgress:every: 121975920: a(n) OrderedCollection 0x8f495c M OrderedCollection>do: 121975920: a(n) OrderedCollection 0x8f498c M [] in OrderedCollection(Collection)>do:displayingProgress:every: 121975920: a(n) OrderedCollection 0x8f49b0 M [] in ProgressInitiationException>defaultMorphicAction 123309096: a(n) ProgressInitiationException 0x8f49cc M BlockClosure>on:do: 123331824: a(n) BlockClosure 0x8f49f4 M [] in ProgressInitiationException>defaultMorphicAction 123309096: a(n) ProgressInitiationException 0x8f4a14 M BlockClosure>ensure: 123331688: a(n) BlockClosure 0x8f4a38 M ProgressInitiationException>defaultMorphicAction 123309096: a(n) ProgressInitiationException 0x8f4a50 M MorphicUIManager>progressInitiationExceptionDefaultAction: 80294140: a(n) MorphicUIManager 0x8f4a6c M ProgressInitiationException>defaultAction 123309096: a(n) ProgressInitiationException 0x8f4a88 M UndefinedObject>handleSignal: 78381060: a(n) UndefinedObject 0x8f4aa8 M MethodContext(ContextPart)>handleSignal: 104675620: a(n) MethodContext 0x8f4ac8 M MethodContext(ContextPart)>handleSignal: 117365292: a(n) MethodContext 0x8f4ae8 M MethodContext(ContextPart)>handleSignal: 121697844: a(n) MethodContext 0x8f4b08 M MethodContext(ContextPart)>handleSignal: 123155732: a(n) MethodContext 0x8f4b24 M ProgressInitiationException(Exception)>signal 123309096: a(n) ProgressInitiationException 0x8f4b3c M ProgressInitiationException>display:at:from:to:during: 123309096: a(n) ProgressInitiationException 0x8f4b68 M ProgressInitiationException class>display:at:from:to:during: 80856472: a(n) ProgressInitiationException class 0x8f4b94 M ByteString(String)>displayProgressAt:from:to:during: 89108292: a(n) ByteString 0x8f4bc8 M OrderedCollection(Collection)>do:displayingProgress:every: 121975920: a(n) OrderedCollection 0x8f4bec M OrderedCollection(Collection)>do:displayingProgress: 121975920: a(n) OrderedCollection 0x8f4c0c M [] in MCPackageLoader>basicLoad 121841256: a(n) MCPackageLoader 0x8f4c28 M BlockClosure>on:do: 123154900: a(n) BlockClosure 0x8f4c50 I [] in MCPackageLoader>basicLoad 121841256: a(n) MCPackageLoader 0x8f4c70 M BlockClosure>ensure: 123154776: a(n) BlockClosure 0x8f4c94 I MCPackageLoader>basicLoad 121841256: a(n) MCPackageLoader 0x8f4cb4 I [] in MCPackageLoader>loadWithNameLike: 121841256: a(n) MCPackageLoader 0x8f4cd8 I [] in MCPackageLoader>useChangeSetNamed:during: 121841256: a(n) MCPackageLoader 0x8f4cf8 M BlockClosure>ensure: 123154580: a(n) BlockClosure 0x8f4d24 I MCPackageLoader>useChangeSetNamed:during: 121841256: a(n) MCPackageLoader 0x8f4d4c I MCPackageLoader>useNewChangeSetNamedLike:during: 121841256: a(n) MCPackageLoader 0x8f4d74 I MCPackageLoader>loadWithNameLike: 121841256: a(n) MCPackageLoader 0x8f4d9c I MCVersionLoader>loadWithNameLike: 121632208: a(n) MCVersionLoader 0x8f4dc0 I MCVersionLoader>load 121632208: a(n) MCVersionLoader 0x8f4de0 I GoferLoad>execute 121632192: a(n) GoferLoad 0x8f4e08 I Gofer>execute:do: 121439760: a(n) Gofer 0x8f4e30 I Gofer>execute: 121439760: a(n) Gofer 0x8f4e54 I Gofer>load 121439760: a(n) Gofer 0x8f4e80 M MetacelloGoferBasedLoaderTest>testNestedLoad1 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4e98 M MetacelloGoferBasedLoaderTest(TestCase)>performTest 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4eb0 M [] in MetacelloGoferBasedLoaderTest(TestCase)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4ed0 M BlockClosure>ensure: 121439724: a(n) BlockClosure 0x8f4eec M MetacelloGoferBasedLoaderTest(TestCase)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4f04 M [] in MetacelloGoferBasedLoaderTest(MetacelloDictionaryRepositoryTest)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4f20 M [] in SystemChangeNotifier>doSilently: 78407412: a(n) SystemChangeNotifier 0x8f4f40 M BlockClosure>ensure: 121438364: a(n) BlockClosure 0x8f4f5c M SystemChangeNotifier>doSilently: 78407412: a(n) SystemChangeNotifier 0x8f4f80 I [] in MetacelloGoferBasedLoaderTest(MetacelloDictionaryRepositoryTest)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4fa0 M BlockClosure>ensure: 121438128: a(n) BlockClosure 0x8f4fc8 I MetacelloGoferBasedLoaderTest(MetacelloDictionaryRepositoryTest)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4fe4 M [] in TestResult>runCase: 104170712: a(n) TestResult 0x8f5000 M BlockClosure>on:do: 121437812: a(n) BlockClosure 0x8f5020 M TestResult>runCase: 104170712: a(n) TestResult 0x8f503c M MetacelloGoferBasedLoaderTest(TestCase)>run: 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f5058 M TestRunner>runTest: 104102048: a(n) TestRunner 0x8f5074 M [] in TestRunner>runSuite: 104102048: a(n) TestRunner 0x8f50ac M [] in OrderedCollection(Collection)>do:displayingProgress:every: 104171212: a(n) OrderedCollection 0x8f50cc M OrderedCollection>do: 104171212: a(n) OrderedCollection 0x8efb10 M [] in OrderedCollection(Collection)>do:displayingProgress:every: 104171212: a(n) OrderedCollection 0x8efb34 M [] in ProgressInitiationException>defaultMorphicAction 117364284: a(n) ProgressInitiationException 0x8efb50 M BlockClosure>on:do: 117365116: a(n) BlockClosure 0x8efb78 M [] in ProgressInitiationException>defaultMorphicAction 117364284: a(n) ProgressInitiationException 0x8efb98 M BlockClosure>ensure: 117364980: a(n) BlockClosure 0x8efbbc M ProgressInitiationException>defaultMorphicAction 117364284: a(n) ProgressInitiationException 0x8efbd4 M MorphicUIManager>progressInitiationExceptionDefaultAction: 80294140: a(n) MorphicUIManager 0x8efbf0 M ProgressInitiationException>defaultAction 117364284: a(n) ProgressInitiationException 0x8efc0c M UndefinedObject>handleSignal: 78381060: a(n) UndefinedObject 0x8efc2c M MethodContext(ContextPart)>handleSignal: 104675620: a(n) MethodContext 0x8efc48 M ProgressInitiationException(Exception)>signal 117364284: a(n) ProgressInitiationException 0x8efc60 M ProgressInitiationException>display:at:from:to:during: 117364284: a(n) ProgressInitiationException 0x8efc8c M ProgressInitiationException class>display:at:from:to:during: 80856472: a(n) ProgressInitiationException class 0x8efcb8 M ByteString(String)>displayProgressAt:from:to:during: 89108292: a(n) ByteString 0x8efcec M OrderedCollection(Collection)>do:displayingProgress:every: 104171212: a(n) OrderedCollection 0x8efd10 M OrderedCollection(Collection)>do:displayingProgress: 104171212: a(n) OrderedCollection 0x8efd40 I [] in TestRunner>basicRunSuite:do: 104102048: a(n) TestRunner 0x8efd60 M BlockClosure>ensure: 117364072: a(n) BlockClosure 0x8efd84 I TestRunner>basicRunSuite:do: 104102048: a(n) TestRunner 0x8efdac I TestRunner>runSuite: 104102048: a(n) TestRunner 0x8efdc8 M TestRunner>runAll 104102048: a(n) TestRunner 0x8efde8 I PluggableButtonMorph>performAction 104128960: a(n) PluggableButtonMorph 0x8efe04 M [] in PluggableButtonMorph>mouseUp: 104128960: a(n) PluggableButtonMorph 0x8efe28 M Array(SequenceableCollection)>do: 104170568: a(n) Array 0x8efe48 M PluggableButtonMorph>mouseUp: 104128960: a(n) PluggableButtonMorph 0x8efe64 M PluggableButtonMorph(Morph)>handleMouseUp: 104128960: a(n) PluggableButtonMorph 0x8efe80 M MouseButtonEvent>sentTo: 104170528: a(n) MouseButtonEvent 0x8efe9c M PluggableButtonMorph(Morph)>handleEvent: 104128960: a(n) PluggableButtonMorph 0x8efeb8 M PluggableButtonMorph(Morph)>handleFocusEvent: 104128960: a(n) PluggableButtonMorph 0x8efee0 M [] in HandMorph>sendFocusEvent:to:clear: 79625104: a(n) HandMorph 0x8efefc M [] in PasteUpMorph>becomeActiveDuring: 80073648: a(n) PasteUpMorph 0x8eff18 M BlockClosure>on:do: 104170476: a(n) BlockClosure 0x8eff44 M PasteUpMorph>becomeActiveDuring: 80073648: a(n) PasteUpMorph 0x8eff68 M HandMorph>sendFocusEvent:to:clear: 79625104: a(n) HandMorph 0x8eff90 M HandMorph>sendEvent:focus:clear: 79625104: a(n) HandMorph 0x8effb4 M HandMorph>sendMouseEvent: 79625104: a(n) HandMorph 0x8effd8 M HandMorph>handleEvent: 79625104: a(n) HandMorph 0x8f0004 M HandMorph>processEvents 79625104: a(n) HandMorph 0x8f001c M [] in WorldState>doOneCycleNowFor: 80242024: a(n) WorldState 0x8f0040 M Array(SequenceableCollection)>do: 78394416: a(n) Array 0x8f005c M WorldState>handsDo: 80242024: a(n) WorldState 0x8f0078 M WorldState>doOneCycleNowFor: 80242024: a(n) WorldState 0x8f0094 M WorldState>doOneCycleFor: 80242024: a(n) WorldState 0x8f00b0 M PasteUpMorph>doOneCycle 80073648: a(n) PasteUpMorph 0x8f00d0 I [] in Project class>? 80481880: a(n) Project class 80528720 s [] in BlockClosure>? On Tue, Jun 28, 2011 at 9:20 PM, Brian Tabone <brian_tabone(a)yahoo.com>wrote: > Sven, > > I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and > succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all > (and only) Zn* tests and 151 ran and 151 passed. > I then ran all tests except Zn* and it ran much further up until the VM > crashed. crash snapshots and the small dmp file attached. > > -Brian > > ------------------------------ > *From:* Sven Van Caekenberghe <sven(a)beta9.be> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Tuesday, June 28, 2011 1:48 PM > *Subject:* Re: [Pharo-project] Re Please test Pharo 1.3! > > > On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > > > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > > > >> > >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: > >> > >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, > and it appears that the image hangs up on a socket read. Below is some > information from the F2 console window, I dumped stacks, processes, > primitives, and socket info. The image does not respond to alt - . (no user > interrupt window ever displays). Attached is a screenshot of the image where > it hangs. The VM reports its version as: > >>> > >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 > >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > >>> > >>> Sorry if this is a duplicate or known issue, just figured I should be > on the safe side and report it. > >> > >> It seems that ZnUserAgentTests>>#testDelete fails for you. > >> > >> It works for me and for the regular integration/build servers, does the > windows slave pass this test ? > >> > > The windows slave does not yet run tests.. we will add that ASAP now that > it is up and running. > > OK, Marcus, I don't want to push, you'll let us know when it is ready. > > Brian, > > Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation > ? > > Does the whole test suite always fail at the same test ? > > Sven > > > > > > -- Mariano http://marianopeck.wordpress.com

1 0

Compiling Cog (merge with eem.87)
by Igor Stasenko 28 Jun '11

28 Jun '11

/Users/sig/projects/cog/blessed/src/vm/cogit.c:15864: error: lvalue required as left operand of assignment /Users/sig/projects/cog/blessed/src/vm/cogit.c:15864: error: lvalue required as left operand of assignment here the problematic line: case SSConstant: inst = (shouldAnnotateObjectReference((self_in_storeToReg->constant)) ? annotateobjRef(gMoveCwR((self_in_storeToReg->constant), reg), (self_in_storeToReg->constant)) >>> : /* begin MoveCq:R: */quickConstant = (self_in_storeToReg->constant),genoperandoperand(MoveCqR, quickConstant, reg)); break; seems like code generator producing bad code. Or maybe i'm not initializing stuff properly (since there are new options which may need to be passed?) -- Best regards, Igor Stasenko AKA sig.

2 3

VM Maker: VMMaker.oscog-eem.87.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 28 Jun '11

28 Jun '11

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker.oscog-eem.87.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.87 Author: eem Time: 27 June 2011, 7:17:18 am UUID: 5587fcb2-10cb-409d-9ebb-cdbd66bd910a Ancestors: VMMaker.oscog-eem.86 Cogit: Implement genDynamicSuperSendBytecode Implement unalignedAt:[put:] in CogAbstractInstruction & subclasses. Rename the explicit/implicit receiver trampolines to eliminate "Push". Fix C compilation of the Newspeak Cogit VM (at least on WIndows)

1 0

VM Maker: VMMaker-dtl.241.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 28 Jun '11

28 Jun '11

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.241.mcz ==================== Summary ==================== Name: VMMaker-dtl.241 Author: dtl Time: 27 June 2011, 10:18:20 am UUID: d8cf8a28-cb6e-4827-8765-d072c7e384df Ancestors: VMMaker-dtl.240 VMMaker 4.5.5 Integrate Igor's fix from http://code.google.com/p/cog/issues/detail?id=46. This change is adapted from NewObjectMemory>>sufficientSpaceAfterGC: in VMMaker.oscog-eem.86 and is intended to address object memory expansion problems noted on Windows. Background from <http://code.google.com/p/cog/issues/detail?id=46 Reported by project member siguctua, Today (4 hours ago) Hello, remember the problem Tudor has on Win32. I tracked it down to the #sufficientSpaceAfterGC: method. It looks like it miscalculating the amount of required space , because the check self oop: freeStart + minFree + 15000 isLessThan: reserveStart fails after growing the memory. So, instead of failing (and consequently raising a low-space condition), i placed the loop in allocation procedure to query even more memory from platform side , until condition will be fulfilled or no extra memory available , and then we naturally fail. I modified source files to trace memory allocation requests, and here what they producing. Before change: max available memory space: 1073741824 , reserved now: 422965248 allocated extra memory: 4198400 , total: 427163648 allocated extra memory: 4198400 , total: 431362048 allocated extra memory: 4198400 , total: 435560448 allocated extra memory: 4198400 , total: 439758848 After change: max available memory space: 1073741824 , reserved now: 422965248 allocated extra memory: 4214784 , total: 427180032 allocated extra memory: 4214784 , total: 431394816 allocated extra memory: 4214784 , total: 435609600 allocated extra memory: 4214784 , total: 439824384 sqMemoryExtraBytesLeft returns: 633917440 allocated extra memory: 5914624 , total: 445739008 As you can see, the VM without fix fails at 4th memory allocation request, but as it shown below, there are plenty of memory space available, and problem is not in insufficient space but in calculating the requested memory size >> and comparing with wrong desired space after allocating it. The loop just heals this issue.

1 0

VM Maker: VMMaker.oscog-eem.86.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 28 Jun '11

28 Jun '11

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker.oscog-eem.86.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.86 Author: eem Time: 27 June 2011, 4:09:22 am UUID: 9fa2ae33-553f-4e81-b8d8-45c5ba299256 Ancestors: VMMaker.oscog-eem.85 Integrate Igor's fix from http://code.google.com/p/cog/issues/detail?id=46. Modify to use #= instead of #== (important in the simulator)

1 0

VM Maker: VMMaker.oscog-eem.85.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 28 Jun '11

28 Jun '11

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker.oscog-eem.85.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.85 Author: eem Time: 27 June 2011, 3:48 am UUID: ddb80040-b647-4723-a62b-313ff83eb733 Ancestors: VMMaker.oscog-eem.84 Cogit: Implement GC update and unlinking of pushImplicitReceiver and dynamic super sends. Implement dynamic super sends and push explicit outer.

1 0

Re: [Pharo-project] out of memory - cog on windows
by Tudor Girba 27 Jun '11

27 Jun '11

Hi, On 18 May 2011, at 18:07, Levente Uzonyi wrote: > On Wed, 18 May 2011, Tudor Girba wrote: > > snip > >> >> I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible. > > You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.… I tried with this VM, but it crashes with the attached error. In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip Cheers, Doru > > Levente > > snip -- www.tudorgirba.com "Being happy is a matter of choice."

4 10

Cog on windows: compiler warning about alloca
by Igor Stasenko 27 Jun '11

27 Jun '11

Is it ok with this one: C:/hudson/workspace/CogWin32/cog/platforms/Cross/plugins/IA32ABI/dabusiness.h:34:11: warning: incompatible implicit declaration of built-in function 'alloca' ? -- Best regards, Igor Stasenko AKA sig.

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2011