ttamttam has quit [Remote host closed the connection]
Cyanure has joined #ocaml
vouillon has quit [Read error: Operation timed out]
vouillon has joined #ocaml
ymasory has joined #ocaml
Yoric has joined #ocaml
<hcarty>
thelema: I should be able to use odb with a hand-compiled OCaml, ocamlfind and nothing else from OCaml-land, correct?
<thelema>
hcarty: I think so.
<thelema>
the only ocaml libraries it uses are Str and Unix
eaburns has left #ocaml []
<hcarty>
I'm hoping to get a chance to test it later... which also makes it easier to test oasis, since oasis isn't packaged for GODI yet.
<hcarty>
thelema: Are binaries, documentation, etc. installed in ~/.odb?
<thelema>
yes, one thing it does is build oasis well. I tried adding some more libraries to the server, and neither went well.
<thelema>
hcarty: the issue of where things get installed depends on the package itself. If not installing as root, (which is currently always the case), "--prefix $odb_home" is added to the configure command
boscop_ has joined #ocaml
<thelema>
this usually makes everything get installed in ~/.odb, but some packages could break this
boscop has quit [Ping timeout: 246 seconds]
<thelema>
make doc isn't executed, so for most packages, documentation isn't built or installed.
<thelema>
it wouldn't be hard to add this
<hcarty>
thelema: Ok, that's all good to know. I want to make sure I have an idea of what to expect before I start trying it out.
<thelema>
let me know how it goes -- any errors.
<hcarty>
I certainly will
<hcarty>
If I start making packages I'll submit them too
<thelema>
great.
<gildor>
hcarty, thelema: I hope that creating package for odb will mostly be a matter of writing an _oasis file (and compiling it with "oasis setup")
<gildor>
is this what you have in mind ?
<hcarty>
gildor: Probably mimicing the existing packages which are available for odb at first, but then yes - I hope/plan to get some packages oasis-ified
<hcarty>
gildor: odb is an easy way to get access to oasis in the near-term
<thelema>
gildor: you mean re-creating the build systems of every odb-enabled package to conform to oasis? If that were a requirement for being in odb, oasis itself wouldn't be compilable with odb.
<hcarty>
s/mimicing/mimicking/
<gildor>
hcarty: a better plan would be to have it in GODI, if you use GODI ?
<gildor>
hcarty: to have oasis in GODI
<hcarty>
gildor: Yes, although odb's packaging is much simpler. GODI is nice, but the process for creating packages is rather involved.
<gildor>
hcarty: yep, I agree
<hcarty>
gildor: Unless oasis-db eventually provides a replacement for GODI (with the exception of building OCaml itself) I think GODI will continue to be an important part of the OCaml community
<gildor>
(and one of my goal is to have a bridge to GODI through GODIVA, which shares a lot with _oasis)
<gildor>
gildor: and we should keep it this way
philtor has quit [Ping timeout: 246 seconds]
<gildor>
I do think GODI is important
* adrien
uses godi
Snark has quit [Quit: Ex-Chat]
<gildor>
thelema: I mean that since odb is undertitled "Oasis-db experiments", it is not a mad prerequisites to have every package in it use _oasis
<gildor>
thelema: or at least a setup.ml that implements --configure/--build/--install
<gildor>
thelema: and oasis itself uses a setup.ml that conforms to his own requirement
<thelema>
gildor: that sounds good in theory, but makes it almost certain that few packages will be odb-installable
agarwal1975 has joined #ocaml
<gildor>
thelema: you need in a way or another to allow upstream author to provide a standard path to install
<thelema>
it'd be an interesting crusade for me to take on to oasis-ify tons of packages, but...
<gildor>
thelema: I mean that is the point of any CPAN like structure
korya has joined #ocaml
<gildor>
(be it CPAN or hackage)
<gildor>
and a meta data provider (author, upload links)
<hcarty>
Doesn't CPAN require a standard "configure && make && make test && make install"-like process from its packages?
<thelema>
well, for most packages, setting OCAMLFIND's DESTDIR on make install suffices
<gildor>
hcarty: that what I call a standard path
<hcarty>
It wouldn't be too outlandish to require something similar for odb/oasis-db/etc.
<gildor>
hcarty: and it uses MakeMaker + .yaml file
* thelema
is fine supporting oasis, omake and make (w/ and w/o configure)
Pepe_ has quit [Quit: leaving]
Pepe_ has joined #ocaml
<gildor>
omake/make doesn't provide a standard
<thelema>
as long as they support --prefix and/or DESTDIR
<gildor>
path
<gildor>
so you need also at least autoconf
<thelema>
no, batteries doesn't use autoconf, and it odb-installs fine
<gildor>
and you need to find a way to auto-describe dependencies
<thelema>
same with camomile
<gildor>
thelema: for now you generate your file by hand
<thelema>
and auto-describing dependencies is nice, but not critical
<thelema>
dependencies don't change much
<gildor>
thelema: you will end up doing the same job as GODI/Debian/Fedora people do
<gildor>
to describe deps
<gildor>
thelema: not very efficient
ulfdoz has joined #ocaml
<thelema>
the harder part is detecting whether a package is installed. for example ocaml-expect installs a binary, batteries a library, and oasis both
<hcarty>
gildor: Isn't that required for any system like this though? OCaml doesn't have a good automated "here is the source, what dependencies do I need?"
<hcarty>
Go is the only language I've read about which has something like that.
<thelema>
hcarty: ocaml doesn't even have a way to put magic comments (or require/use declarations) to make this happen
<gildor>
hcarty: oasis use findlib name and it works pretty well
<gildor>
hcarty: I have smthg like 5 Debian packages almost auto-generated using _oasis and its deps
<gildor>
(and findlib)
<gildor>
works pretty well
<hcarty>
gildor: Where do the deps come from?
<gildor>
from _oasis
<thelema>
gildor: auto-extracting dependencies from _oasis files sounds good, but I bet <1% of oaml programs and libraries have an oasis file, so the deps will have to be specified somehow
<gildor>
BuildDepends: expect (>= 0.0.2)
<hcarty>
gildor: I suppose META files could be used when a package isn't using oasis
<gildor>
thelema: chicken and egg problem, you won't find a common scheme in all package for now
<gildor>
(that is the debian packager that have create more than 80 packages talkink)
<thelema>
correctly dealing with dependencies requires an 'installed-packages' database. even _oasis doesn't provide a way to tell what version an installed ocaml-expect is
<gildor>
META are unreliable because they are not used at compile time
<gildor>
installed-package = ocamlfind list
<thelema>
s/ocaml-expect/ocamlify/
<gildor>
i.e. you write a META file for end-user when you are upstream and almost never tested it when you release it
<gildor>
binary/library -> it is described through Library/Executable section in _oasis
<thelema>
gildor: installed ocamlify doesn't have an _oasis file
<gildor>
thelema: agreed on the missing version number for ocamlify
<gildor>
thelema: no solution so far
<thelema>
I'd probably be happy enough putting the commands to configure/build/install a package into the odb-info file, and leaving it entirely up to the "packager"
<gildor>
thelema: that is the point of _oasis
<gildor>
thelema: you write one with custom plugin, and you probably see that it was all about XCustomBuild: make
<thelema>
I still can't convince myself to use _oasis files as info files.
<gildor>
XCustomInstall: make install
<gildor>
thelema: it is parseable and contains enough field for what you want, moreover you can use to create your own build system
<gildor>
thelema: and set your deps here and use it while building (as upstream)
<gildor>
thelema: what is missing ?
<thelema>
parseable schmarsable. I've seen the results of the oasis parser, giving parse errors when a plugin isn't available.
<thelema>
Unless I'm quite wrong about the complexity of the _oasis parser library, I'd rather use XML
<gildor>
thelema: do you use "ignore_plugin = true" when parsing ?
<gildor>
you compare parsing _oasis with the complexity of an XML library ????
<thelema>
no, I've not touched the api for the parser, I've just seen some errors it gave when I was trying to build batteries' _oasis
<thelema>
and I infer that it's doing way too complex parsing for me to embed it it odb.ml
<gildor>
thelema: you put a non-existing plugin in the wrong field and it gives you an error... it is not like a real error
<thelema>
I admit that I like _oasis syntax better than XML, but they're both far from optimal.
* gildor
just stop talking, I don't see any way to convince thelema
<thelema>
or if I give a field name that isn't expected, it gives an error. meaning it's keeping track of allowed field names...
<gildor>
thelema: good luck with recreating something totally different to oasis
<thelema>
which is on the level of xml with a dtd
<gildor>
and better
<thelema>
gildor: no, I'm not trying to make something better, I'm trying to make something worse.
gildor has left #ocaml []
<hcarty>
gildor: _oasis and odb address a similar problem, but from different points in the toolchain. odb is something which could be used to bootstrap an oasis install, for example.
<thelema>
well, I didn't expect him to leave in frustration quite yet.
<thelema>
otoh, I was starting to get tired of him trying to remake odb into oasis-db
<hcarty>
It's probably a little frustrating to see an independent project pop up which is, at least on the surface, so similar
<thelema>
hcarty: oasis is well designed to not need bootstrapping - the setup.ml files it creates are independent of the oasis binary
<hcarty>
I do think the two can coexist quite nicely though, and converge if needed.
<hcarty>
thelema: But can the same be said for oasis-db?
<hcarty>
thelema: Or oasis the toolchain?
<thelema>
hcarty: well, gildor suggests that binary distribution solves the oasis-db distribution problem
<thelema>
and he produces binary distributions of the oasis setup.ml-generator for the reason that oasis-db isn't ready yet
gildor has joined #ocaml
<thelema>
gildor: my apologies for being so stubborn - I think we have different visions of oasis-db and odb.
<gildor>
thelema: thx for apologies
<thelema>
Not to be too abrasive, I fear you're building a 2.0 system with the current design for oasis (and oasis-db).
<gildor>
thelema: not sure to understand
<gildor>
thelema: you mean a system too complex ?
<thelema>
This refers to a story I heard a long time ago - when a bunch of people build a computer program, they first build this patchy, kludgy system that works, but is held together with tape and twine, a 1.0 system.
<gildor>
and the second, designa a perfect system, but never get it to work ?
<thelema>
It outgrows its design constraints, so its designers, having learned how to *really* build that application start from scratch, using the highest level design principles, with infinite flexibility and ability to handle cases noone will ever need, a 2.0 system
<thelema>
This system is buggy and slow and is missing some of the things the 1.0 system did, but is completely customizable to the nth degree.
<gildor>
thelema: today oasis (not oasis-db) is already there and working for some apps
<gildor>
thelema: I mean I am able to make it works for most of my app
<thelema>
The designers learn from their mistakes of building a 2.0 system, and plan a 3.0 system, but this is never built, as the team is dissolved and put to work on other projects
<gildor>
(e.g. ocsigen-bundler, that I just release)
<gildor>
thelema: you don't see my point, I don't try to convince you to wait oasis-db, I am trying you to convince using _oasis, so that everything you do will profit to oasis directly and on the long term to oasis-db
<gildor>
thelema: go on with odb and make it works, that is perfect for me (though I will to concur with oasis-db)
<thelema>
so yes, complex, but not just that. There's a 2.0 syndrome that I imagine you can identify in many projects - usually around the point that a programming language is embedded in the system and it becomes turing complete.
<gildor>
thelema: but don't try to design a 3.0 version _oasis
<thelema>
I understand you want my efforts to help you with the oasis project, but fear that I'll be dragged into the 2.0 syndrome
<thelema>
You misunderstand my intentions, I want to build a 1.0_ oasis
<adrien>
another thing you can do is to design the 2.0 system but only have a fourth or so of the features
<thelema>
To a large extent, one has to progress through the stages, and I've not the packaging experience you do to skip version 1.0
<gildor>
thelema: but if oasis is working now, what the point of inventing something else ?
<thelema>
adrien: yup.
<gildor>
I don't have that much of experience, but it is here and you can either choose to help me or decide to go another way
tauntaun has quit [Quit: Ex-Chat]
<thelema>
gildor: if you're fine with me converting _oasis files into odb-info files, what's the problem with me creating them by hand (for now)?
<thelema>
gildor: I hope this isn't a "with you or against you" thing.
<gildor>
thelema: as long as you use _oasis file (just as you have done with batteries AFAIK) it is perfect for me
<thelema>
gildor: server support for _oasis files will come in odb 2.0
<gildor>
with you or against you -> no, I am not this kind of guy, but it would help me (and maybe the community) to have a point of convergence for this
<hcarty>
gildor, thelema: As an outsider, I think both projects and approaches are very important
<hcarty>
oasis gives a build system to test Right Now
<hcarty>
odb gives a lightweight CPAN-like tool Right Now
<hcarty>
The two can continue to develop and experiment with different approaches.
<gildor>
hcarty: this exactly that
<gildor>
hcarty: I am just trying to convince thelema to base its system on _oasis to enhance the cooperation
<gildor>
so that we can benefit from the progress of each other
<thelema>
the frontend will support _oasis, but I see no reason to un-support other install modes
<hcarty>
Creating a package for odb for any one of ~80% of the OCaml packages out there would probably take 1-5 minutes. Converting that package to _oasis may take longer and require some upstream interaction.
<gildor>
thelema: you can formet the backend to read _oasis file
<gildor>
hcarty: my problem is that, I don't want yet another packaging system
Cyanure has quit [Remote host closed the connection]
<thelema>
gildor: I'm doing my best to leverage findlib as much as possible.
<hcarty>
If oasis becomes an informal standard like findlib has, then the two will converge.
<gildor>
hcarty: and the difference is that if you set an _oasis, upstream author can use it for its own build system
<gildor>
thelema: oasis already use a lot findlib
<gildor>
hcarty, thelema: and if we work together around 1 format file, we will hopefully make it converges faster
<hcarty>
gildor: I agree, and I think that's probably the right mid to long term plan. But odb is REALLY simple as it is, and it works now. That's good because it makes it easier to try oasis for someone using GODI (for example).
<thelema>
gildor: I *could* send patches to each upstream project to enable oasis in their project. Maybe once I have a tarball upload that auto-extracts the deps and makes the odb-info file, authors will be better encouraged to use _oasis
<gildor>
at least it paves the way to make my own odb system using oasis-db as a backend ;-)
<hcarty>
gildor: Given what I've seen of oasis and from what thelema has said, I expect that to be what happens enventually :-)
<thelema>
gildor: you're trying to make me work against my innate virtue of laziness, quit that! ;-)
<gildor>
hcarty: you know that they are still people around thinking hard that findlib is a bad thing (TM)
<hcarty>
gildor: I do, and I think that's very unfortunate.
<thelema>
findlib *is* kinda complex. Maybe necessarily so for what it attempts to accomplish. But still more complex than -I +pkg
<gildor>
there are too many people against systems they don't have designed
<gildor>
and I am always saddened when I see that
<thelema>
that's not quite it - they're happy to use [make], even though they didn't design that.
<gildor>
but even if they use make they won't use OCamlMakefile
<thelema>
gildor: true.
<hcarty>
On the other hand, trying to create your own system can be healthy - either it fails and they transition to the standard (ex. findlib) or they succeed and create the new standard system.
<gildor>
and when you are a packager, it is hell
<thelema>
but I won't use OCamlMakefile either (anymore)
<thelema>
hcarty: without a cpan-like system to bring the community together, everyone can have their own standard
<gildor>
or they convince themselves that this is because other people are d...b and decide to continue in their own path (eventually creating a new language)
<gildor>
thelema: and what if we make a pact
<hcarty>
thelema: Which is why I think odb and oasis+oasis-db and Batteries are so important :-)
<gildor>
thelema: I provide you with the deps you need in oasis-db
<hcarty>
Maybe s/I think/I agree/ is a better way to put that.
<gildor>
thelema: before the end of the week
<gildor>
thelema: you tell me what you need
<thelema>
gildor: a cpan system is more important than a stdlib. don't put batteries in the same league as odb.
<thelema>
s/odb/odb and oasis-db/
<gildor>
thelema: so any package uploaded in oasis-db will be downlodable by odb
<gildor>
i.e. i do the backend, you do the frontend
<thelema>
I'm not quite convinced about the role that oasis provides, but admit that it's important in automating package upload into the -db system
<gildor>
and maybe one day will reintgrate
<hcarty>
thelema: That was me - don't assign my mistakes to gildor :-)
<gildor>
thelema: you can upload non oasis tarball in oasis-db BTW
<thelema>
hcarty: oops
<thelema>
gildor: my apologies for attributing that mistake to you :)
<gildor>
thelema: what about my proposition ?
<thelema>
gildor: Your proposition sounds good. I have a simple idea for a backend that I'd like to try first before leaving that in your hands.
<gildor>
thelema: we can work incrementally, send me a first description of your odb-info + examples and I will try to get it up and running on oasis.ocamlcore.org/dev/ before the end of the week
<thelema>
The requirements that odb has of the backend are: 1) get_info (get metadata about the package, specifically: deps, tarball name, whether it's a library, program or both, etc.) and 2) download a tarball
<gildor>
thelema: I have all this info at hand, just need to compile them in the right format
<thelema>
odb-info : ([^=\n]+=[^\n]+\n)*
<gildor>
easy to do
<thelema>
the one other trick I have in odb.ml is that it can get a directory listing of the info dir and clean it up to show a list of packages available
<gildor>
3 fields, is_library=true|false
<gildor>
is_program=true|false
<thelema>
tarball=batteries-1.3.0.tar.gz
<gildor>
deps=pkgname*,
<thelema>
the tarball field is removable - it just made my life easier putting that in the info
<gildor>
sound quite easy to generate
<thelema>
yes, it is. easy even by hand
<gildor>
I could probably be able to generate it before EOW
<thelema>
right now, the tarball has to be a valid tar.gz file, as I have hardcoded "tar -zxvf" - I've had to convert some .bz2 files to .gz
<gildor>
but if you download a tarball without _oasis file, how would you guess its deps and everything else ?
<thelema>
(another idea for github integration - just update the server each commit)
<hcarty>
Another feature request, possibly for oasis over odb/oasis-db -- It would be nice to be able to specify a custom findlib name. This would allow batteries and batteries-head to be installed simultaneously.
<thelema>
gildor: maybe I could hack in enough support for oasis to get deps
<gildor>
thelema: or you can send a kind of ping to an URL on oasis.ocamlcore.org that notify that a new commit exists
<thelema>
gildor: that's what the post-receive-hooks do automatically
<gildor>
and have a ~head revision containing this
<hcarty>
Before I submit the request - do you think that would be more appropriate for odb or oasis?
<thelema>
hcarty: custom findlib names seems like a bad idea for dependencies
<gildor>
thelema: there is no easy way to hook the name of the library installed
<thelema>
hcarty: the build system (oasis, make, omake) would have to support it
<hcarty>
thelema: Without version support in findlib, I'm not sure how else to have testing + "real" versions available.
<thelema>
hcarty: so that's a request for findlib, then
<gildor>
whereas it is a simple "^!extension" for oasis
<hcarty>
thelema: Fair enough
<gildor>
if it uses the internal install system
<thelema>
gildor: only because oasis knows the library name beforehand. It'd be straightforward to diff the list of ocamlfind packages pre and post install to find what was just added.
<gildor>
hcarty: you can submit a bug to oasis, if you want
<gildor>
thelema: of course, you can move around library directory, not a big deal either
smerz has joined #ocaml
<gildor>
thelema: I will do a whole bunch of github synchro stuff (including planet.o.o stuff and synchronization of tarballs between the two)
<gildor>
thelema: and also with oasis-db
<gildor>
thelema: I acknowledge the fact that there are many users of github
<thelema>
gildor: put the github fun stuff lower on your todo list than "make it work"
<gildor>
thelema: my fight for more project on the OCaml Forge has to go through a better github integration
<thelema>
the github users are more likely to adopt _oasis, as they're not entrenched in a very old way of organizing their projects
<gildor>
thelema: you'll get your working odb repo by the end of the week, and you will help me make it works
<gildor>
;-)
* gildor
time for dinner
<gildor>
see you
<thelema>
cheers
vivanov has quit [Quit: Lost terminal]
<thelema>
grr, if odb.ml handles versions, it might have to recommend installing a newer version of a library
<thelema>
but everything that depends on the older version would have to be recompiled
<thelema>
how to deal with this...
avsm has joined #ocaml
<thelema>
avsm: how to get dependencies from github projects?
boscop_ is now known as boscop
<avsm>
the same as any other package… OASIS i guess?
<hcarty>
thelema: A relatively simple hack would be to redownload rebuild all packages which depend on the upgraded package
<hcarty>
redownload AND rebuild
<thelema>
hcarty: how to find that out?
<hcarty>
thelema: findlib's libraries probably
<thelema>
avsm: can one github package depend on another github package?
* thelema
checks if findlib can do that
<thelema>
although findlib wouldn't know about any binaries that depend on the package
<avsm>
this can't be a github-only thing. usually, the underlying packaging system (gem or cpan or whatever) appends a -dev "epoch" to indicate its a development version, but uses the rest of the information from the metadata file (like OASIS or setup.py)
<avsm>
isnt this what Oasis is for?
<thelema>
avsm: I'm just seeing if gem could work entirely off github (no other package server)
<hcarty>
thelema: No, binaries wouldn't be covered by findlib. I think GODI handles this by downloading all available package metadata and basing checks on that.
<thelema>
yes, _oasis contains dependencies, but I'm thinking it'd need special syntax to depend on a github package, unless that github package was already indexed on the package server
<thelema>
hcarty: blah
<thelema>
well, I'm happy with 80% for now - binaries will have to be reinstalled
<avsm>
i suggest doing what homebrew does, it's incredibly simple and effective
<hcarty>
thelema: The other option is scan every findlib package to see if it depends on the package being updated
<avsm>
just have a single github repo with all the packaging data in one place, and if someone wants to modify it, they clone it, add theirs, and send a pull request.
<hcarty>
thelema: You could require META files for binaries...
<hcarty>
thelema: Then the binaries would be caught along with libraries.
<thelema>
avsm: lol - that would be one solution...
<thelema>
hcarty: that might not be a bad solution - having *everything* findlib-enabled
<thelema>
I'm trying my best to avoid keeping another findlib-like database
faanbj has quit [Ping timeout: 260 seconds]
<hcarty>
thelema: Probably a good idea. findlib does a lot on its own.
<thelema>
working on odb as root - no ~/.odb folder needed
<thelema>
also, no need to add to PATH and OCAMLPATH. Downside: well, you're downloading code from the internet to run as root.
<hcarty>
And it requires root, which is a downside on machines maintained by others.
<thelema>
true. It'll be a secondary mode, but useful for lazy people like me who would blindly make && sudo make install anyway
<gildor>
thelema, hcarty: binary deps ?
<thelema>
gildor: like ocamlify
<gildor>
thelema, hcarty: I know the solution
<gildor>
use ocamlobjinfo on the generated exec (bytecode)
<thelema>
gildor: lol
<thelema>
the problem is when a package is upgraded from one version to another (as might be required by another package), finding everything compiled against the first package to recompile
<gildor>
thelema: use ocamlobjinfo on *.cma and finds missing imported interfaces
<thelema>
for libraries, the assumption of ocamlfind solves this already, I think. (still need to check)
<gildor>
(or mismatch if you consider module name/sig separately)
<thelema>
but for programs (like ocamlify), there's still a problem
<gildor>
thelema: nope, because a new build can generate a new interface checksum
<gildor>
ocamlify is a bytecode program, so the ocamlibjinfo trick works
<thelema>
assuming ocamlfind, we can query it to get a list of dependent packages
<thelema>
I'm not going to ocamlobjinfo /usr/bin/*
<thelema>
and I'd kind of like odb to be able to install mldonkey
<thelema>
(not that there's a lot of deps needed there)
<gildor>
but there is no real deps on exec, because libraries are embedded in it
<thelema>
ah, good point.
<thelema>
yay static linking.
<gildor>
you can basically live without recompiling them (this is just to check that it still work)
<thelema>
any limitations on package names in oasis?
<hcarty>
gildor: That's a good point. Binary rebuilding could be on-demand for odb's 80% solution.
<thelema>
I'm currently favoring [-a-zA-Z0-9]+
<gildor>
thelema: i think package name is "string_not_empty"
alexyk has quit [Quit: alexyk]
<thelema>
gildor: I'll want some restrictions on this to eliminate people putting commands in their package names
<thelema>
not that this is the worst attack on odb, but it's something I'm edgy about. I don't like Sys.command's interface
<gildor>
thelema: open a bug on that, I'll think it is doable in the next version
<thelema>
done
sepp2k has quit [Quit: Leaving.]
<mrvn>
thelema: _?
<mrvn>
or gärstenbrot? (äüöß)
<thelema>
mrvn: supporting both _ and - is a good way for them to get mixed up
edwin has quit [Remote host closed the connection]
<thelema>
and i18n is definitely not in the important 80%
<hcarty>
thelema: . is the only other character I see on my system's "ocamlfind list" and I think that's only used for sub-packages
<thelema>
some ocamlp4/5 subpackages in my list use _ (including batteries :()
<thelema>
but as long as they're not packages, I think I can deal with it.
<thelema>
grr, just parsing version numbers is annoying
<gildor>
thelema: there is OASISVersion that can help you parse >= 0.3.0
<hcarty>
thelema: Would it be reasonable to use odb.ml-current as a bootstrap to grab batteries, oasis, whatever else is required to make handling everything else more easy?
<thelema>
hcarty: you mean have odb.ml download everything needed to run a full oasis-db? most of the problems in the full version can come up in the bootstrap code
<thelema>
so I don't think it'd simplify things much
ulfdoz has quit [Read error: Operation timed out]
* thelema
is complaining mostly for the sake of it
<thelema>
all my findlib packages have versions of the form [0-9]+(.[0-9]+)*
<hcarty>
thelema: That's what I was thinking, since odb.ml does that as it is
<thelema>
it's good thinking to have to do this from base libraries
<thelema>
I've taken lots of syntax from batteries already (|>, |-, tap)
alexyk has joined #ocaml
jonafan_ is now known as jonafan
lopex has quit [Ping timeout: 276 seconds]
Yoric has quit [Quit: Yoric]
lopex has joined #ocaml
ikaros has quit [Quit: Leave the magic to Houdini]
alexyk has quit [Read error: Connection reset by peer]
Oejet has quit [Ping timeout: 240 seconds]
Amorphous has quit [Ping timeout: 276 seconds]
lopex has quit []
ymasory has quit [Ping timeout: 250 seconds]
alexyk has joined #ocaml
Amorphous has joined #ocaml
boscop has quit [Ping timeout: 246 seconds]
dnolen has joined #ocaml
tauntaun has joined #ocaml
alexyk has quit [Read error: Connection reset by peer]
lopex has joined #ocaml
avsm has quit [Quit: Leaving.]
alexyk has joined #ocaml
alexyk has quit [Read error: Connection reset by peer]