Trying to build ocaml-websocket, it fails with:
File "lib/websocket.ml", line 202, characters 29-42:
Error: The function applied to this argument has type
?buffer_size:int ->
(Lwt_io.input_channel * Lwt_io.output_channel) Lwt.t
This argument cannot be applied with label ~setup_socket
The function line in question is,
lwt ic, oc = Lwt_io.open_connection ~setup_socket sockaddr in
Any idea, if the lwt API was changed in previous release?
I used a customized version of Lwt, that’s why. I’m going to release a new version, compatible with normal Lwt, very soon.
Related
When debugging C/C++ function that with many arguments, and each arguments may still call some functions, people have to repeated typing step and finish, then reach where this function's body part.
e.g. I'm using OpenCV's solvePnP() function, it requires many arguments:
solvePnP(v_point_3d,v_point_2d,K,D,R,T);
Among which, each argument will be converted from cv::Mat to cv::InputArray, thus calling a init() function.
What I expected is, directly go to where solvePnP() implemented, and I'm not interested in each argument type conversion.
Luckily, there is advance command in gdb. Official document is here， writes:
advance location
Continue running the program up to the given location. An argument is required, which should be of one of the forms described in Specify Location. Execution will also stop upon exit from the current stack frame. This command is similar to until, but advance will not skip over recursive function calls, and the target location doesn’t have to be in the same frame as the current one.
This gdb advance command really helps. And what's the equivalent command in LLDB?
I've search in lldb official's gdb => lldb command mapping web page, https://lldb.llvm.org/use/map.html , but not found.
Edit: I forgot to mention, the gdb usage for me is
(gdb) b main
(gdb) r
(gdb) advance solvePnP
Checkout the sif command for lldb. sif means **Step Into Function
Reference: How to step-into outermost function call in the line with LLDB?
To get all the supported commands of LLDB, one should first go into lldb command, then type help, then there will be the explanations for sif:
sif -- Step through the current block, stopping if you step directly into a function whose name matches the TargetFunctionName.
I'm trying to use the C++ integration with GPSD on a Pi. If I run GPSMON I can verify that I have a full fix without issue, however in my C++ program I am getting a fix with mode 0, which means "MODE UPDATE NOT SEEN YET".
The program isn't erroring out at the socket connection, so I'm not sure what's causing the disconnect.
I suppose you are using libgps and libgpsmm. Your problem may be caused by a version incompatibility between gpsd daemon and libgps.
I.e. the client (libgps) may speak a different version of the "API protocol" gpsd_json than the gpsd daemon.
This may happen if you decided to build/link a static version of libgps -- which does not exactly match the version number of gpsd. Or if your client runs on a diffent machine than gpsd server.
I ran into same problem and it took me valuable time to figure out the reason:
JSON parser in libgps is designed badly. It ignores/discards JSON objects which contain name/value pairs, which are not known a priori.
So whole TPV messages from gpsd may be discarded and your client implementation shows no error message, neither libgps functions return an error code. Too bad.
Here it is (json.c, line 296+, #2016-07-27):
if (cursor->attribute == NULL) {
json_debug_trace((1,
"Unknown attribute name '%s' (attributes begin with '%s').\n",
attrbuf, attrs->attribute));
/* don't update end here, leave at attribute start */
return JSON_ERR_BADATTR;
}
And here (libgps_json.c, line 27+, #2016-07-27):
static int json_tpv_read(const char *buf, struct gps_data_t *gpsdata, const char **endptr)
{
const struct json_attr_t json_attrs_1[] = {
{"class", t_check, .dflt.check = "TPV"},
{"device", t_string, .addr.string = gpsdata->dev.path, .len = sizeof(gpsdata->dev.path)},
{"time", t_time, .addr.real = &gpsdata->fix.time, .dflt.real = NAN},
...
Use _gpsmm->enable_debug( level, stderr ) with level>=6 and compile libgps, libgpsmm with define CLIENTDEBUG_ENABLE to get the debug trace output.
git repositiory of gpsd sources tells us dates of recent incompatible changes on the gpsd_json protocol:
git commits:
2016-04-07 Add "status" to TPV for DGPS notification
2016-01-04 Address Savannah bug #46804: JSON satellite view parsing is somewhat broken.
2015-04-04 Add client-library parsing of PPS precision.
2015-01-24 In client library, "dip" member was missing from ATT parsing.
Releases:
3.11 23-Aug-2014
3.12 22-Feb-2015 incompatible
3.13 26-Feb-2015
3.14 14-Mar-2015
3.15 03-Jun-2015 incompatible
3.16 08-Jan-2016 incompatible
3.17 xx-xxx-xxxx incompatible
Do gpsd developers not care about client-server compatibility across versions? What about shared libgps library binary API/ABI stability then?
It is missing versioning functions. Very unsafe also.
(Look at the comment git comment on the 2015-04-04 change mentioned above: Data is currently discarded, pending the next gps_data_t structure break.)
I have a program that uses the Bytes module from the Ocaml standard library and also opens the Core_kernel.Std module at the top of the file
open Core_kernel.Std
...
let let buf = Bytes.make bom_len '\x00' in
The problem I am having is that the latest version of Core_kernel introduced a new Bytes module that is shadowing the one from the standard library, which is resulting in a Unbound value Bytes.make compilation error.
Is there a way to solve this naming issue without getting rid of the open at the top of the file? If I did that it would require changing lots of things.
You could provide an alternative name for the Bytes module as such:
module B = Bytes
open Core_kernel.Std
let buf = B.make 10 '\x00'
and then do a search-replace in your code to change Bytes by B.
Another solution would be to avoid using open, but this would require a lot of changes in your code, I guess.
Core_kernel provides Caml module that binds everything that is available in standard library.
So, you could write this as
open Core_kernel.Std
...
let buf = Caml.Bytes.make bom_len '\x00' in
Unfortunately, Caml.Bytes is added only in 113.00.00 version that is not in OPAM yet.
While compiling an OCaml application I get the following error:
File "/tmp/ocamlpp466ee0", line 308, characters 34-233:
Error: Signature mismatch:
...
The field `unlock' is required but not provided
The field `lock' is required but not provided
Command exited with code 2.
My guess is that the error is releated with the OCaml library Datalog (I've installed the version 0.3 from here) because the line 308 in the file is /tmp/ocamlpp466ee0 the first one in the following code
module Logic = Datalog.Logic.Make(struct
type t = atom
let equal = eq_atom
let hash = hash_atom
let to_string a = Utils.sprintf "%a" pp_atom a
let of_string s = atom_of_json (Json.from_string s)
end)
I would really appreciate if someone could help me to know what I am doing wrong.
Moreover, I would like to undestand why the file /tmp/ocamlpp466ee0 is generated each time I execute 'make'? I tried to understand by reading the Makefile but I did not succeed.
I think that something have changed in Datalog library and in some version > 0.3 functor Datalog.Logic.Make requires module argument with values lock and unlock declared. So, it's version problem.
About temporary file. As you can see, its name consists of ocaml literal, pp which means preprocessor and some number. Preprocessors in OCaml usually work this way: they read input source file and write output source files. That's why some temporary files are created.
I opened a file in "SML of New Jersey" with the following command: use "c:\\work.sml", and it gives me the next problem:
[openning c:\\work5.sml]
[use failed: Io: openln failed on "c:\\work.sml", Win32TextPrimIO:openRd: failed]
uncaught Exception error
raised at:../complier/TopLevel/interact.sml:24.14-24.28
In work.sml, I have just this one line:
- datatype ’a seq = Nil | Cons of ’a * (unit -> ’a seq);
Your file contains two errors:
The - at the beginning of the line needs to be removed.
The ’s should be 's.
However these should cause a syntax error and a bunch of "illegal token" errors respectively, not an IO error.
The only reason I can think of that you get the error you do is that you mistyped the file name.
I suddenly started experiencing this problem as well after I pinned the shortcut to SML New Jersey to my task bar. If I ran SML from this shortcut and tried to "use" a .sml file it would give this error.
So basically make sure your SML.exe is in the same folder as your .sml programs and this should work fine again.