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
<d_bot> <glennsl> by "seniors", do they mean the geriatric kind?
olle has quit [Ping timeout: 272 seconds]
<qwr> olle: probably you can also write some parts in Rust for speed and some in OCaml, the interfacing isn't pretty, but since Rust don't need much runtime, it should be possible... and if you can tolerate nim's bugs/weirdness, it should also be fast
<qwr> but I'm not sure what you're actually doing - probably it would be also good idea to test languages for what your code does and decide then?
<qwr> OCaml might actually be fast enough despite not using stack allocations
olle has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
zebrag has quit [Quit: Konversation terminated!]
SrPx has quit [Ping timeout: 268 seconds]
Haudegen has quit [Ping timeout: 256 seconds]
zebrag has joined #ocaml
SrPx has joined #ocaml
troydm has quit [Ping timeout: 268 seconds]
olle has quit [Ping timeout: 246 seconds]
olle has joined #ocaml
troydm has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
mfp has quit [Ping timeout: 256 seconds]
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
aquijoule_ has joined #ocaml
glass has joined #ocaml
theglass has quit [Remote host closed the connection]
richbridger has quit [Ping timeout: 240 seconds]
zebrag has quit [Read error: Connection reset by peer]
zebrag has joined #ocaml
companion_cube has quit [Ping timeout: 260 seconds]
companion_cube has joined #ocaml
mfp has joined #ocaml
mfp has quit [Ping timeout: 256 seconds]
andreas303 has quit [Remote host closed the connection]
andreas303 has joined #ocaml
<d_bot> <theangryepicbanana> olle: I'd say Rust (safe) or Objective-C (high-level)
<d_bot> <theangryepicbanana> (well, assuming you know how to set up objc w/ Foundation libs)
djellemah has quit [Ping timeout: 260 seconds]
_whitelogger has joined #ocaml
iridesce has joined #ocaml
<iridesce> so I have `type t = {direction: whatever}` in snake.ml and `type t = { mutable snake : Snake.t }` in game.ml. now in game.ml, i'm trying to do something like `t.snake <- {t.snake with direction = blah}` but it's telling me that direction is an unbound record field
<iridesce> why is this the case?
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
<sleepydog> iridesce: likely because `direction` is unqualified. if the record field is in another module you must qualify it with the module name.
<sleepydog> e.g. `t.snake <- {t.snake with Snake.direction = blah}`
<iridesce> i tried that, still getting "unbound record field Snake.direction"
<iridesce> even with annotations it's not recognizing it: `let (t:Snake.t) = {t.snake with Snake.direction=North}`
<iridesce> strangely it works if i get rid of the .mli file, but doesn't with the .mli
<iridesce> i'm confused why this would be the case
<d_bot> <Splingush> Is your type opaque?
<sleepydog> can you share the mli entry for `Snake.t` ?
<iridesce> snake.mli
<sleepydog> t is an abstract type there
<sleepydog> you cannot access any of its record fields or make any other assertions about it from outside of the Snake module
<sleepydog> it looks like they intend for you to do `t.snake <- Snake.set_direction t.snake North`
<iridesce> i see, what's the reason for having a .mli file?
<iridesce> when i remove the .mli the code still works fine
<sleepydog> imagine you didn't want other parts of the code to know Snake.t was a record, because you might want to change it in the future
<iridesce> oh i see
<sleepydog> or imagine you wanted to make sure that a snake cannot turn 180 degrees. you could enforce that in a function, but if other code could just access the record field, it can bypass your function
iridesce has quit [Remote host closed the connection]
iridesce has joined #ocaml
zebrag has quit [Ping timeout: 260 seconds]
iridesce has quit [Remote host closed the connection]
_whitelogger has joined #ocaml
sleepydog has quit [Remote host closed the connection]
ansiwen has quit [Quit: ZNC 1.7.1 - https://znc.in]
ansiwen has joined #ocaml
sleepydog has joined #ocaml
jlr has joined #ocaml
waleee-cl has quit [Quit: Connection closed for inactivity]
mbuf has joined #ocaml
narimiran has joined #ocaml
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #ocaml
ldbeth has joined #ocaml
<ldbeth> it seems marshaling from array of assoc lists is much slower than hashtbl
nicoo has quit [Ping timeout: 240 seconds]
nicoo has joined #ocaml
shawnw has joined #ocaml
ldbeth has quit [Remote host closed the connection]
mbuf has quit [Ping timeout: 265 seconds]
bartholin has joined #ocaml
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
Tuplanolla has joined #ocaml
mro_name has joined #ocaml
jlr has quit [Ping timeout: 264 seconds]
dhil has joined #ocaml
jlr has joined #ocaml
olle_ has joined #ocaml
ArthurStrong has joined #ocaml
beaky has quit [Read error: Connection reset by peer]
beaky has joined #ocaml
mfp has joined #ocaml
beaky has quit [Read error: Connection reset by peer]
beaky has joined #ocaml
Haudegen has joined #ocaml
so has quit [Ping timeout: 264 seconds]
beaky has quit [Read error: Connection reset by peer]
so has joined #ocaml
beaky has joined #ocaml
plant_enjoyer has joined #ocaml
plant_enjoyer has quit [Quit: Leaving]
nullcone has quit [Quit: Connection closed for inactivity]
Haudegen has quit [Quit: Bin weg.]
Haudegen has joined #ocaml
mro_name has quit [Remote host closed the connection]
hoel has joined #ocaml
zolk3ri has quit [Remote host closed the connection]
hoel has quit [Quit: leaving]
raver has quit [Quit: Gateway shutdown]
raver has joined #ocaml
raver has quit [Client Quit]
tane has joined #ocaml
drewolson has quit [Quit: The Lounge - https://thelounge.chat]
drewolson has joined #ocaml
djellemah has joined #ocaml
mro_name has joined #ocaml
dhil has quit [Ping timeout: 264 seconds]
dhil has joined #ocaml
shawnw has quit [Ping timeout: 265 seconds]
mxns has joined #ocaml
<companion_cube> the hashtable buckets might be a bit more compact
zebrag has joined #ocaml
seliopou has quit [Ping timeout: 240 seconds]
seliopou has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
sleepydog has quit [Ping timeout: 246 seconds]
waleee-cl has joined #ocaml
olle_ has quit [Ping timeout: 265 seconds]
<d_bot> <stab> Does anybody know how to mix async code with atdgen? basically i have an async Reader.t and I want to parse atd json off of it and have a callback run on each message. The candidate functions i have are:
<d_bot> <stab> ```
<d_bot> <stab> val read_ghidra_messages :
<d_bot> <stab> Yojson.Safe.lexer_state -> Lexing.lexbuf -> ghidra_messages
<d_bot> <stab> (** Input JSON data of type {!ghidra_messages}. *)
<d_bot> <stab>
<d_bot> <stab> val ghidra_messages_of_string :
<d_bot> <stab> string -> ghidra_messages
<d_bot> <stab> (** Deserialize JSON data of type {!ghidra_messages}. *)
<d_bot> <stab> ```
<d_bot> <stab>
<d_bot> <stab> I'm guessing it might be easier to just use of_string instead of somehow trying to wrap the reader into a lexbuf since i dont see how lexing is going to play nicely with Async. That still leaves the issue of splitting off each string as the json object finishes
<companion_cube> stab: is there only one json in the buffer?
<d_bot> <stab> the client will send multiple messages but they'll all be of the same type if that makes sense?
<companion_cube> yeah but json doesn't give you good framing
<companion_cube> if you can, add some basic framing yourself
hnOsmium0001 has joined #ocaml
<companion_cube> (e.g. one line with the number of bytes of the next json message, then the json itself)
<d_bot> <stab> I mean isnt just framed by the object terminating? like if you streaming parse it
<companion_cube> this way you can do the IO in async, and the parsing on a string
<companion_cube> yeah but that's very annoying to do
<companion_cube> maybe with jsonm…
<d_bot> <stab> go it ok was just wondering. im doing the streaming parsing thing on the rust side which is the client
<d_bot> <stab> im just way more familiar with async in rust and how to do things
<d_bot> <stab> I can add framing tho since i control everything
<companion_cube> yeah, it's simpler imho
<companion_cube> the day you need to introduce js or some other language, it'll simplify your life
<companion_cube> having a fully async json parser is not thatr common
<d_bot> <stab> yeah idk tokio is honestly really good for this type of thing in rust and im very used to doing networking stuff in Rust. Pretty much no experience in Ocaml
zebrag has quit [Quit: Konversation terminated!]
<companion_cube> I imagine you use serde
<companion_cube> does serde play nice with async?
zebrag has joined #ocaml
<d_bot> <stab> yeah t hat'
<d_bot> <stab> *yeah that's one good option
<d_bot> <stab> tokio exposes serde json stuff
<companion_cube> huuu ok
<companion_cube> good to know
<d_bot> <holmdunc> Maybe this is too simplistic, but there's a very natural way to frame JSON values: https://en.wikipedia.org/wiki/JSON_streaming#Line-delimited_JSON
<d_bot> <stab> @companion_cube it's also nice because you can use say nom to create a parser then wrap it in a codec. You then apply the codec to the async stream and boom insta custom streaming parsing
<d_bot> <stab> hmm yeah line delimiting might work
<companion_cube> yeah but it's a bit brittle
<companion_cube> it requires the json to be compact
<companion_cube> I think `<n bytes>\n<the json` is the simplest
<companion_cube> it's one `read_line` and one `read_exact`
<d_bot> <stab> yeah the only thing annoying about n bytes is it's brittle to client representation of integers so just have to you know worry about endianness all that good stuff
<d_bot> <stab> It would be nice if Ocaml Async had an implementation of codecs honestly
<d_bot> <stab> cause im pretty sure i could then wrap this stream pretty easily in a normal json parser
<companion_cube> oh I meant in ascii
<companion_cube> (possibly in hexa)
<companion_cube> like http does, for example
<companion_cube> or jsonrpc (which must tackle this exact problem of transmitting a bunch of json objects on a stream)
<d_bot> <stab> oh hmm that feels weird to me but yeah i guess that could work
<companion_cube> LSP (which uses jsonrpc) uses http-like headers
<companion_cube> so for each json message, it's preceded with `content-length: 1234\r\n\r\n<the json>`
mro_name has quit [Read error: Connection reset by peer]
mro_name has joined #ocaml
<d_bot> <stab> yeah that makes sense i guess it's not a big deal since everything is plaintext anyways
<d_bot> <stab> i considered using capnproto for this but i enjoyed atdgens flexible specification format
<companion_cube> protobuf is probably better supported on both ends
<companion_cube> (not that it's better than capnproto, it's just more comon)
<companion_cube> common*
<d_bot> <stab> tru although protobufs just bring up the same framing issue lol
<companion_cube> ahah true
<d_bot> <stab> capnproto does default framing i think
<d_bot> <Anurag> I haven't looked at yojson in a while, but using jsonm + async should be doable without a lot of work. You could rely on async readers' `read_one_chunk_at_a_time` to get a view into the buffer and feed that slice to jsonm.
<d_bot> <stab> hmm i can look at it, just implemented the framing stuff described above and it does the thing
<d_bot> <Anurag> Something like <https://github.com/inhabitedtype/jsonaf> might be even easier to integrate since you could then use the async wrapper for angstrom. But this library isn't published on opam and I haven't used it personally.
<companion_cube> Anurage: but then atdgen doesn't support jsonm, afaik
<companion_cube> that's kind of the problem
<companion_cube> if (when) OCaml had proper fibers we wouldn't have this colored function problem
<d_bot> <Anurag> companion_cube: it doesn't indeed. I like jsonm's api but yojson seems to be the more popular choice in the ecosystem
<d_bot> <stab> well i mean that's not a super big deal tho no? cause i could just parse the json off then ship it to of_string
<d_bot> <d4hines> Is there a way for me to detect at runtime whether I'm running `byte` or `native` mode?
<companion_cube> in Sys, d4hines
<companion_cube> Sys.backend_type
<d_bot> <stab> now i just need to completely modify Infer's internals 😛
<theblatte> stab: what are you doing in/to infer? :)
<d_bot> <stab> I’m writing a “Frontend” that calculates function summaries and warnings for ghidra decompiler output incrementally. The idea being you have a ghidra plugin and you can just run the infer server which will reanalyze functions and their dependents as the reverse engineer improves the decompilation output
<d_bot> <stab> It’s substantially more involved than just a frontend tho unfortunately since infer isn’t really built to reanalyze at a per function level since it’s source file change oriented
<d_bot> <stab> It’s also a bit of a pain since ghidra decompilation isn’t actually compilable and has some syntax differences to C so I have to have a bit more tolerance for unknown types or undefined functions
mro_name has quit [Quit: Leaving...]
<d_bot> <stab> That’s why im putting Frontend in quotes lol since it requires reworking backend logic as well lol... I initially thot it could just be a Frontend
<def> stab: are you familiar with ghidra? I was surprised by the representation of stack frames of their decompiler output
<def> they try to guess local variables, sometime making mistake.
<d_bot> <stab> Yeah I’m pretty familiar I’ve done a fair bit of ghidra development in the past.
<def> while generating an anonymous struct that mirror the shape of the stack frame would be a much more conservative translation but as readable.
<theblatte> stab: wow! infer has an "incremental" mode that's indeed per-file but the code should be able to handle per-procedure incrementality. Check out how Config.incremental is handled in InferAnalyze.ml (you should be able to use CallGraph.flag_reachable from a set of procnames you want to invalidate)
<theblatte> some backend analyses are more sensitive to unknown types/functions than others :) eg biabduction is fussy about knowing struct fields in advance but its replacement pulse isn't, just fyi
<def> theblatte: what are the differences between biabduction and pulse? (is it documented somewhere?)
<d_bot> <stab> Thanks I’ll definitely take a look! It gets a little weird re storage tho because there are no source files but Infer IR has the concept of a iCFG which is oriented to a source file
<d_bot> <stab> I guess you could have a per binary “source” file or something tbd
<theblatte> yeah you'll have to fake a source file
<d_bot> <stab> Re stack decompilation, I think the idea is to try to lift back as close to original c source as possible and so then the engineer can edit vars as needed as independent objects
<theblatte> def: pulse is poised to replace biabduction eventually (hopefully this year :) ). It's the new and improved version ;) it starts from under-approximating foundations instead of over-approximating ones, i.e. it looks for bugs directly instead of trying to prove programs have no bugs then classifying proof failures
<d_bot> <stab> Yeah TypeEnvs also become a disaster with partial information
<def> theblatte: thanks. looking forward to it :)
<theblatte> def: there are some words about Pulse in Section 5 of https://www.soundandcomplete.org/papers/CAV2020/ISL-CAV-2020.pdf
<def> stab: If I had an infinite amount of time, I would at least add an option to generate this fine C stackk representation (at least when the decompiler had to approximate stuff because parts of the stack frame is aliased)
<def> fine-grained*
<theblatte> stab: ugh, yeah I see... pulse pretty much ignores the tenv for now but many analyses assume the tenv exists and makes sense :)
<def> theblatte: thank you
<d_bot> <stab> I’ll definitely take a look at that pulse paper as well. Pretty interesting stuff, been a while since I’ve read the biabduction paper as well. Wish I was better/ more familiar with the logical reasoning stuff. Much more familiar with like bog standard numeric abstract interpretation etc
<d_bot> <stab> The dream here is to be able to use Infer as my base platform for developing static analysis targeting binaries. If this works then I can just deploy another checker and magically get fast and incremental results over the decompilation output
<theblatte> stab: why is the incremental aspect so important?
<d_bot> <stab> Because decompilation output changes as the reverse engineer adds new types etc
<theblatte> ah ok there are manual steps in between
<d_bot> <stab> The idea is to create a feedback loop where the engineer is looking at function summaries and results. Editing and adding stuff where it goes wrong
<d_bot> <stab> Then automatically and quickly propagating the changes
<theblatte> sounds extremely cool!
<d_bot> <stab> I’m pretty excited about it yeah. Haven’t figured out how to stage interdependent analyses yet...
<d_bot> <stab> That’s a very tbd thing
dhil has quit [Quit: Leaving]
ArthurStrong has quit [Quit: leaving]
nullcone has joined #ocaml
mxns has quit [Ping timeout: 272 seconds]
mbuf has joined #ocaml
<mbuf> Is there a way to override and set the %{workspace_root} variable when executing dune?
iZsh has quit [Quit: ZNC - http://znc.in]
mxns has joined #ocaml
mxns has quit [Ping timeout: 268 seconds]
andreas303 has quit [Remote host closed the connection]
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
andreas303 has joined #ocaml
mxns has joined #ocaml
oriba has joined #ocaml
mxns has quit [Ping timeout: 272 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 246 seconds]
hoel has joined #ocaml
iZsh has joined #ocaml
mxns has joined #ocaml
mxns has quit [Ping timeout: 268 seconds]
mxns has joined #ocaml
freshmaker666 is now known as greeb
iZsh has quit [Quit: ZNC - http://znc.in]
iZsh has joined #ocaml
<oriba> is it possible to define certain strings as constants in (sum-)types?
<oriba> what I want is: string-patterns in pattern matches fixed by and controlled by types.
<d_bot> <craigfe> oriba, it is not
mbuf has quit [Quit: Leaving]
<d_bot> <craigfe> what you can do: expose a `type t = private string` with pseudo constructors that check that the string is valid
<d_bot> <craigfe> what this will get you: string pattern matching on variables of this type
<d_bot> <craigfe> what this will not get you: exhaustive checking that reflects the invariants respected by the constructors
<oriba> hmhh ok.
jnavila has joined #ocaml
<d_bot> <Christophe> Do you really need your values to stay strings though? Can't you convert them to variants?
<oriba> I had in mind, that a while ago, there was syntax enhanced, so that constants could be inlined in type definitions. I did not explored that feature so far, so maybe it's just meaning something else, not string constants.
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
terrorjack has quit [Ping timeout: 268 seconds]
terrorjack has joined #ocaml
smazga has joined #ocaml
Mehdi[m] has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
narimiran has quit [Ping timeout: 260 seconds]
olle_ has joined #ocaml
oriba has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
jnavila has quit [Quit: Konversation terminated!]
hoel has quit [Quit: leaving]
Jesin has joined #ocaml
zgasma has joined #ocaml
smazga has quit [Ping timeout: 264 seconds]
olle_ has quit [Ping timeout: 246 seconds]
sleepydog has joined #ocaml
jlr has quit [Ping timeout: 260 seconds]
Tuplanolla has quit [Quit: Leaving.]
mxns has quit [Ping timeout: 240 seconds]
mxns has joined #ocaml
tane has quit [Quit: Leaving]
mxns has quit [Ping timeout: 260 seconds]
cantstanya has quit [Ping timeout: 240 seconds]
cantstanya has joined #ocaml
mxns has joined #ocaml
mxns has quit [Ping timeout: 260 seconds]
bartholin has quit [Remote host closed the connection]
mxns has joined #ocaml
mxns has quit [Ping timeout: 264 seconds]
mxns has joined #ocaml
jmiven has quit [Quit: reboot]
mxns has quit [Ping timeout: 264 seconds]
mxns has joined #ocaml