krono has quit [Remote host closed the connection]
q66 has quit [Quit: Leaving]
tobiasBora has quit [Quit: Konversation terminated!]
watermind has quit [Quit: Konversation terminated!]
watermind has joined #ocaml
lostcuaz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lostcuaz has joined #ocaml
lostcuaz has quit [Client Quit]
Dongyancai has quit [Ping timeout: 252 seconds]
Dongyancai has joined #ocaml
ollehar has joined #ocaml
madroach has quit [Ping timeout: 252 seconds]
malo has quit [Quit: Leaving]
madroach has joined #ocaml
NoNNaN has quit [Remote host closed the connection]
Dongyancai has quit [Ping timeout: 265 seconds]
Dongyancai has joined #ocaml
NoNNaN has joined #ocaml
jonludlam has quit [Quit: Leaving]
zpe has joined #ocaml
Simn has quit [Quit: Leaving]
dsheets has quit [Ping timeout: 245 seconds]
zpe has quit [Ping timeout: 264 seconds]
NoNNaN has quit [Remote host closed the connection]
NoNNaN has joined #ocaml
thomasga has joined #ocaml
cdruzac has quit [Quit: Leaving]
S11001001 has joined #ocaml
S11001001 has quit [Changing host]
S11001001 has joined #ocaml
n0v has quit [*.net *.split]
IbnFirnas_ has quit [*.net *.split]
darkf has quit [*.net *.split]
claudiuc has quit [*.net *.split]
rz has quit [*.net *.split]
gambogi has quit [*.net *.split]
knz has quit [*.net *.split]
olasd has quit [*.net *.split]
julm has quit [*.net *.split]
tchell has quit [*.net *.split]
saml has quit [*.net *.split]
bitbckt has quit [*.net *.split]
_habnabit has quit [*.net *.split]
gereedy has quit [*.net *.split]
watermind has quit [Quit: Konversation terminated!]
talzeus has quit [Read error: Connection reset by peer]
Dongyancai has quit [Ping timeout: 240 seconds]
morolin has joined #ocaml
tlockney_away is now known as tlockney
Dongyancai has joined #ocaml
<morolin>
Is there a good way to write a function that takes a list and an integer (n) as an input, and returns a list with the nth element modifed in some way?
<morolin>
I'd rather avoid using fold_left, since in most cases, I will be modifying elements from the beginning of the list
<morolin>
Looking at the "List" module, I see "nth" which will let me get the nth element, but nothing that'll let me replace it.
<morolin>
I.e., I would like to have a function whose type is: 'a list -> int -> ('a -> 'a) -> 'a list
ygrek has joined #ocaml
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
tlockney is now known as tlockney_away
ygrek has quit [Ping timeout: 245 seconds]
smiler has quit [Ping timeout: 245 seconds]
darkf has joined #ocaml
claudiuc has joined #ocaml
rz has joined #ocaml
gambogi has joined #ocaml
knz has joined #ocaml
olasd has joined #ocaml
julm has joined #ocaml
tchell has joined #ocaml
saml has joined #ocaml
bitbckt has joined #ocaml
_habnabit has joined #ocaml
gereedy has joined #ocaml
smiler has joined #ocaml
thomasga has quit [Quit: Leaving.]
tautologico has joined #ocaml
aurynj has joined #ocaml
ygrek has joined #ocaml
Dongyancai has quit [Ping timeout: 268 seconds]
Dongyancai has joined #ocaml
Dongyancai has quit [Ping timeout: 240 seconds]
Dongyancai has joined #ocaml
michael_lee has joined #ocaml
talzeus has joined #ocaml
Dongyancai has quit [Ping timeout: 265 seconds]
Dongyancai has joined #ocaml
ollehar has quit [Ping timeout: 240 seconds]
Dongyancai has quit [Ping timeout: 252 seconds]
Dongyancai has joined #ocaml
Dongyancai has quit [Ping timeout: 268 seconds]
Dongyancai has joined #ocaml
Dongyancai has quit [Ping timeout: 240 seconds]
Dongyancai has joined #ocaml
Dongyancai has quit [Ping timeout: 264 seconds]
Dongyancai has joined #ocaml
yacks has joined #ocaml
jao has quit [Ping timeout: 268 seconds]
ygrek_ has joined #ocaml
ruzu has joined #ocaml
ruzu has quit [Read error: Connection reset by peer]
ruzu has joined #ocaml
ruzu has quit [Changing host]
ruzu has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
siddharthv_away is now known as siddharthv
siddharthv is now known as siddharthv_away
justinfront has joined #ocaml
divyanshu has joined #ocaml
siddharthv_away is now known as siddharthv
divyanshu has quit [Quit: Computer has gone to sleep.]
siddharthv is now known as siddharthv_away
siddharthv_away is now known as siddharthv
divyanshu has joined #ocaml
justinfront has quit [Ping timeout: 268 seconds]
claudiuc has quit [Remote host closed the connection]
basus1 has quit [Ping timeout: 240 seconds]
basus1 has joined #ocaml
cantstanya has quit [Quit: k]
ygrek has joined #ocaml
ygrek_ has quit [Ping timeout: 240 seconds]
michael_lee has quit [Remote host closed the connection]
cantstanya has joined #ocaml
csakatoku has joined #ocaml
nikki93 has joined #ocaml
ggole has joined #ocaml
axiles has joined #ocaml
ygrek has quit [Ping timeout: 265 seconds]
michel_mno_afk is now known as michel_mno
nikki93 has quit [Remote host closed the connection]
siddharthv is now known as siddharthv_away
claudiuc has joined #ocaml
claudiuc_ has joined #ocaml
nikki93 has joined #ocaml
claudiuc has quit [Ping timeout: 268 seconds]
rand000 has joined #ocaml
claudiuc_ has quit [Remote host closed the connection]
nikki93 has quit [Ping timeout: 245 seconds]
demonimin has quit [Ping timeout: 246 seconds]
talzeus has quit [Read error: Connection reset by peer]
talzeus has joined #ocaml
ygrek has joined #ocaml
wwilly has joined #ocaml
<wwilly>
bonjour
S11001001 has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
talzeus has quit [Remote host closed the connection]
talzeus has joined #ocaml
maattdd has joined #ocaml
aurynj has quit [Quit: Leaving]
yacks has quit [Remote host closed the connection]
csakatoku has quit [Remote host closed the connection]
csakatoku has joined #ocaml
Thooms has joined #ocaml
Kakadu has joined #ocaml
n0v has joined #ocaml
tane has joined #ocaml
cantstanya has quit [Quit: k]
Hannibal_Smith has joined #ocaml
ygrek has quit [Ping timeout: 265 seconds]
maattdd has quit [Ping timeout: 268 seconds]
talzeus has quit [Read error: Connection reset by peer]
maattdd has joined #ocaml
Thooms has quit [Quit: WeeChat 0.3.8]
ygrek has joined #ocaml
IbnFirnas_ has joined #ocaml
ikaros has joined #ocaml
thomasga has joined #ocaml
Simn has joined #ocaml
divyanshu has quit [Quit: Computer has gone to sleep.]
divyanshu has joined #ocaml
beurks has quit [Ping timeout: 240 seconds]
wwilly has quit [Quit: This computer has gone to sleep]
talzeus has joined #ocaml
<Drup>
morolin: you will have to write it by iterating on the list and counting
<Drup>
but you will have to rewire the list up to the element you want to change
<Drup>
so the complexity is going to be O(n) anyway
avsm has joined #ocaml
avsm has quit [Ping timeout: 252 seconds]
Yoric has joined #ocaml
siddharthv_away is now known as siddharthv
thomasga has quit [Quit: Leaving.]
thomasga has joined #ocaml
<companion_cube>
gasche: this PR about cycling printing makes me wondering, could such a printer be defined in userland code?
justinfront has joined #ocaml
krono has joined #ocaml
<krono>
good morning
<krono>
I read on wikipedia, that, while CamlLight was based on the CAM, OCaml is not
csakatoku has quit [Remote host closed the connection]
<krono>
if this is right, is there an Abstract machine OCaml is based on? Is there a paper?
<def-lkb>
ousado & companion_cube: actually, it's a fork of ocaml typechecker. It's binary compatible with cmi & cmt from compiler, but in read only
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
<ousado>
def-lkb: does it predate compiler-libs?
zpe has quit [Ping timeout: 268 seconds]
rand000 has quit [Ping timeout: 268 seconds]
siddharthv is now known as siddharthv_away
tane has joined #ocaml
Thooms has joined #ocaml
thomasga has quit [Quit: Leaving.]
thomasga has joined #ocaml
dsheets has joined #ocaml
thomasga1 has joined #ocaml
thomasga has quit [Ping timeout: 240 seconds]
csakatoku has quit []
thomasga1 has quit [Quit: Leaving.]
<def-lkb>
ousado: no
<def-lkb>
but compiler-libs is not flexible enough for merlin, though some patches could improve the situation
ygrek has quit [Ping timeout: 268 seconds]
nikki93 has joined #ocaml
nikki93 has quit [Ping timeout: 265 seconds]
avsm has quit [Quit: Leaving.]
thomasga has joined #ocaml
thomasga has quit [Ping timeout: 265 seconds]
justinfront has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0/20140318013849]]
<gasche>
krono_away: why would you want to write a jit for ocaml? I think that's mostly useless (or at least not worth the effort)
krono_away is now known as krono
<krono>
gasche: I got an execution model that somewhat resembles ML
<krono>
Its purpose is to test data structure optimization
<krono>
In the end, I do not want to write a JIT manually but have it generated
maattdd has quit [Ping timeout: 264 seconds]
<gasche>
by "ML execution model", do you mean small-step semantics for surface languages, or abstract/bytecode machines?
<krono>
in-between
<gasche>
and what kind of data structure optimization?
zpe has joined #ocaml
<krono>
automatic transparaent inlining of (possibly deeply nested) Constructors
<gasche>
I don't get it, do you have an example?
<gasche>
(you mean constructor in the usual algebraic-datatype sense?)
<krono>
(I don't know)
<krono>
an example would be: Cons is a binary constructor
<gasche>
so yes
<gasche>
inert thing that just builds data
<krono>
TIL :D
<krono>
exactly
<gasche>
ML datatype declarations are called "algebraic" because of their sums-of-products nature
<krono>
ah
<gasche>
(sums being disjoint variants, products being conjunctions of several parameters)
<krono>
yes
divyanshu has quit [Quit: Computer has gone to sleep.]
<krono>
So having these, I for example would take a Cons-cell list and inline it to an array-like structure just-in-time and transparent to the language
<krono>
The point is I currently have to rely on the immutability of such structures, which not many languages provide
<flux>
cool idea
thomasga has joined #ocaml
<krono>
And I actually stumbled with OCaml when I tried to map the blocks (ZINC blocks?) to my model of Constructors
<flux>
I had a similar one a long time ago, that one should implement an oracle data structure that can implement all kinds of high-level operations, such as sorting, getting min/max, getting nth element, associating by key, etc
<krono>
because blocks are only “mostly” immutable
<flux>
then one could run benchmarks and the oracle could be replaced with a datastructure most suitable for the work load
<gasche>
OCaml has mutable records/parameters, but you could remove those
<gasche>
you will still need something for building fixpoints, though
<ousado>
krono: would that example imply some kind of look-ahead? (regarding what's going to happen later with that list)
<krono>
gasche: I know that there are explicit things in the Language to mark mutable data
<krono>
but these do not really reflect in the bytecode :(
<krono>
ousado: no, I just assume the list is immutable
<krono>
ousado: also, the actual problem is that I destroy/reassemble data during optimization and references to data that changes somewhen is simply lost
<ggole>
krono: if you map lists to vectors, how do you preserve sharing?
<ggole>
(I think I know how this might be done, but I'd like to hear your story.)
<krono>
ggole: not at all
<ousado>
that was how I should have asked my question
<krono>
the point is, the mapping is transparent to the language level and only happens at implenetation level
<ggole>
Sure, but how do you *implement* it?
<ggole>
Lists have certain "performance semantics", if you like
<ousado>
does not at all mean you copy the whole thing?
rand000 has joined #ocaml
<krono>
I record what the list “looks like” (call ti shape)
<krono>
and when I mash the data together, I store what the actual data shape was
<krono>
ousado: yes, I am constantly copying
<ggole>
I see: that's not what I was expecting at all
<krono>
but the Facility I use to have a JIT is _very_ good at allocation removal :D
<ousado>
so when you create another list, prepending an element to the Nth element, you copy all N+ elements to a new array?
<krono>
yep, that is how the interpreter does it
lostcuaz has joined #ocaml
<krono>
however I employ a meta-tracing jit that records what is done and is able to remove most of the copying
<ggole>
The trick I was expecting is that you can implement lists as pair of pointer+distance-to-end-of-vector into (possibly short) vectors
<krono>
ggole: that would be a neat one, but it turns out that this is not necessary with the jit
<gasche>
more generally you can "buffer" list into linked list of vectors to get a compromise between atomicity of sharing and locality
jonludlam has joined #ocaml
<ggole>
I don't see how a jit solves the sharing problem
<krono>
not a jit per se but the allocation removal
<gasche>
I tend to suspect that the overhead of the JIT makes it not that interesting compared to simple native code generation
<krono>
see: typically you just take something out of a list to put it in annother one (map, apply, reverse etc.)
<krono>
this makes the allocations short-livbed
<krono>
s/b//
<ousado>
you want to do that just in time (instead of doing static analysis ahead of time)?
<companion_cube>
gasche: depends on how sophisticated it is, imho
<gasche>
(also allocation is not very expansive in OCaml)
<companion_cube>
what if you always call a polymorphic combinator with a given partially applied function?
<companion_cube>
you get much more information at runtime
<krono>
gasche: I do not use the C code
ygrek has joined #ocaml
<flux>
very often when you build a new list from a head and a tail you could just as well be writing backwards to an array?
<def-lkb>
if the jit can do some escape analysis, this might make sense
<companion_cube>
the point is sharing
<ggole>
krono: is this like the "shape" stuff that the PyPy guys were working on?
<krono>
companion_cube: I ignore sharing for the moment
<krono>
gasche: Yep
<krono>
I use RPython, actually
<ggole>
The problem I see with that approach is that Python lists own their contents opaquely, whereas OCaml lists allow you direct visibilty into the constructors
<ggole>
I won't say it's impossible, but it seems problematic.
<krono>
companion_cube: mostly, identity is irrelevant for immutable data, and sharing is less of a problem
<krono>
ggole: the things I do have nothing in common with pythons semantic
<krono>
ggole: can you elaborate on that last part (direct vistibily?)
<ggole>
It's the opaqueness that is the issue, nothing to do with Python in particular
<krono>
why?
<ggole>
Because you can cons an element onto any part of any list at any time
beurks has joined #ocaml
<ggole>
So you cannot simply assume that there is one canonical pointer into a vector of elements, for example.
<ggole>
List structure forms arbitrary DAGs in OCaml
<companion_cube>
I'd be very interested by a notion of "transient" in OCaml
<companion_cube>
with escape analysis
<ggole>
And when you cons onto part of a list, there is no information on whether other pointers to that list structure exist
<companion_cube>
stuff that is not shared, that is totally owned by the current frame
<krono>
ggole: yes, I actually anticipate the DAG-nature
divyanshu has joined #ocaml
<ggole>
krono: OK. I'm interested to hear how that works.
<krono>
ggole: as long as the data is immutable, I can freely copy it around and i don't need the references to it
<ggole>
That would seem to lose both sharing and O(1)ness of cons?
<krono>
ggole: yes, on the interpreter level
<ggole>
(Fine for short lists, I guess.)
<gasche>
companion_cube: there is internally for references and boxing
<gasche>
(and staticcatch)
<companion_cube>
gasche: I suppose it would be quite complicated to extend?
<companion_cube>
the more you can put on the stack, or unbox, the more efficient
<companion_cube>
also, tail-consing would be more doable
<gasche>
well the natural extension would be linear typing and unboxed types
<krono>
ggole: the rpython-jit then elides most of the superfluous copying an access is fast again
<gasche>
but is it really worth polluting the language design with that much complexity if a simple local optimization can reap 80% of the benefits?
<ggole>
I'd be happier if OCaml did tail-consing :(
<ggole>
Non tail-recursive map is so sad.
<def-lkb>
ggole: +1
<companion_cube>
gasche: 80% seems high
<companion_cube>
full linear typing is probably much more complicated than transients, isn't it?
<companion_cube>
I'm quite sad that the beautiful functional programs on lists are often not tailrec
<companion_cube>
and therefore not that useful
<ggole>
krono: again, I don't see what the jit has to do with it. If you have a long list sitting around and somebody conses onto it, how do you "elide the copying" without retaining the existing share-by-pointing structure of lists?
<krono>
I do not retain that
<krono>
If you cons onto a list, you get a completely new one
<ggole>
...that's copying
<krono>
yep
<krono>
that is how I write the interpreter
<def-lkb>
but that would not fit ocaml at all
<ggole>
krono: OK. Thanks for taking the time to explain it.
<gasche>
I think krono's idea is to reuse a part of the bytecode design (to get efficient bytecode instructions for a functional language), but not optimize OCaml code
<ggole>
companion_cube: are you asking for tail-call-modulo-cons?
<ggole>
(That *would* be nice.)
<companion_cube>
ggole: or modulo other constructors
<companion_cube>
(trees?)
<ggole>
Right
<ggole>
You can do it with trees afaik, but you have to pick a side.
<krono>
gasche: somewhat like that, yes
<companion_cube>
I mean, it's really sad that you have to use CPS or reverse to work on lists
<ggole>
Agreed.
<ggole>
And there are (possible) hacks such that you wouldn't need a write barrier.
avsm has joined #ocaml
<ggole>
(Although that would need both compiler and runtime support, I think.)
<companion_cube>
such as keeping the first node in the stack?
<companion_cube>
so that it's always traversed by the GC
<ggole>
No, you don't need to do that.
<ggole>
The trick is to notice that because you are mutating fresh list structure, the pointer-from-old-to-new is only possible if there is a GC in the interim that moves the old node out of the nursery
<ggole>
If that doesn't happen, there's no need for the barrier
<companion_cube>
oh
<ggole>
So what you do is that you mark the frame table to say "put that pointer in the remembered set"
<companion_cube>
so, you need to check whether the GC ran or not
<ggole>
Then the barrier can be elided.
<ggole>
Essentially it has been moved into the GC, where it will run far less often.
<ggole>
In this way it should be possible to make map written in the obvious way both tail recursive and fast.
<companion_cube>
ohhh, you mean the GC would automatically use the current list value (in the stack frame) as a root?
<ggole>
No
<ggole>
The purpose of the write barrier is to place objects into the "remembered set", that is, a set of objects in the major heap that may point into the nursery
<ggole>
This set is required because when the nursery is collected, pointers into it need to be adjusted.
<ggole>
If you use this GC frame table trick, this is achieved without using the write barrier
<ggole>
(Depending on the fact that the mutated structure is guaranteed to be freshly allocated.)
<ousado>
ggole: so that'd require N slots in the remembered set, right?
Hannibal_Smith has quit [Quit: Sto andando via]
<ggole>
Well, the remembered set is of arbitrary size anyway
<ggole>
And I wouldn't think that you'd have very many tail-consing pointers to put on it
<ousado>
hm.. yes but still it's some cache pollution etc.
<ggole>
Right, but the ordinary write barrier does the same thing
<companion_cube>
ggole: if you need to do it for every cons node, it's big
<ggole>
And the ordinary write barrier would run for every element
<companion_cube>
otoh if you have a tailrec function
<ggole>
companion_cube: that's the beauty of this trick
<companion_cube>
the current list node is always in the same frame
<ggole>
It's only the one node that you need to put into the set
<companion_cube>
so you can indeed tell the GC to put a barrier on this one
<ggole>
If you think of it in generation lifetimes, a consed-up list might look like this: 2 -> 2 -> 2 -> 2 -> 1 -> 1 -> 1
<ggole>
The only time the write barrier is actually needed is when a GC happens: ie, the transition from 2 -> 1
<ggole>
That node needs to go into the remembered set.
<companion_cube>
yes, but you need to know when the GC runs
<companion_cube>
so you check it at every call?
<ousado>
ah
<ggole>
That's why you put the info in the frame table
<ousado>
I get it now
<ousado>
nice
<ggole>
When the GC runs, it will look at the table and know "something in this frame is about to be mutated"
<companion_cube>
ggole: what is the frame table exactly? :s
<companion_cube>
hmm, sure
<ggole>
Then it will put that pointer in the remembered set
<ggole>
A table describing how to find pointers on the stack for relocation by the GC
<companion_cube>
does it already exist?
<ggole>
(The format would have to be changed to allow for this technique, unfortunately.)
<companion_cube>
that's nice anyway
<ggole>
Frame tables are emitted already, yes.
<companion_cube>
thanks for explaining :)
<ggole>
I *think*, but I'm not quite sure, that this is how some Prolog implementations used to work
<ggole>
(I know they pioneered tail-call-modulo-cons, at least.)
talzeus has quit [Remote host closed the connection]
<companion_cube>
they have a weird abstract machine anyway
<ggole>
That's just a model: doesn't prevent you compiling to native code
<ggole>
Like Haskell's STGM or whatever that is
<companion_cube>
STG-machine, yes
<companion_cube>
but still, a prolog runtime is peculiar
<companion_cube>
because you need unification in it
<ggole>
I have a few papers on the history of prolog implementation sitting around, but I haven't really dug into them seriously
<ggole>
Seems like a very interesting but sadly mostly irrelevant subject
<companion_cube>
ggole: if you're interested, there's even better with the tabling prolog variants
darkf has quit [Quit: Leaving]
<ggole>
Hmm?
<companion_cube>
XSB-prolog, for instance, can detect some "loops"
<companion_cube>
so you can query graphs or things like this
talzeus has quit [Remote host closed the connection]
talzeus has joined #ocaml
rand000 has quit [Ping timeout: 264 seconds]
nikki93 has joined #ocaml
<companion_cube>
that looks pretty overkill for css...
<adrien_oww>
why? if you could describe more, do less javascript and let the engine handle as much as possible, you could get lower overall cpu usage and most importantly, less wakeups
nikki93 has quit [Ping timeout: 252 seconds]
talzeus has quit [Read error: Connection reset by peer]
talzeus has joined #ocaml
<companion_cube>
I mean, you'd need big CSS for this to matter, wouldn't you?
talzeus has quit [Read error: Connection reset by peer]
<companion_cube>
a JIT for javascript is more reasonable because people often write a lot of code
talzeus has joined #ocaml
talzeus has quit [Remote host closed the connection]
talzeus has joined #ocaml
<def-lkb>
companion_cube: I read "JIT for CSS" as "we implemented an automaton for quickly computing matches"
<ygrek>
is there a way to setup on_cancel on lwt thread, and make subsequent Lwt.cancel invoke this on_cancel without setting thread state to Canceled?
<def-lkb>
(it's just less sexy)
<ygrek>
* invoke this on_cancel handler
<def-lkb>
(but makes sense, more than their… "Interpreter pattern")
<ygrek>
i.e. the task that handles canceling but signals it in some other different way
jonludlam has quit [Ping timeout: 268 seconds]
divyanshu has quit [Quit: Computer has gone to sleep.]
<NoNNaN>
ggole: just wait for the first jit exploit, for proper selector/xpath performance they should use better data structures eg.: vtd-xml
<adrien_oww>
companion_cube: "big CSS" is another way to say "the amount of css you routinely get on websites currently"
<companion_cube>
maybe that's the problem -_-
<companion_cube>
def-lkb: automaton compiled to native code, yes
divyanshu has joined #ocaml
<ygrek>
here is a test case : let t = Lwt.bind (Lwt_unix.sleep 3.) (fun () -> print_endline "happy"; Lwt.return ()) in Lwt.on_cancel t (fun () -> print_endline "handled"); Lwt.cancel t; Lwt_main.run t
jonludlam has joined #ocaml
mfp_ is now known as mfp
mcclurmc has joined #ocaml
<mfp>
ygrek: maybe using Lwt.protected? This way the original thread is not actually canceled, but the "wrapper" is and can invoke the on_cancel callback for the original thread
<ygrek>
I am playing with it now...
<ygrek>
that's for curl_lwt
<ygrek>
the question is - what would you expect to happen with Lwt.cancel on Curl_lwt.perform?
<mfp>
for high-level wrappers, something like: closing the channels, aborting curl opt, releasing any resources
<ygrek>
and raising Canceled
<mfp>
not merely closing, but rather Lwt_io.abort on them
<mfp>
yes, for the initial op
<mfp>
(after curl's got the headers, you only interact via the channels)
<mfp>
in my curl-lwt, the intf was like lwt code, headers, ich = Curl_lwt.get url
<ygrek>
will do that, but sometime low-level interface is needed
<mfp>
so if you cancel before that completes, it raises Canceled right there, but if you do it later it's the operations on ich that raise
<mfp>
# let setup t lbl = Lwt.on_cancel t (fun () -> print_endline lbl) in let t1, _ = Lwt.task () in setup t1 "1"; let t2 = Lwt.protected t1 in setup t2 "2"; Lwt.on_cancel t2 (fun () -> print_endline "and now we invoke t1's on_cancel if we want"); Lwt.cancel t2;;
<mfp>
and now we invoke t1's on_cancel if we want
<mfp>
2
<mfp>
- : unit = ()
<ygrek>
yes, that works
<ygrek>
I have one "moral" problem
<ygrek>
usual way of course for low-level perform is : let h = Curl.init () in lwt code = Curl_lwt.perform h in Curl.cleanup h
<ygrek>
currently it doesn't handle on_cancel at all. what happens after Lwt.cancel is that the invoking side moves on and downloads finish on their own and call cleanup..
<ygrek>
when I setup on_cancel - the thread gets killed at Curl_lwt.perform and cleanup is never called
<ygrek>
but download is interrupted immediately
lostcuaz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ygrek>
I guess that should be made the responsibility of the caller (of Curl_lwt.perform) to handle canceling too
<ygrek>
but I guess leaving "dangling" lwt threads around is bad anyway
<ygrek>
so I better handle on_cancel and make the user responsible if he is brave enough to use low-level interface
krono has left #ocaml []
<mfp>
would it make sense to force to install a writefunction so that you can tell curl when it's over
<ygrek>
no, not at this level
<ygrek>
and that's not the problem
<ygrek>
curl is actually halting the transfer ok
<ygrek>
but resource handling is not in scope of Curl_lwt.perform
<ygrek>
as with usual Curl.perform
<mfp>
not sure I'm seeing the pb, but would Lwt.on_termination help in the above snippet?
<ygrek>
the ideal solution I would like is to make sure that perform reacts to Lwt.cancel but doesn't raise Canceled itself
<ygrek>
rather curl will halt the transfer and make the handle return some CURLE error
<mfp>
you said curl halts OK, is that thanks to a timeout?
<ygrek>
no, easy handle is removed from the multi handle
<ygrek>
that's I think a correct way to abort transfer at any time with multi
<ygrek>
ok, now I see the "impossibility" - if I react to cancel the way described above - it means that surrounding code called cancel and moved on considering tasks canceled, but they are left alive and dangling around
<ygrek>
dangling tasks are obviously bad
<ygrek>
so Canceled should be raised
<ygrek>
thanks for the discussion
<mfp>
I'm being silly here: lwt code = try_lwt Curl_lwt.perform h finally Curl.cleanup h; return_unit in
<ygrek>
mfp, ^^
mcclurmc has quit [Remote host closed the connection]
<mfp>
I'm not quite seeing the pb if curl is interrupting the operation correctly
shinnya has joined #ocaml
Yoric has joined #ocaml
<ygrek>
yes, you are right
<ygrek>
I think I got things clear in my head
<ygrek>
perfrom may raise Canceled - that's user's responsibility to handle it
nikki93 has joined #ocaml
mcclurmc has joined #ocaml
<ygrek>
I don't see Canceled being documented for many Lwt ops - is it like commonly understood that user should be expecting Canceled raised at arbitrary points if e uses Lwt.cancel?
<ygrek>
i.e. I shouldn't write for every function in ocamldoc comments that task may raise Canceled ?
<mfp>
something like "all operations on [t] can be canceled and may thus raise Lwt.Canceled" would do
wwilly_ has joined #ocaml
<mfp>
it's definitely expected to get Canceled exns when you cancel things around
<ygrek>
ok, tq
wwilly_ has quit [Client Quit]
<mfp>
Lwt_unix states something similar "Most operations on sockets and pipes (on Windows it is only are {b cancelable}, meaning you can cancel them with {!Lwt.cancel}."
wwilly has joined #ocaml
nikki93 has quit [Ping timeout: 265 seconds]
Yoric has quit [Ping timeout: 265 seconds]
wwilly has quit [Client Quit]
wwilly has joined #ocaml
<mfp>
and Lwt.cancel's docs do state "... the deepest sleeping thread created with [task] and connected to [t] is woken up with the exception {!Canceled}"
<wwilly>
hi
<ygrek>
yeah, cancel is a powerful thing, I omitted it initially from my picture of lwt..
ikaros has quit [Quit: Ex-Chat]
mcclurmc_ has joined #ocaml
nikki93 has joined #ocaml
mcclurmc has quit [Ping timeout: 264 seconds]
jwatzman|work has joined #ocaml
jonludlam has quit [Ping timeout: 265 seconds]
nikki93 has quit [Remote host closed the connection]
jonludlam has joined #ocaml
lostcuaz has joined #ocaml
<ygrek>
do I understand correctly that in `try_lwt .. with exn -> e1 finally e2` e2 is called before e1..?
<ygrek>
is that natural?
Hannibal_Smith has joined #ocaml
zarul has joined #ocaml
<ygrek>
especially that `try_lwt .. finally .. with exn -> ..` order is not supported
<ygrek>
by syntax extension
NoNNaN has quit [Ping timeout: 265 seconds]
jonludlam has quit [Ping timeout: 265 seconds]
<ygrek>
mfp? ^^^
<ygrek>
..sorry for highlighting :)
<ygrek>
but that's just strange
Kakadu has quit [Quit: Page closed]
NoNNaN has joined #ocaml
avsm has quit [Quit: Leaving.]
rand000 has joined #ocaml
tlockney_away is now known as tlockney
Yoric has joined #ocaml
mcclurmc_ has quit [Remote host closed the connection]
<Drup>
you can ask jpdeplaix about it too, it's his current subject :p
tlockney is now known as tlockney_away
tlockney_away is now known as tlockney
ollehar has quit [Ping timeout: 265 seconds]
mcclurmc has quit [Read error: Connection reset by peer]
Hannibal_Smith has quit [Ping timeout: 240 seconds]
willy_ has joined #ocaml
Yoric has joined #ocaml
ollehar has joined #ocaml
malvarez has joined #ocaml
michael_lee has joined #ocaml
ygrek has quit [Ping timeout: 265 seconds]
zpe has joined #ocaml
zpe has quit [Ping timeout: 265 seconds]
rand000 has quit [Ping timeout: 240 seconds]
claudiuc_ has joined #ocaml
claudiuc has quit [Remote host closed the connection]
_andre has quit [Quit: leaving]
nikki93 has quit [Remote host closed the connection]
nikki93 has joined #ocaml
tane has joined #ocaml
claudiuc_ has quit [Ping timeout: 268 seconds]
claudiuc_ has joined #ocaml
claudiuc has joined #ocaml
claudiuc_ has quit [Ping timeout: 252 seconds]
ggole has quit []
tlockney is now known as tlockney_away
rand000 has joined #ocaml
rand000 has quit [Quit: leaving]
avsm has quit [Quit: Leaving.]
avsm has joined #ocaml
Thooms has quit [Read error: Connection reset by peer]
Thooms has joined #ocaml
<maurer>
Is there an easy way to dump the list of modules in a .cmxa file?
<maurer>
I'm having a weird problem with an overly complex build system where I'm being told when I try to link the .cmxa file that some of the modules didn't get in there somehow
<adrien>
maurer: try ocamlobjinfp
<adrien>
ocamlobjinfo*
wolfnn has joined #ocaml
Kakadu has quit [Quit: Konversation terminated!]
axiles has quit [Remote host closed the connection]