struktured_ has quit [Remote closed the connection]
Jedai has joined #ocaml
<Palace_Chan>
in the description for List.fold_left it says: ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a .....does that mean it is a function from a function with argument a function from some type 'a to function of 'b to 'a to a
<Palace_Chan>
ugh, how would one read this; ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a
<Myoma>
Palace_Chan: Do you know what 'a -> 'b -> 'a means?
<Myoma>
fun x y -> x;; is one
<Palace_Chan>
Myoma, expects 'a and returns a function which expects 'b and returns 'a
<Myoma>
fun x y -> x + y;; has type int -> int -> int
<Myoma>
but that' could be used there too, if 'a = 'b = int
<Palace_Chan>
int -> int -> int is equivalent to int -> (int -> int) isnt it ? since -> is right associative
<Myoma>
yes
<Palace_Chan>
fun x y -> x+y;; takes x first (int), then returns a function with expects and int and returns an int (it gets y and returns x+y as an int)
<Myoma>
so fold_left takes some kind of cominding function ('a -> 'b -> 'a) a seed 'a and them mashes the 'a list together to get the result a'
<Myoma>
combining-*
<Palace_Chan>
oh so the ('a -> 'b -> 'a) can be thought of as a fun x y -> x+y int->int->int function
<Palace_Chan>
?
<Myoma>
that is just one possibility
<Palace_Chan>
what do you mean by "a seed 'a and then mashes the 'a list together to get the result 'a"
<Palace_Chan>
there's also a 'b list lying around there too
<Myoma>
oh sure, I should have said 'b list
<Palace_Chan>
so the ('a -> 'b -> 'a) means something involving an 'a and a 'b argument return an 'a argument, and then that along with another 'a argument returns a 'b list and then the 'b list goes through something to produce 'a...i sort of got lost again
<Palace_Chan>
this is from List.fold_left by the way
<Myoma>
Why don't you look at the code for this function
<Palace_Chan>
in an example i found it, it is invoked as: List.fold_left (fun sublist next -> next :: sublist) [] l where l is an 'a list
<Palace_Chan>
fun sublist next -> next looks like it would match with the 'a -> 'b -> 'a portion of the type of List.fold_left
<Myoma>
no it wouldn't
<Myoma>
fun sublist next -> next : 'a -> 'b -> 'b
<Myoma>
(fun sublist next -> next :: sublist) : list 'a -> 'a -> list 'a
tar_ has quit ["byebye"]
<Palace_Chan>
Myoma, i have trouble reading these longer -> chains, do they have a name or something so i may look it up online, maybe a little tutorial or something ?
<Palace_Chan>
i mean, not the arrows but the whole "a -> b -> c -> (d -> e -> f -> g) -> h" thing
<Myoma>
I'm actually writing it completey wrong
<Myoma>
it should have been, 'a list -> 'a -> 'a list
<Palace_Chan>
yea
<Myoma>
no wonder you are confused
<Palace_Chan>
i mean still, im new to functional programming and stuff like "a -> b -> c -> (d -> e -> f -> g) -> h -> a -> b -> c -> (d -> e -> f -> g) -> h" is confusing to me anyways
<Myoma>
where are you seeing that?
<Palace_Chan>
i made up that abcdefgh thing, it's just the -> chains longer than int -> int -> int that suddenly i cant read
<Palace_Chan>
like, i guess let add3 x = x+3;; in top level would say add3 is of type int -> int and ok, take an int return an int...but then all of a sudden BAM ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a and whoa
Mr_Awesome has joined #ocaml
Ched- has quit [Read error: 110 (Connection timed out)]
Ched- has joined #ocaml
rog1 has joined #ocaml
middayc_ has joined #ocaml
middayc has quit [Read error: 110 (Connection timed out)]
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
<hcarty>
Palace_Chan: That sort of type may take some time to get used to, but like anything else once you do they make sense
<hcarty>
Practice worked best for me - particularly reading through the OCaml standard library documentation, comparing the function types with the short descriptions the documentation provides
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
struktured has joined #ocaml
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
Associat0r has quit []
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
<Eridius>
Palace_Chan: ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a, that's List.fold_left, right?
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
TypedLambda has quit [Read error: 110 (Connection timed out)]
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
middayc_ has quit []
<Palace_Chan>
Eridius, sorry i was having dinner, yes that is List.fold_left
<Palace_Chan>
hcarty, how do i access the documentation, through the website ?
<Palace_Chan>
val fold_left : ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a
<Palace_Chan>
List.fold_left f a [b1; ...; bn] is f (... (f (f a b1) b2) ...) bn.
ozy` has joined #ocaml
<Palace_Chan>
lol, that's the documentation for List.fold_left
<Palace_Chan>
thelema, but thanks for the link i have bookmarked it
struktured has quit [Read error: 110 (Connection timed out)]
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
Vital303 has quit [Read error: 110 (Connection timed out)]
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
Vital303 has joined #ocaml
<thelema>
Palace_Chan: that documentation doesn't suffice?
<Palace_Chan>
thelema, no it helps, as hcarty was telling me it just takes some time to get used to the types in functional programming
<thelema>
:) yup, ocaml's types express so much more than most languages. I love ocaml's rich type system.
<Palace_Chan>
with the currying and all, see something like int -> int -> int was like cool the currying..but then after that i suddently saw ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a and it sorta blew my mind
<Palace_Chan>
i'm less than 24 hours new to functional programming
Snark has joined #ocaml
<thelema>
yup, I can see how that'd shock a new learner
<Palace_Chan>
thelema, did you just get used to it with time ?
<thelema>
yeah. there's still some types I don't understand, but they're either having to do with polymorphic variants or objects
<Palace_Chan>
thelema, wow, earlier i was asking if there was a name for ocaml's way of expressing types (the -> chains) so i might look up some tutorial on it
<thelema>
a -> b just indicates a function from type a to type b. The syntax is used by many ml-based languages, I think/
<thelema>
the only reason that there's a chain instead of a single -> has to do with currying (lots of one-argument functions that return other functions)
<Palace_Chan>
thelema, yea, it can get pretty wild though there with all the parens and stuff
<thelema>
if you like, you could describe the type of a C function with an arrow, but it would be pretty simple.
<thelema>
yes, it does get wild because functions work as 1st class values in functional languages.
<Palace_Chan>
right, whereas in C, java and all it is always just, a return type and a list of args
<thelema>
yup, a simple list of arg types and a return type. no complex description of any functional arguments.
sporkmonger has quit []
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
jeddhaberstro has quit []
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
ygrek has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
bzzbzz has quit [Remote closed the connection]
seafood has joined #ocaml
bzzbzz has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
seafood has quit []
seafood has joined #ocaml
seafood has quit [Client Quit]
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
rog1 has quit [Read error: 110 (Connection timed out)]
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
Palace_Chan has quit ["Leaving"]
Snark has quit ["Ex-Chat"]
Vital303 has quit ["Leaving."]
bzzbzz has quit [Remote closed the connection]
bzzbzz has joined #ocaml
Palace_Chan has joined #ocaml
Palace_Chan has quit [Client Quit]
Myoma has quit ["Leaving"]
Myoma has joined #ocaml
tar_ has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hugh
<Yoric[DT]>
sorry, wrong channel
<Yoric[DT]>
here, it's "hi"
<Myoma>
it's ok you can 'hugh' or 'harrumph' here I think
seafood has joined #ocaml
Camarade_Tux_ has joined #ocaml
<Yoric[DT]>
Well, harrumph to you all, then.
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
Camarade_Tux_ is now known as Camarade_Tux
tar_ has left #ocaml []
tar_ has joined #ocaml
<tar_>
Is there an example of creating a set of objects with the same class?
<tar_>
less annoying than: module MySet = Set.Make(struct type t = int let compare = fun a b -> compare a#st b#st end);;
<tar_>
s/int/class name
ygrek has quit [Remote closed the connection]
<Yoric[DT]>
tar_: I don't quite understand the question.
ygrek has joined #ocaml
<Yoric[DT]>
Does anyone know if there's a convenient way of grouping plenty of .cmi into one single file?
tar_ has quit [Read error: 110 (Connection timed out)]
<flux>
I don't think there is
<flux>
how is it more convenient, the files are tucked away from the visibility anyway?
<flux>
s/is it/would it be/
seafood_ has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
itewsh has joined #ocaml
rog1 has joined #ocaml
itewsh has quit [Read error: 113 (No route to host)]
<Yoric[DT]>
flux: well, it would simplify distribution.
<flux>
yoric[dt], how? one already needs to deal with multiple files anyway?
<flux>
and one likes to bundles the individual .mli-files anyway?
<flux>
and it's nice for tools like cmigrep to work..
<Yoric[DT]>
Well, I have 100+ .cmi in Batteries Included and it's only going to get worse.
<Yoric[DT]>
So packing them all into one may make my life a tad easier :)
<flux>
I have 877 cmi-files at /opt/stow/godi/*** and it doesn't annoy me at all :)
<Yoric[DT]>
:)
tomh_-_ has joined #ocaml
<flux>
with .cmo-files the problem is that one needs them at linking stage, so .cma-files help there, but with .cmi they just need to be foundable by the compiler..
<flux>
s/found/find/
<Yoric[DT]>
Fair enough.
lde has quit [Read error: 104 (Connection reset by peer)]
lde has joined #ocaml
maattd1 has joined #ocaml
itewsh has joined #ocaml
maattd1 has quit [Client Quit]
marmotine has joined #ocaml
<Yoric[DT]>
smimou: pin
<Yoric[DT]>
smimou: ping
ygrek has quit [Remote closed the connection]
<smimou>
Yoric[DT]: pong
ygrek has joined #ocaml
itewsh has quit [No route to host]
middayc has joined #ocaml
Myoma has quit [Read error: 104 (Connection reset by peer)]
Myoma has joined #ocaml
ygrek has quit [Remote closed the connection]
seafood has joined #ocaml
vpalle has joined #ocaml
ygrek has joined #ocaml
vpalle has quit [Client Quit]
vpalle has joined #ocaml
sporkmonger has joined #ocaml
Associat0r has joined #ocaml
seafood_ has quit [Read error: 110 (Connection timed out)]
struktured has joined #ocaml
Anarchos has joined #ocaml
seafood has quit []
<Anarchos>
Did anyone encouter an infinite loop in caml_oldify_one ?
Linktim has joined #ocaml
<Yoric[DT]>
Not me.
<Yoric[DT]>
Gasp, there's no findlib package for ocamldoc...
Anarchos has quit ["Vision[0.8.5-0418]: i've been blurred!"]
pango_ has quit [Remote closed the connection]
<Yoric[DT]>
ertai: ping
pango_ has joined #ocaml
Myoma has quit ["Leaving"]
<thelema>
Yoric[DT]: ping
<Yoric[DT]>
pong
<thelema>
is there an archive for batteries-devel? The one I try to get to on ocamlforge doesn't work.
<Yoric[DT]>
At the moment, the archive seems down.
<Yoric[DT]>
It worked two or three days ago.
threeve has joined #ocaml
Asmadeus has joined #ocaml
<thelema>
ok. I just wanted to check which of my posts I failed to get to both you and the list. One time I cought the lack of a CC after I pressed the send button, so I copied the same reply from my outbox and sent it to the list.
<gildor>
mfp: ping
<Yoric[DT]>
thelema: I could try and look in my local archives, if you want.
Kerjean has quit [Read error: 113 (No route to host)]
batcoder-71 has joined #ocaml
batcoder-71 has left #ocaml []
pants1 has quit [Read error: 110 (Connection timed out)]
tomh_-_ has joined #ocaml
<Yoric[DT]>
thelema: yep, I've read it already.
<Yoric[DT]>
thelema: big difference: we're actually building a standard library, not a product.
<Yoric[DT]>
Se we need genericity.
<thelema>
we don't need to over-engineer a solution when simple "gloves" work.
<thelema>
(in reference to including libfoo which depends on batteries)
batcoder-7 has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
And I advocate that forking code (because that's what's bound to happen) is usually not the solution.
sporkmonger has quit []
<Smerdyakov>
Forking code works great with the right infrastructure for rejoining later.
<Yoric[DT]>
Well, in that case, I don't see how rejoining could happen.
<Yoric[DT]>
Plus it needs more manpower to fork a library than to simply depend on it.
<Smerdyakov>
It's easy, if modules are developed separately, as first-class entities, and then linked into a single combined module.
<Yoric[DT]>
Which is not the case here, as we are in the process of adding dependencies between modules.
<thelema>
Smerdyakov: I don't see how the module system takes care of dependent modules
<Smerdyakov>
It doesn't. The point is that you can develop the modules separately.
Proteus__ has quit [Read error: 113 (No route to host)]
Proteus has joined #ocaml
<Smerdyakov>
If someone wants a fancy new module, he can build it, and also build a version that combines his module and many others.
<thelema>
my mental model still favors complete integration of the good parts into a solid, coherent whole, not just bolting together a bunch of libraries and calling that "batteries"
<Smerdyakov>
I'm pretty sure that approach is doomed in the long run.
<Yoric[DT]>
Well, I'm coming from the opposite approach :)
<Smerdyakov>
It's a pretty 1990's methodology. :)
<Yoric[DT]>
Smerdyakov: which one?
<Yoric[DT]>
Dependencies or forking?
<Smerdyakov>
Yoric[DT], having a centralized arbiter of what the code is, controlling all of the modules.
<Yoric[DT]>
Well, that fits a bit of both approaches, but mostly the forking one :)
<thelema>
Smerdyakov: it seems to work reasonably well for the linux kernel.
maattd has joined #ocaml
<Smerdyakov>
I don't know. Linux is crap, from a scientific standpoint, so I won't draw any lessons there.
<flux>
it hasn't been done before, has it, that "the new standard lib is the composite of these unforked modules"?
<Yoric[DT]>
That's also what Haskellites are attempting.
<thelema>
how many re-implementations of input/output are there?
<Yoric[DT]>
I don't know. Why?
<thelema>
cryptolib has one, Camomile, Extlib, ocamlnet, JS's core... all incompatible
<Yoric[DT]>
Camomile, ExtLib and OCamlNet are compatible.
<Yoric[DT]>
I don't know about Cryptolib.
<Yoric[DT]>
And I don't remember about Core.
<thelema>
camomile & extlib are compatible? IIRC, camomile's is based on objects, and extlib a 4-field record.
<Yoric[DT]>
thelema: look in IO, ExtLib has both.
<Yoric[DT]>
And the object is the same in Camomile, ExtLib and OCamlNet.
<Yoric[DT]>
As for Core, I think it's the same as the Base library.
<thelema>
but you've gone and extended the record-based one in extlib.
<flux>
regarding cryptolib, does it have a home page?
<Yoric[DT]>
On an unrelated note, who's familiar with findlib around here?
<thelema>
flux: it's one of Xavier's projects
<Yoric[DT]>
thelema: because they're compatible anyway.
<flux>
google should have "this is the url, give me keywords that best find me this page" :)
<thelema>
Yoric[DT]: the question is one of harmonization - how to harmonize all these design choices without forking?
<Yoric[DT]>
thelema: that's where the glue comes in.
<Yoric[DT]>
We write a new API on top of existing APIs.
<thelema>
ick.
<flux>
ah, it indeed is cryptokit, not cryptolib, no wonder my searches didn't work :)
<Yoric[DT]>
That's the clean technique.
<Yoric[DT]>
We keep the code untouched, except for very specific cases (ExtLib vs Camomile).
<flux>
it does lead to larger codebase and to a solution that is more complicated than necessary. the latter can hurt developers when they attempt to understand the library.
<thelema>
I believe the work of implementing and maintaining a separate stdlib (there's only so many ways to implement quicksort) to be less than that of building cruft on top of existing libraries.
<flux>
but I understand the layers provided are quite thin?
kig has quit [Remote closed the connection]
<Yoric[DT]>
That's the idea.
<Yoric[DT]>
I mean, forking OCamlNet is bound to be harder than providing a few additional modules to add Unicode.
<Smerdyakov>
Let me try again to say what I meant: Forking needn't mean copying code.
<Smerdyakov>
Think of as library as a module. You [open] the "standard" version and add some modules of your own.
<Smerdyakov>
s/as library/a library
<Yoric[DT]>
What do you mean by "open"?
<thelema>
and providing a few enhancements, especially in separate files, is bound to get harder to maintain and understand.
<Yoric[DT]>
That's possible.
<thelema>
I might even separate each external library into two parts
<thelema>
the part that actually does the work, and convenience/helper/stdlib improvements desired by the author to make getting the work done easier.
<Smerdyakov>
Yoric[DT], the [open] declaration of OCaml or SML.
Linktim has quit ["Quitte"]
<Yoric[DT]>
Smerdyakov: in that case, that's essentially what I'm advocating.
<thelema>
if you just depend on the external library, that second part doesn't get shared with the end-users... which is one major reason for having batteries in the first place.
<Yoric[DT]>
thelema: you haven't read my blog entry, have you? :)
<thelema>
the really long one where you outlined each module structure?
<Smerdyakov>
Any approach where people sit down and think for a while is going to fail.
<Smerdyakov>
You need waits of linking together different solutions created by different people, with refactoring to bridge API gaps.
<Yoric[DT]>
Smerdyakov: we both agree with that.
<Yoric[DT]>
We're just discussing two ways of doing it.
<thelema>
OCaml Batteries Included is an attempt to provide a uniform library environment for OCaml, both for beginners and for experienced developers, which should give programmers out-of-the-box support for most common tasks. Although OCaml Batteries Included has to be a library for technical reasons, the objective is not to create some brand new framework but rather to integrate existing works
<thelema>
I agree with you up to here.
<thelema>
with dependencies towards existing libraries, and relying on the mechanisms of Findlib and GODI/Apt/Rpm for dependencies resolution.
<thelema>
This part, I don't like.
<Yoric[DT]>
Smerdyakov: in essence, thelema says "import the code and modify it"
<Yoric[DT]>
Smerdyakov: in essence, I way "depend on the code and add a layer of glue"
<Yoric[DT]>
s/code/library/
<Smerdyakov>
Yoric[DT], neither will work without some serious tool support.
<Yoric[DT]>
s/way/say/
<Yoric[DT]>
Smerdyakov: well, care to detail?
<thelema>
Yoric[DT]: I imagine something like the project to implement the Java stdlib by the open source community. - one roof for all the code.
<Yoric[DT]>
thelema: we agree on that.
<Smerdyakov>
Yoric[DT], no. It's an important open research area.
<thelema>
Yoric[DT]: ?? we agree on "one roof"?
<Yoric[DT]>
thelema: we just disagree on how to build the house under the roof :)
<thelema>
ah. yes, you seem to want to put a big roof over other people's houses, and I want to take their furniture and move it into my house.
<Yoric[DT]>
Exactly.
<Yoric[DT]>
I'm willing to add some paint, too.
<thelema>
I agree that there's something to be gained by decentralization in terms of how far this project will scale.
<thelema>
But I also want to knock down the walls between some of the houses so that one can go from one to another without noticing.
<Yoric[DT]>
That's the point of the paint.
<Yoric[DT]>
Now, I agree that for some libraries, painting will be harder than knocking down the walls -- and reciprocally.
<thelema>
paint doesn't change the structure of the internal houses. I expect better long-term results from taking the good ideas and leaving the bad ones.
<Yoric[DT]>
Do you have an example of something which can't be done by paint?
<Yoric[DT]>
Now, I should perhaps change metaphor.
<thelema>
yes, this metaphor is wearing thin.
<Yoric[DT]>
:)
<thelema>
camomile has lots of helper libraries to do the job of character transcoding.
<Yoric[DT]>
Sure.
<thelema>
some of those are more generally useful, for example sets and maps over ints (specialized for speed)
<flux>
my view is that if all the code were imported and forked for the OCaml Batteries project, that would become the repository for the code to go to die. keeping the real meat as dependencies, each individual project can keep living on and it sort of automatically gets into other people's "standard lib", without a separate new standard library release.
<thelema>
no, I guess you could do that with just importing libraries... hmmm...
<thelema>
but you likely wouldn't get to know the code you were importing if you kept it at arm's length.
<flux>
if there was excess manpower for maintaining a real different fork, then I would prefer a fork. but I'm guessing that it is beneficial for the batteries project to need as little maintenance as possible.
<Yoric[DT]>
thelema: that's a risk.
<Yoric[DT]>
But for most libraries, I'd say it's ok.
<thelema>
flux: why would the projects keep living while the batteries code dies?
* Yoric[DT]
agrees with flux.
<flux>
thelema, well, it needs someone to integrate code back from the main fork back to batteries
<Yoric[DT]>
thelema: because to avoid that, we would need to convince the original developers to work for us, too.
<thelema>
I see many projects as effectively dead because noone uses them because it's too much of a pain.
<flux>
thelema, and if someone makes patches to batteries, they need to be fed back to the main streams
<flux>
to minimize the fork size, which minimizes the effort to maintain it
<thelema>
Yoric[DT]: I like the idea of getting the developers of camomile and extlib on our side. (although from the response in teh extlib-devel list, this is probably naive.
<Yoric[DT]>
thelema: I agree on both accounts.
<thelema>
flux: This is stdlib code - it should be maintainable by anyone. Any non-complete code shouldn't get included.
<Yoric[DT]>
Actually, I tend to believe that rwjones would be happy to help us.
<Yoric[DT]>
But he won't work on two projects at once.
<Yoric[DT]>
thelema: buggy code can always get past tests.
<thelema>
which is why we need to become the defacto standard by integrating all the good parts from everyone.
<thelema>
Yoric[DT]: I'm not suggesting tests. I prefer peer review.
<Yoric[DT]>
thelema: doesn't change the argument.
<Yoric[DT]>
Sometimes, buggy code can pass.
<Yoric[DT]>
Which means a need for patches.
<Yoric[DT]>
Which means a need for someone to maintain that part of the code.
<thelema>
and we issue a fix and we go on.
<Yoric[DT]>
With the fork approach, we need to understand 100% of the code and be willing to maintain 100% of the code.
<thelema>
we don't *need* to maintain a great relationship with the external project
<Yoric[DT]>
With the glue approach, we only forward bug reports upstream.
<thelema>
and when they don't fix what we want?
<Yoric[DT]>
Which is the Debian/Fedora approach.
<Yoric[DT]>
Well, in that case, we improvise.
<Yoric[DT]>
We always have the option of forking dead code if upstream doesn't answer.
<Yoric[DT]>
I just advocate that we should start with the opposite approach.
<thelema>
the last camomile release was in 2006
<thelema>
extlib has effectively frozen itself.
<flux>
there is always the possibility of forking. but going back from a fork is going to be a lot more difficult.
<Yoric[DT]>
thelema: I agree that Camomile is most likely frozen.
<Yoric[DT]>
That's one Camomile has been one of my exceptions from day 1.
<Yoric[DT]>
For ExtLib, I'm not sure.
<thelema>
ocamlnet 2.2 released in 2006, no newer releases?
<Yoric[DT]>
I intend to insist to get our patches upstream.
<Yoric[DT]>
thelema: would you be willing to first try without forking?
<Yoric[DT]>
I'm not 100% sure it's possible. Although I tend to believe that, for most cases (e.g. not Camomile vs ExtLib), that approach should be sufficient and more manageable.
<thelema>
Annexlib : 2006, OUnit: 2005
<Yoric[DT]>
Well, in other words, the OCaml world is dead, is it?
<thelema>
there's some new code I'm not including on purpose, but my point is that lots of good code will have to be maintained by us.
ygrek has quit [Remote closed the connection]
<Yoric[DT]>
That's something that may happen.
<Yoric[DT]>
But I still believe that we should start with the opposite state of mind.
<thelema>
and I find lots of value in not including packages wholesale, but reviewing what code we include.
<Yoric[DT]>
We're not taking over the world, we're offering something new.
<thelema>
brb, laundry
<Yoric[DT]>
:)
<Yoric[DT]>
I believe we're going to face lots of hostility if we attempt to take over projects.
<Yoric[DT]>
Rather than just giving access to them.
<Yoric[DT]>
« No implementations provided for the following modules »
<Yoric[DT]>
Is that familiar to someone? (that's an unrelated question, mind you)
<Yoric[DT]>
I keep encountering that message when attempting to compile to native code using ocamlfind.
<Yoric[DT]>
Ahah, I think I have it.
<Yoric[DT]>
It's a "-linkpkg"
<Eridius>
anybody know what the point of compiling without -linkpkg?
<Eridius>
*is
kelaouchi has quit [Read error: 54 (Connection reset by peer)]
<Yoric[DT]>
Eridius: I'm not clear about the meaning of "-linkpkg".
<Eridius>
it means link those packages
<Yoric[DT]>
But I had a problem with modules being linked twice when using that flag.
<Eridius>
it's like the -l switch for linking C programs
<Yoric[DT]>
It's probably not a good idea if you're building a library, I guess.
kelaouchi has joined #ocaml
<flux>
well, you don't need -linkpkg when you are not producing executables
<thelema>
Yoric[DT]: I think we're already 2/3 of the way to "taking over" extlib. You really want to link camomile because... why? Most likely we'll end up maintaining it anyway.
<thelema>
hmmm... maybe lots of my attempts to avoid linking together these packages really come from my dislike of ocaml's package system.
<thelema>
(not the module system, the whole findlib thing)
<thelema>
each time I've tried to use an external package, I've been met with lots of pain and suffering. maybe that's why I avoid them, and why I think this project should get stuck in the compiler.
nuncanada has joined #ocaml
<Yoric[DT]>
I understand the reluctance.
<Yoric[DT]>
I *think* I've solved my issues with findlib.
<Yoric[DT]>
And frankly, if we can avoid taking over more than extlib, I'd be happy.
<Yoric[DT]>
(that and I intend to keep sending upstream patches to ExtLib anyway)
<thelema>
good luck with that. My feelings is that if they want the code, they can get it out of your tree.
<Yoric[DT]>
Side note: the godi package seems to work.
<thelema>
Yoric[DT]: there's a bunch of dead stdlib-extension projects that have good code to include.
<Yoric[DT]>
grmph
<Yoric[DT]>
Still problems with documentation generation.
<Yoric[DT]>
You mean AnnexLib?
<thelema>
annexlib, missinglib, stdlib2, xstr
<Yoric[DT]>
If you think AnnexLib and a few others of the same kind, I'd go for merging these with ExtLib (which means yes, including them into the tree) and sending patch upstream (towards ExtLib).
<Yoric[DT]>
I agree that these ones probably should get into the tree.
<Yoric[DT]>
These are usually simple utilities, so ok.
<Yoric[DT]>
But not, say, Cairo or OCamlNet.
<thelema>
oh yeah, we should also put calendar on the list of code to include.
<Yoric[DT]>
Yeah, I was planning to.
<thelema>
I'm not sure about ocamlnet. cairo doesn't need inclusion.
<Yoric[DT]>
Well, I believe that Cairo would be a nice addition.
<Yoric[DT]>
But definitely not as an inclusion.
bluestorm has joined #ocaml
<Yoric[DT]>
(do we agree on the vocabulary, btw?)
<Yoric[DT]>
bluestorm: hi
<Yoric[DT]>
We're discussing Batteries design.
<thelema>
I see your differentation and will attempt to keep by it.
hkBst has quit [Read error: 104 (Connection reset by peer)]
<thelema>
inclusion = merging the code into our codebase, addition = add as dependency
<thelema>
and we're expecting godi/findlib to take care of dependency management so it's reasonable for people to compile our code?
<Yoric[DT]>
thelema: (ok with the vocabulary)
<Yoric[DT]>
thelema: indeed.
<Yoric[DT]>
At the moment, compiling code against the godi package is as hard/easy as
<Yoric[DT]>
* copying a file myocamlbuild.ml provided with the documentation
<Yoric[DT]>
* adding "pkg_batteries" to file _tags
<Yoric[DT]>
That's it.
<Yoric[DT]>
Assuming you're using ocamlbuild, that is.
<Yoric[DT]>
Probably different with other build tools, but I'm not familiar with OCamlMake, OMake et al.
<Eridius>
what's myocamlbuild.ml?
<bluestorm>
Eridius: it's an ocamlbuild plugin
<Yoric[DT]>
as bluestorm
* Eridius
doesn't know anything about ocamlbuild, except playing with it a bit to get eigen-seamcarve to work with his godi installation
<bluestorm>
Yoric[DT]: btw, we could provide the ocamlbuild-findlib module in the "Tool" module
itewsh has joined #ocaml
<bluestorm>
that would make the "copy ocamlbuild.ml" operation looks like "let module M = Tools.OCamlbuild.Findlib(struct end) in ()"
<bluestorm>
now i have your mails to read
<thelema>
Yoric[DT]: any chance of including everything needed to bootstrap batteries within a simple tarball distro?
<bluestorm>
whoa : documentation with an index frame :p
itewsh has quit ["KTHXBYE"]
<Camarade_Tux>
completely unrelated but ocaml should really have a cross-compiler, it's about ten times faster to compile for windows
<thelema>
Camarade_Tux: there's some work done lately in that direction.
<Camarade_Tux>
thelema, by the inria team ? I'm asking because I've seen Eric C. Cooper's patch but it doesn't really fit here
<Camarade_Tux>
and that would be really really great =)
Palace_Chan has quit [Client Quit]
<Yoric[DT]>
bluestorm: not possible, I'm afraid.
<Yoric[DT]>
I've considered that but you need to be able to link with Batteries first.
<Yoric[DT]>
thelema: I hope so.
<Yoric[DT]>
thelema: I would like to see a Community OCaml with Batteries Included inside (tm) :)
<thelema>
that becomes much harder with external dependencies
<Yoric[DT]>
I realize there's a (large) difficulty here.
<Yoric[DT]>
Doing that would pretty much require including godi (I have no idea how hard that is).
<Yoric[DT]>
...
<Yoric[DT]>
Maybe not, actually.
<Yoric[DT]>
Perhaps only findlib.
vpalle has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
And that shouldn't be too hard.
<bluestorm>
yes, if we depend only on easy to build findlib-friendly packages that should not be a problem
<Yoric[DT]>
bluestorm: well, that's the idea.
<Yoric[DT]>
Most packages that I know of are findlib-friendly anyway.
<fremo>
anybody using efuns ?
<fremo>
I cant compile it...
<Yoric[DT]>
fremo: is it still maintained?
<fremo>
I dont think so
<Yoric[DT]>
Oh, actually, I was thinking of jofuns anyway.
<Yoric[DT]>
The distributed version of efuns :)
<thelema>
To compile Efuns, you need Objective-Caml version 2.01 at least. <- slightly old code...
<fremo>
any relation with jocaml ? no...
<Yoric[DT]>
Yep.
<fremo>
heh
<fremo>
double heh
<fremo>
ok, ok...
<fremo>
and peerple ?
<fremo>
I cant get source from the Inria gforge...
<fremo>
the svn stale (/spellcheck)...
<Yoric[DT]>
I don't even know what that is.
<fremo>
a kind of private peer to peer if I understand correctly
<fremo>
best way for doing P2P IMO...
<fremo>
using AES
<Yoric[DT]>
fremo: checking out wfm
<fremo>
and friends
<Yoric[DT]>
Interesting.
<Yoric[DT]>
I know of a research project which would need that.
<Camarade_Tux>
peerple is written by some former mldonkey devs ;)
<fremo>
Warszawska Fabryka Motocyklowa ?
<fremo>
Wired For Management ?
<fremo>
...sorry...
<Yoric[DT]>
Works For Me.
<fremo>
ha ! ok :)
<Yoric[DT]>
:)
<fremo>
I try again
<Yoric[DT]>
I used svn checkout svn://scm.gforge.inria.fr/svn/peerple
<thelema>
fremo: that command is working for me.
<fremo>
yes ! it's working now :)
<fremo>
I tried this afternoon...
<Yoric[DT]>
thelema: come to think about it, I believe that a (conceptually) simple Makefile should be sufficient for your problem.
<thelema>
the problem of merging batteries with the ocaml compiler source?
<Yoric[DT]>
Yes.
<Yoric[DT]>
It's "just" the matter of
<Yoric[DT]>
* building the compiler and base library
<Yoric[DT]>
(using Inria's Makefiles)
<Yoric[DT]>
* walking through a number of directories containing the .tgz of any required additional library and calling make on each such library
<Yoric[DT]>
* doing the same with Batteries.
<Yoric[DT]>
We still have the problem of pretending that Batteries.Standard is Pervasives.
<Yoric[DT]>
I believe there's support for that in the Inria Makefiles.
<Yoric[DT]>
Plus there's a flag -no-stdlib (or -nostd or something such, I'm not sure) for ocamlc.
<Yoric[DT]>
-- on a sidenote, the godi package now works also for the documentation.
<Yoric[DT]>
In other words, I believe that we now have a full godi package for Batteries Included.
<Camarade_Tux>
using module Pervasives = Batteries (or the like) is better than using -nostdlib imho
<thelema>
I guess the pervasives -> batteries.standard switch could happen after compiler installation by replacing pervasives.ml with batteries.standard
<Yoric[DT]>
thelema: I'm not 100% sure about pervasives.ml -- batteries depends on pervasives
<Yoric[DT]>
I mean, we're using string everywhere for the moment :)
<Yoric[DT]>
Camarade_Tux: do you know of a simple way of adding this to ocamlc?
<Yoric[DT]>
And why is it better?
<thelema>
Yoric[DT]: we can fix that by including anything we need from pervasives into batteries.standard.
<Yoric[DT]>
thelema: true.
<thelema>
there's no magic in pervasives - it's just a module that gets opened by default.
<Yoric[DT]>
MMmhhh....
<bluestorm>
i suggest we delegate the "-nostdlib" work to Camarade_Tux wich seems supportive right now :-'
<Yoric[DT]>
Yeah, we still need to find a way to get Batteries.Standard opened by default.
<Camarade_Tux>
bluestorm, lol ;p
<Yoric[DT]>
That's the big issue.
<Yoric[DT]>
Camarade_Tux: seriously, if you have an idea, we're interested.
<Camarade_Tux>
hum, let me check something
<bluestorm>
it feels so good to gently delegate work to someone called "camarade"
<Yoric[DT]>
:)
<Yoric[DT]>
Now, I guess it's a bit too later to start adding new features.
<thelema>
if batteries.standard really works as a drop-in replacement for pervasives, we just hijack the existing pervasives by copying over it.
<Yoric[DT]>
s/later/late/
* Yoric[DT]
wonders if he should do a new preview release.
<bluestorm>
Yoric[DT]: i don't think anyone depends on Batteries right now, so you shouldn't bother with compatibility
<Yoric[DT]>
thelema: that may work.
<Yoric[DT]>
bluestorm: what do you mean?
<Yoric[DT]>
No, I mean it's too late (11.40 pm) to start adding new features tonight :)
<bluestorm>
ah :]
<thelema>
Yoric[DT]: if you can get batteries to compile from a tarball (including any dependencies), I'll get it hooked into the compiler.
<Camarade_Tux>
in fact by just renaming your file to pervasives.cm* you can have the desired effect
<Camarade_Tux>
just use "ocaml -I /path/to/some/dir/with/pervasives.cm*" and this should work
<thelema>
Camarade_Tux: it'll have to go in the right place.
<thelema>
or there'll be some wrapper around the compilers... hmm, too many wrappers.
<Camarade_Tux>
I'm too tired to even move and still have plenty things to do =/
tomh_-_ has quit [Client Quit]
<Yoric[DT]>
Nice.
<thelema>
Camarade_Tux: that's what they make tomorrows for.
<Yoric[DT]>
I may try that.
<Yoric[DT]>
...
<Yoric[DT]>
I'm not 100% sure that's going to work, though.
<Yoric[DT]>
My code depends on Pervasives.
<Yoric[DT]>
So I can't have two modules with the same name.
<Yoric[DT]>
Now, of course, I could just copy & paste pervasives.ml .
<Yoric[DT]>
I even have the file for that.
<thelema>
you'll have to have enough of pervasives in batteries.standard for it to work without pervasives.
<thelema>
i.e. in a -no-stdlib condition
<Camarade_Tux>
you may get around that by using "module Pervasives = ..." but I can't think properly anymore ;)
<Yoric[DT]>
thelema: I think I can do that.
<Yoric[DT]>
pervasives.ml is only 447 lines and some of these are not going to be included anyway.
<Camarade_Tux>
thelema, yes but tomorrow I have even more things to do, and in fact I should pack, plus I won't have internet next week (but I'll finish ocamllive ;) )
struktured has quit ["Konversation terminated!"]
* Yoric[DT]
wonders if string_of_* *_of_string should remain in Batteries.Standard.
<Camarade_Tux>
that's probably just me but I like print_endline
<thelema>
Yoric[DT]: if we have submodules for all of them, I don't mind Integer.of_string
<thelema>
and Integer.to_string
<Camarade_Tux>
neither do I
<thelema>
but for backwards compatibility, I dunno how to get rid of them.
<thelema>
I don't think you can
<Camarade_Tux>
personnaly I'd break backward compatibility, and if programmers are too lazy, "sed -i -e 's/int_of_string/Integer.of_int/'", that's really fast and still sure
<Yoric[DT]>
Unfortunately, it's going to be a little bit more complex than Integer.of_int.
<Yoric[DT]>
Unfortunately, it's going to be a little bit more complex than Integer.of_string.
<Yoric[DT]>
It's bound to be "Data.Numeric.Int.of_string".
<Yoric[DT]>
Which is somewhat more annoying.
<Yoric[DT]>
So I guess we'll just leave these here.
<Camarade_Tux>
considering how small Pervasives is, I think that won't be a problem
<Camarade_Tux>
just one thing, don't add too many categories and levels for the modules, I've tried .net twice and gave up each time because the function I wanted was lost somewhere deep in a sub-sub-sub-sub-sub-module (I think that's the correct level for xml parsing...)
struktured has joined #ocaml
tomh_-_ has joined #ocaml
<Yoric[DT]>
Camarade_Tux: I'm not sure it's always possible.
<Yoric[DT]>
Xml parsing will probably be around [Languages.Xml.Parse], though.
<Yoric[DT]>
Which might be a tad more readable than sub-sub-sub-sub-sub-modules.
<Yoric[DT]>
Of course, that's when I find out how to automatically open [Batteries].
<Yoric[DT]>
Which probably means delving deeper into -no-stdlib .
mgodshal1 has quit ["leaving"]
ozzloy has quit [Read error: 110 (Connection timed out)]
<thelema>
heh. Apparently by setting OCAMLLIB=path/to/batteries, that'll replace the existing stdlib.
<thelema>
In orcer to do this, we have to provide all stdlib capabilities within batteries -- is this off the table?
<Camarade_Tux>
I wanted an exemple so : "System.Xml.XmlDataDocument..::.Load", I'm not sure it's exact though, I lost myself in the api reference...
<Camarade_Tux>
the worst thing though is probably the name "System" which is completely meaningless
<Yoric[DT]>
thelema: where does the stdlib stop?
<Yoric[DT]>
mmmhhhh....
<jlouis>
The ZINC experiment paper from 1990 is really interesting!
<Yoric[DT]>
Come to think about it, -nostdlib is probably not the right way to go.