RE: [Caml-list] Native dynlink on 3.11: a request for packagers
On 22 November 2008 01:20 Jon Harrop wrote: > On Friday 21 November 2008 23:45:34 Dario Teixeira wrote: > > Hi, > > > > > Does ocamlfind support any of this? Since I'm now also > > > cross-compiling OCaml, I've certainly come to appreciate > > > findlib more than ever. > > > > Indeed it does. The current version of Ocsigen already > > makes use of this feature. However, because very few > > (none, actually, other than Ocsigen's) packages currently > > ship with cmxs files, an Ocsigen user who wants to play > > with native code is forced to manually generate them. > > (What impelled me to write the request was precisely > > having just gone through the process of producing the > > cmxs for a bunch of Ocamlnet and PXP libraries...) > > This begs the question: what is the advantage of a .cmxa over a .cmxs, > and > what are the downsides of linking everything dynamically? That's reducible to the standard debate of static vs dynamic linking in any language, surely? The only "impact" on performance presumably is the re-writing of the symbol tables which flexlink/dlopen does as the .cmxs file is loaded but that must be negligible. However, isn't ocamlopt able to do some cross-module optimisation (which is why .cmx files are usually shipped as well as .cmxa) - this presumably isn't possible when linking dynamically... Short-term, native dynlink doesn't work on all platforms (AFAIK?) so .cmxa is not dead, whatever your linking preference. David ___ 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
Re: [Caml-list] Native dynlink on 3.11: a request for packagers
On Friday 21 November 2008 23:45:34 Dario Teixeira wrote: > Hi, > > > Does ocamlfind support any of this? Since I'm now also > > cross-compiling OCaml, I've certainly come to appreciate > > findlib more than ever. > > Indeed it does. The current version of Ocsigen already > makes use of this feature. However, because very few > (none, actually, other than Ocsigen's) packages currently > ship with cmxs files, an Ocsigen user who wants to play > with native code is forced to manually generate them. > (What impelled me to write the request was precisely > having just gone through the process of producing the > cmxs for a bunch of Ocamlnet and PXP libraries...) This begs the question: what is the advantage of a .cmxa over a .cmxs, and what are the downsides of linking everything dynamically? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ 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
Re: [Caml-list] Native dynlink on 3.11: a request for packagers
Hi, > Does ocamlfind support any of this? Since I'm now also > cross-compiling OCaml, I've certainly come to appreciate > findlib more than ever. Indeed it does. The current version of Ocsigen already makes use of this feature. However, because very few (none, actually, other than Ocsigen's) packages currently ship with cmxs files, an Ocsigen user who wants to play with native code is forced to manually generate them. (What impelled me to write the request was precisely having just gone through the process of producing the cmxs for a bunch of Ocamlnet and PXP libraries...) Cheers, Dario ___ 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
Re: [Caml-list] Native dynlink on 3.11: a request for packagers
Does ocamlfind support any of this? Since I'm now also cross- compiling OCaml, I've certainly come to appreciate findlib more than ever. Rich. -- Richard Jones Red Hat ___ 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
[Caml-list] Native dynlink on 3.11: a request for packagers
Hi, As you are probably aware, the upcoming 3.11 release includes Alain Frisch's native dynlink patches. AFAIK, you cannot directly dynlink a cmxa or cmx file like you would do in bytecode with cma or cmo files. Beforehand, a native code binary must be made into a plugin via ocamlopt's -shared option. The suggested convention [1] is to give these plugins a cmxs extension: ocamlopt -shared -linkall -o foobar.cmxs foobar.cmxa These native code plugins are a prerequisite if one intends to run Ocsigen in native mode. Therefore, the life of Ocsigen users would be greatly simplified if library writers and packagers (GODI, Debian, Fedora, etc) would add this little extra step of generating cmxs for each cmxa. This request only makes sense for 3.11, of course. Complementary, META files should also include extra directives for plugins. For example: archive(byte) = "foobar.cma" archive(native) = "foobar.cmxa" archive(plugin,byte) = "foobar.cma" archive(plugin,native) = "foobar.cmxs" This request can of course become an OSR. My question is if the herein contained instructions will still be valid verbatim for 3.11 final. Will they? Also, please check the Ocsigen Wiki for more info on this subject [2]. Best regards, Dario Teixeira [1] http://alain.frisch.fr/natdynlink.html [2] http://www.ocsigen.org/trac/wiki/NativeCodeVersion ___ 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
Re: [Caml-list] Notes from testing OCaml 3.11.0+beta1 on Fedora
Richard Jones wrote: ocaml-pa-monad -- Stricter module naming restrictions in 3.11: ocamlc -warn-error AX -g -pp 'camlp4orf -I . pa_monad.cmo' -c pythagorean-triples.ml File "pythagorean-triples.ml", line 1, characters 0-1: Warning X: bad source file name: "Pythagorean-triples" is not a valid module name. File "pythagorean-triples.ml", line 1, characters 0-1: Error: Error-enabled warnings (1 occurrences) We are just about to release a new version of pa-monad which will fix this problem. Jacques ___ 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
Re: [Caml-list] [announce] O'Browser : OCaml on browsers
Hi, >From Kuba Ober: > Pardon the question, but is this meant to be "useful" in the future, > or is it just a fun experiment (in which case the next target should > be brainfuck). Coming soon: the OCaml VM on a turing machine ! >From Burgisser Francois : > Good idea but maybe a browser plugin to manipulate DOM would be much > more efficient. >From Gabriel Kerneis: > But, sadly, much less portable. >From Jon Harrop: > Could you write a compiler and call eval to get better performance? >From David Thomas: > I'd like to see a plugin that makes available to JS a function to > execute ocaml bytecode. Our plan is to achieve efficiency with a (not yet available) browser plug-in (the original bytecode interpreter or the native compiler) while remaining portable by using the JavaScript VM where the plug-in is not available. So we don't currently focus on optimizing (and complexifying) too much the JavaScript version. >From David Teller: > To me, the fact that you can write portable lightweight applets sounds > like a good enough reason. That and the fact that I can see this being > used by stuff like Ocsigen to make for (even) richer client-server > applications. Indeed, as Vincent wrote, even if O'Browser is at this point only a client-side scripting core, it takes place into the Ocsigen project and will be used to interact with (OCaml) server code (in its current form or not). Benjamin Canou. ___ 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
Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Erkki Seppala a écrit :
Richard Jones <[EMAIL PROTECTED]> writes:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
However, this would take away some of the benefits. For example I
prefer using the least amount of opening of modules, to make it easier
to see where the values come from, and let module S = System would
give me both IO and File reachable through S.IO and S.File
I subscribe to Richard Jones and Zheng's comments,
Using a dot means that the System namespace cannot be extended by
external packages. If you use an underscore then an external package
can extend the namespace (eg. by providing System_Newpackage)
I'm not sure how beneficial it would be that an external package can
extend the hierarchy anyway.
Disllowing third parties to extend the namespace enforces organization
of libraries in terms of PROVIDER, FUNCTIONNALITY. For the galaxy of
small modules porviding multi-purpose functionnalities, hiding the
provider from the name space makes programs and module lists more
legible. For instance, in CPAN (Perl) providers does usually not appear
in the namespace, and searching functionnalities in the wealth of
modules in CPAN is made (more) easy by this.
___
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
[Caml-list] Notes from testing OCaml 3.11.0+beta1 on Fedora
Fedora compiled most of our OCaml packages for 3.11.0+beta1 now. Here
are my notes on this, which I hope prove helpful for anyone else
trying out 3.11.
Firstly you can get any of the packages / patches we are using through
our CVS repo here: http://cvs.fedoraproject.org/viewvc/devel/
Packages _other_ than those listed below built without any problems
and are available from my temporary repository
(http://www.annexia.org/tmp/mingw/fedora-10/x86_64). They will
eventually get built in Fedora 11. Fedora 10 (released next week)
will continue to be based on OCaml 3.10.2.
Base ocaml package
--
Here are the patches we are carrying (NB especially patch 6):
Patch0: ocaml-3.11.0-rpath.patch
Patch1: ocaml-user-cflags.patch
# Support for PPC64 platform by David Woodhouse:
Patch3: ocaml-3.11.0-ppc64.patch
# This is a patch from upstream which fixes PR#4637, PR#4582.
# http://camlcvs.inria.fr/cgi-bin/cvsweb/ocaml/stdlib/string.ml.diff?r1=text&tr1
=1.29&r2=text&tr2=1.28
# commonly manifested as errors thrown saying:
# Invalid_argument("String.index_from")
Patch6: ocaml-3.11.0-string-index-from.patch
These are the patches we have removed since 3.10.2, which we believe
are no longer necessary:
# Patch to work with new TCL versions:
#Patch2: ocaml-3.10.0-tclver.patch
# Not needed because the GC allocator was completely rewritten:
#Patch4: ocaml-3.10.1-map32bit.patch
# A similar fix went upstream in 3.11.0:
#Patch5: ocaml-3.11-dev12-no-executable-stack.patch
cduce
--
Camlp4 parsing problem:
Build runtime/print_xml.cmx
File "runtime/print_xml.ml", line 110, characters 35-37:
Parse error: [expr level ;] expected after "in" (in [expr])
File "runtime/print_xml.ml", line 1, characters 0-1:
Error: Preprocessor error
make:
*** [runtime/print_xml.cmx] Error 2
cmigrep
--
Small patch required, sent upstream (see our CVS).
coq
--
Strange camlp4 problem, not yet resolved. Maybe just a missing
BuildRequires:
OCAMLClib/pp.mli
OCAMLC4 lib/pp.ml4
sh: camlp4o: command not found
File "lib/pp.ml4", line 1, characters 0-1:
Error: Preprocessor error
freetennis
--
Since we upgraded to camlimages 3.0.1, freetennis is looking for a
library called ci_core.cmxa which no longer appears to exist.
Upstream seems to be dead on this one.
ocaml-bitstring
--
Small patch required to fix a camlp4 parsing problem, not yet upstream
(see our CVS).
ocaml-cil
--
Build system failure - I didn't look very closely at this yet.
ocaml-ocamlgraph
--
There seem to be a number of build problems with the 1.0 release of
ocamlgraph. I'm not sure if these are related to 3.11.0 or not.
ocaml-omake
--
Undefined reference to caml_sync. Not looked into this yet.
ocaml-pa-monad
--
Stricter module naming restrictions in 3.11:
ocamlc -warn-error AX -g -pp 'camlp4orf -I . pa_monad.cmo' -c
pythagorean-triples.ml
File "pythagorean-triples.ml", line 1, characters 0-1:
Warning X: bad source file name: "Pythagorean-triples" is not a valid module
name.
File "pythagorean-triples.ml", line 1, characters 0-1:
Error: Error-enabled warnings (1 occurrences)
type-conv & sexplib
--
These work fine, but you must upgrade to the latest versions.
virt-df
--
camlp4 parsing problem, not yet resolved.
Rich.
--
Richard Jones
Red Hat
___
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
Re: [Caml-list] Stability of exceptions
On Thu, 20 Nov 2008 21:56:32 -0500, Eliot Handelman wrote: > > let test i = >try > [||].(i) >with > Invalid_argument "index out of bounds" -> raise (Array_access i) > > > The problem is that this test is dependent on a literal string match of > "index out of bounds." If > I accidentally write something like "index out out bounds" (an extra > space between index & out) These strings are for user information, you should write let test i = try [||].(i) with Invalid_argument _ -> raise (Array_access i) IMHO, in this case, you should rather make sure you do not perform accesses outside the array bounds. Cheers, ChriS ___ 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
Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Fri, 2008-11-21 at 00:18 +0100, Daniel Bünzli wrote: > Le 20 nov. 08 à 22:12, David Teller a écrit : > > > If anyone is willing to work on a solution for linking documentation > > from third-party libraries into one transparent source, as suggested > > by Richard Jones, please contact me. > > I'm not sure I understand what you want to acheive. If it is only a > documentation issue cannot that be done with ocamldoc's -dump and - > load ? No, it's not. You cannot ask everyone to regenerate all the documentation of every single package they have as often as they install new packages. The problem is linking already-generated documentation post-facto. > > Batteries (pack) > > 1. Standard (automatically opened) > > Is this Pervasives ? If it is I think the latter name is more > descriptive. It is the replacement for [Pervasives], indeed. And I'm pretty sure that, for beginners, [Pervasives] is more confusing than [Standard]. Since it's automatically opened anyway, most people won't need to know the name. > > 13. Threads (A module containing aliases to Condition, Event...) > >19. CoThreads (as Threads but with implementations coming from > >coThreads) > > If Threads and CoThreads are really semantically compatible I think > that your idea of only having everything in Threads and CoThread is > better and sufficient (i.e. top-level Condition, CoCondition, etc. > should be dropped). Advise the users to open Threads/Cothreads to use > the modules (or functorize their code on Concurrency). This allows to > quickly switch from one implementation to the other by changing the > toplevel open directive. With the current proposal users may be > tempted to use Condition directly, and what happens if some have used > Condition and others CoCondition in their modules and we suddenly try > to use them toghether ? Well, that was my argument for hierarchies. Stop stealing my arguments :) More seriously, sure. > > While I personally find this solution a little clumsier than the > > previous hierarchy, ymmv. > > Of course when you look it as a long list it does, but that's a > presentation issue. This proposal is much more convenient to use in > your code and that's what eventually matters (at least to me). Thanks > for the new proposal. Well, I've started working on a new generation of documentation generation should make navigation by topics feasible. I'll try and have a prototype within 1-2 weeks. > Best, > > Daniel Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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
Re: [Caml-list] About namespaces
On Thu, 2008-11-20 at 22:57 +0100, Christophe Raffalli wrote: > And what about include (it is your import) ? It allows what you want and > is short ? No, [include] is the low-level mechanism which must be used to implement the higher-level [import]. The main difference being that [import] needs to read information from all the (findlib) packages which are being used to compile your project and determine all the modules from each package which are registered as providing [List]. The programmer doesn't need to know the exact name of each module. Does that make things any clearer? Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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
