The Batteries Included project has come under new management since David Teller moved on. The project has gone through a process of reorganization and is finally ready for a release. We've rethought a lot of the structure decisions of the old codebase to make it easier to use and develop.
Major changes: * Builds in 10 seconds, plus 10 seconds for documentation (on my system) * Depends only on Camomile and Findlib * Syntax Extensions now optional * Less magic in build system * Allows smaller executable creation
We're using OMake instead of ocamlbuild and a much more stock ocamldoc for documentation generation. All the modules we provide are standard modules, no [module Array = struct include Array ... end] magic except in batteries.ml which ties everything together for convenience. Of course there's a bunch of bug fixes and additional functions.
We're using Semantic Versioning (http://semver.org/) for version numbers, meaning we're taking backwards compatibility very seriously. This is our 1.0.0 release, but we don't expect to stay at it very long. We're looking forward to fixing any bugs you find.
> The Batteries Included project has > come under new management since David Teller moved on. The > project has gone through a process of reorganization and is > finally ready for a release. We've rethought a lot of the > structure decisions of the old codebase to make it easier to > use and develop.
A big thanks to you and the entire Batteries team is definitely in order! I do have a couple of questions/suggestions:
- What is the relation between the development of ExtLib and AAA Batteries? A first glance at the AAA Batteries API suggests it to be a superset of ExtLib's. If both development teams are on board, I would suggest an explicit deprecation of ExtLib in favour of AAA Batteries.
On Sun, Jan 17, 2010 at 08:13:52AM -0800, Dario Teixeira wrote: > A big thanks to you and the entire Batteries team is definitely in order!
FWIW, the merits of this release are almost entirely Edgar's, he took up the whole refactoring work from the previous Batteries design on his shoulders.
> - Is AAA Batteries definitely the new Batteries?
Yes, this has been discussed extensively on the batteries-devel archive. That's why this release is called "Batteries Included 1.0.0" and not "AAA batteries" as initially thought.
On this, I also have a very brief public service announcement: the Debian package ocaml-batteries-included will, obviously, migrate to this 1.0.0 release. If any of the readers has good reason to want to keep both this and the old-style Batteries please mail me, but note that the old code is currently unmaintained, so I'd support that at worst for a single release cycle (so you better be convincing).
Cheers.
-- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c' ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...........| ..: |.... Je dis tu tous ceux que j'aime
> - What is the relation between the development of ExtLib and AAA Batteries? > A first glance at the AAA Batteries API suggests it to be a superset of > ExtLib's. If both development teams are on board, I would suggest an > explicit deprecation of ExtLib in favour of AAA Batteries.
This is up to the ExtLib team - our intention is to do much more than ExtLib.
> - Please provide also a GODI package.
This is high on the list of TODO, if anyone can help, in theory it should be easy. But I'm not a GODI user, so it's hard for me.
> FWIW, the merits of this release are almost entirely Edgar's, he took up > the whole refactoring work from the previous Batteries design on his > shoulders.
Mauricio Fern ndez helped in fundamental ways to make this release what it is. It would be much less featureful if it weren't for him.
> On 01/17/2010 11:13 AM, Dario Teixeira wrote: >> - What is the relation between the development of ExtLib and AAA >> Batteries? >> A first glance at the AAA Batteries API suggests it to be a >> superset of >> ExtLib's. If both development teams are on board, I would suggest an >> explicit deprecation of ExtLib in favour of AAA Batteries.
> This is up to the ExtLib team - our intention is to do much more than
You're welcome ;) ExtLib was designed from the start to do "a little".
On Tue, Jan 19, 2010 at 12:06:53PM +0100, Nicolas Cannasse wrote: > >> ExtLib's. If both development teams are on board, I would suggest an > >> explicit deprecation of ExtLib in favour of AAA Batteries. > >This is up to the ExtLib team - our intention is to do much more > >than > You're welcome ;) ExtLib was designed from the start to do "a little". > Good luck with "Batteries"
So, just to be crystal clear (which in this cases is essential), can we consider this as a statement that ExtLib will stop its development here seeing Batteries as its own successor? Or is it something else?
I know that de facto, large ExtLib development has stopped a while ago, but having a statement such the above will terribly help the community of programmers in orienting their choices and understanding the panorama of available extended libraries. It would also help distributions to decide where to put their packaging efforts (hint hint :-)).
If it is indeed the case that you intend to "pass the baton" to Batteries, it would be nice to have such a notice on the ExtLib project page at http://code.google.com/p/ocaml-extlib/ .
Thanks for your feedback, Cheers.
-- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c' ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...........| ..: |.... Je dis tu tous ceux que j'aime
Thank you for your work on batteries. Here are a few comments that I have, having "migrated" my source code to this new version.
First, I appreciate the reduction of dependencies. This makes it much more reasonable to share code using batteries.
On the negative side, my greatest concern is about outdated documentation : I found it very difficult to know what had changed, and how to adapt my code. These changes range from the deletion of some features (batteries/ocaml* tools, myocamlbuild.ml, "open in" syntax extension, implicit "open Batteries") to minor API changes (naming of Standard, Data, Shell modules, no more Different_list_size exception, no more Queue.enum...). Also, there seems to be a packaging bug which requires using -thread in the ocamlfind command.
So, I spent a significant time replacing my old 1-line ocamlbuild command by a real Makefile (also because of a strange and probably unrelated linking bug which I still don't fully understand). I believe that an updated compiling howto is really needed, as well as a list of the main deleted features with respect to the last release, allowing users to estimate how much change their code will need.
Other than that, I have not found any regression or other problems in this new release of the library, and I'm looking forward to see its further development.
> The Batteries Included project has come under new management since > David Teller moved on. The project has gone through a process of > reorganization and is finally ready for a release. We've rethought a > lot of the structure decisions of the old codebase to make it easier > to use and develop.
> Major changes: > * Builds in 10 seconds, plus 10 seconds for documentation (on my system) > * Depends only on Camomile and Findlib > * Syntax Extensions now optional > * Less magic in build system > * Allows smaller executable creation
> We're using OMake instead of ocamlbuild and a much more stock ocamldoc > for documentation generation. All the modules we provide are standard > modules, no [module Array = struct include Array ... end] magic except > in batteries.ml which ties everything together for convenience. Of > course there's a bunch of bug fixes and additional functions.
> We're using Semantic Versioning (http://semver.org/) for version > numbers, meaning we're taking backwards compatibility very seriously. > This is our 1.0.0 release, but we don't expect to stay at it very > long. We're looking forward to fixing any bugs you find.
> Thank you for your work on batteries. Here are a few comments that I > have, having "migrated" my source code to this new version.
I appreciate your taking the time to give feedback.
> First, I appreciate the reduction of dependencies. This makes it much > more reasonable to share code using batteries.
Thank you. > On the negative side, my greatest concern is about outdated > documentation : I found it very difficult to know what had changed, and > how to adapt my code. These changes range from the deletion of some > features
I'm glad you were able to wade through the new codebase and adapt.
> (batteries/ocaml* tools, myocamlbuild.ml, "open in" syntax > extension, implicit "open Batteries") to minor API changes
I'm not convinced that the batteries/ocaml* tools were useful - can people weigh in on this?
Ocamlbuild should have a global directory for packages to install their own tag extensions, allowing most users to omit myocamlbuild.ml files from their directory.
"Open in" should be replaced soon in ocaml proper, implicit "open batteries" seems a bad idea IMHO.
> (naming of > Standard, Data, Shell modules,
Intentional - flattened structure
> no more Different_list_size exception,
Intentional - too many exceptions.
> no more Queue.enum...).
Should be fixed now, a point release should come out within the week.
> Also, there seems to be a packaging bug which > requires using -thread in the ocamlfind command.
Needs fixing. Added to issues tracker.
> So, I spent a significant time replacing my old 1-line ocamlbuild > command by a real Makefile (also because of a strange and probably > unrelated linking bug which I still don't fully understand). I believe > that an updated compiling howto is really needed, as well as a list of > the main deleted features with respect to the last release, allowing > users to estimate how much change their code will need.
I still use ocamlbuild with the old myocamlbuild.ml to compile my projects.
<*>: pkg_batteries, thread
is the main line in my _tags file I need.
Would it help to use a wiki to keep track of these things? All my code is already adapted to the new system, so I don't find regressions anymore to record.
> Other than that, I have not found any regression or other problems in > this new release of the library, and I'm looking forward to see its > further development.
> Tiphaine
I'm happy to push this forward, and there's a lot of good to add. Patches welcome.
