companion_cube changed the topic of #ocaml to: Discussions about the OCaml programming language | http://www.ocaml.org | OCaml 4.11 release notes: https://caml.inria.fr/pub/distrib/ocaml-4.11/notes/Changes | Try OCaml in your browser: http://try.ocamlpro.com | Public channel logs at http://irclog.whitequark.org/ocaml
_whitelogger has joined #ocaml
zolk3ri has quit [Quit: leaving]
raver has quit [Read error: Connection reset by peer]
<d_bot> <beheddard> ```
<d_bot> <beheddard> (library
<d_bot> <beheddard> (name olm_c_type_descriptions)
<d_bot> <beheddard> (public_name olm.c_type_descriptions)
<d_bot> <beheddard> (modules Olm_c_type_descriptions)
<d_bot> <beheddard> (libraries ctypes))
<d_bot> <beheddard>
<d_bot> <beheddard> (executable
<d_bot> <beheddard> (name generate_types_start)
<d_bot> <beheddard> (modules Generate_types_start)
<d_bot> <beheddard> (foreign_archives vendor/libolm/build/olm)
<d_bot> <beheddard> (libraries ctypes.stubs olm_c_type_descriptions))
<d_bot> <beheddard>
<d_bot> <beheddard> (rule
<d_bot> <beheddard> (with-stdout-to generate_types_step_2.c
<d_bot> <beheddard> (run ./generate_types_start.exe)))
<d_bot> <beheddard>
<d_bot> <beheddard> (rule
<d_bot> <beheddard> (targets generate_types_step_2.exe)
<d_bot> <beheddard> (deps (:c generate_types_step_2.c))
<d_bot> <beheddard> (action (bash "\
<d_bot> <beheddard> %{cc} %{c} \
<d_bot> <beheddard> -I '%{lib:ctypes:.}' \
<d_bot> <beheddard> -I %{ocaml_where} \
<d_bot> <beheddard> -I vendor/libolm/build/libolm.a -o %{targets}")))
<d_bot> <beheddard> ```
<d_bot> <beheddard> Currently trying to run through the types generation following a similar route as in https://github.com/aantron/luv/blob/master/src/c/dune (line 74+). Trying to use a pre-made static archive of course instead.
<d_bot> <beheddard> Attempting to `#include` any headers that should be in the archive fails, not finding the header.
<d_bot> <beheddard> ```
<d_bot> <beheddard> generate_types_step_2.c:1:10: fatal error: olm.h: No such file or directory
<d_bot> <beheddard> 1 | #include <olm.h>
<d_bot> <beheddard> | ^~~~~~~
<d_bot> <beheddard> compilation terminated.```
remexre has quit [Read error: Connection reset by peer]
remexre has joined #ocaml
infinity0 has quit [Ping timeout: 260 seconds]
infinity0 has joined #ocaml
<d_bot> <rgrinberg> `-I vendor/libolm/build/libolm.a` <- this is suspicious `-I` should accept directories
<d_bot> <rgrinberg> Where is the location of `olm.`?
<d_bot> <beheddard> yes I realized my mistake there. When I initially tried
<d_bot> <beheddard> ```
<d_bot> <beheddard> (action (bash "\
<d_bot> <beheddard> %{cc} %{c} \
<d_bot> <beheddard> -I '%{lib:ctypes:.}' \
<d_bot> <beheddard> -I %{ocaml_where} \
<d_bot> <beheddard> -I vendor/libolm/include -o %{targets}")))
<d_bot> <beheddard> ```
<d_bot> <beheddard> I made a typo, but it wasn't giving a directory doesn't exist error so I was trying other things, like what I pasted above
<d_bot> <rgrinberg> your dependencies also look wrong
<d_bot> <rgrinberg> how do you depend on a single source file?
<d_bot> <rgrinberg> At the very least you depend on `libolm.a`
<d_bot> <rgrinberg> and if you're using `olm.h` you should specify a dependency on it
<d_bot> <beheddard> with a deps stanza?
<d_bot> <rgrinberg> `deps` field
<d_bot> <beheddard> For current error context, it doesn't choke on the includes, but it tries to run generate_types_step_2.exe and finds my types are undeclared.
<d_bot> <beheddard>
<d_bot> <beheddard> In the libuv dune file the generate_types_step_2.exe just had deps like so:
<d_bot> <beheddard> ```
<d_bot> <beheddard> ; Based partially on
<d_bot> <beheddard> (rule
<d_bot> <beheddard> (targets generate_types_step_2.exe)
<d_bot> <beheddard> (deps (:c generate_types_step_2.c) helpers.h)
<d_bot> <beheddard> (action (bash "\
<d_bot> <beheddard> %{cc} %{c} \
<d_bot> <beheddard> -I '%{lib:ctypes:.}' \
<d_bot> <beheddard> -I %{ocaml_where} \
<d_bot> <beheddard> -I vendor/libuv/include -o %{targets}")))
<d_bot> <beheddard> ```
<d_bot> <beheddard> so I wasn't sure
<d_bot> <beheddard> `helpers.h` is a header that they wrote (not apart of the vendor libuv)
<d_bot> <beheddard> most of the dune file preceding this is building libuv with dune to produce a `.a` from what I can understand
<d_bot> <rgrinberg> > but it tries to run generate_types_step_2.exe and finds my types are undeclared.
<d_bot> <rgrinberg> What does that mean? Do you have the full error handy maybe?
<d_bot> <beheddard> I'll paste it when I get back to the computer later to smack my head some more. It was basically the bash command run to call gcc, then an error saying a type was not found.
mxns has quit [Ping timeout: 260 seconds]
mxns has joined #ocaml
CcxWrk has quit [Remote host closed the connection]
CcxWrk has joined #ocaml
mxns has quit [Ping timeout: 260 seconds]
visage_ has joined #ocaml
visage_ has quit [Quit: Textual IRC Client: www.textualapp.com]
<d_bot> <beheddard> ```
<d_bot> <beheddard> dune build
<d_bot> <beheddard> bash c/generate_types_step_2.exe (exit 1)
<d_bot> <beheddard> (cd _build/default/c && /usr/bin/bash -e -u -o pipefail -c 'gcc -O2 -fno-strict-aliasing -fwrapv -fPIC generate_types_step_2.c -I '\''/home/user/.opam/default/lib/ctypes'\'' -I /home/user/.opam/default/lib/ocaml -I vendor/libolm/include -I vendor/libolm/build -o generate_types_step_2.exe')
<d_bot> <beheddard> In file included from /home/user/.opam/default/lib/ctypes/ctypes_cstubs_internals.h:13,
<d_bot> <beheddard> from generate_types_step_2.c:11:
<d_bot> <beheddard> generate_types_step_2.c: In function ‘main’:
<d_bot> <beheddard> generate_types_step_2.c:162:76: error: ‘OlmErrorCode’ undeclared (first use in this function)
<d_bot> <beheddard> 162 | ctypes_arithmetic_type_name(CTYPES_CLASSIFY_ARITHMETIC_TYPE(OlmErrorCode)));
<d_bot> <beheddard> ```
<d_bot> <beheddard> | ^~~~~~~~~~~~
<d_bot> <beheddard> And it continues, but it's all fallout from `OlmErrorCode` not being found
<d_bot> <beheddard> I assumed because the libraries are not being loaded correctly, since the types themselves worked when I was fiddling in dynamic mode before (though the names of the types themselves aren't relevant there)
mmohammadi981266 has joined #ocaml
mmohammadi9812 has joined #ocaml
mmohammadi9812 has quit [Quit: Quit]
mmohammadi9812 has joined #ocaml
mmohammadi981266 has quit [Quit: I quit (╯°□°)╯︵ ┻━┻]
mmohammadi9812 has quit [Ping timeout: 264 seconds]
mmohammadi9812 has joined #ocaml
narimiran has joined #ocaml
mmohammadi9812 has quit [Ping timeout: 256 seconds]
<d_bot> <rgrinberg> In which header file is OlmErrorCode declared?
<d_bot> <beheddard> `error.h`
<d_bot> <rgrinberg> 1. make sure that you depend on `error.h`
<d_bot> <rgrinberg> 2. make sure that it's found through one of the include paths you've specified
<d_bot> <beheddard> if I don't have `-I vendor/libolm/include` in the bash gcc action it fails with not finding the includes e.g. `#include <error.h>`
<d_bot> <beheddard> so, the path is found anyway, could my issue be that the compiled archive is not being used?
<d_bot> <beheddard> I could be missing something here though, and assuming too much of course
<d_bot> <rgrinberg> I don't think so. Archives are used in linking, and what I see is a compilation error.
<d_bot> <rgrinberg> post the contents of error.h
<d_bot> <beheddard> ahh ok
<d_bot> <rgrinberg> Did you fix the dependencies by the way?
<d_bot> <rgrinberg> It's wrong to pass `-I foo` without depending on the contents of `foo` if `foo` exists in your dune project.
<d_bot> <beheddard> by the way, right now everything is commented out in the stubs functor other than the ErrorCode type. When I tried out with a couple other types that depended on other headers I had the same "not declared" issue.
<d_bot> <beheddard> ```c
<d_bot> <beheddard> #ifndef OLM_ERROR_H_
<d_bot> <beheddard> #define OLM_ERROR_H_
<d_bot> <beheddard>
<d_bot> <beheddard> #ifdef __cplusplus
<d_bot> <beheddard> extern "C" {
<d_bot> <beheddard> #endif
<d_bot> <beheddard>
<d_bot> <beheddard> enum OlmErrorCode {
<d_bot> <beheddard> OLM_SUCCESS = 0, /*!< There wasn't an error */
<d_bot> <beheddard> OLM_NOT_ENOUGH_RANDOM = 1, /*!< Not enough entropy was supplied */
<d_bot> <beheddard> OLM_OUTPUT_BUFFER_TOO_SMALL = 2, /*!< Supplied output buffer is too small */
<d_bot> <beheddard> OLM_BAD_MESSAGE_VERSION = 3, /*!< The message version is unsupported */
<d_bot> <beheddard> OLM_BAD_MESSAGE_FORMAT = 4, /*!< The message couldn't be decoded */
<d_bot> <beheddard> OLM_BAD_MESSAGE_MAC = 5, /*!< The message couldn't be decrypted */
<d_bot> <beheddard> OLM_BAD_MESSAGE_KEY_ID = 6, /*!< The message references an unknown key id */
<d_bot> <beheddard> OLM_INVALID_BASE64 = 7, /*!< The input base64 was invalid */
<d_bot> <beheddard> OLM_BAD_ACCOUNT_KEY = 8, /*!< The supplied account key is invalid */
<d_bot> <beheddard> OLM_UNKNOWN_PICKLE_VERSION = 9, /*!< The pickled object is too new */
<d_bot> <beheddard> OLM_CORRUPTED_PICKLE = 10, /*!< The pickled object couldn't be decoded */
<d_bot> <beheddard>
<d_bot> <beheddard> OLM_BAD_SESSION_KEY = 11, /*!< Attempt to initialise an inbound group
<d_bot> <beheddard> session from an invalid session key */
<d_bot> <beheddard> OLM_UNKNOWN_MESSAGE_INDEX = 12, /*!< Attempt to decode a message whose
<d_bot> <beheddard> * index is earlier than our earliest
<d_bot> <beheddard> * known session key.
<d_bot> <beheddard> */
<d_bot> <beheddard>
<d_bot> <beheddard> /**
<d_bot> <beheddard> * Attempt to unpickle an account which uses pickle version 1 (which did
<d_bot> <beheddard> * not save enough space for the Ed25519 key; the key should be considered
<d_bot> <beheddard> ```c
<d_bot> <beheddard> /** get a string representation of the given error code. */
<d_bot> <beheddard> const char * _olm_error_to_string(enum OlmErrorCode error);
<d_bot> <beheddard>
<d_bot> <beheddard> #ifdef __cplusplus
<d_bot> <beheddard> } // extern "C"
<d_bot> <beheddard> #endif
<d_bot> <beheddard>
<d_bot> <rgrinberg> > Did you fix the dependencies by the way?
<d_bot> <rgrinberg> @beheddard
<d_bot> <beheddard> adding deps? I've tried a couple things. I'll paste some stuff.
<d_bot> <rgrinberg> Post your compilation rule
<d_bot> <beheddard> ```
<d_bot> <beheddard> (rule
<d_bot> <beheddard> (targets generate_types_step_2.exe)
<d_bot> <beheddard> (deps (:c generate_types_step_2.c) (source_tree vendor/libolm))
<d_bot> <beheddard> (action (bash "\
<d_bot> <beheddard> %{cc} %{c} \
<d_bot> <beheddard> -I '%{lib:ctypes:.}' \
<d_bot> <beheddard> -I %{ocaml_where} \
<d_bot> <beheddard> -I vendor/libolm/include -o %{targets}")))
<d_bot> <beheddard> ```
<d_bot> <beheddard> preceded by
<d_bot> <beheddard> ```
<d_bot> <beheddard> (rule
<d_bot> <beheddard> (with-stdout-to generate_types_step_2.c
<d_bot> <beheddard> (run ./generate_types_start.exe)))
<d_bot> <beheddard> ```
<d_bot> <beheddard> I also tried `install`ing a package as Luv does, and `deps` on that, but it didn't solve my issue either
<d_bot> <beheddard> ```
<d_bot> <beheddard> (install
<d_bot> <beheddard> (section lib)
<d_bot> <beheddard> (package olm)
<d_bot> <beheddard> (files
<d_bot> <beheddard> (vendor/libolm/include/olm/crypto.h as olm/crypto.h)
<d_bot> <beheddard> (vendor/libolm/include/olm/error.h as olm/error.h)
<d_bot> <beheddard> (vendor/libolm/include/olm/inbound_group_session.h as olm/inbound_group_session.h)
<d_bot> <beheddard> (vendor/libolm/include/olm/megolm.h as olm/megolm.h)
<d_bot> <beheddard> (vendor/libolm/include/olm/olm.h as olm/olm.h)
<d_bot> <beheddard> (vendor/libolm/include/olm/outbound_group_session.h as olm/outbound_group_session.h)
<d_bot> <beheddard> (vendor/libolm/include/olm/pk.h as olm/pk.h)
<d_bot> <beheddard> (vendor/libolm/include/olm/sas.h as olm/sas.h)))
<d_bot> <beheddard> ```
<d_bot> <beheddard> adding `-l vendor/libolm/build/libolm.a` as a gcc flag also didn't change anything (incase that was an issue, but from what you said the archive is not likely my issue anyway)
<d_bot> <rgrinberg> If you were to add the archive this way, you would need to add `vendor/libolm/build/libolm.a` in the list of dependencies as well.
<d_bot> <rgrinberg> source_tree does not add dependencies on build artifacts, only sources.
<d_bot> <beheddard> ok I'll try adding that in
<d_bot> <beheddard> no change
<d_bot> <rgrinberg> post the contents of `generate_types_step_2.c`
<d_bot> <beheddard> can paste in a few blocks if you'd rather
<d_bot> <rgrinberg> if the project is on github, i'd try to reproduce
<d_bot> <beheddard> I can make it public, I just have it private right now since it is a mess as it's been a uhhh learning experience haha
<d_bot> <rgrinberg> Yeah, that would be the easiest way to proceed
<d_bot> <beheddard> ok, thank you very much! Making the change right now
Serpent7776 has joined #ocaml
<d_bot> <beheddard> Really appreciate all the help, it would take a long time of reading docs and trial and error to gain the build system knowledge I lack to get over this hump
<d_bot> <rgrinberg> This looks wrong:
<d_bot> <rgrinberg> ```
<d_bot> <rgrinberg> let t = view ~read:of_int ~write:to_int int
<d_bot> <rgrinberg> ```
<d_bot> <beheddard> thats in the dynamic ErrorCode type
<d_bot> <rgrinberg> The code generated by ctypes is:
<d_bot> <rgrinberg> ```
<d_bot> <rgrinberg> ctypes_printf(" | \"OlmErrorCode\" -> \n Cstubs_internals.build_enum_type \"OlmErrorCode\" Ctypes_static.%s ?typedef ?unexpected alist\n",
<d_bot> <rgrinberg> ctypes_arithmetic_type_name(CTYPES_CLASSIFY_ARITHMETIC_TYPE(OlmErrorCode)));
<d_bot> <rgrinberg> ```
<d_bot> <beheddard> `olm_c_type_descriptions.ml` is where the OlmErrorCode c type is reference in a Cstubs functor. Is the existence of my old dynamic libffi code going to cause issues somehow? That stuff was runnable in utop, meaning it was able to find all of the foreign functions anyway. And the integer view worked in toplevel
<d_bot> <rgrinberg> I think you gotta bring the functors back
<d_bot> <beheddard> ```ocaml
<d_bot> <beheddard> let t = enum "OlmErrorCode" ~typedef:true
<d_bot> <beheddard> ErrorCode.
<d_bot> <beheddard> [ Success , olm_success
<d_bot> <beheddard> ; NotEnoughRandom , olm_not_enough_random
<d_bot> <beheddard> ; OutputBufferTooSmall , olm_output_buffer_too_small
<d_bot> <beheddard> ; BadMessageVersion , olm_bad_message_version
<d_bot> <beheddard> ; BadMessageFormat , olm_bad_message_format
<d_bot> <beheddard> ; BadMessageMac , olm_bad_message_mac
<d_bot> <beheddard> ; BadMessageKeyId , olm_bad_message_key_id
<d_bot> <beheddard> ; InvalidBase64 , olm_invalid_base64
<d_bot> <beheddard> ; BadAccountKey , olm_bad_account_key
<d_bot> <beheddard> ; UnknownPickleVersion , olm_unknown_pickle_version
<d_bot> <beheddard> ; CorruptedPickle , olm_corrupted_pickle
<d_bot> <beheddard> ; BadSessionKey , olm_bad_session_key
<d_bot> <beheddard> ; UnknownMessageIndex , olm_unknown_message_index
<d_bot> <beheddard> ; BadLegacyAccountPickle, olm_bad_legacy_account_pickle
<d_bot> <beheddard> ; BadSignature , olm_bad_signature
<d_bot> <beheddard> ; InputBufferTooSmall , olm_input_buffer_too_small
<d_bot> <beheddard> ; SasTheirKeyNotSet , olm_sas_their_key_not_set
<d_bot> <beheddard> ]
<d_bot> <beheddard> ~unexpected:(fun _ -> assert false)
<d_bot> <beheddard> end
<d_bot> <beheddard> ```
<d_bot> <beheddard> Is this not that part (specifically the "OlmErrorCode" string) which is telling cstubs what type to look for?
<d_bot> <rgrinberg> But you reference your integer view in many places
<d_bot> <beheddard> The functors are in `olm/c/olm_c_type_descriptions.ml`
<d_bot> <rgrinberg> we are blind
<d_bot> <rgrinberg> There:
<d_bot> <rgrinberg> ```
<d_bot> <rgrinberg> diff --git a/olm/c/olm_c_type_descriptions.ml b/olm/c/olm_c_type_descriptions.ml
<d_bot> <rgrinberg> index b9aa7a3..f856eff 100644
<d_bot> <rgrinberg> --- a/olm/c/olm_c_type_descriptions.ml
<d_bot> <rgrinberg> +++ b/olm/c/olm_c_type_descriptions.ml
<d_bot> <rgrinberg> @@ -94,7 +94,7 @@ module Descriptions (F : Cstubs.Types.TYPE) = struct
<d_bot> <rgrinberg> let olm_input_buffer_too_small = constant "OLM_INPUT_BUFFER_TOO_SMALL" int64_t
<d_bot> <rgrinberg> let olm_sas_their_key_not_set = constant "OLM_SAS_THEIR_KEY_NOT_SET" int64_t
<d_bot> <rgrinberg>
<d_bot> <rgrinberg> - let t = enum "OlmErrorCode" ~typedef:true
<d_bot> <rgrinberg> + let t = enum "OlmErrorCode"
<d_bot> <rgrinberg> ErrorCode.
<d_bot> <rgrinberg> [ Success , olm_success
<d_bot> <rgrinberg> ; NotEnoughRandom , olm_not_enough_random
<d_bot> <rgrinberg>
<d_bot> <rgrinberg> ```
<d_bot> <beheddard> my view is in `lib/` which has the old dynamic (non stubs) versions. Cstubs is in `c/`
<d_bot> <beheddard> the `~typedef:true` was the issue
<d_bot> <beheddard> ?
<d_bot> <beheddard> wow
<d_bot> <rgrinberg> Yes. It's not a typedef
mbuf has joined #ocaml
<d_bot> <beheddard> I copied that part from an example of enum usage, damn
<d_bot> <beheddard> I had it on my mental list to actually look that up but forgot.
<d_bot> <beheddard> dumb moment
<d_bot> <beheddard> so my structs should look like so:
<d_bot> <beheddard> ```ocaml
<d_bot> <beheddard> module Aes256Key = struct
<d_bot> <beheddard> type t = [ `Aes256Key ] structure
<d_bot> <beheddard> let t : t typ = structure "_olm_aes256_key"
<d_bot> <beheddard> let key = field t "key" (array aes256_key_length uint8_t)
<d_bot> <beheddard> let () = seal t
<d_bot> <beheddard> end
<d_bot> <beheddard> ```
<d_bot> <beheddard> rather than this:
<d_bot> <beheddard> ```ocaml
<d_bot> <beheddard> module Aes256Key = struct
<d_bot> <beheddard> type t = [ `Aes256Key ] structure
<d_bot> <beheddard> let t : t typ = typedef (structure "`Aes256Key") "_olm_aes256_key"
<d_bot> <beheddard> let key = field t "key" (array aes256_key_length uint8_t)
<d_bot> <beheddard> let () = seal t
<d_bot> <beheddard> end
<d_bot> <beheddard> ```
<d_bot> <beheddard> Since they shouldn't actually be typedefs
<d_bot> <beheddard> Seems to build with the former and not the latter (which is the way most of the structs seem to be in Luv).
<d_bot> <rgrinberg> Glad to hear that you got it working.
<d_bot> <beheddard> definitely some progress, thanks for everything so far again. Seems like many types are making it through now, but the ones that are `typedef`'d in the headers seem to be the sticking point
Haudegen has joined #ocaml
<d_bot> <beheddard> ```
<d_bot> <beheddard> dune build
<d_bot> <beheddard> bash c/generate_types_step_2.exe (exit 1)
<d_bot> <beheddard> (cd _build/default/c && /usr/bin/bash -e -u -o pipefail -c 'gcc -O2 -fno-strict-aliasing -fwrapv -fPIC generate_types_step_2.c -I '\''/home/geoff/.opam/default/lib/ctypes'\'' -I /home/geoff/.opam/default/lib/ocaml -I vendor/libolm/include -o generate_types_step_2.exe')
<d_bot> <beheddard> In file included from /usr/include/stdio.h:33,
<d_bot> <beheddard> from generate_types_step_2.c:9:
<d_bot> <beheddard> generate_types_step_2.c: In function ‘main’:
<d_bot> <beheddard> generate_types_step_2.c:24:16: error: invalid use of undefined type ‘struct OlmSAS’
<d_bot> <beheddard> 24 | offsetof(struct OlmSAS, their_key_set));
<d_bot> <beheddard> | ^~~~~~~~
<d_bot> <beheddard> generate_types_step_2.c:28:16: error: invalid use of undefined type ‘struct OlmSAS’
<d_bot> <beheddard> 28 | offsetof(struct OlmSAS, secret));
<d_bot> <beheddard> | ^~~~~~~~
<d_bot> <beheddard> generate_types_step_2.c:32:16: error: invalid use of undefined type ‘struct OlmSAS’
<d_bot> <beheddard> 32 | offsetof(struct OlmSAS, curve25519_key));
tizoc has quit [Quit: Coyote finally caught me]
<d_bot> <beheddard> | ^~~~~~~~
<d_bot> <beheddard> generate_types_step_2.c:36:16: error: invalid use of undefined type ‘struct OlmSAS’
<d_bot> <beheddard> 36 | offsetof(struct OlmSAS, last_error));
<d_bot> <beheddard> | ^~~~~~~~
<d_bot> <beheddard> generate_types_step_2.c:40:16: error: invalid use of undefined type ‘struct OlmPkSigning’
tizoc has joined #ocaml
<d_bot> <beheddard> 40 | offsetof(struct OlmPkSigning, key_pair));
<d_bot> <beheddard> | ^~~~~~~~
<d_bot> <beheddard> generate_types_step_2.c:44:16: error: invalid use of undefined type ‘struct OlmPkSigning’
<d_bot> <beheddard> 44 | offsetof(struct OlmPkSigning, last_error));
<d_bot> <beheddard> | ^~~~~~~~
<d_bot> <beheddard> generate_types_step_2.c:48:16: error: invalid use of undefined type ‘struct OlmPkDecryption’
<d_bot> <beheddard> 48 | offsetof(struct OlmPkDecryption, key_pair));
<d_bot> <beheddard> ```
<d_bot> <beheddard> continued, for each struct type that had a typedef in the headers it seems
<d_bot> <beheddard> oh actually, maybe it's because the structs are defined in source files rather than the headers
<d_bot> <beheddard> hmm
<d_bot> <beheddard> ```
<d_bot> <beheddard> (rule
<d_bot> <beheddard> (targets generate_types_step_2.exe)
<d_bot> <beheddard> (deps
<d_bot> <beheddard> (:c generate_types_step_2.c)
<d_bot> <beheddard> (source_tree vendor/libolm/include)
<d_bot> <beheddard> (source_tree vendor/libolm/src)
<d_bot> <beheddard> (file vendor/libolm/build/libolm.a))
<d_bot> <beheddard> (action (bash "\
<d_bot> <beheddard> %{cc} %{c} \
<d_bot> <beheddard> -I '%{lib:ctypes:.}' \
<d_bot> <beheddard> -I %{ocaml_where} \
<d_bot> <beheddard> -I vendor/libolm/include \
<d_bot> <beheddard> -I vendor/libolm/src \
<d_bot> <beheddard> -o %{targets}")))
<d_bot> <beheddard> ```
<d_bot> <beheddard> This should be providing the source files needed for the structs that aren't defined in the headers right?
decentpenguin has quit [Quit: ZNC crashed or something]
decentpenguin has joined #ocaml
<d_bot> <beheddard> ```ocaml
<d_bot> <beheddard> print_endline "#include <olm/crypto.h>";
<d_bot> <beheddard> print_endline "#include <olm/error.h>";
<d_bot> <beheddard> print_endline "#include \"inbound_group_session.c\"";
<d_bot> <beheddard> print_endline "#include <olm/inbound_group_session.h>";
<d_bot> <beheddard> print_endline "#include <olm/megolm.h>";
<d_bot> <beheddard> print_endline "#include <olm/olm.h>";
<d_bot> <beheddard> print_endline "#include \"outbound_group_session.c\"";
<d_bot> <beheddard> print_endline "#include <olm/outbound_group_session.h>";
vicfred has quit [Quit: Leaving]
<d_bot> <beheddard> print_endline "#include \"pk.cpp\"";
<d_bot> <beheddard> print_endline "#include <olm/pk.h>";
<d_bot> <beheddard> print_endline "#include \"sas.c\"";
<d_bot> <beheddard> print_endline "#include <olm/sas.h>";
<d_bot> <beheddard> ```
<d_bot> <beheddard> I've included the struct containing source files, and now the types seem to have been found, but now I've got a new issue due to including the source files :mike2:
<d_bot> <beheddard> ```
<d_bot> <beheddard> dune build
<d_bot> <beheddard> bash c/generate_types_step_2.exe (exit 1)
<d_bot> <beheddard> (cd _build/default/c && /usr/bin/bash -e -u -o pipefail -c 'gcc -O2 -fno-strict-aliasing -fwrapv -fPIC generate_types_step_2.c -I '\''/home/geoff/.opam/default/lib/ctypes'\'' -I /home/geoff/.opam/default/lib/ocaml -I vendor/libolm/include -I vendor/libolm/src -o generate_types_step_2.exe')
<d_bot> <beheddard> In file included from generate_types_step_2.c:7:
<d_bot> <beheddard> vendor/libolm/src/outbound_group_session.c:32: warning: "PICKLE_VERSION" redefined
<d_bot> <beheddard> 32 | #define PICKLE_VERSION 1
<d_bot> <beheddard> |
<d_bot> <beheddard> In file included from generate_types_step_2.c:3:
<d_bot> <beheddard> vendor/libolm/src/inbound_group_session.c:33: note: this is the location of the previous definition
<d_bot> <beheddard> 33 | #define PICKLE_VERSION 2
<d_bot> <beheddard> |
<d_bot> <beheddard> In file included from generate_types_step_2.c:7:
<d_bot> <beheddard> vendor/libolm/src/outbound_group_session.c:71:15: error: conflicting types for ‘raw_pickle_length’
<d_bot> <beheddard> 71 | static size_t raw_pickle_length(
<d_bot> <beheddard> | ^~~~~~~~~~~~~~~~~
<d_bot> <beheddard> In file included from generate_types_step_2.c:3:
<d_bot> <beheddard> vendor/libolm/src/inbound_group_session.c:184:15: note: previous definition of ‘raw_pickle_length’ was here
<d_bot> <beheddard> 184 | static size_t raw_pickle_length(
<d_bot> <beheddard> | ^~~~~~~~~~~~~~~~~
<d_bot> <beheddard> In file included from vendor/libolm/src/pk.cpp:18,
<d_bot> <beheddard> from generate_types_step_2.c:9:
<d_bot> <beheddard> vendor/libolm/include/olm/ratchet.hh:16:10: fatal error: cstdint: No such file or directory
<d_bot> <beheddard> 16 | #include <cstdint>
<d_bot> <beheddard> | ^~~~~~~~~
<d_bot> <beheddard> compilation terminated.
<d_bot> <beheddard> Done: 347/350 (jobs: 1)%
<d_bot> <beheddard> ```
raver has joined #ocaml
Anarchos has joined #ocaml
Anarchos has quit [Client Quit]
reynir1 has joined #ocaml
<d_bot> <beheddard> Alright, I make a little helper stub with the struct types from the `pk.cpp` src that was causing the error with `<cstdint>`.
reynir has quit [Disconnected by services]
reynir1 is now known as reynir
<d_bot> <beheddard> I suppose I could throw all of the relevant stucts into one `.c` so I don't have to wholesale include a bunch of src files that I shouldn't be
terrorjack has quit [Quit: Ping timeout (120 seconds)]
terrorjack has joined #ocaml
borne has joined #ocaml
olle has joined #ocaml
borne has quit [Quit: WeeChat 2.9]
borne has joined #ocaml
<d_bot> <beheddard> That's what I did for now, all the types. The generation is running without warnings! Tons of progress today, and starting to understand the ecosystem a bit better. Thanks @rgrinberg
Tuplanolla has joined #ocaml
larou has joined #ocaml
larou has quit [Client Quit]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
bartholin has joined #ocaml
bartholin has quit [Quit: Leaving]
nullcone has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
berberman_ has quit [Ping timeout: 272 seconds]
berberman has joined #ocaml
malc_ has joined #ocaml
<malc_> one aspect of compiler behavior (both byte and native code ones are affected) that is apparently what it is, but makes me engage in workarounds that shouldn't be necessary, and exist, it seems, solely because developers are lazy and doing the right thing has a distant potential to break something. https://repo.or.cz/llpp.git/blob/master:/misc/notes/cmi.txt describes the issue
<octachron> The right thing is to allow to explicit pair ml and cmi files. I am not sure how it would break things?
<malc_> the right thing is to put the .cmi alongside the .cmo and not emit it at all if it's present in the directory -o designates
visage_ has joined #ocaml
mbuf has quit [Ping timeout: 256 seconds]
<octachron> You are not using "-o" in your example.
Haudegen has joined #ocaml
<malc_> octachron: right, my bad, the issue is the second compilation a.cmi was already compiled and exists in d, it is ignored by when compiling .ml (irrespective of -I), please if you will answer add my nick somewhere in the sentence, i will get notified an will respond in a timely manner, thanks
<octachron> malc_, using the included directories to look for associated mlis file does feel brittle and increase the probability of persistent module collisions.
<malc_> octachron: that unfortunately means i have to live with the workaround i have, which is a pity (and thanks...)
dckc has quit [Ping timeout: 272 seconds]
dckc has joined #ocaml
dhil has quit [Ping timeout: 260 seconds]
dhil has joined #ocaml
<vsiles> does anyone is using ocaml on a windows machine by any change ?
<vsiles> change*
<d_bot> <konsolas> i gave up with opam for windows and i'm just using it with WSL
<vsiles> I'm looking for the output of `ocamlc -config` the line about `system`
<vsiles> @konsolas it should still report that the system is windows, shouldn't it ? Ping me if you have the chance to run the command
<d_bot> <konsolas> as far as i know, wsl is just a linux virtual machine
<vsiles> oh.. sad :(
def has quit [Remote host closed the connection]
def has joined #ocaml
hnOsmium0001 has joined #ocaml
kini has quit [Remote host closed the connection]
borne has quit [Ping timeout: 272 seconds]
kini has joined #ocaml
mxns has joined #ocaml
<d_bot> <mnxn> system is mingw64
olle has quit [Ping timeout: 260 seconds]
<vsiles> thank you
vicfred has joined #ocaml
vicfred has quit [Max SendQ exceeded]
vicfred has joined #ocaml
vicfred has quit [Max SendQ exceeded]
vicfred has joined #ocaml
mxns has quit [Ping timeout: 256 seconds]
orbifx has joined #ocaml
dhil has quit [Ping timeout: 260 seconds]
mxns has joined #ocaml
tane has joined #ocaml
dhil has joined #ocaml
borne has joined #ocaml
rwmjones|meeting is now known as rwmjones|hols
Haudegen has quit [Quit: Bin weg.]
neiluj has joined #ocaml
Haudegen has joined #ocaml
neiluj has quit [Changing host]
neiluj has joined #ocaml
nullcone has joined #ocaml
neiluj has quit [Ping timeout: 258 seconds]
neiluj has joined #ocaml
<theblatte> how do you make dune show the source code after ppx have run?
<malc_> octachron: "scriptified" version: https://repo.or.cz/llpp.git/blob/master:/misc/notes/cmi.sh
<Armael> I'm using opium to build a simple webapp (fwiw I'm currently using the released version of opium), including the middleware to serve static content
<Armael> additionally, I'd like to have that accessing foo/bar/ serves foo/bar/index.html for the static content
<Armael> is it something that can be done with the standard middleware for static content? or should I rather copy its code and modify it?
<Armael> (alternatively I could rely on nginx to do that outside of the webapp, but I guess it's a bit simpler configuration-wise if it can be done by the webapp itself)
orbifx has quit [Ping timeout: 260 seconds]
<d_bot> <Anurag> off the top of my head we don't have a conversion from `/ => index.html` in opium. I don't think you'd need to copy the whole middleware to make this change though. You can potentially wrap the static middleware in a middleware of your own, do a "/" to "/index.html" conversion for the paths you care about and then forward that to the static middleware? its not ideal but i think it'll get you results you want.
<d_bot> <Anurag> I'd also suggest opening this as an issue on the repository as this could be something that's done in the upcoming breaking release
reynir1 has joined #ocaml
reynir has quit [Ping timeout: 256 seconds]
reynir has joined #ocaml
reynir1 has quit [Ping timeout: 264 seconds]
<Armael> thanks! both options sound good
berberman_ has joined #ocaml
berberman has quit [Ping timeout: 272 seconds]
neiluj has quit [Ping timeout: 256 seconds]
yomimono has quit [Ping timeout: 265 seconds]
yomimono has joined #ocaml
neiluj has joined #ocaml
<companion_cube> @Anurag: is that with httpaf?
amiloradovsky has joined #ocaml
narimiran has quit [Quit: leaving]
neiluj has quit [Ping timeout: 256 seconds]
<d_bot> <Anurag> companion_cube: the next release will indeed be with httpaf
neiluj has joined #ocaml
<companion_cube> nice
<companion_cube> does it really have to be dependent on the httpd, btw?
<companion_cube> (just curious, not a criticism)
<companion_cube> seliopou has done a ton of work, wow…
djellemah has joined #ocaml
<d_bot> <Anurag> at one point i tried abstracting over cohttp and httpaf, but it felt simpler to just use httpaf and provide a nicer end-user experience with that. If i want to be independent of the http implementation i'd need some sort of lest common denominator adapter between cohttp/httpaf and that started to get a little awkward.
<companion_cube> I suppose httpaf is the future anyway
<Drup> there is no real point abstracting over the http implem if one is clearly better than the other :|
<d_bot> <Anurag> I found it easier to use/understand than cohttp so that was also a motivating factor to just stick with it
<Drup> (also, everyone who worked on functorized cohttp talks about it like if they had gone to war ...)
<companion_cube> 😂
<companion_cube> it's pretty cool that faraday is able to use writev(), for example
<companion_cube> the perfs should be high
<d_bot> <Anurag> I saw someone had an attempt at https://github.com/lyrm/ocaml-httpadapter but i don't think that project is active anymore
borne has quit [Ping timeout: 240 seconds]
<d_bot> <Anurag> With dinosaure's https://github.com/dinosaure/paf-le-chien i can keep using httpaf even if i want to write a mirage unikernel 🙂
<companion_cube> omg, "AF" means "angstrom + faraday" ? 🤯
<d_bot> <Anurag> Took me a while to see that too, haha
<companion_cube> it's in the readme now
<Drup> It is a good excuse, isn't it ?
<companion_cube> clearly
malc_ has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
<hannes> from what I remember, httpaf was started by spiros to have a low-latency http server (when investigating the latency profiles of cohttp, see https://github.com/inhabitedtype/httpaf#performance esp. the long tail, 99 percentile)
<d_bot> <Anurag> i personally don't put a lot of weight in techempower benchmarks, but someone added an httpaf implementation to the techempower benchmark (there is a cohttp version as well), the latency numbers definitely reflect the improvement that httpaf brings.
<d_bot> <Anurag> https://www.techempower.com/benchmarks/#section=test&runid=bf3eceff-da94-46a8-87ab-6fc3ef39c12c&hw=ph&test=db&l=zik0zj-v&a=2
neiluj has quit [Changing host]
neiluj has joined #ocaml
tane has quit [Quit: Leaving]
Serpent7776 has quit [Quit: leaving]
<d_bot> <mbacarella> hmm. what makes cohttp slower? i'm suddenly self-conscious because i have a web service written in cohttp and wonder if i could be saving tens of cpu credits a day
<d_bot> <mbacarella> i guess there's this https://github.com/mirage/ocaml-cohttp/issues/328
<d_bot> <mbacarella> median latency on my modest web service in cohttp is 700micros which doesn't seem crazy
mxns has quit [Ping timeout: 256 seconds]
ewanas has joined #ocaml
aaaaaa has joined #ocaml
<aaaaaa> Hi all. I found there are several possible 'standard' libraries. Dunno what to pick. What would you recommend for starters? Something to start at.
<companion_cube> well, totally biased advice: try containers :p
mxns has joined #ocaml
mxns has quit [Ping timeout: 272 seconds]
<aaaaaa> companion_cube: what is this?
<aaaaaa> companion_cube: 10x for the suggestion
neiluj has quit [Remote host closed the connection]
mxns has joined #ocaml
mxns has quit [Ping timeout: 260 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 240 seconds]
dhil has quit [Ping timeout: 258 seconds]
Tuplanolla has quit [Quit: Leaving.]