cdidd has quit [Remote host closed the connection]
demonimin_ is now known as demonimin
malo has quit [Quit: Leaving]
ontologiae has joined #ocaml
cdidd has joined #ocaml
ontologiae has quit [Ping timeout: 276 seconds]
madroach has quit [Ping timeout: 248 seconds]
madroach has joined #ocaml
ontologiae has joined #ocaml
mrvn has quit [Read error: Operation timed out]
q66 has quit [Quit: Leaving]
mrvn has joined #ocaml
ontologiae has quit [Ping timeout: 264 seconds]
ygrek has joined #ocaml
darkf has joined #ocaml
so has quit [Ping timeout: 268 seconds]
introom has joined #ocaml
dsheets has quit [Ping timeout: 248 seconds]
mye has joined #ocaml
mye has quit [Client Quit]
gnuvince has joined #ocaml
tani has quit [Quit: Verlassend]
pkrnj has quit [Ping timeout: 256 seconds]
pkrnj has joined #ocaml
pkrnj has quit [Client Quit]
<Drup>
For anyone interested, I'm benchmarking my lsystem engine against various "stream" datastructure. Basically, I'm chaining concat-map operations (and the size of the stream I'm manipulating grow exponentially). For now I have tested BatEnum, BatSeq and BatLazyList.
<Drup>
BatSeq is 2.5 times faster than BatEnum for what I'm doing. BatLazyList is horribly slow.
<Drup>
If someone have other data structure to test, I can try :)
<ygrek>
I guess extlib enum and batenum are essentially the same
<ygrek>
what about Stream.t ?
<Drup>
ygrek: the one from the standard library ?
<ygrek>
yup
<Drup>
ygrek: I'm gonna try with BatStream, since it's supposed to be the same but contain all the primitive I need
<Drup>
Hum, no clone primitive :/
<Drup>
ygrek: ok it's working, launching the bench :]
<Drup>
it seems really slow
<Drup>
ygrek: 12 time slower than BatSeq
yacks has joined #ocaml
<ygrek>
lol
<Drup>
I'm quite surprised by BatSeq's performances.
<Drup>
ygrek: to be honest, Stream is still faster than BatLazyList ... >_>
yacks has quit [Read error: Operation timed out]
yacks has joined #ocaml
gautamc has quit [Ping timeout: 264 seconds]
Neros has joined #ocaml
Neros has quit [Ping timeout: 264 seconds]
ggole has joined #ocaml
gautamc has joined #ocaml
emmanuelux has quit [Ping timeout: 248 seconds]
ivan\ has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
ivan\ has joined #ocaml
weie has joined #ocaml
weie_ has quit [Ping timeout: 264 seconds]
Drup has quit [Quit: Leaving.]
ben_zen has joined #ocaml
xenocons has joined #ocaml
vext01_ has joined #ocaml
ivan\_ has joined #ocaml
ivan\ has quit [*.net *.split]
ygrek has quit [*.net *.split]
thizanne has quit [*.net *.split]
xenocons_ has quit [*.net *.split]
avsm_cl has quit [*.net *.split]
vext01 has quit [*.net *.split]
ivan\_ is now known as ivan\
thizanne has joined #ocaml
ygrek has joined #ocaml
Snark has joined #ocaml
Simn has joined #ocaml
flux has quit [Read error: Operation timed out]
flux has joined #ocaml
Watcher7 is now known as Watcher7|off
gautamc has quit [Read error: Connection reset by peer]
gautamc has joined #ocaml
pango has quit [Remote host closed the connection]
tane has joined #ocaml
ben_zen has quit [Quit: sleeeeeeeeeeeep]
ollehar has joined #ocaml
UncleVasya has joined #ocaml
ollehar has quit [Ping timeout: 276 seconds]
_iota has joined #ocaml
ollehar has joined #ocaml
_iota has quit [Client Quit]
ygrek has quit [Ping timeout: 276 seconds]
introom has quit [Remote host closed the connection]
<rly>
opam tells me "No current switch defined." I am sure it wants a current switch to be defined, but why can't it just prompt me for one?
doomrobo has joined #ocaml
<wmeyer>
probably you have deleted the old switch, and opam is still on it
<wmeyer>
otherwise you can file a bug, saying that opam should be interactive in this case (but first make sure that my im guess is correct)
demonimin has quit [Ping timeout: 245 seconds]
* wmeyer
going to city centre to enjoy the sun
* adrien
knew there couldn't be sun everywhere in any british city
demonimin has joined #ocaml
<pippijn>
wmeyer: omake has problems
<pippijn>
with multi-target rules
q66 has joined #ocaml
Uvs has joined #ocaml
<wmeyer>
order of building, when dynamic variables are mutated?
UncleVasya has quit [Ping timeout: 252 seconds]
doomrobo has quit [Quit: This computer has gone to sleep]
<rly>
opam switch list also says there is no "No current switch defined".
<rly>
wmeyer: do you know of any way to bring it back in a normal state?
<rly>
adrien: I understand what you meant by "first run" just fine.
<rly>
adrien: it's just that I perhaps made a too large mental leap.
<pippijn>
24 seconds here
<pippijn>
or 25
<pippijn>
incremental builds are immediate
<pippijn>
setup time from a hot cache when the file system monitor is not running is 17 seconds
<pippijn>
so, setting up the monitor takes 17 seconds
<rly>
I don't think there is anything inherently slow about Tup's design.
<pippijn>
after that, it's fast
<pippijn>
like tup
<pippijn>
I'm curious about ninja, though
<pippijn>
it seems to be a classic build system, but written in a ridiculously efficient way
<pippijn>
- very fast (i.e., instant) incremental builds, even for very large projects.
<adrien>
ahhhh
<pippijn>
I don't know what very large projects are, but I suppose it's like KDE
<adrien>
the main issue with tup: the awful style of its documentation
<adrien>
which makes it unreadable
<pippijn>
if it can achieve nearly instant incremental builds without a file system monitor, that is impressive
<pippijn>
MarcWeber told me about it
<rly>
adrien: awful? I am usually the largest whiner in that area and even I think it is acceptable.
<adrien>
I can't find numbers that show it =/
<rly>
adrien: show what?
<adrien>
the setup time
<adrien>
it exists; it might be 1ns or 1 hour, I don't know: I don't see that mentionned on the website
dsheets has joined #ocaml
<rly>
adrien: it's a good theoretical point, but I have used it and it didn't annoy me at all.
<rly>
adrien: which means, for me, that it's fast enough.
<adrien>
I'm simply trying to find numebrs :-)
<adrien>
if you package software, you do clean builds
<rly>
adrien: why don't you install Ggithub?
<adrien>
setup time matters quite a lot
<rly>
adrien: er gittup.
<adrien>
?
<adrien>
ah
<rly>
adrien: play around with the Linux kernel in a very efficient manner.
<adrien>
because I'm trying to write a difficult-to-write email then I have to work on the ocaml compiler build system then swim then (or before) buy stuff for my flowers then sleep then ...
<nicoo>
pippijn: What problem do you have with non-copyleft licences ?
<whitequark>
people not contributing back ?
<pippijn>
nicoo: I want to force users of my code to contribute changes back
<pippijn>
not to me, but in some way to the community
<nicoo>
1) Users of the code aren't forced to publish their modifications, if they keep them in-house.
<pippijn>
that's ok
<pippijn>
I don't care about in-house products
<pippijn>
GPL does nothing about that, either
<nicoo>
2) In practice, it seems that the chosen licence hasn't much impact, and community-management matters more.
<pippijn>
that's ok, too
<nicoo>
I had a few good refs for 2), but they were on my old laptop (that died)
<whitequark>
license is an "exception handler". it doesn't do much impact until you actually need it, and then it's indispensable
<pippijn>
but I want to state my intentions
<pippijn>
and the licence does that
<pippijn>
I want to say "I would like you to contribute back"
<whitequark>
though, to say that choosing GPL doesnt have much impact is a stretch at least
introom has quit [Remote host closed the connection]
<tane>
pippijn, MIT license does exactly that
<whitequark>
tane: how so?
<pippijn>
tane: MPL does so, too?
<tane>
whitequark, read their page
<tane>
it#s not _in_ the license, but the license' idea stems from those ideals
<whitequark>
tane: I read the license
osnr has quit [Ping timeout: 256 seconds]
<whitequark>
besides, in practice MIT almost always appears as poor man's public domain dedication
<whitequark>
(since you can't reliably release something in public domain)
<tane>
what do you mean by that?
<whitequark>
by which part?
<tane>
the first
<tane>
or "why is that?"
<pippijn>
wmeyer: are you ok with MPL for treematch?
<nicoo>
tane: There are some legislations (like France's) when you cannot volontarily put something ni the public domain. The only option is waiting long enough.
<whitequark>
I may be biased, but most of time I have seen MIT applied somewhere, esp. in the Ruby community, it's a substitution for "do whatever you want"
Watcher7|off is now known as Watcher7
<pippijn>
nicoo: also germany
<pippijn>
I think most (or all) of europe is like that
<tane>
that's exactly the way i thought it to be :)
<tane>
nicoo, waiting for what?
<nicoo>
pippijn: 'k. France was the only one for which I was (reasonably) certain.
<Drup>
Is there somewhere a proper documentation for Core ? the ocamldoc is completely useless :/
domsj has joined #ocaml
<mrvn>
what do you need to know?
<nicoo>
tane: For the code (the text, drawing or whatever) to be old enough that it automatically falls in the public domain.
<tane>
oh
<whitequark>
pippijn: I just read up on merr. Merr is very cool.
<whitequark>
would you also relicense it?
<pippijn>
yes
<pippijn>
I'm relicensing everything
<whitequark>
awesome
<whitequark>
thanks
<pippijn>
I published all my code last week
<pippijn>
so that's no problem to do now
<Drup>
mrvn: basic information for various data structure like complexity, lazy or strict and so on.
<nicoo>
What is merr ?
<nicoo>
Ok, found
<mrvn>
Drup: only the lazy module is lazy
ollehar has quit [Ping timeout: 252 seconds]
<Drup>
mrvn: and what about complexity ?
<mrvn>
tends to be the best possible
<Drup>
that doesn't mean anything
<pippijn>
whitequark: done
<whitequark>
pippijn: thx
<whitequark>
now
<whitequark>
I need to start using omake, I guess :)
<pippijn>
it should just work :)
<mrvn>
Drup: I'm not going to list the complexity of all std lib functions now
<pippijn>
I really hope it works
<pippijn>
you need to drop the requires libraries in the src/ directory somewhere
<Drup>
mrvn: That's not what I asked for
<pippijn>
or have them installed, but I don't have an install procedure, yet
<nicoo>
whitequark: Isn't omake just a bonus ? (Thus, completely optionnal)
* nicoo
returns to bad-pun land.
<whitequark>
nicoo: I would really rather drop the library in as a submodule
<nicoo>
(Did jou mean to hilight pippijn instead ?)
travisbrady has joined #ocaml
<whitequark>
oh
<whitequark>
right
<pippijn>
obuild is basically a package manager for a source based distribution :)
<pippijn>
(except it can't uninstall)
ben_zen has joined #ocaml
<whitequark>
so uh... I want your ucslib to be available as Ucslib module or something
<whitequark>
I'm not sure how do I achieve that
<pippijn>
oh
<pippijn>
whitequark: in the OMakefile.ml
<pippijn>
you replace Library with Package
<pippijn>
then it's an ocaml pack
ollehar has joined #ocaml
<whitequark>
pippijn: hm, that would require me to maintain a fork
<pippijn>
whitequark: maintain it for now
<pippijn>
I'll change it one of these days
<pippijn>
it's a 10 minute change
<pippijn>
maybe I'll do it later today
<whitequark>
mm ok
<pippijn>
I need to change other code to use Ucslib then
<pippijn>
also, it would be Ucs, not Ucslib
<whitequark>
Ucs, sure
<whitequark>
hm, how do I build that
<whitequark>
it can't find Omakeroot
<pippijn>
get obuild
<pippijn>
from my github
<pippijn>
delete all directories in src/ and drop in the ones you need
<whitequark>
that uh... looks like a little overkill
<pippijn>
what does?
<whitequark>
the whole obuild thing. seems like I will have to rearrange my whole build process rather dramatically
<pippijn>
hm
<pippijn>
why?
<pippijn>
you can put it into a subdirectory, and call omake in that
<pippijn>
when it's finished, you have the things in _install
<pippijn>
you can set your OCAML_PATH to that, and use ocamlfind
<whitequark>
oh I see
<pippijn>
alternatively, because these two are very small and mostly independent things, you can let your build process compile them
<whitequark>
CI would be a pain to set up, though...
<pippijn>
whitequark: why?
<pippijn>
that's interesting
<pippijn>
because I made obuild to make CI easy
<whitequark>
that means I would need to have a fork of obuild which tracks your ucslib development
<pippijn>
hm?
<whitequark>
and on CI, I would check out that fork, build ucslib, then check out my main repo and link it all together
<whitequark>
well, git submodules point to a particular sha1
<pippijn>
ah submodules
<pippijn>
yeah, the submodules thing..
<pippijn>
that's temporary
<whitequark>
ok... I think that for now, I'll just import the libs into the tree
<whitequark>
deal with it later
<pippijn>
ok
Yoric has quit [Ping timeout: 252 seconds]
<pippijn>
the packages built by obuild need to be in its source directory
<pippijn>
how would you do that if it were empty?
<pippijn>
imagine there are no submodules
<pippijn>
would it be easier?
<whitequark>
pippijn: have you considered submitting your stuff to opam?
<pippijn>
the submodules are just easy for me, because I can do a foreach on them
<pippijn>
whitequark: not yet
<pippijn>
I don't have opam, I don't know how it operates
ulfdoz has joined #ocaml
tobiasBora has quit [Ping timeout: 276 seconds]
<wmeyer>
pippijn: yes, becasuse I can always change it. (I'd prefer GPL3 to be fair)
zpe has joined #ocaml
<mrvn>
Why is "%S@\n" with Scanf a problem in ocalm-4.00 and what is the fix?
<whitequark>
pippijn: oh you also use corelib... yeah, I'd have to fork in either case
<whitequark>
out of curiosity, why do you need
<whitequark>
let (|>) = BasePervasives.(|>)
<whitequark>
let identity = BasePervasives.identity
<whitequark>
?
<whitequark>
you could define both with several characters of ocaml, no?
<wmeyer>
mrvn: what kind of error you get, may I ask?
<mrvn>
wmeyer: Scanf.Scan_failure
<wmeyer>
well, maybe your string does not match
<mrvn>
it matches in 3.12
<wmeyer>
how about removing @ and \n, it's used in format, I hope it does not affect Scand
<mrvn>
it affects scanf
<mrvn>
"Scanning indications appear just after the string conversions %s and %[ range ] to delimit the end of the token. A scanning indication is introduced by a @ character, followed by some constant character c. It means that the string token should end just before the next matching c (which is skipped). If no c character is encountered, the string token spreads as much as possible. For instance, "%s@\t" reads a string up to th
<wmeyer>
here you go, I hope that answers your question mrvn
<wmeyer>
oh, I see
<wmeyer>
well I don't have idea really
zpe has quit [Remote host closed the connection]
<wmeyer>
mrvn: you might want to ask on the mailing list too, I hope it helps (never used @ formatting character)
* wmeyer
gtg now
darkf has quit [Quit: Leaving]
ollehar has quit [Ping timeout: 276 seconds]
zpe has joined #ocaml
jayprich has joined #ocaml
ttamttam has joined #ocaml
zpe has quit [Ping timeout: 264 seconds]
Yoric has joined #ocaml
ski has quit [Quit: Lost terminal]
<Drup>
ygrek: as a following of yesterday's experiments, Core's Lazy_list is 10 time slower than BatSeq but is still incredibly faster than BatLazyList
gustav___ has quit [Ping timeout: 248 seconds]
gustav___ has joined #ocaml
Yoric has quit [Ping timeout: 252 seconds]
ygrek has quit [Ping timeout: 256 seconds]
ashleyis_ has quit [Quit: WooChat 0.4.2-dev]
ggole has quit []
<pippijn>
wmeyer: ok, why?
<pippijn>
whitequark: yeah
<pippijn>
whitequark: because of documentation
<pippijn>
whitequark: I don't know :)
<pippijn>
whitequark: I want to make my own CorePervasives with those things in it
<pippijn>
I already have one, actually
<pippijn>
it's called BasePervasives now
* mrvn
wants prefix types for records
<mrvn>
extensible records
<wmeyer>
pippijn: because I think it's important to protect freedom. (but I am fine with MPL at the moment)
<mrvn>
type r = { x:int; } type s = { r with y:int; } or so
<Drup>
mrvn: that's not really extensible records
<pippijn>
wmeyer: yeah..
<pippijn>
wmeyer: I do agree
<wmeyer>
mrvn: r is not a subtype of s
<wmeyer>
so this is just extending the fields
<wmeyer>
(but could be done!)
<mrvn>
wmeyer: s :> r should work too
<Drup>
wmeyer: use objects
<Drup>
huh, mrvn*
<mrvn>
Drup: useless overhead
<Drup>
mrvn: inevitable for what you want
<wmeyer>
with type directed record label disambiguation can still be useful
<mrvn>
Problem is that I have a few different records with a common prefix (fist few labels are identical). Now I want to put instances of them into a hashtbl and iterate over them and such.
<wmeyer>
mrvn: not possible! use class for it if you really want this
<mrvn>
wmeyer: I know it is not possible. That's why I said I want it.
<Drup>
mrvn: if you're using an homogeneous hashtbl, you're not going to be able to get back the "complete" type of the record anyway (since you can't guess it) so what's the point ?
<Drup>
You're better with copying your "extended" record to a common subrecord and put it in the hashtbl.
<mrvn>
Drup: Unless the record includes closures that already have the full type
<mrvn>
Drup: type r = { on_read : unit -> unit; ... }
<wmeyer>
mrvn: you can bother people like Jacques Garrigue or Alain Frisch on the mantis always. I think it must have been considered before. But imagine now existing type extensions to ML type systems, like polymorphic variants and GADTs and add this on top of that.
<Drup>
wmeyer: the main point is that you can do it with objects ...
<Drup>
more than that, object is exactly that
<wmeyer>
you can use camlp4 to do the type safe marshaling work for you
<wmeyer>
Drup: yes, it should work with objects.
<mathieui>
p/W 10
<mrvn>
On the topic of GADTs. Can you do a GADT equivalen of `Foo?
<wmeyer>
we have even row notation for it
<Armael>
mathieui: .
<mathieui>
Armael: :(
<wmeyer>
mrvn: what do you mean, equivalent
<mrvn>
wmeyer: you can't do matching with objects though.
<Drup>
mrvn: you can't do GADT polymorphic variants
travisbrady has quit [Quit: travisbrady]
<mrvn>
wmeyer: extensible GADTs with open and closed types.
<Drup>
(if that's your question)
<wmeyer>
on the topic of GADTs not many people realise but you require just single axiom using GADTs to implement any GADT
<pippijn>
whitequark: I don't want to define it in every file I use it in
<pippijn>
whitequark: and I don't want to use "open BatPervasives"
<pippijn>
whitequark: because it includes too much stuff, like the whole BatIO standard overrides
zpe has joined #ocaml
<wmeyer>
Drup: while I agree it works with objects, this is not a backward compatible change, and as you say objects support it already
zpe has quit [Ping timeout: 276 seconds]
<mrvn>
Error: This expression has type hops but an expression was expected of type
<mrvn>
hops
<mrvn>
The type constructor hops would escape its scope
<mrvn>
what does that mean?
<Drup>
wmeyer: the problem is that "extensible" records are far less efficient than regular records so it's better to keep them separated (so that you can choose the one you want according to your need in terms of efficiency)
<pippijn>
mrvn: it seems you're using local modules
<pippijn>
mrvn: or first class modules
<Drup>
or playing with gadts :)
<mrvn>
Drup: why should they be less efficient? They change nothing in the runtime
<mrvn>
pippijn: no and no
<pippijn>
oh, gadts
<Drup>
mrvn: a record in the runtime is basically an array. access is very fast. An object/extensible record (it's the same, really) is almost like a hashtable.
<pippijn>
record access is faster than array access
<Drup>
pippijn: indeed, because you don't need to check boundaries
<pippijn>
right
rednovae_ has quit [Ping timeout: 260 seconds]
<mrvn>
Drup: With prefix typing for records nothing changes. Only change would be that the copy function has to use the blocks size instead of a compile time size.
<mrvn>
boundary checks would happen at compile time
<mrvn>
let ops = Hashtbl.create 0
<mrvn>
type hops = Ops : 'a ops * 'a -> hops
<wmeyer>
Drup: yes, classes use dynamic dispatch so it's good reason to have something similar. Not sure however about the order of the record fields, with subtyping all the inherited fields must be in the same order as in the parent.
<mrvn>
The type constructor hops would escape its scope
<mrvn>
If I reverse the two lines it works.
<wmeyer>
(and marshaling is another issue)
<mrvn>
wmeyer: marschaling isn't typesafe anyway
<Drup>
mrvn: does your extensible records allow to promote a record to a larger record whitout copying ? if yes, then you can't compile the same way it's done right now
<Drup>
if not, it's just typing sugar, so yes, sure.
<mrvn>
Drup: no, that wouldn't be safe
<Drup>
it's safe ... with objects :)
<mrvn>
Drup: you need runtime type infos to cast to a larger type
<Drup>
not cast, add information
<mrvn>
you could write let t = { x with y = 1; } to create a new record with a larger type
Yoric has joined #ocaml
<mrvn>
or maybe let t = { x :> xy with y = 1; } to tell the compiler explicitly that you want to grow the record.
<mrvn>
:>? <:? something like that
<Drup>
you can't do that if you want sharing between x and y *and* fast array-like access. that's my point.
<mrvn>
Drup: sure you can.
<mrvn>
type xy is the larger record that can be cast to type x for the shared code
<Drup>
well, you will have to implement it because, afaik, it's really not as easy as you make it sound.
<mrvn>
Drup: for prefix types it is. It basically just eliminates the let as_x : xy -> x = fun x = Obj.magic x
<mrvn>
Drup: the runtime part is trivial since basically nothing changes. The type system changes are the hard part and the syntax extensions.
<Drup>
hum, I see what you mean.
<mrvn>
Drup: The labels and offsets in x must be identical in xy while xy has some extra lables added at the end. So any access to the common lables has identical code for both. So they can just use the same code.
<Drup>
indeed, the import part is the "prefix" aspect.
<wmeyer>
mrvn: I see no reason this can't be done, but I am also sure it was discussed before
<Drup>
( mrvn : it took me quite a while to get it, sorry ^^')
<mrvn>
Drup: np
<wmeyer>
the record would have an row type, where rows are not dynamic, this would not allow to overlap by any means the fields, however
<mrvn>
overlap?
<wmeyer>
yes, like twice xoffset
<mrvn>
type r = { x:int; x:int; } makes no sense
<wmeyer>
in the record you want it to be super type
<wmeyer>
in other way extending with the existing field would not possible
<wmeyer>
the dynamic dispatch helps here
<wmeyer>
in case of objects
<mrvn>
records don't do dynamic dispatch. Otherwise there would be no difference to objects
<wmeyer>
of course, that's what I am implying here mrvn
<mrvn>
"extending with the existing field" would mean writing type r = { x:int; x:int; }, which simply makes no sense.
<wmeyer>
ah, no, it means (in your syntax): [type r = { x : int; y : int } type w = { r with x : float }]
<wmeyer>
it's easy to detect, but makes a difference to classes
<mrvn>
wmeyer: yeah, the "with" would be syntactic suggar.
<mrvn>
it would simply give an error that lable x is already used.
<wmeyer>
not entirelly syntaciv sugar as it turns the both types (you need like [record r = { x : int; y : int}] to row types of type < x : int; y : int; ... >
<mrvn>
wmeyer: I think I would want type r = { x : int; } type s = { x with y : int; } and type s = x : int; y : int; } to be equivalent.
<wmeyer>
if you use row types the same rules apply as for classes
<wmeyer>
ok, i will mark it as dup, I haven't found anything in the search
<mrvn>
and why not record bar = { foo with z : int; }
gnuvince has joined #ocaml
<orbitz>
what's that do?
<wmeyer>
because I've not used OCaml too much these days
<wmeyer>
which is duplicated?
<wmeyer>
orbitz: it makes the records extensible, thus you can extend and use the extended one where extendee is allowed
<whitequark>
pippijn: but the definition is even shorter than your import
<whitequark>
let identity = BatPervasives.identity vs let identity x = x
<whitequark>
I mean, why is it even a question of what's better?
<mrvn>
wmeyer: I know this was reported before but don't see it in "my view"
mlh has quit [Ping timeout: 256 seconds]
<mrvn>
whitequark: BatPervasives.identity should be %identity
<wmeyer>
mrvn: ok, I can't find it either, when the concerned parties will spot it they will mark it
<whitequark>
mrvn: is that different?
<mrvn>
whitequark: might optimize better
mlh has joined #ocaml
<whitequark>
mrvn: if your compiler cannot optimize an identity function... I don't even know what to say
zpe has joined #ocaml
gnuvince has quit [Remote host closed the connection]
zpe has quit [Ping timeout: 248 seconds]
gnuvince has joined #ocaml
<whitequark>
pippijn: oh, read the other part of backlog
<whitequark>
by the way it finally compiled for me. I replaced your (|>) and identity with expanded definitions
<whitequark>
and Core stuff with Extlib
<wmeyer>
whitequark: it does cross module inlining, so I see no way it can increase the performance as mrvn says
ttamttam has quit [Quit: ttamttam]
<mrvn>
wmeyer: probably makes no difference on identify. But it makes a difference on other polymorphic operations like =
<mrvn>
wmeyer: as in %equal is faster than (fun x y -> x = y)
<orbitz>
wmeyer: so subtyping?
<orbitz>
sounds hard to do in a way that doesn't make the runtime suck
<wmeyer>
mrvn: how would you inline = as it's part of runtime?
<mrvn>
orbitz: the runtime only needs one change: let x = { r with y = 1; } needs to copy a chunk the size of the old record instead of the size of type_of r.
<wmeyer>
orbitz: yes, but no dynamic dispatch
<orbitz>
mrvn: how do you access elements?
<mrvn>
orbitz: r.x, same as now
<orbitz>
Type inference uses the fields you access to determine the type
<mrvn>
orbitz: that is compile time, not runtime
<orbitz>
right but how does this work?
<orbitz>
You can only inherit in different modules?
<mrvn>
orbitz: same way it works now
<orbitz>
Right now you can't have two records in the same module with the same fields
<pippijn>
whitequark: BatPervasives.identity is not fun x -> x
<mrvn>
orbitz: actualy that was changed. now you can.
<whitequark>
pippijn: judging by the discussion above this should make no practical difference
<orbitz>
it's also unclear to me how this is superior to just having a record with the old record as a value in it
<orbitz>
type r2 = { r : r1; moar.. }
<pippijn>
whitequark: it won't make a difference
<mrvn>
orbitz: type r = { y:int; x:int; } type s = { x:int; } ... if t.y = 0 then t.x ... The use of t.y tells ocaml t is type x so t.x use the type r too.
<pippijn>
whitequark: I just feel better not defining the same (even if trivial) function everywhere
<mrvn>
orbitz: They changed that in 4.00 or it is on the drawing board for the next version.
<pippijn>
whitequark: anyway, I changed all my code to use CorePervasives, now
<mrvn>
orbitz: type r2 = { r : r1; moar.. } can't be added to a r list
<orbitz>
mrvn: what if I do 'if t.yx = 0'?
<orbitz>
mrvn: so you want subtyping?
<mrvn>
orbitz: yes
<orbitz>
Ehh records aren't classes though
<orbitz>
Adding subtyping to records sounds expensive, especially since records are one of the few ways you can actually gaurantee your data is packed
<mrvn>
orbitz: usage example: type key = { k:kind; h:int; } type value = { k:kind; h:int; data:string; }. Now build a tree of values using the key as locator.
<mrvn>
orbitz: with prefix types you could cast values to keys for use in the tree.
<mrvn>
or for comparison purposes
<wmeyer>
orbitz: mrvn: it makes a difference of course. The new record can be used where old record is, and it has row type signature.
<orbitz>
you can already accomplish this with objects though
<mrvn>
orbitz: yes. but objects are different and have overhead
<orbitz>
How does subtyping records not include this overhead?
<mrvn>
orbitz: except for the "{ x with y = 1; }" syntax it is completly compile time.
<Drup>
orbitz: the whole thing is in the "prefix" part
<wmeyer>
orbitz: dynamic dispatch on every access of the data
<mrvn>
orbitz: accessing key.k or value.k is identical code. the compiler doesn't have to do dynamic dispatch there.
<orbitz>
I think you're all saying idfferent things. what wmeyer is saying would require dynamic dispatch as far as I understnad.
travisbrady has joined #ocaml
<wmeyer>
orbitz: records access does access a field by offset like arrays. Objects access field by method call which requires a dynamic dispatch. Records are not extensible, where objects are.
<Drup>
wmeyer, orbitz: but prefix records as described by mrvn (don't call them extensible, it's misleading) have the same fast access property than regular records.
<orbitz>
How do you use them in a type safe way?
<Drup>
that's the good question
<orbitz>
seems like to be useful at some point you have to make a runtime decision as to which concerete typeto use
gautamc has quit [Read error: Connection reset by peer]
<mrvn>
orbitz: you can only cast to a smaller type. so it can never become type unsafe
gautamc has joined #ocaml
<orbitz>
mrvn: just including records in other ones accomplishes teh same thing
<mrvn>
orbitz: but you loose the data of the outer type when you store the inner
<wmeyer>
orbitz: but one record is not equal to other one, so you have to do Obj.magic on it, or type safe copying
<orbitz>
ohh magic :)
<mrvn>
orbitz: including records also adds redirections. waste time and space if you have a few of them
<orbitz>
maybe. This isn't really a problem I've ever head so *shrug*
* orbitz
goes back to doing other things
<mrvn>
orbitz: and consider this code: let set_x r x = { r with x = x; }
<mrvn>
orbitz: type p2 = { x:int; y:int; } type p3 = { p2 with z: int; } let a = { x=0; y=0; z=0 } let b = set_x a 1
tianon has quit [Ping timeout: 246 seconds]
tianon has joined #ocaml
rwmjones has quit [Read error: Operation timed out]
travisbrady has quit [Quit: travisbrady]
<wmeyer>
orbitz: yep. but you have to do it recursively if one of your records is in different type and you have to use parametric polymorphism, so it's not very convenient. For array of records you need to do it for every single element.
<wmeyer>
and that's why mrvn proposed this :-)
pootler__ has quit [Remote host closed the connection]
pootler_ has quit [Remote host closed the connection]
pootler has quit [Remote host closed the connection]
rwmjones has joined #ocaml
pootler has joined #ocaml
<whitequark>
hm, I want to override the (^) operator so it will do one of the following:
<whitequark>
no. I just want one of the following: 1) override the (^) operator so it could take either `string' or `utf16s' as its operands
<whitequark>
2) somehow insert a preprocessing step which turns string literals into something completely different
<whitequark>
ie, utf16s's.
<whitequark>
what's easier/saner?
<wmeyer>
either?
Yoric has quit [Ping timeout: 252 seconds]
<wmeyer>
you need to convert once the literal
<Drup>
having a custom operator for utf16s seem's easier and saner :3
<whitequark>
Drup: but it needs to be polymorphic
<wmeyer>
and then use the custom operators as Drup says
<wmeyer>
it can't be polymoprhic over range of types
<whitequark>
right
<whitequark>
that's the problem
<wmeyer>
it can be only polymorphic for any type
<wmeyer>
you need type directed dictionary lookup for that aka type classes
tane has quit [Quit: Verlassend]
<mrvn>
utf16 is stupid though
<Drup>
whitequark: why would you absolutely need that ? Can't you make everything utf16 ?
<wmeyer>
(or one of the first class module tricks, with type abstractions)
<whitequark>
Drup: I have a lot of literals in the code, and I concatenate those literals with external strings all the time
<amiller_>
i am observing some (i think) weird behavior trying to run a benchmark
<whitequark>
think compiler error messages
<whitequark>
not only that
snearch has joined #ocaml
<mrvn>
whitequark: use a variant type. U16 "foo"
<whitequark>
also: pretty-printing, various initialization of internal structures
<amiller_>
basically the problem is that it takes many trials (like 6, or 2 minutes worth) that run slower before it reaches a steady state that runs faster
<Drup>
whitequark: I still don't really see why you can't transform everything you got in utf16
<whitequark>
Drup: I don't want to manually prefix each single string literal with something
<whitequark>
that's just dumb
fayden has joined #ocaml
<amiller_>
all of the extra time during the first few iterations comes is in the 'sys' part, i'm using the Benchmark library that wraps Unix.get_stime
<mrvn>
whitequark: write a camlp4 thing to turn string literals into another type
<whitequark>
essentially, I wish the `string' type represented some kind of Unicode string and everything just used it
<whitequark>
mrvn: yes, that's what I'm thinking about
<Drup>
whitequark: there is something in batteries that transform every literal into utf8
<mrvn>
whitequark: check if libtext-ocaml doesn't already have one. It depends on camlp4
<mrvn>
Drup: batteries includes ocaml-text, right?
<whitequark>
mrvn: hm, thanks, seems useful
<whitequark>
I guess I can rip the camlp4 parts from it
<whitequark>
(it uses Cexts so I can't directly use it)
<Drup>
whitequark: I'm not sure how you are going to do a syntactic extension without campl4 :D
<whitequark>
Drup: no no, the libtext uses C
<whitequark>
camlp4 is fine, why wouldn't it be?
<Drup>
"I can rip the camlp4 parts from it"
<mrvn>
whitequark: what is wrong with C?
<whitequark>
mrvn: js_of_ocaml
<Drup>
oh, you mean rip as "extract", it was not clear
<whitequark>
Drup: yeah
<whitequark>
hm, it seems to be concerned only about RE syntax
<whitequark>
rather a complex automaton
<whitequark>
hm. actually I may just avoid that
<whitequark>
because pippijn's library stores utf16 as lists of codepoints
<whitequark>
I would be far better off storing everything in utf8 and converting only when I actually need utf16
milosn_ has joined #ocaml
<whitequark>
this will also imply that operands to (^) are always strings in their nature... I guess there should be some obscure way to tell the typechecker that `utf8s` actually is a `string`
<pippijn>
whitequark: how would you store it?
<pippijn>
whitequark: as string?
<whitequark>
pippijn: I, uh, won't
<whitequark>
or as an array of chars.
<pippijn>
char?
<pippijn>
char doesn't hold utf-16
<whitequark>
yep. two chars do.
<pippijn>
ok, yeah
<pippijn>
23:04 < pippijn> whitequark: as string?
<pippijn>
as string, then
<whitequark>
oh. well, yes
<pippijn>
whitequark: maybe I should, yes
<whitequark>
pippijn: well, I think that utf8 storage and processing is actually a much better fit
<pippijn>
this is the first time I implement unicode stuff :)
<whitequark>
since it will map to MlString everywhere in js_of_ocaml and something efficient in the native compiler too, and I won't waste space or spend time
<whitequark>
pippijn: I like your implementation
<whitequark>
utf-16 is my storage format of choice for the target, i.e. on-device representation
<whitequark>
it has various desirable characteristics
milosn has quit [Ping timeout: 276 seconds]
<pippijn>
such as?
<mrvn>
whitequark: why not utf-8?
<pippijn>
direct indexing if you know it contains only 16 bit characters
<whitequark>
yeah
<pippijn>
so you have a flag?
<whitequark>
also: simpler/faster to iterate
<whitequark>
pippijn: no, it's dependent on the code the user writes
<mrvn>
pippijn: 1) which isn't always true, 2. you don't do direct indexing on disk.
<whitequark>
I have a flag which enables 8-bit characters, though
<pippijn>
so the user is responsible for ensuring that only low characters are used?
<whitequark>
pippijn: as in, #each_codepoint or #each_character.
<whitequark>
yes
<pippijn>
ah
<whitequark>
since having such predictable cost model may be important in some cases
<whitequark>
I expose this
<mrvn>
If you need direct indexing then you should be using 32bit.
<whitequark>
mrvn: space is at a premium
<pippijn>
java is 16 bit, and direct indexing is halfword-wise
<whitequark>
mrvn: whichever way I implement it... that doesnt change the fact that I like his implementation. it has 32-bit as well :)
<whitequark>
pippijn: I will likely enhance my fork with more Extlib-derived stuff
<whitequark>
for example most of uses of lists in your library can be replaced with enumerations
<pippijn>
oh
<pippijn>
what is the representation of enumerations?
<pippijn>
they are lazy, right?
<mrvn>
.oO(a list)
<whitequark>
pippijn: lazy, yeah
<whitequark>
>Enumerations are entirely functional and most of the operations do not actually require the allocation of data structures. Using enumerations to manipulate data is therefore efficient and simple. All data structures in ExtLib such as lists, arrays, etc. have support to convert from and to enumerations.
<pippijn>
ok, that's nice
<pippijn>
whitequark: very nice
<pippijn>
but
<pippijn>
converting from and to something a few times will add indirections
<mrvn>
using enumerations means you become independent of the actual storage below them
<whitequark>
^
<pippijn>
utf16 -> utf8 -> utf16 will cascade the conversions
<whitequark>
pippijn: well, the initial from-utf16 conversion in my case only happens inside js_of_ocaml
<whitequark>
so I can optimize that easily
<whitequark>
all internal compiler representation is utf-8... and I mainly concatenate and store it, so that's ok
<whitequark>
I imagine examining it (apart from comparing) would be a problem, even more so indexing
<pippijn>
why does ocaml have tagged integers?
<pippijn>
does it make the GC faster?
<whitequark>
GC, arithmetics, less memory
<pippijn>
arithmetics?
<whitequark>
yes. allows to store integers in registers
<pippijn>
java integers are in registers
<whitequark>
as opposed to going through memory access each time you need to do something with those
<ousado>
java has two kinds of integers
<pippijn>
and .NET integers and structs are on the stack and potentially in registers, as well
<whitequark>
yeah, .NET value types are great
<pippijn>
ousado: right, so it's necessary for polymorphic code
fayden has quit [Read error: Operation timed out]
<pippijn>
and .NET can have value types because it creates new instances of generic code at runtime as required
osa1 has joined #ocaml
<mrvn>
pippijn: tagged integers are needed for the GC to be able to move blocks.
<pippijn>
mrvn: the .NET GC can move blocks
<pippijn>
and its integers are neither tagged nor boxed
<mrvn>
pippijn: are pointers?
<pippijn>
in .NET? no
<pippijn>
and that doesn't make sense
<mrvn>
pippijn: the GC needs a way to decide what is a integer and what a pointer. otherwise it can't move stuff.
<pippijn>
at all
<pippijn>
mrvn: in .NET that is easy
<pippijn>
because at every point in the program, it knows what something is
<pippijn>
stack maps
<mrvn>
pippijn: then the integers are tagged. Just not in the same word.
<pippijn>
no
<pippijn>
not the integers
<whitequark>
that's stretching the definition of "tagged" :)
<pippijn>
the locations they can be stored in are registered
<pippijn>
actually no
<pippijn>
only memory locations that can be pointers are registered
<mrvn>
pippijn: how is a type r = { next : r; data : int; } stored in .NET?
<pippijn>
if it's a value type, that is 2 words
<pippijn>
if it's a reference type, it's 2 words in an object
<mrvn>
pippijn: and somewhere it must say that next is a pointer and data an integer.
<pippijn>
if it's a reference type, the object has a pointer to structural information
<pippijn>
type-info
<pippijn>
if it's a value type, it's just flattened into the stack and contained in the stack map
<mrvn>
in both cases the values are then marked in some way. In ocaml that happens by tagging in the lower bits. Makes the info more localized.
<pippijn>
that's true
<pippijn>
I think some of my network code is unportable :)
<pippijn>
because I get 32 bit integers from the network, but store them in int
<mrvn>
kind of sucks on 32bit though since you often need every bit for an int there.
<pippijn>
I only have 64 bit computers and never test with 32 bit
<whitequark>
mrvn: you could say that it "tags" integers by absence of a pointer tag on them
<whitequark>
but that is really a stretch
<mrvn>
pippijn: I wrote int31 for that in extunix.
<pippijn>
mrvn: what does that do?
<whitequark>
the common meaning of "tagged pointer" is the one with some set of bits inside dedicated to tagging
<mrvn>
whitequark: lets say "it marks them"
<whitequark>
mrvn: sure. but I'm not sure what is the value of predicate "marked" in this context
<pippijn>
I wonder if it really helps that much..
<pippijn>
performance
<whitequark>
i mean it obviously does, so what
<mrvn>
pippijn: That is a 4 byte type with 31bit precision. So it works the same on 32bit and 64bit cpus.
<pippijn>
mrvn: ah
<pippijn>
mrvn: yeah, that's good
<pippijn>
how did you do that?
<whitequark>
hm, seems I need a camlp4 preprocessor to mark my literals as utf8-safe... doesn't seem very hard
<mrvn>
pippijn: just some functions that take or give an int and internally use (u)int32_t.
<ousado>
whitequark: you can use -ppx
<whitequark>
ousado: -ppx?
<pippijn>
oh
<ousado>
extension points or what they're called
<pippijn>
mrvn: I see
<mrvn>
pippijn: I wrote functions for endian conversion and storing/extracting from big arrays.
<pippijn>
extern C functions
<companion_cube>
hmmm, looks like Martin Jambon will never answer my pull request :(
<pippijn>
that's..
<pippijn>
ok
<whitequark>
ousado: not sure what you're talking about
tobiasBora has joined #ocaml
<pippijn>
not inlinable
<ousado>
whitequark: that's a new integrated preprocessor
<ousado>
-ppx is the compiler option
<pippijn>
oh yeah, bigarrays
<mrvn>
pippijn: yeah. Faster to do a C call then write my own endian conversion functions.
<pippijn>
aren't bigarrays just byte strings?
<pippijn>
endian conversion is 1 instruction on x86(_64)
<mrvn>
pippijn: bigarrays are references to largish blocks of memory not controlled by the GC.
<pippijn>
mrvn: so basically the same as strings
<whitequark>
ousado: oh, I'm stuck at 4.00.1
<pippijn>
ah, but strings are limited in size
<mrvn>
pippijn: without the 16MB limit and with sub arrays.
<whitequark>
js_of_ocaml
<pippijn>
ok, seems good
<pippijn>
I've never used them
<mrvn>
pippijn: Also, since they don't move, you don't need to copy them on read/write calls.
<ousado>
hm.
<pippijn>
ok
<mrvn>
pippijn: And you can write to a socket and then create a subarray of the stuff that didn't fit into the sockets buffer at minimal cost. With strings you would have to copy the rest or store string + offset.
<pippijn>
that's nice
<pippijn>
maybe I will use it
<pippijn>
I do have code that does things like that
<pippijn>
and it uses a string
<pippijn>
but I move stuff instead of copying
<mrvn>
does js_ocaml have endian conversion functions?
<pippijn>
memmove is pretty fast
<pippijn>
byte copy loops are fast on modern cpus
<mrvn>
not copying is faster. :-P
<pippijn>
I'm not sure
<whitequark>
pippijn: what?
<pippijn>
not copying is faster, yes
<whitequark>
byte copy loops?
<whitequark>
are you from 1993? :D
<pippijn>
whitequark: why?
<whitequark>
it's done in SSE since... when SSE appeared
<pippijn>
ok
<whitequark>
well, for non-overlapping ranges
ulfdoz has quit [Read error: Operation timed out]
zpe has joined #ocaml
Simn has quit [Quit: Leaving]
zpe has quit [Ping timeout: 276 seconds]
Macuser__ has joined #ocaml
Macuser__ has left #ocaml []
fayden has joined #ocaml
<whitequark>
gasche: ping
<adrien>
(it's past bedtime around here)
<whitequark>
I'm trying to make ocamlbuild invoke my camlp4 extension in the build process
<whitequark>
so I've found and adapted this from the net:
<whitequark>
flag ["ocaml"; "pp"; "use_utf8str"] (A"ucs/lib/pa_utf8str.cmo");
<whitequark>
but that results in a flag pp ucs/lib/pa_utf8str.cmo
<whitequark>
i.e. it tries to launch that as an executable
jbrown has quit [Remote host closed the connection]
zpe has joined #ocaml
ollehar has joined #ocaml
zpe has quit [Ping timeout: 246 seconds]
snearch has quit [Quit: Verlassend]
ollehar has quit [Read error: Operation timed out]
ollehar has joined #ocaml
tobiasBora has quit [Remote host closed the connection]
jayprich has quit [Ping timeout: 276 seconds]
ontologiae has quit [Ping timeout: 240 seconds]
osnr has joined #ocaml
osnr has quit [Changing host]
osnr has joined #ocaml
<pippijn>
does anything except coq target ocaml as its backend language?
<pippijn>
I mean programming languages, not DSLs
<Drup>
pippijn: Haxe
<pippijn>
oh
<pippijn>
interesting
<pippijn>
Drup: how high- or lowlevel is its output?
<Drup>
I have absolutely no idea :D
<Drup>
There is some Haxe people around here, wait a bit and one of them will eventually read this. :)
<pippijn>
ok, I'm not in a hurry
<pippijn>
but I'm thinking of targetting ocaml at some point
<pippijn>
I'm curious what kind of performance I'd get
<pippijn>
currently, it's C or java
<pippijn>
and the C backend is quite fast
<pippijn>
the java backend is incredibly slow
<pippijn>
much faster than the interpreter (in C), but still very slow
<Drup>
targeting java is strange, why not directly the JVM ?
<pippijn>
jvm is java
<pippijn>
it's almost a direct mapping
<pippijn>
and java code is easier to inspect
<pippijn>
at some point I will target the JVM
<pippijn>
but for now, this is convenient
<pippijn>
it's easier to make changes and experiment with java code than with bytecode
<pippijn>
native (via C): real 0m0.019s
<Drup>
afaik, the maping is not *that* direct and you avoid some complications
<pippijn>
interpreter: real 0m18.722s
<pippijn>
java: real 0m0.618s
<pippijn>
just some loops computing pow(i, j) for some large numbers
<Drup>
if you already have a C backend, why do you want an ocaml one ? I don't think you're going to have better performances with it
<pippijn>
Drup: it might
<bernardofpc>
pippijn: I'd be interested do know such cases
<pippijn>
actually I wanted the java backend, because I wasn't happy with the lack of type-safety in my generated code
<pippijn>
a lot of int <-> word going on
<pippijn>
implicitly
<bernardofpc>
most micro-benchs I have made this year make OCaml lose to C
<pippijn>
which is fine
<pippijn>
but not nice
<pippijn>
and it's not nice to have such inconsistencies in my IR
<pippijn>
and in java, that's impossible, because everything is an object
<pippijn>
which might be the reason it's so slow :)
<pippijn>
even ints are objects
<pippijn>
Drup: it might be faster when targetting ocaml, because it's optimised for functional stuff, and the backend produces quite a lot of closures
<pippijn>
also, GC
<pippijn>
ocaml's GC is fast
<pippijn>
our GC is a conservative one
<mrvn>
pippijn: ocaml doesn't optimize
<pippijn>
which, by the way, makes it impossible to debug with valgrind
<pippijn>
(we have to turn off the GC for that)
<pippijn>
mrvn: no, but it has an efficient execution model
<pippijn>
also, I'd be interested in making FFI with ocaml
<pippijn>
and it's just fun to develop a backend :)
<mrvn>
pippijn: you can forget mostly about that. You either have to hand craft it or generate code that copies the data between the internal and external data model all the time
<pippijn>
uhm
<pippijn>
I think I'll have a lot of ocaml records
csakatoku has joined #ocaml
<mrvn>
You can't just throw a C header file at some converter and get an ocaml interface out of it.
<pippijn>
and those can be passed back and forth
<pippijn>
mrvn: why not?
<mrvn>
because there is too much hidden stuff not present in the header.
<mrvn>
pointers escaping into the lib or from the lib into your code. Who is supposed to free the pointer and when?
<pippijn>
that's true
travisbrady has joined #ocaml
<mrvn>
so for anything not totaly trivial an automatic conversion will fail
<pippijn>
but you can get a start
<mrvn>
Those converters I looked at all build stubs to copy between ocaml records and c structs so the data gets converted on every call.
<pippijn>
ah
<pippijn>
I wouldn't do that
<pippijn>
I don't do that
<pippijn>
I have accessor functions for C struct values
<mrvn>
sometimes you must. other times you can keep the type abstract.
<pippijn>
I almost always have abstract types
<mrvn>
sometimes you need a custom block with finalizer, sometimes not. and so on.
<pippijn>
the finaliser can be done in ocaml
<whitequark>
>Warning 18: this ground coercion is not principal.
<whitequark>
what is that supposed to mean?
<mrvn>
pippijn: better to use a custom block with all the hooks.
<pippijn>
but yeah, I see what you mean
<pippijn>
yes
<pippijn>
but
<mrvn>
Which reminds me. I wanted to create an abstract equivalent of Unix.file_descr as custom block with finalizer. Warn when a FD isn't closed properly and such.
<pippijn>
if I target ocaml, I don't need to worry about such things
<pippijn>
mrvn: that's nice, you should do it
<mrvn>
After my network protocol framework
<mrvn>
I'm a bit stuck with epoll. I want to register the FD with EPOLLIN level triggered and EPOLLOUT edge triggered. Looks like I have to dup() the FD and register one for in and one for out seperately.
<pippijn>
why don't you use libev?
<mrvn>
pippijn: and that helps how?
<pippijn>
I don't know what you are doing, but you want to poll fd events, so what do you need that an event library doesn't provide?
<mrvn>
"There is a GC related issue that will eventually cause a segmentation violation, so it is not advisable to use this for anything except small hacks :-)." Sounds like a perfect solution, oh jeah.
<mrvn>
pippijn: I need level trigger for input and edge trigger for output.
<pippijn>
mrvn: I'm not talking about the ocaml libev bindings
<pippijn>
obviously it's possible to bind libev without segfaults
<pippijn>
Lwt uses it
ollehar has quit [Ping timeout: 260 seconds]
<mrvn>
I don't see lwt providing any polling interface.