<d_bot>
<mbacarella> /var/folders/4q/kn24w2t13rqctm5s3ykgyqv80000gn/T/build996740.dune/camlasm5d3aab.s:481039:16: error: index must be an integer in range [-256, 255].
<d_bot>
<mbacarella> ldr x30, [sp, #45880]
<d_bot>
<mbacarella> ^
<d_bot>
<mbacarella> cool an assembler error 😲
motherfsck has quit [Ping timeout: 276 seconds]
motherfsck has joined #ocaml
motherfsck has quit [Quit: quit]
zebrag has quit [Quit: Konversation terminated!]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
motherfsck has joined #ocaml
Haudegen has joined #ocaml
kurfen has quit [Ping timeout: 256 seconds]
kurfen has joined #ocaml
dwt_ has quit [Ping timeout: 246 seconds]
dwt_ has joined #ocaml
kaph__ has quit [Ping timeout: 240 seconds]
olle has joined #ocaml
kaph has joined #ocaml
average has joined #ocaml
<average>
does/can OCaml offer guarantees like Rust's in terms of memory safety?
<average>
does OCaml have a GC ?
<d_bot>
<NULL> It has a GC
<average>
a-ha, okay. what about them guarantees from Rust?
<average>
(not that they should be available, just wondering if any of them are available in Ocaml)
<olle>
Not needed
<average>
olle: could you please unpack/elaborate that?
<olle>
average: You don't need ownership and lifetime when there's a GC
<olle>
average: All unused memory is automatically collected
<average>
olle: sadly.. GC's can hold onto memory longer than necessary, and while that's not an actual memory leak, it's a phenomenon where memory is being held longer than necessary
<average>
also i'm aware that certain situations require immutable data structures to be copied and modified, so a duplicate is required and that can have some impacts on memory usage. OCaml being FP must be using imutable data structures in some places..
mro has joined #ocaml
<olle>
average: Sure
<olle>
Memory is rarely a problem on modern machines
average has quit [Ping timeout: 240 seconds]
<olle>
But yes, of course a GC lang will eat more memory than a manual memory lang
hsw has joined #ocaml
mro has quit [Remote host closed the connection]
bartholin has joined #ocaml
azimut has quit [Ping timeout: 240 seconds]
azimut has joined #ocaml
epony has joined #ocaml
mro has joined #ocaml
kaph has quit [Read error: Connection reset by peer]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
bartholin has quit [Ping timeout: 246 seconds]
xgqt has quit [Ping timeout: 246 seconds]
xgqt has joined #ocaml
bartholin has joined #ocaml
kaph has joined #ocaml
mro has quit [Remote host closed the connection]
<d_bot>
<leviroth> Ownership is useful for reasons other than memory management, right?
<d_bot>
<leviroth> For example, I have some mutable thing, I want to pass it to a function but ensure that the function doesn’t retain a reference to that thing after the function returns.
<d_bot>
<NULL> Since GC, your thing won't be deallocated if it happens, so you just have potentially annoying behaviour
<d_bot>
<leviroth> I don’t understand the “just” here. It’s bad if my program behaves incorrectly, right?
<olle>
That'd be affine types
<olle>
See the paper "Kindly bent to free <something>"
<d_bot>
<NULL> The program will behave as expected, you just did something that makes it more difficult (or annoying) to understand what it is doing
<d_bot>
<NULL> As opposed to a situation without a GC, where your thing would [potentially] be deallocated and then you would segfault
mro has joined #ocaml
<Corbin>
Ownership semantics are nice, but it's important to remember that objects in memory are inherently copyable. Linear logic works well for RAM because RAM is physical, and chemistry obeys linear logic at that level; RAM banks aren't physically copyable.
* Corbin
remembers downloading more RAM
<d_bot>
<NULL> In Rust, you may want to pass a reference to a function, memory management means you must give intent. In OCaml, memory management doesn't require to give intent, so you don't
<d_bot>
<Bluddy> The added advantage of linear types is that you can treat mutable data structures as if they were immutable. The type system lets you know if you shared a mutable data structure incorrectly.
<d_bot>
<Bluddy> (e.g. passed the same alias to a data structure to two different mutating functions)
<qwr>
imho the memory management is simply tradeoff between static and runtime computational cost, and memory usage - and the tail of correctly determining optimal allocations statically is very high (maybe/probably NP complete problem?)
<Corbin>
Sort of. You can't ensure that all of your invariants hold, if you have a composite data structure built from "immutable" components. You'd need to also somehow enforce a sequence of observations.
<qwr>
many languages (like C) offload this computation to programmer
<d_bot>
<leviroth> I don’t understand. If I expected the function not to retain (and later mutate) its argument after returning, and it does, then the program is not behaving as expected.
<d_bot>
<leviroth> That is, where by “as expected” I mean according to my expectation as the programmer.
<d_bot>
<NULL> You can offload this expectation on the type system if it has ownership, true. But it is less dangerous if it is not met with GC-managed languages since it won't do stuff you didn't ask (deallocate), only stuff you did ask (mutate incorrectly)
<Corbin>
leviroth: Imagine that you have e.g. a packed-array structure, and you're going to mutate it as part of some array algorithm. If you read after writing, then the compiler will order your mutations correctly. But if you only write, then the compiler might batch up your mutations for efficiency, and this is actually something we want from this design.
<qwr>
some non-pure languages allow you to describe such expectations to compiler in function signatures and types
<Corbin>
But now we need for the compiler to correctly batch up *all* mutations when we assemble composite structures. This isn't impossible, but it has to be considered. This is one of the reasons why Haskell puts this sort of effect behind a monad.
<d_bot>
<leviroth> @corbin I’m not sure, but I think you’re misinterpreting my previous message as directed at you (I was replying to @NULL on discord, but you wouldn’t see that via the IRC bridge).
hannes has quit [Ping timeout: 260 seconds]
<Corbin>
Ah, sorry. Yeah, I can't see some of your indicators.
kaph has quit [Read error: Connection reset by peer]
mro has quit [Remote host closed the connection]
hornhack has joined #ocaml
hornhack has quit [Remote host closed the connection]
mro has joined #ocaml
zebrag has joined #ocaml
rgrinberg has joined #ocaml
mro has quit [Remote host closed the connection]
kakadu has quit [Quit: Konversation terminated!]
neilthereildeil has joined #ocaml
neilthereildeil has left #ocaml [#ocaml]
mro has joined #ocaml
shawnw has quit [Ping timeout: 256 seconds]
waleee has joined #ocaml
<d_bot>
<mbacarella> how do see a human representation of a foo.pp.ml file again?
bartholin has quit [Quit: Leaving]
<companion_cube>
I use `ocamlc -dsource foo.pp.ml`
<companion_cube>
possibly wrapped in less
shawnw has joined #ocaml
<d_bot>
<mbacarella> thank you 🙏
<companion_cube>
there's probably a better way
<d_bot>
<rgrinberg> vscode has an ast explorer now
<d_bot>
<rgrinberg> you could try that out
<d_bot>
<Bluddy> dang
<companion_cube>
the EEE continues :p
<d_bot>
<sim642> The VSCode plugin preprocessed and AST viewer is amazing, especially for developing/debugging ppx-s
<companion_cube>
and lo, we replaced emacs with vscode :/
waleee has quit [Ping timeout: 250 seconds]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<rgrinberg> I love your optimism
<d_bot>
<hcarty> EEE = Emacs Eventually Evaporates?
<mjacob>
how can i use some library that was built by dune in one project in another project?
<mjacob>
can i use opam pin to use an already built (by dune) library?
<d_bot>
<crackcomm> you would pin the source code
<d_bot>
<crackcomm> but it may be possible I just haven't tried it
<d_bot>
<crackcomm> but I'm not exactly sure what you mean
Serpent7776 has joined #ocaml
<d_bot>
<KW78> In the source directory the general gist is `opam pin .` , assuming you have a package definition in `dune-project` and then `dune @install`
<d_bot>
<crackcomm> you need to pin the location of dune-project/.opam files
neilthereildeil has joined #ocaml
rgrinberg has joined #ocaml
<d_bot>
<mbacarella> trying to compile a 500kloc .ml file makes the compiler sad
<d_bot>
<mbacarella> it needs an enormous amount of stack space and slows down considerably (on x86-64; on arm64 Mac it throws up that assembly error)
mro has joined #ocaml
<d_bot>
<mbacarella> if I could break this up into smaller modules would it still be possible to include them in the original file and get something with an interface that looks like if I had only the big file, while sidestepping the compiler performance issues?
<d_bot>
<crackcomm> yes you can use `include`
<d_bot>
<mbacarella> my question isn't if `include` exists, it's if that would perform better
<d_bot>
<crackcomm> I see, no idea
<d_bot>
<rgrinberg> it might, but you should first make sure that you can type check the inferred interface
rawley has joined #ocaml
<d_bot>
<mbacarella> are you saying if I have a big module F it might not have the same interface if I split it out and did `module F = struct include F1 include F2 include F3 end` ?
mro has quit [Remote host closed the connection]
<d_bot>
<leviroth> If you have some weakly polymorphic value in a .ml file you can give it a monomorphic type in a .mli file, but if you omit the mli then the compiler will complain.
<d_bot>
<leviroth> Not sure if there are other issues like this that @rgrinberg might have in mind.
<d_bot>
<rgrinberg> I meant that if it's the typechecker that's overflowing on your massive module signature, I don't think splitting the modules will help
<d_bot>
<rgrinberg> At least I'm not certain it will
<d_bot>
<leviroth> Ah
<d_bot>
<mbacarella> oh
<d_bot>
<octachron> It is unlikely that it is the typechecker that is overflowing outside of over-sized litterals and not human-amenable types.
<d_bot>
<octachron> You might also want to compile your generated module with `-linscan` to remove register allocation from the list of concerns.
mro has joined #ocaml
average has quit [Ping timeout: 260 seconds]
<mjacob>
crackcomm: "opam pin add src" doesn't offer "kimchi_backend". how is it determined which packages can be pinned?
<d_bot>
<crackcomm> I can't really help, I don't use opam anymore instead I use esy
waleee has joined #ocaml
neilthereildeil has quit [Quit: Client closed]
neilthereildeil has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mbuf has quit [Quit: Leaving]
ahmed has quit [Ping timeout: 240 seconds]
nerdypepper has quit [Ping timeout: 256 seconds]
nerdypepper has joined #ocaml
Tuplanolla has joined #ocaml
neilthereildeil has quit [Quit: Client closed]
average has joined #ocaml
average has joined #ocaml
average has quit [Changing host]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gravicappa has quit [Ping timeout: 246 seconds]
mro has quit [Ping timeout: 260 seconds]
Anarchos has joined #ocaml
<average>
is there any guide written about diagnosing memory-related problems in Ocaml "?
<average>
or about profiling Ocaml programs
<average>
(memory or speed profiling)
olle has quit [Ping timeout: 246 seconds]
<d_bot>
<mbacarella> -linscan helps but is not a complete solution
<d_bot>
<mbacarella> assuming this solves the performance issue, the downside to splitting the big .ml file up into f1.ml, f2.ml, f3.ml and f4.ml and then doing `module F = struct include F1 include F2 include F3 end` is that types in `F3` will now say they depend on `F1.bar` instead of just `bar`?
mbacarella has joined #ocaml
spip has joined #ocaml
<d_bot>
<geoff> From the perspective of the consumer of F the types won't be qualified by the submodules. You could open the former submodules in the later ones so that you don't have to change references to bar
<d_bot>
<mbacarella> oh, nice
olle has joined #ocaml
rgrinberg has joined #ocaml
kaph has joined #ocaml
Serpent7776 has quit [Remote host closed the connection]
rawley has quit [Remote host closed the connection]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
olle has quit [Ping timeout: 246 seconds]
kaph has quit [Read error: Connection reset by peer]
kaph has joined #ocaml
mbacarella has quit [Quit: Client closed]
waleee has quit [Ping timeout: 240 seconds]
waleee has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tuplanolla has quit [Quit: Leaving.]
hannes has joined #ocaml
<d_bot>
<mbacarella> ok that worked pretty well. without touching the .mli file, i split the 500kloc f.ml file into f1.ml ... f8.ml and included them in f.ml. additionally, f2.ml opens F1 at the top of it, and f8.ml opens F1 through F7 at the top. they're each now about 62kloc
<d_bot>
<mbacarella> compilation time reduced by about 40%, and i was able to reduce ulimit -s from 50000 to 16384
<d_bot>
<mbacarella> oddly, it seems overall cpu utilization went up, but wall clock time went down
<d_bot>
<mbacarella> it also stopped causing that weird assembler error on arm64
<d_bot>
<hcarty> Are you building with dune? If the dependencies between your split files allow it, you might be getting some benefits from multiple files building in parallel