2017-02-10 18:08:06 +01:00
|
|
|
// Code generated by protoc-gen-go.
|
|
|
|
// source: engine.proto
|
|
|
|
// DO NOT EDIT!
|
|
|
|
|
2017-05-18 20:38:28 +02:00
|
|
|
package lumirpc
|
2017-02-10 18:08:06 +01:00
|
|
|
|
|
|
|
import proto "github.com/golang/protobuf/proto"
|
|
|
|
import fmt "fmt"
|
|
|
|
import math "math"
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
import google_protobuf1 "github.com/golang/protobuf/ptypes/empty"
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
import google_protobuf "github.com/golang/protobuf/ptypes/struct"
|
2017-02-10 18:08:06 +01:00
|
|
|
|
|
|
|
import (
|
|
|
|
context "golang.org/x/net/context"
|
|
|
|
grpc "google.golang.org/grpc"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Reference imports to suppress errors if they are not otherwise used.
|
|
|
|
var _ = proto.Marshal
|
|
|
|
var _ = fmt.Errorf
|
|
|
|
var _ = math.Inf
|
|
|
|
|
|
|
|
// LogSeverity is the severity level of a log message. Errors are fatal; all others are informational.
|
|
|
|
type LogSeverity int32
|
|
|
|
|
|
|
|
const (
|
|
|
|
LogSeverity_DEBUG LogSeverity = 0
|
|
|
|
LogSeverity_INFO LogSeverity = 1
|
|
|
|
LogSeverity_WARNING LogSeverity = 2
|
|
|
|
LogSeverity_ERROR LogSeverity = 3
|
|
|
|
)
|
|
|
|
|
|
|
|
var LogSeverity_name = map[int32]string{
|
|
|
|
0: "DEBUG",
|
|
|
|
1: "INFO",
|
|
|
|
2: "WARNING",
|
|
|
|
3: "ERROR",
|
|
|
|
}
|
|
|
|
var LogSeverity_value = map[string]int32{
|
|
|
|
"DEBUG": 0,
|
|
|
|
"INFO": 1,
|
|
|
|
"WARNING": 2,
|
|
|
|
"ERROR": 3,
|
|
|
|
}
|
|
|
|
|
|
|
|
func (x LogSeverity) String() string {
|
|
|
|
return proto.EnumName(LogSeverity_name, int32(x))
|
|
|
|
}
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
func (LogSeverity) EnumDescriptor() ([]byte, []int) { return fileDescriptor1, []int{0} }
|
2017-02-10 18:08:06 +01:00
|
|
|
|
|
|
|
type LogRequest struct {
|
2017-05-18 20:38:28 +02:00
|
|
|
Severity LogSeverity `protobuf:"varint,1,opt,name=severity,enum=lumirpc.LogSeverity" json:"severity,omitempty"`
|
2017-02-10 18:08:06 +01:00
|
|
|
Message string `protobuf:"bytes,2,opt,name=message" json:"message,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *LogRequest) Reset() { *m = LogRequest{} }
|
|
|
|
func (m *LogRequest) String() string { return proto.CompactTextString(m) }
|
|
|
|
func (*LogRequest) ProtoMessage() {}
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
func (*LogRequest) Descriptor() ([]byte, []int) { return fileDescriptor1, []int{0} }
|
2017-02-10 18:08:06 +01:00
|
|
|
|
|
|
|
func (m *LogRequest) GetSeverity() LogSeverity {
|
|
|
|
if m != nil {
|
|
|
|
return m.Severity
|
|
|
|
}
|
|
|
|
return LogSeverity_DEBUG
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *LogRequest) GetMessage() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Message
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
type ReadLocationRequest struct {
|
|
|
|
Token string `protobuf:"bytes,1,opt,name=token" json:"token,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ReadLocationRequest) Reset() { *m = ReadLocationRequest{} }
|
|
|
|
func (m *ReadLocationRequest) String() string { return proto.CompactTextString(m) }
|
|
|
|
func (*ReadLocationRequest) ProtoMessage() {}
|
|
|
|
func (*ReadLocationRequest) Descriptor() ([]byte, []int) { return fileDescriptor1, []int{1} }
|
|
|
|
|
|
|
|
func (m *ReadLocationRequest) GetToken() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Token
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2017-02-10 18:08:06 +01:00
|
|
|
func init() {
|
2017-05-18 20:38:28 +02:00
|
|
|
proto.RegisterType((*LogRequest)(nil), "lumirpc.LogRequest")
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
proto.RegisterType((*ReadLocationRequest)(nil), "lumirpc.ReadLocationRequest")
|
2017-05-18 20:38:28 +02:00
|
|
|
proto.RegisterEnum("lumirpc.LogSeverity", LogSeverity_name, LogSeverity_value)
|
2017-02-10 18:08:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Reference imports to suppress errors if they are not otherwise used.
|
|
|
|
var _ context.Context
|
|
|
|
var _ grpc.ClientConn
|
|
|
|
|
|
|
|
// This is a compile-time assertion to ensure that this generated file
|
|
|
|
// is compatible with the grpc package it is being compiled against.
|
|
|
|
const _ = grpc.SupportPackageIsVersion4
|
|
|
|
|
|
|
|
// Client API for Engine service
|
|
|
|
|
|
|
|
type EngineClient interface {
|
|
|
|
// Log logs a global message in the engine, including errors and warnings.
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
Log(ctx context.Context, in *LogRequest, opts ...grpc.CallOption) (*google_protobuf1.Empty, error)
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
// ReadLocation reads the value from a location identified by a token in the current program.
|
|
|
|
ReadLocation(ctx context.Context, in *ReadLocationRequest, opts ...grpc.CallOption) (*google_protobuf.Value, error)
|
2017-02-10 18:08:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
type engineClient struct {
|
|
|
|
cc *grpc.ClientConn
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewEngineClient(cc *grpc.ClientConn) EngineClient {
|
|
|
|
return &engineClient{cc}
|
|
|
|
}
|
|
|
|
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
func (c *engineClient) Log(ctx context.Context, in *LogRequest, opts ...grpc.CallOption) (*google_protobuf1.Empty, error) {
|
|
|
|
out := new(google_protobuf1.Empty)
|
2017-05-18 20:38:28 +02:00
|
|
|
err := grpc.Invoke(ctx, "/lumirpc.Engine/Log", in, out, c.cc, opts...)
|
2017-02-10 18:08:06 +01:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return out, nil
|
|
|
|
}
|
|
|
|
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
func (c *engineClient) ReadLocation(ctx context.Context, in *ReadLocationRequest, opts ...grpc.CallOption) (*google_protobuf.Value, error) {
|
|
|
|
out := new(google_protobuf.Value)
|
|
|
|
err := grpc.Invoke(ctx, "/lumirpc.Engine/ReadLocation", in, out, c.cc, opts...)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return out, nil
|
|
|
|
}
|
|
|
|
|
2017-02-10 18:08:06 +01:00
|
|
|
// Server API for Engine service
|
|
|
|
|
|
|
|
type EngineServer interface {
|
|
|
|
// Log logs a global message in the engine, including errors and warnings.
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
Log(context.Context, *LogRequest) (*google_protobuf1.Empty, error)
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
// ReadLocation reads the value from a location identified by a token in the current program.
|
|
|
|
ReadLocation(context.Context, *ReadLocationRequest) (*google_protobuf.Value, error)
|
2017-02-10 18:08:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
func RegisterEngineServer(s *grpc.Server, srv EngineServer) {
|
|
|
|
s.RegisterService(&_Engine_serviceDesc, srv)
|
|
|
|
}
|
|
|
|
|
|
|
|
func _Engine_Log_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
|
|
|
|
in := new(LogRequest)
|
|
|
|
if err := dec(in); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if interceptor == nil {
|
|
|
|
return srv.(EngineServer).Log(ctx, in)
|
|
|
|
}
|
|
|
|
info := &grpc.UnaryServerInfo{
|
|
|
|
Server: srv,
|
2017-05-18 20:38:28 +02:00
|
|
|
FullMethod: "/lumirpc.Engine/Log",
|
2017-02-10 18:08:06 +01:00
|
|
|
}
|
|
|
|
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
|
|
|
|
return srv.(EngineServer).Log(ctx, req.(*LogRequest))
|
|
|
|
}
|
|
|
|
return interceptor(ctx, in, info, handler)
|
|
|
|
}
|
|
|
|
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
func _Engine_ReadLocation_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
|
|
|
|
in := new(ReadLocationRequest)
|
|
|
|
if err := dec(in); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if interceptor == nil {
|
|
|
|
return srv.(EngineServer).ReadLocation(ctx, in)
|
|
|
|
}
|
|
|
|
info := &grpc.UnaryServerInfo{
|
|
|
|
Server: srv,
|
|
|
|
FullMethod: "/lumirpc.Engine/ReadLocation",
|
|
|
|
}
|
|
|
|
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
|
|
|
|
return srv.(EngineServer).ReadLocation(ctx, req.(*ReadLocationRequest))
|
|
|
|
}
|
|
|
|
return interceptor(ctx, in, info, handler)
|
|
|
|
}
|
|
|
|
|
2017-02-10 18:08:06 +01:00
|
|
|
var _Engine_serviceDesc = grpc.ServiceDesc{
|
2017-05-18 20:38:28 +02:00
|
|
|
ServiceName: "lumirpc.Engine",
|
2017-02-10 18:08:06 +01:00
|
|
|
HandlerType: (*EngineServer)(nil),
|
|
|
|
Methods: []grpc.MethodDesc{
|
|
|
|
{
|
|
|
|
MethodName: "Log",
|
|
|
|
Handler: _Engine_Log_Handler,
|
|
|
|
},
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
{
|
|
|
|
MethodName: "ReadLocation",
|
|
|
|
Handler: _Engine_ReadLocation_Handler,
|
|
|
|
},
|
2017-02-10 18:08:06 +01:00
|
|
|
},
|
|
|
|
Streams: []grpc.StreamDesc{},
|
|
|
|
Metadata: "engine.proto",
|
|
|
|
}
|
|
|
|
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
func init() { proto.RegisterFile("engine.proto", fileDescriptor1) }
|
2017-02-10 18:08:06 +01:00
|
|
|
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
var fileDescriptor1 = []byte{
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
// 287 bytes of a gzipped FileDescriptorProto
|
|
|
|
0x1f, 0x8b, 0x08, 0x00, 0x00, 0x09, 0x6e, 0x88, 0x02, 0xff, 0x6c, 0x90, 0x4f, 0x4b, 0xc3, 0x40,
|
|
|
|
0x10, 0xc5, 0x93, 0xd6, 0x36, 0xcd, 0xb4, 0x48, 0xd8, 0x16, 0x09, 0xb1, 0x87, 0x92, 0x53, 0x51,
|
|
|
|
0xd8, 0x4a, 0xf5, 0xe4, 0x4d, 0x31, 0x2d, 0x85, 0x90, 0xc2, 0x8a, 0x7f, 0xae, 0x69, 0x1c, 0x97,
|
|
|
|
0x60, 0x92, 0x8d, 0xc9, 0x46, 0xe8, 0x17, 0xf0, 0x73, 0x4b, 0xf3, 0xa7, 0x04, 0xe9, 0x71, 0xe6,
|
|
|
|
0xbd, 0x7d, 0x6f, 0xf6, 0x07, 0x23, 0x4c, 0x78, 0x98, 0x20, 0x4d, 0x33, 0x21, 0x05, 0xd1, 0xa2,
|
|
|
|
0x22, 0x0e, 0xb3, 0x34, 0xb0, 0x2e, 0xb9, 0x10, 0x3c, 0xc2, 0x45, 0xb9, 0xde, 0x15, 0x9f, 0x0b,
|
|
|
|
0x8c, 0x53, 0xb9, 0xaf, 0x5c, 0xd6, 0xf4, 0xbf, 0x98, 0xcb, 0xac, 0x08, 0x64, 0xa5, 0xda, 0xef,
|
|
|
|
0x00, 0xae, 0xe0, 0x0c, 0xbf, 0x0b, 0xcc, 0x25, 0xb9, 0x81, 0x41, 0x8e, 0x3f, 0x98, 0x85, 0x72,
|
|
|
|
0x6f, 0xaa, 0x33, 0x75, 0x7e, 0xbe, 0x9c, 0xd0, 0xba, 0x84, 0xba, 0x82, 0x3f, 0xd7, 0x1a, 0x3b,
|
|
|
|
0xba, 0x88, 0x09, 0x5a, 0x8c, 0x79, 0xee, 0x73, 0x34, 0x3b, 0x33, 0x75, 0xae, 0xb3, 0x66, 0xb4,
|
|
|
|
0xaf, 0x61, 0xcc, 0xd0, 0xff, 0x70, 0x45, 0xe0, 0xcb, 0x50, 0x24, 0x4d, 0xc5, 0x04, 0x7a, 0x52,
|
|
|
|
0x7c, 0x61, 0x52, 0xe6, 0xeb, 0xac, 0x1a, 0xae, 0xee, 0x61, 0xd8, 0xca, 0x27, 0x3a, 0xf4, 0x9e,
|
|
|
|
0x9c, 0xc7, 0x97, 0xb5, 0xa1, 0x90, 0x01, 0x9c, 0x6d, 0xbc, 0xd5, 0xd6, 0x50, 0xc9, 0x10, 0xb4,
|
|
|
|
0xb7, 0x07, 0xe6, 0x6d, 0xbc, 0xb5, 0xd1, 0x39, 0x38, 0x1c, 0xc6, 0xb6, 0xcc, 0xe8, 0x2e, 0x7f,
|
|
|
|
0x55, 0xe8, 0x3b, 0x25, 0x17, 0x72, 0x07, 0x5d, 0x57, 0x70, 0x32, 0x6e, 0x1f, 0x5d, 0x17, 0x5b,
|
|
|
|
0x17, 0xb4, 0x02, 0x41, 0x1b, 0x10, 0xd4, 0x39, 0x50, 0xb2, 0x15, 0xb2, 0x82, 0x51, 0xfb, 0x52,
|
|
|
|
0x32, 0x3d, 0x3e, 0x3f, 0xf1, 0x81, 0x13, 0x39, 0xaf, 0x7e, 0x54, 0xa0, 0xad, 0xec, 0xfa, 0xe5,
|
|
|
|
0xe6, 0xf6, 0x2f, 0x00, 0x00, 0xff, 0xff, 0x09, 0x2f, 0x2a, 0x90, 0xa6, 0x01, 0x00, 0x00,
|
2017-02-10 18:08:06 +01:00
|
|
|
}
|