<mfp>
since there are now many reasons for (**>) to go away, you might want to rewrite that example as args |> map files_of |> flatten which is also shorter :)
<Yoric[DT]>
:)
<Yoric[DT]>
The problem with exceptions is weird.
<Yoric[DT]>
Printing uncaught exceptions is handled directly at C-level.
<mfp>
(open Shell, Enum, Char and trading String.lowercase for the Char.is_* also saves some bytes)
<mfp>
yes really strange
<mfp>
are you doing something special with stderr?
<Yoric[DT]>
Can't think of anything weird.
<mfp>
I get this through strace: write(2, "Fatal error: exception Invalid_a"..., 67) = -1 EBADF (Bad file descriptor)
<mfp>
are you closing stderr on prog exit?
<Yoric[DT]>
Mmmmhh....
<Yoric[DT]>
I might do that.
<mfp>
ah yes, just before that... close(2) = 0
<Yoric[DT]>
Let me check.
<Yoric[DT]>
I might do that *accidentally*, let me add :)
<Yoric[DT]>
Mmmmh....
<mfp>
hmm this isn't that easy to solve, gotta detect if the program is exiting (in which case, avoid closing in the finalizer) or not
<Yoric[DT]>
Yeah, as suspected, [IO.output_channel] and [IO.input_channel] close the underlying [in_channel]/[out_channel].
<Yoric[DT]>
Which is often wrong, as the user may still wish to write to that channel.
<Yoric[DT]>
Should be easy to solve, actually.
<mfp>
wasn't that there as a safety net so channels are closed on GC?
<mfp>
then, if wrapping existent channel, don't close, if making a new one, do close?
<Yoric[DT]>
Could be a policy.
<Yoric[DT]>
What I'm doing for the moment is adding an optional argument to determine whether autoclosing is required.
<mfp>
so if you open a file using Batteries' API, it gets closed automatically, but channels are left as is
<Yoric[DT]>
mmmhhh....
<Yoric[DT]>
Except it's going to be slightly more complex.
<Yoric[DT]>
Let me ponder this a few seconds.
<Yoric[DT]>
mfp: yes, that's the idea.
<mfp>
how many ways do we have to create input or _ output, just those in IO, right?
<Yoric[DT]>
Well, there are derived ways.
<Yoric[DT]>
Those of File, Unix, GZip, etc.
<Yoric[DT]>
All of them built on top of IO.
<mfp>
I suppose they also have a finalizer to flush & close?
<Yoric[DT]>
Yep.
<Yoric[DT]>
But they should all be safe.
<Yoric[DT]>
(i.e. they are not built from lower-level constructions which are not safe to finalize)
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
* Yoric[DT]
wonders what the default behavior should be.
<mfp>
maybe just a really_close_channel field at the lowest level for IOs built from channels, w/ sensible defaults (based on the function used to construct the IO) + way to access/set close_channel
<Yoric[DT]>
I don't quite understand why.
<mfp>
the pb is that it doesn't fit the current code (record of functions) very well
<mfp>
-> let the finalizer check if the channel needs to be closed or not
Axioplase is now known as Axioplase_
<mfp>
so you can close_in/out transitively
<mfp>
e.g. the finalizer for the compressor does flush + close of its internal IO, which then decides whether to actually close the channel or not
<Yoric[DT]>
What I'm changing at the moment is adding a boolean during construction which determines whether [close_in]/[close_out] actually calls the underlying [Pervasives.close_in]/[close_out].
<Yoric[DT]>
Which is more or less the same thing.
<mfp>
the point is to defer that decision because the higher layers don't know what to do
<mfp>
yes
ygrek has joined #ocaml
* Yoric[DT]
needs to understand what happens when closing the input or output to [open_connection] or [establish_server].
_zack has quit ["Leaving."]
_zack has joined #ocaml
<Yoric[DT]>
mfp: btw, could you submit your bug?
<Yoric[DT]>
That will let us track progress on the issue.
<mfp>
ok
_zack has quit ["Leaving."]
<Yoric[DT]>
thanks
_zack has joined #ocaml
<mfp>
Yoric[DT]: should I also file a bug against (**>)'s precedence, as a reminder?
<mfp>
(so as to remember to either remove (**>) or change its precedence)
<Yoric[DT]>
Yes, please.
oleg|log has quit [Read error: 104 (Connection reset by peer)]
oleg|log has joined #ocaml
ygrek has quit [Remote closed the connection]
sporkmonger has joined #ocaml
seafood has quit []
zerny has joined #ocaml
schmx has joined #ocaml
OChameau has joined #ocaml
Cheshire has joined #ocaml
slash_ has joined #ocaml
schme has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
Brrr....
<Yoric[DT]>
The number of bugs I discover while writing unit tests is simply scary.
<mfp>
what are you using, oUnit?
<Yoric[DT]>
I suppose I should.
<Yoric[DT]>
For the moment, I'm just writing tests as I go.
vpalle has quit [Read error: 110 (Connection timed out)]
hkBst has joined #ocaml
<gildor>
rwmjones: no, I am rewriting ocaml-fileutils configure.in
<gildor>
rwmjones: but your macro seems good
<gildor>
_zack: ok, will do it
vpalle has joined #ocaml
Yoric[DT] has joined #ocaml
_zack has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
mfp: well, you seem to have more success than me with reddit :)
<Yoric[DT]>
(or perhaps I just don't know how to use reddit)
ttamttam has left #ocaml []
<mfp>
Yoric[DT]: my "trick" is to see when the 25th most recent submission was sent; if only 3-4H, it's hard to get enough votes before it disappears from what's new
<mfp>
doable with 7-8H, trivial with >10H (weekends)
<Yoric[DT]>
ok
<Yoric[DT]>
Interesting.
<Yoric[DT]>
Well, thanks :)
<mfp>
depends on the "inner strength" of the posting too :)
<mfp>
OCaml postings are seemingly more successful in the morning (CET)
<mfp>
often see downvotes as lazy FPers from the east coast wake up ;)
<mfp>
then there's the saturation issue, which hits dons badly (note how the Nth posting of his of the day gets vigorously downvoted even when it's more interesting than other stuff he posted before & ranked high)
<mfp>
I interpret that as ppl being fed up with Haskell stories but not bothering to downvote something that is already +NN and then ravaging new postings out of spite
<gildor>
rwmjones: first patch ready (very small) where can I send it ?
pango has quit [Remote closed the connection]
<Yoric[DT]>
On a different note, it seems that Romain Bardou cannot understand the notion of "manual". Or perhaps it's a conflict of personalities with Daniel Bünzli.
<rwmjones>
gildor, debian-ocaml-maint probably best
r0bby has quit [Connection timed out]
pango has joined #ocaml
Cheshire has quit ["This computer has gone to sleep"]
Cheshire has joined #ocaml
Camarade_Tux has joined #ocaml
Demitar has quit [Remote closed the connection]
Demitar has joined #ocaml
Waleee has quit [Read error: 104 (Connection reset by peer)]
willb has joined #ocaml
Waleee has joined #ocaml
ttamttam has joined #ocaml
Cheshire has quit [Read error: 113 (No route to host)]
OChameau has quit [Read error: 113 (No route to host)]
Cheshire has joined #ocaml
jado has joined #ocaml
<jado>
hi, i've installed libpcre-ocaml ; how can i use it ?
<kig>
if you are using findlib, ocamlfind opt -package pcre -linkpkg my_program.ml -o my_program
<kig>
or #use "topfind";; #require "pcre";; on toplevel
<jado>
thanks
Cheshire has quit [Read error: 113 (No route to host)]
willb1 has joined #ocaml
ulfdoz_ has quit [brown.freenode.net irc.freenode.net]
sporkmonger has quit [brown.freenode.net irc.freenode.net]
peper has quit [brown.freenode.net irc.freenode.net]
thelema has quit [brown.freenode.net irc.freenode.net]
haelix has quit [brown.freenode.net irc.freenode.net]
ozzloy has quit [brown.freenode.net irc.freenode.net]
sporkmonger has joined #ocaml
peper has joined #ocaml
ulfdoz_ has joined #ocaml
thelema has joined #ocaml
ozzloy has joined #ocaml
haelix has joined #ocaml
xian has joined #ocaml
jeddhaberstro has joined #ocaml
willb has quit [No route to host]
ygrek has joined #ocaml
<jado>
hi again, can someone explain me this : http://paste.ubuntu.com/116177/ ; i'm trying to find the pattern 1234 in the string "12341234123412". The function repeatedPattern applied on s should find the smallest pattern p such as s = (p+)w where |w| <= |p|
* Yoric[DT]
sees PCRE and flees away in terror.
<jado>
Yoric[DT]: i shouldn't use it ?
<Yoric[DT]>
I don't know and I don't want to know :)
<Yoric[DT]>
(I've tried PCRE once and I was scarred for life)
<jado>
and what do you use now ?
<Yoric[DT]>
I don't use regexps at all:)
<Yoric[DT]>
(actually, mikmatch looks good, but I haven't tried it)
<jado>
and how would you do if one day you need to seek a pattern in a string ? ^^
Camarade_Tux has quit [brown.freenode.net irc.freenode.net]
mehdid has quit [brown.freenode.net irc.freenode.net]
|jeremiah has quit [brown.freenode.net irc.freenode.net]
mattam has quit [brown.freenode.net irc.freenode.net]
rodge has quit [brown.freenode.net irc.freenode.net]
Camarade_Tux has joined #ocaml
mehdid has joined #ocaml
|jeremiah has joined #ocaml
mattam has joined #ocaml
rodge has joined #ocaml
<kig>
"(.+)\\1{2,}(.*)"
<kig>
that sort of matching likely gets ridiculously expensive with some inputs (backreferences being np iirc)
rodge has quit [Remote closed the connection]
rodge has joined #ocaml
<jado>
'iirc' ?
<jado>
your solution returns ": string array = [|"66666667"; "66"; "67"|]" for "66666667" while it should return [|"66666667"; "6"; "7"|]
<jado>
(kig)
<jado>
kig: ?
pdonadeo has joined #ocaml
<kig>
?
hkBst has quit [Read error: 104 (Connection reset by peer)]
pdonadeo has left #ocaml []
<jado>
kig : your solution returns ": string array = [|"66666667"; "66"; "67"|]" for "66666667" while it should return [|"66666667"; "6"; "7"|]
hkBst has joined #ocaml
<jado>
kig : what did you mean by 'iirc' ?
jonasb has joined #ocaml
<kig>
if i remember correctly
<kig>
+ is greedy so it would do that for 666667, yes
<kig>
there is a way to make it non-greedy, by using ?
<jado>
just after the + ?
mehdid has quit [brown.freenode.net irc.freenode.net]
mattam has quit [brown.freenode.net irc.freenode.net]
Camarade_Tux has quit [brown.freenode.net irc.freenode.net]
|jeremiah has quit [brown.freenode.net irc.freenode.net]
Camarade_Tux has joined #ocaml
mehdid has joined #ocaml
|jeremiah has joined #ocaml
mattam has joined #ocaml
<jado>
kig: putting a ? after the + resolves the problem of 6666667, but here is a new one : - : string array = [|"111231112311123"; "1"; "231112311123"|]
<jado>
i'm searching the smallest pattern p such as s = pppp*w where |w| <= |p|, how can i say that w should be smaller than p ?
<jado>
will i have to use a parameter 'k' : "(.{k,}?)\\1{2,}(.*)" and increment k while |w| > |p| or is there a more efficient way ?
<kig>
maybe you get to write your own custom parser :)
<jado>
yes that probably would be easier
ygrek has quit [Remote closed the connection]
mattam has quit [Remote closed the connection]
__mattam__ has joined #ocaml
sporkmonger has quit []
ygrek has joined #ocaml
ygrek has quit [Remote closed the connection]
ygrek has joined #ocaml
marmottine has joined #ocaml
sgnb has quit ["ERC Version 5.3 (IRC client for Emacs)"]
<pango>
jado: there may be a bug left, try with "66677"
<jado>
thelema_ : i'm not talking about the colors
<rwmjones>
Yoric[DT], so if you see a package there, just "yum install ocaml-foo" will install the package + any deps
Camarade_Tux has quit ["Leaving"]
<thelema_>
jado: the indenting? the only change I made to mine was to not indent on let.
<rwmjones>
Yoric[DT], except I should say that if you expect that they will _develop_ against the package (ie. write new software) then they should install ocaml-foo-devel
<Yoric[DT]>
rwmjones: actually, since I'm guiding people into installing Batteries, as long as there's no ocaml-batteries-devel, I'll just have them install gcc.
<Yoric[DT]>
(et al.)
<rwmjones>
Yoric[DT], sure, but we want batteries in Fedora don't we?
<Yoric[DT]>
Sure.
<rwmjones>
I mean, that would be the ideal situation
<jado>
pango: yes i think that should return 666,77 instead of 66,677
<Yoric[DT]>
Of course.
<rwmjones>
Yoric[DT], well before that happens, they can install just the ocaml package (+ maybe ocaml-findlib etc), but after that happens they can install ocaml-batteries-devel
<jado>
thelema_: no it's not that either ; it's just that sometimes, emacs lets a text colored as a string whereas this text is not a string anymore ; or as i just saw, when i write "extract ~rex:myreg s" he understands myreg as a type and colors it with the type color (green) (ok that's no big deal) but it also colors 's' with the type color
<jado>
but pango, don't work too hard on it that's not really a problem
<Yoric[DT]>
rwmjones: mmmmh.....
<thelema_>
jado: maybe () will help. It's not a common case. people use ( val : type ) much more often.
<rwmjones>
mmmmh?
* Yoric[DT]
is thinking about what's easiest to explain.
<thelema_>
yor: I like straightforward [sudo yum install foo] when the deps just work out.
sporkmonger has joined #ocaml
<Yoric[DT]>
rwmjones: I'll first try and finish the GODI tutorial then I'll write a Fedora-specific one.
<Yoric[DT]>
I'll probably need your help.
<jado>
thelema_ yes but what about the text that stays colored as a string whereas it is not anymore (i have no example right now to reproduce this bug)
<rwmjones>
Yoric[DT], why don't you email it to me & I can take a look -- rjones ^at^ redhat ^dot^ com
<thelema_>
jado: that's an optimization gone wrong, and editing near the incorrect highlighting fixes it. It's inherent in how emacs highlighting works, I think.
<Yoric[DT]>
rwmjones: I'll do that, thanks.
<rwmjones>
np
ttamttam has quit ["Leaving."]
<hcarty>
jado: I think I ran in to the same problem when I was using emacs. I had to force it to re-highlight the code every now and then
<thelema_>
Yoric[DT]: could it go on a wiki somewhere for you two (and others) to collaborate on?