Spoon December 2011

spoon@lists.squeakfoundation.org

4 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Spoon December 2011