<brettgilio>
Anybody have thoughts on dune and opam being merged together as a single tool? (toolchain switcher, package manager, build tool).
<brettgilio>
some people have suggested it before, suggesting the Rust cargo solution is simpler
<brettgilio>
and that opam and dune basically overlap in many places
<brettgilio>
not overlap in function, but rather integrate really well
<rgrinberg>
lots of people thought about it, but few have done the homework to understand what it would require
<brettgilio>
I'm sure it would be a large task
<brettgilio>
I have also seen people suggest that dune wrap opam somehow
<rgrinberg>
that would be quite difficult and likely very leaky
<brettgilio>
The biggest reason I've seen for merging the two projects is that there are times where they are unsure of whether to look in the opam or dune docs for particular functionality
<brettgilio>
because there are times where dune is touching opam
<brettgilio>
I think the partitioning between the two projects is mostly clear
<brettgilio>
but I can see some validity in this
<rgrinberg>
I'd like to see some ideas on how to improve this
<brettgilio>
rgrinberg "this" being what exactly?
<brettgilio>
Just unclear on which part you mean
<rgrinberg>
Well, deeper integration between opam and dune
<companion_cube>
brettgilio: I'd love for dune to replace opam :p
<rgrinberg>
Or better package management support in dune itself
<companion_cube>
just imitate cargo ✔
<companion_cube>
(yes, it's a thoughtless one liner)
<brettgilio>
companion_cube do you think, in this hypothetical scenario, that dune should also manage toolchain switches?
<companion_cube>
like a merge of cargo and rustup? idk, it could — it already does with the multi-compiler env feature
<brettgilio>
that is something rustup manages. But I think in the ocaml environment, a totally contained single tool would be the ideal route
<rgrinberg>
nope, i think the concept of a switch is burdensome and unnecessary
<brettgilio>
rgrinberg I agree, but I often take for granted that it exists
<companion_cube>
that's an interesting question
<companion_cube>
if dune managed a lockfile from the dune-project file
<companion_cube>
you could imagine that the lock file could contain multiple sections — one per compiler "switch" (version + options)
<brettgilio>
like I know there is `cargo +1.41.0 run` kind of stuff
<brettgilio>
specifying a toolchain
<companion_cube>
so you could run several compilers on your project, all from one single dune-project file :)
<brettgilio>
I basically have a lot of opinions and absolutely no useful or practical insight on actually making a dent in these directions :)
<rgrinberg>
right. to move ahead in that direction, we just need dune to know how to build the compiler
<brettgilio>
I would really like to stop having to run `eval $(opam env)`
<rgrinberg>
me too
<brettgilio>
companion_cube I think getting dune to manage multiple versions of the compiler on a project would probably be the least complex part of this integration
<brettgilio>
everything else opam handles would be the trouble
<rgrinberg>
well dune already supports multi context builds, so that's no problem
<brettgilio>
Right
<rgrinberg>
the problem is getting the compiler for a project (in a timely manner)
<brettgilio>
my thoughts exactly
<brettgilio>
going back to rust, something else rustup also handles is specific tooling components: rls (or ocaml-lsp-server / merlin). Would dune also be responsible for providing tooling?
<brettgilio>
where does the rust debugger come from?
<brettgilio>
or I guess since rust compiles native just gdb would do
<rgrinberg>
If dune can manage the compiler, it can surely manage simple binaries like lsp or merlin
<brettgilio>
Yeah rgrinberg the more I think about it, I do think the concept of switches is part of the problem.
<brettgilio>
they are great until they arent
<d_bot>
<NULL> About `eval $(opam env)`, I don't know which parts makes it possible but I don't need to use it ever since I switched to zsh
<rgrinberg>
yes, opam can hijack your shell's dotfile to do this incantation for you
<d_bot>
<Anurag> opam init offers to set up shell hooks for bash/zsh/fish, and then you won't need to use `eval $(opam env)`
<d_bot>
<NULL> Well it doesn't work for me in bash
<d_bot>
<NULL> Okay, that was on me, I got it working in bash
aspe has quit [Ping timeout: 246 seconds]
<companion_cube>
rgrinberg: most of the issues with installing the compiler are related to relocatability, right?
vicfred has quit [Quit: Leaving]
<rgrinberg>
probably not. or at least i don't see how.
<rgrinberg>
the main issue is that we need quality dune rules to build the entire toolchain without ocamlc already being installed
<companion_cube>
hum
<companion_cube>
I'm being naive again, but does it have to be _quality_? :D
<brettgilio>
Could bootstrap from something like camlboot?
<companion_cube>
can you run the configure/make rules for ocamlopt?
<brettgilio>
But thatd be painful likely
<rgrinberg>
companion_cube you'd lose much of the benefits of using dune for this. in particular, we'd need to rely on the dune cache to actually make this bearable per project
<brettgilio>
How does opam currently handle building the toolchain without a system level ocamlc/ocamlopt?
<companion_cube>
ah, cause it'd still be local to the project
<companion_cube>
I see
<companion_cube>
rgrinberg: doing it the naive way is as bad / as good as opam
<companion_cube>
what I'd like is a cargo-like experience for the rest of the development
<companion_cube>
not necessarily to create a switch in the current project
<rgrinberg>
i don't plan on creating switches anywhere :)
<rgrinberg>
but anyway, you probably care about fetching/generating lock files, right?
<rgrinberg>
opam-monorepo is pretty good for that
<brettgilio>
companion_cube how does cargo find the referenced toolchain version? Like where does rustup keep it and how does cargo find it?
Serpent7776 has quit [Read error: Connection reset by peer]
<companion_cube>
rgrinberg: yeah I mostly would love a workflow where `dune build --profile=release <foo>` would pick on the lockfile, install deps, etc.
<rgrinberg>
without the compiler?
<companion_cube>
oh, not necessarily.
<companion_cube>
I'm ok with `dune init` or whatever to install the right compiler
<companion_cube>
it's something more rarely done… although I get your point, if you just cloned a repo… hmm
<rgrinberg>
to me, it seems like dealing with the compiler is half the problem. which is why i don't use opam-monorepo myself very much
<brettgilio>
companion_cube or `dune build --profile=release --toolchain=ocaml-base-compiler-5.0.0` or keep the toolchain rules in a dune-project file
<rgrinberg>
in dune, we don't like passing too many command line flags. so you will have to specify the toolchain the workspace file or something
<brettgilio>
I prefer the file method anyways
<brettgilio>
I like the @targets and think those could be useful for one offs here
<brettgilio>
Like @4.14.0+libs or something
<brettgilio>
But then we are back to how dune would manage these compilers in the first place
Serpent7776 has joined #ocaml
<rgrinberg>
which has a good answer. once somebody will put in the hardwork of doing it :)
<companion_cube>
rgrinberg: so the relocation part is where it's a problem, again? cause if it was, you could just copy the ocamlopt from a central cache
<rgrinberg>
why is relocation a problem though? i don't see why we need to copy the compiler anywhere, and I doubt most users care where their ocaml binaries exist
<brettgilio>
Seems like rustup installs rust to .cargo
<brettgilio>
So .cargo can directly reference it like everything else
<rgrinberg>
what's the point though?
<brettgilio>
Could dune not have a central .dune cache?
<rgrinberg>
nobody runs the compiler manually anyway
<rgrinberg>
if you want to run it, you could always dune exec ocamlc
<brettgilio>
So that invocation by dune doesnt require the ocamlopt compiler to be copied to 30 different places
<brettgilio>
I agree with you rgrinberg
<brettgilio>
I dont necessarily see relocation as an issue here
<d_bot>
<nutellα~> hello folks, this may be a dumb question, but is it possible to use ReasonML syntax on utop?
<d_bot>
<nutellα~> rtop is not working for my personal usecase
<rgrinberg>
it's not possible.
<rgrinberg>
wait a second, maybe it's possible now. you need to evaluate `dune top` in rtop
<d_bot>
<nutellα~> lmao is this a bot or a real human
<d_bot>
<nutellα~> sounds like a real human
<brettgilio>
We are on irc
<brettgilio>
This chat is bridged
<d_bot>
<nutellα~> ohh
<d_bot>
<nutellα~> I understand
<rgrinberg>
#use_output "dune top" in rtop I think
<brettgilio>
companion_cube relocation doesnt seem like an issue in the cargo model, but granted my knowledge of rust literally older than my own kid who is almost 3. So I see the potential of a .dune dir in home as a potential solution
<rgrinberg>
sure. that sounds like a good enough solution to me.
<d_bot>
<nutellα~> #!/usr/bin/env rtop
<d_bot>
<nutellα~> print_string("test");
<d_bot>
<nutellα~>
<d_bot>
<nutellα~> well I have this Reason code, it is showing the rtop welcome screen, unlike utop
<d_bot>
<nutellα~> so I don't know what I can do
<companion_cube>
brettgilio: the rust compiler doesn't depend on where it lives, afaik
<d_bot>
<nutellα~> poggers
<companion_cube>
what doesn't work?
hyphen has quit [Ping timeout: 260 seconds]
<companion_cube>
rgrinberg: but then if you don't need a compiler per project, it'll probably be fast to compile a new project
<companion_cube>
assuming either: a lockfile without specifying ocamlopt
<companion_cube>
or a lockfile that uses a compiler version that is already installed
hyphen has joined #ocaml
<brettgilio>
companion_cube what are the ways in which ocamlopt depends on where it lives?
<companion_cube>
it contains absolute paths in several places, I honestly don't recall exactly where
<companion_cube>
but the places it looks for .cmi and .cmo files are affeced
<brettgilio>
Those absolute paths come from the ./config step I assume?
<companion_cube>
of course dune would be perfectly able to provide the required paths.
<companion_cube>
I think so, yeah
<rgrinberg>
Yeah, when I say a compiler per project I don't necessarily mean we need to build it per project. Just that it should appear while inside the project.
<companion_cube>
then I think that compiling ocamlopt naively is fine, for a start
<companion_cube>
it's quickly amortized
<rgrinberg>
I suppose so
<brettgilio>
Then I would think that a central .dune dir would handle this well, and we just dont relocate the compiler. Any per project configurations would just get their own copy compiled? Idk honestly
<rgrinberg>
for a compiler to appear in a project, it's sufficient to just populate some environment variables.
<brettgilio>
If anybody writes anything that tries to cp the compiler, we just show up at their door and yell at them
<rgrinberg>
so yeah, the compilers could stay in .dune/
<brettgilio>
rgrinberg something dune can easily handle
<brettgilio>
Then make dune-monorepo for everybody else lol
<companion_cube>
rgrinberg: if you ever go this way, please
<companion_cube>
only one lockfile per project
<companion_cube>
not one per package :/
<rgrinberg>
lol
<rgrinberg>
we'll have one lock file per build plan, and you can have as many build plans as you want. even select them per context, etc.
* brettgilio
just clues in that rgrinberg is a dune member
<brettgilio>
I wonder if such a draft is something we could propose. I cant hack on it much, but over the summer id have more time (though probably not enough skill)
<brettgilio>
Or if such a draft exists already
<rgrinberg>
i'd say start small. do a few smaller contributions in dune as a warm up
<brettgilio>
I am but a lowly teacher who casually enjoys ocaml :)
<rgrinberg>
we've all casually enjoyed ocaml at some point
<companion_cube>
I note the "we'll", not "we would" :-°
<brettgilio>
And some people casually have phds in cubical type theory and implemented a PRL in 30 lines of ocaml lol
<rgrinberg>
companion_cube maybe i'm optimistic. the backlog of feature wishes in dune is super long.
<brettgilio>
Is there a compiled list?
<brettgilio>
or just the github issues box
<rgrinberg>
just the github issues
<brettgilio>
well, congratulations on being a working member of what will be the center of the entire ocaml ecosystem. hahaha
<brettgilio>
but in reality, I would love to contribute. Once this school year ends, I might dig up a few small tasks
<companion_cube>
rgrinberg: what does "build plan" mean in this particular case?
<rgrinberg>
it's a mapping from every external dependency to a url that can be used to fetch its source
<companion_cube>
(… and check its checksum?)
<rgrinberg>
that would be nice as well :)
<brettgilio>
companion_cube checksums are for losers. Live life on the dangerous side
<drakonis>
brettgilio: so you mean nix/guix users are losers :V?
<drakonis>
they checksum everything!
<brettgilio>
drakonis My 300+ commits to guix have something to say about this :)
<drakonis>
heh
<drakonis>
it is a statement
<brettgilio>
I was being sarcastic. Though I remember one time the crates system for rust had some blocking issue for checksums
<brettgilio>
And for like 3 days everybody opted out of them lol
<brettgilio>
I think that was when I decided I had had enough rust
<Corbin>
As long as `buildDuneProject` continues to work, I don't think any of this really affects nixpkgs.
<brettgilio>
Just imagine the potential of getting rid of opam. 😆
<drakonis>
ah rust.
<drakonis>
yes.
<drakonis>
although, personally, i think both would benefit from detaching non core packages from the build process
<drakonis>
so a language like rust wouldn't lock up the builds until it is dealt with
<drakonis>
although i think nix is most affected by this
<companion_cube>
brettgilio: if the hash system is broken, doesn't seem unreasonable to skip it for 3 days
<companion_cube>
what else do you do, take a vacation?
<brettgilio>
companion_cube find ocaml
<brettgilio>
That is literally what happened to me lol
<companion_cube>
I mean, what if you have too much rust (or any other language) to just jump ship?
<brettgilio>
Nah, I agree with you
<companion_cube>
I'd expect a lockfile system in OCaml to have an emergency override system for the same reason :)
<companion_cube>
opam has something to skip checksums iirc
<brettgilio>
Youre totally right. I just enjoy poking fun
<drakonis>
i find it mighty silly that the notion of letting people have escape hatches in nix and guix is considered bad
<companion_cube>
unsafePerformNoHash
<drakonis>
if only
<Corbin>
Well, it makes it rather hard to establish capability-safety. And since Nix stores already are enumerable, and there's a couple ways to impurely insert stuff into the store, I'm not sure how much more impurity is needed.
<brettgilio>
rgrinberg thanks for letting me use you as an idea sounding board
<rgrinberg>
np
<d_bot>
<Ambika E.> It's funny when the entire discord channel is messages from irc
vicfred has joined #ocaml
_PSY_ has joined #ocaml
bobo has quit [Ping timeout: 246 seconds]
bobo has joined #ocaml
Haudegen has joined #ocaml
gereedy has quit [Quit: gereedy]
vicfred has quit [Quit: Leaving]
<d_bot>
<yrashk> I wonder if I am missing anything in my thinking. Why is it that in much of OCaml code (well, the one I observed) we tend to use individual type-specific functions (say, for comparison or a quality: `Int.equal`, `Int.compare`) as opposed to using the module system and detaching the operation from the operands, so to speak? If you look into derivations, they all generate `equal_this` and `equal_that`. I am preparing a library to pu
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kurfen has quit [Ping timeout: 240 seconds]
kurfen has joined #ocaml
_PSY_ has quit [Quit: .]
gravicappa has joined #ocaml
brown121407 has joined #ocaml
_whitelogger has joined #ocaml
lisq has joined #ocaml
landonf has joined #ocaml
drakonis has joined #ocaml
drakonis has joined #ocaml
drakonis has quit [Signing in (drakonis)]
caasih has joined #ocaml
jsoo has joined #ocaml
riverdc has joined #ocaml
reynir has joined #ocaml
gdd has quit [*.net *.split]
d_bot has quit [*.net *.split]
mg- has quit [*.net *.split]
grobe0ba has quit [*.net *.split]
micro has quit [*.net *.split]
SquidDev has quit [*.net *.split]
CalimeroTeknik has quit [*.net *.split]
ebb has quit [*.net *.split]
micro has joined #ocaml
micro has quit [Changing host]
micro has joined #ocaml
SquidDev has joined #ocaml
d_bot has joined #ocaml
mg- has joined #ocaml
gdd has joined #ocaml
grobe0ba has joined #ocaml
ebb has joined #ocaml
brown121407 has quit [Ping timeout: 244 seconds]
CalimeroTeknik has joined #ocaml
grobe0ba has quit [Ping timeout: 248 seconds]
grobe0ba_ has joined #ocaml
brown121407 has joined #ocaml
grobe0ba_ is now known as grobe0ba
brown121407 has quit [Remote host closed the connection]
brown121407 has joined #ocaml
jpds has quit [Ping timeout: 240 seconds]
<d_bot>
<undu> I know `Orderring.t` has not been adoptes in the standard library to avoid breaking compatibility. Regarding the module dispatch... I'm the code I've worked comparing is quite rare, I haven't felt the need to have it, there are many other bigger inconveniences I guess
<d_bot>
<undu> Don't worry and publish it, advertise it on the discuss.ocaml.org forums , you should get useful feedback about it
jpds has joined #ocaml
<d_bot>
<yrashk> I am generally wary of publishing on discussion forums, can provoke some flamewars or just less than constructive discussions. I am just curious if this makes any sense to others; wanted to sound-check it.
<d_bot>
<Bluddy> when you say module dispatch you mean first class modules?
<d_bot>
<yrashk> yeah, basically instead of having functions that couple the types of the operands and the operation itself (say "equality of integers") I am experimenting with separating this into operations ("equality") and types ("integers") where the actual implementations are provided by first class modules indeed.
<d_bot>
<sim642> Maybe I'm missing the point, but it seems like a roundabout way to call `Int.equal`
<d_bot>
<Butanium (@me on reply)> yes I thought like sim642
<d_bot>
<sim642> Because they're still coupled in the `(module Int)` argument, which has to implement it and know the type which it implements it for
<d_bot>
<Butanium (@me on reply)> not sure how it's different
<d_bot>
<yrashk> my point here is to generalize operations; so that I only need to call, say, Eq.eq or Ord.cmp instead of looking for type-specific `euqal` and `compare`
<d_bot>
<sim642> But you still have to look for the first-class module to provide as argument
<d_bot>
<yrashk> yes
<d_bot>
<sim642> It would make a difference if we had modular implicits
<d_bot>
<yrashk> I would have loved to have modular implicits indeed
<mro>
Anybody an idea how to reduce the footprint of https://opam.ocaml.org/packages/uucp? It adds all unicode character names etc. to the linked binary. About 3MB.
<d_bot>
<yrashk> my feeling here is with the approach taken is that now I can pass operations OR modules independently down the implementation. I will try to come up with a better (deeper) example.
<d_bot>
<sim642> Compress the data and decompress at runtime?
mbuf has joined #ocaml
<mro>
sim642: i'd even rather strip them if I knew how.
<d_bot>
<yrashk> cc @Butanium here's a slightly more complicated example where we define a range of things that should be possible to do with operands https://gist.github.com/yrashk/6233141df17bfe2811460a92a0f8bd19 ; Some benefits from the use of modules comes from structural indication of implications (say, Eq implies equivalence but PartialEq implies only partial equivalence; there's no difference between them code-wise).
<d_bot>
<yrashk>
<d_bot>
<yrashk> But it's okay if I am way off the mark and this is useless 🙂
<d_bot>
<yrashk> Let's put it this way -- if a function 'f' needs to do a some operations on some values of certain types, we can either pass a bunch of functions to it ("this one is for equivalence", "this one is for order", etc.) or we can pass a first-class module so that `f` can use whatever it needs. The idea here was that one module easily composes over multiple "traits".
<d_bot>
<Butanium (@me on reply)> My remark was really naive I almost never passed module as argument in OCaml 😉
<d_bot>
<octachron> @yrashk , without modular explicit (aka lightweight functors), this approach does not scale to higher-kinded types.
CalimeroTeknik has quit [Changing host]
CalimeroTeknik has joined #ocaml
mro has quit [Remote host closed the connection]
<dh`>
it sounds like you want typeclasses and not modules
mro has joined #ocaml
olle has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
bartholin has joined #ocaml
grobe0ba has quit [Read error: Connection reset by peer]
grobe0ba has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
kakadu has joined #ocaml
mro has quit [Remote host closed the connection]
wingsorc has quit [Ping timeout: 244 seconds]
Haudegen has quit [Quit: Bin weg.]
gravicappa has quit [Ping timeout: 256 seconds]
jpds has quit [Ping timeout: 240 seconds]
jpds has joined #ocaml
Haudegen has joined #ocaml
<d_bot>
<ec> wait, hold the fucking phone, you're learning OCaml!?
mbuf has quit [Quit: Leaving]
gravicappa has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
Sankalp- has joined #ocaml
Sankalp has quit [Ping timeout: 276 seconds]
Sankalp- is now known as Sankalp
<d_bot>
<EricSesterhennX41> I was wondering, since there is no Security.md (or similar) for ocaml (at least i didnt find it), what is the best way / place to discuss security relevant questions or issues?
chrisz has quit [Ping timeout: 276 seconds]
chrisz has joined #ocaml
waleee has joined #ocaml
mbuf has joined #ocaml
rgrinberg has joined #ocaml
gravicappa has quit [Ping timeout: 258 seconds]
bartholin has quit [Ping timeout: 260 seconds]
bartholin has joined #ocaml
vicfred has joined #ocaml
motherfsck has joined #ocaml
mro has joined #ocaml
remexre has quit [Ping timeout: 250 seconds]
mro has quit [Remote host closed the connection]
remexre has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<mbacarella> I'm really looking forward to ocaml multicore on M1s
<d_bot>
<mbacarella> oh man, 2-3 weeks of focused hacking left
zebrag has joined #ocaml
<d_bot>
<octachron> As far as I know, OCaml 5 already works on M1 right now. The multicore repository is nowadays only a historical archive.
mro has joined #ocaml
<d_bot>
<mbacarella> oh. i tried to get 4.12+domains to build and it failed. i guess i should go straight to 5?
<d_bot>
<octachron> @EricSesterhennX41 , you can open regular issues, or do you need a private channel?
<d_bot>
<octachron> Indeed, you should try 5.0.0+trunk
mro has quit [Remote host closed the connection]
<d_bot>
<EricSesterhennX41> if there is a private channel i would prefer that, since I am not really sure how ocaml handles potential issues and i am too new to ocaml to be able to estimate the full impact
rgrinberg has joined #ocaml
<d_bot>
<EricSesterhennX41> but i guess, the main question is, how does the ocaml project handle these topics, if github issues is the preferred way, thats fine for me
<d_bot>
<EricSesterhennX41> lot of projects have something like a security.md file where they outline where to send security sensitive things etc
hyphen has quit [Ping timeout: 260 seconds]
hyphen has joined #ocaml
gravicappa has joined #ocaml
mro has joined #ocaml
<d_bot>
<octachron> Is it really that common for compilers? Neither rust nor swift nor gcc seems to have a `SECURITY` file. But it is true that llvm does. Anyway, we don't really have a process for security issues, if a github issue really does not seem adequate, you can send me a mail and I will transfer it the rest of the maintainer team.
hyphen has quit [Ping timeout: 255 seconds]
<d_bot>
<EricSesterhennX41> not compilers per se, but since ocaml ships eg the stdlib/runtime as well it might be appropriate
hyphen has joined #ocaml
<d_bot>
<octachron> Which languages outiside of assembler don't ship a stdlib/runtime? For instance, gcc/clang/mucc ship one.
<d_bot>
<EricSesterhennX41> some projects are like super secretive until a patch is ready for even remotely security related things, thats why i tought it might be better to ask
<d_bot>
<EricSesterhennX41> yeah, it might be a corner case, but I would consider the libc similar to ocaml/stdlib?
<d_bot>
<octachron> We are mostly on the transparent end of the spectrum. I think. (Partially by lack of resources and the quite upstream nature of compilers).
<d_bot>
<EricSesterhennX41> good to know. I will send you my remarks/questions latest tomorrow morning and if github issues are better suited i will file them
<d_bot>
<EricSesterhennX41> got to jump to take care of the kid, thanks!
hyphen has quit [Ping timeout: 258 seconds]
hyphen has joined #ocaml
hyphen has quit [Ping timeout: 244 seconds]
hyphen has joined #ocaml
hyphen has quit [Ping timeout: 256 seconds]
aspe has joined #ocaml
hyphen has joined #ocaml
aspe has quit [Client Quit]
aspe has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
hyphen has quit [Ping timeout: 240 seconds]
hyphen has joined #ocaml
waleee has quit [Ping timeout: 244 seconds]
remexre has quit [Ping timeout: 244 seconds]
remexre has joined #ocaml
P1RATEZ has joined #ocaml
aspe has quit [Quit: aspe]
aspe has joined #ocaml
mro has quit [Quit: Leaving...]
chiastre has quit [Ping timeout: 260 seconds]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mbuf has quit [Quit: Leaving]
rgrinberg has joined #ocaml
bartholin has quit [Quit: Leaving]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
spip has joined #ocaml
bobo has quit [Ping timeout: 246 seconds]
hyphen has quit [Ping timeout: 258 seconds]
hyphen has joined #ocaml
hyphen has quit [Ping timeout: 248 seconds]
hyphen has joined #ocaml
rgrinberg has joined #ocaml
Haudegen has joined #ocaml
<companion_cube>
@octachron stdlib sure, but stuff like rust no_std has no runtime, correct? :)
hyphen has quit [Ping timeout: 240 seconds]
hyphen has joined #ocaml
<octachron>
Yes, as far as I understand. At the same time, you can also see the no_std mode as a option for disabling the rust runtime.
<companion_cube>
indeed
hyphen has quit [Read error: Connection reset by peer]
<companion_cube>
that's pretty much it
<companion_cube>
and you retain only the parts of the stdlib that don't require the runtime
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hyphen has joined #ocaml
hyphen has quit [Read error: Connection reset by peer]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
xgqt has quit [Ping timeout: 256 seconds]
xgqt has joined #ocaml
gravicappa has quit [Ping timeout: 255 seconds]
Everything has joined #ocaml
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
Haudegen has joined #ocaml
aspe has quit [Quit: aspe]
<d_bot>
<mbacarella> can anyone think of an example of building an AST from list of strings that would match on that list and construct a polymorphic variant from it? e.g. given ```["a"; "b"; "c"]``` it would build ```match "a" -> `A | "b" -> `B | "c" -> `C```?
zebrag has quit [Ping timeout: 240 seconds]
zebrag has joined #ocaml
<d_bot>
<mbacarella> actually is there an easy way to write an .ml file and have OCaml load it and then dump a pretty print of the AST?
<thizanne>
you can give -dparsetree to the compiler