I have a test that compares the equality of two pointers to instances of a struct (MyStruct). The pointers are stored within other structs (container1 and container2). Here's how I check the equality:
require.Equal(*container1.MyStruct, *container2.MyStruct)
the Equals() method is from the Testify library: https://github.com/stretchr/testify/blob/master/require/require_forward.go#L128
This test passes when I run it on my Mac. However, when I push my changes to our build server (Linux), the test fails. The error message is the standard Error: Not equal... message, but when I diff the expected and actual shown in the output, they're exactly the same!
I thought maybe Go is somehow comparing the addresses of the pointers rather than the contents, but the comment on require.Equal makes this seem unlikely:
// Pointer variable equality is determined based on the equality of the referenced values (as opposed to the memory addresses)
Any idea what's going on here? Does Go behave differently on Mac vs Linux?
I'm not able to post specifics here as it's an issue I'm seeing in a codebase I touch at work.
The problem is that there's a bug in the output of the Equal function's "expected... actual..." printing logic for structs when the struct contains a Time object. Here's a snippet from the error output: (I've removed the irrelevant fields of the struct):
Error Trace: my_test.go:388
my_test.go:50
Error: Not equal:
expected: {
BuildStartDateUtc: 2020-08-17 22:43:05.330062876 +0000 UTC,
actual : {
BuildStartDateUtc: 2020-08-17 22:43:05.330062876 +0000 UTC,
}
Fields look the same. However, if I compare MyStruct.BuildStartDateUtc directly, I get this:
expected: &time.Time{wall:0x389ccfe6, ext:63733398658, loc:(*time.Location)(0x101d4e0)}
actual : &time.Time{wall:0x389ccfe6, ext:63733398658, loc:(*time.Location)(nil)}
The "loc" field is missing in the actual. This is what's causing the comparision to fail, but since "loc" evidently is not included in the output when we compare a struct that contains a Time, we get a very confusing "expected... actual..." output where the actual/expected look exactly equal when they're not.
When I syncronized the Location of the Times being compared the test passed.
Looks like it might be related to this Testify issue: https://github.com/stretchr/testify/issues/984
Related
So I have this fake object definition, that has a fake method in it :
// Note: This is a simplified version of my code.
// If it turns out that such issues could come from complex method prototypes,
// then I'll post the full setup.
IFooRepositoryClass fooRepo = A.Fake<IFooRepositoryClass>();
A.CallTo(() => fooRepo.FooFunctionAsync(A<Guid>.Ignored).ReturnsLazily(
(Guid fooId) => {
fooInternalObject.DoSomething(fooId);
}
);
As you can see, nothing out of the ordinary.
Later, in my XUnit tests, I call the fake function :
Guid testGuid = new Guid("aaaaaaaa-9a88-4746-914b-aaaaaaaaaaaa"); //I changed to "aaaaa" to make it easily recognizable
await fooRepo.FooFunctionAsync(testGuid).configureAwait(false);
I put a breakpoint on that instruction :
await fooRepo.FooFunctionAsync(testGuid).configureAwait(false);
...I see that testGuid is indeed aaaaaaaa-9a88-4746-914b-aaaaaaaaaaaa
But then I put a breakpoint inside, on this instruction :
fooInternalObject.DoSomething(fooId);
To my great surprise, fooId has a weird value with lots of zeros, different at each run!
f933b838-007b-0000-0000-000000000000
785bb288-001a-0000-0000-000000000000
4d4bb8d8-0012-0000-0000-000000000000
etc.
As you can see it's not Guid.Empty, just Guids that look suspiciously manufactured.
What the hell is going on? Can FakeItEasy do that to Guids?
Even weirder : I shared my branch to a colleague, and he checked it out. So he has the exact same code as me.
...But for him, fooId has the expected value, i.e. the value of testGuid! We peeked at each other's screen and every execution conditions seem identical. Only the Guid differs at the breakpoint : Expected value for him, bogus values for me. I cleaned the solution, rebuilt, even restarted VS. to no avail!
What the hell is going on? x2
I'm not expecting anyone to fix my unit tests, but maybe this is a well-known behaviour under certain conditions. Ever seen that? Especially those weird 000000 Guid values? Something has to differ between our setups, but I need a lead to know where to look.
I'm struggling to figure out a reason for this behavior, or maybe this is suppose to happen and I just wasn't aware.
For background, I'm using proto3, and am doing this in Go1.15, and I do know that packed is the default in proto3, and I'm relatively new to protobufs.
I defined the following message in a proto file:
message Response {
repeated uint32 points = 1 [packed=true];
}
Which will generate the following code using protoc-gen-go v1.25.0.
type Response struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Points []uint32 `protobuf:"varint,3,rep,packed,name=points,json=points,proto3" json:"points,omitempty"`
}
I go to use the new struct, and it doesn't behave like I would normally expect a struct to behave. Here's some things I wrote, along with what was printed out.
newResponse := pb.Response{Points: []uint32{2,4,6,8}}
fmt.Println(newResponse)
//{{{} [] [] <nil>} 0 [] [2 4 6 8] --> I expect this
refToNewResponse := &newResponse
fmt.Println(refToNewResponse)
// points:2 points:4 points:6 points:8 --> not what I expected
Now you might be thinking, it's just formatting big deal.
But I expect a list... not numbers that each individually have a label. I've seen and used other protobufs... and when I see the response that they return, it doesn't look like this, it's one label to a list like:
points: [2 4 6 8]
I do need to use the reference version of this because I eventually want to expand and use a list of Responses which the generated code will spit out a slice of pointer Responses, but I can't understand why it's separating and labeling each element in the slice.
I'm hoping someone can point out something I'm doing or not doing that is causing this... thank you in advance.
This is indeed just formatting. Nothing has changed in the underlying data structure. You requested a repeated uint32 Points and it's literally printing them that way.
The marshaler in the protobuf implementation can really output whatever it likes, there is no reference version of the human-readable representation of a protobuf.
If you really must have a custom format for the .String() output, you can try a different proto library such as gogoprotobuf, or try various extensions. But ultimately, it's just human-readable output.
Note:
this has nothing to do with packed=true (which is indeed the default).
if you're confused about printing the pointer vs the basic type, it's because the String() method has a pointer receiver. See this question
Am trying to read the lotus notes document using VB6.I can able to read the values of the but suddenly type mismatch error is throwed.When i reintialise the vb6 variable it works but stops after certain point.
ex; address field in lotus notes
lsaddress=ImsField(doc.address)
private function ImsField(pValue)
ImsField=pValue(0)
end function
Like this I am reading the remaining fields but at certain point the runtime error "13" type mismatch error throwed.
I have to manually reintialize by
set doc=view.getdocumentbykey(doclist)
The type mismatch error occurs for a certain field. The issue should be a data type incompatibility. Try to figure out which field causes the error.
Use GetItemValue() instead of short notation for accessing fields and don't use ImsField():
lsaddress=doc.GetItemValue("address")(0)
The type mismatch is occurring because you are encountering a case where pValue is not an array. That will occur when you attempt to reference a NotesItem that does not exist. I.e., doc.MissingItem.
You should not use the shorthand notation doc.itemName. It is convenient, but it leads to sloppy coding. You should use getItemValue as everyone else is suggesting, and also you should check to see if the NotesItem exists. I.e.,
if doc.hasItem("myItem") then
lsaddress=doc.getItemValue("myItem")(0)
end if
Notes and Domino are schema-less. There are no data integrity checks other than what you write yourself. You may think that the item always has to be there, but the truth is that there is nothing that will ever guarantee that, so it is always up to you to write your code so that it doesn't assume anything.
BTW: There are other checks that you might want to perform besides just whether or not the field exists. You might want to check the field's type as well, but to do that requires going one more level up the object chain and using getFirstItem instead of getItemValue, which I'm not going to get into here. And the reason, once again, is that Notes and Domino are schema-less. You might think that a given item must always be a text list, but all it takes is someone writing sloppy code in an one-time fix-it agent and you could end up having a document in which that item is numeric!
Checking your fields is actually a good reason (sometimes) to encapsulate your field access in a function, much like the way you have attempted to do. The reason I added "sometimes" above is that your code's behavior for a missing field isn't necessarily always going to be the same, but for cases where you just want to return a default value when the field doesn't exist you can use something like this:
lsaddress ImsField("address","")
private function ImsField(fieldName,defaultValue)
if doc.hasItem(fieldName) then
lsaddress=doc.getItemValue(fieldName)(0)
else
lsaddress=defaultValue
end if
end function
Type mismatch comes,
When you try to set values from one kind of datatype variable to different datatype of another variable.
Eg:-
dim x as String
Dim z as variant
z= Split("Test:XXX",":")
x=z
The above will through the error what you mentioned.
So check the below code...
lsaddress = ImsField(doc.address)
What is the datatype of lsaddress?
What is the return type of ImsField(doc.address)?
If the above function parameter is a string, then you should pass the parameter like (doc.address(0))
So I'm doing some business logic and want to run some code that goes like
select id from blah where foo = 1234 for update nolock
This code throws a DataMapper::SQLError when the corresponding row in blah is locked. This is desirable behavior; I would like to catch this error and use it to inform my application logic. But I want to re-throw any other SQL errors, because they're different than the case I'm programming for, and catching them in the same way would be wrong.
The error object returned has a string error message, and a numeric code (50463045). It seems like comparing on the numeric code would be great, but I don't want to embed the constant 50463045 in my code without some modicum of understanding of how the heck it was determined. Notably, the Postgres manual suggests that the error code for this state is 55P03, and that doesn't seem to be the same thing. I don't have any idea how much I can trust this magic number, and how to determine it except for experimentally, so I'm not really comfortable with using it.
How is the error code determined?
The Internet was distressingly unhelpful, since searching for stuff about DataObjects SQL errors seems to mostly return problems with other software raising the errors, not information on the errors themselves... but after locating the right source code and browsing around through the source code I finally located do_postgres.c:
void do_postgres_raise_error(VALUE self, PGresult *result, VALUE query) {
const char *message = PQresultErrorMessage(result);
char *sql_state = PQresultErrorField(result, PG_DIAG_SQLSTATE);
int postgres_errno = MAKE_SQLSTATE(sql_state[0], sql_state[1], sql_state[2], sql_state[3], sql_state[4]);
PQclear(result);
data_objects_raise_error(self, do_postgres_errors, postgres_errno, message, query, rb_str_new2(sql_state));
}
Notice how a 5-character state is passed to MAKE_SQLSTATE... and then also passed to data_objects_raise_error itself. I couldn't track down where MAKE_SQLSTATE is defined to figure out what crazy manipulations are going on to make this integer, but it appears I can just use the error object's .sqlstate property directly, and make my condition e.sqlstate == '55P03'.
I am trying to animate an actor in Clutter, but when I enter a property that exists, something goes wrong.
actor.animate( AnimationMode.LINEAR, 400, scale_x:2);
gives me this error
Clutter-WARNING **: Cannot bind property '\x83\xec\u0014\x89\xc6e\xa1\u000c': objects of type 'ClutterTexture' do not have this property
Looks like Unicode-characters to me.
However, when I enter a property that does NOT exist
actor.animate( AnimationMode.LINEAR, 400, thisdoesntwork:2);
I get an error that makes much more sense
Clutter-WARNING **: Cannot bind property 'thisdoesntwork': objects of type 'ClutterTexture' do not have this property
I get the exact same problem when I try this alternative approach:
actor.animate( AnimationMode.LINEAR, 400, "scale-x", 2);
How come all properties that actually exist get converted to some mess, and what can I do to get this to work?
You should be using 2.0 for the value, not 2. 2 is an integer, 2.0 is a double. Vala can't provide type safety for variadic methods, so you have to be careful.
As for why you're seeing the behavior you are for properties which exist, my guess is it has to do with the fact that 2 is a (32-bit) integer and 2.0 is a (64-bit) double. This is simplifying things a bit, and I don't know how much experience you have with C (probably not a lot, since this is the sort of mistake someone coming from a dynamically typed language would make), however... Clutter (well, va_arg) expects a double so it parses 64 bits of data, but you only provided 32 bits, so the first 32-bits of the next argument (NULL) are included. Now, when it starts trying to parse the next argument it starts from the wrong location (32-bits into the argument), so you get the the remainder of NULL and part of whatever garbage happened to be on the stack... Unsuprisingly, that doesn't just so happen to be 32-bits of 0s so when Clutter tests to see if the value it just read == NULL it isn't and Clutter thinks it's been given a pointer to an null-terminated array of characters (which is how strings are represented in C). It reads the data at that location, which just so happens to be \x83\xec\u0014\x89\xc6e\xa1\u000c, and checks to see if there is a property with that name. There isn't, so it emits the error message you saw.
Now, if you switch to using a property which doesn't exist, Clutter will parse the argument (the name of the property), notice that it doesn't exist (just like it did with the second property above), and emit an error.