<hcarty>
adrien: Maybe a "<big text>Documentation</big text>" like you have for downloads
<thelema>
hcarty: thanks - this helps
<hcarty>
thelema: Oh right. Under the "ocamldoc generated documentation" text :-)
<thelema>
hcarty: a couple lines above "Download"
<hcarty>
thelema: I added a flag to ocamlbrew to allow you to pass configuration options to OCaml. Testing now, then I'll push.
<thelema>
hcarty: it's there
<hcarty>
adrien: Having a prominent link to the documentation would be helpful
<hcarty>
adrien: Yes, I have found the same. Although I haven't had to use/fight lablgtk much recently.
<hcarty>
thelema: Quite true
<hcarty>
I also added a list of recipes, including how to install trunk
<hcarty>
It makes sense that it would, given that OCaml, findlib, and odb all do.
<hcarty>
I got a report that ocamlbrew works on OSX... so that's nice.
<hcarty>
I mainly run into issues with locally written and installed modules, when "make doc && make install-doc" hasn't been run recently enough
<hcarty>
I would love a better way to access that information locally
<hcarty>
I only use tk for the module browser GUI
<hcarty>
thelema: Do you know which flags are required to get OCaml's configure to detect X11 and Tk under more recent Ubuntus?
<hcarty>
thelema: Yes, it works with trunk (and maybe version/3.12?) but not 3.12.1 sadly.
<thelema>
hcarty: oh yeah, as the ocaml configure script can't autodetect libX11 on ubuntu 11.10, this is one defect in obrew
<thelema>
hcarty: maybe ocamlbrew could install git/darcs builds of batteries/oasis
<tonyg>
orbitz, hcarty, _habnabit: thanks! I'll check that out.
<hcarty>
tonyg: Which means that it can be done with the stdlib, but perhaps not in a line or two of code :-)
<hcarty>
tonyg: I'm fairly certain Batteries provides the means to do what you're asking.
2012-01-07
<adrien>
hcarty: iirc it was that; I could "fix" it with by changing xterm's config but that was not the best solution for other reasons (broke other things I think)
<hcarty>
adrien: Not sure why utop isn't working for you - there may be a missing prerequisite or some kind of terminal handling mismatch.
<hcarty>
adrien: Thank you for testing!
<hcarty>
I'm glad to hear it worked. You should now have (yet another) installation of OCaml 3.12.1 with a handful of libraries and tools to go with it.
<hcarty>
adrien: Oops! Thanks, I'll fix that :-)
<hcarty>
adrien: Fair enough :-)
<hcarty>
adrien: I could use tee to redirect the download output, but I wanted to keep the default output fairly terse
<hcarty>
adrien: You should get some progress updates from curl in the log file if you tail it during the download
<adrien>
hcarty: I meant for downloading but it would probably be interesting to know a bit about compilation too
<hcarty>
adrien: The closest thing you can get to a progress meter at the moment is tailing the log file
<hcarty>
adrien: I hope so too. But if it does, you get to keep all the pieces!
<hcarty>
adrien: Yes
<hcarty>
That will download and build OCaml, findlib, odb, oasis, Batteries, utop, ocamlscript in $HOME/ocamlbrew/ocaml-3.12.1/
<hcarty>
_habnabit: Did you run "oasis setup" or "oasis setup-dev" when you setup oasis for the package?
<_habnabit>
hcarty, yeah, it was simple enough that I could rewrite it to use ocamlbuild trivially
<hcarty>
_habnabit: But it looks like you figured out something already... I missed that last comment.
<hcarty>
_habnabit: You can wrap oasis around existing build systems. See Batteries as one example.
<hcarty>
adrien: The compare function for the set elements may not compare every component of a value in a set. In that case, it would matter if the existing element is replaced in the returned set.
<Drakken>
hcarty thx
<hcarty>
Drakken: Beyond that, (lots of?) camlp4 extensions or compiler changes are required.
<hcarty>
Drakken: Batteries has a large number of composable printing functions, and oleg wrote something similar using first-class modules.
2012-01-04
<thelema>
hcarty: I think I'll do that now.
<hcarty>
I'm a little concerned about the 3.13 oasis breakage. There is even an Official OCaml Developer post on that bug :-)
<hcarty>
thelema: It may be worth asking gildor to join to development team for odn and oasis on the forge
<thelema>
hcarty: I didn't end up working in ocamlbrew, although I thought I would when I started the email. I look forward to your announcement.
<hcarty>
s/that/the/ ... can't type today
<hcarty>
Chose to ignore that 'just do it' part that is.
<hcarty>
thelema: Yes... I saw that this morning and chose to ignore it. But I'm glad someone is addressing it.
<thelema>
hcarty: Pons' the "just do it" reply to Minsky
<hcarty>
vivanov: Cool! I will have a use for that soon, so that's good to know.
<vivanov>
hcarty: it does
<hcarty>
thelema: What is the context of the post?
<hcarty>
thelema: Don't let that hold you up though
<hcarty>
thelema: Not at all - I was planning to do a formal "alpha" announcement today
<thelema>
hcarty: do you mind if I mention ocamlbrew on caml-list?
<hcarty>
vivanov: ocamlnet does have support for sending email. I'm not sure if it includes any examples.
<vivanov>
hcarty, adrien: thx :)
2012-01-03
<hcarty>
It looks like Lwt_stream could do this as long as the input function was properly written
<hcarty>
It seems to do everything else :-)
<hcarty>
adrien: Yes, I wouldn't be surprised if Lwt could match this rather closely
<hcarty>
vivanov: You could hack something together with the Calendar module plus some sort of loop
2012-01-02
<hcarty>
thelema_: It would be nice if that could be done without losing 3.13's added flexibility and security.
<hcarty>
thelema_: Will some sort of fix for the 3.13 Hashtbl.create signature change go into Batteries 2.0?
<hcarty>
That's understandable
<hcarty>
The simplest install option is more aggressive than that - it installs OCaml 3.12.1, findlib, odb, oasis, and Batteries
<hcarty>
adrien: If you test it heavily over the next week, then maybe so!
<hcarty>
adrien: :-)
<adrien>
hcarty: more tests? so, -f by default next week? =)
<hcarty>
3.12.1, 3.12-svn, trunk
<hcarty>
On the positive side of things, I was successfully able to build three OCaml versions in parallel using ocamlbrew :-P
<hcarty>
I considered it, but I'm not willing to be that aggressive until it's been tested more :-)
<hcarty>
And install the latest stable version, which is currently hardcoded as 3.12.1
<hcarty>
Running it directly would prompt you for options
<hcarty>
adrien: The goal is to be able to, with just a few keystrokes, build and install (almost?) any version of OCaml + some basic tools
<hcarty>
adrien: "ocamlbrew -s version/3.12 -f" would build 3.12.x from Subversion and install findlib along with it
<hcarty>
adrien: "ocamlbrew -o" would, by default, only build the 3.12.1 .tar.gz, yes
<hcarty>
Brewing should be more usable now with Subversion targets
<hcarty>
thelema_: ocamlbrew has a few new options; -o for OCaml only; -f for OCaml+findlib+odb; -n [path] to specify a custom basename (ex. install OCaml 3.12.1 as $OCAMLBREW_BASE/stable)
<thelema_>
hcarty: n/p
<hcarty>
thelema_: Thanks, 'ocamlbrew -a' can run properly again.
<thelema_>
hcarty: permission detection disabled in HEAD
<thelema_>
hcarty: one for findlib permission and the other for executable/other permission i.e. --prefix
<thelema_>
hcarty: ok, I guess I need to break that into two perms
<hcarty>
s/locl/local/
<hcarty>
thelema_: Without the --prefix option, some packages (I don't remember which) were trying to install pieces under /usr/locl/
<hcarty>
thelema_: odb's automatic permissions check is breaking installation of some packages under ocamlbrew
2012-01-01
<thelema_>
hcarty: github.com/hcarty/oasis?
<thelema_>
hcarty or an oasis fix. We could fork oasis and put patches in the fork.
<hcarty>
It looks like it will take some ugly hacks to make the version/3.12 case work. That's a royal pain.
<hcarty>
The 3.13 case is more serious since it's a syntax error
<hcarty>
For the 3.12.2 case
<hcarty>
That seems to do the trick
<hcarty>
tr -d '[() ]' <<< "funky version here"
<hcarty>
If I add ' ' '(' ')' to the list of allowed version characters then type-conv builds
<hcarty>
It doesn't look like there is a way to get a root version (3.12.2 in this case) from ocaml(c)
<hcarty>
That version string is certainly a little odd
<thelema_>
hcarty: ah. well, fwiw, the odb packages file doesn't allow it either, although it doesn't allow ' ' in any key or value
<hcarty>
oasis doesn't allow ' ' in version strings. That's part of the problem.
<hcarty>
thelema_: A quick look indicates that is the only way
<thelema_>
hcarty: patching the setup.ml? blah.
<hcarty>
There may be a way to tell oasis to ignore the version check
<hcarty>
Cool
<hcarty>
Ah
<hcarty>
[^0-9]+?
<hcarty>
At least as a fall back mechanism
<hcarty>
3 = 3; 12 = 12; 1 < 2+dev4 (2011-11-10)
<hcarty>
I wonder if something simple-minded like splitting on '.' then doing a string comparison on each resulting piece until a comparison comes back as not equal would work
<hcarty>
I got the 11 and 10 swapped in the date, but that's not particularly important...
<hcarty>
So, for example, type-conv fails to install
<hcarty>
oasis's version checking rejects "3.12.2+dev4 (2011-10-11)" - or whatever the proper date suffix is - as being >= 3.12.0
<hcarty>
There are problems with version/3.12 too
<hcarty>
That's correct
<hcarty>
So while trunk brews, oasis'd libraries do not
<hcarty>
thelema_: trunk is brewable, but output from oasis breaks with trunk due to a bug fix in format handling
<thelema_>
hcarty: trying to get ocaml trunk brewable?
<hcarty>
gildor: Without that, everything with an oasis-generated setup.ml will fail under OCaml 3.13.x
<hcarty>
The scanf bug in oasis is/was apparently due to a bug in OCaml 3.12.x -
<letrec>
hcarty: this is exactly what I'm struggling with - I'm trying to install utop, which depends on camomile which I have installed in godi, but it's too old
<hcarty>
thelema: oasis, or at least setup.ml from oasis, seems to break in a few different ways under 3.12.2+dev: broken OCaml version checking; something to do with invalid log files
<hcarty>
letrec: As long as the version in GODI meets your needs, then yes it is generally easier that way
<letrec>
hcarty: so it's better to install a package in godi if it's available
<hcarty>
odb will, on the other hand, see GODI packages as valid since odb relies on findlib for dependency checks
<hcarty>
So if you want to install a GODI package, its dependencies must be met by other GODI packages.
<hcarty>
letrec, thelema: GODI will not be able to use odb-installed packages
<hcarty>
Fix pushed
<hcarty>
"reply_lower" <> "$reply_lower"
<hcarty>
I found the Continue? (y/n) bug...
<hcarty>
thelema: Remove the 1? I don't want a flood of OCaml compilation output though.
<hcarty>
That's not very helpful :-)
<hcarty>
Never mind, it is catching the error. But the output is being directed to the log file
<hcarty>
The trap isn't catching that error, which is also strange
<hcarty>
I'm not sure why that last prompt doesn't work. It's doing the same thing as the previous ones, as far as I can see
<hcarty>
in setup.ml
<hcarty>
L2939
<hcarty>
Not from the error, but I found it in setup.ml... one moment
<hcarty>
Invalid_argument("scanf: premature end of format string ``%S %S@\n''") -- That's the error I get with trunk + ounit
<hcarty>
Ok, I'll take a closer look. I changed the input handling a bit which may have broken that piece.
<hcarty>
Any chance there was a space after the y?
<hcarty>
That's very odd
<hcarty>
Ok, then it removed the log file. If it thinks the user said 'n' then it removes the log.
<hcarty>
Does it say "Exiting..." at the end?
<hcarty>
I think I only tested -t -a yesterday
<hcarty>
thelema: Thanks for the report, I'll take a look at it
<hcarty>
I'm going to try trunk again, then version/3.12
<thelema>
hcarty: an odd behavior report: -t -a seems to work, -t and then answering 'y' to all questions quits immediately, before any download
<hcarty>
thelema: I didn't either. It could be a bug, but I'm not willing to jump to that conclusion yet.
<hcarty>
thelema: Thanks. I'm going to start another test in a few minutes, but IIRC the error came from a bad format string in a scanf call.
<thelema>
hcarty: I'll try brewing trunk and see what error I get
<thelema>
hcarty: I guess it's good we get this testing out of the way now.
<hcarty>
thelema: The ounit issue may be due to something else, possibly an incompatibility between OCaml 3.13.x and oasis-generated setup.ml files
<thelema>
hcarty: about ocamlbrew - it's great
<thelema>
hcarty: about ounit and trunk
<thelema>
hcarty: really? that's too bad.
<orbitz>
hcarty: but does the allocator hold onto that or does it give it back to the OS?
<companion_cube>
hcarty: I think the question is about, in the case you free a lot of memory, whether Ocaml gives back some pages to the OS
<hcarty>
orbitz: I'm not sure I understand. OCaml has a garbage collector which automatically frees unused values.
<hcarty>
Unfortunately it looks like OUnit does not build against trunk
<hcarty>
thelema: Inspired by your recent odb efforts, ocamlbrew is about to get support for building OCaml from an arbitrary (official) SVN path
2011-12-29
<hcarty>
odb is similar to cpan(m); barbra seems more like a localized build environment creator
<hcarty>
concerns
<hcarty>
barbra and odb seem like they are addressing two different concenrs
<hcarty>
The fact that odb doesn't require you to create a configuration file to build utop is quite nice
<hcarty>
thelema: But I think that there is a lot of utility in odb's method.
<hcarty>
thelema: I agree, and it does look like barbra could handle that.
<thelema>
hcarty: it would be nice to automate the building of utop without calling odb three times - this looks like something that barbra would do
<thelema>
hcarty: probably
<hcarty>
thelema: I think a bash function could be enough, or a simple OCaml/Perl/whatever script
<hcarty>
I've used similar tools with Perl and they are very nice to have.
<hcarty>
thelema: It's something I would like to tackle at some point, either as part of the odb project, the ocamlbrew project, or a separate project.
<hcarty>
thelema: I agree that a tool external to odb itself would be nice for this
<hcarty>
As those may be patched in ways that are not easy to replicate
<hcarty>
If someone is using OCaml from a deb or rpm then it helps even more
<hcarty>
True, the complexity from the standpoint of environment variable changes is similar. The build time is a lot less, as is the effort to recreate the rest of the environment (libraries, etc.)
<thelema>
hcarty: faur enough, but the complexity of this seems the same as the complexity of switching ocaml versions
<hcarty>
As or potentially more useful than testing personal-project-a + batteries-vCurrent against OCaml-vCurrent+1
<hcarty>
Being able to quickly test personal-project-a against batteries-vCurrent+1, without needing to install a completely separate OCaml, is very useful
<hcarty>
So I, personally, am very interested in being able to use one OCaml installation against multiple sets of libraries
<hcarty>
thelema: That's part of the real work I am looking forward to doing soon :-)
<hcarty>
thelema: But part of getting real work done could involve testing code against batteries-git under ocaml-stable
<thelema>
hcarty: yes, and that's a compiler version change
<hcarty>
And then quickly swap back to ocaml-stable, Batteries-stable, etc. to get real work done
<hcarty>
My hope is that, between ocamlbrew and odb, it will be easy to test ocaml-3.13.0~gadt-super-awesome + Batteries-git + oasis + foo-lib with just a few commands
<hcarty>
thelema: One would still need to change OCAMLPATH, etc. to swap between ~/.odb's
<hcarty>
thelema: Can co-exist on the filesystem only
<hcarty>
~/brew-dev could have ~/.odb-stable ~/.odb-test; ~/brew-prod could have ~/.odb-stable
<hcarty>
thelema: I think it's nice to be able to have multiple odb roots for a single OCaml install
<hcarty>
thelema: Having ~/.odb, ~/.odb-project-a, ~/.odb-project-b?
<hcarty>
thelema: What would be violated, and how?
<thelema>
hcarty: grr, if I implement this, I'll have violated my church-and-state separation of ocaml versions and installing packages
<hcarty>
It's not automated, but the bundle could be isolated that way
<hcarty>
Shouldn't that be possible with some environment variable tweaking?
<hcarty>
I've done that before in GODI, to track dependencies for a project
<hcarty>
Well, something should(?) be installed - maybe just a META file?
<hcarty>
Ah
<hcarty>
thelema: It may not require any extra support
<thelema>
hcarty: yup. I guess I should support this too.
<hcarty>
Or, rather, dependencies
<hcarty>
thelema: It could be implemented as a package with no content, but with a list of requirements.
<thelema>
hcarty: yes, quite.
<hcarty>
thelema: odb bundles should be pretty straightforward...
<hcarty>
thelema: I was able to get ocamlnet to install via odb, but I only tested through a fresh ocamlbrew installation
2011-12-28
<hcarty>
And new entries could be added at any time
<hcarty>
Any given definition shouldn't change that often
<hcarty>
thelema: Yes, that's what I was thinking
<hcarty>
So rather than having the Batteries git definition sitting in ~/.odb/ it would be in some public location
<hcarty>
Just putting references to them
<hcarty>
thelema: Oh no, I don't mean fork the repositories
<thelema>
hcarty: I don't see much use for forking people's repos
<hcarty>
thelema: A public version of the local package support, strictly or primarily for HEAD versions of projects.
<thelema>
hcarty: I'd rather add patching support to odb and have a repo of patches
<hcarty>
thelema: Given odb's new VCS support, it might be cool to have a mostly static, public repository available with some libraries in it.
<hcarty>
There are still a lot of libraries managed in Subversion
<hcarty>
thelema: It was somewhat facetious... but SVN is a nice feature to have if versioning systems are supported.
<thelema>
hcarty: surprised that svn and/or cvs is a big feature
<hcarty>
thelema: Surprised at...?
<hcarty>
thelema: Woo!
<hcarty>
ousado: If you set a few environment variables properly it will
<hcarty>
flux: That's my expectation as well
<hcarty>
flux: Very true! open X in broke vim and emacs OCaml indentation IIRC.
<hcarty>
Well, part of why it's nice to have it.
<hcarty>
That's why it's nice to have the M.(...) equivalent
<hcarty>
everyonemines: You wouldn't generally use the let open M in .. syntax for something that short
<hcarty>
Requiring "let open" for local opens may make handling global and local opens easier. I haven't hacked on the compiler though, so I don't know for certain.
<hcarty>
Avoiding ambiguity? I'm not sure.
<hcarty>
Both are supported, with a slight change -- open Module in is now let open Module in
<hcarty>
That transformation is no longer required with 3.12.0+
<hcarty>
Or something resembling that
<hcarty>
let f x = open Foo in e --> let f x = let module M = struct include Foo let local_x () = e end M.local_x ()
<hcarty>
From 3.12.0 on there is language-level support without the performance penalty the syntax extension brought
<hcarty>
Yep, that how the old local open syntax extension worked
<hcarty>
everyonemines: This is mostly guessing, but I expect that a module would only be GC'd if it is created as a value or with let module Foo = ... in
2011-12-27
<adrien>
hcarty: oh, and this: sed -e '/include/ d' _tags > tags_0 && mv tags_0 _tags
<adrien>
hcarty: it's true the additional layer is not a requirement
<adrien>
hcarty: actually it depends whether automatic downloading of archives is wanted or not ;-)
<hcarty>
adrien: Just cuious... I think one of gildor's goals with oasis was automated package generation
<hcarty>
adrien: Why odb over oasis for this task?
<thelema>
hcarty: bah, I already have dirty-parsing of _oasis files for deps in 11 LOC
<hcarty>
thelema: Anything else - if there's a use for it, it could be used
<hcarty>
thelema: oasis - for proper parsing of _oasis files
<hcarty>
But someone would have to need it enough to write the code
<hcarty>
An odb-installable odb-heavy version could always be made which depends on oasis, yojson, and loads of other goodies.
<hcarty>
adrien: JSON is a bit more difficult to parse without library support :-)
<thelema>
hcarty: two plans: 1) dirty parse _oasis file, 2) change packages format to allow "deps=foo,bar,baz" inline
<hcarty>
thelema: Do you have a plan for how you will implement dependency support? Maybe something manual, like a CSV list of findlib dependencies at the end of the definition
<hcarty>
adrien: I look forward to it :-)
<adrien>
hcarty: it will be on git quite soon
<hcarty>
adrien: Can you post the _oasis somewhere as an example?
<jamii>
hcarty: sorry, Int32.shift_left_logical is what I need
<hcarty>
jamii: lsl I think
<hcarty>
vivanov: There are a number of other multi-process options, including Functory and preludeml which has some parallel map, iter and fold operations
<thelema>
hcarty: ignore
<thelema>
hcarty: ok, fair enough.
<hcarty>
It is a royal pain needing to have Array, BatArray, MyArray, etc. floating around.
<hcarty>
Prefixing is an easier hack to reason about though. So perhaps the hackishness is not truly equal.
<thelema>
hcarty: ok, fair enough.
<hcarty>
thelema: IMNSHO that's a roughly equally poor hack :-)
<thelema>
hcarty: prefixing.
<hcarty>
thelema: It's a poor hack with no good alternative at this point
<hcarty>
There was error checking before... just not reporting when one came up
<hcarty>
:-)
<thelema>
hcarty: yes, that's something we should have to do, push the oasis-db changes upstream
<hcarty>
thelema: ocamlbrew now reports errors when they occur and directs the user to check out the log file for more information on the failure
2011-12-26
<hcarty>
Given that Jane St. is involved with lacaml it may switch over to oasis fully upstream
<hcarty>
I just uploaded and tested lacaml with a basic _oasis wrapper to oasis-db. It works here, so that's one more library down.
<hcarty>
thelema: That sounds reasonable. At the package, findlib, and module level?
<hcarty>
I don't know how much the upstream version is used or updated at this point, but it does have some nice modules (Umatrix for 2D arrays; Its Arg-like module(s) look handy)
<hcarty>
thelema: If that's not going to cause other problems, then the name change would be nice. However, given that Ulib in Batteries was actually officially announced while I don't think Ulib the OCaml CVS stdlib extension ever was, I don't mind changing the library name.
<hcarty>
They do conflict
<hcarty>
thelema: I'll try uploading Ulib as Ulib to odb and test it against Batteries 2.0beta2