impy has quit [Read error: Connection reset by peer]
impy has joined #ocaml
dnolen has quit [Quit: dnolen]
philtor has quit [Ping timeout: 255 seconds]
ankit9 has quit [Quit: Leaving]
joewilliams is now known as joewilliams_away
ulfdoz has quit [Ping timeout: 255 seconds]
ulfdoz has joined #ocaml
cizra2_ is now known as cizra2
edwin has joined #ocaml
mfp has quit [Ping timeout: 246 seconds]
mfp has joined #ocaml
Yoric has joined #ocaml
ankit9 has joined #ocaml
ikaros has joined #ocaml
ocp has joined #ocaml
boscop has quit [Ping timeout: 240 seconds]
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
Cyanure has joined #ocaml
flux has quit [Read error: Connection reset by peer]
flx_ has joined #ocaml
flx_ is now known as flux
Cyanure has quit [Remote host closed the connection]
Yoric has quit [Quit: Leaving.]
boscop has joined #ocaml
ulfdoz has quit [Ping timeout: 276 seconds]
Yoric has joined #ocaml
Cyanure has joined #ocaml
Yoric has quit [Quit: Leaving.]
larhat has joined #ocaml
ftrvxmtrx has joined #ocaml
wagle has quit [Remote host closed the connection]
wagle has joined #ocaml
<gildor>
bitbckt: yes, the server hosting the forge seems to have failed between 00:08 and 00:25 this morning. I need to open a bug to OVH so that they can have a look at it (again)
ikaros has quit [Quit: Ex-Chat]
ikaros has joined #ocaml
qlife has joined #ocaml
Yoric has joined #ocaml
mnabil has joined #ocaml
thomasga has joined #ocaml
Yoric has quit [Read error: Connection reset by peer]
Yoric has joined #ocaml
pdhborges has joined #ocaml
pdhborges has quit [Quit: Leaving.]
mnabil has quit [Remote host closed the connection]
milosn has quit [Ping timeout: 250 seconds]
milosn has joined #ocaml
lopex has joined #ocaml
ygrek has joined #ocaml
rwmjones_afk is now known as rwmjones
pdhborges has joined #ocaml
pdhborges has quit [Quit: Leaving.]
<rixed>
Hi camlers!
<rixed>
ocamlmktop gives me this: "Reference to undefined global `Camlp4'"
<rixed>
does it ring a bell to someone?
ygrek has quit [Ping timeout: 250 seconds]
rwmjones has quit [Ping timeout: 240 seconds]
dnolen has joined #ocaml
<adrien>
would anyone happen to have the Hilbert curve implementation I made a few months ago (doubt it but worth asking)
rwmjones has joined #ocaml
lopex has quit [Quit: Page closed]
lopex has joined #ocaml
sepp2k has joined #ocaml
rwmjones has quit [Read error: Operation timed out]
rwmjones has joined #ocaml
<hcarty>
rixed: Maybe it's not linking dynlink.cma? Just a guess though.
<rixed>
hcarty: well, probably related since it works at home and one of the difference is that my home machine do not support dynlink. I replaced ocamlfind+makefile by custom compile.sh and now it works :)
ygrek has joined #ocaml
Snark has joined #ocaml
ygrek has quit [Ping timeout: 250 seconds]
dnolen has quit [Quit: dnolen]
lamawithonel has joined #ocaml
thomasga has quit [Quit: Leaving.]
lamawithonel has quit [Remote host closed the connection]
lamawithonel has joined #ocaml
thomasga has joined #ocaml
Associat0r has joined #ocaml
gasche has joined #ocaml
gasche has left #ocaml []
bluestorm has joined #ocaml
<bluestorm>
hi
<hcarty>
bluestorm: Hello
<thelema>
hi
<hcarty>
Regarding the Enum operators - I'm of the opinion that most, if not all, of them should be moved from Batteries to Enum.Infix (and maybe Enum)
<hcarty>
The same operators could then be used in List.Infix, Array.Infix, Seq.Infix, etc.
<bluestorm>
from Pervasives ?
<hcarty>
bluestorm: Yes
<hcarty>
This would be a 2.0ism
<thelema>
Well, I don't mind enum being the default for those operators, with the option to open modules to change them to List, Array, etc.
<hcarty>
But if 2.0 requires OCaml 3.12 then it's less of an issue since you get local module open
<bluestorm>
(also, I don't like it so much when "private" communication happen on IRC and is buried forever in the logs; we should try to take the time to make a summary of what we say and send it on the list)
<thelema>
2.0 probably won't require 3.12
<thelema>
bluestorm: agreed, I'll post chat log on batteries-devel?
<hcarty>
thelema: In that case keeping the operators in Pervasives as well may not be such a bad idea. I still think that Enum is more surprising than it should be though.
<bluestorm>
thelema, great
<hcarty>
bluestorm: Yes, and if I remember it correctly I agree with the idea of having Foo.Infix (or .Operator or whatever name is used) and then include Foo.Infix at the end of Foo
<thelema>
hcarty: I agree about enum being surprising. Maybe we need to emphasize more it's not a lazy list, and encourage more use of lazy list
<hcarty>
bluestorm: So pre-3.12 can "open Foo.Infix" for minimal impact, and 3.12+ can use Foo.(...) for access to operators and functions
<thelema>
hcarty: maybe Foo.Op?
<hcarty>
thelema: Or Seq
<bluestorm>
that's fine
<bluestorm>
actually changing this (adding Infix systematically and including it in the end) was on my todo-list
<bluestorm>
but those last week I haven't had batteries time
<bluestorm>
if by chance you feel your patch-fu rising, don't hesitate
<hcarty>
bluestorm: I think ( --. ) for all appropriate modules (numbers, others?) could be helpful
<thelema>
hcarty: seq seems like a wierd compromise between enum and lazylist, I don't mind it being available for those who need exactly it, but think that enum and ll should be more pervasive
<bluestorm>
regarding enum / LazyList, bob zhang seems quite motivated to work on this
<hcarty>
My patch-fu is rather limited these days. New baby, so not a lot of coding time outside of work.
<thelema>
bluestorm: go ahead and commit on the v2 branch, I've technically made a beta1 release of it in oasis-db, and will make a more formal release soon.
<bluestorm>
(the main problem is : the Enum code is too ugly and ill-defined)
<bluestorm>
hcarty, congratulations
<hcarty>
bluestorm: Thank you!
<bluestorm>
thelema, regarding the v2 release, I'm wondering if you're not pushing things a bit too fast
<bluestorm>
maybe it would be good to have a pre-v2 release with the main changes available but not forced on the user, so that there can be a bit of adaptation
<hcarty>
thelema: But it would be bad to end up locked in to 2.0 compatibility with a bunch of half-baked changes
<thelema>
hcarty: 3.0 is always available to fix problems
<thelema>
but yes, I understand that we lose from including bad code
<thelema>
bluestorm: what would the pre-v2 (1.9?) release look like? it would be backwards compatible?
<bluestorm>
yeah, I was thinking something backward-compatible with the v2-changes in Future modules
<hcarty>
It would be nice if 2.0-final could be used to bring more consistency to Batteries.
<thelema>
ah, so that people could use each module at v1 or v2
<bluestorm>
(also I need to finish the bunch of changes that I have initiated these last months but not concluded, but maybe this can be done before the next release anyway)
<thelema>
hcarty: it will, but not magically everything gets fixed, things will improve at the rate that people contribute
<hcarty>
Maybe that pre-2.0 should be a separate release then. findlib name "batteries-next" or similar.
<bluestorm>
hcarty, thelema plans to stick to semantic versioning and that means doing major releases "often"
<thelema>
hcarty: I don't like that idea so much
<bluestorm>
we don't have much space after batteries-next-next
<hcarty>
bluestorm: batteries-next would always be "unstable" batteries
<hcarty>
Sort of like sid is to Debian
<bluestorm>
regarding Enum: I have poked bob a bit recently to know if he was still working on Enum; he is planning to, and has rather good ideas imho, but I don't think he will really start working before some time (he's moving from china to us iirc.), so probably not for the next release
<thelema>
hcarty: we could have that within the normal batteries -- [open Batteries_next] would be like [module List = struct include List include BatList include BatList.Future end
<hcarty>
Packing everything in shipped batteries seems like it's asking for trouble
<bluestorm>
we should also consider the 3.12 issue
<bluestorm>
at some point we will want to use 3.12 features in batteries, because it would also be improvements for the users (eg. potentially shipping some first-class modules)
<hcarty>
You require a very rapid release cycle, with potentially no non-Future changes, in order to keep users up to date if you put everything in batteries-stable
<bluestorm>
and maybe having both 3.12 and 3.11 code in the same package is delicate (but conditional compilation may be enough)
<thelema>
It seems reasonable for batteries to switch to 3.12 sometime, but let's be a bit conservative and wait until most linux distros have 3.12 available
<bluestorm>
yeah, of course
<bluestorm>
(me me, I have 3.12 on debian testing!)
schme has quit [Ping timeout: 276 seconds]
<thelema>
we can switch to 3.12 at batteries 3.0
<hcarty>
Does anyone but Ubuntu have OCaml but not 3.12?
<hcarty>
s/anyone/any distro/
<thelema>
hcarty: Okay, let's have a 1.9 release that makes big use of Future.
<thelema>
hcarty: I dunno.
lopex has quit [Ping timeout: 252 seconds]
<bluestorm>
you can't only consider distributions, there is Godi which is quite a major player
<bluestorm>
I'm not sure Godi use 3.12 by default yet, iirc. some packages have still to be adapted
ankit9 has quit [Quit: Leaving]
<bluestorm>
maybe we should ask users at the next release ("we're interested in knowing if some people cannot or don't plan to transition to 3.12 quickly...")
<hcarty>
bluestorm: godi supports 3.12, but I don't know what the default is
<gildor>
hcarty: AFAIK, default is 3.11 in GODI
pdhborges has joined #ocaml
sgnb` is now known as sgnb
ocp has quit [Quit: Leaving.]
AdmWiggin has quit [Ping timeout: 255 seconds]
lopex has joined #ocaml
<hcarty>
thelema: Why LinkedList over Seq?
Cyanure has quit [Remote host closed the connection]
<bluestorm>
Seq doesn't memoize
<bluestorm>
(you mean LazyList right ?)
<hcarty>
bluestorm: Oops, yes
<hcarty>
Is that a bad thing?
<hcarty>
Seq is a functional counterpart to Enum
<bluestorm>
it's usually not what you want
<bluestorm>
hm
<hcarty>
I'm thinking of something like (1 -- 1_000_000)
<hcarty>
I don't want that memoized
<bluestorm>
ok
lopex has quit []
<bluestorm>
I think we should be more precise on what our needs are (eg. for memoization or destructive update, the use case matter a lot), then try to come up with a saner behaviour than the current Enum (and possibly also a saner implementation)
<hcarty>
What is the use case for LazyList?
<bluestorm>
if you're interested in this, please start a thread on the list, cc'ing bob zhang ( bobzhang1988 , gmail )
<thelema>
hcarty: backtracking consumption
<thelema>
hcarty: if you want 1--1E6, use Seq or Enum.
ankit9 has joined #ocaml
<thelema>
bluestorm: I think enum is originally data conversion - List -> Set
<bluestorm>
yeah
<thelema>
but yes, this should be on batteries-list
<bluestorm>
but then we have advanced filtering and mapping
<bluestorm>
plus "clone"
<bluestorm>
(and if you think of it, "clone" doesn't make sense in a data conversion context)
<thelema>
bluestorm: maybe we should remove clone
<bluestorm>
I think that's what bob had in mind
<thelema>
not a bad idea.
<bluestorm>
well, start a thread :-}
<hcarty>
bluestorm: I'd like to have a better idea of why someone would use LazyList before I open my mouth too wide :-)
jamii_ has joined #ocaml
caligula__ has quit [Quit: Konversation terminated!]
<bluestorm>
hcarty: speak early, speak often ^^
<thelema>
fail early, fail often
<bluestorm>
one use I would see for lazy list is a kind of traversal with backtracking
<bluestorm>
or when you want to use side effects but make sure they're invoked only one per element traversal
<bluestorm>
(but probably for both use cases there would be a more specific and adapted solution)
<thelema>
well, discussion on enum started.
<hcarty>
Wouldn't Seq allow backtracking here as well?
<hcarty>
Not for the side-effects part though
<bluestorm>
well, it depends
<bluestorm>
but imagine eg. you're consuming input from stdin, how would you go using a Seq for this, without having a lazy list underneath ?
joewilliams_away is now known as joewilliams
caligula has joined #ocaml
ymasory has joined #ocaml
thomasga has quit [Read error: Connection reset by peer]
thomasga has joined #ocaml
thomasga has left #ocaml []
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
<hcarty>
bluestorm: That makes sense. Thank you - I admit, I wasn't thinking about side-effects.
<hcarty>
That seems like a rather limited focus though for a pervasive data type.
<bluestorm>
well
<bluestorm>
there may also be cases where you want to traverse a sequence more than once
<bluestorm>
and have applied several mapping/filtering operations, that you don't want to be recomputed each time
<bluestorm>
in this case the lazyness is used not to hold long lists, but to be able to stack transformations without traversing a (strict) sequence each time
<hcarty>
bluestorm: I need to go for a bit, but I hope to pick this back up here and on the list :-)
<hcarty>
bluestorm: Thank you very much for your explanations
<bluestorm>
you're welcome, thank you for taking care of things
enthymeme has joined #ocaml
pou has joined #ocaml
Yoric has quit [Quit: Leaving.]
rossberg has quit [Remote host closed the connection]
lopex has joined #ocaml
sepp2k has quit [Ping timeout: 250 seconds]
sepp2k has joined #ocaml
ymasory has quit [Quit: Leaving]
pdhborges has left #ocaml []
ftrvxmtrx has joined #ocaml
philtor has joined #ocaml
sepp2k has quit [Quit: Leaving.]
jamii_ has quit [Ping timeout: 255 seconds]
ymasory has joined #ocaml
Yoric has joined #ocaml
ygrek has joined #ocaml
bluestorm has quit [Quit: Leaving]
chambart has quit [Ping timeout: 250 seconds]
larhat has quit [Quit: Leaving.]
jderque has joined #ocaml
chambart has joined #ocaml
pdhborges has joined #ocaml
Anarchos has joined #ocaml
Tobu has joined #ocaml
lamawithonel has quit [Ping timeout: 255 seconds]
lamawithonel has joined #ocaml
rixed_ has joined #ocaml
<rixed_>
Why is ocamlfind mktop insisting on linking with batteries_uni.cma (and fail finding module Batteries) instead of using batteries.cma where I suppose it is defined?
<rixed_>
What does _uni stands for?
<thelema>
rixed_: non-threaded
<rixed_>
ah! thank you!
<thelema>
enable threads and it'll use batteries.cma
<rixed_>
So if the link try to locate module Batteries instead of Batteries_uni (I supose) it's probably because I have some module that's compiled with threads probablly..
<thelema>
not so much - it only depends on the predicates for that invocation of ocamlfind - if threads are enabled then, it'll use batteries.cma, otherwise batteries_uni.cma
ocp has joined #ocaml
<rixed_>
thelema: my only predicate regarding batteries is "batteries". Should I use something else?
<thelema>
batteries is a package, predicates are things like "mt" and "camlp4"
<rixed_>
thelema: yes figured out my mistake. Effective set of compiler predicates: pkg_unix,pkg_bitstring,pkg_bitstring.syntax,pkg_num.core,pkg_num,pkg_bigarray,pkg_str,pkg_findlib,pkg_camomile,pkg_batteries,autolink,byte,create_toploop
<thelema>
ah, tags.
<rixed_>
no "mt" in there
<thelema>
tags aren't predicates
<thelema>
you can usually use the tag "pkg_threads" to turn on the "mt" predicate
<rixed_>
thelema: but I don't want to turn on "mt".
<thelema>
then you should do [open Batteries_uni]
<rixed_>
I do not use thread, so if none of the libs I use require "mt" Im fine without.
<thelema>
[open Batteries] requires threads
<rixed_>
thelema: oh! of course, I'm looking for errors in camlfind when it's right there on my code as usual :)