<Anarchos>
zozozo i tried landmarks but it fails for me cause somewhere else in the project i do 'module type of' and it fails complaining about missing additionnal values added by landmarks
amiloradovsky has quit [Ping timeout: 258 seconds]
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
<Anarchos>
nobody tried to profile a project compiled with dune ?
ygrek has quit [Remote host closed the connection]
steenuil_ has quit [Read error: Connection reset by peer]
steenuil has joined #ocaml
mfp has quit [Ping timeout: 240 seconds]
ldbeth`` has joined #ocaml
ldbeth`` has quit [Ping timeout: 260 seconds]
mxns has quit [Ping timeout: 258 seconds]
ygrek has joined #ocaml
ygrek has quit [Remote host closed the connection]
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
mxns has joined #ocaml
mxns has quit [Ping timeout: 260 seconds]
steenuil has quit [Read error: Connection reset by peer]
<d_bot>
<Lupus> I hope Reason syntax support is not going to be dropped along?
mxns has joined #ocaml
<d_bot>
<rgrinberg> We'll keep reason support. Though I have no plans to improve or work on it myself.
waleee-cl has quit [Quit: Connection closed for inactivity]
narimiran has joined #ocaml
mxns has quit [Ping timeout: 264 seconds]
mxns has joined #ocaml
vicfred has quit [Quit: Leaving]
mxns has quit [Ping timeout: 258 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 258 seconds]
osa1 has quit [Quit: osa1]
osa1 has joined #ocaml
cqc_ has quit [Read error: Connection reset by peer]
kristjansson has quit [Ping timeout: 268 seconds]
ipavlo has quit [Ping timeout: 268 seconds]
cqc_ has joined #ocaml
ipavlo has joined #ocaml
bitonic has quit [Read error: Connection reset by peer]
JSharp has quit [Read error: Connection reset by peer]
JSharp has joined #ocaml
kristjansson has joined #ocaml
bitonic has joined #ocaml
mxns has joined #ocaml
mxns has quit [Ping timeout: 272 seconds]
nkatte has quit [Remote host closed the connection]
Serpent7776 has joined #ocaml
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #ocaml
wonko7 has joined #ocaml
Haudegen has joined #ocaml
mxns has joined #ocaml
mxns has quit [Ping timeout: 264 seconds]
rwmjones is now known as rwmjones|hols
dmbaturin has quit [Remote host closed the connection]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
Tuplanolla has joined #ocaml
bartholin has joined #ocaml
waleee-cl has joined #ocaml
neiluj has joined #ocaml
neiluj has joined #ocaml
mxns has joined #ocaml
mxns has quit [Ping timeout: 258 seconds]
urek has joined #ocaml
urek__ has joined #ocaml
urek has quit [Ping timeout: 258 seconds]
<d_bot>
<Cyclomatic Complexity> Hi
<d_bot>
<Cyclomatic Complexity>
<d_bot>
<Cyclomatic Complexity> I'm interested in a DSL for schedules. Like, a type that represents stuff like "Every 2 months, this. And every week, on Monday and Friday, that.", with timezone support and things like this.
<d_bot>
<Cyclomatic Complexity> I can't find any, but imagine this must be a widespread library, does anyone know of any such thing / better search keywords for Google?
dmbaturin has joined #ocaml
<d_bot>
<Drup> *cough* @BigOof *cough*
steenuil has joined #ocaml
<d_bot>
<darrenldl> @Drup and I have a library in the works atm that seems to align with what you're looking for: https://github.com/daypack-dev/timere - we still need to add recurrence based constructors (our current items are mostly pattern matching based), so not exactly everything you listed is expressible atm
<d_bot>
<darrenldl> for "monday and friday", it would be
<d_bot>
<darrenldl> for timezone support, you can do
<d_bot>
<darrenldl> ```
<d_bot>
<darrenldl> Timere.(change_tz_offset_s N (...))
<d_bot>
<darrenldl> ```
<d_bot>
<darrenldl> where N is the time zone offset in seconds to evaluate (...) under
<d_bot>
<darrenldl> Timere doesn't handle task scheduling exactly, however, Daypack-lib supports that, but it needs a lot of overhaul (reintegrating Timere into Daypack-lib, clean up, etc)
dmbaturin has quit [Remote host closed the connection]
<zozozo>
for people who marshal structures into files, do you use a specific extension for those files ? (just checking before I try and invent an extension)
<d_bot>
<darrenldl> @Cyclomatic Complexity there is one library I noticed that's recurrence based that could lead to more pointers: https://github.com/clulab/timenorm
<d_bot>
<darrenldl> note that they don't all achieve the same goal (timere allows you to resolve to explicit time intervals that matches your description at second precision, but does not handle actually running tasks etc)
shawnw has joined #ocaml
hnOsmium0001 has joined #ocaml
<neiluj>
do you know if that's possible to mix reason code and ocaml code?
<neiluj>
like, writing the backend in ocaml and the frontend in reason
<d_bot>
<Drup> you can mix them fine, as long as they are in different files, even in the same library
<neiluj>
how so? i did not find the information in the dune docs
<octachron>
Dune selects the syntax from the extension (ml/mli for the OCaml syntax, re/rei for the Reason one).
raver has quit [Quit: Gateway shutdown]
raver has joined #ocaml
<neiluj>
oh ok, thanks you all! (guess one can import reason modules in ocaml and the converse, right?)
<reynir>
Yes
<reynir>
It should Just Work™ with dune, I believe
<octachron>
More precisely there are no Reason modules, Reason is a syntax. Once your code is compiled, the syntax does not matter anymore.
vicfred_ has joined #ocaml
vicfred has quit [Ping timeout: 256 seconds]
vicfred_ has quit [Quit: Leaving]
<mrvn>
is anyone workiing on making ocamlopt multicore?
Jesin has quit [Quit: Leaving]
<octachron>
Do you mean working on upstreaming OCaml multicore (the answer is yes), or do you mean parallelizing ocamlopt with multicore OCaml (not as far as I know)?
<mrvn>
the later, making the final optimization and linking use multiple cores.
<companion_cube>
what'd be the expected speed-up, though?
<companion_cube>
seems to me like compilers are not super parallelizable
<mrvn>
I wouldn't say that. You have a lot of functions that can be optimized on their own. Register allocation and such can take time.
Haudegen has quit [Quit: Bin weg.]
<d_bot>
<joris> All I can say is that rustc can sometimes eat all my cores even when a single one is running
<mrvn>
joris: Oh? I just read a complaint about the rust code in firefox often taking a long time to compile on a single core while all the c++ code has already finsihed using all cores.
Jesin has joined #ocaml
<mrvn>
(plus that the rustc uses 13GB of ram, getting close to the 16GB the complainer has)
<neiluj>
reynir: excellent!
<d_bot>
<joris> I said it used all cores not that it was fast 🦊
<mrvn>
yeah, it isn't go. Where the design goal was: compiles fast.
<d_bot>
<joris> @mrvn but technically in Firefox it might be because rust is split into lots of small crate that create join nodes for parallel compilation while the c++ is probably more bunch of stuffs
<d_bot>
<Drup> I though the design principal of Go was to assume your programmers were stupid
<dash>
it's a safe assumption
<mrvn>
joris: The C++ code certainly isn't using LTO so every .o file is optimized in parallel.
<d_bot>
<joris> Lto (thin Lto at least) is also kind of parallel
<d_bot>
<beheddard> > “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
<d_bot>
<beheddard> -- Rob Pike
<d_bot>
<beheddard> ( Go founder )
<companion_cube>
🤷
<d_bot>
<Drup> Yeah, the Java 1.0 school of PL design
<d_bot>
<Drup> Some people should be forced to retire
<def>
:D
<Armael>
"they're not capable of understanding a brilliant language" ahhh
<d_bot>
<Anurag> > So, the language that we give them has to be easy for them to understand.
<d_bot>
<Anurag> If only there was a consensus on what is "easy" to understand 🙂 Go might be simple to write, but I personally don't find it to be the easiest language for maintaining large projects.
<dash>
anurag you don't have 100+ programmers working for you though
<dash>
what's easiest to maintain for a single person and what's easiest to maintain for an org that's constantly adding and losing people may be different
ygrek has quit [Remote host closed the connection]
<d_bot>
<Drup> Yes, that's why they gave all programmers the ability to make segfaults, it's much easier for everyone involved
<d_bot>
<beheddard> But hey, they're getting weird looking generics now!
<companion_cube>
their generics might not be too bad, tbh
<companion_cube>
they'll have the ability to restrict type parameter to satisfy a constraint
<companion_cube>
which is useful
<d_bot>
<beheddard> Why the alternative was could be anything interface {} yea
<companion_cube>
no I mean, they will be able to say "for any T satisfying interface I"
<companion_cube>
which we can't do
<d_bot>
<beheddard> Ahh I see
RalfJ has quit [Remote host closed the connection]
<d_bot>
<beheddard> Except with modules I guess
RalfJ has joined #ocaml
<def>
or objects
<d_bot>
<joris> Tbh it is true it is easier to write super obscure code a newcommer will need weeks to understand even if the author didn't left in ocaml than in go
<d_bot>
<Anurag> dash: That's a fair point, I only have experience in teams of around 10-12 engineers with people leaving/joining over time, and my opinion has been formed in that setting
<d_bot>
<joris> That is a valid concern.
<d_bot>
<joris> It is also much easier to do in c than in go
<d_bot>
<joris> So this part was successful. But go is a risk averse approach to code maintaince while assuming there is vaste amount of ressources for qa, integration testing and fuzzing
<d_bot>
<joris> Which might as well be true for Google idk
<dash>
I don't like Go either. But I also don't like the idea of working at Google
<dash>
All this just validates Conway's law further - the kinds of software you can produce are determined by the structure of your organization
<d_bot>
<beheddard> Tbh, a nitpicky thing, but whenever I've read Go source on Github I wonder why the hell they force tabs with their autoformatter
<d_bot>
<joris> Tabs are good. Unfortunately nobody like them anymore
<companion_cube>
it's C like, why not
<d_bot>
<joris> I wish all languages were forcing tabs
<companion_cube>
I mean it works if you have a statement oriented language
<companion_cube>
which in 2011 was a mistake
<companion_cube>
but well
<d_bot>
<Ulugbek> (shouldn't such discussion be in "random"?)
<d_bot>
<beheddard> I just find the huge indents of whitespace make it harder to read on github 😅 which is why I said nitpick. I don't write in the lang
<companion_cube>
we're on IRC @ulugbek
<def>
companion_cube: why do you think statement oriented is a mistake?
<companion_cube>
I think expression oriented is strictly better :)
<companion_cube>
not claiming it's objective, of course
<dash>
why would you have statements when you can have expressions instead
<def>
rust is statement oriented too :P
<companion_cube>
no it's not
<companion_cube>
rust is expression oriented
<def>
yes it is
<def>
it has both.
<companion_cube>
what's not an expression in rust?
<companion_cube>
rust is as statment oriented as OCaml
<companion_cube>
no more, no less
<dash>
there's a bunch of things that aren't expressions in rust
<companion_cube>
such as?
<dash>
but it's definitely more expression-y than C or Python or whatever
<companion_cube>
I disagree, it's as expression oriented as OCaml
<def>
I agree it is a mistake to forbid statements in expression, but I don't think it is a mistake to have both
<d_bot>
<Drup> if you allow statements in expressions, it means that pretty much everything is an expression in practice :p
<def>
to me expression emphasize computations where order in not important while statements are about expressing control flow
<def>
everything is a module in OCaml then.
<companion_cube>
everything is in a module* ? :p
<companion_cube>
I mean, `let` in rust is a statement, but you can put blocks anywhere, so it's isomorphic to `let` in OCaml if you have ( ) or begin/end around it
<companion_cube>
but match, while, if, etc. are expressions
<companion_cube>
that's the big difference with Go
<companion_cube>
also, any block can return a value
<companion_cube>
which is what differentiates good syntax (ocaml, rust, etc.) from bad (go, JS, python) :p
<companion_cube>
FACTS
<def>
I agree :)
<def>
But it is cleaner to have different syntactic categories for pure and for order-sensitive computations
<def>
(unless you write haskell code, in which case... you add these syntactic categories after the fact and call them sugar)
<companion_cube>
agreed
<companion_cube>
but then only lisp (?) is purely expression based, I guess
<companion_cube>
after all a haskell do-block is a series of statements
<def>
OCaml is quite strongly expression based :P
<companion_cube>
OCaml's let is the same as rust's :p
<companion_cube>
look at Reason, it's *exactly* like rust's syntax
<companion_cube>
{ let x=1; let y=2; x+y }
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
Haudegen has joined #ocaml
<d_bot>
<EduardoRFS> pretty isn't it?
<companion_cube>
I do like it :p
<companion_cube>
I'm just saying, it's the same as OCaml
<companion_cube>
just forces you to put a block around
<d_bot>
<EduardoRFS> and uses `;` for everything, instead of mixing with `in`, I really don't like this
<d_bot>
<EduardoRFS> ```ocaml
<d_bot>
<EduardoRFS> in
<d_bot>
<EduardoRFS> in
<d_bot>
<EduardoRFS> ;
<d_bot>
<EduardoRFS> in
<d_bot>
<EduardoRFS> in
<d_bot>
<EduardoRFS> ```
<d_bot>
<EduardoRFS> sometimes I use `let () =` just to make it consistent
<companion_cube>
:D
bartholin has quit [Quit: Leaving]
<d_bot>
<beheddard> I quite like `in`, especially when ending multiline expressions on a new line. Really grew on me despite being foreign at first
<d_bot>
<rw> When I learned of OCaml through Reason, I thought "wtf is this 'let in' who decides these things", but then I noticed that most of the time it reads very naturally.
<def>
> look at Reason, it's *exactly* like rust's syntax
<def>
:D, I know, that's an accidental ;)
<def>
that's not*
<companion_cube>
yep
<d_bot>
<Drup> to be fair, both started with the premise "take the ML syntax and make it more C"
<companion_cube>
but since reason is ocaml, it shows that the amount of expressions in the syntax is the same for OCaml and rust :p
<d_bot>
<Drup> so, naturally ...
<companion_cube>
were I to make a new ML variant, I'd definitely go for that syntax anyway
<def>
Like Eduardo, I prefer ; to in.
<d_bot>
<Drup> Actually, I would probably do the same
<d_bot>
<Drup> uniform usage of {} for delimiters is pretty nice
<def>
:), just sad we didn't find anything better for tuples.
<d_bot>
<Drup> I would probably not use the application syntax though
<def>
f() ?
<d_bot>
<Drup> yeah
<def>
I like it :). And I don't like currified functions
<d_bot>
<Drup> I prefer the ML one, with auto-curification
<d_bot>
<Drup> and more importantly, the syntax should match the semantics
<companion_cube>
agreed on that
<companion_cube>
you can have `match x { … }` and `f a b` in the same syntax
<companion_cube>
(but I think my point about rust being expression based stands :p)
amiloradovsky has joined #ocaml
<d_bot>
<rgrinberg> @octachron why doesn't this work?
<d_bot>
<rgrinberg> ```
<d_bot>
<rgrinberg> and 'k ret =
<d_bot>
<rgrinberg> | Values : values ret
<d_bot>
<rgrinberg> | Fields : Fields.t -> fields ret
<d_bot>
<rgrinberg> The compiler can't refute `Fields _ ` for some reason.
<d_bot>
<rgrinberg> `fields` is defined in this module while `values` is abtsract
ygrek has joined #ocaml
<d_bot>
<octachron> Is `values` defined in this module? Or `Fields.t` abstract?
<d_bot>
<rgrinberg> In this module:
<d_bot>
<rgrinberg> ```
<d_bot>
<rgrinberg> module Fields = struct
<d_bot>
<rgrinberg> type t = Sexp.t String.Map.t
<d_bot>
<rgrinberg>
<d_bot>
<rgrinberg> let check_empty _ = ()
<d_bot>
<rgrinberg>
<d_bot>
<rgrinberg> let of_list _ = String.Map.empty
<d_bot>
<rgrinberg> end
<d_bot>
<rgrinberg>
<d_bot>
<rgrinberg> type values = Sexp.t
<d_bot>
<rgrinberg>
<d_bot>
<rgrinberg> type fields = Fields.t
<d_bot>
<rgrinberg> ```
<d_bot>
<rgrinberg> So only `values` is abstract
<d_bot>
<octachron> Rather every thing is abstract here if `Sexp.t` is abstract: String.Map.t is abstract; Sexp.t is abstract; and none of them are defined in this module.
<d_bot>
<octachron> The typecheck has to consider the case where `Sexp.t= Sexp.t String.Map.t`.
<d_bot>
<octachron> One solution is to add an independent type level tag:
<d_bot>
<octachron> ```ocaml
<d_bot>
<octachron> type values_tag = Values_tag
<d_bot>
<octachron> type ('k,'tag) ret = Values: (values, values_tag) ret | ...
<d_bot>
<octachron> ```
<d_bot>
<rgrinberg> What about it this way:
<d_bot>
<rgrinberg> ```
<d_bot>
<rgrinberg> type values = Values of Sexp.t
<d_bot>
<rgrinberg>
<d_bot>
<rgrinberg> type fields = Fields of Fields.t
<d_bot>
<rgrinberg> ```
<d_bot>
<octachron> That also works.
<mrvn>
But that adds an extra indirection
Haudegen has quit [Quit: Bin weg.]
Haudegen has joined #ocaml
<octachron>
Not with [@@unboxed]
<mrvn>
newfangled things, be gone. :)
sagax has joined #ocaml
wonko7 has quit [Ping timeout: 272 seconds]
raver has quit [Read error: Connection reset by peer]
amiloradovsky1 has joined #ocaml
amiloradovsky has quit [Ping timeout: 258 seconds]
amiloradovsky1 is now known as amiloradovsky
jnavila has joined #ocaml
wonko7 has joined #ocaml
narimiran has quit [Ping timeout: 258 seconds]
vicfred has joined #ocaml
urek__ has quit [Quit: urek__]
shawnw__ has joined #ocaml
shawnw has quit [Ping timeout: 264 seconds]
vicfred has quit [Ping timeout: 258 seconds]
shawnw__ is now known as shawnw
vicfred has joined #ocaml
amiloradovsky has quit [Ping timeout: 258 seconds]
jnavila has quit [Quit: Konversation terminated!]
amiloradovsky has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
Serpent7776 has quit [Quit: leaving]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]