The_third_man has quit [Ping timeout: 265 seconds]
siddharthv_away has quit [Ping timeout: 265 seconds]
dmbaturin has quit [Ping timeout: 265 seconds]
cow-orker has quit [Ping timeout: 265 seconds]
pleiosaur has quit [Ping timeout: 265 seconds]
mcclurmc has quit [Ping timeout: 256 seconds]
gasche has quit [Ping timeout: 256 seconds]
jbrown has quit [Ping timeout: 256 seconds]
SHODAN has quit [Ping timeout: 256 seconds]
Cypi has quit [Ping timeout: 256 seconds]
dmbaturin has joined #ocaml
siddharthv_away has joined #ocaml
haesbaert has joined #ocaml
cow-orker has joined #ocaml
pleiosaur has joined #ocaml
Cypi has joined #ocaml
gasche has joined #ocaml
sqweek has joined #ocaml
ohama has joined #ocaml
tane has joined #ocaml
SHODAN has joined #ocaml
tizoc has joined #ocaml
thomasga has joined #ocaml
iZsh has joined #ocaml
The_third_man has joined #ocaml
obadz has quit [Ping timeout: 240 seconds]
obadz has joined #ocaml
low-profile has joined #ocaml
jbrown has joined #ocaml
matason has joined #ocaml
yomimono has joined #ocaml
Simn has joined #ocaml
octachron has joined #ocaml
arquebus has joined #ocaml
sailorswift has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mort___ has joined #ocaml
Haudegen has quit [Ping timeout: 246 seconds]
darkf_ has joined #ocaml
darkf has quit [Ping timeout: 246 seconds]
tane has quit [Remote host closed the connection]
tane has joined #ocaml
Haudegen has joined #ocaml
obadz has quit [Remote host closed the connection]
obadz has joined #ocaml
nullcatxxx_ has joined #ocaml
BitPuffin|osx has quit [Ping timeout: 240 seconds]
arquebus has quit [Quit: konversation disconnects]
antkong_ has quit [Quit: antkong_]
mcorbin has joined #ocaml
nullcatxxx_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<gasche>
mfp: I'm surprised by the use of Format.sprintf instead of Printf.sprintf in the ocsigen_server code touched by your PR
<gasche>
I would assume Printf.sprintf to give a moderate performance boost on very short answers, but then it is probably noise in the general Lwt overhead
jabesed has joined #ocaml
<mfp>
It was a "%x\n" or something like that for chunked responses, right? I noticed it but guessed it would hardly make a difference
<mfp>
but s/Format/Printf/ certainly wouldn't hurt :)
<gasche>
(it would actually be nicer to have a more general Printf printer that is parametrized over the output functions, to directly interpret the formats in term of Lwt_io primitives)
<mfp>
uhm there are actually many more instances, including one for printing the cookies
thomasga has quit [Quit: Leaving.]
<gasche>
unrelatedly, Lwt_bytes has its own code to read/write int{16,32,64} integers, which could be replaced by caml_get_ba_int8_{get,set}{16,32,64} compiler primitives
KDr2 has quit [Ping timeout: 260 seconds]
<mfp>
those are >= 4.01, right?
<mfp>
There's ocplib-endian which provides fallback code at compile-time for older compilers, Lwt should build on that. I'll file an issue.
<ollehar>
Although I don't understand much of that paper.
<ollehar>
"Garbage Collection Based on a Linear Type System"
<mrvn>
Sounds like they are fixing the wrong problem.
<ollehar>
what do you mean?
<mrvn>
"if the memory space for used linear values is still reachable through pointers, dangling pointers are created."
<mrvn>
I thought the point of linear type systems was that you know how long the value is in use and that there can't be any pointers to the value once they aren't.
<ollehar>
yeah, I don't get that.
<mrvn>
In rust you have 2 kinds of objects. Static managed objects on the stack with known lifetime and reference counted / GCed objects on the heap with unknown lifetimes.
<ollehar>
mrvn: I thought Rust had no GC?
<ollehar>
instead, you pass ownership
<ollehar>
which is responsibility to free.
<mrvn>
That's for the statically managed objects.
<flux>
I only find references that Rust might have GC implemented in the future.. ?
<mrvn>
There might be statically managed objects on the heap too where you pass the ownership out of the scope.
<mrvn>
flux: yeah, currently it only has reference counted. But a future GC is planed in the design.
<flux>
so it doesn't have tracing GC which people usually mean with GC
<mrvn>
not yet at least
<mrvn>
The point was that it has 2 distinct types of objects. The GC would only trace the second kind and they can't mix.
<flux>
they can mix in one direction, but not the other :)
<ollehar>
hm, in effect types, heap allocation is just another effect, right? although you can't possibly know how big without starting to prove stuff.
<flux>
I suppose it depends on what you want
<mrvn>
flux: right, stack objects could point to heap objects. They would have to modify the root set of the GC for that.
<mrvn>
I still don't see how you would ever get a dangling pointer
AlexRussia has quit [Read error: Connection reset by peer]
kakadu has joined #ocaml
thomasga has quit [Quit: Leaving.]
<ggole>
Objects on the heap aren't necessarily of unknown lifetime
<ggole>
They can be dynamically sized things that are owned by something on the stack
<ggole>
(Or owned by something that is owned by, etc)
<ollehar>
yeah
<ggole>
Such objects wouldn't need GC to be collected, but they would still need to be traced
<ggole>
(Unless they didn't contain any refs to GC-managed objects.)
<mrvn>
ggole: If they can point to GC objects. The type knows that. So on creation they get added to the root set, then they are always valid and eventually they get removed from the root set. They never dangle.
<mrvn>
A dangling pointer would mean adding something with a shorter lifetime to something with a longer lifetime. And I thought linear type systems would prevent exactly that.
AlexRussia has joined #ocaml
<bernardofpc>
Algebr> Saw this comment, (** Safe version of append *) Since when was append not safe? Or does the comment mean O(1) concat? => probably means tail recursive
<mrvn>
.oO(That's what rev_append is for)
pyon is now known as ninja-maid-robot
<ggole>
"Such deallocation is performed independently of memory space from the run-time stack or registers"
<ggole>
They seem to think that the GC would follow pointers that are no longer used... but I don't think that precise collectors actually do that.
<ggole>
Maybe they are concerned with conservative collectors.
<mrvn>
Well, then don't. When you free pointer set pointer to NULL
zpe has joined #ocaml
<mrvn>
Also the DWARF (or better) info should tell which registers and stack positions contain pointers at every moment. Otherwise how would that work without tags?
native_killer has joined #ocaml
<ggole>
Like I said, conservative collectors do exactly that.
<ggole>
The paper isn't particularly clear about it though.
<flux>
conservative collectors rather leave unreferenced space allocated, not release references space?
<mrvn>
conservative collectors go wrong all the time, esspecially on 32bit.
<flux>
s/references/referenced/
<mrvn>
flux: if an int happens to contain the bit pattern of a valid object than that stays alive.
<flux>
mrvn, yes, but it doesn't crash, it just wastes memory
<mrvn>
yep
<ggole>
There are also conservative-on-stack precise-on-heap schemes that are rather less problematic
<mrvn>
Never heard that called a dangling pointer.
<ggole>
(SBCL, for instance.)
<ggole>
And they reference all the old tagless GC schemes that never worked out.
<ggole>
So doing this for a language with polymorphism would probably be quite painful.
<flux>
I think combining tracing GC with reference counting/ownership would be quite problematic
<flux>
has it ever been done?
<mrvn>
GC with reference counting makes no sense. GC with ownership is what rust has planed for.
<ggole>
Immix had some hybrid thing iirc
<ggole>
Refcounting with a tracing collector for cycles
<profan>
flux: doesn't python do that?
<flux>
well yes, python does that, but I meant in way that makes sense.. :)
<flux>
it's only its implementation. there are versions of python that do non-deterministic gc as well.
<flux>
I understand PyPy is one
<mrvn>
Refcounting wastes time and memory and the GC makes it uneccessary. So why do that?
<flux>
because it's nice to close open file handles immediately when they go out of scope
<flux>
so, for resource management
<ggole>
Immix performed reasonably well, afaik
<profan>
i reckon people usually go that way in an effort to reduce the non-determinism involved (even if it maybe slower overall, it could be more predictable?)
<ggole>
Although not quite as well as the tracing collectors
<ggole>
It was also very complicated, so simplicity of implementation (one of the arguments often put forward for RC) was not one of its advantages.
* ggole
dinner time
<mrvn>
flux: python has "with open("foo") as fd:" for that.
kushal has quit [Quit: Leaving]
mcorbin has quit [Remote host closed the connection]
jabesed has quit [Ping timeout: 244 seconds]
jabesed has joined #ocaml
tmtwd has joined #ocaml
jabesed has quit [Client Quit]
native_killer_ has joined #ocaml
native_killer_ has quit [Remote host closed the connection]
<ely-se>
python context managers are great in the absence of multistatement lambdas
<flux>
featuring classic file leak issues and doesn't really cover the case of (key, in_channel) Hashtbl
<flux>
actually I mean object leak, not file descriptor leak
<flux>
c++ rules!!
<flux>
;-)
<companion_cube>
well it's as good as python's solution
<ely-se>
what is?
<companion_cube>
C++ rules until (as in rust) you put the file descriptor in a cycle of RC pointers
<ggole>
You can still leak the object in C++, it'll just break
<ely-se>
you almost never use RC pointers in C++
<ggole>
(A pointer to the object, I should say.)
<ely-se>
std::shared_ptr is almost exclusively used by noobs who don't understand move semantics or who overcomplicate their design
<ely-se>
it's very nice for sharing immutable objects though
ninja-maid-robot is now known as pyon
<mrvn>
ely-se: I like that
<companion_cube>
ely-se: still, you can mess up
<ggole>
You can mess up in OCaml, too
sqweek has quit [Ping timeout: 256 seconds]
<ely-se>
I don't think resource management is a large source of bugs in programs written by people who know what they're doing.
<ely-se>
bracket works fine, really
<ggole>
And leaking is considerably less harmful than memory unsafety
<ggole>
Still, it would be nice to have a good clean up story.
nullcatx_ has joined #ocaml
<mrvn>
std::shared_ptr lets you waste memory but it doesn't let you free things to early. So at least it's save.
sqweek has joined #ocaml
<companion_cube>
well next Ocaml will print a warning when a non-closed channel is GC'd
<mrvn>
companion_cube: I wanted that for Unix.file_descr
<ely-se>
wrap it with a custom finalizer
<mrvn>
ely-se: that doesn't help.
<ggole>
Oberon had an interesting way of dealing with it: you could leak (their analogue of) fds and they would simply be GCd
<mrvn>
ely-se: you need a flag somewhere that tells you if the FD was closed. It being an int you can't hide the flag in there.
<ggole>
Although that approach doesn't really work for very expensive resources
<ely-se>
mrvn: why not?
<dsheets>
that warning is going to be annoying for a lot of quick and dirty ocaml code that knows it has a short lifetime (e.g. command-line utils)
<ely-se>
oh
<ely-se>
I see.
<mrvn>
ggole: That's why I wanted to give a warning in the finalizer and close the FD. It doesn't leak and you see that you forgot to close it properly.
<companion_cube>
mrvn: but Unix.file_descr is just an int, isn't it? so it's not GC'd
<ggole>
That doesn't really solve the issue in the same way: you can run out of fds to allocate and your program will die
<ggole>
Whereas with Oberon it would just run a collection and free whatever hadn't been closed (just like memory)
nullcatxxx_ has quit [Ping timeout: 260 seconds]
<ely-se>
Is Oberon still a thing?
<mrvn>
ggole: then you know you leaked something. And the code that fails to get a new FD could run GC.major () and try again.
<ggole>
They may have even removed the close operation entirely
<ggole>
Although that wouldn't be suitable for a Unix-like design.
<mrvn>
companion_cube: problem is that it is passed by value, not by reference. So "Unix.close fd" can not set fd to -1 to flag it as closed and invalid.
<companion_cube>
well yes, it's just an integer
<mrvn>
It should be a block containing the int.
<companion_cube>
still I think that issuing a warning on non-closed channels will help a lot
<companion_cube>
if you see such a warning, you have a bug
<ggole>
mrvn: I don't think that works across fork
<mrvn>
companion_cube: I think it's a level to high. Should be done on file_descr.
<companion_cube>
well, Unix.file_descr is an opaque type, maybe you can propose to change its implementation
<mrvn>
companion_cube: breaks C bindings
<mrvn>
What is the type of Unix.file_descr under windows?
darkf_ is now known as darkf
<ggole>
How do you (safely) tell whether an FD was closed?
<ggole>
You can't just pass it to some system call, since it might have been used again since.
<mrvn>
ggole: you set it to -1 on close and check for that.
<mrvn>
ggole: which requires that it is boxed so it gets passed by reference.
<ggole>
Oh, I see
<ggole>
Yeah: doesn't work with the current implementation at all
<mrvn>
alternativcely you box it as {fd:int; valid:bool;}
tane has quit [Quit: Verlassend]
yomimono has quit [Remote host closed the connection]
<dsheets>
it's a pity the stdlib doesn't expose int_of_file_descr and so everyone Obj.magics it and violates the abstraction
<mrvn>
ggole: I think being reused is the biggset problem. When you use a closed FD you get an error. But if it got reused that simply works on the new file.
<ggole>
But does that play nice with O_CLOEXEC?
<ggole>
I guess you could do the checks even if it were valid.
<mrvn>
ggole: nope. you will have to register all FDs and on fork invalidate all that are O_CLOEXEC
<dsheets>
interesting... seems to ask for a lot more than I want, though
<dsheets>
i'd be happy with just converters -- but i suppose create_process could have more arguments
nullcatx_ has quit [Read error: Connection reset by peer]
badkins has joined #ocaml
<mrvn>
dsheets: converter would work but under windows I don't think a FD is an int
<mrvn>
I think the first step would be to provide Val_FD and FD_Val makros for use in C stubs.
nullcatxxx_ has joined #ocaml
<mrvn>
Then get core, batteries, async, ... fixed to use those to get file_descr back to an abstract type.
<dsheets>
i'm not sure how windows support affects this? those functions could raise like they do for other unsupported functions on windows
<dsheets>
but there is a lot of linux and unix software that really needs to manipulate fds as ints
izaak has joined #ocaml
yomimono has joined #ocaml
lobo has joined #ocaml
thomasga has joined #ocaml
pyon has quit [Quit: only way to stop]
ely-se has quit [Quit: leaving]
AltGr has left #ocaml [#ocaml]
<flux>
I think the problem with application code dealing directly with unix filedescriptors and them being accidentally reused or remaining opened isn't that great, most software shouldn't deal with such low-level constructs.
whirm has joined #ocaml
ely-se has joined #ocaml
ely-se has quit [Client Quit]
jeffmo has joined #ocaml
<dmbaturin>
dsheets: When you really have to manipulate file descriptors as ints?
<dsheets>
dmbaturin, passing the fd to use via an env var to a child
<dsheets>
dmbaturin, writing system test and simulation software
<dmbaturin>
Why would a child who isn't a fork want someone else's file descriptor?
<mrvn>
dmbaturin: seperation of permissions. You can have a server running as nobody and a client that opens files as root or user and passes the FD to the server.
<dmbaturin>
mrvn: Or you can setup MAC and give it only capabilities it actually needs. :)
<mrvn>
dmbaturin: you can't. then it would be able to open any file.
<dmbaturin>
With POSIX capabilities? Yes. With SELinux and other MAC implementations, no, it will only be able to access what its context allows.
<mrvn>
dmbaturin: which would be all of my files, a fixed set of files or none of my files. And I as user couldn't grant it access to a file on a whim.
dongcarl has joined #ocaml
izaak has quit [Quit: izaak]
<dmbaturin>
mrvn: Users can change file context, even though you can prevent them from doing so.
<mrvn>
With passing FDs I can even give a server permission to a O_TMPFILE file.
<dsheets>
in this case it's to perform privileged operations in a setuid (ew, i know, not my choice) executable and connect those operations to a pipe
<dsheets>
this is how FUSE performs a mount, btw
BitPuffin has joined #ocaml
<flux>
dsheets, you want to convert file desciptor to numbers and vice versa when you are dealing with another program that needs to access inherited fds other than 0, 1 or 2?
<flux>
actually dmbaturin, not dsheets :)
<mrvn>
flux: my use case uses 3 for an extra socket
<mrvn>
stdin, stdout, stderr, control socket.
<flux>
for example, Wayland passes the fd number to connect to the wayland server via environment variable WAYLAND_SOCKET
<flux>
seems incredibly fragile though :-)
<ggole>
The three hardcoded fds and no way to talk about others was a pretty silly idea
<mrvn>
why? They know which FD it is when they exec()
<mrvn>
Problem is: How do you open fd WAYLAND_SOCKET in ocaml?
<flux>
fact remains such protocols are used in unix, whether one likes them or not :)
pyon has joined #ocaml
<ggole>
Ideally there'd be a string->fd mapping made available and processes could just look for what they expect
<flux>
what string?
<mrvn>
some Unix.export_file_descr and Unix.import_file_descr
<ggole>
Whatever the programs agree on for that use case
<mrvn>
Under unix it would just convert an int to string and back. Under windows whatever the equivalent for file handles is.
<flux>
mrvn, why not of_string, to_string..
<ggole>
The point being to allow arbitrary redirection, etc, with nice readable names for everything
<mrvn>
flux: might not be string
<flux>
readable names being something else in a unix environment than a number?
<ggole>
The problem is that there's no reasonable way to pass in an fd and say "use that for logging"
<ggole>
In the way that you can pass in an fd for error output
<flux>
there is, if you agree there is?
<flux>
just put LOG_FD=42 in off you go
<mrvn>
Logging.use_fd (Obj.magic 3)
<flux>
(and ensure the logging fd is passed as fd 42)
<ggole>
That seems entirely too fragile
<mrvn>
ggole: hardly
<flux>
well, you need to ensure not only that you close the fd 42 when fork-execing external apps, but also that you remove the environment variable
<flux>
so it is a bit fragile, only the fd closing part has a builtin mechanism
<ggole>
Two uses of the same number would collide too easily
<flux>
you allocate the numbers dynamically
<mrvn>
ggole: the env var is there so you can pick an arbitrary number
<flux>
and use environment variable to pass them around
<flux>
and you can even renumber it with dup2
<ggole>
Eh, I guess so.
<mrvn>
The alternative would be to pass a unix domain socket and then pass the other FDs as messages.
<ggole>
Seems like it would be pretty cumbersome
<companion_cube>
why use a FD for logging?
<mrvn>
ggole: Hide it in a module.
<flux>
companion_cube, at least you can easily guarantee only your child processes can access it
<flux>
unless the pass it forward over a unix socket I suppose :)
<mrvn>
flux: or fork
<flux>
it seems at least wayland does it for security reasons
<flux>
it creates a socket, adds some internal security settings for that particular client, and then fork+execs
<flux>
I suppose it could also work by passing a unix domain socket made for that client
<mrvn>
flux: does it pass a pipe/socketpair or does it pass a unix domain socket (backed by a file in the FS)?
<flux>
or alternatively a unix domain socket and a cookie
<mrvn>
(that answeres that)
<mrvn>
Not having an actual file that some hacked process can access to gain access to wayland is a bonus.
antkong_ has joined #ocaml
<mrvn>
how does that work with ssh? Can you forward the FD and ENV var?
<flux>
it doesn't
<flux>
it wouldn't work anyway
<flux>
you need shared memory access to render opengle
<flux>
+s
<mrvn>
right, they broke that completly.
ely-se has joined #ocaml
grouzen has joined #ocaml
pyon is now known as ninja-maid-robot
sepp2k has joined #ocaml
jeffmo has quit [Quit: jeffmo]
zpe_ has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
jeffmo has joined #ocaml
Snark has joined #ocaml
nullcatxxx_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nullcatxxx_ has joined #ocaml
MercurialAlchemi has joined #ocaml
native_killer has joined #ocaml
BitPuffin has quit [Disconnected by services]
itPuffinB has joined #ocaml
itPuffinB is now known as BitPuffin
izaak has joined #ocaml
antkong_ has quit [Quit: antkong_]
psy_ has quit [Ping timeout: 260 seconds]
lobo has quit [Quit: leaving]
BitPuffin has quit [Disconnected by services]
itPuffinB has joined #ocaml
<nullcatxxx_>
how is Hashtbl.hash implemented?
itPuffinB is now known as BitPuffin
grouzen has quit [Ping timeout: 260 seconds]
ely-se has quit [Quit: leaving]
mrm has joined #ocaml
mrm has left #ocaml [#ocaml]
<ggole>
It's a pretty straight forward chaining table
jao has joined #ocaml
jeffmo_ has joined #ocaml
jeffmo has quit [Ping timeout: 245 seconds]
jeffmo_ is now known as jeffmo
igoroliveira has joined #ocaml
zpe_ has quit [Remote host closed the connection]
thomasga has quit [Quit: Leaving.]
jeffmo has quit [Read error: Connection reset by peer]
<nullcatxxx_>
ok. i need to know more about runtime values representation =_=
yomimono has quit [Ping timeout: 256 seconds]
jeffmo has joined #ocaml
izaak has quit [Quit: izaak]
BitPuffin has quit [Disconnected by services]
itPuffinB has joined #ocaml
itPuffinB is now known as BitPuffin
MercurialAlchemi has quit [Ping timeout: 246 seconds]
psy_ has joined #ocaml
<pippijn>
nullcatxxx_: what do you want to know?
<nullcatxxx_>
chaining table, what's that
<pippijn>
nullcatxxx_: oh, you want to know about Hashtbl.hash?
<nullcatxxx_>
yeah
<nullcatxxx_>
that c code in byterun/ is clean
<nullcatxxx_>
but i'd like to know what chaining table is
<pippijn>
it does a traversal over the memory graph pointed to by its argument and applies different hash functions for different values
<nullcatxxx_>
how is that graph designed? is it documented somewhere?
<mrvn>
nullcatxxx_: Obj module, interfacing with C in the manual
<mrvn>
nullcatxxx_: it just goes over the memory representation of ocaml values
<nullcatxxx_>
ok
<nullcatxxx_>
thanks
MercurialAlchemi has joined #ocaml
ely-se has joined #ocaml
contempt has quit [Ping timeout: 250 seconds]
nullcatxxx_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
contempt has joined #ocaml
<ggole>
Oh, Hashtbl.hash
<ggole>
I mentally skipped the .hash part -_-
izaak has joined #ocaml
ninja-maid-robot has quit [Ping timeout: 252 seconds]
jwatzman|work has joined #ocaml
izaak has quit [Quit: izaak]
pyon has joined #ocaml
octachron has quit [Quit: Leaving]
darkf has quit [Quit: Leaving]
BitPuffin has quit [Ping timeout: 245 seconds]
nullcatxxx_ has joined #ocaml
<mrvn>
Anyone know how many possible board layouts there are in tic-tac-toe? Wikipedia doesn't say.
ely-se has quit [Quit: Leaving...]
<bitbckt>
back-of-the-envelope: 19,683.
<bitbckt>
trust but verify :)
<ollehar>
yeah 3^9
<ollehar>
two squares: 3 * 3
<ollehar>
three: 3 * 3 * 3
<ollehar>
etc
matason has quit []
<mrvn>
bitbckt: A board with just two Os is not valid.
<bitbckt>
like I said...
<bitbckt>
at a guess.
<mrvn>
wikipedia only gives those naive numbers but not how many unique positions are reachable.
srcerer has joined #ocaml
<bitbckt>
tough luck, having to do work.
<mrvn>
I guess I have to generate them all and count.
pyon has quit [Ping timeout: 246 seconds]
slash^ has joined #ocaml
Lis_ has joined #ocaml
Lis_ is now known as Lis
ely-se has joined #ocaml
native_killer has quit [Ping timeout: 244 seconds]
<mcc>
drup algebr: are those two answers the same?
MrScout has quit [Remote host closed the connection]
<Algebr>
if you are use emacs, you can do merlin-use ctypes
<Drup>
mcc: Algebr's answer is local to your session, mine is persistent
<Algebr>
yes, add: PKG ctypes.
<mcc>
Cool. I added PKG ctypes and it worked
<Drup>
about question 2; I was going to link you this table, yes :)
kakadu has quit [Remote host closed the connection]
swgillespie has joined #ocaml
noplamodo has quit [Remote host closed the connection]
jun has quit [Quit: WeeChat 1.1.1]
jwatzman2 has joined #ocaml
jwatzman|work has quit [Ping timeout: 246 seconds]
nullcatx_ has joined #ocaml
nullcatxxx_ has quit [Ping timeout: 244 seconds]
nullcatx_ has quit [Read error: Connection reset by peer]
nullcatxxx_ has joined #ocaml
rand000 has quit [Ping timeout: 244 seconds]
antkong_ has joined #ocaml
antkong_ has quit [Client Quit]
antkong_ has joined #ocaml
nullcatx_ has joined #ocaml
nullcatxxx_ has quit [Read error: Connection reset by peer]
jwatzman2 is now known as jwatzman|work
jwatzman|work has quit [Changing host]
jwatzman|work has joined #ocaml
pyon has joined #ocaml
nullcatx_ has quit [Ping timeout: 246 seconds]
Haudegen has quit [Ping timeout: 250 seconds]
madroach has quit [Ping timeout: 264 seconds]
madroach has joined #ocaml
Haudegen has joined #ocaml
rbocquet has quit [Ping timeout: 246 seconds]
oriba has joined #ocaml
jwatzman|work has quit [Quit: jwatzman|work]
oriba_ has joined #ocaml
<oriba_>
Just tried again using csv-module ... ( https://forge.ocamlcore.org/projects/csv/ ). For 157 MB it eats up more then 2 GB RAM; maybe more, but I then cancleled it, because it starte dto swap on this machine.