rgrinberg has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
zenmov has quit [Ping timeout: 260 seconds]
<Soni>
14900k unreliable? sounds about right
<Soni>
sorry you got unlucky
zenmov has joined #ocaml
<companion_cube>
Isn't there a firmware update?
<companion_cube>
Since intel messed up the 13 and 14th gen
Haudegen has quit [Quit: Bin weg.]
<Soni>
it can't fix silicon damage
<Soni>
it can, to some extent, prevent further damage tho
<discocaml>
<mbacarella> intel-microcode is already the newest version (3.20240910.0ubuntu0.24.04.1).
<discocaml>
<mbacarella> 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
<discocaml>
<mbacarella> 😬
zenmov has quit [Read error: Connection reset by peer]
Tuplanolla has quit [Ping timeout: 255 seconds]
Everything has quit [Quit: leaving]
zenmov has joined #ocaml
<discocaml>
<oijolisp_11693> Hello I would to like to implement my own mesh generator for something like simulations (FEA), someone here could give me a recommendation about (papers. books), I think it will be cool try to implement this in ocaml 😄 and also how hard this will be specifically in ocaml (libraries and that kind of stuff) thanks in advance
<discocaml>
<mbacarella> I guess I thought it was built into the compiler, for some reason
semarie has quit [Ping timeout: 248 seconds]
semarie has joined #ocaml
<discocaml>
<deepspacejohn> I think you're both right. the value `compare` provided by the stdlib is defined as the external `%compare` which the compiler uses to specialize it when the compiler knows the types, or it uses the default polymorphic compare when it can't.
<discocaml>
<mbacarella> so... how does mirage deploy without a libc? the ocaml runtime depends on libc. is it also re-implementing the ocaml runtime?
<discocaml>
<mbacarella> I guess not so much providing its own runtime as rebuilding ocaml to use fewer features and providing a stub-libc
<discocaml>
<mbacarella> I guess not so much providing its own runtime as rebuilding ocaml to use fewer features and providing a minimal libc
semarie has quit [Quit: quit]
<reynir>
yea, I think that's right
semarie has joined #ocaml
zenes has joined #ocaml
zenes has quit [Changing host]
zenes has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
zenes has quit [Remote host closed the connection]
ygrek has joined #ocaml
f[x] has joined #ocaml
f[x] has quit [Remote host closed the connection]
mbuf has quit [Quit: Leaving]
olle has quit [Ping timeout: 255 seconds]
Haudegen has quit [Quit: Bin weg.]
pi3ce has quit [Read error: Connection reset by peer]
pi3ce has joined #ocaml
<discocaml>
<hannes6838> it provides these functions that are necessary, plus some stubs (symbols required by OCaml runtime, but when they're called they exit the program, or print a warning - depending on the concrete function) -- and indeed the ocaml-solo5 project does this. it also embeds a math library that is necessary for building the OCaml runtime (mainly float functions)
<discocaml>
<mbacarella> oh hey hannes 👋🏻
<discocaml>
<mbacarella> yes understood got it
<discocaml>
<hannes6838> and, as you mention, it doesn't build e.g. the unix package.
Anarchos has joined #ocaml
Haudegen has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
Serpent7776 has quit [Quit: leaving]
euphores has quit [Quit: Leaving.]
euphores has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #ocaml
myrkraverk_ has quit [Ping timeout: 248 seconds]
Tuplanolla has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<discocaml>
<mbacarella> goddamnit `uv` guy we trusted you
<companion_cube>
what uv guy??
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<discocaml>
<coolccat> im confused. this guy is saying, if you write the python code better than the rust/c/c++ code, it is better so therefore python is better? or am i just viewing this uncharitably because i dislike python 😭
<discocaml>
<Kali> "python can make writing fast code easier if there are already fast python libraries for the thing you're coding for"
<discocaml>
<mbacarella> he's saying python makes it convenient to use extremely fast highly optimized C libraries so arguing python is slow is not really fair
<companion_cube>
what's uv anyway?
<discocaml>
<mbacarella> `uv` is a new package manager for python written by rust people
<companion_cube>
oh
<companion_cube>
thought it was "rye" 🙃
<discocaml>
<mbacarella> so, it's fast and feels a lot like cargo. which is a breath of fresh air compared to the standard practice in python re: pip, pyenv, virtualenv, poetry, etc
Stumpfenstiel has joined #ocaml
<discocaml>
<mbacarella> > If you're getting started with Rye, consider uv, the successor project from the same maintainers.
<discocaml>
<mbacarella> > While Rye is actively maintained, uv offers a more stable and feature-complete experience, and is the recommended choice for new projects.
<discocaml>
<mbacarella> > Having trouble migrating? Let us know what's missing.
<discocaml>
<sim642> Kind of ironic that it's written in rust then, not that super fast python then
<discocaml>
<ape_logic> isn't it more or less the default dune project setup but with multiple executables declared?
<discocaml>
<ape_logic> imo the real problem with python packaging is.. python packaging
<discocaml>
<ape_logic> not the package manager
<discocaml>
<ape_logic> there's so many workflows to have an installable package and there's no restriction on downloading random stuff, no canonical way to compile some C library, etc, everything just kinda does its own thing
<discocaml>
<ape_logic> especially ML libraries, they seem full of custom build script insanity
<discocaml>
<ape_logic> especially machine learning libraries, they seem full of custom build script insanity
<discocaml>
<ape_logic> also, to be fair rust and python play together really well with pyo3, making the guts of something in rust and then the interface in python is a solid choice imo
<discocaml>
<mbacarella> yeah i agree python packaging is a horrific mess but `uv` is still a nice quality of life improvement
<discocaml>
<ape_logic> for fun comparison try writing in rust for node js
<discocaml>
<ape_logic> i am a nix freak so it's all just a lower level of abstraction to me :p
<dh`>
I cannot fathom why anyone would _want_ something like cargo
<dh`>
but maybe I'm weird
<discocaml>
<ape_logic> ... until I have to package it myself 😩
<dh`>
yeah, it just works, as long as you limit yourself to a small number of crates that are themselves not much more complex than helloworld
<discocaml>
<ape_logic> it makes rust fully self contained and removes all the annoyance you get using some libs in Cpp for example
<dh`>
I can't imagine trying to set up a 100,000-line project in cargo, let alone anything really large like an operating system or production compiler
<discocaml>
<ape_logic> why?
<dh`>
because it dictates the structure of your sources
<dh`>
or rather, it dictates that your sources will have no structure
<dh`>
you can get away with that up to maybe half that size if your project is very disciplined
<dh`>
every extant large rust project seems to be hundreds of crates all mooshed together with no organization
<discocaml>
<ape_logic> is using sub crates (much as OP desires) not a form of structure?
<dh`>
my recollection from reading the cargo docs several months ago is that this is what lets you move from helloworld to a real small project
<dh`>
anyway, suppose you're trying to build a self-hosting compiler
<dh`>
where in cargo is the flexibility that makes it possible to even think about a multistage build?
<discocaml>
<mbacarella> cargo can't turn your python into a rust project because python doesn't allow multiple versions of the same package
<discocaml>
<ape_logic> build.rs 😂
<discocaml>
<mbacarella> on the plus side you can usually just ignore build incompatibility hell and the solver doesn't take 15 seocnds to figure your dependencies out
<discocaml>
<mbacarella> in rust
<discocaml>
<ape_logic> I guess you have a point, though I think most people will use a Justfile + Cargo for this
<dh`>
that's just one example
<dh`>
suppose I'm trying to build an operating system
<discocaml>
<mbacarella> i've been in fairly big projects and didn't experience that much cargo hell so, maybe i've been lucky
<dh`>
quite apart from the question of how one might build a kernel with cargo, there'll be something on the order of 500-1000 programs that are part of your system
<dh`>
there does not appear to be any way in cargo for these to be anything other than 500-1000 separate crates
<discocaml>
<ape_logic> I wonder how Redox does it
<companion_cube>
dh`: there are actual counterexamples to your claims? large systems written in rust, etc
<companion_cube>
splitting in crates helps with modularity, sure, but you don't _have_ to have 1000s of them
<dh`>
cargo will only build one program per crate, you don't have much choice, do you?
<companion_cube>
you mean one executable? I think so..
<companion_cube>
otoh a kernel is a single executable 🤷
<dh`>
yeah but /usr/bin has hundreds
<discocaml>
<ape_logic> no, that's not true
<discocaml>
<ape_logic> you can have multiple executables
<dh`>
that is specifically not what the docs I have read have said
<companion_cube>
ah yeah, seems like the rust userlands have been packing multiple executables into one, busybox style
<discocaml>
<ape_logic> at least from one "workspace"
<dh`>
cube: gross
<dh`>
it is also possible that there are things they don't put into the documentation, or at least the documentation that can be found by outsiders
<companion_cube>
but if you make a full OS, kernel and userland, many crates doesn't seem crazy
<companion_cube>
ah good to know, lol
<discocaml>
<ape_logic> you use [[bin]] and specify a source file as entry point
<dh`>
ok, I must have gotten the wrong idea
<companion_cube>
very cool @ape_logic, til
<dh`>
I thought you could have multiple libraries but only one executable, but perhaps it's the other way around?
<dh`>
ah, it's the other way around
<dh`>
derp
<discocaml>
<ape_logic> if you want different libraries for different executables that's where you start with subcrates I believe
<discocaml>
<iamjcchan> is there a way to disable certificate verification with cohttp get request
<dh`>
I have 634 libraries on this system and it's not very heavily populated compared to many
<discocaml>
<ape_logic> also I think busybox style argv[0] checking is kinda neat ngl
<companion_cube>
just because linux has tons of small .so doesn't mean all OSes need the same thing
<companion_cube>
however it's true that rust skews more towards static linking anyway
<dh`>
if you had a real rust OS there probably wouldn't be any shared libraries, but you still have _libraries_
<companion_cube>
well there's lots of libraries on crates.io that you can already use
<discocaml>
<ape_logic> redox *is* a real rust os, no?
<dh`>
depends on what you mean by a real os
<discocaml>
<ape_logic> and yeah they do have many libraries, you can see some on crates.io
<dh`>
anyway the problem is that if you have say 250 library crates in your OS, that's 250 top-level things to keep track of
<dh`>
the real point here is that for something that size you really want at least some higher-level project structure
<dh`>
and it doesn't appear that cargo can do that
<companion_cube>
just like make also can't do that? I'm not sure what you're looking for really
<dh`>
make can do whatever, both the upside and the downside is that it's up to you to set it up
<companion_cube>
you might want a specialized package manager that will in turn invoke cargo for the programs written in rust
<dh`>
warning: I have written any number of complex build systems in make and have strong opinions :-)
<dh`>
anyway given that experience my assessment of cargo is that (like probably most build tools) it's entirely inadequate unless you stick to relatively simple projects
<dh`>
and I will definitely grant that it's less annoying than cmake
<companion_cube>
it'll scale fairly far I think
<dh`>
though it does have one really annoying property from a downstream perspective: it makes you jump through a lot of stupid hoops to patch anything
<dh`>
anyway the absolute worst builds are umbrella projects that have lots of different kinds of things
Everything has joined #ocaml
<dh`>
anyway my original comment was that I don't see why anyone would want something like cargo, and I stand by that -- for simple things it just works, but for equally simple things you can write a few makefiles and that'll just work too
<companion_cube>
I've never found makefiles to be up to the task for anything more advanced than C
<companion_cube>
so I guess we have to disagree here
<dh`>
I've never had real problems except for things that make you use their private bespoke system
<discocaml>
<ape_logic> I think cargo also serves to mask any magic in calls to rustc tbh
<dh`>
I have not tried but I imagine it would be difficult to build rust projects with make
<dh`>
and it was quite impossible with modula-3, for example, because the modula-3 compiler _only_ be run by their private build system
<companion_cube>
cargo also fetches dependencies
<discocaml>
<ape_logic> /usr/src ? never knew this was in the fhs
<dh`>
s/only/can only/
<companion_cube>
probably a BSD
<dh`>
fhs?
<discocaml>
<ape_logic> is it sources for your whole system ?
<dh`>
/usr/src is 20+ years older than the first linux fhs
<discocaml>
<ape_logic> filesystem hierarchy standard, it's what defines all the /var /etc /usr and so on
<discocaml>
<ape_logic> oh
<dh`>
the world's a lot broader than linux
<companion_cube>
on my machine there's barely anything in it
<discocaml>
<ape_logic> sure probably
<dh`>
and actually I would be very surprised if /usr/src isn't in the fhs
<companion_cube>
the world is also a lot broader than C :)
<companion_cube>
make has proven insufficient even for C++, in the long run
<dh`>
fetching dependencies should not be part of a build, but that's a whole different argument
<companion_cube>
well when you develop it's very convenient
<dh`>
cube: what did C++ break? :-)
<companion_cube>
and it's part of why lots of people like cargo
<discocaml>
<ape_logic> I agree and so does my build system of choice
<companion_cube>
people who ues C++ tend to use meson, cmake, etc because they want more than what make offers
<companion_cube>
or even bazel (🥵)
<dh`>
(a) download should be separate from build because you ought to be able to audit what's downloaded before running it through the compiler (even though most people never do)
<discocaml>
<ape_logic> have you seen Nix dh? it sounds like you might get along with it
<dh`>
(b) download should also be separate from build because there are in general multiple ways to download things, and also sometimes you can't download anything except manually
<companion_cube>
you can `cargo fetch` if this matters to you, ofc
<discocaml>
<ape_logic> or find 1000 problems with it, who knows 😂
<dh`>
I have used nix a bit, it has a bunch of weirdnesses and some of them are more or less shortcomings
<dh`>
cube: people use meson and cmake and whatnot because they got fed up with autotools (for good reason) and people use/used to use autotools because they couldn't be arsed to learn to write makefiles
<companion_cube>
we live in a world where it's normal to fetch dependencies from the web easily
<companion_cube>
and cargo makes that easy
<dh`>
yes, we also live in a world where people recommend curl | bash
<dh`>
doesn't make it advisable
<companion_cube>
it might not be a great idea, but not everyone is an openBSD dev
<discocaml>
<ape_logic> lmao it hurts me so much to see curl to bash on all these trendy new tools as the recommended install method
<dh`>
no disagreement on that!
<discocaml>
<ape_logic> the ubuntu crowd effect
<sleepydog>
mk is a nice quality of life improvement over make. not a drastic departure, just a few little touches that make it pleasant to use
<companion_cube>
curl | bash is basically "I trust the developers"
<sleepydog>
i use mkfiles as a general-purpose tool. it generates my blog, for example
<companion_cube>
it's funny to discuss this here, tbh, where dune has crushed most remnants of omakefile/omake/…
<sleepydog>
i recently tried to write a makefile for an ocaml project from scratch and got frustrated
<dh`>
my recollection is that omake had nothing going for it
<discocaml>
<diligentclerk> Hi, folks. I came across a subtlety in how the type checker handles optional arguments, and I was wondering if anyone could explain what is happening here. My understanding is that putting function arguments on the left of the equals sign is equivalent to putting them on the right of the equals sign under a lambda, but (unsurprisingly, I suppose) it gets more complicated when you bring in optional arguments.
<companion_cube>
sleepydog: duh, yeah
<discocaml>
<diligentclerk>
<discocaml>
<diligentclerk> let f ?(x:int = 0) ?(y:bool = false) : string -> unit =
<discocaml>
<diligentclerk> fun _ -> if x = 1 && y then ();;
<discocaml>
<diligentclerk> let g (y :bool) : string -> unit = f ~y;;
<discocaml>
<diligentclerk> let g' : bool -> string -> unit = fun (y:bool) -> f ~y;;
<discocaml>
<diligentclerk> The compiler accepts g but not g'. It says that f ~y is only partially applied. What is the rule here? Why is g treated differently than g' ?
<companion_cube>
it's not powerful enough
<sleepydog>
companion_cube: hmm, i don't think that was my issue. it was something about directory nesting being cumbersome.
<companion_cube>
do you use -M or sth to deal with dependency resolution?
<sleepydog>
yea
rgrinberg has joined #ocaml
<sleepydog>
i used `ocamldep`
<dh`>
I have been using bsd make for ocaml, and that works fine modulo a couple obscure problems with ocamldep I've run into
<dh`>
gmake doesn't cut it though
<dh`>
(either works fine for haskell, the problems with gmake stem from interface file/source file pairings)
<sleepydog>
dh`: do you use that OCamlMakefile or do you write your own
<dh`>
I wrote my own
<discocaml>
<ape_logic> man seeing all these angular brackets make me miss real irc
<discocaml>
<ape_logic> is only #general bridged from discord?
<dh`>
there are a bunch of things like OCamlMakefile and CoqMakefile floating around and all of them seem... idk, like attempting to avoid learning make
<dh`>
ape_logic: yes
<discocaml>
<ape_logic> tragic, I have dire need for #beginners also
<discocaml>
<._null._> @diligentclerk Apparently optional arguments can only be erased at function applications
<dh`>
ape_logic: you're on the discord side, what's stopping you?
<discocaml>
<diligentclerk> Recently I was playing with a window manager, and while installing and fiddling with it I repeatedly opened a terminal window many times to test the windowing system. I quickly noticed an observable delay while opening the terminal - less than half a second, but still very noticeable, as I expect opening a simple terminal window to be near instantaneous.
<discocaml>
<diligentclerk>
<discocaml>
<diligentclerk> I debugged my bash script and realized that I installed an application a while back written in NodeJS, I think via a simple curl + bash one-liner - yes, I know, caveat emptor - which automatically installed Node and added a reference to a configuration script to my .bashrc file so that every time I opened a new terminal window it would run the 4600-line configuration script to initialize the Node engine. That's the kind of thing I really
<dh`>
yeah in particular _never_ let any of those things turn themselves on in your shell config by default
<dh`>
also helps to not use bash, bash is phenomenally slow
<discocaml>
<ape_logic> dh: I'm saying the need for beginners channel is stopping me from realising my nostalgic IRC desires
<dh`>
ah
<discocaml>
<ape_logic> also lol that's insane
<dh`>
failed to follow, sorry :-)
<discocaml>
<ape_logic> only half a second startup time is better than I expected though I guess
<companion_cube>
I remember a friend using make for OCaml a long time ago on dragonflyBSD
<companion_cube>
why is BSD make better?
<discocaml>
<diligentclerk> @dh, are there better shells that you can recommend?
rgrinberg has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
<companion_cube>
fish! :p
<discocaml>
<ape_logic> I've been on a tear through different shells lately, especially the new batch like nushell, elvish, murex
<discocaml>
<diligentclerk> @companion_ cube how much of my system will I break if I try to replace bash with fish as the system shell? And is there anything about fish that's worth learning (I'm not super Unix-savvy, I'm a casual Ubuntu user)
<companion_cube>
oh a lot
<discocaml>
<ape_logic> they're all mostly much nicer than my previous zsh + 100 plugins but I still don't find any of them bridge the gap between "quick script" and "use a real programming language" for my small tools
<companion_cube>
fish is not posix
<companion_cube>
I mean I use it as my login shell
<dh`>
as the system shell is one thing, as your login shell a completely different thing
<dh`>
anything that breaks if you change your login shell was already wrong
<companion_cube>
^
<dh`>
replacing /bin/sh with something that isn't a sh will never work
<dh`>
using a sh that isn't bash as /bin/sh will sometimes work and sometimes require you to go fix things
<dh`>
some linuxes use dash and they have mixed success with it
<dh`>
the BSDs have their own sh implementations (that derive from ash, like dash, but have diverged a lot)
<dh`>
and that routinely requires patching gratuitous bashisms out of package builds and other things
<dh`>
but don't try to change your ubuntu, you'll just break everything
<dh`>
correction: but don't try to change your ubuntu's /bin/sh, you'll just break everything
<dh`>
although the more general statement is usually fairly true too
<discocaml>
<ape_logic> /bin/sh on ubuntu is probably a Snap by now 😂
<discocaml>
<diligentclerk> @dh regarding "couldn't be arsed to learn to write makefiles" I think that makefiles are not super user-friendly.
<discocaml>
<diligentclerk> Recently I spent a long time trying to debug a broken makefile, the error was on a line `var=filename ` where the space after the filename was accidental and not easily visible to me in the editor. If I could simply write `var="filename "` I would have spotted the error immediately. Tools like bash and make that allow such fluid slippage between commands, variables and strings are just a headache to me, I would rather use a language with
<dh`>
they are not, but it's not that difficult
<dh`>
and on types I agree with you
<dh`>
the first 95% of make is VAR=value, $(VAR), target: sources, and .c.o: suffix rules
<dh`>
oh and include and -include
<discocaml>
<diligentclerk> The fact that snaps are forbidden from accessing hidden directories and you can't change that setting is just insane.
<discocaml>
<diligentclerk> While setting up `odoc` and `odig`, I found that my Firefox snap couldn't access the html files that odig generates (because they were stored in the `.opam` directory). I looked in the odig documentation for a while but couldn't find a setting to change the location of the generated html files, so I ended up completely reinstalling OCaml in a folder called `opam` not `.opam`
<dh`>
that's enough for most simple projects
<dh`>
<companion_cube> why is BSD make better?
<discocaml>
<diligentclerk> Later on I gave up and installed the non-snap version of Firefox
<dh`>
sorry, missed tht
<dh`>
bsd make has a much saner metalanguage
<dh`>
and also more expressive, so you can write complicated things a lot more easily without having to argue with the tool
<dh`>
(note that saner is relative, there are still a lot of horrors)
<discocaml>
<diligentclerk> given that make is basically a form of logic programming, are there any build tools which are basically just dialogues of Prolog? Has anyone here ever written a build script in something like that?
<dh`>
gmake has a bunch of adhoc metalanguage constructs like ifeq, ifdef, etc. that aren't syntactically distinct
<discocaml>
<diligentclerk> dialects*
<dh`>
bsd make has an .if expression construct, where it's both clearly a directive line and has a real (if limited) expression syntax
<dh`>
diligentclerk: good question, I have no idea
<companion_cube>
So maybe bsd make would be useful to me as a build system, idk. I only have gmake on my system and it's clearly not good enough
<dh`>
bsd make also has a .for, which turns out to be really necessary for complex stuff
ygrek has quit [Remote host closed the connection]
<companion_cube>
So really you should qualify your claims about make
<dh`>
well, yes and no
<dh`>
you can do a fair amount with gmake
<dh`>
more than most people give it credit for
<companion_cube>
Outside of C and some C++, not that much imho
<dh`>
the thing that breaks down using gmake to build ocaml is that .mli files need to be built before their .ml files, and you'd like to be have to just write SRCS=foo.mli foo.ml bar.mli bar.ml
<dh`>
s/have/able/
<dh`>
(...?)
<dh`>
bizarre typo
<dh`>
anyway you can extract the list of .mli files and you can extract the list of .ml files for processing but I couldn't figure out a way to both generate the rules needed and preserve the ordering
<dh`>
and using rules to generate the ordering doesn't work that well
<dh`>
unless you are religious about never having a .ml file without a .mli file, and that isn't reasonable
<dh`>
with bsd make you can just iterate over SRCS with .for and do what you need
<dh`>
oh another thing, bsd make's parallelism works better
<dh`>
it's derived from the original parallel make implementation from berkeley, and gmake's parallelism was bolted on after and the difference shows
<dh`>
but beware that it also has some drawbacks, like a bunch of things that are named functions in gmake are single-letter magic variable modifiers
<discocaml>
<mbacarella> so... are you all using irssi or something? or stuff more like thelounge?
<dh`>
so on the one hand you can do $(VAR:C/pattern/substitution/) to do arbitrary regexp transforms, but on the minus side you have to remember the magic letter C
<discocaml>
<mbacarella> `/ctcp #general version`
<dh`>
(why C? fiik. S was already taken for non-regexp substitutions)
<dh`>
anyway I am now rambling and severely offtopic
<discocaml>
<ape_logic> as a spectator I was enjoying it
<discocaml>
<ape_logic> always interesting to hear about other unices, especially from someone properly experienced
<dh`>
well, I'm usually all too willing to blather away :)