OCaml-bitcoin 1.0

OCaml-bitcoin is a library offering an OCaml interface to the official
Bitcoin client API. It works by making JSON-RPC calls over the network
to a running Bitcoin daemon offering the client API. The project's
homepage can be found here:
http://ocaml-bitcoin.forge.ocamlcore.org/
Bitcoin has been a controversial subject, to say the least. With this
in mind, I've written a blog post that hopefully clarifies my view on
the subject. It also contains some technical information concerning
the implementation of OCaml-bitcoin:
http://nleyten.com/post/2012/10/24/Announcing-OCaml-bitcoin-1.0
To summarise: the release of this library should not be construed as
an unconditional support of Bitcoin in its current form. There is
enough potential in the idea, however, to warrant some guarded
support.

Bolt 1.4 release

This post announces the 1.4 release of the Bolt project, whose goal is
to provide a comprehensive yet flexible logging framework for the
OCaml language.
Home page: http://bolt.x9c.fr
Main changes since 1.3:
- API change: introduction of modes, allowing to choose when data is written
- API change: updated support for Pajé format (version 1.2.3)
- support for '&&' and '||' in filters (new configuration format only)
- new 'minimal' layout using only message
- new 'bell' output writing the bell character on the standard output
- new 'say' output using MacOS X text-to-speech
- support for Growl under Windows
- bug#86: '-ocaml-prefix' doesn't really work
- bug#87: install shouldn't build anything
- bug#89: do not activate warnings by default
- bug#105: crashes with 'Not_found' when both BOLT_FILE and BOLT_CONFIG are not set
- bug#107: when using syntax extension with level NONE, preprocessed code

opam and versions

> For our purposes, we need to be able to ensure that our builds are
> reproducible, and hence need to know exactly which versions are installed.
> We had hoped to achieve this by removing or disabling packages whose
> sources were got directly from a master branch in github. However, it turns
> out that some packages that are 'stable' are dependent upon these packages,
> which seems brittle. The question is how to fix it? Should the opam
> repository maintainers require that 'stable' packages aren't dependent on
> 'unstable' ones? Should opam itself be aware of the difference and enforce
> this policy? If someone really wants to release a stable version of their
> thing and it's dependent upon an upstream project with only a github repo,
> should the developer engage the upstream devs and request at least a tag,
> or should they make their own tarball/github fork?
Before the 1.0 release my plan is:
* to remove the unstable packages in the main opam-repository (ie. every
packages should have a stable tarball with a fixed checksum) [1]
* add a way to specify commits/branches for unstable packages if needed. [2]
The current workaround is, as Anil pointed out, to clone opam-repository, use
'opam-mk-repo' at its root to generate a local mirror of opam.ocamlpro.com,
and tell opam to add the local repository as a remote: 'opam remote -add
local /path/to/your/local/repository'
Then 'opam remote -list' should display the list of repositories and their
respective priority (higher is better). You can also tweak ~/.opam/repo/index
manually to tell opam to use your local repository only for some packages,
for instance the unstable ones (don't forget to run 'opam update' after
changing the index file).
For [1], I'm gladly accepting external contributions (for [2] as well
actually if someone really wants to hack into opam).
--
Thomas
[1] https://github.com/OCamlPro/opam-repository/issues/171
[2] https://github.com/OCamlPro/opam/issues/267