I am trying to define a complex structure (practically a POD) as a property in a REP file. The structure is defined already as Q_GADGET in a separate header file.
When I try to instantiate the replica the system crashes complaining that
it is unable to create a certain type (and in the log then comes three completely bogus (e.g. too high) type id numbers)
Is it possible to define structures as properties in the QT5 Remote Object
world? If yes how?
Thanks,
It appears my "naive" operator<< implementation was wrong. I simply <<-ed all the members one after the other into the stream, which caused some issues.
However using the
inline QDataStream& operator<<(QDataStream& stream, const my::api::User & value) {
QtRemoteObjects::copyStoredProperties(&value, stream);
return stream;
}
inline QDataStream& operator>>(QDataStream& stream, my::api::User & value) {
QtRemoteObjects::copyStoredProperties(stream, &value);
return stream;
}
"ethalon" solution (generated my the REPC compiler for PODs) works just fine.
Related
Could someone explain how to properly use Scan() and Value() in the following example?
I'm trying to make use of the following examples:
https://github.com/jinzhu/gorm/issues/2017#issuecomment-537627961
https://github.com/travisjeffery/proto-go-sql/blob/master/_example/person_sql.go
My proto:
message Timestamp {
google.protobuf.Timestamp timestamp = 1;
}
message User {
uint32 ID = 1;
Timestamp createdAt = 2;
}
Code (need to fix time.Now()):
package v1
import (
"database/sql/driver"
"fmt"
"time"
"github.com/golang/protobuf/ptypes"
)
func (u *User) Create() {
u.CreatedAt = time.Now() // FIXME: ERROR. How do I make use of Scan() and Value() here?
// saving to SQL database
}
func (ts *Timestamp) Scan(value interface{}) error {
switch t := value.(type) {
case time.Time:
var err error
ts.Timestamp, err = ptypes.TimestampProto(t)
if err != nil {
return err
}
default:
return fmt.Errorf("Not a protobuf Timestamp")
}
return nil
}
func (ts Timestamp) Value() (driver.Value, error) {
return ptypes.Timestamp(ts.Timestamp)
}
The scanner and valuer interfaces are not really things you'll use yourself, not when it comes to storing custom types in a DB, at least. I'll first cover the use of the Scan() and Value() functions, then I'll address your issues.
When you get a sql.Row result, and want to assign (scan) the values from the result set into your variables of a custom type. The docs show the sql.Row.Scan() function takes 0 or more arguments of type interface{}, basically anything. (check docs here).
In the list of supported types into which values can be scanned, the last line is the important one:
any type implementing Scanner (see Scanner docs)
With the function func (ts *Timestamp) Scan(value interface{}) error {, the Timestamp type now implements the Scanner interface, thus allowing sql.Row to assign values to this type. The documentation for the Scanner interface is located right below the docs for Scan(), which I linked above.
Of course, that helps you to read values from the DB, gets you nowhere when it comes to storing these types. For that, you need the Valuer interface. In case you haven't guessed it yet, the func (ts Timestamp) Value() (driver.Value, error) function indeed makes it so your Timestamp type implements this interface. The documentation for the driver.Valuer interface can be found here, all the way at the bottom.
The point of the Valuer interface is to allow a way to convert any type to a driver.Value, that the driver can work with and store in the DB (again: docs here).
Fixing the issues
First up, I'm goign to have to assume your protoc output is written to the v1 package. If it isn't, it's not going to work very well for you.
The offending line is indeed the one you marked out:
u.CreatedAt = time.Now()
First up, User.CreatedAt is of type Timestamp, which is in and of itself a message containing a single timestamp. To set the CreatedAt time to time.Now(), you need to initialise the CreatedAt field correctly:
u.CreatedAt = &Timestamp{
Timestamp: ptypes.TimestampNow(), // this returns a PROTOBUF TYPE!
}
You are doing this in your Scan and Value functions already, so I really don't get why you didn't do it here...
Advice
If the protoc output is indeed written to the v1 package, I really, really would remove the User.Create() function. In fact, I'd outright kill it. Your protocol buffers are used for communication. Exposing your program via RPC's. It's an API. These message types are essentially request and response objects (glorified DTO's if you will). You're adding this Create function to it, which turns them into AR types. It makes your protobuf package unusable. The beauty of gRPC is that you generate golang, C++, Python, ... code that others can use to call your program. If you make your gRPC package dependent on a database, as you are doing, I personally would never, ever use it.
I'm looking for documentation/information on how to share information/code between multiple binaries compiled for a Cortex-m/0/4/7 architectures. The two binaries will be on the same chip and same architecture. They are flashed at different locations and sets the main stack pointer and resets the program counter so that one binary "jumps" to the other binary. I want to share code between these two binaries.
I've done a simple copy of an array of function pointers into a section defined in the linker script into RAM. Then read the RAM out in the other binary and cast it to an array then use the index to call functions in the other binary. This does work as a Proof-of-concept, but I think what I'm looking for is a bit more complex. As I want some way of describing compatibility between the two binaries. I want some what the functionality of shared libraries, but I'm unsure if I need position independent code.
As an example how the current copy process is done it is basically:
Source binary:
void copy_func()
{
memncpy(array_of_function_pointers, fixed_size, address_custom_ram_section)
}
Binary which is jumped too from source binary:
array_fp_type get_funcs()
{
memncpy(adress_custom_ram_section, fixed_size, array_of_fp)
return array_of_fp;
}
Then I can use the array_of_fp to call into functions residing in the source binary from the jump binary.
So what I'm looking for is some resources or input for someone who have implemented a similar system. Like I would like to not have to have a custom RAM section where I'm copying the function pointers into.
I would be fine with having the compilation step of source binary outputting something which can be included into the compilation step of the jump binary. However it needs to be reproducible and recompiling the source binary shouldn't break the compatibility with the jump binary(even if it included a different file from what is now outputted) as long as you don't change the interface.
To clarify source binary shouldn't require any specific knowledge about the jump binary. The code should not reside in both binaries as this would defeat the purpose of this mechanism. The overall goal if this mechanism is a way to save space when creating multi-binary applications on cortex-m processors.
Any ideas or links to resources are welcome. If you have any more questions feel free to comment on the question and I'll try to answer it.
Its very hard for me to picture what you want to do, but if you're interested in having an application link against your bootloader/ROM, then see Loading symbol file while linking for a hint on what you could do.
Build your "source"(?) image, scrape its mapfile and make a symbol file, then use that when you link your "jump"(?) image.
This does mean you need to link your "jump" image against a specific version of your "source" image.
If you need them to be semi-version independent (i.e. you define a set of functions that get exported, but you can rebuild on either side), then you need to export function pointers at known locations in your "source" image and link against those function pointers in your "jump" image. You can simplify the bookkeeping by making a structure of function pointers access the functions through that on either side.
For example:
shared_functions.h:
struct FunctionPointerTable
{
void(*function1)(int);
void(*function2)(char);
};
extern struct FunctionPointerTable sharedFunctions;
Source file in "source" image:
void function1Implementation(int a)
{
printf("You sent me an integer: %d\r\n", a);
function2Implementation((char)(a%256))
sharedFunctions.function2((char)(a%256));
}
void function2Implementation(char b)
{
printf("You sent me an char: %c\r\n", b);
}
struct FunctionPointerTable sharedFunctions =
{
function1Implementation,
function2Implementation,
};
Source file in "jump" image:
#include "shared_functions.h"
sharedFunctions.function1(1024);
sharedFunctions.function2(100);
When you compile/link the "source", take its mapfile and extract the location of sharedFunctions and create a symbol file that is linked with the source the "jump" image.
Note: the printfs (or anything directly called by the shared functions) would come from the "source" image (and not the "jump" image).
If you need them to come from the "jump" image (or be overridable) , then you need to access them through the same function pointer table, and the "jump" image needs to fix the function pointer table up with its version of the relevant function. I updated the function1() to show this. The direct call to function2 will always be the "source" version. The shared function call version of it will go through the jump table and call the "source" version unless the "jump" image updates the function table to point to its implementation.
You CAN get away from the structure, but then you need to export the function pointers one by one (not a big problem), but you want to keep them in order and at a fixed location, which means explicitly putting them in the linker descriptor file, etc. etc. I showed the structure method to distill it down to the easiest example.
As you can see, things get pretty hairy, and there is some penalty (calling through the function pointer is slower because you need to load up the address to jump to)
As explained in comment, we could imagine an application and a bootloader relying on same dynamic library. So application and bootloader rely on library, application can be changed without impact on library or boot.
I did not find an easy way to do a shared library with arm-none-eabi-gcc. However
this document gives some alternatives to shared libraries. I your case, I would recommand the jump table solution.
Write a library with the functions that need to be used in bootloader and in applicative.
"library" code
typedef void (*genericFunctionPointer)(void)
// use the linker script to set MySection at a known address
// I think this could be a structure like Russ Schultz solution but struct may or may not compile identically in lib and boot. However yes struct would be much easyer and avoiding many function pointer cast.
const genericFunctionPointer FpointerArray[] __attribute__ ((section ("MySection")))=
{
(genericFunctionPointer)lib_f1,
(genericFunctionPointer)lib_f2,
}
void lib_f1(void)
{
//some code
}
uint8_t lib_f2(uint8_t param)
{
//some code
}
applicative and/or bootloader code
typedef void (*genericFunctionPointer)(void)
// Use the linker script to set MySection at same address as library was compiled
// in linker script also put this section as `NOLOAD` because it is init by library and not by our code
//volatile is needed here because you read in flash memory and compiler may initialyse usage of this array to NULL pointers
volatile const genericFunctionPointer FpointerArray[NB_F] __attribute__ ((section ("MySection")));
enum
{
lib_f1,
lib_f2,
NB_F,
}
int main(void)
{
(correctCastF1)(FpointerArray[lib_f1])();
uint8_t a = (correctCastF2)(FpointerArray[lib_f2])(10);
}
You can look into using linker sections. If you have your bootloader source code in folder bootloader, you can use
SECTIONS
{
.bootloader:
{
build_output/bootloader/*.o(.text)
} >flash_region1
.binary1:
{
build_output/binary1/*.o(.text)
} >flash_region2
.binary2:
{
build_output/binary2/*.o(.text)
} >flash_region3
}
I want to inject some functions to Backboardd, because of some reasons, I can not use plist to restrict it, so I want to use "if" to determine whether it's inside Backboardd.I know in 'Logos' I can use like that:
%ctor{
if (%c(SpringBoard)) {
}
}
But without Logos, can I do it like below?It doesn't work.
MSInitialize {
if (objc_getClass("Backboardd")) {
CFMessagePortRef local = CFMessagePortCreateLocal(NULL, CFSTR(MACH_PORT_NAME), messageCallBack, NULL, NULL);
CFRunLoopSourceRef source = CFMessagePortCreateRunLoopSource(NULL, local, 0);
CFRunLoopAddSource(CFRunLoopGetCurrent(), source, kCFRunLoopDefaultMode);
}
}
In general, you need to find some obj-c class that is unique to what you are hooking. Ideally, it should be class defined inside that binary, not imported from a framework. For example, in SpringBoard there is SpringBoard class that can only be found inside SpringBoard's binary. If objc_getClass("SpringBoard") returns non NULL value then you're inside the SpringBoard.
Now, backboardd. What I'm doing in cases like that is copying binary on my PC and obtaining the list of all classes inside that binary using class-dump or IDA. In case of backboardd, good candidate would be BKApplication. So
if (objc_getClass("BKApplication")) {
...
}
would do the job. There is no Backboardd class in backboardd.
And just for the future, use more popular tags for the questions like that. You have a better chance of getting an answer if you use jailbreak or iphone-privateapi tags.
I've inherited a piece of custom test equipment with a control library built in a COM object, and I'm trying to connect it to our Tcl test script library. I can connect to the DLL using TCOM, and do some simple control operations with single int parameters. However, certain features are controlled by passing in a C/C++ struct that contains the control blocks, and attempting to use them in TCOM is giving me an error 0x80020005 {Type mismatch.}. The struct is defined in the .idl file, so it's available to TCOM to use.
The simplest example is a particular call as follows:
C++ .idl file:
struct SourceScaleRange
{
float MinVoltage;
float MaxVoltage;
};
interface IAnalogIn : IDispatch{
...
[id(4), helpstring("method GetAdcScaleRange")] HRESULT GetAdcScaleRange(
[out] struct SourceScaleRange *scaleRange);
...
}
Tcl wrapper:
::tcom::import [file join $::libDir "PulseMeas.tlb"] ::char
set ::characterizer(AnalogIn) [::char::AnalogIn]
set scaleRange ""
set response [$::characterizer(AnalogIn) GetAdcScaleRange scaleRange]
Resulting error:
0x80020005 {Type mismatch.}
while executing
"$::characterizer(AnalogIn) GetAdcScaleRange scaleRange"
(procedure "charGetAdcScaleRange" line 4)
When I dump TCOM's methods, it knows of the name of the struct, at least, but it seems to have dropped the struct keyword. Some introspection code
set ifhandle [::tcom::info interface $::characterizer(AnalogIn)]
puts "methods: [$ifhandle methods]"
returns
methods: ... {4 VOID GetAdcScaleRange {{out {SourceScaleRange *} scaleRange}}} ...
I don't know if this is meaningful or not.
At this point, I'd be happy to get any ideas on where to look next. Is this a known TCOM limitation (undocumented, but known)? Is there a way to pre-process the parameter into an appropriate format using tcom? Do I need to force it into a correctly sized block of memory via binary format by manual construction? Do I need to take the DLL back to the original developer and have him pull out all the struct parameters? (Not likely to happen, in this reality.) Any input is good input.
I grew up in the days when passing around structures was bad mojo because they are often large, so pointers were always the way to go. Now that C++11 has quite good RVO (right value optimization), I'm wondering if code like the following will be efficient.
As you can see, my class has a bunch of vector structures (not pointers to them). The constructor accepts value structures and stores them away.
My -hope- is that the compiler will use move semantics so that there really is no copying of data going on; the constructor will (when possible) just assume ownership of the values passed in.
Does anyone know if this is true, and happens automagically, or do I need a move constructor with the && syntax and so on?
// ParticleVertex
//
// Class that represents the particle vertices
class ParticleVertex : public Vertex
{
public:
D3DXVECTOR4 _vertexPosition;
D3DXVECTOR2 _vertexTextureCoordinate;
D3DXVECTOR3 _vertexDirection;
D3DXVECTOR3 _vertexColorMultipler;
ParticleVertex(D3DXVECTOR4 vertexPosition,
D3DXVECTOR2 vertexTextureCoordinate,
D3DXVECTOR3 vertexDirection,
D3DXVECTOR3 vertexColorMultipler)
{
_vertexPosition = vertexPosition;
_vertexTextureCoordinate = vertexTextureCoordinate;
_vertexDirection = vertexDirection;
_vertexColorMultipler = vertexColorMultipler;
}
virtual const D3DVERTEXELEMENT9 * GetVertexDeclaration() const
{
return particleVertexDeclarations;
}
};
Yes, indeed you should trust the compiler to optimally "move" the structures:
Want Speed? Pass By Value
Guideline: Don’t copy your function arguments. Instead, pass them by value and let the compiler do the copying
In this case, you'd move the arguments into the constructor call:
ParticleVertex myPV(std::move(pos),
std::move(textureCoordinate),
std::move(direction),
std::move(colorMultipler));
In many contexts, the std::move will be implicit, e.g.
D3DXVECTOR4 getFooPosition() {
D3DXVECTOR4 result;
// bla
return result; // NRVO, std::move only required with MSVC
}
ParticleVertex myPV(getFooPosition(), // implicit rvalue-reference moved
RVO means Return Value Optimization not Right value optimization.
RVO is a optimization performed by the compiler when the return of a function is by value, and its clear that the code returns a temporary object created in the body, so the copy can be avoided. The function returns the created object directly.
What C++11 introduces is Move Semantics. Move semantics allows us to "move" the resource from a certain temporary to a target object.
But, move implies that the object wich the resource comes from, is in a unusable state after the move. This is not the case (I think) you want in your class, because the vertex data is used by the class, even if the user calls to this function or not.
So, use the common return by const reference to avoid copies.
On the other hand,, DirectX provides handles to the resources (Pointers), not the real resource. Pointers are basic types,its copying is cheap, so don't worry about performance. In your case, you are using 2d/3d vectors. Its copying is cheap too.
Personally, I think that returning a pointer to an internal resource is a very bad idea, always. I think that in this case the best aproach is to return by const reference.