<Ringo48>
is read_dir in that code still tail_recursive, or does the "with End_of_file -> ()" ruin it?
slash_ has quit [Client Quit]
<Ringo48>
nevermind, after further investigation it looks like the exception handler does ruin it
sbok has left #ocaml []
knightrage has joined #ocaml
<thelema>
Ringo48: yes, you have to catch the exception and wrap it with Some/None, and match
etoxam has quit [Read error: 110 (Connection timed out)]
jeddhaberstro has quit [Client Quit]
etoxam has joined #ocaml
tmaedaZ is now known as tmaeda
verte has joined #ocaml
<knightrage>
hey guys. so i'm new to ocaml/functional programming, but not new to programming. im trying to get the unique elements in a list. right now im thinking about using List.filter ... is that at least a good start?
<knightrage>
oh, i found a workaround. but i'd still be interested in knowing how to do that [for future knowledge]
<hcarty>
Some of those rules/compiler facts have changed, but from what I understand they are still mostly true.
ttamttam has joined #ocaml
tarbo2 has joined #ocaml
kaustuv_` has joined #ocaml
ttamttam has quit ["Leaving."]
<bluestorm>
hcarty: I'll come back this evening, and wish you good luck with the sprint until then
<bluestorm>
(do you have some place online where to push the scripts/packages ?)
kaustuv_ has quit [Read error: 110 (Connection timed out)]
julm_ has joined #ocaml
valross has joined #ocaml
knightrage has quit ["Leaving"]
tarbo2 has quit [Read error: 110 (Connection timed out)]
julm has quit [Read error: 110 (Connection timed out)]
f[x] has joined #ocaml
tarbo2 has joined #ocaml
ttamttam has joined #ocaml
valross has quit [Remote closed the connection]
blackdog has left #ocaml []
Tinos has joined #ocaml
Associat0r has joined #ocaml
f[x] has quit [Read error: 110 (Connection timed out)]
_zack has joined #ocaml
Snark has joined #ocaml
dmentre has joined #ocaml
patronus has quit ["Changing server"]
hkBst has joined #ocaml
pandamonial has joined #ocaml
_zack has quit ["Leaving."]
<sgnb>
flux: you might want to disable automatic installation of recommended packages on a server
<flux>
sgnb, I don't think I have that even enabled. wouldn't it be disbabled per defauilt?
<flux>
sgnb, I do believe they were indeed required libraries
<sgnb>
flux: it is enabled by default
<sgnb>
(I would say it's the difference between recommended and suggested)
<flux>
well, it isn't on that host
<flux>
for example apt-get install blender suggests yafray, but it isn't in the list of packages to be installed
<flux>
oh, hmm
<flux>
I guess that's only a 'suggested' package
<flux>
bad manual page for apt.conf, it doesn't mention either of the terms :)
<flux>
nor does apt_preferences mention them
<sgnb>
in aptitude, go to preferences and uncheck "Automatically install recommended packages"
<flux>
is that something that affect apt-get?
<sgnb>
I think
<sgnb>
to be sure,
<sgnb>
add « APT::Install-Recommends "false"; » somewhere in your apt.conf
<sgnb>
FYI, a basic Debian system (with Debian-related development tools) with libcairo-ocaml-dev without recommendations is 608M
<sgnb>
the /usr is 390M
<sgnb>
and without, it's 399M (/usr -> 189M)
<sgnb>
so libcairo-ocaml-dev and its dependencies (including ocaml, but not including libc) -> 209M (uncompressed)
<flux>
in any case, I don't mind if there's too much dev-stuff on that host
<flux>
it's a university computer club host anyway, people (..me) might want to compile various stuff there anyway ;)
<flux>
the root-disk still has 60G to go..
pandamonial has quit [Read error: 60 (Operation timed out)]
cedric___ has joined #ocaml
schme has quit [Remote closed the connection]
schme has joined #ocaml
_zack has joined #ocaml
tmaeda is now known as tmaedaZ
julm_ is now known as julm
caligula_ has joined #ocaml
tarbo2 has quit [hubbard.freenode.net irc.freenode.net]
caligula__ has quit [hubbard.freenode.net irc.freenode.net]
authentic has quit [hubbard.freenode.net irc.freenode.net]
Pepe__ has quit [hubbard.freenode.net irc.freenode.net]
xevz has quit [hubbard.freenode.net irc.freenode.net]
tsuyoshi has quit [hubbard.freenode.net irc.freenode.net]
rbancrof1 has quit [hubbard.freenode.net irc.freenode.net]
|Jedai| has quit [hubbard.freenode.net irc.freenode.net]
nimred has quit [hubbard.freenode.net irc.freenode.net]
rbancroft has joined #ocaml
<cedric___>
Hi all, what's new about the ocamlsprint "ocamlfind and GODI packaging"?
tarbo2 has joined #ocaml
authentic has joined #ocaml
Pepe__ has joined #ocaml
|Jedai| has joined #ocaml
xevz has joined #ocaml
tsuyoshi has joined #ocaml
nimred has joined #ocaml
<cedric___>
Hi all, what's new about the ocamlsprint "ocamlfind and GODI packaging"?
th5 has joined #ocaml
<cedric___>
Hi all, what's new about the ocamlsprint "ocamlfind and GODI packaging"?
<cedric___>
Who takes part in it?
Pepe__ is now known as Pepe_
<kaustuv_`>
cedric___: anyone can participate, I think. Have you seen the wiki page?
<kaustuv_`>
wait until hcarty or bluestorm show up for more official news
<cedric___>
yes
<cedric___>
ok, thanks
tsuyoshi has left #ocaml []
tmaedaZ is now known as tmaeda
Alpounet has joined #ocaml
<Alpounet>
hi
<julm>
hi Alp
kaustuv_` is now known as kaustuv
tmaeda is now known as tmaedaZ
u1ik has joined #ocaml
u1ik has quit ["ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]"]
ski_ has joined #ocaml
ski_ has quit ["Lost terminal"]
u1ik has joined #ocaml
komar_ has joined #ocaml
<hcarty>
cedric___: There is no official format - just the hope that folks will work on packaging libraries for GODI today :-)
<hcarty>
cedric___: Do you have any particular questions?
Amorphous has quit [Read error: 104 (Connection reset by peer)]
<hcarty>
bluestorm: I do not have an account to push packages to GODI, but Yoric[DT] does.
pandamonial has joined #ocaml
<hcarty>
bluestorm: We can discuss this when you are around, but I'm not sure if it is better to push packages today, or post the results to the GODI mailing list and request comments there
<cedric___>
hcarty: no, I have no questions, but as I did the mlpost package (and cairo too), I could explain what I did if any question about it. Furthermore, if there is a way I get a GODI account, I could maintain it.
komar_ has quit [Read error: 110 (Connection timed out)]
<Tinos>
cedric: For what it's worth I asked a GODI account a few days ago and gerd did not answer me, maybe he's busy those days
<hcarty>
If anyone is attempting a package for a particular library, please indicate it on the wiki page next to the library listing.
<cedric___>
Tinos: For what it's worth I asked a GODI account a few months ago and gerd did not answer me, maybe he's busy those months ;)
<Tinos>
:D
komar_ has joined #ocaml
Amorphous has joined #ocaml
tmaedaZ is now known as tmaeda
* thelema
is around for GODI sprint
<thelema>
although I wonder how well this will work, me not using GODI and all
blue_prawn has joined #ocaml
tmaeda is now known as tmaedaZ
Alpounet has quit ["Page closed"]
willb has joined #ocaml
tmaedaZ is now known as tmaeda
Narrenschiff has joined #ocaml
<hcarty>
thelema: :-) Getting working META files for packages that don't have them already is a start
<hcarty>
thelema: Also, to make packaging possible/easier with godiva, there should be specific make targets.
<hcarty>
Patches/wrappers to implement those targets would help.
<hcarty>
And there is the option of installing GODI. But that may be more than you want to do if you're not using it in general.
hsuh has left #ocaml []
Associat0r has quit []
Narrenschiff_ has joined #ocaml
<thelema>
META files are same for findlib and godi?
<Camarade_Tux>
thelema: afaik, yes
<hcarty>
Yes, it's findlib for GODI, Debian, Fedora, etc.
<hcarty>
Perhaps a better way to put it - the META files are specific to findlib, not the distribution.
<thelema>
how do META files fit with GODI?
<hcarty>
GODI requires findlib support, IIRC
<Camarade_Tux>
yep
<hcarty>
But even if not, the META files are generally useful since they are required for findlib support.
<Camarade_Tux>
thinking about it: what about .cmxs (for the packaging sprint)?
<thelema>
ok. Say I have a META file for camlzip - does it go into GODI?
<flux>
thelema, I would say it should go to the upstream
<flux>
thelema, however, if upstream is non-responsive, it can go to GODI as a patch
<flux>
or it can stay in GODI until the upstream makes a new release with the META file
<hcarty>
thelema: camlzip already has META files in GODI, Debian and Fedora
<thelema>
sure, but just as an example.
<flux>
I just recently contributed a META file to sfml. however, there's an issue I discovered lately and haven't quite figured out :-/
<hcarty>
There is actually an ongoing discussion about getting it upstream, as GODI uses a different naming convention than the others...
<thelema>
if only it was upstream
<flux>
thelema, in any case it's best to have the same META file for all distributions
<hcarty>
thelema: Upstream would be best.
<flux>
thelema, because if for examlpe the name changes between different distributions, Makefiles may fail to work
<thelema>
It's just a matter of Xavier Leroy adding it to his tarball, I think.
<hcarty>
thelema: And adding appropriate make target(s)
<thelema>
yes, for findlib installation
u1ik has quit ["ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]"]
Narrenschiff has quit [Read error: 110 (Connection timed out)]
Narrenschiff_ is now known as Narrenschiff
<blue_prawn>
about camlzip there is even a more important issue, there is a .cmi file that the Makefile forgets to install
<blue_prawn>
so it is unusable with a source installation
<thelema>
so let's email Xavier some patches?
<flux>
btw, regarding that, a more general issue can be found in many packages that pack multiple .cmo's into one cmo: the still accidentally install the .cmi-files for the now non-existant .cmo-files
<flux>
and it's bloody annoying :)
<hcarty>
thelema: An emailed patch would be good. I think that the Debian META file would be best for the camlzip package.
<flux>
(because you can actually write code like module A = Foo and it works, except the actual values are unbound)
<hcarty>
It has, from what I understand, been around the longest.
<hcarty>
flux: That is rather problematic :-)
<blue_prawn>
IMHO sending the META file upstream is not always a good solution, imagine an upstream author that don't use findlib, he won't be able to maintain the META if changes have to be made in it
<flux>
blue_prawn, well, people can resent patches. in any case, maintaining META file is a very low-effort task. mostly it doesn't even need to be done.
<Camarade_Tux>
but META files aren't that hard to write hopefuly
* thelema
has the feeling that Xavier doesn't use findlib
<flux>
blue_prawn, I think worse is that different downstream people have incompatible META-files
<flux>
besides I don't understand people who don't use findlib, It Just Makes Life Better :)
<hcarty>
thelema: He may still accept the patch though, if it leaves non-findlib installation in place
<blue_prawn>
flux: I'm not the same opinion, the effort to learn findlib is not that low
<hcarty>
ocamlgsl has findlib and non-findlib installation options, for example.
<flux>
it's like (for example) glibc-config, but better
<hcarty>
blue_prawn: How so?
<flux>
blue_prawn, effort to learn = writing META-files or using it?
<thelema>
godi requires findlib installation for [make install] - he probably won't go for that.
<flux>
because using it is IMO dead simple
<blue_prawn>
both, it's linked
<flux>
writing them requires some effort
<flux>
the only catch is that you need to use -linkpkg to produce executables
<hcarty>
thelema: That part can be patched in on the GODI side
<flux>
but then again usually you need to figure that you need to put the .cma-files only to the linking stage manually
<thelema>
hcarty: ok
<hcarty>
thelema: Even if the Makefile isn't patched at all, if Xavier Leroy includes a META file it will mean that downstream will be consistent.
<hcarty>
blue_prawn: One generally only has to write META files for new libraries. And the META file format is very simple.
<hcarty>
Compiling with findlib is certainly much simpler than compiling without.
Narrenschiff_ has joined #ocaml
<thelema>
hcarty: ok, we're only going to solve one problem by going upstream, the other will have to be solved by godi. gotcha
<blue_prawn>
IMHO we shouldn't ask an upstream author additionnal efforts, I think in FLOSS it doesn't work like this everyone does what he can, and one don't have to ask to others
<hcarty>
blue_prawn: But if the effort doesn't go upstream, then everyones' individual efforts end up diverging
<hcarty>
Leading to things like GODI and Debian having different findlib names for the camlzip library.
<hcarty>
Then it is up to the upstream author to accept or not accept the contribution.
<blue_prawn>
the idea to add META files is from the findlib project, so this effort should go there
<blue_prawn>
one project should not ask additionnal effort to another one
<hcarty>
I disagree - particularly when many (most?) OCaml library authors are also findlib users themselves.
<thelema>
blue_prawn: I think this more about the community asking library authors to support its packaging standard
<blue_prawn>
not everyone uses findlib
<hcarty>
Putting all of the META files in findlib means that you need a new findlib release every time a new library release comes out.
<flux>
well, that's slightly exaggarated
<hcarty>
flux: Each new library would need a new findlib release to get the new META file.
<thelema>
back in a while.
<hcarty>
If they were included in findlib
<flux>
hcarty, he didn't say the libraries that currently come with META cannot continue coming with META
<flux>
hcarty, however I still don't think they should be packaged with findlib
<blue_prawn>
I was writing lib C wrappers before to use findlib and I was very annoyed when someone sent me a META file
<flux>
because in essence maintainig findlib could be stopped now, as it's perfect :)
<blue_prawn>
and I had to maintain something I didn't know
<flux>
blue_prawn, why would you be annoyed by that?
<blue_prawn>
because I had to maintain something I didn't know
<flux>
blue_prawn, it was like 10 simple statements?
<flux>
I've sent a few META-files myself and the author hasn't minded at all
<flux>
indeed I've just saved them some effort
<blue_prawn>
no it has more complicated with several modules so with several rules
<hcarty>
blue_prawn: Then don't accept the patch? If you don't like it, you don't have to keep it.
<flux>
simply put # non-maintained by author. if it doesn't work, fix it and submit a patch.
<blue_prawn>
hcarty: yes this is what I say
<flux>
still, the best place to get a package-specific file should be the package
<hcarty>
blue_prawn: From my limited experience, most authors are happy to receive such contributions.
<blue_prawn>
upstream shouldn't have to be considered to be as "must do"
<hcarty>
The submitter could always be asked to maintain the META file.
<blue_prawn>
hcarty: probably but not all
<hcarty>
blue_prawn: But upstream submission should - then it's up to them if the change is included or not.
<flux>
blue_prawn, you don't want to provide a feature you don't use even, if the feature could be used by many of the users of your library, and it has been submitted by one?
<flux>
even, -> , even
<hcarty>
blue_prawn: If one does not want submissions from others, then just state that clearly and people will stop submitting them.
<blue_prawn>
and about the fact of a new findlib release for any change of a META file, it could be managed on another way, for example put each META in a wiki page
rcloud has joined #ocaml
<hcarty>
blue_prawn: But why do it that way, when it is such a common part of the OCaml community?
<flux>
I don't see how much of a win a META-wiki would be over the different maintainers simply putting in the META-file to their distribution
<blue_prawn>
hcarty: there are still a lot of tarballs without META file
<flux>
as said the maintenance of META-file is extremely low-effort, thus the effort of accepting patches related to it should be as well
<flux>
I simply add a META-file to libraries I use (and submit them to the author) before I usually even install them. it's that much nicer to just -package xx :)
<hcarty>
flux: Indeed :-)
<blue_prawn>
you cannot say that an author should or should not do this or that, the FLOSS philosofy is to accept a free software as a gift
<hcarty>
blue_prawn: But if users of software want to contribute, why shouldn't they?
<flux>
blue_prawn, yes, that's exactly what the author should do, accept the gift :)
<blue_prawn>
you don't say "I don't like its color" when you recieve a gift
<blue_prawn>
flux: lol :)
<hcarty>
blue_prawn: Software is very different from a physical thing.
<flux>
nobody is changing a thing in the original package, but rather adding something zero-bloat with some gain to be had
<hcarty>
If software has a bug that a user finds and fixes, and the author is available - should they not submit a fix?
<blue_prawn>
OK send an email to Xavier Leroy to explain this to him
<flux>
blue_prawn, let's say your program would not work on 64-bit platforms and a user submitted a patch. would you not accept it, even if you (let's say) have only a 32-bit platform?
Narrenschiff has quit [Read error: 110 (Connection timed out)]
Narrenschiff_ is now known as Narrenschiff
<hcarty>
blue_prawn: What does Xavier Leroy have to do with this, and why should it be explained to him?
<blue_prawn>
hcarty: he doesn't include the META in his tarballs
<blue_prawn>
hcarty: (for example in camlzip)
<hcarty>
blue_prawn: If no one has submitted one, and he doesn't use findlib, why should he?
<hcarty>
AFAIK, no one has sent him a patch yet.
<blue_prawn>
hcarty: I think debian did, because it is written in thier policy to do so
<hcarty>
blue_prawn: There is a bug report open about this now in Debian, due to the naming diferrence for camlzip between Debian and GODI.
<hcarty>
blue_prawn: I don't know of a patch, but that doesn't mean it hasn't been sent.
<flux>
indeed, none of xavier's packages appear to contain META-files
<hcarty>
Still - the reasoning stands that if he does not want to accept the patch then he does not have to.
<flux>
however it is my understanding inria has some issues with user-submitted patches
<hcarty>
And if he does, then it is beneficial to submit one.
<flux>
(mostly due to some interesting feature in the french copyright law where a contributor has some 'moral rights' over their contributions)
<blue_prawn>
and sometime it's just a question of time available
<hcarty>
flux: Yes, I'm not sure how that works out for non-OCaml projects. The reasoning, from what I understand, behind not accepting outside patches for OCaml is because it hinders their ability to relicense.
<hcarty>
blue_prawn: Again, the patch does not have to be accepted. It's not really worth getting angry over a well-intentioned submission.
<blue_prawn>
what is this issue in the name of a package between debain and godi ?
<hcarty>
blue_prawn: One has the name as zip (Debian), the other camlzip (GODI).
<blue_prawn>
is it the name field in the META file?
<hcarty>
Yes
<blue_prawn>
I thought findlib use the name of the directory
<hcarty>
The simple work-around is to install a dummy "zip" package in GODI, which has nothing itself but requires "camlzip"
<hcarty>
blue_prawn: No, the name is defined in the META file
<blue_prawn>
and the name of the dir is not important ?
<hcarty>
Rather, the name defined in the META file is the name used for the package
<blue_prawn>
ha OK
<blue_prawn>
I've learned something today
<blue_prawn>
so what should be the name field ?
<hcarty>
blue_prawn: "zip" seems to be the general consensus. camlzip installs to a "zip" directory by default, and the Debian package was around first.
<hcarty>
If xleroy does not want to include an official META file then I'll submit the work-around META file to GODI.
<hcarty>
Then using "zip" will be generally safe.
<blue_prawn>
in Mandriva the META file contains name="camlzip"
<hcarty>
blue_prawn: HA
<blue_prawn>
should I fix this ?
<hcarty>
Of course...
<hcarty>
Sorry - the "of course" was "of course there is further inconsistency"
<hcarty>
blue_prawn: If you wouldn't mind, I think changing it to "zip" would be best.
<blue_prawn>
hcarty: OK
<hcarty>
blue_prawn: I assumed "camlzip" was the better name as well, which is why I submitted a bug report to Debian.
<hcarty>
But, from the conversation around that report, I learned the bits and pieces I mentioned earlier.
dmentre has quit ["Leaving."]
<blue_prawn>
hcarty: I don't understand if you consider it as a bug it should be changed, no ?
<hcarty>
blue_prawn: The bug, as I see it, is the inconsistency.
<hcarty>
As long as the same name is used consistently then I see no problem.
<blue_prawn>
hcarty: consistently with what ?
<hcarty>
Debian had the first package. Then GODI, then Fedora. Debian and Fedora use "zip" for the name, GODI, and apparently Mandriva as well, use "camlzip".
<hcarty>
This breaks packages which rely on the zip/camlzip library.
<hcarty>
There is no consistent name to use to indicate that this library is a prerequisite.
<hcarty>
If the META file is added upstream OR all of the packagers use the same META file, then the problem is resolved.
<hcarty>
Or at least the same package name in the META file, if not exactly the same META file.
<blue_prawn>
don't you think that it could be a good idea to set up a mailing list for ocaml packaging, where the packager form all distros could discuss about consistently packages accross all the distros ?
<hcarty>
blue_prawn: And I apologize - I was wrong about the META file naming and package naming.
<hcarty>
blue_prawn: The findlib package name is set by the "ocamlfind install" command.
<blue_prawn>
hcarty: so the name of the dir ?
<hcarty>
blue_prawn: If the META file is included upstream then there is no need
smimou has joined #ocaml
<hcarty>
blue_prawn: Yes, I suppose so, where the name is determined by the "ocamlfind install" command.
<blue_prawn>
so the name field in the META file is not really used
<flux>
(with embedded SQL and HTML and everything in the same soup)
<flux>
hcarty, well, plain CGI is even simpler
<flux>
it looks like I didn't actually use the embedded HTML with that, I've got another, even smaller piece of code, where I tried that :)
<thelema>
mihamina: try running as an executable before going mod-ocaml.
<flux>
mihamina, I would not go the mod-ocaml route unless you need to hook into apache internals
<flux>
mihamina, you can have plain CGI-scripts or you can use SCGI for better performance. the scgi is the one used with python too, you can find it with mod_scgi on google
<mihamina>
thelema, flux: uh...
<mihamina>
thelema, flux: ok, I'll try to simple run first
<mihamina>
last dumb question... Iwould like to compile ocamlnet "add" examples... did not find on the web how to do it...
<mihamina>
:-P
<mihamina>
As far as I read add_cgi.ml, it depends on add.ml
<mihamina>
so I guess I have to invoke ocamlc with at least add.ml and add_cgi.ml as argumetns
<hans_>
however, I'm not able to get it to install (or rather work correctly) with ocamlfind with the META file provided with the packet
<hans_>
the packet comes with a build (some Debian packing stuff i think) file, and not a makefile, so I have to make my own makefile
<hans_>
the packet META file is the following:
<hans_>
version = "0.9.3"
<hans_>
description = "Universally unique identifiers (UUIDs) for OCaml"
<hans_>
archive(byte) = "uuidm.cmo"
<hans_>
archive(native) = "uuidm.cmx"
<hans_>
directory = "+uuidm"
<flux>
seems ok
<thelema>
hans: looks ok so far
<hans_>
but when I try to use it, I get this error:
<hans_>
Error: Unbound type constructor Uuidm.t
<bluestorm>
how do you "use it" ?
<hans_>
I have made my own META file (for an old version that did not have a META file
<hans_>
my file looks like:
<hans_>
name = "uuidm"
<hans_>
version = "0.9"
<hans_>
description = "A UUID library for OCaml"
<hans_>
archive(byte) = "uuidm.cma"
<hans_>
archive(native) = "uuidm.cmxa"
sramsay has joined #ocaml
<hans_>
install: all opt
<hans_>
ocamlfind install $(NAME) *.mli *.cmo *.cmx *.cmi META
<flux>
..you should install the .cma/.cmxa-files then too?
<hans_>
so I might be doing something wrong
<flux>
but not the .cmo/.cmx-files. or was that for the different version?
<flux>
do you have uuidm.cma?
<Alpounet>
how's going the packaging day ? :)
<hans_>
yes, it builds a cma file as well
<flux>
I'm not sure which version you are actually now using. atleast the install-rule doesn't match the previous META-file (it does match the first one)
<thelema>
you'll want to install the uuidm.cma and .cmxa
<flux>
hans_, do you do the testing in another directory?
<flux>
..than where the .cmi-files etc reside
<hans_>
so it's the archive() in "my" META that install the cma cmxa files
<flux>
hans_, hmm.. no
<hans_>
but since it is missing in the META of the package...
<flux>
hans_, META tells that to use that package the .cma-file must be linked in
<flux>
hans_, and you need to put the .cma-file with the installation so it can be found
<flux>
hans_, but if you have a .cma-file, you don't need the .cmo-files anymore because the .cma-files contain them
<hans_>
help msg
LeCamarade is now known as LeCamarade|Away
LeCamarade|Away has quit ["Gone."]
<flux>
hans_, it is advised to keep the discussion on channel so others can take part if I wear out ;)
<flux>
hans_, in any case, you either use .cmo-files or .cma-files, not both
<flux>
.cma-files are built out of .cmo-files
<thelema>
we hand off helping people all the time in #ocaml
<hans_>
what does the: directory = "+uuidm" mean? do I need to install it in a sub directory
<flux>
I haven't actually seen that earlier :)
<flux>
if you have only one .cmo-file and no c-code, it's slightly simpler to use just a .cmo-file
<flux>
otherwise, you can make a .cma-file (and possibly .a-file) out of the .cmo and .o-files
<flux>
in that case you don't use the original .cmo/.o-files because they are in the library
<hans_>
yes, but does ocamlfind require .cma files, or can it work directly with individual .cma files?
<flux>
ocamlfind can use .cma or .cmo-files
<hcarty>
bluestorm: Just got back from lunch
<hcarty>
bluestorm: I can host the files in the short-term, either directly or make a git repo
<hans_>
OK. I'll try to do some little more experimentation
<flux>
I'll likely go sleep around now, so I hope someone else can help you further. happy hacking :)
<hans_>
OK. Thanks! :-)
LeCamarade has joined #ocaml
<bluestorm>
hcarty: i think "direct" hosting would be interesting
LeCamarade is now known as LeCamarade|Away
<bluestorm>
so that people can look at the work already done
<hcarty>
bluestorm: I haven't heard much of anything from others who may be taking part
<bluestorm>
I've seen that
<Alpounet>
bluestorm, github ?
<hcarty>
Sounds good to me. Or I can make it available by cgit
<bluestorm>
Alpounet: why not
<bluestorm>
anything would do, but I'm not sure everyone knows git
<bluestorm>
I've just been trying my hand at deriving
<hcarty>
bluestorm: cgit will make .tar.gz/.zip/etc files for download.
<bluestorm>
and that's not easy :p
<hcarty>
bluestorm: I started looking at deriving earlier and decided it might be better suited for your talents :-)
<bluestorm>
no install script, strange way to build syntax extensions
<bluestorm>
har :p
<hcarty>
I'm completed a GSL package, and there are the packages from Cedric
<bluestorm>
Alpounet: you should participate :)
<hcarty>
So if anyone here has GODI and the GSL development pacakage(s) installed from their system, that's ready to test.
<hcarty>
s/from/on/
<hcarty>
Alpounet: Seconded!
<bluestorm>
I'll try to have a working META file, but it will probably require changes to the build script, so asking upstream for review will certainly be necessary before trying to push something into GODI
cedric_ has joined #ocaml
<Alpounet>
time's hugely missing in here bluestorm, hcarty, but try to keep some work for me, later !
<bluestorm>
we have a reasonable TODO list, we'll save some for you
<hcarty>
Alpounet: For simple (and not so simple) packages, godiva does a lot of the heavy lifting.
<hcarty>
bluestorm: That sounds reasonable (META + talking with upstream)
<hcarty>
Alpounet: godiva requires a .godiva file (simple syntax, see the docs linked from the wiki) and any extra files/patches required to make the library's build system match what GODI expects.
<cedric_>
hi, all; did any body tried to integrate the package for cairo-ocaml I did?
<hans_>
after some experimentation with the original META file coming with the package, it seems like the problem is cause by the 'directory = "+uuidm"' line
<hcarty>
cedric_: It's next on my list to try
<Alpounet>
hcarty, ok, thanks. I'll try to read that when I'll have enough time, and then get back here asking for libraries to package :)
<hcarty>
Alpounet: We will look forward to it :-)
ttamttam has joined #ocaml
<hcarty>
cedric_: Did you make any modifications to the upstream cairo-ocaml code in the .tar.gz you provide?
<hcarty>
cedric_: Also, why are the "opt" portions commented out?
<cedric_>
yes, because there wasn't tar.gz files, and there were some errors If I remember well
<cedric_>
I should extract the tar.gz and diff it with a git checkout, to verify it
<bluestorm>
cedric_: btw., I used your godi-ocamlgraph yesterday and it was very helpful (once I figured how to install local packages with GODI) : count me as one more happy user :)
<cedric_>
sorry I haven't done any ocaml-graph package
<hcarty>
cedric_: That makes sense - I thought the godi_* tools did some sort of directory scanning.
Demitar_ has quit ["Ex-Chat"]
<cedric_>
I didn't use GODIVA partly because we can't make configuration options, if I well remember
<hcarty>
Yoric[DT]: It's going reasonably well. One package by me, the 3 submitted by cedric_ before today, and bluestorm is working on at least one other.
<hcarty>
GSL and Cairo could use some love, as they should both depend on conf-(gsl|cairo) packages.
<Yoric[DT]>
cool
<Yoric[DT]>
I'll get to the task of packaging coThreads.
<hcarty>
Hooray!
<hcarty>
Yoric[DT]: Thanks for coming by.
<Yoric[DT]>
A pleasure.
<hcarty>
6 packages would be a reasonable success for today, I think.
<hcarty>
They still need to be submitted and put in to GODI. But it's a very nice start.
<hcarty>
bluestorm++ for the idea
<bluestorm>
do anyone here has a reasonable knowledge of the OCamlMakefile magic ?
<cedric_>
I am on the same building as the persons developping mlpost, but I have no GODI account, so I can't maintain them in GODI repository, if you include it.
<hcarty>
bluestorm: I used to use OCamlMakefile a lot, but it has been a while.
<bluestorm>
i'd like to change an exec-producing rule to a -pack rule, it's easy to do by hand but the packed result is not known by "make clean", and there is a predefined pack-byte-code but it links to much stuff
<hcarty>
That, unfortunately, is beyond my knowledge.
<bluestorm>
ok
<cedric_>
hcarty: my godi package has no conf-* for cairo, but I am not sure such a package should be usefull...
<hcarty>
cedric_: The purpose would just be to check for a recent enough version of Cairo. But I don't think it's needed yet.
<hcarty>
cedric_: And I'm not sure, as you suggest, that it is needed in general.
<hcarty>
Just getting a few more of these packages in to GODI will be a big help.
<cedric_>
hcarty: the update function of godi_console is here for that
<hcarty>
cedric_: I don't follow.
<bluestorm>
cedric_: there is a discussion of -conf -base in the GODI FAQ
<bluestorm>
hcarty: for the record, I did the trick by declaring LIB_PACK_NAME with the name of the produced .cmo : i'm still building it myself instead of using OCamlMakeFile rule, but the predefined "make clean" knows about LIB_PACK_NAME.cm*
<cedric_>
hcarty: I don't think there will be often updates on the version of cairo and if there is, somebody must make it, in the sense that there is no tar.gz for cairo-ocaml; I had to checkout cairo-ocaml, then make the tar.gz file and upload it, so an update of the version should consist in remaking the tar.gz then commit the package to godi repository; no conf-* is required (nor usefull) for that
<hcarty>
cedric_: No, I mean the system Cairo, not the OCaml bindings.
<cedric_>
hcarty: I understood it 0.5 s after posting, sorry
<hcarty>
cedric_: Check for the dev files and a recent enough version, similar to how conf-pcre behaves.
<hcarty>
cedric_: Not a problem :-)
ttamttam1 has joined #ocaml
<cedric_>
hcarty: for the moment such a conf-* is beyond my abilities, but it should be a piece of cake for persons familiar to those things; but for that GODIVA won't help...
mjs22 has quit []
Alpounet has quit [Remote closed the connection]
<hcarty>
cedric_: It's beyond mine as well, at least as much as time allows. I think godiva could be used to make the configuration package, but I'm not certain of that.
<hans_>
I have fixed the packing for Uuidm, and seems to work from my installation. Is there somewhere I can post it so that it will be part of the packages submitted?
<hcarty>
bluestorm: Should we collect packages by email?
<orbitz>
can anyone pu ta package into godi?
<hcarty>
orbitz: Anyone can request the ability to do so.
<hcarty>
Packages can also be submitted to the GODI mailing list.
<hans_>
hcarty: maybe just submitting to the mailing list might be just as good, if no one here has write access to the SVN repository and can take the responsibility of submitting packets created by this effort
ttamttam has quit [Read error: 110 (Connection timed out)]
<hcarty>
hans_: That specific message is about local patches. The attached/referenced email explains local repositories
<hans_>
hcarty: thanks. I'll have a look at it
<blue_prawn>
I know the package ocamlnet requires the package ocaml-pcre, but does the package ocamlnet-devel requires the package ocaml-pcre-devel ???
cedric_ has quit [Ping timeout: 180 seconds]
<hcarty>
blue_prawn: What do the Debian and Fedora folks do?
<blue_prawn>
they have automatic generators that manage this kind of things
<blue_prawn>
but here is no equivalent in Mandriva
<blue_prawn>
so I have to specify it explicitly
<hcarty>
But for those specific packages?
<hans_>
I updated the wiki page with Uuidm, and will just mail the submission request on the godi mailing list and see what happens :-)
<hcarty>
hans_: Thanks :-)
<hcarty>
You can email it to me as well. One of us will put up the files somewhere public for people to retrieve until they are officially added.
<blue_prawn>
hcarty: I don't know if it is possible to check without an installed distro
<hcarty>
Or I can just grab the files from your list post.
<cedric_>
but they are only package files, not the source code files of bitstring/cairo/mlpost, in fact i got it by running tar -czf on my godi/build repository
<hcarty>
hans_: I'll add your package there as well
<cedric_>
hcarty: Ok
mikaz has joined #ocaml
<cedric_>
How will we maintain them without godi accounts?
<hcarty>
cedric_: Hopefully we can all get GODI accounts :-)
<cedric_>
Is Gerd resurrected?
<hcarty>
I'll start making some noise on the GODI list once today is complete.
<cedric_>
ok
<hcarty>
I emailed him about a separate GODI question and have not heard back. My guess is that he has been busy.
<hcarty>
And/or away on vacation :-)
<cedric_>
I also sent him a mail about one month ago ... (I didn't waited today to try to add cairo/bitstring/mlpost) and no response either
ttamttam1 has quit [Read error: 110 (Connection timed out)]
<cedric_>
By the way, for my mlpost package, there is a configuration option which has no default value, that is not very nice (it should have "true" value), so if you want to modify it (it shouldn't be complicated)...
<hcarty>
cedric_: Do I just change the line to "GODI_MLPOST_CAIRO_SUPPORT=true"?
<cedric_>
I think, I didn't try to correct this
<hcarty>
Should I do the same for the Cairo lablgtk2 option? Only in that case, I suppose "false" may be a better default.
<cedric_>
I forgot this option, I trust you if you think so.
<cedric_>
I should change it in my own files
<cedric_>
I will do it tomorrow since I have no easy way to update them from where I am
ulfdoz has quit [Read error: 110 (Connection timed out)]
<hcarty>
I'm not sure how to define default options
<cedric_>
I hope CONFOPTS allow default values
<hcarty>
If I make the line "GODI_MLPOST_CAIRO_SUPPORT=yes" then it thinks that is the option name.
<cedric_>
hcarty: I don't know either, I never tried to do it
<hcarty>
I'll look around some more.
gerdstolpmann has joined #ocaml
mol_ has quit [Remote closed the connection]
ttamttam has joined #ocaml
<cedric_>
hcarty: Cool Gerd is here, we can ask him!
<hcarty>
gerdstolpmann: Thank you for stopping by!
<hcarty>
cedric_: It looks like default settings for CONFOPTS are set in the Makefile
<gerdstolpmann>
well, I wanted all day, but there something urgent in the company I'm working for
<cedric_>
gerdstolpmann, hcarty: I also have a question about giving default value to an option in CONFOPTS, how do we do it?
<gerdstolpmann>
yes, in Makefile
<gerdstolpmann>
something like
<gerdstolpmann>
P ?= default
<gerdstolpmann>
if P is your conf option
<cedric_>
hcarty: yes I didn't thought of it, but it is natural
<hcarty>
gerdstolpmann: Thanks
<cedric_>
gerdstolpmann: Thanks
<hcarty>
Yes, works here for the Cairo package.
<cedric_>
gerdstolpmann: How can we get some godi accounts to maintain our packages?
<gerdstolpmann>
I can create them
<hcarty>
cedric_: Your Cairo package works here
<gerdstolpmann>
please send an email to gerd@gerd-stolpmann.de if you want. You will get then a response where you can enter account name etc. It's a bit of handwork for me (nothing is automated), but I can do this tonight
<cedric_>
hcarty: Ok, that is cool; I knew it without the default option, but I will change it tomorrow on my repository
<hcarty>
cedric_: Sounds good. I'll update my end as well
<hcarty>
gerdstolpmann: Thank you very much
<gerdstolpmann>
I have to thank
<gerdstolpmann>
it is impressive to see how many people are interested in packaging
<blue_prawn>
does someone know how is the state of ocaml packaging for openSuse and Gentoo ?
<Yoric[DT]>
Oh, hi gerdstolpmann.
<Yoric[DT]>
How do you do?
<gerdstolpmann>
thanks for the question, I'm good
hans_ has quit ["Leaving"]
<cedric_>
blue_prawn: I don't, but I thought you were packaging for GODI, so what is the matter?
<blue_prawn>
cedric_: I don't package for GODI but for Mandriva
<hcarty>
gerdstolpmann: Camarade_Tux (IIRC) brought up the idea of using a native code godi_console. It greatly increases the speed of the program. Is there a configuration option to have it built by default?
<cedric_>
blue_prawn: Ok, I was almost certain you had a discussion today about GODI, but now I remember, it was rather about findlib and the META...
mjambon has left #ocaml []
<cedric_>
hcarty: did Camarade_Tux (IIRC) compiled it in native code to compare or did he only emit the idea?
<hcarty>
cedric_: We both tried it, and it does indeed provide a large speedup.
<hcarty>
Almost unbelievably large.
<Yoric[DT]>
gasp, I have managed to remove some of my ocaml installation while performing experiments with ocamlfind
<Yoric[DT]>
:(
<cedric_>
hcarty: ok, so I will try to do it too
ttamttam has quit ["Leaving."]
<hcarty>
Yoric[DT]: Oh my - that's not good at all
<hcarty>
Yoric[DT]: Any idea how it happened?
<cedric_>
hcarty: oups, I have done mistakes, my default values are in range {yes/no} and not {true/false}
<Yoric[DT]>
ocamlfind remove threads ...
<Yoric[DT]>
Rebuilding the world now...
<gerdstolpmann>
try to reinstall findlib
<Yoric[DT]>
Me?
<Yoric[DT]>
I'm rebuilding godi-ocaml atm.
<hcarty>
cedric_: Yes, I set it up to use yes/no if you want to grab the files from 0ok.org
<hcarty>
cedric_: I found that out as well when digging in to the Makefile
<cedric_>
hcarty: thanks, for having a native version of godi, what did you do? add the target opt to the godi-tools Makefile?
<hcarty>
cedric_: I don't remember :-) I'll look it up.
<Camarade_Tux>
cedric_: the target opt is already there
* Camarade_Tux
half there
<hcarty>
Camarade_Tux to the rescue :-)
<Camarade_Tux>
;p
<hcarty>
cedric_: If you are going to upload and maintain the Cairo OCaml GODI package, could you change the version number to 1.2.0?
<Camarade_Tux>
I'm currently making wifi work on a linux box through ssh :) (it's a bcm4312 =/ )
<cedric_>
yes
<hcarty>
cedric_: There will hopefully be a proper 1.2.0 release at some point, and without that I think the version comparisons may have trouble going from a date to a "normal" version.
<hcarty>
cedric_: Thanks
<Yoric[DT]>
Effectively, this is therefore the end of this evening's GODI sprint for me...
<Yoric[DT]>
I'll try and upload my package tomorrow.
<hcarty>
Yoric[DT]: Cool, thanks again for taking part
<hcarty>
cedric_: (if you know) - Is texlive-metapost the package I need to build mlpost?
<cedric_>
I think so
<hcarty>
Thanks. I'm testing the packages on my system.
<cedric_>
In fact, I believe that eventually, metapost won't be needed, but current version of mlpost use it
<hcarty>
mlpost is first I have heard of this program.
<cedric_>
there are some examples at mlpost.lri.fr
<cedric_>
I don't develop it, but I know the persons who do it.
<hcarty>
It looks pretty nifty. Not something I need at this point, but interesting none the less.
<hcarty>
I will hopefully, at some point, learn my way around GODI well enough to package PLplot. I think that will be a pretty significant undertaking though.
<hcarty>
cedric_: I'm getting errors when trying to install mlpost. I'm not sure what they are coming from though.
<hcarty>
It's a mkdir command... something with docs maybe.
<hcarty>
Yes, it seems to have come from the doc generation.
<hcarty>
The other packages (cairo, bitstring, gsl, uuidm) all build correctly though.
<cedric_>
strange, I checked it was the last version (0.7 had a bug at compile time); I tried my package on only two computers...
<hcarty>
cedric_: I'll try to clean things out. When I first tried to build mlpost, it failed because of a missing mpost.
<hcarty>
It may have left some cruft behind from the failed build.
<hcarty>
I can send the build log if you want it.
<cedric_>
I'll take a look on it tomorrow; if you can send me the output by mail (cauger@lri.fr)
<cedric_>
gerdstolpmann: Gerd, do you intend to put a RocketBoost with 3.11 by default instead of 3.10, or are there reasons not to do it (lack of time is a good reason)?
<gerdstolpmann>
cedric: yes, lack of time
<gerdstolpmann>
cedric: it is now becoming a bit better, so I think I can release it. I wanted to do it already months ago
Yoric[DT] has quit ["Ex-Chat"]
Narrenschiff has joined #ocaml
<cedric_>
gerdstolpmann: Ok; like lot of other persons I know, I manually switched to 3.11 with no particular problem
<gerdstolpmann>
cedric: yes, that works well. The godi support for 3.11 is stable
<cedric_>
gerdstolpmann: I have a strange error while checkouting: cedric@debian:~/godi-repo$ svn checkout https://godirepo.camlcity.org/svn/godi-build svn: Fichier '/tmp/buildd/subversion-1.6.3dfsg/subversion/libsvn_ra_serf/update.c' ligne 1620 : dysfonctionnement interne Abandon
<cedric_>
it seems that error comes from the server as I have no such file (sorry for the output, I am french)
<gerdstolpmann>
cadric: looking into the log files
<gerdstolpmann>
cedric: I still have version 1.1.4, so I think this is a client-generated message
<gerdstolpmann>
cedric: I've restarted the server, in case something was in a wrong state there
komar_ has quit [Read error: 104 (Connection reset by peer)]
<bluestorm>
I'm puzzled : i have hacked a META file for deriving that should work, apparently works in the toplevel ("topfind" then #require "deriving" is fine) but doesn't with ocamlfind ocamlc
<bluestorm>
Reference to undefined global `Pickle'
<bluestorm>
(when producing executables, using -linkall)
<bluestorm>
did I miss something obvious (beginning to get tired) ?
<hcarty>
bluestorm: Is -linkpkg needed?
<bluestorm>
oh
<hcarty>
I don't remember if that's ocamlopt only or both opt and c.
<bluestorm>
it was -linkpkg instead of -linkall
<bluestorm>
thanks
<bluestorm>
that was damn obvious :D
<hcarty>
:-) That tends to happen as it gets late.
<bluestorm>
well, so I have a working META file for deriving, modulo a small patch to the upstream syntax makefile
<hcarty>
Very nice
<bluestorm>
if you know how to use godiva from that, I'd consider letting you (or another people knowing the godi packaging side) do the package and possibly try something else before going to sleep
<hcarty>
bluestorm: godiva is pretty straightforward. I may be able to take a stab at it today.
<hcarty>
bluestorm: Is it fair to say that work on deriving is "In progress"?
smimou has quit ["bli"]
<bluestorm>
fair enough
lutter has quit ["Leaving."]
<bluestorm>
can I send you the patch and META (or is your repo pushable from outside) ?
<hcarty>
It's not pushable (or clonable) from outside, sadly. I need to figure out how to do that at some point. You can send the patch + META though.
lutter has joined #ocaml
<hcarty>
Ok, from my count we now have three packages _DONE_ and four more in progress.
tmaeda is now known as tmaedaZ
<hcarty>
At least two of those four (cairo and mlpost) are just small steps from completion.
hkBst has quit [Read error: 104 (Connection reset by peer)]
<hcarty>
bluestorm: Thanks, I'll see if I can get that working here. If I do and you are still around I will let you know.
cedric_ has quit [hubbard.freenode.net irc.freenode.net]
cedric___ has quit [hubbard.freenode.net irc.freenode.net]
cedric_ has joined #ocaml
<cedric_>
hcarty: I tried to install mlpost here and had no problem, during the configure, the program didn't recognized your platform; and maybe old files polluted the repository. Some usefull command is godi_make [install/clean/delete], see the documentation of GODI; another thing is to delete the work directory in godi/build/godi/godi-*/ to erase all old generated files
<hcarty>
cedric_: I tried deleting the build directory and restarting the process, but had the same error.
onigiri has quit [Read error: 110 (Connection timed out)]
onigiri_ is now known as onigiri
<cedric_>
hcarty: is metapost well installed (try to run mpost and see if you have a teX-like interactive command line)
<hcarty>
This is MetaPost, Version 0.993 (Web2C 7.5.6)\n**
<hcarty>
cedric_: Nothing immediately obvious
<cedric_>
hcarty: that seems ok... the error of the compilation is not very verbose... "mkdir -p img/ && cd img/ && ../customdoc/img_doc.byte >> /dev/null && cd .. + mkdir -p img/ && cd img/ && ../customdoc/img_doc.byte >> /dev/null && cd .." which one of the four commands has failed?
<hcarty>
cedric_: I wonder the same thing :-)
<cedric_>
is there remaining files in the work directory (build/godi-mloost/work)?
<cedric_>
by the way what is your OS?
<hcarty>
cedric_: Ubuntu 9.04 64bit
<hcarty>
OCaml 3.11.1
<hcarty>
The work/ directory is there
<cedric_>
hcarty: and empty, are some of the files of the command presents?
<hcarty>
It looks like it is in the failed build state
<hcarty>
There is a _build directory, for example
<bluestorm>
do you know how to insert comments in a META file ?
<hcarty>
bluestorm: # I think
<bluestorm>
thanks
<hcarty>
Yes, # starts a comment
<hcarty>
I need to go for an hour or maybe more. I'll post a message to the OCaml list some time later this evening with a summary of the day's progress.
<hcarty>
cedric_: Will you be uploading and maintaining your three packages?
<hcarty>
bluestorm: I may be able to godiva-fy your work on Deriving, but it won't be until several hours from now at the earliest. I'll send you the results once I have some.
<cedric_>
hcarty: tomorrow only, from where I am it is not very convenient
<cedric_>
and your error is quite boring
<hcarty>
bluestorm: If you feel the urge to work on it yourself, the godi-ocamlgsl directory has the gsl.godiva file which may provide some insight. And the online documentation is good as well.
<hcarty>
cedric_: Yes, I don't know how to get a better error from that.
<cedric_>
hcarty: trying to type each statements one after the other of the last command from the good directory and the good rights (but I don't know them)?
<bluestorm>
the makefile diff is mostly cosmetic this time : added install/uninstall targets but no behaviour change
<cedric_>
it is late for me, I go to sleep; bye
<bluestorm>
(well, regarding godi packaging, I will look into it in the long run, but right now I'm falling asleep in front of my keyboard, so that's probably the best thing to do)
cedric_ has quit ["Page closed"]
<bluestorm>
+not
<hcarty>
bluestorm: Sleep well then, and we can talk more about this tomorrow.
<hcarty>
Thanks again for your time on this!
bluestorm has quit [Remote closed the connection]
<hcarty>
I am off as well, take care all
willb has quit [Read error: 110 (Connection timed out)]