silver has quit [Read error: Connection reset by peer]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kakadu has quit [Remote host closed the connection]
kvda has joined #ocaml
spew has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
shinnya has quit [Ping timeout: 256 seconds]
zolk3ri has quit [Quit: Lost terminal]
kvda has joined #ocaml
kleimkuhler has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kvda has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kvda has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
granttrec has joined #ocaml
kvda has joined #ocaml
<granttrec>
is there nything like this for http://mappedbus.io/ for ocaml? if not i'd like to work on it as a project and wondering if anyone would care to mentor
<granttrec>
Bluddy[m]: not quite what I want, this library makes it really simple for ipc, at least in java, so I was hoping I could make this experience for others
shinnya has joined #ocaml
spew has joined #ocaml
<granttrec>
ahh MPI looks interesting tho, ill play around with that
<discord3>
<Bluddy> yeah i'm not saying it exists, just that there's stuff that's somewhat similar
<discord3>
<Bluddy> to see what's there
pierpa has quit [Quit: Page closed]
spew has quit [Read error: Connection reset by peer]
isd has quit [Remote host closed the connection]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cbot has joined #ocaml
yomimono has quit [Ping timeout: 264 seconds]
shinnya has quit [Ping timeout: 260 seconds]
keep_learning has quit [Remote host closed the connection]
Fare has joined #ocaml
kvda has joined #ocaml
pierpal has quit [Quit: Poof]
pierpal has joined #ocaml
jimmyrcom has quit [Ping timeout: 264 seconds]
jao has quit [Ping timeout: 260 seconds]
grandy______ has quit []
c4rc4s has quit [Ping timeout: 260 seconds]
Guest46527 has quit [Ping timeout: 260 seconds]
SegFaultAX has quit [Ping timeout: 276 seconds]
TC01 has quit [Ping timeout: 260 seconds]
gsingh93_ has quit [Quit: Connection closed for inactivity]
granttrec has quit [Quit: granttrec]
TC01 has joined #ocaml
zv has quit [Quit: WeeChat 1.9]
<kvda>
is RWOcaml still a recommended way to get into Ocaml?
<discord3>
<Christophe> I'd say yes, but look at the development version ( dev.realworldocaml.org)
Fare has quit [Ping timeout: 248 seconds]
cbot has quit [Quit: Leaving]
<discord3>
<mars0i> Or if you want something easier, OCaml from the very beginning. RWO seems to be suitable for a lot of people, though.
<kvda>
Thank you
MercurialAlchemi has joined #ocaml
kleimkuhler has quit [Quit: kleimkuhler]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mbuf has joined #ocaml
tarptaeya has joined #ocaml
ratschance has quit [Remote host closed the connection]
ratschance has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
mbuf has quit [Remote host closed the connection]
Haudegen has joined #ocaml
mbuf has joined #ocaml
robmyers has quit [Ping timeout: 256 seconds]
terrorjack has quit [Read error: Connection reset by peer]
robmyers has joined #ocaml
robmyers has quit [Max SendQ exceeded]
vodkaInf1rno has joined #ocaml
Robdor has quit [Quit: Ping timeout (120 seconds)]
Robdor has joined #ocaml
vodkaInferno has quit [Ping timeout: 264 seconds]
c4rc4s has joined #ocaml
robmyers has joined #ocaml
robmyers has quit [Max SendQ exceeded]
robmyers has joined #ocaml
terrorjack has joined #ocaml
ozzymcduff has joined #ocaml
jaar_ has joined #ocaml
kvda has joined #ocaml
freyr has joined #ocaml
argent_smith has joined #ocaml
argent_smith1 has joined #ocaml
steenuil has joined #ocaml
argent_smith has quit [Ping timeout: 276 seconds]
ozzymcduff has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dhil has joined #ocaml
ziyourenxiang has joined #ocaml
jnavila has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
kvda has joined #ocaml
kvda has quit [Client Quit]
wildsebastian has joined #ocaml
mbuf has quit [Ping timeout: 245 seconds]
mbuf has joined #ocaml
zv has joined #ocaml
kvda has joined #ocaml
zv has quit [Quit: WeeChat 2.0.1]
gtrak has quit [Ping timeout: 264 seconds]
gtrak has joined #ocaml
zolk3ri has joined #ocaml
ozzymcduff has joined #ocaml
jnavila has quit [Ping timeout: 256 seconds]
mfp has joined #ocaml
malina has joined #ocaml
dhil has quit [Ping timeout: 245 seconds]
dhil has joined #ocaml
mk9 has joined #ocaml
mk9 has quit [Ping timeout: 264 seconds]
ozzymcduff has quit [Ping timeout: 240 seconds]
kakadu has joined #ocaml
ousado has joined #ocaml
alphor has quit [Ping timeout: 256 seconds]
alphor has joined #ocaml
dhil has quit [Ping timeout: 248 seconds]
jao has joined #ocaml
dhil has joined #ocaml
jnavila has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kvda has joined #ocaml
malina has quit [Ping timeout: 256 seconds]
dhil has quit [Ping timeout: 245 seconds]
Haudegen has quit [Remote host closed the connection]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
donnie_2 has left #ocaml ["Leaving"]
dhil has joined #ocaml
silver has joined #ocaml
webshinra has quit [Remote host closed the connection]
mbuf has quit [Quit: Leaving]
webshinra has joined #ocaml
spew has joined #ocaml
Haudegen has joined #ocaml
<discord3>
<Bluddy> RWO is very well written. The only caveat is that you're learning just one side of the ecosystem -- the Jane Street side. It's a good side, but not necessarily the most commonly used.
aciniglio has joined #ocaml
<ZirconiumX>
Bluddy: I think a combination of Core and Lwt probably solves most issues reasonably well. I haven't really looked at Async though
<discord3>
<Bluddy> Probably. The other modern approach I like is Containers + BOS + Lwt
<Fardale>
What is BOS ?
<discord3>
<Bluddy> dbuenzli's OS interaction library. It's basically a rewrite of the IO functions you need. Add that to Containers, which is an stdlib supplement function-wise and data structure-wise, and you're pretty much covered.
jaar_ has quit [Remote host closed the connection]
jaar_ has joined #ocaml
mbuf has joined #ocaml
aciniglio has quit [Read error: Connection reset by peer]
_andre has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 260 seconds]
aciniglio has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
twopoint718 has joined #ocaml
freyr has quit [Remote host closed the connection]
dhil has quit [Ping timeout: 256 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #ocaml
jimmyrcom has joined #ocaml
sz0 has joined #ocaml
Haudegen has quit [Remote host closed the connection]
mbuf has quit [Quit: Leaving]
gtrak has joined #ocaml
Guest98033 has joined #ocaml
FreeBirdLjj has joined #ocaml
ygrek has joined #ocaml
gtrak has quit [Ping timeout: 268 seconds]
aciniglio has quit [Read error: Connection reset by peer]
Guest98033 is now known as Haudegen
pierpal has quit [Quit: Poof]
pierpal has joined #ocaml
gtrak has joined #ocaml
kleimkuhler has joined #ocaml
yomimono has joined #ocaml
jbrown has joined #ocaml
noitakomentaja has joined #ocaml
<discord3>
<mseri> I like Containers + BOS + Lwt! But I think that the new RWO will push Base, that is not that bad, and is much lighter than Core
<companion_cube>
and… is still incompatible with the stdlib :/
<discord3>
<mseri> indeed
<discord3>
<mseri> I think the StdLib is not that far away: if your PRs for safe IO are accepted, and hopefully one with finally/bracket/whatevernameforit, then practically it will be missing some combinators for options/result/list and Astring
<discord3>
<mseri> the rest is more or less there
<discord3>
<mseri> (I am assuming that @companion_cube == GitHub's c-cube here)
<companion_cube>
and you're right :-)
<discord3>
<mseri> 😛
kleimkuhler has quit [Quit: kleimkuhler]
zv has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
freyr has joined #ocaml
deividas has joined #ocaml
<deividas>
does anyone really use objects in ocaml?
<theblatte>
yes
<deividas>
why not only structs and functions?
<freyr>
How is it so that mlton could keep so much types unboxed, even without this GC bit trick? Why didn't ocaml people apply the same strategy?
sz0 has quit [Quit: Connection closed for inactivity]
<discord3>
<Bluddy> freyr: mlton uses whole-program compilation ie. it's not modular. This means compilation is generally slow and doesn't scale very well. Once you can see the whole program ie. every single usage of every variable etc, you can make more powerful optimizations. The principle behind flambda is applying 'whole program' a few small bits a time via inlining.
zv has quit [Ping timeout: 240 seconds]
isd has joined #ocaml
<theblatte>
deividas: sometimes you actually want inheritance (I don't use objects, but I know that some projects do)
jaar_ has quit [Ping timeout: 245 seconds]
<deividas>
meh... I find composing structs within structs work better
<freyr>
I see, thanks. But if ocaml does not have native arrays, does it mean GC scans and marks all objects in my array?
<discord3>
<Bluddy> what do you mean by native arrays? C-style arrays?
<freyr>
Arrays of unboxed values I meant.
<freyr>
Like new Floatarray
<octachron>
deividas, open recursion works better with objects. Similarly, if you are reimplementing objects with record of functions all taking a self argument, there is no reason to not use objects directly
<deividas>
closest thing I have to an object are structs whose fields are functions which may alter the state of other fields in a struct, everything's public though, but I wouldn't have it any other way
<companion_cube>
freyr: I think floatarrays are special enough that the GC knows about them
<companion_cube>
similarly for bigarrays
<freyr>
Yeah, but there are no int32arrays, int64arrays etc
<companion_cube>
they wouldn't be unboxed anyway… :/
<companion_cube>
there are bigarrays of int32/int64 tho
<freyr>
Are there enough tags for them or should any numeric code use bigarrays?
<freyr>
tags for specialization like in case of float array, I mean
<companion_cube>
if you're serious about numeric code, I think you'll use bigarrays anyway
<companion_cube>
they interface properly with C and most numerical bindings (e.g. lapack) are based on them
<freyr>
I see, I just tried mlton and was quite astonished by what could it do in that field.
<deividas>
I've never heard about mlton, why its so special? Is it better than ocaml?
<freyr>
It's one of the SML compilers.
<discord3>
<Bluddy> yeah if you give up on modularity you get a lot of power in return
<discord3>
<Bluddy> many of the most advanced analysis systems only work well when you can see the whole program
<steenuil>
those compile times though
<steenuil>
the last time I tried to compile something with MLton it took about 20 minutes and my computer was unusable for most of that time
<freyr>
It's a really strange that so much is invested in sml compilers (mlton, multimlton, sml#, cakeml), whilst the language inself is so dead.
<discord3>
<Bluddy> yeah there's no guarantee you won't run out of memory
zv has joined #ocaml
<steenuil>
I guess it's a better language to write an independent compiler for precisely because it's dead
<companion_cube>
:D
<companion_cube>
dead, but standardized!
<steenuil>
exactly
<companion_cube>
not sure if SML+MLton is more convenient than rust, if you really want perfs
<freyr>
Rust is a pain
<deividas>
ocaml is easy compared to rust
<freyr>
Although linear types are good
<discord3>
<Bluddy> Rust has the extra cognitive overhead of linear types
<deividas>
I tried to write some stuff at work but I find I was pulling my hair fighting the ownership stuff
<steenuil>
MLton is usually recommended for a "production" build since it takes so long to compile anything
<discord3>
<Bluddy> It's debatable whether the cognitive overhead of C++ is greater than Rust
<discord3>
<mseri> To be honest you get used to it quite fast
<companion_cube>
I heard that after a while, rust is not that painful
<spew>
after you develop stockholm syndrome you mean
<deividas>
I guess you need to code it everyday to get used to it, but my first time ocaml experience was very pleasant compared to rust
<deividas>
<companion_cube>
Bluddy: to me C++ has an incredible overhead because 1/ it's really not intuitive after years of OCaml 2/ I'm afraid of footguns
<discord3>
<mseri> You just have to rethink a bit the way you structure your program. And the pain you feel is mostly lack of Gc. If you start cloning everything it gets quite easy (but at that point you might as well use ocaml)
<freyr>
Well, it least rust does prohibit you to shoot your head of
<freyr>
C++ is beyoung evil
<freyr>
*beyond
<companion_cube>
exactly
<discord3>
<mseri> Rust is easier that C++ because of that and because of the lack of legacy syntaxp and compromises
<companion_cube>
and enums!!
<companion_cube>
and HO stuff, and usable iterators…
<discord3>
<mseri> God yes
<spew>
comparing something to the worst thing ever is not a good argument
<companion_cube>
spew: it is if the worst thing ever is the main contender to the something
<discord3>
<mseri> If you wanted more complex types, until ‘impl Traits’ (and dyn Traits soon ) the errors were as unreadable as C++ templates :’-D
<discord3>
<mseri> It got way better recently
<freyr>
If only ocaml had as much attention as rust or go
<steenuil>
I haven't used Rust a lot, but honestly the thing I found most confusing was the hierarchy of types
<discord3>
<mseri> What about it?
<freyr>
It is absent?
<steenuil>
maybe that's not the best way to word it
<freyr>
Lack of classes and objects?
<companion_cube>
freyr: it would still not be as powerful
<discord3>
<mseri> It is not higher kinded if that is what you mean
<steenuil>
no, I mean that there's tons of these traits to keep track of and navigating the docs felt pretty confusing
<steenuil>
it felt like using Haskell
<discord3>
<mseri> Yes that is true
<discord3>
<mseri> But it is kind of the same idea
<steenuil>
yeah
<discord3>
<mseri> And you mostly use always the same traits so you get used to it fairly soon
<companion_cube>
otoh you can write `a+b` for sevwral different types, yay
<freyr>
While all my rust code concerns gstreamer and gobjects, I didn't manage to get used to this awkward object and inheritance emulation via traits
<companion_cube>
> gobject :/
<freyr>
Yeah, til you have some huge hierarchy
<discord3>
<mseri> @steenuik Ipersonally like that. I miss modular implicits in ocaml
<discord3>
<mseri> Freyr I am not sure if the fact that there you have to match gobjects complicates the matter further
<discord3>
<mseri> I have never used it
<steenuil>
I dunno, I like it in theory but in practice it's confusing
<freyr>
I'm pretty sure any object system would be interfaced in the same way in rust, don't think that rust-qt is much different
<steenuil>
I hope that whatever comes out of modular implicits will manage to strike a good balance
<companion_cube>
yeah, but don't hold your breath
<gonz_>
In the year 2030
<freyr>
The year of OCaml on desktop
<steenuil>
eventually, yes
zolk3ri has quit [Quit: Lost terminal]
<companion_cube>
freyr: interfacing with such weird things is bound to be ugly anyway
<freyr>
I find gobject nice
<freyr>
But maybe I'm just a pervert
<companion_cube>
isn't it this whole weird dynamic object system? :s
<companion_cube>
in… C ?
<steenuil>
it's hella weird
<freyr>
Aren't objects dynamic by their nature?
<companion_cube>
given how little I use objects in OCaml, I'm confident I wouldn't miss them in rust
<companion_cube>
no, they can be typed properly…
<freyr>
No in the sense of static types
<freyr>
more in the sense of dynamic dispatching
<companion_cube>
that's a different matter, and rust has trait objects for that
<freyr>
they are just structures + functions without it
<companion_cube>
-> I'd rather stay as far away from it as possible
<freyr>
It's inspired by something like clos or smalltalk, I suppose
<discord3>
<mseri> Freyr I have not used that either so I don’t know but I didn’t Maine using qt in the past, it was reasonable for a gui framework
<discord3>
<mseri> mind* — my mobile spell checker is getting drunk
<freyr>
It's very useful sometimes, to have such a dynamic dispatch out of the box, when you want to build something pluggable and adhoc variable, like gstreamer or actors
<companion_cube>
now I suspect freyr is secretly a python fan
<companion_cube>
show your true nature!! :o
<steenuil>
yes, but... in C?
<companion_cube>
secretly you know you always dreamt of being a void*
<freyr>
Stable and standard ABI
<freyr>
Python is an abomination, it is worse than anything (safe C++)
<freyr>
I mean
<freyr>
We have so much gui in ocaml using GTK
<freyr>
coqide, frama-c
<freyr>
and no qt
<freyr>
for some reason ;)
tane has joined #ocaml
<companion_cube>
if you start using popularity arguments, you'll soon argue that JS is the best frontend :/
dhil has joined #ocaml
<discord3>
<mseri> Freyr isn’t that because C is easier to interface than C++?
<freyr>
I mean, gobject was built with an intention to be used with other languages
<discord3>
<mseri> How are tk bindings for ocaml?
<freyr>
While for qt people nothing but python and c++ exist
<discord3>
<mseri> I see what you mean
<freyr>
Well, js was inspired by scheme, so it has a good something in it's core
<freyr>
deep
<discord3>
<mseri> :’-D
<steenuil>
at least it has closures!
<discord3>
<mseri> It can be very functional but it’s not enough to by my affection
<discord3>
<mseri> And as a dynamic language I enjoy much more using racket or python
<discord3>
<mseri> (But then they don’t run in the browser -.-)
<freyr>
What's good with python?
<steenuil>
it's bundled in pretty much every linux distro, and I think that's it
<discord3>
<mseri> Fast prototypes. As a glue I often prefer it to bash
<steenuil>
oh, it's also better than shell
<discord3>
<mseri> And for numerical stuff, until owl, there wasn’t much else
<companion_cube>
there are some lapack bindings
<freyr>
So unpredictable though, like a bunch of ad hoc features which guido like, awkwardly tied together
<discord3>
<mseri> And owl is still quite limited in that respect. I hope I’ll be able to do something there soon
<steenuil>
yeah, Guido is not exactly a great language designer
<discord3>
<mseri> Yes but it is a running pseudo code with an unbelievably complete standard library hat you will find in almost every machine
<freyr>
OCaml is so unsuitable for numeric code
<discord3>
<mseri> And you can use it on Mac windows and Linux
<discord3>
<Bluddy> freyr: it's no less suitable than python
<discord3>
<Bluddy> with Owl, you get pytorch and numpy in one
<freyr>
Yeah, but python is already there
<discord3>
<mseri> Freyr I think is more about writing a higher level wrapper that delegates the nasty bits for you imho. At that point could be a decent option
<discord3>
<Bluddy> the point is, you don't need your language to be amazing at handling vectorization and such if you have a good FFI and library
<companion_cube>
maybe julia is better than python
<discord3>
<mseri> Yes it is going to be an insane amount of work with owl but is not inpossible
<discord3>
<mseri> Impossible*
<freyr>
slap waы штеукуыештп
<freyr>
slap was interesting*
<discord3>
<mseri> Look at Julia. They are improving at the speed of light
<freyr>
OCaml't type system is really lacking here
<companion_cube>
yeah, agreed
<freyr>
and the absence of value types
<companion_cube>
traits/typeclasses are really needed if you want to make numerical stuff convenient
noitakomentaja has quit [Ping timeout: 250 seconds]
<discord3>
<mseri> I think owl is not far away to be able to attract critical mass. It needs arbitrary precision, ode/pde integrators and more special functions
<freyr>
At least you want to have a numbers as types
<discord3>
<mseri> And better plot integration in jupyter
<discord3>
<mseri> Companion_cube as much as I agree, I think having the right functors can mitigate the pain
<freyr>
Even C++ could do it with it's awkward templates
<discord3>
<mseri> It is going to be an interesting trade-off to find
<freyr>
companion_cube: why do I need typeclasses?
<discord3>
<mseri> Freyr true 😦
<freyr>
Actually, I don's
<freyr>
don't
noitakomentaja has joined #ocaml
<freyr>
Even Haskell wiki says not to use them ;)
<discord3>
<mseri> No but then you have to deal with multiple operators names and with lots of functors
<discord3>
<Bluddy> For what?
<discord3>
<mseri> Not saying it is a problem. But you have to get used to it
<discord3>
<Bluddy> Usually you're dealing with only one kind of number
<freyr>
Time to switch to F* I think, it could do some pretty cool stuff
<discord3>
<mseri> Say you are implementing numerical integrators. Your tables will likely be rational to deal with good precision with different numerical types and will have to be specialised to the numbers you use and then use the right operators for everythib
<discord3>
<mseri> This could happen semi automatically or it could happen using functors
<discord3>
<Bluddy> I guess I know the machine learning side more. You really stick with one or two numeric types.
<discord3>
<mseri> There are simulations in which you can start with floats or doubles and suddenly you need mpmath or BigFloat 😦 or maybe complex numbers for a change
<discord3>
<mseri> It’s not that you have many but the implementato has to work with the various combinations (if it makes sense for it to)
<discord3>
<mseri> You can look at the discussions on the Julia differential equations packages to get an idea
<discord3>
<Bluddy> I think this is something all static languages will have difficulty with.
<discord3>
<Bluddy> Dynamic languages can examine the number and just decide to switch representation
<freyr>
But modules are enough for dealing with a couple of numeric types at once, not a big deal
<discord3>
<Bluddy> This is similar to the way that JITed static languages like Java have the advantage of dynamically examining the hardware and adjusting instructions used.
<discord3>
<Bluddy> Or compiling hot paths differently
<discord3>
<mseri> You can do it in rust at compile time. And also in ocaml@with functors
<discord3>
<mseri> And some casting here and there :-s
<discord3>
<Bluddy> OK you're talking about when you statically know when the switch needs to be made.
<discord3>
<mseri> Yes. If I have to do it in a statically typed language I would try to leave the choice to the user and have the library to be generic
<discord3>
<mseri> It would heavily rely on the compiler doing the right thing and the right inlining and optimisations though
<discord3>
<mseri> From that point of view it is easier for python and Julia
<discord3>
<mseri> As you were saying
<freyr>
Speaking of inlining how far the new flambda is from mainlining?
<octachron>
Far away
<theblatte>
hmm, Caml.Unix.kill is not in Core.Unix?
<rks`>
have a look in sys perhaps?
<theblatte>
can't find it there either
<rks`>
weird
<rks`>
there is a signal submodule somewhere, pretty dure
<rks`>
sure*
<theblatte>
grep -R 'Unix.kill' doesn't return anything on core or core_kernel (from `opam source`)
FreeBirdLjj has quit [Remote host closed the connection]
jimt has quit [Ping timeout: 248 seconds]
Fare has joined #ocaml
FareTower has joined #ocaml
Fare has quit [Ping timeout: 268 seconds]
dtornabene has joined #ocaml
kakadu has quit [Quit: Konversation terminated!]
parcs has joined #ocaml
Anarchos has joined #ocaml
dhil has quit [Ping timeout: 268 seconds]
dtornabene has quit [Ping timeout: 264 seconds]
mk9 has joined #ocaml
yomimono has quit [Ping timeout: 276 seconds]
tarptaeya has quit [Quit: Konversation terminated!]
steenuil has quit [Remote host closed the connection]
FareTower has quit [Ping timeout: 264 seconds]
yomimono has joined #ocaml
philtor has joined #ocaml
jack5638 has quit [Ping timeout: 245 seconds]
cbot has joined #ocaml
jack5638 has joined #ocaml
pierpal has quit [Quit: Poof]
pierpal has joined #ocaml
mk9 has quit [Quit: mk9]
jao has quit [Ping timeout: 255 seconds]
dedgrant has quit [Ping timeout: 260 seconds]
malina has joined #ocaml
ocabot_ has joined #ocaml
weird_error has joined #ocaml
malina has quit [Ping timeout: 264 seconds]
deividas has quit [Remote host closed the connection]
dedgrant has joined #ocaml
pierpal has quit [Quit: Poof]
pierpal has joined #ocaml
pierpal has quit [Client Quit]
pierpal has joined #ocaml
groovy2shoes has quit [Ping timeout: 260 seconds]
kakadu has joined #ocaml
groovy2shoes has joined #ocaml
pierpa has joined #ocaml
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
spew has quit []
gtrak has quit [Ping timeout: 260 seconds]
gtrak has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
soupladler has joined #ocaml
neatonk has quit [Ping timeout: 260 seconds]
jnavila has quit [Remote host closed the connection]
tane has quit [Quit: Leaving]
argent_smith1 has quit [Quit: Leaving.]
Haudegen has quit [Remote host closed the connection]
Anarchos has quit [Quit: Vision[0.10.2]: i've been blurred!]
twopoint718 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<steelbrain>
In the `main` part of the switch, how do I make so it so it won't overwrite if it's already been set with `flow:main`
<steelbrain>
This is my first time working with OCaml (need this for quick patch), so please be kind
<octachron>
you can match on both the key and package with 'match key, package with | ("main"|"flow:main"), { main = None; _ } -> ...'
freyr has quit [Remote host closed the connection]
<steelbrain>
@octachron Unfortunately the order keeps changing
<steelbrain>
We want to use "flow:main" if both are available
<steelbrain>
and package.json contents can vary from one package to another
groovy2shoes has quit [Ping timeout: 255 seconds]
gtrak has quit [Ping timeout: 260 seconds]
<octachron>
ok, so you have a list of key where both main and flow:main can appear, and only "flux:main" keys can overwrite entry set up with "main". Did I get your problem right?
<steelbrain>
Yes that is correct
gtrak has joined #ocaml
groovy2shoes has joined #ocaml
aidalgol has joined #ocaml
<octachron>
Then, you could add a priority value to the main record field: "type priority = Top | Bottom" and "type package = {main: (priority * 'a) option; .. }"
malina has joined #ocaml
<octachron>
and now you can assign the Top priority to "flow:main", and the Bottom one to "main", and only overwrite if the new priority is higher than the lower one
<steelbrain>
That sounds like a good idea, just a sec, I'll show you what I had in mind
<octachron>
If you cannot change the definition of the record, another solution is to keep the priority status of main as a complementary data in the fold/loop
<steelbrain>
Don't know the OCaml syntax but if we do it like this
<steelbrain>
It'll solve the issue without adding a seperate type or record, because `flow:main` would write regardless and `main` would not write unless it's not written
<steelbrain>
It'll work regardless of order of input, now if I only knew how to translate this in OCAML syntax :)
<octachron>
true, it works too; it is just a matter on adapting my pattern matching above: "match key, package -> "main", {main = None} -> ..."
<steelbrain>
Thank You
<steelbrain>
Gonna try
<octachron>
or you can just add a nested pattern matching ' "main" -> (match package.main with None -> { package with main = value } | Some _ -> package )'
<steelbrain>
That worked perfectly. Thank you for your kindess
<discord3>
<mseri> Also "flow:main" when package.main = None -> { package with main = Some value }
<steelbrain>
Thank you too @mseri! You are all very helpful
jao has joined #ocaml
Human has joined #ocaml
Human is now known as Guest95074
steelbrain has quit []
Guest95074 has quit [Client Quit]
ygrek has joined #ocaml
kvda has joined #ocaml
<aidalgol>
Is ReactiveML on-topic here?
ygrek has quit [Ping timeout: 245 seconds]
soupladler has quit [Ping timeout: 240 seconds]
steenuil has joined #ocaml
cbot has quit [Ping timeout: 256 seconds]
jbrown has quit [Ping timeout: 264 seconds]
silver has quit [Read error: Connection reset by peer]