<hcarty>
thelema: This release is a bit more attractive than the last, with a selection of examples and better documentation to go along with it
<hcarty>
And it /has/ to be good if it takes 15 minutes to build :-)
<hcarty>
Batteries is looking very nice at this point and seems to have a promising roadmap. Thanks to those involved.
<thelema>
heh. just the documentation takes 15 minutes.
<thelema>
it's frickin' awesome.
<hcarty>
The documentation is an impressive (ab)use of ocamldoc
<thelema>
thank yoric for that. I'll admit its impressiveness.
<mbishop>
I haven't even gotten it installed yet
<mbishop>
installed godi, but it's erroring on the second bootstrap
<mbishop>
Error: Package godi-ocamlnet replaces previous godi-equeue, but the latter is still installed. Remove godi-equeue first!
<mbishop>
got a whole bunch of messages like that, but I have no idea how to remove them...running 'godi_console' tells me it's just a bootstrap version
<hcarty>
mbishop: Did you set your $PATH appropriately?
<mbishop>
yes
<mbishop>
it tries to install godi-ocamlnet but complains about a whole bunch of other godi packages that it replaces
<mbishop>
So...know any way for me to remove the ones it's asking to remove?
<mbishop>
the readme says there should be godi_delete, but there isn't
<mbishop>
I think I'll uninstall godi and wait for a debian/ubuntu package for batteries :)
<thelema>
yes, we really do need that. I insisted on a one-command install of batteries, but was told that people'll just use package managers for dependencies.
* thelema
doesn't use package managers for ocaml stuff.
<thelema>
I install ocaml, then bin-prot, camlzip, camomile, findlib, lablgtk2, sexplib and type-conv (not in that order)
tvn1981_0 has quit ["Leaving"]
<mbishop>
I use apt for ocaml and it's libraries, usually
<mbishop>
and I agree it would be nice to have a single command to install what is needed (and in the right places)
<mbishop>
I've never used godi before, and hope I don't have to again heh
<doy>
so i'm trying to do stuff with lablgtk
<doy>
and i have an event
<doy>
it's a button_press event
<doy>
and i want to only get `BUTTON_PRESS Gdk.event things, not `TWO_BUTTON_PRESS Gdk.event things
<doy>
but i can't find any way to get that out of the event that i receive
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
<doy>
aha, found it
jknick has joined #ocaml
Palace_Chan has joined #ocaml
Palace_Chan has quit [Client Quit]
threeve has quit []
Palace_Chan has joined #ocaml
Jedai has joined #ocaml
|Jedai| has quit [Read error: 110 (Connection timed out)]
bohanlon has quit [Remote closed the connection]
<det>
Will installing godi-batteries give me alpha 2 ?
kg4qxk has joined #ocaml
<thelema>
det: pretty likely yes, but I don't use godi
Palace_Chan has quit ["Palace goes to sleep"]
sporkmonger has quit []
apples` has quit ["Leaving"]
jeddhaberstro has quit []
jknick has quit [kornbluth.freenode.net irc.freenode.net]
mbishop has quit [kornbluth.freenode.net irc.freenode.net]
snhmib has quit [kornbluth.freenode.net irc.freenode.net]
BSWolf has quit [kornbluth.freenode.net irc.freenode.net]
lorph has quit [kornbluth.freenode.net irc.freenode.net]
ecc has quit [kornbluth.freenode.net irc.freenode.net]
authentic has quit [kornbluth.freenode.net irc.freenode.net]
jknick has joined #ocaml
authentic has joined #ocaml
lorph has joined #ocaml
Mr_Awesome has joined #ocaml
snhmib has joined #ocaml
BSWolf has joined #ocaml
ecc has joined #ocaml
mbishop has joined #ocaml
ecc has quit [Read error: 60 (Operation timed out)]
ecc has joined #ocaml
det has quit [Remote closed the connection]
Guest37031 is now known as tp76
det has joined #ocaml
ulfdoz has joined #ocaml
velco has joined #ocaml
filp has joined #ocaml
mishok13 has joined #ocaml
Camarade_Tux has joined #ocaml
Kerris0 has joined #ocaml
velco has quit ["Ex-Chat"]
rwmjones_ has joined #ocaml
_zack has joined #ocaml
seafood has joined #ocaml
munga_ has joined #ocaml
velco has joined #ocaml
seafood has quit [kornbluth.freenode.net irc.freenode.net]
Camarade_Tux has quit [kornbluth.freenode.net irc.freenode.net]
munga_ has quit ["Ex-Chat"]
seafood has joined #ocaml
Camarade_Tux has joined #ocaml
Kerris0 has quit [Read error: 113 (No route to host)]
jknick has quit ["leaving"]
code17 has joined #ocaml
Kerris0 has joined #ocaml
kattla has joined #ocaml
marmotine has joined #ocaml
Snark has joined #ocaml
rwmjones_ has quit ["Closed connection"]
Kerris0 has left #ocaml []
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
<Yoric[DT]>
Gasp, my post on Batteries Included has disappeared and has been replaced by a political rant (of mine).
marmotine has quit [Read error: 113 (No route to host)]
<Yoric[DT]>
Ok, rewritten.
marmotine has joined #ocaml
marmotine has quit [Read error: 104 (Connection reset by peer)]
marmotine has joined #ocaml
marmotine has quit [Read error: 54 (Connection reset by peer)]
<flux>
I take it val unique : unit -> int is thread-safe?
<flux>
I would like to see companion unique' or unique64, it is not unforeseeable that unique will eventually end up either failing or returning duplicate identifiers. with Int64 that's much less likely :)
<mfp>
it isn't
<mfp>
just incr counter; !counter
<Yoric[DT]>
flux: not thread-safe yet.
<flux>
that should be mentioned in the interface then
<mfp>
(<|) is left-associative, doesn't that make it essentially useless?
<mfp>
f <| g <| x is not equivalent to the symmetric x |> f |> g
<Yoric[DT]>
mfp: that's a problem, I grant you.
<mfp>
*symmetric
<Yoric[DT]>
If you have a better alternative, please submit it.
<Yoric[DT]>
For the moment, I'm thinking about using Camlp4 to change the associativity of this operator.
<mfp>
either using an operator starting with ^, @ or **, or camlp4, yep
Kerris0 has joined #ocaml
<Yoric[DT]>
I guess we could use *>* and *<*
<mfp>
ah regarding operators
<mfp>
wouldn't pa_do be a nice addition?
<Yoric[DT]>
Yes, at some point.
<Yoric[DT]>
Not just quite yet, but that's bound to happen.
<mfp>
batteries.syntax could use it to change the associativity of (<|), probably easier than special-casing it manually
<Camarade_Tux>
*<* and *>* aren't so nice to type
<Yoric[DT]>
That's the problem.
<mfp>
*<*? where's that from, the parser combinator lib?
<mfp>
s/lib/module/
<Yoric[DT]>
Well, placed in the TODO list.
<mfp>
ah, so the rule is *[whatever]* = right-assoc?
<Yoric[DT]>
No, it's a suggestion for replacement.
<Yoric[DT]>
Yeah.
<Yoric[DT]>
iirc
<Yoric[DT]>
Actually, iirc *[whatever] is right-assoc.
<Camarade_Tux>
if only *[whatever] is needed, that's much easier to type for me
<Camarade_Tux>
anyone on a qwerty ?
<_zack>
Yoric[DT]: I think yesterday we have concluded that config.ml generation can be done via ./configure, right?
<Yoric[DT]>
_zack: No.
<Yoric[DT]>
Camarade_Tux: me
<Yoric[DT]>
_zack: since, when installing as a GODI package, we detect GODI only in Makefile.
<bluestorm>
that's a first draft, i'll add some documentation, tests, and it's not yet variable-capture-proof
<bluestorm>
s/in let result/and result/
<flux>
wouldn't using regular variants be slightly faster?
<bluestorm>
flux: i should declare them, wich means local module and unknown performance costs
<flux>
bluestorm, well, I'm thinking a global transformation would be ok too
<flux>
or even requiring a library to be used
<bluestorm>
isn't that overkill ?
<flux>
batteries might actually have related types already?
<bluestorm>
hm, i'll investigate
<bluestorm>
i think the current solution is an acceptable compromise between performance and readability
<bluestorm>
but you're right, i could use an Either-like type from battery
<bluestorm>
hm
<bluestorm>
but then i'd have to be careful not to introduce cycles in batteries compilation (some of the batteries modules may depend on this extension in the future)
<bluestorm>
flux: do you see any isssue with variable capture ?
<bluestorm>
i think users should be able to read the postprocessed code for simple extensions
<flux>
surely it will fail if I use let after () = 42 in try let a = final () finally ..
<flux>
should be simple enough to use generated ids?
<bluestorm>
hm
<bluestorm>
i don't think it will fail
<bluestorm>
(i don't like generated ids)
<flux>
how will it not fail?-o
<bluestorm>
hm
<flux>
if the example is correct
<flux>
uh
<flux>
I meant obviously try let a = after () finally ..
<flux>
how would one call a user function called 'after' from within the try .. finally -block/
<bluestorm>
well
<bluestorm>
my first version used "let after ... in let result = ... in"
<flux>
ah, I misparsed
<bluestorm>
but i noticed the issue and changed (about 2 second after releasing on the chan) to an "and" wich i think should handle that
<flux>
indeed, it doesn't cause a problem :)
<bluestorm>
i should add a comment on the issue, though
<bluestorm>
it tends to be error-prone and gives headaches to check
<bluestorm>
hm, lunch time
<bluestorm>
hopefully i'll bug you with the "let try ..." extension this afternoon :)
seafood has quit []
* _zack
is preparing debian packages of batteries alpha 2
<_zack>
but I'm still fighting with the docpath, even though config.ml is right, #help looks for them in the wrong place
Kerris0 has quit ["Leaving."]
willb1 has quit ["Leaving"]
munga has joined #ocaml
<_zack>
Yoric[DT]: any reason why batteries top.ml is executable?
<_zack>
it was just an heisenbug
vixey has quit [Remote closed the connection]
<det>
I've noticed that debian packages for camlzip and lablgtk differ greatly in their META file than GODI's
munga has quit ["Coyote finally caught me"]
munga has joined #ocaml
<det>
To the point that your build infrastructure must target one or the other
<det>
for example, lablgtk2 in godi links in gtkInit.cmx and gtkThread.cmx by default, whereas the Debian packages dont link in anything other than the cmxa
<det>
Also, the zip package is called camlzip in GODi and zip in Debian
<flux>
I find it a bit redundant to call packages caml-foo or ocaml-bar ;)
<flux>
but otoh, the package might be well known with its full name
gene9 has joined #ocaml
<det>
# 50 -- 55 |> List.of_enum;;
<det>
- : int list = [51; 52; 53; 54; 55; 56]
<det>
off-by-1 bug ?
<flux>
what does 55 -- 50 |> List.of_enum give?
<det>
empty list
<flux>
but in any case, looks like a bug
<flux>
or atleast very unexpected behavior!
<det>
I'm really impressed with the integration of Libraries in Batteries
<det>
like using Generic IO and Enum types all over the place
<Camarade_Tux>
I can't believe it either :)
<Yoric[DT]>
_zack: no good reason, no.
<Yoric[DT]>
det: yes, I've just fixed that bug.
itewsh has joined #ocaml
<Yoric[DT]>
(if you wish to fix it for yourself, it's in [Enum.seq])
<det>
Btw, was it a conscience decision to use raise and exception style instead of return an option style ?
<_zack>
Yoric[DT]: other minor point, isn't documentation_root inconsistently used in batteries_help.ml? we look for docroot ^ toplevel.help and for docroot ^ doc/batteries/...
* Yoric[DT]
returns to deadline mode and stops answering questions on Batteries :)
<det>
conscious*
<_zack>
Yoric[DT]: ah, oops, /me didn't know
<_zack>
I'll post on the ML then
<det>
Yoric[DT], I'll leave you alone then :-)
Axle has joined #ocaml
sporkmonger has joined #ocaml
<hcarty>
bluestorm: Yoric[DT] said you are the one to talk to regarding camlp4 + Batteries. I have some patches for pa-do which add ocamlbuild support and expand the META file a bit if/when you integrate pa-do.
<hcarty>
The patches also make the extension work properly with a (patched) 3.10.2 toplevel or a 3.11.0 toplevel which already has several camlp4 + toplevel bugs fixed
<hcarty>
I'm planning on submitting the patches upstream some time in the next few days
<bluestorm>
hcarty: hm, what's the link between batteries and pa-do ?
willb has joined #ocaml
purple has joined #ocaml
itewsh has quit [Read error: 60 (Operation timed out)]
vixey has joined #ocaml
tp76 has quit ["ERC Version 5.2 (IRC client for Emacs)"]
<det>
Is it necessary to "Open Batteries" and "Open Batteries.Standard" in every source file of a batteries using project ?
<ertai>
Yoric[DT]: hi
<Yoric[DT]>
det: no, see examples/
<ertai>
I'm looking at the new release of batteries and looked at combinators in Standard
<det>
ahh, using the ocamlbuild tagging system
<ertai>
currently first is: let first f x = fst (f x)
<Yoric[DT]>
hi, talk to you later, deadline mode.
<ertai>
I was expecting let first f (x, y) = (f x, y)
<ertai>
Yoric[DT]: ok
<ertai>
Although my message is there!
<Yoric[DT]>
:)
<vixey>
can you write it like first f = fst "compose" f
<vixey>
?
<vixey>
let first f = fst o f
<kattla>
yes
<kattla>
is there a compose in Batteries?
<kattla>
i think ertai's version of first seems more usefull
<det>
there is compose in Batteries, see Standard module
<_zack>
still, right now people got used to that, that's why we can't change just a single op, IMO
<vixey>
bluestorm, but people seem to be afraid of confusing others by using this tool 'pa_do' so is pa_do unsuitable?
<olegfink>
composition has its reason, but application?
<vixey>
I can't understand who would find x |> h |> g |> f more clear than f (g (h x))
<vixey>
maybe if they were a BASIC programmer or something
<mfp>
olegfink: fewer parentheses f (g (h x)) vs. f $ g $ h x in Haskell
<Kerris4>
vixey: people used to UNIX pipes would find that intuitive
<vixey>
mfp, only newbies write f $ g $ h x though
<bluestorm>
Kerris4: and if you expand your expression on multiple lines, it's easier to indent coherently
<olegfink>
mfp: vs. x >> h >> g >> f which is what I usually do. I'm used to left-to-right reading.
<mfp>
vixey: well, because there's .
<vixey>
Kerris4, I suppose I see what you mean, I think that UNIX pipes work so differently that it is harmful to use anything analoguous
<vixey>
Kerris4, (this is why I did not like the thing |> in F#)
<vixey>
Kerris4, (and it is a shame to see it be taken up by other languages)
<Kerris4>
vixey: it's used in other languages too?
<vixey>
Kerris4, ocaml
<Kerris4>
oh. :x
<Yoric[DT]>
Well, it's still time to drop it from Batteries if you a good alternative is suggested.
<vixey>
yeah :/
<vixey>
Yoric[DT]: I think removing it is a good idea but adding in an alternative would be bad again
<bluestorm>
olegfink: f << g << h << x wouldn't work because of the associativity : ((f g) h) x isn't usually what you expect
<vixey>
Yoric[DT]: Although my opinion shouldn't matter much since I don't start new programs in ocaml
<olegfink>
why do you insist on right-to-left order?
<vixey>
bluestorm, is that easier to read, reason about, anything? than f (g (h x)) ?
<Yoric[DT]>
Noted.
<bluestorm>
olegfink: in some occasion right-to-left is more natural than left-to-right
<olegfink>
Yoric[DT]: I would *really* like to see 'a -> ('a -> 'b) -> 'b making it into Batteries.
<Yoric[DT]>
Features request :)
<vixey>
olegfink, isn't that the type of |> ?
<olegfink>
er, it is.
<vixey>
ok so that's already in batteries
<vixey>
I'm suggesting it be removed
<bluestorm>
:]
<olegfink>
then just disregard everything I'm saying here. :-)
<vixey>
as well as <| |- -| &&& and ***
<bluestorm>
i think that
<bluestorm>
we may choose meaningful prefix names
<vixey>
maybe the whole section 'Fundamental functions and operators' should be taken out of batteries core and put into a new one called 'Trivial combinators'
<det>
|> is very useful
<olegfink>
what what harm does |> do? It doesn't have associativity problems and is quite useful.
<bluestorm>
and then add an Infix module with cryptic operators for the enthusiats
<vixey>
det, I am certain that there is absolutely no use for it
<bluestorm>
hm
<bluestorm>
i find the similarity in expression between vixey and Smerdyakov confusing
<vixey>
<bluestorm> i find the similarity in expression between vixey and Smerdyakov confusing
<vixey>
oops
* kattla
has used |> a lot
<bluestorm>
(are you from the same family or something ?)
<vixey>
olegfink, compare x |> h |> g |> f with f (g (h x))
<olegfink>
vixey: print me all the numbers plus two in a list which are greater than 7?
threeve_ has joined #ocaml
<olegfink>
compare list >> List.filter (>7) >> List.map (+2) >> List.iter print_int with parans version
<bluestorm>
Yoric[DT]: (<|) probably has an associativity problem, though
<olegfink>
*parens
<vixey>
olegfink, looks like Ruby
<olegfink>
maybe, I don't do Ruby.
<vixey>
olegfink, (btw, you might notice that you just wrote down your specification _in reverse_ to write that program)
<det>
# (1 -- 1000) // (fun x -> x mod 30 = 0) |> take 10 |> List.of_enum;;
<det>
- : int list = [30; 60; 90; 120; 150; 180; 210; 240; 270; 300; 330]
<vixey>
olegfink, and I'm not sure that reversing specifications in ones head is sensible
<det>
# List.of_enum (take 10 (filter (fun x -> x mod 30 = 0) (1 -- 1000)));;
<det>
- : int list = [30; 60; 90; 120; 150; 180; 210; 240; 270; 300; 330]
<det>
I prefer the first version
<vixey>
det, I like that (--) thing though
<bluestorm>
det: using pa_holes you could write (\ \1 mod 30 = 0) :-'
<det>
bluestorm, in place of the anonymous function ?
<bluestorm>
(and possibly (\ _ mod 30 = 0), though i'm not sure about enabling that one)
<bluestorm>
yes
<vixey>
It looks like an attempt to turn Ocaml into Perl 6 :)
<olegfink>
vixey: in which direction would you read haskell's print $ map (+2) $ filter (>7) $ list?
<vixey>
olegfink, I would not even finish reading that, I would just tell them not to use ($) in that way
<olegfink>
I apparently don't have a stack in my head, so I have to read it right-to-left
<vixey>
sorry I don't I'm going to grasp your point if you use haskell code to explain it
<olegfink>
there shouldn't be dot after map, sorry.
<olegfink>
I thought you were advocating haskell approach, but probably I just don't have any clue whatsoever.
<vixey>
olegfink, I am mostly suggesting that ($) in haskell, (|>) in ocaml and f# are fundamentally bad things to program with because they are awkard and do not admit nice algebraic properties
<olegfink>
so you suggest rewriting that with parens?
<vixey>
olegfink, I'm not really saying there's a specific good way to do anything, just that this one thing is _bad_
<bluestorm>
i don't really understand why you think that f $ g x is worse than f (g x)
<_zack>
vixey: we kind of get it, but I'm entirely sure yet, can you repeat the concept? (SCNR)
<vixey>
_zack, if you have had me on /ignore then you should read the channel logs
pango has joined #ocaml
<bluestorm>
looks like the same to me, except parens put delimiters both before and after the latter part
<_zack>
vixey: ok, I'll try again, can you please first of all explain why you do bother? if you don't like the operators, just don't use them
<olegfink>
vixey | det, I am certain that there is absolutely no use for it
<_zack>
second, the examples with just f/g/h are naive, when the code gets trickier, the parens version has not only the parens required for nested applications, but also all the other parens inside f/g/h
<_zack>
in that case, the ability to write them in a non-nested way, makes the code more readable
<olegfink>
I think that's the point, but I have provided sort of a counter-example
<_zack>
and, as it has been already pointed out, indentable more clearly
<vixey>
_zack, If you write code that complicated _You are doing something wrong_, if |> makes it easier to do the wrong thing this is not helpful
<_zack>
that is, each successive step in a series of transformation can be indented on the same line
<_zack>
it does not
<_zack>
on the contrary, it encourages to write complex nested applications, which is the core of functional programming
<vixey>
olegfink, the one where you had to reverse the problem specification in your head to write the code? that was not a good counter example
<_zack>
if the current style forces people to do sequential let ... in, that is less of a functional style
<Smerdyakov>
I'm all in favor of complex nested applications.
<vixey>
olegfink, at least you did not convince me
<Smerdyakov>
(That one was for people who claim vixey and I say things that are too similar. :P)
<_zack>
Smerdyakov: :)
<olegfink>
am I supposed to do the right thing with var:=... in a (...) block instead
<olegfink>
?
threeve_ has quit []
<_zack>
moreover, a series of sequential transformation is really a functional way of seeing a program, a syntax that make the sequence explicit is just good(TM)
<olegfink>
vixey: the problem specification in my head follows the process, which is the same order as my ocaml code. Natural language is more complicated.
<vixey>
ok
<vixey>
oh well I didn't convince anyone :p
<_zack>
vixey: in spite of that, can you explain which danger do you see in having that operator? I didn't get that
<_zack>
I mean, OK, you don't like it, but what harm it does?
<vixey>
_zack, yes I already did that, like I said you should read the channel logs
<bluestorm>
from what i find in the logs, you find the |- symbol confusing
<bluestorm>
(you could also argue that if such operators become more-or-less "standard", then you'll have to read the code of others people using it)
<_zack>
vixey: just reread, I've only found a "very odd choice", and a "a shame to take it over from other languages", which don't really answer my question
<vixey>
bluestorm, I didn't argue that though
<bluestorm>
yes
<bluestorm>
from the analogy with Smerdyakov i'd guess that you don't read others people code anyway :-'
<bluestorm>
i agree that |- is probably not an optimal choice
<bluestorm>
and |> has the advantage of F#-compatibility, and the disadvantage of being associativity-flawed
mishok13 has quit [Read error: 60 (Operation timed out)]
* olegfink
still can't understand what's wrong with |> associativity
<bluestorm>
finding a consensus on intimate matters like infix operators naming is damn hard
<bluestorm>
olegfink: |> is right but <| is not
<olegfink>
there I agree.
<Yoric[DT]>
Well, we'll just fix this with Camlp4 (and possibly using pa_do).
<vixey>
F# compatability is not an advantage
<bluestorm>
Yoric[DT]: i'm not sure it's a good idea, but why not
<Yoric[DT]>
We're not aiming for F# compatibility. We're aiming for something nice.
<Yoric[DT]>
bluestorm: well, still waiting for alternatives :)
<bluestorm>
i've proposed >^ but seems nobody loves it
<bluestorm>
(a possible critic is that on some keyboards, ^ is a dead key)
<vixey>
Yoric[DT]: Do you use |> though?
<bluestorm>
i've used >@ in the past but people tend to find it awful
<vixey>
bluestorm, I actually don't see why anybody would use any operator for this
<bluestorm>
vixey: to get rid of parenthesis
<Yoric[DT]>
vixey: sometimes.
<vixey>
why would you want to get rid of them?
<Yoric[DT]>
Sometimes, they hamper reading.
<Yoric[DT]>
Not always.
<vixey>
if they are meant to be there, it seems right to have them
<Yoric[DT]>
This is not an operator to be abused.
<Smerdyakov>
Yoric[DT], which operators should I abuse?
<Yoric[DT]>
+
<Yoric[DT]>
:)
<vixey>
Yoric[DT: what did you think of my earlier suggestion though?
<Yoric[DT]>
Dropping it from the language?
<Yoric[DT]>
s/language/library/
<vixey>
move the section 'Fundamental functions and operators' out of batteries core and put into a new one called 'Trivial combinators'
<vixey>
then people aren't forced with this
<Yoric[DT]>
Well, they never are.
<_zack>
vixey: they aren't force right now either
Axle has left #ocaml []
<_zack>
vixey: and you still need to explain why you have a problem with the mere existence of |>
<vixey>
Yoric[DT]: everything in batteries looks fine except this one awful thing
<bluestorm>
i would find it nice to have them in an "Infix" submodule
<vixey>
_zack, I'm sorry you are asking me the same question again and again, I have answered it already
<vixey>
_zack, please do not keep doing tat
<mfp>
Yoric[DT]: is there any reason for not submitting the ANN to reddit?
<_zack>
vixey: no, you didn't, but I can assume that now you like &&& and *** ?
threeve_ has joined #ocaml
<_zack>
Yoric[DT]: in debian we usually don't install 0-sized files, while some of the *.idex file are, so I'm changing batteries_help to avoid complaining if some .idex file do not exist, do you see any problem with that?
<_zack>
Yoric[DT]: I don't, because anyhow they were empty files
<_zack>
(JFTR: just 2 of them: class_types.idex and attributes.idex)
<Yoric[DT]>
_zack: no, no problem.
<Yoric[DT]>
They probably won't remain empty forever, though.
<Yoric[DT]>
mfp: well, someone has done it, I think.
<_zack>
yep, sure, the day they won't be empty they'll get installed, and everything will be fine as well
<Yoric[DT]>
sure
<mfp>
Yoric[DT]: really? must have been downvoted quickly (missed it)
<bluestorm>
does anybody read the "ocaml" subreddit ?
purple has quit [Read error: 110 (Connection timed out)]
<mfp>
uh, I for one, rarely do
purple has joined #ocaml
<bluestorm>
Yoric[DT]: btw, i have a question regarding the syntax extensions i'm gonna add for alpha 3
<bluestorm>
should the development happen in the batteries tree ?
<_zack>
bluestorm: I guess the answer depends on how generic they are
<bluestorm>
hm
<_zack>
if they are more general then batteries they should better be decoupled from batteries, so that other people can use them
<_zack>
let's be good freesw players :)
<bluestorm>
ok
<_zack>
but I don't know which ext you are referring to, so the decision is still up to that
<bluestorm>
the "try .. finally" and "let try ...", wich are "more general" as you said
<_zack>
yup, definitely, still there is a third alternative
<_zack>
keep them in the batteries tree, but in a subdir which is usable independently from the rest
<_zack>
so that we can distribute easily small tarballs of the xt
<_zack>
ext
<_zack>
I'm not sure how a good idea that is
<kattla>
Has anybody used symbiosis?
<bluestorm>
(other question : do some of you have an idea of when batteries will be 3.11 ready ? i heard the problem are bin-prot related but i'm not very up-to-date on these things)
<_zack>
bluestorm: no idea, but I know you will soon be able to try it out in debian :)
<Camarade_Tux>
bluestorm, mfp tried very recently and has patches iirc
jeddhaberstro has joined #ocaml
<bluestorm>
i guess they're waiting for the next Janestreet Core release wich was to happen "soonish"
<_zack>
bluestorm: yeah, right :/
hkBst has joined #ocaml
velco has quit ["Went wasting time elsewhere ..."]
threeve_ has quit []
<bluestorm>
i have a question regarding the "let .. try" construct
<bluestorm>
should it be "let try a = b in c with ..." or "let try a = b with ... in c" ?
<bluestorm>
i prefer the first solution actually
<Yoric[DT]>
_zack: by the way, what about a Debian package?
<_zack>
Yoric[DT]: working on it
* Yoric[DT]
still needs to get rid of 3 pages from his paper, though.
<_zack>
Yoric[DT]: once done, I'll blog about it, don't worry :)
<Yoric[DT]>
:)
<_zack>
Yoric[DT]: FWIW, the missing bit for debian package is graceful degradation for the top-level when doc is not installed. Doc is in a separate package in Debian, because it is quite big (13 Mb)
apples` has joined #ocaml
<_zack>
I'm adding a Debian-specific patch for that (not to Batteries itself of course), which suggest to install the -doc pacakge
filp has quit ["Bye"]
jeddhaberstro has quit []
comglz has joined #ocaml
BSWolf has quit [Read error: 104 (Connection reset by peer)]
<Yoric[DT]>
ok
comglz has quit ["AddToFunc ExitFunction I Exec exec sudo halt"]
itewsh has joined #ocaml
glondu has left #ocaml []
Smerdyakov has quit ["Leaving"]
zbrown has quit [Read error: 60 (Operation timed out)]
<flux>
bluestorm, why not .. | `Exn (End_of_file) -> .. | `Exn x -> raise x? too complicated?
<bluestorm>
well
<bluestorm>
that would complicate the code a bit
<bluestorm>
but i could eventually do that
velco has joined #ocaml
<bluestorm>
i think i will but i focused on getting the correct behaviour first
<bluestorm>
(i agree in that case a bit of optimization will not hurt)
<flux>
also.. polymorphic variants.. ;-)
<bluestorm>
but you're right, i'm not so happy with the "try raise exn with ..."
<bluestorm>
another possibility would be match (try `Result (read_line ()) with End_of_file -> `Exn (List.rev acc)) ...
<bluestorm>
but that would break tail-recursion in the "with ..." position
<flux>
`Exn (List.rev acc)?
<flux>
looks strange :)
tomh-- has joined #ocaml
tomh-- is now known as tomh__
tomh__ is now known as tomh___
tomh___ is now known as tomh
jlouis has joined #ocaml
bluestorm has quit [Remote closed the connection]
vixey has quit ["Ex-Chat"]
vixey has joined #ocaml
seafood has joined #ocaml
Snark has quit ["Ex-Chat"]
itewsh has quit ["KTHXBYE"]
seafood_ has joined #ocaml
seafood has quit [Read error: 110 (Connection timed out)]
seafood_ has quit []
threeve_ has joined #ocaml
jeddhaberstro has joined #ocaml
<mbishop>
Are "|" "&" and "^" used in standard OCaml?
<mbishop>
well I know ^ is
<Camarade_Tux>
# true & false;;
<Camarade_Tux>
- : bool = false
<Camarade_Tux>
but it's advised not to use it
<Camarade_Tux>
(just like 'or')
<mbishop>
what about "|"? I ask because I saw "&&&" "|||" etc are used in Batteries, but they are used the way they work in Haskell
<mbishop>
and I generally used &&& etc for bitwise shorthand
<mbishop>
so now I'll have to find new symbols, I guess :P
* Camarade_Tux
fears the "heated discussion"
<Yoric[DT]>
Let's just say that these symbol names are still up for debate :)
<Camarade_Tux>
and I can't answer ;)
<mbishop>
well
<mbishop>
I don't particularly like tripling the symbol for bitwise shorthand anyway
<mbishop>
just don't know of any better symbols
itewsh has joined #ocaml
<mbishop>
F# uses &&&, ||| etc for bitwise stuff, which is why I used those in OCaml in the first place
threeve_ has quit []
<mbishop>
Yoric[DT]: also, any news on a .deb package for alpha 2?
<Camarade_Tux>
mbishop, there's been a 3-hours discussion about these operators, their use, their future, their origin (F#, haskell, ...), and anything you could imagine ;)
<mbishop>
Camarade_Tux: well I missed it :P
<Camarade_Tux>
you're lucky ;)
<Camarade_Tux>
as for the debian package, zack is working on it, I don't know if he's done yet (must be close anyway)
<Yoric[DT]>
mbishop: _zack promised me it was under way.
* Camarade_Tux
goes into urgent deadline mode :)
<_zack>
guys, calm down :) what's such a frenzy? :)
<_zack>
anyhow I'm doing the final build right now
<_zack>
(though of course, one know that it's final only after the final tests)
* Yoric[DT]
is painfully aware of that.
<_zack>
the fact that ocamldoc takes 25 minutes does not help either ;)
<mbishop>
_zack: will there be an x86 version this time?
<_zack>
well, there was also the other time, you just have to wait for the experimental autobuilders to catch up
<vixey>
it seems to me that ASCII isn't big enough
<_zack>
my upload will be amd64, as that is my devel machine
<Yoric[DT]>
_zack: don't blame me :)
<_zack>
Yoric[DT]: I wasn't :)
<Yoric[DT]>
A new and improved ocamldoc would be nice.
<mbishop>
Hmm, so I read the scrollback, and I would agree that |- isn't very nice, but I like |>
<mbishop>
And as for the haskellish triple operators, they can stay as long as I can find a better replacement for bitwise operators :P
<_zack>
eventually, after my upload for amd64, the package gets rebuilt for all archs, it is just that being "experimental" there is some buildd sloppyness at a time
<mbishop>
hmm k
<_zack>
it did work, but due to some irony, I've some checksum mismatch, sounds familiar? :)
<_zack>
they are totally different checksums, but it's still funny
<Yoric[DT]>
Yep, familiar :)
rwmjones has quit ["Closed connection"]
Kerris4 has quit ["Leaving."]
Kerris0 has joined #ocaml
Kerris4 has joined #ocaml
Kerris0 has quit ["Leaving."]
<mbishop>
I just installed the "old" Batteries for ubuntu (just downloaded the .deb myself)
itewsh has quit ["KTHXBYE"]
ygrek has quit [Remote closed the connection]
_zack has quit ["Leaving."]
marmotine has quit ["mv marmotine Laurie"]
willb has quit [Read error: 145 (Connection timed out)]
Yoric[DT] has quit [Read error: 104 (Connection reset by peer)]
snhmib has quit ["Good riddance!"]
hkBst has quit [Read error: 131 (Connection reset by peer)]