Re: [Caml-list] Modify macro and caml_initialize function
On Sun, 5 Dec 2010 17:02:37 +0100
"CUOQ Pascal" wrote:
> ygrek wrote:
>
> > BTW, while we are on this topic, why the following is not in upstream yet?
> >
> > http://eigenclass.org/R2/writings/optimizing-caml_modify
> >
> > Looks like a clear win-win without drawbacks (increased code size shouldn't
> > be significant
> > cause Modify is only used in a couple of places). What do you think?
>
> This is very interesting. Thanks for pointing it out.
Sorry to be nitpicking, but...
IIRC, there might be some rare occasions where the Modify macro could
be called several times in a C routine. And then you've got several
caml_modify_maybe_add_to_ref_table labels in the same C routine.
With GCC, you could use a local __label__
http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html but if you want to
be portable to non GCC compilers, you'll need a Modify macro which
generates a unique label (perhaps using __LINE__ for that purpose).
I am thinking of something like [UNTESTED CODE]
#define Modify(fp, val) Modify_at(fp, val, __LINE__)
#define Modify_at(fp, val, lin) do{ \
value in_heap = 0;\
value _old_ = *(fp); \
*(fp) = (val);\
if (caml_gc_phase == Phase_mark) {\
if (Is_in_heap (fp)) { \
caml_darken (_old_, NULL);\
in_heap = 1; \
goto caml_modify_maybe_add_to_ref_table##Lin; \
} \
} else { \
caml_modify_maybe_add_to_ref_table##Lin: \
if (Is_block (val) && Is_young (val) \
&& ! (Is_block (_old_) && Is_young (_old_)) &&\
(in_heap || Is_in_heap (fp)) ){ \
if (caml_ref_table.ptr >= caml_ref_table.limit){\
CAMLassert (caml_ref_table.ptr == caml_ref_table.limit); \
caml_realloc_ref_table (&caml_ref_table); \
} \
*caml_ref_table.ptr++ = (fp); \
} \
} \
}while(0)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] GADT constructor syntax
On Sat, 4 Dec 2010 14:25:01 -0500
Jacques Le Normand wrote:
> Dear caml-list,
> I would like to start a constructive discussion on the syntax of GADT
> constructors of the ocaml gadt branch, which can be found at:
>
> https://sites.google.com/site/ocamlgadt/
>
> There are two separate issues:
>
> 1) general constructor form
>
> option a)
>
> type _ t =
> TrueLit : bool t
> | IntLit of int : int lit
>
> option b)
>
> type _ t =
> TrueLit : bool t
> | IntLit : int -> int lit
>
I would believe that we need more examples to choose the most readable
or natural syntax. Because both options have their valid point.
Maybe you might
1. provide a more convincing example, e.g. a 20 lines tutorial example,
and give it in both syntaxes. This let people choose really...
2. choose one syntax for the ocamlyacc (or menhir) based parser, and
provide an Ocamlp4 (or is it Ocamlp5) extension for the other syntax.
3. support both syntaxes at once, and have the user choose what fits him best.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] OCamlJIT2 vs. OCamlJIT
On Tue, 30 Nov 2010 19:26:00 +0200
Török Edwin wrote:
>
> Well there could also be a GCC backend for OCaml, but I don't know how
> one should get started writing one (or if it would be worth it).
Since I worked on OcamlJIT1 and since I am working now on GCC
(actually, mostly on the GCC MELT branch, see www.gcc-melt.org for
more, but sometimes on the GCC trunk, e.g. its gengtype generator), I
probably have some personal ideas [e.g. my opinions only] on that.
However, I am not crazy enough to work on an Ocaml front-end to GCC!
The current (slow) trend inside GCC is to open & stabilize more and
more its middle-end. In particular, the GCC middle end internal
representations (which you can work on using MELT, a Lispy domain
specific language suited for that very purpose) such as Gimple (and
Tree) are becoming more stable, and will eventually (I don't know how
and when and by whom!) have a "front-end", that is a program eating a
textual representation of Gimple code and building from it Gimple
internal representation in GCC memory.
So in the long term, the GCC internal Gimple language is becoming more
stable and will have a textual front-end. It will then becomes quite
similar to the LLVM input language http://llvm.org/docs/LangRef.html.
When that happens, one could imagine that ocamlopt (or some other
program) will have the ability to generate (in textual files) the
appropriate representations of the Ocaml code it is compiling.
One could also imagine that in the long term, GCC would provide enough
plugin hooks to plug a full (nearly arbitrary) front-end inside it. If
that happens, one could imagine an Ocaml compiler, implemented as a
gcc-ocaml-frontend.so plugin, which would create Gimple internals from
Ocaml code.
However, I believe no one is interested to work on that, and this is
probably the case because Ocaml is "fast-enough" for most cases. Ocaml
major strength is the power and expressiveness of its source language.
My feeling is that Ocaml is more targetted for people requiring
developers' productivity, while GCC is a mature industrial compiler
aiming portability and performance of generated binary programs, coded
in old [ugly] languages like C or C++.
I am not sure that putting a lot of efforts inside the Ocaml compiler,
to slightly improve the performance of generated executable, is
worthwhile (in particular, because the runtime & the GC may become a
bottleneck w.r.t to minor performance improvement of ocamlopt generated
binaries). I would bet that would bring less than 20% improvement at
most (and often, much less), for a quite high labor cost.
And my personal feeling is that these days, bright Gallium people (like
Xavier Leroy or François Pottier and their colleagues) and other Inria
persons related to Ocaml (like Damien Doligez or Pierre Weis and many
others) are much more interested in bringing formal methods inside
compilers (e.g. the Compcert project of a certified & "proved" C
compiler) than in spending a lot of time to improve ocamlopt generated
code by a few percents.
I would prefer them to improve even more the Ocaml language (e.g.
GADT...), perhaps to work on a parallel runtime (but we all now that is
*very* hard and perhaps even boring), perhaps even to start working, as
researchers, on the [incompatible] successor of Ocaml. As food for
thought, I tend to believe that parallel computers (e.g. "clouds", or
just our next desktop with 16 cores) will require another programming
style and another programming language, and that incrementally
improving Ocaml for such systems is not enough. Some people will have
to invent another way of thinking and programming these parallel
systems, and it might be the same people who brought us Ocaml!
But all this is day-dreaming, I have no real ideas, just personal
wishes (and a big admiration for all the Ocaml people at INRIA, which
are *researchers* not random software developers).
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] my own exceptions from ocamlyacc?
On Mon, 11 Oct 2010 12:22:49 +0200
oli...@first.in-berlin.de wrote:
>
> the header-section from ocamlyacc appears in the
> *.ml file of the parser, but not in the mli-file.
Maybe menhir is better in that respect (I don't know). Did you try it?
http://gallium.inria.fr/~fpottier/menhir/
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] Compiling Ocaml sources to c sources
On Wed, 15 Sep 2010 15:18:39 +0200
Vincent Gripon wrote:
> Hello David,
>
> This is a good idea. Basile made a just in time implementation which is
> preferable to us as we do not know if the contest has time constraints
> on the compilation of submitted sources.
But my ocamljitrun.c still needs your ocaml sources to be compiled by
ocamlc. And you could use ocaml instead.
And ocamlopt compiles source code quite quickly in practice (faster
that gcc is handling source code compiled with -O2).
Did you ask the contest organizer if ocaml is a valid language?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] Compiling Ocaml sources to c sources
On Wed, 15 Sep 2010 15:04:30 +0200
Vincent Gripon wrote:
> Hi Thomas,
>
> Basile's suggestion allows us to use the whole OCaml syntax with no real
> need for coding. That's why we are planing to use it.
> Thank you for your solution.
I am not sure to follow what you call "Basile's suggestion" exactly. If
it is ocamljitrun.c it is just a tiny improvement over interp.c from
ocaml distribution. Of course you don't need my permission to use
ocamljitrun.c provided you respect its licence and its copyright owner
(which is INRIA, which was my employer at the time I wrote it).
And after glancing quickly at
http://www.ieee.org/membership_services/membership/students/competitions/xtreme/index.html
I was not able to easily find mention of a fixed set of languages like
C, C#, Java, C++.
However, perhaps in reality, your question becomes: what is source code
in the eyes of an expert (the human jury of your competition). This
don't have any easy or trivial answer. Maybe your answer should take
into account the preference of the jury.
The definition I usually like the most is that source code is the form
of code which is preferred by the programmer (I think it is a GNU
definition, or perhaps an FSF one). But again, this could be subject to
interpretation, and lawyers or programmers have different views on it.
And different programmers have different preferences (just think about
the role of comments; there are probably important in your competition,
but they don't mean anything to Ocaml.).
Source code is not necessarily even a textual file (but in Ocaml or C
it usually is; however I could be very pedantic and claim that source
code for me is the code picture with syntax hightlighting and colors -as
provided by my favorite editor's setting.). Likewise, I am not able to
give a precise definition of what a text is (are two different
translations or editions of the Bible the same text?).
There used to be systems where source code was not textual. Long long
time ago, at IRIA (the predecessor of INRIA) there used to be systems
like Centaur... I also remember having a read a paper about Galaxy and
hypertext programming (forgot the references).
Good luck for the competition.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] Compiling Ocaml sources to c sources
On Tue, Sep 14, 2010 at 02:09:47PM +0200, Vincent Gripon wrote:
> Hello,
>
> We are currently planing to participate to a programming contest.
It would be interesting for us to know more about that contest.
> This contest allows the use of four languages (C/C#/C++/java) but
> not OCaml.
That does not mean much. What about libraries you are calling from C?
In particular:
* can you use any library? This seems strange (because the
organizers very probably won't have the same libraries or versions
as you have).
* do you have any restrictions on the libraries you are using?
* at the extreme case, the competition might require you to provide
all the sources of every non standard (in the sense of ISO C
standard) libraries you are using, and a verified mean to build
them. What about POSIX system calls?
>
> We would like to use Ocaml as it is to us the language that fits the
> most the kind of exercises proposed. The organizers don't mind if we
> use OCaml as long as we provide an easily compilable C source to
> them, even if it is not readable.
>
> Is there any platform independent way to compile OCaml sources to C
> sources?
I don't see any easy way to do that. There are several issues
* the Ocaml runtime environment, which not only includes its garbage
collector but also all the ocaml runtime library.
* Hacking a C generator inside Ocaml is non-trivial, because of the
garbage collector, currified function calls, and tail recursion
etc.
* If you really insist on coding in Ocaml and if you don't care much
about performance, you could take my bit-rotten Ocamljit work (I
forgot where you can find it, and I don't have it anymore, but
google should help finding it) and make something which transform
the entire bytecode of an Ocaml program into a gigantic single C
function (translating straightforwardly every byte code into a
small chunk of C code). This is not easy to do, and it might not
be fun neither. Very probably, a C compiler would have pain to
optimize such a big function (by personal experience, the GCC
compiler usually take O(n^2) time to optimize with -O2 a
sufficiently large function of size n, and may also need O(n^2)
memory). And such an approach might not produce portable code
(perhaps there are some issues w.r.t. 32 vs 64 bits
systems). Actually, portable C is a fiction: only ported C
programs can exist.
Did you also consider using Scheme, it has several implementations
generating C code (Chicken & Stalin come to mind).
But still, programming in C does not mean much! What about
portability? building? external libraries? linking other stuff? target
system?
If you have complete freedom on what you link with your program, you
could hack a libocamlrun to be linkable, and link the bytecode as an
array, as suggested previously.
I would imagine that preparing stuff to make you code in Ocaml and fit
into the contest rules is a big lot of work.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] interfacing Ocaml with Mathematica
On Fri, 03 Sep 2010 16:49:38 +0100 zaid al-zobaidi wrote: > Dear members > > I am writing an Ocaml code and part of it I need to do the following job: > > * I want to find out if two arithmetic or logical expressions are equal > like "a + b" and "2 * a + b - a" or "a and b or a" and "a", and Ocaml So you want a formal tool working on formal expression trees [you don't want to work on strings]. I believe there are several of these. And there exist a limitation on them. IIRC, one of Robinson's theorems states that under suitable & reasonable hypothesis the formal equality problem is undecidable (perhaps: equality of functions expressed with an expression made from an unknown x, constants, four usual operations + - * /, square roots, trigonometric, logarithmic, exponential, ... is undecidable) On the other hand, rewriting such a simplification tool by yourself is a very interesting exercise. > it is unlikely to achieve my target, therefore I checked the available > packages and tools that can do the job and I found "Mathematica". > I would appreciate if someone could guide me on how to interface (if > possible)to mathematica from Ocaml programme. > I would choose another tool than Mathematica. I would choose a free (as in speech) software. Very probably, Coq could be used that way (Coq is coded in & interfaced with Ocaml). But I don't know it well enough. Coq is a world by itself. Cheers -- Basile Starynkevitch ___ 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] More re GC hanging
On Sun, 2010-08-15 at 12:45 +0200, Adrien wrote:
>
> Finally, C bindings. I created a few while not having access to the
> internet and they are quite dirty. I highly doubt they play perfectly
> well with the garbage collector: they seem ok but probably aren't
> perfect. That's definitely something to check, even if the bindings
> were written by someone else because working nicely with the GC can be
> quite hard.
Then I suggest to post here a representative (rather complex) example of
your C binding glue code.
>
> Also, on my computer, I have the following behaviour:
> 11:44 ~ % sudo echo 0 > /proc/sys/kernel/randomize_va_space
> zsh: permission denied: /proc/sys/kernel/randomize_va_space
This is normal. The sudo applies to the echo command, not to the
redirection. You want to redirect as root, not as the user, so
sudo sh -c 'echo 0 > /proc/sys/kernel/randomize_va_space'
should work.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] More re GC hanging
On Sun, 2010-08-15 at 18:40 +1000, Paul Steckler wrote:
> > I guess this is related to the fact that recent Linux kernel have turned
> > on the randomize virtual address space feature -designed to improve
> > system security. You could disable it by
> > echo 0 > /proc/sys/kernel/randomize_va_space
> > but first learn more about it.
>
> For some reason, I was able to edit that file using emacs, even when
> echo wouldn't work.
To check that it did work as expected (which I doubt) do
cat /proc/sys/kernel/randomize_va_space
it should give 0
>
> But the hanging problem persists.
Are you sure that you don't have badly coded C routines that you call
from your Ocaml code (don't forget correct use of CAMLparam & CAMLlocal,
read again carefully
http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html and perhaps
other material about precise garbage collectors).
Are you sure you don't have a memory leak in your Ocaml code? This could
happen when a reference value refers to a "big" value you don't need
anymore.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] More re GC hanging
On Sun, 2010-08-15 at 15:57 +1000, Paul Steckler wrote:
> I haven't yet come up with a solution to the GC hanging problem I
> mentioned the other day.
>
> But here's something that looks funny. [..]
> After turning on the Gc verbose option, I see:
[...]
> !<>Sweeping 9223372036854775807 words
> Starting new major GC cycle
> Marking 9223372036854775807 words
> Subphase = 10
> Sweeping 9223372036854775807 words
>
> Those are some big mark and sweep numbers at the end!
I guess this is related to the fact that recent Linux kernel have turned
on the randomize virtual address space feature -designed to improve
system security. You could disable it by
echo 0 > /proc/sys/kernel/randomize_va_space
but first learn more about it.
I believe recent Ocaml versions (did you try 3.12?) have GC improvements
for that.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] GC hangs application
On Wed, 2010-08-11 at 19:30 +1000, Paul Steckler wrote:
> I have an OCaml application that does a lot of string manipulations,
> generating a
> lot of garbage. After running awhile, it seems not to make any progress.
> The exact
> point where it hangs varies. The strings aren't very large, but there a lot
> of them.
Is your application a well behaved purely Ocaml code, or do you have
Obj.magic or external functions written in C? Perhaps you are violating
some GC invariant.
You might still occasionally (i.e. every 1000 steps or requests, or
every few seconds) call Gc.compact.
> The information in this e-mail may be confidential and subject to legal
> professional privilege and/or copyright. National ICT Australia Limited
> accepts no liability for any damage caused by this email or its attachments.
I understand you don't customize that kind of [stupid company policy]
mail footer, but it is really inappropriate on a public & archived
mailing list. The usual advice is to use a public email account (e.g. on
gmail) to avoid that kind of nonsense. Nothing on a publicly archived
list can be confidential!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
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] C++ STL bindings
On Mon, May 10, 2010 at 10:00:32AM -0400, Jianzhou Zhao wrote:
> Does anyone know if there is an OCaml binding to C++ STL libraries, or
> any other functional language with a foreign binding to such C++
> standard libraries (STL, boost)?
I believe such a beast cannot reliably exist.
The STL C++ library (and probably the Boost one also) provides a bunch
of data structure implementations in C++. All these implementation are
built on the (sad) fact that C++ manage memory (& resources)
explicitly. In other words, any data in the C++ heap was probably
allocated thru new and should probably be *explicitly* freed thru
delete.
Also the STL C++ library is heavily template based. This means some
kind of systematic code generation.
In contrast, Ocaml provide very useful generic abstract data types in
its standard library (and other common libraries...) using functors
(see the List, Array, Hashtbl, Map, Set, ... modules).
Ocaml has also a powerful garbage collector, and most functors from
its standard library take advantage of it (in a few words, in Ocaml,
allocating memory is conceptually quite cheap & efficient, and you
don't need to free it explicitly; in contrast, allocating memory
inside C++ heap is usually much slower that equivalent allocation in
Ocaml; of course the C++ memory manager has features not provided by
Ocaml's GC -real multithreading, ...-).
So the short answer to your quest is: stick to Ocaml functors (and
avoid using C++ STL in Ocaml programs).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] AGI research using ocaml
Eray Ozkural wrote: My only problem right now is the lack of proper GPU
support.
The OpenGPU http://opengnu.net/ project which just has started would in
principle add interface to GPU processing (perhaps thru OpenCL, e.g. by
interfacing some OpenCL or Cuda libraries to Ocaml) so provide such
features to Ocaml.
But the project has just started, and probably will have first results
in a year.
I will work within OpenGPU, but with GCC (using MELT, a lispy dialect to
code GCC plugins in), so not directly related to Ocaml. The Ocaml work
will be from LIP6 people (like E.Chailloux).
cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] AGI research using ocaml
Eray Ozkural wrote:
Hello BlueStorm,
I assume you're an AI of some sort ;)
On Sat, Mar 13, 2010 at 3:21 PM, blue storm wrote:
It is difficult to understand what you say with no previous knowledge of
your field (wich is probably not a common knowledge among OCaml hackers).
The fact that you paper is named "Stochastic Grammar Based Incremental
Machine Learning Using Scheme" doesn't help.
It would be impossible for anybody to construct Algorithmic Probability Theory
on his own in little time. In fact, that's why I'm working on
incremental machine learning, for
there is no way one can simply come up with all the results in a
branch of science
from zero ground. We stand on the shoulders of the giants, which is the problem
I'm working on: general-purpose long-term memory.
Sorry for the off-topic remark, but you might be interested by Jacques
Pitrat's work, e.g. his "Artificial Being" book (March 2009, Wiley)
http://www.iste.co.uk/index.php?f=a&ACTION=View&id=257 and his
MALICE/CAIA system on http://pagesperso-orange.fr/jacques.pitrat/
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] free, open-source version of OCaml grammar?
Yitzhak Mandelbaum wrote:
Hi,
I'd like to port the OCaml grammar to another parser generator. However,
the grammar is covered under the Q Public License, and the terms of the
license seem to require that the ported version only be distributed as a
patch to the current YACC grammar. Given that I'm porting the grammar to
serve as an example for a new parser generator, distributing it as an
unreadable patch is quite impractical.
I am not sure that the licence requires you to make it a patch, if the syntax of your grammar is sufficiently different.
(for instance, to port it to ANTLR/PCCTS). But I am not a lawyer.
If you intend to make a free software of your parser, perhaps the easiest way
would be to ask kindly the Ocaml team?
My feeling is that your understanding of Ocaml's licence is too restrictive, especially if you play the free software
game. But I am not a lawyer!
And a language syntax is not described by a yacc grammar, but by a human readable document. AFAIK, the Ocaml reference
manual is not covered by QPL.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] Re: How to wrap around C++?
Guillaume Yziquel wrote:
Essentially, the garbage collector will run potentially each time you
allocate an OCaml value. caml_copy_string? the GC may run.
The garbage collector may also run when calling (from C or C++ code) a callback, that is a function like caml_callback
... (see section 18.7 of the manual), since this apply an Ocaml closure which of course will allocate Ocaml values.
In practical terms, you should consider that the Ocaml GC can be invoked by any C function from the Ocaml runtime (as
seen by your C or C++ code) and that it moves pointers at every invocation.
So you better be safe and play carefully Ocaml rules.
Unless you really understand all the details of Ocaml runtime, I strongly recommend against playing tricks with Ocaml,
for instance trying to avoid CAMLlocalX or CAMLparamX or CAMLreturn macros.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] Ocaml implementation and low level details
Konstantin Tcholokachvili wrote:
Thank you for these infos, I will consider which solution fits the best
with my project: make a trade off, find a more suitable ML
implementation or stay (sadly) with C.
You might also consider some safer system programming languages, like Cyclone
or BitC.
You could also consider generating some "safer" C from some other, better,
language...
http://en.wikipedia.org/wiki/Cyclone_%28programming_language%29
http://cyclone.thelanguage.org/
http://www.bitc-lang.org/
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] C++ parser
Guillaume Yziquel wrote:
For a new project, I'd use GCC XML.
[[sorry for this reply, which is barely related to Ocaml, but may be of interest to several Ocaml fans interested in C++
analysis]]
There is however a small caveat. AFAIK, GCC XML is not much maintained, and depends upon an old GCC version (but I might
be wrong on both points). Latest release of GCC XML seems to be 0.6 from february 2004.
Next (4.5.0) release of GCC will provide two major new features: link time
optimization [=LTO] & plugins.
Both features are useful for any kind of C++ static analysis programs; a plugin can define new passes, and the LTO
feature enable them to be run at "link" time, that is to merge information from several compilation units. And indeed
GCC have powerful & common internal representations of the compiled source code, which is the same for C, C++, Fortran,
Ada, Java .. source inputs to GCC.
So one could consider coding a plugin for GCC which extracts the exact information required by your (Ocaml) static
analyser. In addition (sorry for the shameless self-promotion), if you like functional programming, you might even code
your plugin as a MELT module. MELT is a plugin (written by me) which enables you to express your GCC pass in a
higher-level Lisp-like mostly dynamic language (with closures, powerful pattern matching [in particular pattern matching
on GCC internal representations like Gimple], objects - but unfortunately no static typing with type inference).
Feel free to ask me more (preferably off list, or preferably on the
g...@gcc.gnu.org list) about MELT.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] problem creating .cma library
Guillaume Yziquel wrote:
However, I had a look at
https://yquem.inria.fr/caml/svn/ocaml/version/3.09/byterun/sys.c
and more specifically at the function
CAMLprim value caml_sys_exit(value retcode)
{
#ifndef NATIVE_CODE
caml_debugger(PROGRAM_EXIT);
#endif
exit(Int_val(retcode));
return Val_unit;
}
or the function
CAMLprim value caml_sys_close(value fd)
{
close(Int_val(fd));
return Val_unit;
}
Why do these functions not follow the usual CAMLparam/CAMLreturn macro
stuff?
Because they are written by the Ocaml guys (Damien knows really well the Ocaml garbage collector; he wrote it). And
also, because these particular functions do not do any allocation of Ocaml values (either directly or indirectly).
My advice for people coding C code for ocaml is the following:
1. *always* use the CAMLparam/CAMLreturn/... macros.
2. if you dare not using them for some very few functions (because they don't allocate, ...) add a big fat comment with
a warning inside.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] ocaml, llvm and generating code at runtime
Jon Harrop wrote:
On Friday 01 January 2010 17:39:15 Basile STARYNKEVITCH wrote:
LLVM is rumored to be a bit faster, but is also rumored to be slow as a
pure JIT (just in time) code generated (w.r.t. to other non Ocaml
implementations - eg SBCL or CLISP common lisp).
Are you saying that LLVM's JIT is slow to generate code or that the code it
generates runs slow?
I heard that LLVM code generation time is significantly higher (i.e. slower) than other JIT technologies. So machine
code generation time is apparently significant which might be an issue inside a web server) but performance of the
generated code is supposedly good (inside a web server this is important only if the generated code runs a lot, in
particular more than in a single session).
I don't have enough personal experience to validate that claim.
However, both MONO & PARROT sites are saying something similar:
http://www.mono-project.com/Mono_LLVM
http://trac.parrot.org/parrot/wiki/JITRewrite
http://cliffhacks.blogspot.com/2007/03/experimenting-with-llvm.html
But again, I may be wrong. Only real benchmarks on real applications can tell.
I believe that libjit & GNU lightning should probably both generate machine code quicker than LLVM does, but the
performance of the generated code (by libjit or by lightning) is worse than when using LLVM.
And some benchmarks on http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1 suggest that LLVM
generated machine code is less efficient than GCC generated machine code.
Again, take all this with a grain of salt...
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] ocaml, llvm and generating code at runtime
Joel Reymont wrote:
Does anybody have example code that shows how to generate OCaml bindings at
runtime with LLVM?
My goal is to compile an AST into code that uses OCaml functions within the
same binary that's doing the compiling.
I don't think it can be done with OCaml since it requires a standalone assembler, linker, etc.
You could generate some (Ocaml) source code, compile it (using ocamlopt -shared), and then dynamically load the just
generated shared module using Dynlink.loadfile. IIRC, the "experimental" ocamlnat binary did that.
> Correct me if I'm wrong, though. Mine is a web-based compiler with potentially many concurrent sessions. Running gas,
ld, etc. seems a much heavier and less scalable approach that generating code at runtime.
Indeed, forking an ocamlopt & then loading the shared module is more heavy, and you have a slight latency issue: if the
generated code is not big (i.e. less than a thousand lines of Ocaml code), it could take a few seconds (or tenths of
seconds).
LLVM is rumored to be a bit faster, but is also rumored to be slow as a pure JIT (just in time) code generated (w.r.t.
to other non Ocaml implementations - eg SBCL or CLISP common lisp). Polyml http://polyml.org/ is also supposed to be a
JIT-ed SML implementation (it is SML not Ocaml). A few years ago, metaocaml existed, but seems dead today.
However, inside a web server, you also have another issue: garbage collection (or simply disposal) of generated code.
And this happens even with LLVM. You probably should dispose explicitly & manually of session data and generated code.
Ten years ago, SML/NJ was supposed to also garbage-collect code. Ocaml don't do that, and today's Ocaml Dynlink module
don't have any unloading code (it would be unsafe).
A possible work-around could be to restart your web compiling server once in a
while (e.g. twice a day).
Happy new year to everyone!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] Module abbreviation
Romain Bardou wrote:
Basile STARYNKEVITCH wrote:
Romain Bardou wrote:
Hello, dear Caml-list,
I have a file ast.mli. It has no .ml implementation as it contains only
type definitions.
Then you should name that file ast.ml. Last time I tested (more than a
year ago) n ast.ml file without corresponding ast.mli file is handled as
if ast.mli was the output of ocamlc -i ast.ml.
Regards
Yes, this seems to be the easiest way. It's too bad that this implies
having a .cmo to link against just for some type definitions, though.
Why is that bad? The *.cm[oi] files are the only ones containing the processed type & module information, and we
obviously don't want ocamlc to reparse ast.mli each time it is needed.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] How to write a CUDA kernel in ocaml?
David Allsopp wrote:
Basile Starynkevitch wrote:
Eray Ozkural wrote:
Compiling Ocaml to efficient C is not easy and probably impossible (or
extremely difficult) in the general case. In
particular, tail recursive calls are essential in Ocaml, and are not
available in C in most compilers.
What's this based on (out of interest)? Most C compilers don't necessarily
identify tail recursion in *C* code but if you're emitting C as an OCaml
backend then there's no reason not to convert tail recursive *OCaml*
functions to C code based on goto or similar looping constructs (yes, you'd
almost-always-virtually-never use goto in a hand-crafted C program without
apologising profusely at Dijkstra's grave but if you're using C as an
intermediate language then that's a different matter). If I recall correctly
from an old post on this list, this is how Felix handles tail recursion when
translating Felix to C++
I am not sure this can work when tail-calling an unknown function. How would
you translate to C
let rec f g x =
if x < 0 then
g x (*tail recursive call to an unknown function*)
else
f g (x - 1)
;;
ocamlopt -S gives (I am keeping only the crucial code)
camlEsstr__f_58:
.L101:
movq%rax, %rsi
cmpq$1, %rbx
jge .L100
movq(%rsi), %rdi
movq%rbx, %rax
movq%rsi, %rbx
jmp *%rdi tail rec call to g
.align 4
.L100:
addq$-2, %rbx
movq%rsi, %rax
jmp .L101
As you can see, the tail recursive call is translated to an undirect jmp.
Please explain how you would translate the above example to portable &
efficient C.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] Module abbreviation
Romain Bardou wrote:
Hello, dear Caml-list,
I have a file ast.mli. It has no .ml implementation as it contains only
type definitions.
Then you should name that file ast.ml. Last time I tested (more than a year ago) n ast.ml file without corresponding
ast.mli file is handled as if ast.mli was the output of ocamlc -i ast.ml.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] How to write a CUDA kernel in ocaml?
Eray Ozkural wrote:
I've looked at the CUDA bindings for ocaml, but it seems the kernels
were in C, am I right? How can I write the kernel in ocaml?
At any rate, the obvious question from a compiler standpoint is,
cannot we compile ocaml to C, is there a way to translate to C first
and then to whatever works for kernel? I know little about the ocaml
compiler so please forgive my naive questions.
Compiling Ocaml to efficient C is not easy and probably impossible (or extremely difficult) in the general case. In
particular, tail recursive calls are essential in Ocaml, and are not available in C in most compilers. Some C compilers
are able to generate (in the machine) a teil call for a limited kind of C functions, which are not compatible with
Ocaml's runtime system (& garbage collector).
You could perhaps translate (in a dummy & inefficient way) the full Ocaml bytecode of an entire Ocaml application into a
C program (for example, as a huge monolithic single C function, which would make gcc very unhappy to compile it). Of
course, you could do much better, but it is not a trivial task.
Another issue is that Ocaml might not box (or unbox) your floating point values
as CUDA (or OpenCL) expects them.
But I am not an expert on these things.
Good luck.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] How to write a CUDA kernel in ocaml?
Eray Ozkural wrote:
Hello there,
I've looked at the CUDA bindings for ocaml, but it seems the kernels
were in C, am I right? How can I write the kernel in ocaml? I have an
ocaml program that is badly in need of parallelization and it fits the
NVIDIA architecture. If ocaml changes are required please explain to
me a little, I have sufficient knowledge of compilers, I've worked on
a commercial C-to-FPGA compiler project for 2 years. Of course it
would be best if I can just handle it with a makefile :)
You cannot do that today easily.
The French OpenGPU project -funded by French public money http://www.competitivite.gouv.fr/spip.php?article581 (in which
I will be a partner)- will start in january 2010 to deal with such issues (probably with OpenCL, not CUDA). There won't
be usable results soon (and I have no idea if at end of the project, there will be a simple solution to your problem).
You could try to help the OpenGPU partners involved. Ask Emmanuel Chailloux (in
CC).
If you need today to call a CUDA kernel from Ocaml, you have to use C!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] linking errors involving cpp files
Jan Kybic wrote:
On Tue, Dec 15, 2009 at 2:50 PM, Aaron Bohannon wrote:
Thanks for the tip. This does resolve the missing caml symbols (even
when naming the file with a cpp extension). However, my real program
actually uses some C++ features. I think I could convert it to a real
C program, but I assumed there would be some other way.
What you can do is to create a thin C layer between your Ocaml and C++ code.
I am including a very simple code - an interface to the Cubpack
library in Ocaml.
In addition of all the other good answers, you could look at how some existing
C++ open-source libraries interface to Ocaml.
Both the Parma Polyhedra Library (PPL, under GPLv3 licence), at http://www.cs.unipr.it/ppl/ and the Low Level Virtual
Machine library (LLVM, under a BSD-like licence) at http://llvm.org/ are free libraries, coded in C++, interfaced to Ocaml.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] Binding C libraries which use variable arguments (stdarg.h)
Adrien wrote:
Hi,
I am currently trying to bind a C function that takes variables
arguments, like foo(int a, ...). I can't find how to make a C stub for
that function.
I am assuming that the a is the number of actual arguments, so you call
foo(3, x, y, z)
foo(5, t, t+1, t+3, 0, 4)
foo(0)
Any other idea? Hint^WPointer? (sorry for the bad joke ;-) )
First, you could suppose that the a has a reasonable limit, say 100.
Then you could generate the glue code for each value of the argument a.
I mean generate ocaml code like
external f0: void -> uit = "f_0"
external f1: int -> unit = "f_1"
external f2: int -> int -> unit = "f_2"
external f3: int -> int -> int -> unit = "f_3"
let f a = match Array.length a with
0 -> f0 ()
| 1 -> f1 a.[0]
| 2 -> f2 a.[0] a.[1]
| 3 -> f3 a.[0] a.[1] a.[2]
| _ -> failwith "too many components for f"
and generate C code for each of f_0 f_1 ...
and call f with an array ...
The specialized code generator is reasonably written in Ocaml
There are more crazy variants, including
try Ocaml varargs like Pierre Weis did in printf.ml. For plain mortals
like me this is white magic.
Assuming a Linux system, you could lazily generate the glue code and
invoke dynamic linker on it. So the general case would be to call the
code generator.
Time to go to bed. I am saying lot of non-sense.
Bye!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] OCaml and Boehm
Lukasz Stafiniak wrote:
It is a large application. They debate whether to use Boehm or smart
pointers. They already have embedded Scheme (Guile) and are about to
embed Python. (Guile is said to be Boehm-compatible, in some sense,
from the next version.) It is possible that Boehm is a no-way for
them, I asked here to investigate this.
My advice is always to avoid mixing several garbage collection
techniques or implementations inside the same program.
I am not sure "they" are right in embedding both Guile & Python inside
the same program. I would really avoid doing that, especially if the
application is long-running or has to be reliable.
Did you consider having a separate Ocaml program (& perhaps also a
separate Python program) which communicates with that application using
some communication channel (be it a pipe, a socket, IPC or Posix shared
memory, ...) which at least provides a separation between various GCs
and address spaces...
From what you are suggesting, "your" application seems to be a big
spaghetti system, very brittle and hard to maintain. I do know that
these are very common, but I won't like to be at your place... because
you describe a realistic, but quite nasty, situation (probably more a
management issue than a technical one).
But beware of one stuff: GC bugs are hard to find! A single bug could
mean weeks of efforts!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] OCaml and Boehm
Lukasz Stafiniak wrote:
Hi,
Is the OCaml runtime Boehm-safe? That is, can it be run with Boehm
turned on and traversing OCaml's heap? (So that the OCaml heap can
provide roots to Boehm.) And if not, could it be patched to make it
Boehm-safe in this sense?
Probably not. Because I am not sure of what you mean by Boehm-safe,
since Boehm's GC is conservative and do not make much promises.
And very probably, Ocaml runtime cannot realistically be make Boehm-safe
or even Boehm compatible.
There is a reason for all this. The major strength of Ocaml runtime is
its robustness and its efficiency. The efficiency of Ocaml GC is of
paramount importance (it supports very high allocation rate, which is
out of reach for the Boehm collector; and big allocation rate is typical
of most functional programs; the typical allocation speed within the
Ocaml runtime is at least one or two order of magnitudes faster than
that of GC_malloc; a typical GC_malloc is by itself a bit slower than a
libc malloc.).
However, it could happen that you might run some Boehm GC code inside
Ocaml if you are lucky. You should be sure that no pointer go from
GC-Boehm zone into Ocaml zone.
But your question is really too vague. What is the Boehm-GC based code
you want to run within an Ocaml application, and what is that application?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] PowerPC 405
Gregory Bellier wrote:
Hello Basile, thank you for your reply.
Yes, it will run Linux. It will have the uclibC or even the lib C.
The best case is to run native code for better performance. We'd like
to cross-compile for the PowerPC.
I'm not a FPGA expert, I'm asking questions for a colleague who works
on it.
From what you're saying, it should work properly because of the
non-exotic environment thanks to Linux. Am I correct ?
Probably yes. A few years ago, I had a Powerbook G4 with a 32 bits
PowerPC running Linux, and Ocaml did compile and run fine, even in
native mode. Of course, I understand that your ocaml code runs inside an
application in linux user mode (not inside the kernel!).
I would expect you might have minor issues in configuration or
whatsover. I suppose you have enough RAM (and I have no idea what that
means exactly on your system).
Please publish the patches you'll need to implement your solution.
But I never tried all that, so take all my saying with a big grain of salt.
BTW, I'm curious: what kind of embedded application do you want to code
in Ocaml for what sort of device or system?
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] PowerPC 405
Gregory Bellier wrote:
Hi everybody.
Do you know if it is possible to compile caml code on a PowerPC 405
from the Vertex 4 family ?
We'd like to put this processor in a FPGA.
On the Caml's website, it is written "PowerPC" but is it only for
Macintosch ?
That is probably not so hard if your processor runs some Linux kernel,
or if you want to run only ocaml bytecode (not native).
The point is in what kind of runtime environment will your Ocaml run?
Also, what is your development toolchain? Are executables in ELF format? ...
What is your knowledge of Ocaml internals (notably the stdlib, the
runtime C API)?
Do you have a usual C lib?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] Debugging a C / Ocaml interface problem
Hello All
John Whitington wrote:
int fromFile(char* filename)
{
return(Int_val(caml_callback(*caml_named_value("fromFile"),
caml_copy_string(filename;
}
You need to follow Ocaml strong garbage collection related rules for
coding in C.
Are you aware of what a garbage collector is for precisely, how a
copying GC works, what exactly are local and global roots?
Reading a few paragraphs could help a lot to get a big picture. Please
read at least
http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
Then read again chapter 18 [interfacing C with Ocaml] of the manual
http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html
The major rule is that every allocated value should be an Ocaml root.
Try coding instead // untested!
int fromFile (char* filename)
{
CAMLparam0;
CAMLlocal3(fromfil_v, filnam_v, res_v);
fromfil_v = *caml_named_value("fromFile");
filnam_v = caml_copy_string(filename);
res_v = caml_callback(fromfil_v, filnam_v);
CAMLreturnT(int, Int_val(res_v);
}
Hope this helps.
Don't forget that Ocaml (minor) garbage collector is a copying
generational garbage collector, and read enough material to understand
what that is meaning.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] - Convert Caml to C/C++, C#, PHP, etc -
Kuba Ober wrote:
Side note: is there an Ocaml bytecode-compiler written in Ocaml
somewhere?
I'm pretty sure the vast majority of the standard Ocaml bytecode
compiler is written in Ocaml. The same is probably not true for
the bytecode VM.
Chicken-and-egg question: how was it bootstrapped, at the dawn of time?
Some very ancient, embryonic, subset of Caml was initially coded in
LeLisp. You probably won't find any source of them (neither the first
Caml - which was a ancestor of CamlLight - not the LeLisp
implementation, which was proprietary, running on some obscure machine,
perhaps MITRA15 or whatever).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] Writing to argv[0]
Dave Benjamin wrote:
Hi,
Is there any way for an OCaml program to change its name in the process
table? Assigning to Sys.argv.(0) has no effect.
Write a C wrapper for that. And this trick seems Linux specific (it has
no sense in Posix) -maybe working on few other OSes.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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 code compile time question
Raj Bandyopadhyay wrote:
Hi all
I am implementing a language by generating OCaml code for input source
and using the OCaml native code compiler. However, I've run into a
strange problem.
On using my code generator on a large program, I generate a file containing
about 75K lines of OCaml.
The native code compiler takes more than 30 *minutes* to compile this file! The bytecode compiler takes about 5 secs.
It depends of your langage and of the code you are generating, but maybe
Ocaml is not the right tool for that. Did you consider stuff like LLVM
http://llvm.org/ or C-- http://cminusminus.org/ both designed to be
languages to be generated by a program (not to be coded in by a human)?
It could also be that you are generating huge functions. Avoid
generating huge functions (and you'll get the same kind of troubles if
you generate huge C functions).
All the low level code generation issues and algorithms (e.g.
instruction scheduling, register allocation) are violently non linear.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] thousands of CPU cores
Jon Harrop wrote:
Ironically, given the hype surrounding functional programming for parallelism,
all open source FPLs were left behind. On Linux, even the future prospects
are bleak: no tail calls on the JVM, prohibitively difficult to implement an
efficient concurrent GC yourself and Mono is going nowhere.
It is not specific to Linux (and probably not even to *opensource*
functional programming languages; I believe proprietary functional
languages implementations face the same problems). In my perception,
functional programming requires *blindly fast* memory allocation for
values which are becoming garbage quickly. This seems a property of
functional programming (and more generally any programming style
discouraging side effects), in other words functional programming need
very efficient garbage collectors (A.Appel wrote stuff on this almost
20? years ago).
And coding efficient parallel generational collector is really hard, at
least on current hardware (ask Damien Doligez). Perhaps chip makers
might acknowledge the importance of supporting read & write barriers on
the bare metal (which seems easy, more a managerial/merket decision than
a technical one; on x86 we've got MMX, then SSE1, ... SSE5, AVX but no
additional instructions for read & write barriers...). There is a
chicken&egg issue here (no hardware assist for good GC, so no good
functional language implementation on multicore).
As a case in point, I suggest an experiment (which unfortunately I don't
have the time or motivation to realize). Replace the current Ocaml GC
either in bytecode or in nativecode ocaml by Boehm's collector (which is
multithread compatible). I'm sure you'll get a significant performance
loss, but you should gain the true multi-threading feature. Of course,
synchronization issues will appear, very probably in application code
(and some C function wrappers).
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] Re: thousands of CPU cores
Sylvain Le Gall wrote:
On 10-07-2008, Gerd Stolpmann <[EMAIL PROTECTED]> wrote:
In Ocaml you can exploit multi-core currently only by using
multi-processing parallel programs that communicate over message passing
(and only on Unix). Actually, it's an excellent language for this style.
Why only on Unix ?
Rumors (and my remembering of old benchmarks) say than inter-process
communication -using pipes, fifos, or unix sockets- on recent Unix
systems (in particular Linux) are significantly faster than the
equivalent Windows counterpart.
Also, I don't know Windows but it could happen that some system calls in
Windows useful for communication might be missing in Ocaml (but I really
don't know; I never coded on Windows).
Besides, who want to code parallel program with Ocaml or Jocaml on non
Unix plateforms? :-) :-)
And I am not sure that Ocaml has been ported to non-unix free
software... Does Ocaml runs on Hurd, or Syllable, or EROS?
But don't trust me on all that. I am only familiar with Unix. Ask some
more knowledgable guy!
(I am still not sure that the current implementation of Ocaml would
nicely run on a thousand cores machine; and I am not sure that such a
machine would run the current Linux)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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] marshalling objects
Jacques Le Normand wrote:
hello caml list,
if I marshal an object of class c and I write the result in a file
foo.txt and, later on, I add methods to c, can I read the object in
foo.txt and call the new methods on the object?
First, a *.txt extension for a binary file (written thru Marshal.*
functions) is very confusing.
Second, marshalling of any closures (including methods shared by
objects) can only be unmarshalled by the exact same binary. So if you
add/change code, it should not work.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
___
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
