I have a D-Bus method that takes a QDBusUnixFileDescriptor as a parameter. But I do not know how to call this method via the bus.
The documentation for QDBusUnixFileDescriptor states:
This allows applications to send and receive Unix file descriptors over
the D-Bus connection, mapping automatically to the D-Bus type 'h'.
To call other methods I am using QDBusInterface::call which takes the method name and a bunch of QVariants. QVariant is not implemented for QDBusUnixFileDescriptor.
I've been unable to locate any examples either in Qt documentation, at github, or with google.
How can I call a bus method that takes a QDBusUnixFileDescriptor as a parameter?
I am rather new in Qt, but as good as I know you can check
QVariant::fromValue(yourQDBusUnixFileDescriptor)
Good luck
Related
I want to use mbeans on startup of j2ee application to check if all the MDBs are running and jms specification has been activated.
Any pointers will be very helpful
The only way I know of to do this would be to use the ServerEndpointControl MBean. This is a Liberty specific MBean for controlling the input sources for work into the runtime. This can also be used to get status on http listeners.
The best place to find the Javadoc for the MBean is here. To find out if an MBean is running you call the isPaused method providing the MDB name which is defined as:
ApplicationName#ModuleName#BeanName
if the MDB is running it'll return false.
The pprof package documentation says
The package is typically only imported for the side effect of registering its HTTP handlers. The handled paths all begin with /debug/pprof/."
The documentation says if you already have an http server running you don't need to start another one but if you are not using DefaultServeMux, you will have to register handlers with the mux you are using.
Shouldn't I always use a separate port for pprof? Is it okay to use the same port that I am using for prometheus metrics?
net/http/pprof is a convenience package. It always registers handlers on DefaultServeMux, because DefaultServeMux is a global variable that it can actually do that with.
If you want to serve pprof results on some other ServeMux there's really nothing to it; all it takes is calling runtime/pprof.StartCPUProfile(w) with an http.ResponseWriter and then sleeping, or calling p.WriteTo(w, debug) on a runtime/pprof.Profile object. You can look at the source of net/http/pprof to see how it does it.
In a slightly better universe, net/http/pprof would have a RegisterHandlers(*http.ServeMux) function that could be used anywhere, you would be able to import it without anything being registered implicitly, and there would be another package (say net/http/pprof/sugar) that did nothing except call pprof.RegisterHandlers(http.DefaultServeMux) in its init. However, we don't live in that universe.
Both have same parameter except Get Request have extra one json
Here is one example
Create Session httpbin http://httpbin.org
&{params}= Create Dictionary key=value key2=value2
${resp}= Get Request httpbin /get params=${params}
log to console ${resp.content}
In line 3 get method takes parameter , can we use Get Request and Get method together.I am unable to relate how both method works in line 3
When you call the keyword Get Request after having imported RequestsLibrary, that keyword calls the method get_request that is part of the definition of the RequestsLibrary class. They aren't different, one is just the public interface to the internal method. When robot sees you call the Get Request keyword, it scans the libraries for a method named get_request. The method in the library is then called.
Any parameter that the get_request method takes is perfectly valid when calling the keyword. Again, the keyword and the method are identical. They are exactly the same thing.
Apparently, the json parameter that you are asking about was added fairly recently. I guess either that version of the library hasn't been released yet, or the documentation hasn't been updated.
If the version of RequestsLibrary on your computer has the json parameter, you can use that in your test.
I have created a Bluetooth communicator in Qt 5.5.1 following the Qt documentation. I have gotten to the point where I am able to view a list of services offered by a Bluetooth device. The services are generated by:
QLowEnergyService *service = controller->createServiceObject(serviceUuid);
Where controller is a QLowEnergyController and serviceUuid is a QBluetoothUuid. The service is created successfully but since it is a custom service offered by the device I am trying to connect to, the name is unknown. At this point I call:
service->discoverDetails();
which transitions the service to the QLowEnergyService::DiscoveringServices state from the QLowEnergyService::DiscoveryRequired state. Once this happens, the state never changes again and no error is ever thrown. Is there a way to pull the characteristics of an "unknown service"? I have checked the Uuid against what I expected for the service and it is correct. I also have the Uuid of the expected characteristics.
Note: I am using a pyqt (Python binding library of QT C++).
I stumbled upon issue while trying to connect to some device which offers two services. One is the standard battery service and another is private custom non-standard service.
I noticed that I was able to discover the batter service successfully, but I was not able to discover that custom service. However, for some reason, when I subscribed to service_error signal, the discovery works fine, and whenever i comment it out, it does not work.
void QLowEnergyService::error(QLowEnergyService::ServiceError newError)
I know it is funny and I do not have an explanation, but it could be related and i felt it is worth sharing.
QMetaObject::invokeMethod(this, "discoverCharacteristics", Qt::QueuedConnection);
void discoverCharacteristics() {
service->discoverDetails();
}
For a user application (not a driver) using WinUSB, I use WinUsb_ControlTransfer in combination with overlapped I/O to asynchronously send a control message. Is it possible to cancel the asynchronous operation? WinUsb_AbortPipe works for all other endpoints but gives an 'invalid parameter' error when the control endpoint is passed (0x00 or 0x80 as the pipe address). I also tried CancelIo and CancelIoEx but both give an 'invalid handle' error on the WinUSB handle. The only related information I could find is on http://www.winvistatips.com/winusb-bugchecks-t335323.html, but offers no solution. Is this just impossible?
Probably not useful to the original asker any more, but in case anyone else comes across this: you can use CancelIo() or CancelIoEx() with the file handle that you originally passed in to WinUsb_Initialize().
This is similar to how the documentation of WinUsb_GetOverlappedResult says:
This function is like the Win32 API routine, GetOverlappedResult, with one difference—instead of passing a file handle that is returned from CreateFile, the caller passes an interface handle that is returned from WinUsb_Initialize. The caller can use either API routine, if the appropriate handle is passed. The WinUsb_GetOverlappedResult function extracts the file handle from the interface handle and then calls GetOverlappedResult.