pi3ce has quit [Quit: No Ping reply in 180 seconds.]
pi3ce has joined #ocaml
patrick_ is now known as patrick
reynir has joined #ocaml
reynir has quit [Client Quit]
reynir has joined #ocaml
bartholin has quit [Quit: Leaving]
reynir has quit [Read error: Connection reset by peer]
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #ocaml
pi3ce has quit [Quit: No Ping reply in 180 seconds.]
pi3ce has joined #ocaml
Serpent7776 has joined #ocaml
waleee has joined #ocaml
toastal has joined #ocaml
pi3ce has quit [Quit: No Ping reply in 180 seconds.]
pi3ce has joined #ocaml
xam has quit [Quit: WeeChat 4.3.1]
dev2 has joined #ocaml
dev2 has quit [Client Quit]
dev2 has joined #ocaml
dev2 is now known as xam
berberman has quit [Read error: Connection reset by peer]
berberman_ has joined #ocaml
luc4 has joined #ocaml
xam has quit [Quit: WeeChat 4.3.1]
dev2 has joined #ocaml
dev2 has quit [Client Quit]
dev2 has joined #ocaml
dev2 is now known as xam
xam has quit [Quit: WeeChat 4.3.1]
dev2 has joined #ocaml
dev2 is now known as xam
<luc4>
Hello! When code is compiled with string immutability, is it allowed to modify the string in C code? Or C code should also respect the immutability rule?
xam has quit [Client Quit]
dev2 has joined #ocaml
<discocaml>
<.armael.> C code should also follow the rule
dev2 is now known as xam
<discocaml>
<.armael.> (I’m don’t know whether the compiler currently leverages immutability of strings to enable optimisations, but it could and it might)
xam is now known as xam_
<discocaml>
<.armael.> One safe pattern is if you create the string in C, mutate it, and then expose it to the ocaml compiler as a string
<luc4>
.armael. that is a real problem when porting code, cause no compiler error is generated... thanks though!
<discocaml>
<.armael.> But afaiu as soon as the compiler has seen a value to be an immutable string it is in right to assume that its contents won’t change
<luc4>
.armael. unfortuantely, my problem is a bit different. I'm porting code, and it is difficult to find all the places where this was done.
pi3ce has quit [Quit: No Ping reply in 180 seconds.]
<discocaml>
<.armael.> Porting C code that uses the ocaml FFI? Yeah you’ll get very little help from the compiler to unforce safe ffi patterns, unfortunately
<discocaml>
<otini_> It probably already allows itself to share accesses into the same string. If the string is modified by a C call between two character reads, the code may behave as if the mutation never happened. Since strings tend to be shared a lot, mutating a string may affect unrelated parts of the code. That’s off the top of my head
<discocaml>
<otini_> @luc4 searching for all occurrences of `String_val` in the C code?
<luc4>
Porting code to string immutability is really difficult. I doubt I'll succeed.
pi3ce has joined #ocaml
<luc4>
Yes, I'll guess I'll have to do that.
<luc4>
I should probably find all those and replace with bytes.
<luc4>
In principle, my understanding is that it would be convenient to always translate code using string to bytes.
<discocaml>
<otini_> one thing is that now `String_val(v)` is of type `const char *`
<discocaml>
<otini_> so compiling with all the warnings, that should point to most places where strings are mutated
<luc4>
otini_ oh, this is useful, thanks
<luc4>
I do not probably have all warnings enabled then
<discocaml>
<otini_> the C code should also be compiled via ocaml/ocamlopt to make sure the right version of the headers is used
<discocaml>
<otini_> `ocamlopt -ccopt <additional C flags> -cclib <additional link flags> file.c`
<discocaml>
<otini_> Dune does that by default (the C flags can be configured in the dune file)
<luc4>
I do not think this project is using dune, I only see a makefile.
<discocaml>
<otini_> of course you should also checked that string values are directly considered to be bytes (`Bytes_val`) by the C code
<luc4>
Yes, I checked that. I saw that no error was generated.
<discocaml>
<otini_> ok, well using ocamlc or ocamlopt instead of gcc/clang/.... is the highly recommended way
<discocaml>
<otini_> are not* considered to be bytes, sorry
<luc4>
It seems it is using CXX to build C files unfortunately.
<discocaml>
<otini_> how about CXX = ocamlopt
<discocaml>
<otini_> haha
<luc4>
otini_ arguments are identical?
<luc4>
but is it an error to keep using gcc?
<discocaml>
<otini_> not quite
<discocaml>
<otini_> CFLAGS = $(prefix every cflag with -ccopt I don't know the makefile rule)
<discocaml>
<otini_> not an error no
<luc4>
Then I may leave it like this for the moment. I'm trying to focus on what is 100% wrong.
<luc4>
So far it seems to be working, but god knows what I broke in more than 2000 lines changed in my first ocaml experience.
<discocaml>
<otini_> as long you use the headers from `$(ocamlc -where)/caml` you should be okay
<luc4>
I also introduced a considerable amount of to_string and of_string, I'll have to work more to reduce those.
<discocaml>
<otini_> those are safe (they make a copy)
<luc4>
yes, but too unreasonable
<discocaml>
<otini_> possibly
<luc4>
I see I can reduce by using unsafe functions, but it is risky
<discocaml>
<otini_> yes, very
<luc4>
At least when passing bytes to a printf should be safe though.
<luc4>
Ah yes, I have the warnings now :-)
<luc4>
Thanks!
<discocaml>
<otini_> np
<discocaml>
<otini_> it depends what you call safe. Printing a `Bytes.t` that is mutated concurrently by another thread is a data race that can crash the program on some machines
<discocaml>
<otini_> you can print bytes directly with Format
<luc4>
I found a different syntax, but I couldn't make it work properly. I'll try this as well, thanks!
<luc4>
Is that something recent?
<discocaml>
<otini_> fairly, it was introduced in 4.13
<luc4>
ouch... I'm on 4.11.
<discocaml>
<otini_> Do you have any reason not to use a more recent version?
<luc4>
I would like to port to the most recent version, but it is difficult already. I'm doing it in steps.
<luc4>
I could leave it like this for the moment.
<discocaml>
<otini_> we do try to be backward-compatible. Deprecating mutable strings was one of the big exceptions.
<discocaml>
<otini_> but sure, step by step works too
<luc4>
I guess that killed many applications.
<discocaml>
<otini_> I’m not sure, I wasn’t really working on ocaml at the time
<luc4>
lprintf "IN CIPHER: [%s]\n" (Bytes.to_string (Bytes.escaped s));
<luc4>
I suspect I could safely use unsafe here.
<luc4>
No threading issue in something like this.
<discocaml>
<otini_> but in principle, for every C primitive `f` that you have in your ocaml code that takes a string, you could pass it a bytes instead, making a copy: `f (Bytes.of_string)`, and similarly consider that functions that used to return strings now return bytes
<discocaml>
<otini_> and that should be enough to ensure safety
<discocaml>
<otini_> and improve the performance, if needed, from there
<luc4>
I see, thanks.
<discocaml>
<otini_> > I suspect I could safely use unsafe here.
<discocaml>
<otini_> I don’t see it going horribly wrong in that particular case
<luc4>
Thanks for your help!
<discocaml>
<otini_> np
luc4 has quit [Quit: Konversation terminated!]
luc4 has joined #ocaml
steenuil_ has joined #ocaml
steenuil has quit [Ping timeout: 260 seconds]
steenuil_ is now known as steenuil
luc4 has quit [Quit: Konversation terminated!]
luc4 has joined #ocaml
toastal has quit [Ping timeout: 260 seconds]
GreaseMonkey has quit [Remote host closed the connection]
greaser|q has joined #ocaml
jabuxas has joined #ocaml
bartholin has joined #ocaml
jabuxas has quit [Ping timeout: 268 seconds]
jabuxas has joined #ocaml
pi3ce has quit [Quit: No Ping reply in 180 seconds.]
pi3ce has joined #ocaml
waleee has quit [Ping timeout: 256 seconds]
jabuxas has quit [Ping timeout: 260 seconds]
Tuplanolla has joined #ocaml
<discocaml>
<lukstafi> Is there an integration around of Sherlocode and/or Sherlodoc with VS Code? (through the OCaml Platform or maybe someone has it separately) Asking mostly because I forget to use it.
<discocaml>
<otini_> Don’t think so as it’s not mentioned in the readme https://github.com/art-w/sherlodoc, but @emiletrotignon or @artwendling are best placed to answer
jabuxas has joined #ocaml
jabuxas has quit [Quit: oops :p]
wingsorc has quit [Quit: Leaving]
waleee has joined #ocaml
gweithio has joined #ocaml
<gweithio>
ls
<companion_cube>
pwd
<gweithio>
cd
<gweithio>
lmao, was in the wrong tmux pane when I did the ls :P
<companion_cube>
exit 1
<discocaml>
<emiletrotignon> No there isnt, and I am not sure it would make sense, because the doc is not displayed inside vscode, and sherlodoc is a search engine for the doc, not for the typed source code. I believe there was a type-based search thing in merlin at one point.