[Caml-list] Batteries Included 1.0.0
Edgar Friendly
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.
To use:
Download:
https://forge.ocamlcore.org/frs/download.php/346/batteries-1.0.0.tar.gz
Documentation: http://thelema.github.com/batteries-included/hdoc
To contribute:
Mailing list:
https://lists.forge.ocamlcore.org/cgi-bin/listinfo/batteries-devel
Issue Tracker: http://github.com/thelema/batteries-included/issues
Code: git://github.com/thelema/batteries-included.git
[1] Like the small batteries used in TV remote controls
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Dario Teixeira
> 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.
- Is AAA Batteries definitely the new Batteries?
- Please provide also a GODI package.
Best regards,
Dario Teixeira
Stefano Zacchiroli
> 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
Edgar Friendly
> - 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.
>
>
ExtLib.
> - Please provide also a GODI package.
>
>
should be easy. But I'm not a GODI user, so it's hard for me.
E
Edgar Friendly
> 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.
>
it is. It would be much less featureful if it weren't for him.
E
Nicolas Cannasse
> 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".
Good luck with "Batteries"
Best,
Nicolas
Stefano Zacchiroli
> >> 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
_______________________________________________
Tiphaine Turpin
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.
Tiphaine
Edgar Friendly a �crit :
Edgar Friendly
> 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
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.
E.