Spoon September 2011

spoon@lists.squeakfoundation.org

3 participants
8 discussions

Well that blew my mind
by Chris Cunnington 18 Feb '12

18 Feb '12

I understood yesterday that Spoon doesn't send objects to be recreated on the other side of a remote message, it sends information about objects. It encodes objects. I see tags go over the wire and the tag types are related to classes in the EncodingClasses classvar in MessagingSession class>>initialize. OK, a tag called methodTag goes over the wire. Now what? It is connected in the dictionary to CompiledMethod. OK, we are going to make an instance of a compiled method on this side from the info coming over the wire. It's a little generic, isn't it? Don't we need to be a little more specific about what's in it? All those byte codes and literals? Then it occurred to me that a new instance of CM could be populated... with the literals and material that are in a CM. What would we do that with? The whole class category in Spoon called LiteralMarkers. I'm guessing the markers go over the wire after the tag. Then they get installed into the CM. Bang. You've created a CM from a blueprint of one. That' blew my mind. CM's always seemed immutable. Seems I've just never spent much time with CompiledMethod>>#newMethod:header: Let's just make one with a bag of literals. And if we can make CMs from a stream of information, then we can make anything. Classes are just collections of CMs with some variables. Here's were we do just that: we make a CM and fill it full of literals from literal markers. MethodEdition>>#method "Answer the method I prescribe in the local system." | method | *method* := ( *CompiledMethod* newMethod: (endPC - initialPC + 2) header: header). 1 to: literalMarkers size do: [:literalIndex | *method* literalAt: literalIndex put: (literalMarkers at: literalIndex) *literal*]. .. snip ... ^method It seems to me these tools of tags and markers are a complete way to describe classes and instances. They can be stored as data and then re-instantiated on need. And I guess you could take a snapshot of any object or set of objects to have a history or version record. Have a nice weekend, Chris

3 2

Not re-created, encoded
by Chris Cunnington 18 Feb '12

18 Feb '12

"Spoon's remote messaging support doesn't use ReferenceStream to serialize, it uses a minimal proxy-aware framework (with a bias toward sending references, not copies). See class MessagingSession, and the implementors of storeOnProxyStream:for: and storeOnProxyStream:." A Message instance is isolated and sent #storeOnProxyStream:for:. This begins an encoding of that object, which is to say, the object is described with tags. That tags are here: MessagingSession class>> #initialize "Initialize myself." "self initialize" SpecialVariableSignatories := ( (Dictionary new) at: true put: trueTag; at: false put: falseTag; at: nil put: nilTag; yourself). EncodingClasses := ( (Dictionary new) at: symbolTag put: Symbol; at: stringTag put: String; at: messageSendTag put: MessagingSession; at: counterpartRequestTag put: CounterpartRequest; ... snip ... All manner of object can be described with these encoding tags. It's a stream of this tag information that goes over the wire. With this information the objects can be recreated on the other size. That's interesting. Unlike Noury's solution we are not copying the object on other side; we are sending lots of information about it. I can see how this would replace a Changes file, because you have stored the state of the code with these encoding tags. You're storing the state of the source code without using text. And maybe it's a little more versatile than that, too. I understand Viewpoints Research has created something called Worlds, where versions of a single object be stored in a single image. This version information seems like a way to do something similar. Different versions can be stored and re-instantiated. The Object>>storeOnProxySTream:for: has a class comment that seems to sum it up: storeOnProxyStream: aStream for: aMessagingSession "Store myself on aStream in such a way that I may be reconstructed by the peer connected to aMessagingSession." "By default, store a reference to myself, not a copy." ( (self respondsTo: #storeOnProxyStream:) ifTrue: [self] ifFalse: [self otherVia: aMessagingSession] ) storeOnProxyStream: aStream To conclude, objects are described by encoding. The encoding is done by a series of tags in MessagingSession. These are stored in the history image. The only thing I don't understand is how encoding data can "re-animate" an object on the other side, if the subject image does not have a compiler. I used to think Spoon sent serialized compiled methods to the subject memory, but we are encoding the specifications of compiled methods and sending that over the wire. But what agency is building fresh objects with this data? Is this something the modified vm does? Chris

2 1

Imprinting or not
by Chris Cunnington 18 Feb '12

18 Feb '12

I follow the instructions in the alpha's Wormhole server. I have an Other Browser that sees the contents of the micro image. ( Other, by the way, is the name of a class. Not the best of names, I don't think. So the name of the browser as "Other Browser" is being specific, because it is a browser that displays instances of Other. I think Other instances are proxies of the contents of the mini image. Of course, I may have this wrong. You can find a class in the alpha called "Other", so I leave you to see if you draw the same conclusion I did.) I can see the classes in the mini image. I want to change one. I want to start hacking the mini image. How do I do that? I use the Other Browser the same way I would any browser: change the code; and, save. That's the method, I think, for "imprinting" the remote image. I start small. I add a class comment to a class in the mini image. I save. I highlight the code in the Wormhole server to snapshot the mini image. I close everything down. Start everything up and see if the comment is there. It is not. I have not imprinted. But is that because I used a class comment and not actual code? You will read that Spoon makes a deal about the two kinds of content in a CompiledMethod: byte codes and literals. I finally looked up what a literal is. A literal can be a number, a character, a string, a symbol, or an array containing any of the previous four. Spoon, I think, when it puts the compiled methods in the mini image replaces the literals with "literal markers". Do the actual literals stay in the history image? So, since my class comment is a string, and therefor a literal, perhaps it was not shipped to the mini image. You will notice that the mini image has no class comments whatsoever. I don't think it went better with a piece of code. So making permanent changes to the mini/remote image is something I haven't figured out yet. I have yet to imprint. Chris

2 1

Hmmmm ... no HTTP
by Chris Cunnington 18 Feb '12

18 Feb '12

I took out a book on HTTP to probe Spoon. Then I broke out Wireshark and watched messages from 62982 and the base image. Guess what? There is no use of HTTP anywhere. It's all TCP. That makes sense. There is TCPStream and no HTTPStream. Correspondent has no protocols in its subclasses. Actually, there is no HTTP at all that you could put into the #transport instvar, because it's not in the image. Because HTTPServer is not in this alpha. I guess there'd be a corresponding HTTPStream to put into HTTPServer. WormholeServer>>initialize transport := ( (TCPStream transport) beBinary; port: 7777) Neat things do go by watching with Wireshark: ModuleEdition; TagsEdition; activeEditionOfMethodAt:; and "an instance of Array doesn't understand #editionOfMethodAt:inClassWithBaseID:" Spoon transports raw object memory as binary data on the TCP protocol. That's how it appears to me. Chris

2 1

addendum
by Chris Cunnington 15 Sep '11

15 Sep '11

Oops, the remote image does have a compiler. I thought for a moment and the agency doing the encoding is likely the agency doing the un-encoding. MessagingSession>>performNextIncomingMessage. This leads to: send: selector withParameters: parameters to: receiver over: aRemoteMessagingSession under: remoteExchangeID "Send the message with selector and parameters to receiver, using session's connection, for the remote exchange with ID remoteExchangeID." ..snip.. receiver *perform:* selector withArguments: parameters. .. snip.. result := receiver *perform:* selector withArguments: parameters. The #perform: is activating the receiver and selector specified in the message. Everything coming across the wire is a proxy encoding material. I guess you could specify a new class to be instantiated and that could be how imprinting happens over the wire. Onward. Chris

1 0

remote messaging loves #doesNotUnderstand:
by Chris Cunnington 13 Sep '11

13 Sep '11

At Deep Into Smalltalk at Lille in March Noury Bouraqadi presented a simple example of remote messaging. (The exampes are here http://car.mines-douai.fr/noury/docs ). You have two images. One is a proxy; the other is the server. You send a message to the proxy and it appears on the Transcript of the server. proxy := Proxy newOnPort: 5432. proxy cr; show: 'This is my boomstick!'. So you send a message to Proxy, which understands absolutely nothing. Zilch. It defaults to #doesNotUnderstand:, which captures the message as an instance of Message. doesNotUnderstand: *aMessage* "Message answer is not handled!" | messageBytes | *aMessage* lookupClass: nil. messageBytes := ReferenceStream streamedRepresentationOf: *aMessage*. socketStream := SocketStream openConnectionToHostNamed: 'localhost' port: portNumber. socketStream isConnected ifFalse: [^nil]. [socketStream sendCommand: messageBytes] ensure: [socketStream close]. You can see here that it is serialized by ReferenceStream, shot over the wire by SocketStream. It is de-serialized here in the server image: dispatch: messageBytes | message | *message* := ReferenceStream unStream: messageBytes. *message* sendTo: Transcript The important part is the last line, which has the Message instance sent #sendTo: and so for all intents and purposed you have send this old standby: Transcript show: 'This is my boomstick!' except the Transcript is not yours; it's somebody else's. Now let's look at Croquet/Qwaq FarRef>>#doesNotUnderstand: which has a class comment that says: "I represent a reference to an object living on another island. When I receive a message I pass the message on to the object." The class FarRef looks to me to be the same as Noury's Proxy: it understands no selectors; it uses a #doesNotUnderstand: override to capture the message; and, sends the message over the wire. The implementation of #doesNotUnderstand: is not clear to me, so I'll stick to the class comment as my proof. Does Qwaq use ReferenceStream to serialize? I don't know. In Spoon we have Other>>#doesNotUnderstand: which has this class comment: "Each of my instances respresents an object in another memory, reachable through a NetStream. Messages sent to one of my instances are forwarded to the remote object, and another Other is answered." It has #doesNotUnderstand: with a simple #forward: selector doesNotUnderstand: aMessage ^self forward: aMessage and then: forward: aMessage "Forward aMessage to the remote object I represent, and answer the result." "This message was invoked by the virtual machine, in response to an attempt to send aMessage to me." "Transcript cr; print: aMessage; endEntry." ^( ReflectiveBehavior at: aMessage selector ifAbsent: [ ^OutgoingMessageExchange forward: aMessage for: remoteIdentity over: session] ) value: session value: aMessage arguments I think Craig may be familiar with the idea of a remote Transcript as he's included a class comment there that looks like Noury's simple program. The message gets passed to OutgoingMessageExchange. Does it use ReferenceStream to serialize? I don't know yet. To conclude, each of these different programs creates a proxy that understands no selectors, but uses #doesNotUnderstand to glean the message. Thus captured it sends it to a remote receiver. This is the beachhead I've needed to understand Spoon. I'll extend outward from this observation. Chris

2 1

Oops, my bad
by Chris Cunnington 09 Sep '11

09 Sep '11

Some of the problems I've been having have come from not including this code written in the startup Workspace for the Wormhole server: (self minimumSubjectPeer classWithBaseID: EditHistory baseID) connect For reasons unknown I haven't added this when I started the Wormhole server to connect to the subject.image and history.image. I think this has meant the history image has been unreachable. Having started to do that Spoon works much better. RTFM, I guess. Anyway, if I could figure out how to remove the bug I put at bugs.squeak.org, I would. I can now see the code for methods in the code pane of the Other Browser. It wonks out sometimes with an error, but it's a huge leap forward in my hacking. Chris

1 0

Then again...
by Chris Cunnington 07 Sep '11

07 Sep '11

I think what I said yesterday is impossible. I think TCP can open a channel, but can't itself pass data. To even make a request requires the HTTP protocol. TCP stream := SocketStream openConnectionToHostNamed: 'www.squeak.org' port:80 HTTP stream nextPutAll: 'GET /HTTP'; crlf;crlf; flush. Those lines are taken from the SocketStream class comment and I think they illustrate the relationship between TCP and HTTP. You need HTTP to make a request. Soooo... If I open Spoon and follow its instructions. And then in the Other Browser I get an error when I click on a method in the remote/subject image that says this: MessageNotUnderstood: ByteString>>activeClass then I'm going to say that there is a problem between the large and small images in sending each other data. If it is not possible for the TCP protocol to send data on its own and the current alpha has no HTTP protocol classes, then doesn't it follow that the current alpha release expects resources that aren't there? And doesn't the master version of Spoon have an HTTPServer and related HTTP protocol classes? Is that why we get an a ByteString>>activeClass error? It's a thought, Chris

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Spoon September 2011