flux changed the topic of #ocaml to: Yes, inria.fr is back up! | Discussions about the OCaml programming language | http://caml.inria.fr/ | 3.11.0beta1 available from http://caml.inria.fr/pub/distrib/ocaml-3.11/ | Or grab OCaml 3.10.2 from http://caml.inria.fr/ocaml/release.html
sbok has quit [Remote closed the connection]
sbok has joined #ocaml
TypedLambda has quit []
ulfdoz has quit ["deprecated"]
alexyk has quit []
alexyk has joined #ocaml
ulfdoz has joined #ocaml
alexyk has quit [Client Quit]
alexyk has joined #ocaml
vixey has quit [Network is unreachable]
alexyk has quit [Client Quit]
psnively has joined #ocaml
threeve has joined #ocaml
ulfdoz has quit ["deprecated"]
apples` has joined #ocaml
sporkmonger has joined #ocaml
sporkmonger has quit [Client Quit]
alexyk has joined #ocaml
alexyk has quit [Client Quit]
sporkmonger has joined #ocaml
threeve has quit []
threeve has joined #ocaml
sporkmonger has quit []
jlouis has quit [Remote closed the connection]
tomh has quit ["http://www.mibbit.com ajax IRC Client"]
Axle has joined #ocaml
sporkmonger has joined #ocaml
sporkmonger has quit [Client Quit]
willb has quit ["Leaving"]
snhmib has quit ["Good riddance!"]
psnively has quit []
<det> Is there some useful IO library, for doing things like reading a whole file into memory, or folding over the lines of a file ?
struktured_ has joined #ocaml
struktured has quit [Read error: 110 (Connection timed out)]
alexyk has joined #ocaml
alexyk has quit []
apples` has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
jeddhaberstro has quit []
sporkmonger has joined #ocaml
<thelema> det: batteries included provides those.
seafood has quit [kornbluth.freenode.net irc.freenode.net]
threeve has quit [kornbluth.freenode.net irc.freenode.net]
ppsmimou has quit [kornbluth.freenode.net irc.freenode.net]
xevz has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
Amorphous has quit [kornbluth.freenode.net irc.freenode.net]
seafood has joined #ocaml
threeve has joined #ocaml
Amorphous has joined #ocaml
ppsmimou has joined #ocaml
mfp has joined #ocaml
xevz has joined #ocaml
struktured__ has joined #ocaml
struktured_ has quit [Connection timed out]
jeremiah has quit [Read error: 104 (Connection reset by peer)]
kig has joined #ocaml
seafood has quit [kornbluth.freenode.net irc.freenode.net]
threeve has quit [kornbluth.freenode.net irc.freenode.net]
ppsmimou has quit [kornbluth.freenode.net irc.freenode.net]
xevz has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
Amorphous has quit [kornbluth.freenode.net irc.freenode.net]
threeve has joined #ocaml
Amorphous has joined #ocaml
ppsmimou has joined #ocaml
mfp has joined #ocaml
xevz has joined #ocaml
xevz has quit [Read error: 104 (Connection reset by peer)]
threeve has quit [Remote closed the connection]
xevz has joined #ocaml
threeve has joined #ocaml
jeremiah has joined #ocaml
seafood has joined #ocaml
jeremiah has quit [Connection reset by peer]
sporkmonger has quit []
struktured__ is now known as struktured
threeve has quit []
jeremiah has joined #ocaml
seafood has quit []
<det> thelema, thanks
<det> Is there any kind of builtin way to sort strings ?
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<det> Seems silly to convert to an array, sort and then convert back :/
struktured has quit [Read error: 110 (Connection timed out)]
<det> I don't see any whole file reading function in batteries
jeremiah has joined #ocaml
<det> I guess read_all in ExtLib, but I still have to convert it to an IO.input
ysneakers has joined #ocaml
<det> I wonder if OBI would be open to defining some infix operators at the top-level.
<det> let (|>) a b = b a
<det> is really useful
<det> allows you to write things like:
<det> open_in "/etc/fstab" |> IO.input_channel |> IO.read_all
<det> instead of:
<det> IO.read_all (IO.input_channel (open_in "/etc/fstab"));;
Axle has left #ocaml []
<flux> det, do you mean sorting a list of strings, or sorting the characters inside a string?
struktured has joined #ocaml
<det> the latter
<flux> I guess that's the only way then. looks like a rare need, though.
<flux> I don't think I'm getting why ocamlbuild is a great solution. atleast using it with findlib looks a bit complex ;).
<flux> and I'm thinking package name "xml-light" doesn't either work with recipe at http://brion.inria.fr/gallium/index.php/Using_ocamlfind_with_ocamlbuild or I'm doing something else wrong
<flux> (I put <*.ml>: pkg_xml-light, pkg_netclient to my _tags-file)
alexyk has joined #ocaml
svenl has quit [Read error: 60 (Operation timed out)]
svenl has joined #ocaml
foo_ has joined #ocaml
foo_ has quit [Killed by ballard.freenode.net (Nick collision)]
foo_ has joined #ocaml
foo_ has quit [Killed by brown.freenode.net (Nick collision)]
foo__ has joined #ocaml
foo__ has quit [Client Quit]
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<det> ocamlbuild + findlib has worked well for me
<det> I just tried it out past couple days
<det> I was using ocamlopt straight before that
<det> I just copied the myocamlbuild.ml from the wiki into my source dir
<det> and my _tags looks like this
<det> <*.ml> or <*.byte> or <*.native>: pkg_threads, pkg_camlzip, pkg_extlib, pkg_lablgtk2, pkg_netclient
<det> I just kind of improvised that line, so maybe there is a better way
<det> I think your program will fail to link without the *.byte and *.native
<det> flux, ping, because I like when people say my name when they respond to me, so my IRC client flashes
alexyk has quit []
<det> That is what I used, I think
velco has joined #ocaml
jeremiah has joined #ocaml
Camarade_Tux has joined #ocaml
<flux> that's what I'm using too
tp76 has joined #ocaml
<det> what error do you get
<det> I've also been playing with eclipse ocaml plugin
<det> I've been using emacs forever
<det> the plugin + _tags method works with it
<flux> it doesn't link xml-light in
<flux> so: Error while linking autotv.cmo: Reference to undefined global `Xml'
<flux> apparently it does use it while compiling it, otherwise it would be compile time error..
<flux> ocamlfind ocamlc -o autotv -linkpkg -package xml-light,netclient autotv.ml produces the binary without problems
alexyk has joined #ocaml
<flux> while compiling it uses: ocamlfind ocamlc -c -package netclient -package xml-light -o autotv.cmo autotv.ml and while linking it uses ocamlfind ocamlc -linkpkg autotv.cmo -o autotv.byte
<flux> the first one is right, the second isn't
<det> <det> I think your program will fail to link without the *.byte and *.native
alexyk has quit []
<det> try: "<*.ml> or <*.byte> or <*.native>: pkg_xml-light, pkg_netclient"
<det> flux, ping
<det> *.ml is just used when comping the cmx/cmo (ie. ocamlc -c file.ml)
<det> .native and .byte are used during linking
<flux> ah
<flux> yes, that works
<flux> the example in the page (<*.ml> or "prog.byte": pkg_nums, pkg_str
<flux> ) didn't make sense to me
<flux> as I didn't understand I needed the <> there too
<flux> but, does the myocamlbuild.ml-mechanism strike as inelegant to anyone?
<flux> wouldn't it be better if there was a directory with a much of ml-files which would be taken as the whole myocamlbuild.ml?
<flux> bunch, not much :)
<det> that would be nicer, yes
<det> I'd prefer something like Python distutils
<flux> also there should be a possibility for system/user-wide override of such files
<det> a setup.ml that drives everything
<flux> is myocamlbuild.ml used with a preprocessor that supports including other files?
<flux> that is, how easy would it be to emulate that behavior..
alexyk has joined #ocaml
<det> I have no idea how ocamlbuild works, to be honest.
<det> But that is a good thing, it means I have not been forced to learn much about it. Just dropping in that file and editing _tags has worked for me so far.
<det> But yeah, It does strike me as inelegant, the ocamlfind/ocamlbuild integration, yes.
<flux> perhaps I should take a look how batteries uses it
jeremiah has quit [Read error: 104 (Connection reset by peer)]
filp has joined #ocaml
Yoric[DT] has joined #ocaml
mishok13 has joined #ocaml
alexyk has quit []
velco has quit ["Ex-Chat"]
_zack has joined #ocaml
ysneakers has quit [Read error: 110 (Connection timed out)]
velco has joined #ocaml
ulfdoz has joined #ocaml
Kerris0 has joined #ocaml
_zack has quit ["Leaving."]
seafood has joined #ocaml
<Yoric[DT]> hi
<flux> hello
Kerris0 has quit [Read error: 113 (No route to host)]
_zack has joined #ocaml
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
Camarade_Tux has joined #ocaml
<Yoric[DT]> _zack: I've just committed a small change to make your patch work with GODI.
struktured_ has joined #ocaml
<Yoric[DT]> Mmmhh....
<Yoric[DT]> Can anyone think of a situation in which once an input channel has reached its end we might wish to not close it?
<gildor> Yoric[DT]: doing a seek back to the beginning ?
<Yoric[DT]> Mmmhhh....
<Yoric[DT]> Yes, possibly.
* Yoric[DT] wonders if it wouldn't be interesting to add an option to auto-close inputs once the end has been reached.
<Yoric[DT]> That would simplify some programs.
<mfp> Yoric[DT]: also, when you hold a lock on the fd?
struktured has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]> mfp: what do you mean?
<mfp> the lock is released when you close the fd
<Yoric[DT]> Ah, ok.
<mfp> admittedly contrived, but it could lead to bad surprises
<Yoric[DT]> Gasp, I'm currently being bitten by a difference of package names between Debian and Godi.
<mfp> Yoric[DT]: what about close on GC?
<Yoric[DT]> You mean holding a weak reference and all that?
<Yoric[DT]> Strikes me as a bad idea.
<mfp> just using Gc.finalise
<Yoric[DT]> (still)
<Yoric[DT]> Assume channel [a] reading from channel [b].
<Yoric[DT]> If you close [a], this will presumably close [b].
<Yoric[DT]> However, [a] may become inaccessible while you still have need of [b].
<Yoric[DT]> (for the reasons mentioned above)
<mfp> why would a close b?
<mfp> if you just let each channel close itself when it's reclaimed, this example works
<Yoric[DT]> Mmmmhhhhh....
<mfp> hmmm
<mfp> the problem is caused by [b] being used in 2 contexts: within [a], and somewhere else
<mfp> but this is also problematic if we are closing manually
<mfp> if closing [a] implies closing [b
<mfp> [b]
<mfp> but we're still using [b] somewhere else
<Yoric[DT]> Well, it's the same issue as above. Contrived but possible.
<Yoric[DT]> I actually believe that closing [a] should also close [b].
<Yoric[DT]> The contrary would make the user's work more difficult.
<mfp> then the problem is with the sharing of [b], not how [a] is closed
<mfp> same problem when closing manually, on EOF or with Gc.finalise
<Yoric[DT]> (i.e. if you open a network channel, on top of this uncompression, on top of this Unicode transcoding, you don't want to pass around all three channels just to be able to close them all)
<mfp> -> that's what Gc.finalise would take care of
<Yoric[DT]> Well, it's a problem of manual resource management.
<Yoric[DT]> (actually, Gc.finalise doesn't guarantee anything)
<mfp> (add manual close to avoid leaks when the refs aren't discarded)
<Yoric[DT]> ... and you're back to the start
rageway has joined #ocaml
<mfp> yes, but Gc.finalise has made it easier for most cases
<mfp> and didn't cause any additional problem
<Yoric[DT]> That is, provided you designed your library to not close stuff manually.
<Yoric[DT]> s/manually/as a consequence of something else closing/
<flux> if you do close it manually, you must also unregister the finalisation
<mfp> whether you close manually or not doesn't change anything regarding the "closed channel in use somewhere else" problem, does it?
<flux> also if you rely on fd's being autoclosed, you can suddenly find yourself in a situation where you've run out of fd's
<rageway> I would like to create an empty array corresponding to an empty list .. what should I left for the init var ? I mean the x right here let op = Array.make 0 x ?
<mfp> other langs use close-on-GC (Ruby, Perl, Python, I think) plus HOFs that open a file and close it
<flux> mfp, but they (atleast python) has deterministic GC
<mfp> Ruby doesn't
<flux> mfp, so once you lose the last reference, the file getes closed immediately
<mfp> Ruby's is conservative
<flux> well, how does ruby handle this? for (100000 files) string.concat(load_file(filename)) ?
<flux> (hm, s/concat/append/)
<Yoric[DT]> rageway: well, anything with the correct type.
<mfp> also, OCaml's GC is precise, isn't it?
<flux> precise perhaps, but you don't know when it gets run
<mfp> flux: load_file is actually File.read(filename), which opens AND closes
<rageway> Yoric[DT], there is no type. My function gets an empty list and creates the right array
<flux> mfp, so it does closing explicitly instead of relying on GC?
<mfp> both
<Yoric[DT]> rageway: well, there is no such thing as an empty array of elements with no type.
<Yoric[DT]> rageway: you always need a type.
<mfp> <mfp> other langs use close-on-GC (Ruby, Perl, Python, I think) plus HOFs that open a file and close it
<mfp> in Ruby, File.open(file){|f| ... } is a string -> (channel -> 'a) -> 'a HOF that closes the file
<Yoric[DT]> Side-note: 10 lines (including one blank) for a gunzip de-compressor written with Batteries Included.
<mfp> but there's also close-on-GC, which ppl are told not to rely on too much because the GC is conservative and closures capture way too much environment
<rageway> Yoric[DT], my objective is to create an array concording to a list. if my function gets an empty list, then I don't know what to do
<flux> actually I think the same problem is in ocaml gc too, given the documentation regarding Gc.finalise
<mfp> flux: close-on-GC can serve as a safety net; clearly using HOFs is the way to go to ensure timely close()
<Yoric[DT]> rageway: [||] is an empty array with "no-type-yet"
<Yoric[DT]> Well, technically, regions are the way to go to ensure timely close().
<Yoric[DT]> But we don't have regions (yet) for OCaml.
<Yoric[DT]> (although I have the beginning of a prototype of a limited region system lying around somewhere)
<flux> mfp, one way to look at it could be to assert false; when you find that a descriptor has leaked.. ;)
<flux> yoric[dt], linear typing also could help with that?
<Yoric[DT]> Also.
<mfp> Yoric[DT]: is that reasonably doable without changing the compiler?
<Yoric[DT]> Well, depends on your definition of "reasonably", I guess.
TypedLambda has joined #ocaml
<Yoric[DT]> But probably not.
<_zack> Yoric[DT]: np for the patch, but I don't see in the archive, did you push it?
<Yoric[DT]> Gasp, I have a buffering problem.
<Yoric[DT]> _zack: no, not yet.
<Yoric[DT]> At the moment, I'm trying to get gzip-compression to work.
<_zack> urgh
<Yoric[DT]> The core of my example is [copy inp (GZip.compress out)]
<Yoric[DT]> (where [copy] is [IO.copy])
<Yoric[DT]> The problem is that this never flushes out.
<Yoric[DT]> The problem is that this never flushes [GZip.compress out], that is.
<Yoric[DT]> I'm wondering where the responsibility of this flush should lie.
<Yoric[DT]> (I believe that this is an issue we're also going to meet with [tab_out] et al.)
<_zack> I see
<Yoric[DT]> Now, this is where a reference counter would be nice.
<Yoric[DT]> That problem can be worked around, but it's annoying.
<Yoric[DT]> That is, a call to [flush_all ()] solves everything.
<Yoric[DT]> But that's not satisfactory.
<flux> btw, it would be doubly annoying if the flush was called by cloe which would be called by gc, and you appended something to out after that line ;)
<Yoric[DT]> :)
<flux> copy ~flush:true?
<flux> but I suppose it's not copy's responsibility, although it happens to be the sole owner of the output stream
<flux> type 'a refcounted ;)
<flux> (but that's PIA)
<Yoric[DT]> PIA?
<flux> pain in the..
<flux> neck.
<Yoric[DT]> Ah, ok.
<Yoric[DT]> In addition, mixing ref-counting and OCaml's GC is probably going to lead nowhere.
<flux> yeah, it would need to be somehow enforced
<Yoric[DT]> Well, I suppose [copy] should perform the flush.
<Yoric[DT]> But that's not the real solution.
<Yoric[DT]> s/the/a/
<flux> well, it's a solution..
<_zack> Yoric[DT]: I'm getting kinda lost in the chat backlog (i.e., no time to re-read everything right now), can you at the end post a summary to batteries-devel?
<Yoric[DT]> I will.
<Yoric[DT]> I will try.
<flux> with_flush (copy in) (GZip.compress out)
<_zack> Yoric[DT]: tnx, np for the "try" part, we are all best effort servers here :)
<Yoric[DT]> _zack: what do you mean?
<Yoric[DT]> Ah, ok :)
<_zack> :)
TypedLambda has left #ocaml []
<Yoric[DT]> Unfortunately, by that account, every single function should have an option for flushing.
<Yoric[DT]> Mmmhh...
<kig> is copy lazy?
<Yoric[DT]> kig: no, why?
<kig> then it should flush after the last write
<Yoric[DT]> Sure.
<Yoric[DT]> But there are plenty of other functions which take as argument an [output] and write stuff on it.
<Yoric[DT]> Surely not all of them should flush...
<flux> [>needs_flushing] output
<flux> :)
<flux> I think education and documentation could be the first solution
<Yoric[DT]> Well, a local solution would be to have
<flux> if one was using monads, the argument would need to be named anyway (well..), and flushing would then be easy
<Yoric[DT]> [with_zip_out]
<Yoric[DT]> Sure.
<Yoric[DT]> But we're trying to avoid monads here :)
<flux> I was trying to say that it's not much worse than the alternative ;)
seafood_ has joined #ocaml
<flux> perhaps there could be a separate type for "wrapped output"
<Yoric[DT]> Sounds like overkill.
<flux> yes, there is that
<kig> is the problem that you're reading the file before the write is flushed?
TypedLambda|away has joined #ocaml
seafood has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]> kig: no, the problem is that we have two outputs: [out] and [GZip.compress out].
<Yoric[DT]> The second one is anonymous and closed when it's garbage-collected.
TypedLambda|away has quit [Client Quit]
<Yoric[DT]> (mmmhh... seems I have already implemented that, silly me)
<Yoric[DT]> The first one is named and closed when we leave the scope, due to a higher-order function.
<Yoric[DT]> Unfortunately, the first one should only be closed after the second one is flushed.
<Yoric[DT]> Adding flushing to [copy] seems to do the trick.
Jedai has joined #ocaml
hkBst has joined #ocaml
|Jedai| has quit [Read error: 110 (Connection timed out)]
<kig> so it's like: with_file fn (fun outf -> copy inf (gzip_out outf))
snhmib has joined #ocaml
<kig> possible replacements: with_file_out fn (copy (gzip i));; with_gzip_out fn (copy i);; with_file_out fn (fun o -> with_gzip_out o (copy i));;
<Yoric[DT]> Well, at the moment, it's
<Yoric[DT]> something like this, yes.
Spiwack has joined #ocaml
<kig> from my understanding the gist of the problem is that the fd returned by gzip_out isn't closed, which causes trouble when you have lazy writes and a strict close of the fd used in the gzip. So it could be fixed by making the writes strict or enforcing that the gzip always closes
<kig> enforcing that gzip closes = with_gzip, strict writes = let write o .. = write' o; flush o
filp has quit ["Bye"]
<kig> in a sense, the default write is like let write o s = write' o s; lazy o and flush is let flush o = let o' = Lazy.force o in flush' o'; o'
<kig> and the way that requires that write results are explicitly handled reminds me of clean :S
<Yoric[DT]> At the moment, my solution is to make some writes strict.
<Yoric[DT]> That's hardily satisfying, though.
<flux> another case where it breaks down is simply copy (open_in "foo") (open_out "bar") ?
<flux> the closing part that is
<flux> ~close_in:true ~close_out:true.. :(
<Yoric[DT]> Yeah...
sporkmonger has joined #ocaml
<flux> maybe we should just see that this is doomed to fail and switch to c++!
<Yoric[DT]> :)
<Spiwack> maybe some linear voodoo could be, like, cool with file reading...
<Yoric[DT]> Actually, a partial solution to [open_in "foo"] is just what I said above: auto-close files once reading is complete.
<Yoric[DT]> Yeah, but I don't see much linear voodoo being implemented for OCaml.
<flux> what about when there's an exception and the file never gets read in full?
<Spiwack> that's because it's not possible !
<flux> spiwack, sure it's possible, there's the compiler source :)
<Yoric[DT]> flux: I can do that.
<Spiwack> but anyways, for the files themselves, what about closing them at garbage collection?
<Yoric[DT]> Spiwack: dependency issues.
<flux> yoric[dt], do what?
<Yoric[DT]> You've missed the discussion :)
<Yoric[DT]> flux: close the file when there's an exception.
<Yoric[DT]> Mmmhh...
<flux> yoric[dt], I mean if the exception is thrown by something else than the stream that is being read
<Spiwack> (well, it's impossible in any reasonnable way to reuse some part of ocaml type system)
<Yoric[DT]> Ah, ok.
<flux> and it never naturally reaches the end
<kig> i have some piping stuff in preludeml (but imo a better solution would be to use an extended Stream lib for pipe-like-access and mmap for array-like access) http://github.com/kig/preludeml/tree/master/src/pipe.ml
sporkmonger has quit [Client Quit]
<Yoric[DT]> kig: actually, we also have pipes in Batteries.
alexyk has joined #ocaml
<Yoric[DT]> _zack: actually, I believe I've found a bug.
<_zack> Yoric[DT]: tell me
<_zack> regarding the flushing issue, can't [f o] keep a reference to [o], such that [o] is not garbage collected? (that won't solved the general problem of someone closing [o] by hand, but that can be documented)
<Yoric[DT]> Well, that would be in contradiction with the usage of, say [with_file_out].
<Yoric[DT]> Which does close things manually.
<Yoric[DT]> For the possible bug: [GZip.close_out] seems to raise an exception.
<_zack> i'll have a look
<thelema> Yoric[DT]: could you do git config --global user.email David.Teller@univ-orleans.fr
<thelema> (or whatever email you like)
alexyk has quit []
seafood_ has quit []
<_zack> Yoric[DT]: "Zlib.deflate", is that it ?
<Yoric[DT]> yep
<Yoric[DT]> thelema: ok
<Yoric[DT]> thelema: done
rageway has quit ["Leaving"]
<Yoric[DT]> thelema: what's it for?
<_zack> Yoric[DT]: and actually it is even the wrong exception, as it is not properly wrapped :-/
* _zack spawning Emacs
<thelema> Yoric[DT]: so your commits are tagged with your email address (currently they're tagged "Yoric <yoric@Blefuscu.(none)>")
<_zack> the exception come from the C bindings
ysneakers has joined #ocaml
ysneakers has quit [Remote closed the connection]
<_zack> (and that means that, if we want to consistently raise our own exceptions, we need to wrap all [IO.create_in] args within try .. with)
<_zack> i've no idea how costly that would be
<_zack> alternatively, we need to add into IO.create_in the possibility to specify externally exception translators
<_zack> otherwise there is no way to know which exceptions an IO channel created with create_in/out will rease
<_zack> raise
sporkmonger has joined #ocaml
<mbacarella> howdy
<thelema> could this be solved with a non-IO interface to gz/bz2?
<mbacarella> functors have me totally confused. what should i read?
alexyk has joined #ocaml
<thelema> bye
<mbacarella> thanks
Kerris0 has joined #ocaml
<Yoric[DT]> thelema: ok
<Yoric[DT]> _zack: putting [try...in...] around any argument to [IO.create_in] seems ok to me.
<_zack> Yoric[DT]: committed 5 secs ago :)
<_zack> but see the XXX comment ad the beginning of gZip.ml
<_zack> (wait my push)
<_zack> done, but the exception is still there, only now it is the right one ;)
<_zack> I'll invistigate the exception later
<Yoric[DT]> Ah, ok.
* Yoric[DT] thought you were also working on the exception.
<Yoric[DT]> Mmmhh...
<Yoric[DT]> How do I resolve conflicts with git?
alexyk has quit []
<Yoric[DT]> fatal: Entry 'examples/examples.itarget' would be overwritten by merge. Cannot merge.
<Yoric[DT]> _zack: ?
<Yoric[DT]> What should I do?
<Yoric[DT]> thelema: any suggestion?
<mbacarella> does camlidruntime.h exist anymore?
<mbacarella> wxcaml depends on it but it's nowhere in my or google's environment
<mbacarella> sorry, camlidlruntime.h
<Yoric[DT]> Ah, ok, got it.
<mbacarella> oh, and it does exist with the proper spelling
<mbacarella> :D
<Yoric[DT]> :)
tp76 has quit ["ERC Version 5.2 (IRC client for Emacs)"]
<Yoric[DT]> _zack: well, I've committed my changes.
<Yoric[DT]> I'll come back in a while.
<_zack> Yoric[DT]: I was working on the exception, but first I've wrapped it properly
<Yoric[DT]> sure
struktured_ is now known as struktured
<_zack> Yoric[DT]: so, is Compress.with_in just a shorthand or what?
<_zack> Yoric[DT]: and why with_out does not close the channel, but just flushes it?
<Yoric[DT]> Well, it's a shorthand for [try let foo = uncompress bar in ... finally close_in foo].
<_zack> ok
<Yoric[DT]> Yeah, that was while I attempted to find out where I had made a mistake with Gzip.
<_zack> ok, so it should be uncommented, right?
<Yoric[DT]> (turns out it wasn't me, but I forgot to restore the feature)
<Yoric[DT]> Yep.
<_zack> k
<Yoric[DT]> The following line should be remove.
<Yoric[DT]> The following line should be removed.
<Yoric[DT]> (closing flushes the output)
<Yoric[DT]> Well, gottago.
<Yoric[DT]> Talk to you later.
<_zack> cheers
longh has joined #ocaml
alexyk has joined #ocaml
Kerris0 has quit ["Leaving."]
pango has quit [Remote closed the connection]
willb has joined #ocaml
alexyk has quit []
alexyk has joined #ocaml
mishok13 has quit [Read error: 110 (Connection timed out)]
pango has joined #ocaml
sporkmonger has quit []
sporkmonger has joined #ocaml
alexyk has quit []
sporkmonger has quit [Client Quit]
* Yoric[DT] is back.
marmotine has joined #ocaml
<mfp> me always grumpy... why is some experimental stuff to manipulate Erlang in Haskell +20, and more mature stuff for C/C++ in Ocaml merely +3 grr http://www.reddit.com/r/programming/comments/7bzav/yacfe_stylepreserving_sourcetosource/
<mfp> it's not like any Haskeller is going to use Erlang anytime soon, they think GHC's concurrency is better than Erlangs <- half joking
<Yoric[DT]> :)
<Yoric[DT]> I remember seeing a presentation on that manipulation of Erlang in Haskell.
<Yoric[DT]> And the fact that it's actually unsafe-but-useful source-to-source transformation.
<mfp> I thought Erlang was expressive enough to make such transformations not as desirable as in C
<Yoric[DT]> They needed it for refactoring purposes.
<mfp> hmm that must be notably difficult in Erlang, lacking a type system and all
<Yoric[DT]> Yeah, that's why the transformation is unsafe.
<Yoric[DT]> Well, technically Erlang has a static type-system, it's just not implemented to the best of my knowledge :)
<mfp> oh didn't know that
<mfp> isn't Erlang >20 years old? it's about time :-P
<Kerris4> how does JoCaml compare to Erlang :V
<Yoric[DT]> Kerris4: I've toyed a little with the old JoCaml (not the feature-reduced new version) and that was quite nice.
<Yoric[DT]> I've toyed a little with Erlang and, well, that was quite different. Much more hackish.
<Kerris4> er, crumbs, I didn't know the new version had reduced features
<Yoric[DT]> Iirc, you can't send functions anymore.
<Kerris4> would you know how far will I have to go back to get the old version?
<Yoric[DT]> « Code mobility is not yet implemented. It means that a function can not be sent on a distributed channel. »
<Yoric[DT]> (that used to work)
<Yoric[DT]> I think the old JoCaml stopped at 2.x .
<Yoric[DT]> Gasp, 1.x.
<Kerris4> thanks Yoric, I might be using JoCaml in a few months, or next summer at the latest
<Yoric[DT]> np
<Yoric[DT]> What are you going to do with it?
<Kerris4> parallelising some existing OCaml stuff
<Kerris4> compilers, verifiers
<Yoric[DT]> Nice.
<Yoric[DT]> Are you aware of Acute, BSML and Opis?
<Kerris4> Well, attempting to, that is :)
<Yoric[DT]> :)
<Yoric[DT]> Oh, and coThreads and OCamlErl?
<Kerris4> Nope, not heard of them at all. I was a Haskell/Erlang/Lisp tourist until very recently
<Kerris4> thanks for the headsup, I'll definitely look into them before the big summer project
<Yoric[DT]> Acute is another attempt at doing concurrent/distributed stuff with an extension of OCaml. I don't know its current status.
_JusSx_ has joined #ocaml
sporkmonger has joined #ocaml
<Yoric[DT]> BSML and Opis are libraries for OCaml for doing distributed computing.
<Yoric[DT]> coThreads is for concurrency
<Yoric[DT]> OCamErl I'm not quite sure :)
<Yoric[DT]> np
<Kerris4> strange, coThreads is giving me a blank sourceforge page
<Yoric[DT]> Sourceforge migrated recently and most webmaster never took the time to migrate their website.
thelema has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]> (that gives me an excuse for not having migrated mine)
<Kerris4> hahaha#
alexyk has joined #ocaml
alexyk has quit [Client Quit]
vixey has joined #ocaml
Spiwack has quit [Remote closed the connection]
velco has quit [Remote closed the connection]
tomh has joined #ocaml
jlouis has joined #ocaml
<_zack> Yoric[DT]: does it make sense to have gzip-ed channel 'a channels, where 'a is the same of the underlying channel?
<_zack> wouldn't it be more appropriate to have gzip-ed channel unit-channels?
<Yoric[DT]> I don't know.
<Yoric[DT]> I never quite understood the 'a.
<_zack> same here :)
<_zack> but the problem now is
<_zack> currently Gzip'd chans close the underlying chan upon close
<_zack> I think that's worng
velco has joined #ocaml
<_zack> but if they don't close it, there is no link between the 'a of gzip'd chans and the 'a of the underlying chan
<_zack> hence the only solution is having them return unit, the only available 'a will be the underlying one
<_zack> 'a seems to be meaningful only for the "outer" channel, as there is no way to combine the result of "inner" channels with the (future) result of the "outer"
<Yoric[DT]> Yeah, I think it's wrong.
<Yoric[DT]> Mmmhh...
<_zack> have a look at IO.output_string
<Yoric[DT]> Let me think this over.
<_zack> ok
* Yoric[DT] will be back in a few minutes.
<flux> I think I understood the 'a in output some time ago, but I don't remember it anymore ;)
<_zack> flux: my intuition is that it is something computer over what passes through the channel
<flux> maybe it was for extending streams, like provide a stream that counts the number of octets it passes through
<_zack> precisely
<flux> but perhaps it could also be used to provide an additional interface to the stream?
<flux> dunno why it would need to be attached to the stream that way, though
<flux> you could implement the counter too without it
<flux> val counting_strema : output -> (output * int ref)
<flux> but it wouldn't be functional..
<_zack> but anyhow, the point is that if you want to support that for depending channels
<_zack> you need to change the api of create_in
<_zack> so that you can combine together values returned by inner chans
<_zack> with values of outer chans
<_zack> I don't think it's worth
<_zack> but while it is not possible, depending channels can only be unit channels
<_zack> ... or I'm missing something :)
<flux> well, iirc you can cast any channel into a unit channel
<_zack> s/create_in/create_out of course
<_zack> yes, so?
<flux> but yes, it does seem a bit pointless
<flux> perhaps someone can give a compelling example where 'a output rules :)
<flux> I wonder if the extlib authors should be approached of the matter.. I mean, if batteries has essentially forked extlib, then perhaps this would be a chance to get rid of it, if it serves no better use
<_zack> Yoric[DT]: actually even tab_out closes it's underlying channel when it gets closed, I don't think it should
tvn1981_0 has joined #ocaml
<Yoric[DT]> _zack: fair enough.
<_zack> I think that we have all closed the underlying chan because it made a nice 'a -> 'a type :-D
<Yoric[DT]> :)
<_zack> it remains IMO only to reason a bit about IO.lmargin
<_zack> it smells of a functional way of wrapping channels
<_zack> I'll leave that to volunteers, I'm leaving RSN
<Yoric[DT]> Have you pushed your fixes?
<_zack> in a bit
<Yoric[DT]> ok
<_zack> well, yes, the exception fix is there already
<_zack> the unit channel will be in a bit
<Yoric[DT]> ok
threeve has joined #ocaml
<_zack> Yoric[DT]: done, tab_out still needs to be fixed though
<_zack> bye
<Yoric[DT]> done
<Yoric[DT]> cheers
_zack has quit ["Leaving."]
psnively has joined #ocaml
tomh has quit ["http://www.mibbit.com ajax IRC Client"]
itewsh has joined #ocaml
mishok13 has joined #ocaml
struktured has quit [Read error: 110 (Connection timed out)]
struktured has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
sporkmonger has quit []
sporkmonger has joined #ocaml
thelema has joined #ocaml
wlmttobks has quit ["Leaving"]
psnively has quit []
tp76 has joined #ocaml
itewsh has quit ["KTHXBYE"]
Kerris0 has joined #ocaml
struktured has quit [Read error: 104 (Connection reset by peer)]
<Kerris0> haha I found OcaIDE
struktured has joined #ocaml
<Kerris0> looks like my Emacsphobia lives another day
sporkmonger has quit []
Axioplase has joined #ocaml
sporkmonger has joined #ocaml
tp76 has quit ["bbl"]
wlmttobks has joined #ocaml
<Camarade_Tux> anyone know a tool to extract cab files from ocaml ?
<Camarade_Tux> there's cabextract.exe but that's windows only
profmcdgy has joined #ocaml
lnchntdsl has joined #ocaml
unidinph has joined #ocaml
wptbkgrn has joined #ocaml
<Camarade_Tux> (7z should do it but I'd prefer something which does not rely on external programs)
alexyk has joined #ocaml
itewsh has joined #ocaml
unidinph has quit [K-lined]
wlmttobks has quit [K-lined]
lnchntdsl has quit [K-lined]
profmcdgy has quit [K-lined]
wptbkgrn has quit [K-lined]
alexyk has quit []
Amorphous has quit [Read error: 104 (Connection reset by peer)]
apples` has joined #ocaml
Amorphous has joined #ocaml
tomh has joined #ocaml
jeddhaberstro has joined #ocaml
<mbacarella> this is a much better explanation of using functors
<Yoric[DT]> Kerris0 :)
ygrek has joined #ocaml
<Yoric[DT]> Camarade_Tux: there's a cabextract for Linux, iirc.
<Yoric[DT]> Part of wine.
<Yoric[DT]> Camarade_Tux: expand.exe, iirc.
<mbacarella> sounds like you found an itch to scratch
<mbacarella> there's your reference implementation ;)
_zack has joined #ocaml
<Yoric[DT]> Gasp.
<Yoric[DT]> For the first time, I'm in need of polymorphic recursivity.
<Camarade_Tux> Yoric[DT], mbacarella, yeah :)
<Camarade_Tux> I had seen that one when I was mainly using windows, had completely forgotten about it, thanks :)
<vixey> ooh why?
<Yoric[DT]> Mmmhh...
<mbacarella> being able to natively process cabs in ocaml would be neat though
<Yoric[DT]> mbacarella: ask _zack :)
<mbacarella> then you could earn yourself a place in the godi package tree
<_zack> deflection to thelema :)
<mbacarella> ;)
<Yoric[DT]> :)
<_zack> Yoric[DT]: I'm working on ./configure, almost there, and zip vs camlzip is already solved
<Yoric[DT]> Cool.
<Yoric[DT]> I'm working on this management of outputs.
<Yoric[DT]> Btw, you have a point in our e-mail exchange.
<_zack> re: flush vs close ?
alexyk has joined #ocaml
<mbacarella> is anyone writing an ocaml libcrypto alternative?
<Yoric[DT]> _zack: yep
<Yoric[DT]> mbacarella: do we need an alternative?
<mbacarella> too late
<_zack> yup, I'm not sure it is that important though
<mbacarella> ;)
<Camarade_Tux> mbacarella, it should be doable as one of the cab compression algorithm is LZW which is probably already available and anyway easy to implement
* Camarade_Tux is not sure about the other one but it could be deflate
<Yoric[DT]> _zack: there's now a new function, [IO.wrap_out], which should handle the dependency thing.
* Yoric[DT] is now testing.
tp76 has joined #ocaml
<Yoric[DT]> mmmhhhhh...
<Yoric[DT]> Should work better if I don't invert the direction of dependencies.
<_zack> :)
<Yoric[DT]> And work better it does.
<Camarade_Tux> mmmhhhhh
<Camarade_Tux> Should work better if MS did not produce five 15MB one-liner xml files...
<Yoric[DT]> Gasp.
<Yoric[DT]> The "nice" thing with XML, is that this probably requires 500+ Mb RAM to read each of these files.
<Yoric[DT]> Mmmhhh....
<Yoric[DT]> I have a slight problem with gzip/gunzip.
ofaurax has joined #ocaml
<Camarade_Tux> actually vim "only" takes 51MB right now ;)
* _zack hides
<Yoric[DT]> Camarade_Tux: yeah, but that's not real XML reading :)
<Yoric[DT]> _zack: no, it's actually my fault.
<Yoric[DT]> The resulting gunzip-of-gzip-of-test-file is one byte larger than the original.
<Yoric[DT]> There's a newline at the end.
* Yoric[DT] assumes it's an issue with [copy].
jeddhaberstro has quit []
alexyk_ has joined #ocaml
<Yoric[DT]> _zack: changes pushed.
<Camarade_Tux> Yoric[DT], it will come soon, right now I need to understand the format ;)
alexyk has quit [Read error: 104 (Connection reset by peer)]
alexyk has joined #ocaml
smimou has quit ["bli"]
<Camarade_Tux> vim found 350k lines to indent, it can process about 500 lines per second, I think I have time to do some housechores :p
<_zack> Yoric[DT]: you didn't set your name in git, did you?
<_zack> look at http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=batteries/batteries.git;a=summary
<_zack> you are still "Yoric"
<Yoric[DT]> Well, I followed thelema's instructions.
<Yoric[DT]> But that was for my mail, I guess.
<_zack> ah, i see, you did set the email but not the name
<Camarade_Tux> btw, this xml files is the list of all the microsoft (critical) fixes, no wonder it's so long ><
<Yoric[DT]> Camarade_Tux: :)
struktured_ has joined #ocaml
<Yoric[DT]> Camarade_Tux: no wonder it's so obscure :)
<_zack> edit ~/.gitconfig
<_zack> you should set something like:
<_zack> [user]
<_zack> name = Stefano Zacchiroli
<_zack> email = zack@upsilon.cc
<_zack> probably you already have the email line
<_zack> but are missing the name line
<Yoric[DT]> Ok, done
<_zack> thanks
alexyk has quit []
sporkmonger has quit []
marmotine has quit ["mv marmotine Laurie"]
<Camarade_Tux> \o/ 7 minutes later, the xml file has been indented ! Asmadeus, I hate you :)
<Yoric[DT]> :)
sporkmonger has joined #ocaml
alexyk_ has quit [Read error: 110 (Connection timed out)]
struktured has quit [Connection timed out]
<ygrek> I observe some problem with git repo of batteries
<ygrek> error: The requested URL returned error: 403 (curl_result = 22, http_code = 403, sha1 = ad28fe0813c2e0df231cd3bb47c1d8ec93ee2d18)
<_zack> ygrek: uh? which command did you try? anonymous clone via http works here
<ygrek> hm, I did git clone twice and it was the same..
<_zack> ygrek: again, which command did you try?
<_zack> ygrek: I've just did the same
<_zack> and it works
<_zack> maybe a tor problem?
<Yoric[DT]> Ok, copy fixed.
<ygrek> I tried from another host and it works - looks like my local problem - sorry
<Yoric[DT]> And possibly improved.
<ygrek> yes, probably privoxy mangled it
seafood has joined #ocaml
<Yoric[DT]> Ok, gzip/gunzip tested on my Linux kernel and seems to work :)
<_zack> \o/
<Yoric[DT]> For information, the ocaml native version lasts
<Yoric[DT]> real 0m0.394s
<Yoric[DT]> user 0m0.360s
<Yoric[DT]> sys 0m0.012s
<Yoric[DT]> (gzip)
<Yoric[DT]> real 0m0.158s
<Yoric[DT]> user 0m0.132s
<Yoric[DT]> sys 0m0.012s
<Yoric[DT]> (gunzip)
<Yoric[DT]> while the C native version lasts
<Yoric[DT]> real 0m0.325s
<Yoric[DT]> user 0m0.216s
<Yoric[DT]> sys 0m0.008s
<Yoric[DT]> (gzip)
<Yoric[DT]> real 0m0.107s
<Yoric[DT]> user 0m0.032s
<Yoric[DT]> sys 0m0.016s
<Yoric[DT]> (gunzip)
<_zack> not bad
<_zack> looks like the usual loss in flip/flop between C and Caml
<_zack> not worst than that
<_zack> for performance one will be able to use the in-memory API (once I implement it)
<_zack> trading off memory consumption with speed
<Yoric[DT]> Well, it still seems pretty reasonable to me.
<_zack> agreed
tp76 has quit ["ERC Version 5.2 (IRC client for Emacs)"]
seafood has quit []
_JusSx_ has quit ["leaving"]
ygrek has quit [Remote closed the connection]
hkBst has quit [Read error: 104 (Connection reset by peer)]
<_zack> Yoric[DT]: ./configure support pushed, but before working on batteries please read the mail I've just sent about ./configure
seafood has joined #ocaml
<Yoric[DT]> ok
<mfp> Yoric[DT]: just read your latest blog entry
<mfp> Yoric[DT]: is Jon Harrop right (fd leak), or did you decide to close the input in copy on EOF?
<Yoric[DT]> So far, it leaks.
<Yoric[DT]> I haven't decided to close on EOF [yet].
* mfp decides he'll install 3.11 & batteries + GODI tomorrow :)
<Yoric[DT]> I'm unsure Batteries works with 3.11 .
<Yoric[DT]> At least, I haven't tested yet.
<Yoric[DT]> And thelema had confusing reports :)
<mfp> I'll be adding mine to his then :)
<mfp> "A taste of OCaml Batteries Included" > struggling in reddit +10 -9 :-/
<vixey> I don't get it, camels don't run on batteries
Mr_Awesome has quit ["aunt jemima is the devil!"]
<mfp> vixey: have you seen the logo?
<vixey> no
longh has quit [Client Quit]
itewsh has quit ["KTHXBYE"]
tomh has quit ["http://www.mibbit.com ajax IRC Client"]
alexyk has joined #ocaml
willb has quit ["Leaving"]
<Camarade_Tux> so, I couldn't understand how MS made their update list, maybe tomorrow but couldn't they come with a simple design ?
<Yoric[DT]> Well, anyway, time to call it a night.
<Yoric[DT]> Camarade_Tux: it's MS. They just couldn't.
<Yoric[DT]> Cheers everyone.
Yoric[DT] has quit ["Ex-Chat"]
Camarade_Tux has quit ["Leaving"]
Axioplase has quit ["leaving"]
tomh has joined #ocaml
jlouis has quit [Remote closed the connection]
_zack has quit ["Leaving."]
struktured_ has quit [Read error: 110 (Connection timed out)]
jeddhaberstro has joined #ocaml