From Java code I'm pushing into Renjin a data.frame. The fisrt vector of this data frame contains native Java objects as ExternalPtr. Everything works fine including accessing those objects from R code. Nevertheless, I noticed that printing those objects (for debugging purpose) using the print() function does not help much.
print( ptr )
is printing the classname and a sort of hashcode:
<pointer: foo.Class#f0815dc
Similarly
print( list-of-ptr )
is printing:
[[1]] <pointer: foo.Class#3a915df8
[[2]] <pointer: foo.Class#2e4b32f7
Is there anyway to have the #toString() or any other Java method being called?
By the way, I noticed that printing the whole data frame is throwing an exception:
Caused by: org.renjin.eval.EvalException: Invalid argument:
format(externalptr, logical, NULL, integer, NULL, integer, logical, logical)
Expected:
format(character, logical(1), any, any, any, integer(1), logical(1), any)
format(LogicalVector, logical(1), any, any, any, integer(1), logical(1), any)
format(DoubleVector, logical(1), any, integer(1), any, integer(1), logical(1), any)
format(IntVector, logical(1), any, integer(1), any, integer(1), logical(1), any)
at org.renjin.primitives.R$primitive$format.doApply(R$primitive$format.java:96)
Is there anyway to prevent that?
Related
I have a really huge project with hundreds of thousands lines of code.
My application has a complex graphical interface.
For some reason, sometimes my main form is resized, and I just don't see why / how this happens.
To track down the reason for the resizing, I installed a window subclass.
Private Sub iSubclass_WndProc(ByVal bBefore As Boolean, bHandled As Boolean, lReturn As Long, ByVal lng_hWnd As Long, ByVal uMsg As eMsg, ByVal wParam As Long, ByVal lParam As Long, lParamUser As Long)
These are the parameters of the window message for WM_SIZING when this undesired resize occurs:
wParam = 9
lParam = 1697980
lParamUser = 0
The resizing only occurs only like once each 2 hours, so debugging is really difficult already.
How could I track any further who / which function is responsible for the resizing?
I am trying to build a unit test like so:
// region is a (Double, Double) tuple
XCTAssertEqual(region, (0.0, 200.0))
But Xcode is giving me an error: Cannot invoke 'XCTAssertEqual' with an argument list of type ((Double, Double), (Double, Double))
Is there a different way to test tuples without extracting their members and testing individually?
XCTAssertEqual requires that the two parameters passed to it are Equatable, which you can see from the method signature. Note that expression1 returns T?, and T must be Equatable:
func XCTAssertEqual<T : Equatable>(_ expression1: #autoclosure () throws -> T?, _ expression2: #autoclosure () throws -> T?, _ message: #autoclosure () -> String = default, file: StaticString = #file, line: UInt = #line)
But Swift tuples aren't Equatable, so you can't use them with XCTAssertEqual.
Tuples do have an == method — they just don't conform to the protocol — so you could do something like this:
let eql = region == (0.0, 200.0)
XCTAssertTrue(eql)
Or even:
XCTAssertTrue(region == (0.0, 200.0))
Edit: I've expanded on this answer in a blog post, How to Make Specialized Test Assertions in Swift
A disadvantage of using
XCTAssertTrue(region == (0.0, 200.0))
is the inadequate reporting it gives upon failure:
XCTAssertTrue failed -
Now you have to track down what the actual values are, to understand what went wrong.
But you can add diagnostic information to the assertion like this:
XCTAssertTrue(region == (0.0, 200.0), "was \(region)")
For example:
XCTAssertTrue failed - was (1.0, 2.0)
If you plan to have several tests that compare this tuple, I wouldn't want to have to repeat this everywhere. Instead, create a custom assertion:
private func assertRegionsEqual(actual: (_: Double, _: Double), expected: (_: Double, _: Double), file: StaticString = #file, line: UInt = #line) {
if actual != expected {
XCTFail("Expected \(expected) but was \(actual)", file: file, line: line)
}
}
Now the test assertion is
assertRegionsEqual(actual: region, expected: (0.0, 200.0))
Upon failure, this yields a message like
failed - Expected (0.0, 200.0) but was (1.0, 2.0)
I'm trying to implement a Ping program in vb6 which works for both IPv4 & IPv6 addresses. The IPv4 implementation uses IcmpSendEcho which is working fine, but the IPv6 implementation uses Icmp6SendEcho2 and I'm having a lot of difficulty getting it to work.
The function call works fine and it does not error out but the return value is always 0, and GetLastError returns 0 indicating that no errors occurred
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366041(v=vs.85).aspx
The process I follow is as follows:
Load the windows sockets dll by calling WSAStartup
Open a port handle via a call to Icmp6CreateHandle
Send a ICMP ECHO message via a call to Icmp6SendEcho2 and analyze the response
close the port handle by calling IcmpCloseHandle
Unload dll by calling WSACleanup
The definition of Icmp6SendEcho2 is as follows
Private Declare Function Icmp6SendEcho2 Lib "Iphlpapi.dll" _
(ByVal IcmpHandle As Long, _
ByVal EventtoRaise As Long, _
ByVal ApcRoutine As Long, _
ByVal ApcContext As Long, _
ByVal SourceAddressPointer As Long, _
ByVal DestinationAddressPointer As Long, _
ByVal RequestData As String, _
ByVal RequestSize As Long, _
ByVal RequestOptions As Long, _
ReplyBuffer As ICMPV6_ECHO_REPLY, _
ByVal ReplySize As Long, _
ByVal timeOut As Long) As Long
Where ICMPV6_ECHO_REPLY is defined as follows
Private Type ICMPV6_ECHO_REPLY
Address As IPV6_ADDRESS
Status As Long
RoundTripTime As Long
End Type
Private Type IPV6_ADDRESS
sin6_port As Integer
sin6_flowinfo As Long
sin6_addr(1 To 8) As Integer
sin6_scope_id As Long
End Type
The call to Icmp6SendEcho2 is made as follows
lPingResponse = Icmp6SendEcho2(lPortHandle, 0, 0, 0, VarPtr(SourceAddress), VarPtr(DestinationAddress), sMessage, Len(sMessage), 0, Reply, Len(Reply), timeOut)
I used the following link for implementing Ping for IPv4
https://support.microsoft.com/en-us/kb/300197
Any help would be awesome
Nish
The issue was associated with there not being a sufficient buffer to get the response. Changing the response structure to something like this did the trick
Private Type ICMPV6_ECHO_REPLY
Address As IPV6_ADDRESS
Status As Long
RoundTripTime As Long
data(0 To 1023) As Byte
End Type
I've been trying to figure out why the function below throws an error saying "Type Mismatch" when it returns. From what I know about VB6, this should work without any issue, yet it obviously does not. Can anyone see what I am doing wrong here and let me know how I can fix it? Thanks in advance.
Private Function GetByteArray(source As Variant, index As Integer, length As Integer) As Variant
Dim buff() As Byte
ReDim buff(0 To length - 1)
Dim i As Integer
For i = 0 To length - 1
buff(i) = CByte(source(index + i))
Next i
GetByteArray = buff
End Function
It turns out that the problem did not have anything to do with the Function I posted, but rather with what I was doing with the result. I was using the method to get the bytes of a double, and then using CDbl to get the double value. This is where the error was really happening.
The way I should have been doing this is to use the following code:
CopyMemory rfcTest.rfcFloat, GetByteArray(buff, 0, 8), Len(rfcTest.rfcFloat)
Note that in order to use this, you must also declare the CopyMemoryMethod like this:
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDest As Any, pSrc As Any, ByVal ByteLen As Long)
I'm having trouble using pipes in a larger application and so I created a minimal test application to investigate the problem.
I'm creating a pipe:
Dim sa As SECURITY_ATTRIBUTES
Dim R As Long
sa.nLength = Len(sa)
sa.bInheritHandle = 1
R = CreatePipe(hRead, hWrite, sa, 0) //hRead declared globally
Debug.Print "CreatePipe: " & R
and then I'm reading from it:
Const BufSize As Long = 1024
Dim Buffer(BufSize) As Byte
Dim lBytesRead As Long
Dim R As Long
R = ReadFile(hRead, Buffer(0), BufSize, lBytesRead, 0)
Debug.Print "ReadFile: " & R
Debug.Print Err.LastDllError
Now as far as I understand the ReadFile call should block, because nobody has written any data into the pipe.
The problem: That only happens iff I put the code right after the CreatePipe code. As soon as I put it into a separate function, it fails with the last error being ERROR_INVALID_HANDLE. (I confirmed that the value of hRead does not change)
I have absolutely no idea what's causing this kind of behaviour.
I found the solution myself. It was a rather stupid beginner's mistake, but I found some users having the same problem and since the error symptoms where not at all pointing in the right direction, I'll post my solution.
First I did further refactorings to dumb down the code even more. After making each and every variable global, I finally got a "invalid calling convention" error on the ReadFile call.
To make a long story short, the import declaration and the actual call of ReadFile were wrong for the last parameter (the OVERLAPPED parameter)
This is what I did:
Declare Function ReadFile ..., lpOverlapped As Any) As Long
Call ReadFile(..., 0)
Correct would be any one of these:
Declare Function ReadFile ..., lpOverlapped As Any) As Long
Call ReadFile(..., ByVal 0)
Declare Function ReadFile ..., ByVal lpOverlapped As Long) As Long
Call ReadFile(..., 0)
Declare Function ReadFile ..., lpOverlapped As OVERLAPPED) As Long
Call ReadFile(..., myVariableOfTypeOverlapped)