package BERTBuffers

Mouse Melon logoGet desktop application:
View/edit binary Protocol Buffers messages

message Array

variable.proto:43

* array/list/matrix/frame type

Used in: Variable

message CallResponse

variable.proto:352

* unifying call and response, since there are some fuzzy cases, callbacks, and so on. it makes sense for this to be a single message with a switch. FIXME: let's revert "callback" to a separate field for clarity, even though it has the same type as function_call; we have space. FIXME: we now have two errors -- one in here (top level) and one in variable (via result). is that useful? it certainly is confusing. I suppose it distinguishes between errors in the function call and results that are errors...

enum CallTarget

variable.proto:133

Used in: CompositeFunctionCall

enum CallType

variable.proto:127

* distinction between calls and accessors (and accesor type)

Used in: CompositeFunctionCall, FunctionDescriptor

message Code

variable.proto:117

* why not have a single string and then split on the RX side?

Used in: CallResponse

message Color

variable.proto:209

* although colors are passed as 4x 32-bit, they're actually only 8 bits each. FIXME: who passes colors as 128 bits? that's not a thing.

Used in: GraphicsContext

message Complex

variable.proto:37

* complex numbers

Used in: Variable

message CompositeFunctionCall

variable.proto:144

* consolidating function call, callback, COM function call, and control/system calls with arguments

Used in: CallResponse

message Console

variable.proto:252

* console message

Used in: CallResponse

message EnumType

variable.proto:317

Used in: ExternalPointer

message EnumValue

variable.proto:312

* for COM enums

Used in: EnumType

message Error

variable.proto:62

* error has a type and/or message

Used in: Variable

enum ErrorType

variable.proto:52

* error types

Used in: Error

message ExternalPointer

variable.proto:324

* now we're getting less and less general. not sure that's a good thing.

Used in: Variable

message FunctionDescriptor

variable.proto:288

* this type describes a function. adding type so we can reuse this for COM

Used in: ExternalPointer, FunctionList

message FunctionElement

variable.proto:277

* to date, we've been constructing function descriptions by packing them in normal variables. for R, we can use the "name" attribute to identify them. that's not available in Julia (and wouldn't be in some other languages either). this results in inconsitent data arriving at Excel, which requires language-specific handling. in an effort to normalize this data, and recognizing that this message scheme is application-specific, we'll define specific types for function descriptors (AND com calls, below). this type can be used for both the function itself and arguments.

Used in: FunctionDescriptor

message FunctionList

variable.proto:307

* list of functions. union type can't include arrays, so we need an array.

Used in: CallResponse

message GraphicsCommand

variable.proto:186

* we're now adding graphics to support a console graphics device in R. might extend to julia, although that will probably be based on GR and so a little simpler. packing in a variety of different parameters here, this may need to get streamlined... we can also do some creative reuse.

Used in: Console

message GraphicsContext

variable.proto:216

Used in: GraphicsCommand

message GraphicsUpdate

variable.proto:170

Used in: Variable

enum GraphicsUpdateCommand

variable.proto:165

Used in: GraphicsUpdate

message MIMEData

variable.proto:246

Used in: Console

message SheetReference

variable.proto:68

* sheet reference

Used in: Variable

message Variable

variable.proto:77

* basic variable type, optionally named

Used in: Array, CallResponse, CompositeFunctionCall, Console, FunctionElement