Hello,
I'm trying to build a win32 exupery vm - but there is no ExuperyPlugin in the monticello package. Is this intended?
Markus Fritsche writes:
Hello,
I'm trying to build a win32 exupery vm - but there is no ExuperyPlugin in the monticello package. Is this intended?
ExuperyPlugin should be in the VMMaker package in the Exupery project on SqueakSource. There's also changes to the VM itself to support Exupery, the VM needs to know how to call native code for a message send or return if it's going to a natively compiled method.
Bryce
I took Pharo, loaded Speech, FFI-Kernel, Exupery-328 and VMMaker-88
I have the source in \squeakvm\platform\
Usually, the platform source should be generated by vmmaker in \squeakvm\platform\win32 - but now, it's generated in \squeakvm\platform so that the makefile won't work. Does somebody know this prob?
2008/10/5 Markus Fritsche fritsche.markus@gmx.net:
I took Pharo, loaded Speech, FFI-Kernel, Exupery-328 and VMMaker-88
I have the source in \squeakvm\platform\
Usually, the platform source should be generated by vmmaker in \squeakvm\platform\win32 - but now, it's generated in \squeakvm\platform so that the makefile won't work. Does somebody know this prob?
Usually, i specifying different path for generated source files, outside \nameyourpath\platform\ directory. It is to ensure, that this directory remain clean, because it under source control.
Exupery mailing list Exupery@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Igor Stasenko schrieb:
Usually, i specifying different path for generated source files, outside \nameyourpath\platform\ directory. It is to ensure, that this directory remain clean, because it under source control.
I'm using the squeak-build-tools (peconfigured mingw environment), and it's a lot easier for me to stick to that since I'm not a great makefile-maker...
Anyhow, I filed VMMaker and Win32VMMaker in from a standard VMMaker package and it now works.
Markus Fritsche writes:
Igor Stasenko schrieb:
Usually, i specifying different path for generated source files, outside \nameyourpath\platform\ directory. It is to ensure, that this directory remain clean, because it under source control.
I'm using the squeak-build-tools (peconfigured mingw environment), and it's a lot easier for me to stick to that since I'm not a great makefile-maker...
Anyhow, I filed VMMaker and Win32VMMaker in from a standard VMMaker package and it now works.
You can set the path that VMMaker generates the source files in. It's "Path to generated sources".
Bryce
bryce@kampjes.demon.co.uk schrieb:
You can set the path that VMMaker generates the source files in. It's "Path to generated sources".
Yep, but (correct me if I'm wrong), your Win32VMMaker was changed and overided some of the directory-creation methods...
Anyhow, I managed to compile a Win32-VM with an ExuperyPlugin in it (finally! ;-))
Markus Fritsche schrieb:
You can set the path that VMMaker generates the source files in. It's "Path to generated sources".
Hmm... during background compilig I get a dnu from Process>>#isTerminated
5 October 2008 4:01:27 pm
VM: Win32 - a SmalltalkImage Image: Squeak3.10.2 [latest update: #7179]
SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\Dokumente und Einstellungen\mfritsche\Desktop\Seaside\Aida Trusted Dir C:\Dokumente und Einstellungen\mfritsche\Desktop\Seaside\Aida\mfritsche Untrusted Dir C:\My Squeak\mfritsche
ExuperyBlockContext(Object)>>doesNotUnderstand: #startpc Receiver: [] in Delay>>wait (Exupery) Arguments and temporary variables: aMessage: startpc Receiver's instance variables: caller: nil instructionPointer: nil stackPointer: 1 homeContext: Delay>>wait (Exupery) compiledIP: 0 initialCompiledBlock: 75406012
ExuperyBlockContext(ExuperyContext)>>doesNotUnderstand: #startpc Receiver: [] in Delay>>wait (Exupery) Arguments and temporary variables: aMessage: startpc Receiver's instance variables: caller: nil instructionPointer: nil stackPointer: 1 homeContext: Delay>>wait (Exupery) compiledIP: 0 initialCompiledBlock: 75406012
Process>>isTerminated Receiver: a Process in [] in Delay>>wait (Exupery) Arguments and temporary variables:
Receiver's instance variables: nextLink: nil suspendedContext: [] in Delay>>wait (Exupery) priority: 50 myList: a Semaphore(a Process in [] in Delay>>wait (Exupery)) errorHandler: nil name: nil
[] in ProcessBrowser>>updateProcessList {[:each | each isTerminated]} Arguments and temporary variables: oldSelectedProcess: a Process in SortedCollection(OrderedCollection)>>do: (Exup...etc... newIndex: nil now: 1155970 each: a Process in [] in Delay>>wait (Exupery) a: nil b: nil
--- The full stack --- ExuperyBlockContext(Object)>>doesNotUnderstand: #startpc ExuperyBlockContext(ExuperyContext)>>doesNotUnderstand: #startpc Process>>isTerminated [] in ProcessBrowser>>updateProcessList {[:each | each isTerminated]} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [] in OrderedCollection(Collection)>>reject: {[:element | (aBlock value: element) == false]} OrderedCollection>>select: OrderedCollection(Collection)>>reject: ProcessBrowser>>updateProcessList [] in ProcessBrowser>>startAutoUpdate {[self updateProcessList]} WorldState>>runStepMethodsIn: PasteUpMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]}
Markus Fritsche schrieb:
You can set the path that VMMaker generates the source files in. It's "Path to generated sources".
Hmm... during background compilig I get a dnu from Process>>#isTerminated
Which gets send by the process browser itself with turned on auto-updated. But there are more senders for isTerminated, which will all fail since there is nothing like "startpc" in ExuperyBlockContext
Markus Fritsche writes:
Markus Fritsche schrieb:
You can set the path that VMMaker generates the source files in. It's "Path to generated sources".
Hmm... during background compilig I get a dnu from Process>>#isTerminated
Which gets send by the process browser itself with turned on auto-updated. But there are more senders for isTerminated, which will all fail since there is nothing like "startpc" in ExuperyBlockContext
That's possible, The right solution would be to implement the protocol on ExuperyBlockContext. I've been slowly adding protocol as required.
Just curious, what are you doing to hit a new method so quickly?
Bryce
bryce@kampjes.demon.co.uk writes:
Markus Fritsche writes:
Markus Fritsche schrieb:
You can set the path that VMMaker generates the source files in. It's "Path to generated sources".
Hmm... during background compilig I get a dnu from Process>>#isTerminated
Which gets send by the process browser itself with turned on auto-updated. But there are more senders for isTerminated, which will all fail since there is nothing like "startpc" in ExuperyBlockContext
That's possible, The right solution would be to implement the protocol on ExuperyBlockContext. I've been slowly adding protocol as required.
Just curious, what are you doing to hit a new method so quickly?
Try adding:
ExuperyBlockContext>>startpc ^ Exupery byteCodeAddressFor: initialCompiledBlock
bryce@kampjes.demon.co.uk schrieb:
Just curious, what are you doing to hit a new method so quickly?
Something like "stress testing" without having a clue ;-)
Try adding:
ExuperyBlockContext>>startpc ^ Exupery byteCodeAddressFor: initialCompiledBlock
Thx! I attached another method of the BlockContext protocol
'From Squeak3.10.2 of ''5 June 2008'' [latest update: #7179] on 5 October 2008 at 6:23:55 pm'!
!ExuperyBlockContext methodsFor: 'as yet unclassified' stamp: 'maf 10/5/2008 18:23'! valueWithPossibleArgument: anArg
"Evaluate the block represented by the receiver. If the block requires one argument, use anArg, if it requires more than one, fill up the rest with nils."
self numArgs = 0 ifTrue: [^self value]. self numArgs = 1 ifTrue: [^self value: anArg]. self numArgs > 1 ifTrue: [^self valueWithArguments: {anArg}, (Array new: self numArgs - 1)]! !
Markus Fritsche schrieb:
Anyhow, I managed to compile a Win32-VM with an ExuperyPlugin in it (finally! ;-))
Background compiling stops somewhere with a coredump.
I got triggerhappy and did:
[ Smalltalk allClasses do: [ :class | ('*Seaside*' match: class category) ifTrue: [ class methodDictionary keysDo: [ :mthd |[ Exupery compileMethod: mthd class: class] on: Error do: []]]]] forkAt: 15
[ Smalltalk allClasses do: [ :class | ('*Morph*' match: class name) ifTrue: [ class methodDictionary keysDo: [ :mthd |[ Exupery compileMethod: mthd class: class] on: Error do: []]]]] forkAt: 15
[ Smalltalk allClasses do: [ :class | ('Kernel-Numbers' match: class category) ifTrue: [ class methodDictionary keysDo: [ :mthd |[ Exupery compileMethod: mthd class: class] on: Error do: []]]]] forkAt: 15
[ Smalltalk allClasses do: [ :class | ('*Omni*' match: class category) ifTrue: [ class methodDictionary keysDo: [ :mthd |[ Exupery compileMethod: mthd class: class] on: Error do: []]]]] forkAt: 15
So far, the processes still run :-)
exupery@lists.squeakfoundation.org
-
bryce＠kampjes.demon.co.uk -
Igor Stasenko -
Markus Fritsche