ExuperyPlugin?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

ExuperyPlugin?

Markus Fritsche
Hello,

I'm trying to build a win32 exupery vm - but there is no ExuperyPlugin
in the monticello package. Is this intended?

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: ExuperyPlugin?

Markus Fritsche
Markus Fritsche schrieb:

> there is no ExuperyPlugin in the monticello package.

Must have been a problem with my image. I reloaded everything from
scratch and now it works.

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

ExuperyPlugin?

Bryce Kampjes
In reply to this post by Markus Fritsche
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
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: ExuperyPlugin?

Markus Fritsche
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?

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: ExuperyPlugin?

Igor Stasenko
2008/10/5 Markus Fritsche <[hidden email]>:
> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>



--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: ExuperyPlugin?

Markus Fritsche
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.

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: ExuperyPlugin?

Bryce Kampjes
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
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: ExuperyPlugin?

Markus Fritsche
[hidden email] 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! ;-))

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Subject: [BUG]ExuperyBlockContext(Object)>>doesNotUnderstand: #startpc

Markus Fritsche
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]}

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Subject: [BUG]ExuperyBlockContext(Object)>>doesNotUnderstand: #startpc

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

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: ExuperyPlugin?

Markus Fritsche
In reply to this post by Markus Fritsche
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 mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Subject: [BUG]ExuperyBlockContext(Object)>>doesNotUnderstand: #startpc

Bryce Kampjes
In reply to this post by Markus Fritsche
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
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Subject: [BUG]ExuperyBlockContext(Object)>>doesNotUnderstand: #startpc

Bryce Kampjes
[hidden email] 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
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Subject: [BUG]ExuperyBlockContext(Object)>>doesNotUnderstand: #startpc

Markus Fritsche
[hidden email] 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)]! !

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery