Leonidas changed the topic of #ocaml to: Discussion about the OCaml programming language | http://www.ocaml.org | OCaml 4.13.0 released: https://ocaml.org/releases/4.13.0.html | Try OCaml in your browser: https://try.ocamlpro.com | Public channel logs at https://libera.irclog.whitequark.org/ocaml/
olle has quit [Ping timeout: 256 seconds]
vicfred has quit [Quit: Leaving]
humasect has joined #ocaml
humasect has quit [Ping timeout: 250 seconds]
rgrinberg has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
hornhack has quit [Quit: Leaving]
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
Guest3959 has quit [Quit: QUIT]
epony has joined #ocaml
mbuf has joined #ocaml
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
ralu has quit [Ping timeout: 250 seconds]
gravicappa has joined #ocaml
waleee has quit [Ping timeout: 250 seconds]
sparogy has quit [Remote host closed the connection]
sparogy has joined #ocaml
Haudegen has joined #ocaml
humasect has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
gentauro has quit [Read error: Connection reset by peer]
shawnw has joined #ocaml
gentauro has joined #ocaml
shawnw has quit [Quit: Leaving]
humasect has quit [Ping timeout: 250 seconds]
Serpent7776 has joined #ocaml
Geekingfrog_ is now known as Geekingfrog
rgrinberg has quit [Ping timeout: 240 seconds]
JSharp has quit [*.net *.split]
Boarders_ has quit [*.net *.split]
Fardale has quit [*.net *.split]
cbarrett has quit [*.net *.split]
kurfen_ has quit [*.net *.split]
xgqt has quit [*.net *.split]
hackinghorn has quit [*.net *.split]
ouestbillie has quit [*.net *.split]
towel has quit [*.net *.split]
mmalter has quit [*.net *.split]
bgs has quit [*.net *.split]
andreypopp has quit [*.net *.split]
cross_ has quit [*.net *.split]
williewillus has quit [*.net *.split]
xenu has quit [*.net *.split]
afrosenpai has quit [*.net *.split]
kurfen_ has joined #ocaml
hackinghorn has joined #ocaml
xgqt has joined #ocaml
Boarders_ has joined #ocaml
ouestbillie has joined #ocaml
bgs has joined #ocaml
towel has joined #ocaml
andreypopp has joined #ocaml
williewillus has joined #ocaml
cross_ has joined #ocaml
afrosenpai has joined #ocaml
mmalter has joined #ocaml
xenu has joined #ocaml
JSharp has joined #ocaml
cbarrett has joined #ocaml
Fardale 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]
mro has joined #ocaml
perrierjouet has quit [Quit: WeeChat 3.4]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
wyrd has quit [Ping timeout: 276 seconds]
wyrd has joined #ocaml
bartholin has joined #ocaml
cedric has joined #ocaml
Tuplanolla has joined #ocaml
<dmbaturin> How do I create a compiler switch with spacetime enabled? `opam switch create 4.13.1+spacetime ocaml-variants.4.13.1+options ocaml-option-spacetime` doesn't do the trick, I get a "no solution found" error.
humasect has joined #ocaml
humasect has quit [Ping timeout: 250 seconds]
<d_bot> <undu> Didn't spacetime got dropped in favour of memprof?
<dmbaturin> Oh, hhm.
<dmbaturin> undu: Got a link to the memprof instructions?
Techcable has quit [Remote host closed the connection]
Techcable has joined #ocaml
perrierjouet has joined #ocaml
wyrd has quit [Remote host closed the connection]
<d_bot> <Butanium (@me on answer)> .native is .exe if I use dune right ?
olle has joined #ocaml
<d_bot> <bnguyenv> Yeah, `_build/default/foo.exe` even
wyrd has joined #ocaml
humasect has joined #ocaml
<d_bot> <Butanium (@me on answer)> ok thanks
<d_bot> <Boby> Should auxiliar function be declared inside the main function which call it or outside this main function ?
<d_bot> <Boby> I mean I understand the visibility of aux function will be inside the main function, but what is the more readable ?
<d_bot> <octachron> Yes. More seriously, it depends of the size of the auxiliary function and how much the auxiliary is really specific to the main function. Also I would avoid nesting recursive functions.
spip has joined #ocaml
bobo_ has quit [Ping timeout: 256 seconds]
<d_bot> <octachron> A small and specific auxiliary function should be defined inside the main function body.
<d_bot> <octachron> A not-so-small function that is kind of reusable in theory should be defined outside of the main function.
<d_bot> <Boby> Ok, I see
<d_bot> <Boby> Thanks
mro has joined #ocaml
<d_bot> <Boby> And is there a way to remove these parenthesis ?
mro has quit [Remote host closed the connection]
salkin has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
bartholin has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
<humasect> Boby: flip the last 2 args and use curry ?
<d_bot> <octachron> Why do you want to remove these parentheses, they seem perfectly fine to me?
perrierjouet has quit [Ping timeout: 240 seconds]
<d_bot> <Boby> I thought we could reduce the use of all parentheses in ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot> <bnguyenv> Well nested parentheses are visual noise and are hard to parse for the eye, but one or two levels are readable.
mro has quit [Remote host closed the connection]
bartholin has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
<d_bot> <octachron> You can define `let k_m_1 = k - 1 in ... ` but having some parentheses is not that bad.
perrierjouet has joined #ocaml
<d_bot> <VPhantom> I tend to do that (extract an expression into a binding to avoid nesting) only when it becomes unsightly. I personally don't see `(k-1)` as unsightly in that simple line.
olle has quit [Ping timeout: 240 seconds]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
kaph has joined #ocaml
bartholin has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
mg- has quit [Quit: WeeChat 3.2.1]
mg has joined #ocaml
humasect has quit [Quit: Leaving...]
humasect has joined #ocaml
humasect has quit [Client Quit]
humasect has joined #ocaml
qwr has quit [Remote host closed the connection]
Haudegen has quit [Quit: Bin weg.]
<ns12> Hello, how do I use SysV and POSIX semaphores and message queues from OCaml?
humasect has quit [Quit: Leaving...]
bartholin has quit [Ping timeout: 256 seconds]
olle has joined #ocaml
bartholin has joined #ocaml
Haudegen has joined #ocaml
mro has joined #ocaml
waleee has joined #ocaml
<companion_cube> maybe extunix has them? not sure
<companion_cube> Unix in the stdlib certainly doesn't
<ns12> companion_cube: I guess I would have to use Unix domain datagram sockets instead of message queues then.
<companion_cube> that should work
<ns12> But what about semaphores? What could I use instead of SysV and POSIX semaphores
<companion_cube> I'm not familiar with datagram though
<d_bot> <darrenldl> ns12: what are you doing?
<ns12> Mostly experimenting with IPC. To see what's available in OCaml. Nothing practical.
<d_bot> <darrenldl> just use socket as synchronisation primitive ( : D
<ns12> How? That's new to me.
<d_bot> <darrenldl> i mean you can always change shared memory schemes to message passing schemes (with possibly worse performance)
<d_bot> <darrenldl> (let me double check if unix socket can do that - thought it'd be weird to not be able to do that...
<companion_cube> that's not multiprocess I think
<d_bot> <darrenldl> also semaphore is...error prone to use...and lower level than most people's needs
<ns12> I should probably read APUE before trying more systems programming with OCaml ...
<d_bot> <darrenldl> i don't know if unix primitives are what you want in practice : D
<ns12> It'll mostly be for educational purposes.
<companion_cube> unix sockets should be enough then
<d_bot> <darrenldl> yeah, pretend it's channel (except i don't know how they segment data into datagram in unix socket)
humasect has joined #ocaml
bartholin has quit [Ping timeout: 240 seconds]
<olle> What's a "smallest composable part" in software design?
<humasect> i would like to say, a Word. or term; as it is linguistic
rgrinberg has joined #ocaml
bartholin has joined #ocaml
<olle> So a function? :) That was easy. ^^
<humasect> mathemtical :)
<olle> A pure dito, at least. But that's known.
<olle> A need a composability metric...
<humasect> depth/complexity
<olle> Wonder if "smallest composable part" would imply that monad thing Haskell does, what's it called again...
<olle> They make a DSL
<humasect> they functions tho really
<olle> ?
<humasect> bind, >>=, lift, etc
<Corbin> The smallest part of syntax is letters of the alphabet. The smallest part of semantics is functions (or whatever morphisms you're working with)
<olle> Corbin: Yeah, but only using functions leaves out nice OOP for code reuse
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<humasect> can be done with functions/closures, no problem
<Corbin> olle: Objects are just functions equipped with closures. But, also, functions are only one type of category; there are many other sorts of transformations between types.
<humasect> eg. modules
<olle> humasect: Not inheritance, you need the vtable and dynamic dispatch
<humasect> prototypes can do regular flat OO but regular cant do proto
bartholin has quit [Ping timeout: 256 seconds]
<d_bot> <mseri> @EduardoRFS do you know what could have caused this error: https://zerobin.net/?738a05d7b55833d7#FUJK3Iyryh3b5IfDwnM6ORDIWbanLOeSfh/RxCYykqA= ?
<Corbin> olle: Inheritance is just a special case of letrec. With functions, we can do something like `fun self super -> ...` and this lets us model (strict) objects with a self-reference and super-reference. Modelling lazy cooperative inheritance is a little trickier but should also be possible.
<olle> Corbin: Nothing is "just" something else :)
rgrinberg has joined #ocaml
<olle> Still, side-effect DSL is the tricky part, I think
<olle> Don't monads destroy composability, btw?
<Corbin> olle: Sure; "just" means "I believe it", and it's an old unhelpful part of English. Nonetheless, inheritance in e.g. C++ was originally modeled as explicit code in C; there's no reason why vtables and dynamic dispatch have to somehow be so builtin that they can't be accessed from user-level code.
<Corbin> No, each monad comes with its own category, and composition works fine within those categories.
<olle> Hm
<Corbin> We need functors if we want to cross from one category to another, but many languages have an implicit monad whose effects are spread throughout each program.
<olle> What other alternatives are there? I did command objects and yield/generator in PHP for this, worked pretty well in a small experiment.
<olle> "We adopt and argue the position of factoring an effectful program into a first-order effectful DSL with a rich, higher-order `macro' system."
<Corbin> I think that there's no alternative. Suppose we have an identity transformation and the ability to compose transformations associatively; then, we *definitionally* have a category of transformations. Studying composition naturally leads to category theory.
bartholin has joined #ocaml
gwizon has joined #ocaml
gwizon has quit [Client Quit]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<olle> Oh noe
<olle> I don't have time to learn that, I have to learn physiology -.-
<Corbin> olle: In Oleg's paper, look carefully at section 6. They're saying that the *syntax* of monadic expressions, particularly do-notation, is misleading in its scoping of effects. They're not talking about the underlying system of composition.
<Corbin> Similarly, when they talk about tagless-final encodings, it's worth remembering that "final" is the same as in "final object", or "terminal object" as we usually say in English. The corresponding monad typically provides the initial encoding, and there's an entire category of legal encodings!
<Corbin> And from basic abstract nonsense, we can always convert the initial encoding to the final encoding; we can always take a monadic tree of actions and run it on an evaluator.
<olle> Hm hm
<olle> So anyway, the human cell and its organells... ^^
<d_bot> <EduardoRFS> actually that's a weird one, maybe something got updated and now have a weird reference?
<d_bot> <EduardoRFS> can you send me a github?
<olle> Corbin: You know of any good effect DSL for traditional OOP langs? Or just list of command objects?
<olle> Traditional = Java, C#, ...
<olle> Maybe this is a better discussion in proglangdesign
<Corbin> olle: Look at the design of the Ruby language, I guess. There's a lot of possibilities beyond what's been mentioned so far.
<olle> Corbin: What to google for tho?
<olle> Wait, there's also "Free monad"
<olle> Ugh
mro has quit [Remote host closed the connection]
<Corbin> I asked for "ruby dsl design" and got a half-dozen decent tutorials and posts.
<olle> So three alternatives? Classic monad, tagless-final, and free monad?
<olle> Corbin: kk, checking, thanks
<Corbin> Those are all the same thing to me. I'm not sure how to explain it though.
<olle> ^^
bartholin has quit [Ping timeout: 250 seconds]
azimut_ has joined #ocaml
azimut has quit [Ping timeout: 276 seconds]
adanwan_ has quit [Remote host closed the connection]
adanwan has joined #ocaml
bartholin has joined #ocaml
mro has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
mbuf has quit [Quit: Leaving]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
<companion_cube> @Vphantom whyyyyyyy
bartholin has quit [Ping timeout: 256 seconds]
<d_bot> <VPhantom> @companion_cube Sorry I wasn't here this morning. What's going on? 🤨
<companion_cube> why do you upvote the wrong arguments on github :p
<d_bot> <VPhantom> Most of the ones I upvoted were yours, but one suggesting adding the missing reading functions in `Buffer` really appealed to me.
<d_bot> <VPhantom> I rolled my own buffer modules just like you so I feel your pain. Choosing between `byte` and `Buffer.t` has been a growing pain in my introduction to OCaml.
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot> <VPhantom> If we could read from buffers as easily as from bytes, we could easily make ourselves "slices" (like subs of bigarrays) and stop copying things around so much.
<companion_cube> you cannot add the missing functions
<companion_cube> it's not a fucking finite set
<d_bot> <VPhantom> Reading functions present in `Bytes` but not in `Buffer`.
<d_bot> <VPhantom> That is a finite list.
<d_bot> <orbitz> Passion over buffers runs deep
<d_bot> <VPhantom> I'm new to the OCaml community. I see it this way: if we're going to either get nothing because the stdlib is extremely conservative (which is fine), or at least get those "missing functions", then I vote for the missing functions.
<companion_cube> aynway, wrote another piece on that.
<companion_cube> it's not a finite list.
<d_bot> <VPhantom> Right now for example when I read a 32-bit integer from a buffer, I `Bytes.create 4`, then `Buffer.blit` to it, then `Butes.get_int32_be`.
<companion_cube> yes
<companion_cube> but if you use camlzip, and you want to read usign `bytes -> int -> bytes -> int -> int`
<companion_cube> you are fucked
<companion_cube> because that ain't going to be in the stdlib
<companion_cube> it's just like proposing to remove iter/fold and instead hardcode your uses for them
ns12 has quit [Quit: bye]
<d_bot> <VPhantom> Oh for sure, lots of APIs use `bytes`.
<companion_cube> bytes slice, actually, but in 3 separate arguments
<companion_cube> byte slices&
<companion_cube> and why can't we get byte slices from Buffer.t? hmm?
<d_bot> <VPhantom> If there was a `Buffer.unsafe_to_bytes` for specific uses, just like there is in `Bytes` and `String`, things could get interesting.
ns12 has joined #ocaml
<companion_cube> like, my PR?
<d_bot> <VPhantom> Yeah we'd need a guarantee that the underlying storage would be compatible with `bytes` in order to offer that.
<d_bot> <VPhantom> +forever
<d_bot> <VPhantom> Personally I have no problem with that, but apparently there's a future where it might change?
rgrinberg has joined #ocaml
<companion_cube> I think it's illusory
<d_bot> <VPhantom> (Oh crap I hadn't seen the signature in your PR. Yeah, _that_. 😛 )
<d_bot> <VPhantom> I'd still need to manage the notion of "reading position" on my own, but at least we could read any sections of buffers without blitting to bytes first.
<companion_cube> yep
<d_bot> <VPhantom> Yeah that… that needs to happen. Until then I use my own `bytes` based buffers instead of `Buffer`.
<companion_cube> yes
<d_bot> <VPhantom> My realloc strategy is certainly not as optimized as `Buffer`'s since it's pure OCaml.
<companion_cube> you could comment to say that :-°
<companion_cube> hmm isn't Buffer pure OCaml as well?
<d_bot> <VPhantom> Kinda feels like a superfluous `+1` but sure if it can help. 😃
<d_bot> <VPhantom> I thought it had C parts. Let me check again…
<companion_cube> ah, for fixed-size integer
<d_bot> <VPhantom> Oh you're right, it only has externals for setting ints.
Haudegen has joined #ocaml
<d_bot> <VPhantom> (Nice, their `resize` isn't that different from mine… Except that since I use windows (slices?), when I realloc I also remove the useless bytes at the head. That way my buffers can be used for concurrent reading and writing without growing indefinitely.)
salkin has quit [Quit: salkin]
salkin has joined #ocaml
olle has quit [Ping timeout: 256 seconds]
<d_bot> <VPhantom> Alright I abstracted away my impostor syndrome for a few minutes and commented.
<companion_cube> lol good mention of ocaml-protoc, since, well, it uses Buffer.t :D
<companion_cube> (have you seen my PR btw? :))
kaph has quit [Ping timeout: 256 seconds]
<d_bot> <VPhantom> Actually `ocaml-protoc` uses `Buffer.t` for writing but `bytes` for reading, AFAIK.
<companion_cube> yes
<d_bot> <VPhantom> And yes I finally looked at the actual diffs before submitting. 😉 Running on low sleep today so I'm not uhh… my concentration is abysmal. 😬
<companion_cube> ahah, there's a limit, I forgot
<companion_cube> it could be a buffer…
<d_bot> <VPhantom> It can read buffers? I didn't realize. (I haven't touched it in a month or so.)
<companion_cube> no, it can't
<companion_cube> but if we had access to a buffer's internals, then we could
<d_bot> <VPhantom> Yeah that's what I was trying to convey.
kaph has joined #ocaml
vicfred has joined #ocaml
humasect has quit [Remote host closed the connection]
<d_bot> <RegularSpatula> Yeah zero copy access to the buffer's bytes would be sweet...I was wanting something like this a little while back
jackhill has joined #ocaml
<companion_cube> don't hesitate to comment with your use case…
<companion_cube> I think long time users have learnt not to rely on Buffer.t for complex stuff, precisely because it's so limited
<companion_cube> so it's self reinforcing
<d_bot> <RegularSpatula> yeah I wish i still had a concrete example to give ...it was a little while back now and i ended up abandoning it fairly quickly as i couldn't get the bytes without copying
<d_bot> <RegularSpatula> some bioinformatics stuff...i like trying to get ocaml as a competitive choice for bioinfomatics
<d_bot> <RegularSpatula> when i read through the comments on the PR you did...i was expecting like, all sorts of changes to the Buffer module or something, but then looked at the actual changes and its literally just, "oh heres the underlying bytes"
<d_bot> <RegularSpatula> what's the likelihood that the underlying implementation of Buffer changes after all these years? i guess that's the argument some in that thread are making for not giving direct access?
<companion_cube> yeah, the likelihood is precisely 0.000
<d_bot> <RegularSpatula> lol i see
<companion_cube> (in my opinion — but really I can't imagine what it could change to)
olle has joined #ocaml
mro has joined #ocaml
<d_bot> <VPhantom> Since this function is tagged `unsafe`, would it be unreasonable to go for it now and potentially make it actually blit into fresh `bytes` if in some distant future the underlying implementation changes? Sounds like a win-win to me.
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
<companion_cube> going to end up being CCBytevec or whatever
Haudegen has joined #ocaml
<d_bot> <VPhantom> I called mine `Buf_bytes` 😉
<d_bot> <Butanium (@me on answer)> I just made a perf analysis for my program I didn't know `Sys.time()` call were that costly
<d_bot> <VPhantom> I just checked Core briefly and they seem to copy out of buffers.🤔 I'm surprised since this is kind of performance low-hanging fruit. Maybe they mostly use `bytes` directly in their own stuff.
<companion_cube> they probably use Async and bigstring stuff for their IOs
<d_bot> <VPhantom> True, but I remember reading recently about yminsky talking to someone about how `bytes` is better for the GC and to only use `bigstring` for I/O which truly needs it.
<companion_cube> sure, bytes can live in the minor heap, for a start
<companion_cube> bigstring is good for long lived buffers that need to be passed to C (because they won't move)
<companion_cube> in particular it's important for async IO, because you give a buffer to C and then you yield to another fiber/lwt/promise that can still allocate, call the GC, and move your buffer
<companion_cube> … unless the buffer is a immovable bigstring.
Anarchos has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
gravicappa has quit [Ping timeout: 240 seconds]
<d_bot> <VPhantom> Well, it was fun while it lasted. The OCaml 5 note on bytes is interesting. Above my pay grade though.
<companion_cube> it just makes an even stronger case, which is weird?
<companion_cube> it means bytes is even better for buffers… :/
<d_bot> <Et7f3> Where do you see it ? It should be a fast syscall with vdso
wyrd has quit [Ping timeout: 276 seconds]
<d_bot> <Butanium (@me on answer)> `caml_sys_time_include_children_unboxed`
<d_bot> <Butanium (@me on answer)> is 86% of time spent in the most called function
mro has quit [Ping timeout: 250 seconds]
Serpent7776 has quit [Quit: leaving]
oriba has joined #ocaml
rgrinberg has quit [Ping timeout: 240 seconds]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<d_bot> <Et7f3> Is it cumulative time
<d_bot> <joris> @companion_cube fwiw I totally agree that buffer is only half useful without access to internal, and I totally agree cstruct is a the wrong answer
<d_bot> <joris> And I always end up either using lwt or coding my own too
<d_bot> <joris> Cstruct is good for c binding and for low allocation rate, but low allocation rate means super smart code
<d_bot> <joris> I don't like smart code, I don't like having to deal with buffer cache or stuff like this
<companion_cube> @joris btw i need to pick your brain about CCVector, if you still use it
<d_bot> <Butanium (@me on answer)> My code is 5 times faster with less Sys.time() and replaced by Unix
<d_bot> <joris> Ah yes I didn't use it recently because I had bad memory about it but yes can discuss
<d_bot> <Et7f3> A fast function used multiple time will take a big amount of time
<d_bot> <joris> There are various way to get time in Linux from getimeofday to clock_gettime to instruction with various level of performance and precision
<d_bot> <joris> I kind of remember Unix implementation being changed.
<d_bot> <joris> I don't know what it is currently but last time I checked non of the standard way to get time in ocaml allowed to get low precision time counter for profiling you had to use custom bindings. That might have changed now. I
<companion_cube> You could use mtime or ptime
<companion_cube> Forget which is the right one for that
<companion_cube> @joris re-reading the code it seems that the growth policy is a bit high, I'm thinking of decreasing it to x1.5 ish
<d_bot> <undu> to measure spans you want mtime (m is for monotonic)
azimut_ has quit [Remote host closed the connection]
azimut has joined #ocaml
<d_bot> <Anurag> a growth factor of 1.5 is what i've also seen in some C++ stdlib alternatives (the vector implementation in facebook's folly library uses 1.5 for example)
azimut_ has joined #ocaml
<companion_cube> Yeah, there's less waste
<companion_cube> I tend to use x1.5 + c with c a
<companion_cube> Small constant
rgrinberg has joined #ocaml
<companion_cube> Deals with the initial case
azimut has quit [Ping timeout: 276 seconds]
<d_bot> <mseri> Sorry, I can no longer do it. Re-running the job made it disappear. I got a couple of random cache failures in other jobs. Maybe it is related from what you say
<d_bot> <mseri> Why not 1.618? Can’t remember where, but I remember it popping up on some paper on optimality of array growth in c++, making a pun with the golden mean. I’ll link it tomorrow if ai can find it
<companion_cube> :D seems weirdly specific but well
bobo_ has joined #ocaml
spip has quit [Ping timeout: 256 seconds]
cedric has quit [Quit: Konversation terminated!]
wyrd has joined #ocaml
Haudegen has quit [Ping timeout: 256 seconds]
ouestbillie has quit [Quit: leaving]