<flux>
sexplib is a standalone package that does exactly that? maybe core uses it?
<orbitz>
oh that's true, i just always associate it with core
<orbitz>
yes you can install sexplib on yoru own. opam install sexplib
<osa1>
great, now how can I use it ? seems like it doesn't have a documentation
<orbitz>
use it like i did and compile with -package sexplib and -syntax sexplib.syntax i think
<orbitz>
ops no
<orbitz>
-package core,sexplib,sexplib.syntax -syntax camlp4o is how i compile that
<orbitz>
so just remove the core
<thelema>
osa1: batteries provides printing functions that make it much easier to create print functions, nothing automatic
<thelema>
i.e. List.print (Tuple2.print Int.print String.print) stdout [(1,"xy");(2,"yz")]
RagingDave_ has quit [Quit: Ex-Chat]
<fasta>
What's an easy way to reuse code in OCaml for use in _oasis projects? For example, with shell code you can use the source command and there is a very low barrier to make a library.
<fasta>
With OCaml I have the impression you actually need to create a bunch of functions before it is worth the effort.
<fasta>
As a result my OCaml utility programs are programs, not libraries.
<orbitz>
fasta: I make libraries out of most everything
<orbitz>
fasta: my ocaml projects are a collection of ocamlfind-enabld dirs, and I compile them as if they wer eany other library. Pushing them out on their own is easy if I decide to doso
leoncamel has joined #ocaml
<fasta>
orbitz: ok, so you add some directories to some environment variable and it magically works?
<orbitz>
yes
<orbitz>
OCAMLPATH
<orbitz>
or if you use ocamlbuild -I dir I think
<fasta>
orbitz: does that also work with opam, etc.?
<orbitz>
fasta: Opam just executes your build script, my build script establiseh teh paths
<orbitz>
it's not very ocamly, but it's how I like it
<orbitz>
but opass in opam uses the ocamlbuild trick with -I
<fasta>
orbitz: I mean: doesn't setting OCAMLPATH interfere with opam?
<orbitz>
No, why would it?
<fasta>
orbitz: I don't know.
<orbitz>
fasta: I append (or prepend) to OCAMLPATH, so whatever is there is still there
<fasta>
orbitz: ok, so for extreme convenience you could just append everything you ever created.
<fasta>
And then by the time something has really grown package it up more properly.
<fasta>
Does OCAMLPATH override the standard locations?
<fasta>
Or does it only add to it?
<fasta>
Really annoying that searchengines throw away case.
<fasta>
We have 100 times cheaper storage, but still no uppercase search.
<fasta>
This variable may contain an additional search path for package directories. It is treated as if the directories were prepended to the configuration variable path.
<fasta>
Thanks, author of man 5 findlib.conf
<fasta>
orbitz: and does oasis or ocamlbuild not reset OCAMLPATH to be more 'pure' or something like that?
<orbitz>
fasta: if you use ocamlbuild, you use -I to specify the path containing your lbraries, so no OCAMLPATH
<osa1>
is there a way to #use multiple files ? my ocamlop can't find a module that is in same folder with file I'm #using
<adrien>
compiling foo.ml to foo.cm* defines a module "Foo"
<adrien>
#use doesn't do that
<adrien>
#use is like copy-pasting
* orbitz
never usees #use beyond topfind
lopexx has joined #ocaml
lopexx has quit [Client Quit]
ben_zen has joined #ocaml
lopex has joined #ocaml
lopex has quit [Client Quit]
lopex has joined #ocaml
<mfp>
fasta: IIRC you have to install conf-libev via OPAM (and also IIRC it would re-compile lwt as needed automatically)
wmeyer has joined #ocaml
Cyanure has joined #ocaml
<fasta>
mfp: what a horrible system that it works like that.
<fasta>
mfp: thanks for the help
<fasta>
A more 'proper
<fasta>
' system would allow all possible library versions to be installed without conflict.
<mfp>
np
<fasta>
orbitz: how did your Nix experiments go?
<orbitz>
Fine. I have the Core Suite installed via it
<fasta>
orbitz: do you run the OS or just the prefix?
<orbitz>
OS on a VM
<fasta>
orbitz: and where are your real development tools (on your real OS)?
<mfp>
fasta: I guess OPAM's ability to have multiple "OCaml environments" (and to clone an existing one) installed at once and to switch easily is meant to address that
<osa1>
after compiling my sources to multiple .cmo files, how can I load them in toplevel ?
<fasta>
mfp: yes, but that quickly becomes unmanageable.
<fasta>
mfp: exponential blowups for example.
<mfp>
I can picture that
<Armael>
osa1: you can #load "your.cmo" iirc
<orbitz>
fasta: what do you mean?
<mfp>
how do you specify which "lib combination" you want to link against in Nix?
<fasta>
orbitz: I assume that in the end you want to run a program on your real OS, not on the VM.
<orbitz>
mfp: you have to define a package nme based on thecombination
<fasta>
orbitz: and regarding my earlier comment, I meant tools like an editor, etc.
<orbitz>
fasta: nope, generally no
<orbitz>
i edit remotely
<fasta>
orbitz: because there is some fast server on which you compile?
<orbitz>
no i just dont't write softwar that needs to be run on my local machine
<fasta>
orbitz: ok, so how do you deploy now with nix?
<fasta>
orbitz: do you use those makedeb targets, etc.?
<orbitz>
The stuff I write is all for personal consumption so ther eis no real deploy step
<fasta>
orbitz: so, you run it on the VM then?
<fasta>
orbitz: i.e. the programs you are interested in.
<orbitz>
Although every lib I depend on exists in opam, so leaving my little environment isn't much more than either installing them via opam and compiling my package or adding my package to nix
<orbitz>
fasta: yep
<orbitz>
seems to work well so far
<fasta>
orbitz: yeah, I suppose with the right hardware it's not really noticable.
<orbitz>
All the sfotware I write has been compilable on a 500meg NixOS VM without issue
<orbitz>
fasta: but like I said, my Nix packages is really just mirror what I want from Opam, so not much of a big deal
<fasta>
I see opam as an inferior tool which just has gotten more traction.
<orbitz>
inferior to what?
<fasta>
It's the same thing with 'popular' programming languages.
<fasta>
orbitz: nix.
<orbitz>
They are not attacking the same problem
<fasta>
orbitz: nix is a superset of opam, unless I don't understand opam.
<orbitz>
fasta: Almost. The main distinction is that opam can't install all of its dpendenceis
<orbitz>
so it's an incomplete univers
<orbitz>
but it's also meant to integrate with other peoples package management
<fasta>
orbitz: yes, that's true, but long term that's just a bad idea.
<fasta>
In the short-term it's something that 'works'.
<orbitz>
maybe
<orbitz>
from an ocaml perspective it makes signfiicantly more sense
<fasta>
How so?
<orbitz>
because a lot less people are goingto adop an entirely new package manager to use your language than are going to install a little program that manages its own ocaml packages
RagingDave has joined #ocaml
<fasta>
Technically one could build a compiler which would take opam input and translate it to nix.
<fasta>
It could even potentially build the packages in the exact same way.
<fasta>
(even the native C ones)
<fasta>
(At least when they are distribution packages_
leoncamel has quit [Ping timeout: 264 seconds]
<fasta>
Now, that would probably go quite far, but it's not impossible.
leoncamel has joined #ocaml
ontologiae has quit [Ping timeout: 252 seconds]
<orbitz>
fasta: yes i'll probaly write opam->nix eventually
<orbitz>
fasta: i dont' think opam contains dep informtio nfor non-ocaml deps
<thelema>
orbitz: from what I see, opam integrates with other peoples package management very poorly
<avsm>
hm? OPAM is a source-based package manager
<avsm>
it's not meant to integrate with other people's package managers. That's why it keeps everything in its own area
<avsm>
(for things like compiler switches, custom pins, and so forth. It's for development)
<thelema>
exactly
ttamttam has joined #ocaml
<avsm>
so does anyone actually use Nix regularly here (aside from fasta's useless rant)
<avsm>
i used Nix for some time after reading their excellent paper on NixOS, but the constraints weren't quite powerful enough for ocaml
<orbitz>
avsm: I run NixOS on a VM
<orbitz>
I like it, but you have to be pretty hands on with it (which is good for me, bad for my grandmother)
<orbitz>
I find it significantly easier to do experiments with than othe rpackage managers, it's trivial to go backto a pre-experiment state
<avsm>
orbitz: it seems ideal for cloud-y image construction indeed. I'll take it for a drive again soon, thanks!
<wmeyer>
orbitz: the question the practical value - I found simple apt is most of the time good - so Nix is maybe step forward from the perspective of adding/developing new packages
<orbitz>
avsm: yeah def. There is also a chef/puppet thing built on top called Charon i think, I haven't used it
<orbitz>
I've always found apt difficult to reason about
<orbitz>
but nix comes with its own host of issues
* orbitz
shrugs
<wmeyer>
I'd like to try Nix
<avsm>
the NixOS paper is quite nice; they covered a lot of the UNIX-specific problems they encountered