Proposal: Squeak-E = Squeak x Kernel-E (was: squeak as a
rwithers12 at attbi.com
Sun Jan 26 18:25:01 UTC 2003
On Sunday, January 26, 2003, at 01:01 PM, Mark S. Miller wrote:
> At 09:50 AM 1/26/2003 Sunday, Robert Withers wrote:
>> fantastic! I have a couple of questions: Do we need to provide a
>> capability interface to plugin code?
> I don't know. Please tell me about plugin code.
see http://minnow.cc.gatech.edu/squeak/464 Plugins are generated to
c and compiled as shared libs. They get initialize with an
interpreterProxy that gives them access to the virtual machine. Squeak
code can call primitives in the plugin. We may want to think about
both directions as capabilities and look into having an eventual msg
model at this interface. Often plugins are used to either speed
things up or provide access to platform specific I/O resources and api.
>> Could this help us support function
>> callbacks, into the image, so we could use squeak as a shared library
>> another program?
> I don't know, probably because I don't yet know about plugins.
We can callout with FFI, but we have never really worked on allowing
external programs to call back into squeak. The concurrency and
asynchrony of message passing, from the perspective of the vm, might
allow for eventually-sent interrupts.
>> Forget about my authentication ramblings, please.
> Ok, I've already forgotten who said this ;).
>> PS. Mark, I am adding handling of these three messages to the CapTP
>> (id -> class). Does this conflict anywhere?
>> at: 13 put: CapTPAvailableProtocolsMessage;
>> at: 14 put: CapTPSwitchProtocolMessage;
>> at: 15 put: CapTPAcknowledgeProtocolMessage;
> No conflict, but what's the ack for? I think you only need the first
your are right. I think i wrote it when we were discussing having to
do a round trip to change the protocol.
More information about the Squeak-dev