Hello
Here is the latest Caml Weekly News, for the week of January 09 to 16, 2007.
I have been trying to do this too and have finally managed to get wxHaskell 0.9.4 working with wxWidgets 2.8.0. My guide + code to do it can be found here: http://riftor.g615.co.uk/content.php?view=53&type=2 I hope that it works for you too, it should do! Let me know if you have any problems, Dominic Orchard
to get coloured output on a linux terminal, you can do something like
echo -e "\033[31m This is now red"
How can I do this with OCaml? The following doesn't work
print_string "\033[31m blabla"
Daniel de Rauglaudre answered:print_string "\027[31m blabla" Character codes are in decimal in OCaml, not in octal.Goulagman said and Philippe Wang added:
> It's because, for Ocaml, the escape sequence \0xx matches the > ASCII character xx in decimal, not in octal. > print_string "\027[31m blabla" works fine Well, what you said is true, still it's not meant to be explained like this ! (well I guess and hope so) The backslash in a character or string sequence introduces a decimal number between 0 and 255 with *exactly* 3 digits. You can also write special characters in hexadecimal : "\xFF" = "\255" ;-)Christophe TROESTLER also answered the OP:
You can also use ANSITerminal http://math.umh.ac.be/an/software.php#x4-90008.
Having read a thread about a real-time ray tracer by Jacco Bikker rendering the Stanford bunny at 7fps, I decided to try rendering the bunny from OCaml. Chucking it into an OpenGL display list gets me about 450fps on my machine (2.2GHz AMD64, GeForce 7900GT) with 16x FSAA for only 85 lines of code: http://www.ffconsultancy.com/free/bunny/ I'm working on shadows...
I've been working on a raytracer for awhile, and recently decided to remove a lot of experimental code that doesn't work well anyways and release the rest under the gpl version 2. Currently, glome renders some of the scenes from the standard procedural database (http://www.acm.org/tog/resources/SPD/). I thought that, aside from the practical utility of generating pretty pictures, some people on this list might be interested in using it to benchmark the quality of code generated by various versions of the ocaml compiler. Supported primitives are spheres and triangles. It uses a kd-tree as an acceleration structure. There is limited joystick support (moving works fine, but turning can have unexpected results) for those patient enough to tolerate the low framerates. I use lablgl for screen output, but there aren't any other libraries required outside of the standard ocaml distribution. I'm not a very experienced ocaml programmer, so I'm sure there are some things I'm doing inefficiently just because I don't know better. I welcome any suggestions that would make my code faster, or reduce the memory footprint of my scene representation. There is a discussion thread about glome over at ompf.org: http://ompf.org/forum/viewtopic.php?t=336 Source code download is here: http://syn.cs.pdx.edu/~jsnow/glome/Jon Harrop said and Jim Snow answered:
> > I've been working on a raytracer for awhile, and recently decided to > > remove a lot of experimental code that doesn't work well anyways and > > release the rest under the gpl version 2. Currently, glome renders some > > of the scenes from the standard procedural database > > (http://www.acm.org/tog/resources/SPD/). I thought that, aside from the > > practical utility of generating pretty pictures, some people on this > > list might be interested in using it to benchmark the quality of code > > generated by various versions of the ocaml compiler. > I have altered the code to be more idiomatic OCaml, although it is still very > not-OCaml. I've removed OOP from the hot path and virtual function dispatch > has been replaced with pattern matches. > http://www.ffconsultancy.com/temp/glome.tar.bz2 > The code is now 1390LOC instead of 1746 (20% shorter). Performance is also > better. Building the Kd-tree is down from 7.0s to 6.3s. Sorry I'm a bit slow about replying; I was off trying to implement an nlogn kd-tree compiler. Your version seems to have sped up the raytracing by about 10%. However, I think I am going to stick with my approach for the time being for the sake of maintainability; I don't think putting all the ray-intersection code together in one mutually-recursive is going to make the program easy to modify in the future. I am tempted though. I might also give recursive modules a try. (For those just joining us, my dilemma is thus: my raytracer defines ray-intersection tests for a number of types of geometry. Aside from my conventional primitives, triangles and spheres, I also have a number of more abstract primitives like groups (a container for primitives, so I can treat, say, a collection of triangles as if it were one triangle) and kdtrees (semantically similar to a group, but with an axis-aligned binary space partitioning scheme). In order for this latter type to work correctly, they need to have a ray-intersection function that calls the ray-intersection functions of their contained objects. Contained objects may also be groups or kdtrees, hence the necessity of mutual recursion. Due to the lack of mutual recursion across source files, I had resorted to using objects; all primitives inherit from a base type that supports a ray-intersection test. Unfortunately, this incurs noticeable overhead. Jon Harrop's solution was to write one big recursive ray-intersection test that pattern matches on the type of supplied primitve, and evaluates the proper test.) > I have many suggestions for what to do next: > 1. Use records instead of float arrays: stronger type inference, more > concise, purely functional. I did try this after looking at your ray tracer; however, this did not significantly affect performance, except in cases where I needed to access vectors like an array (with an integer index), and none of the tricks I could think of to do that were as fast as plain array access. This created a bottleneck in my kd-tree traversal code (where high-performance ray tracers tend to a significant portion, if not most, of their time). See http://ompf.org/forum/viewtopic.php?p=2709&highlight=#2709 > 2. Get rid of almost all mutation. The core ray tracer has no reason to use > mutation and all those refs and assignments are confusing and probably slow. If you mean the place where I pass a "traceresult" record into each rayintersection test, I agree that that is definitely ugly, but at the time it gained me a noticeable performance increase (I think it was around 5% or so.). However, that was under a different workload; that was before I implemented the kdtree and I was doing many more ray-object intersections. I was also optimizing for a different set of ray-intersection tests that returned more information, and I was keeping the results around much longer (I couldn't throw them away until the whole image was done rendering). I didn't want them to sit around so long they get promoted to the major heap, only to get garbage collected much later. It's possible those concerns aren't valid for the way the raytracer currently works. I might try reverting that optimization one of these days and seeing what happens. If assignment to mutable fields bothers you, I suggest you avert your eyes from the clr.ml file. I don't really have a good excuse for that code, other than it seemed like a good idea at the time and I haven't gotten around to re-writing it. > 3. Restructure the program again: put independent definitions related to > triangles in Triangle, put related definitions like the intersection routine > in Intersect. > Primarily, the program is far too verbose and convoluted. As an algorithm, > ray tracing is very functional in nature. I think the functionality provided > by this program could be achieved in half as many lines of code. It could > also be a lot faster. You're right that the program could be cleaner and much shorter, but I'm relatively new to functional programming, and I haven't figured out all the shortcuts. When I'm feeling lazy and I see something that seems like it should be a loop I'll usually use a loop, whereas I could have used recursion and saved myself some typing. I like that ocaml doesn't force you to program in a particular way. I also don't think "lines of code" is always a good way of measuring code quality. Oop, for instance, adds a lot of cruft (which is one reason I dislike java; I don't like being forced to do all that typing), but I used it because it gave me mutual recursion without having to stick all my mutually recursive functions together in one file, and therefore I can group my code into smaller, more manageable units. (I won't dispute that your version is faster.) > > Supported primitives are spheres and triangles. It uses a kd-tree as an > > acceleration structure. There is limited joystick support (moving works > > fine, but turning can have unexpected results) for those patient enough > > to tolerate the low framerates. > > I use lablgl for screen output, but there aren't any other libraries > > required outside of the standard ocaml distribution. > Rather than rendering dots, you could generate a polygon mesh. To make > things more interesting, you could include the depth value in the mesh, so > when you rotate the scene it gets distorted by OpenGL without needing to ray > trace anything. Hm, I'll bet you'd like to know what the 2/3 of the code I didn't publicly release does :) (It doesn't do quite what you suggest, but I do draw the final image to the screen as an adaptive triangle mesh (using the ROAM algorithm).) Your bunny renderer looks interesting. It's been on my to-do list to contrive some way to load more interesting datasets than the standard procedural database.brogoff then added:
I haven't coded a ray tracer in a long time, and the one I did was for a college class, but my recollection is that even in C (the implementation language I used) the design used classes/objects for the primitives, so that one could add new primitives and the only piece of code that would need modification would be the interpreter of scene description files. I think using classes for that is the right approach. I'm sure you could do it in a more coreish ML fashion without even using recursive modules, say by emulating the OO in C approach with ML records of functions, but it won't be any faster and will be uglier, since the class system provides a kind of generalized polymorphic record. This is a nice example for discussing the merits of OO features, and less complex than the expression problem. A competitive "non-OO" approach should provide easy extensibility along the same axes as the OO one. I admit I don't see the need for cross file recursion here.
I've been wondering what is the best way to write a C function that
takes a variable number of value arguments. Lets say, for example,
that I was writing a function that took an object, a string
(specifying a method on the object), and a variable number of
arguments to pass to the method. The function would then construct an
array (with the object being the first element) from these arguments
and pass it along to caml_callbackN. This function, of course, would
only ever be called by other C functions.
The thing that I guess I'm caught up on is the fact that I cannot
directly apply CAMLparam to these variable arguments. Some calling
conventions place all arguments on the stack, in which case CAMLparamN
could be used (as long as you knew whether the stack was building up
or down). However, some do not do this (the AMD64 calling convention,
for example, puts the first 6 arguments in registers, the rest on the
stack).
I guess the real question is: is it even necessary to worry about this?
The function, as I said, will only ever be called from other C
functions (who have already designated these values as being
params/local to themselves, assuming they are written correctly). I
seem to recall reading somewhere that if you write a function that
will only ever be called from other C functions that have already
registered the values (via CAMLparam/CAMLlocal), then it's
unnecessary to do it again. The function doesn't allocate any new
values either, so it shouldn't trip the GC anyway, right? The function
should, therefore, be something like this:
value func(value obj, char *method, int n, ...)
{
va_list ap;
int i;
value *args = calloc(n + 1, sizeof(value));
value r;
args[0] = obj;
va_start(ap, n);
for (i = 0; i < n; i++)
args[i + 1] = va_arg(ap, value);
va_end(ap);
r = caml_callbackN(caml_get_public_method(obj, hash_variant(method)),
n + 1, args);
free(args);
return r;
}
Should probably check calloc for success and maybe throw an exception
if it failed... Which actually brings me to another quick question: if
I throw an exception, say caml_failwith("..."), is it necessary to
still call CAMLreturn after it? Or will the exception cause the
function to exit?
Is it an invalid assumption that it is unnecessary to bother with the
CAMLparam/CAMLlocal stuff since there's nothing to trip the GC? If so,
what is the best way to handle all the CAMLparam/CAMLlocal stuff? For
example, CAMLlocalN(args, n + 1) is invalid because C does not allow
you to declare dynamic arrays. Looping over the arguments with
va_start/for loop/va_arg and calling CAMLparam on them is also invalid
because it would be declaring the caml__root_##x variable within the for
loop. I have typed up some code that should work if it is necessary,
but it's messy and if CAMLparam is ever changed, it's likely I'll need
to change my code too. I want to avoid that.
One last quick question: is the line "args[i + 1] = va_arg(ap, value);"
above legal? args[] is an array of value and va_arg(ap, value) will
return a value. So, essentially, it's the same thing as the assignment
in the following example:
value func(value v1)
{
value v2 = v1;
...
}
I know values are just pointers so it is syntactically correct, but
what I'm asking is: is it safe to do? Should I be using some function
instead to create a copy of the value?
Thanks in advance for any insight!
Richard Jones suggested:The CAMLparam/CAMLlocal/CAMLreturn/CAMLxparam macros are pretty simple to understand. I suggest you take some simple code using these macros, run it through cpp, and have a look at what these macros actually generate. You will be able to make your own (possibly non-portable) variations which update caml_local_roots etc. directly. If that is necessary.Bob Matcuk then asked and Chris King answered:
Short answer: your function is okay, but not for the reasons you
state. Long answer:
> I guess the real question is: is it even necessary to worry about this?
> The function, as I said, will only ever be called from other C
> functions (who have already designated these values as being
> params/local to themselves, assuming they are written correctly).
This doesn't matter. The purpose of CAMLparam/CAMLlocal is twofold:
first, to declare that a particular value shouldn't be garbage
collected (which, as you point out, the other C functions take care
of). Secondly (and more importantly in this case), they inform the
garbage collector of the all roots which it may need to update in the
event that it relocates a block. If you don't use CAMLparam/CAMLlocal
and a GC cycle occurs, there's a chance that a block which one of your
values points to will be moved, and your value will become invalid.
> I
> seem to recall reading somewhere that if you write a function that
> will only ever be called from other C functions that have already
> registered the values (via CAMLparam/CAMLlocal), then it's
> unnecessary to do it again.
AFAIK this is incorrect (because blocks can be relocated). The only
time it is safe not to register values is if your code does not assume
that the contents of a value are valid after a call which could trip
the GC.
> The function doesn't allocate any new
> values either, so it shouldn't trip the GC anyway, right?
True, false. caml_callbackN executes arbitrary code, which may or may
not trip the GC. hash_variant and caml_get_public_method are
questionable also (since they return values), but looking at the Caml
source code, it seems that they are safe (but I don't think the docs
guarantee this).
(BTW you should use caml_hash_variant rather than hash_variant; the
comment for caml_get_public_method in caml/mlvalues.h should probably
be updated to this effect also.)
> Should probably check calloc for success and maybe throw an exception
> if it failed...
You could do this with caml_stat_alloc and caml_stat_free (in
caml/memory.h). These are equivalent to malloc/free but throw Caml's
out-of-memory exception if they fail. However in this case, I would
simply declare args as an array. Otherwise, if the callback throws an
exception, args will not be freed unless you explicitly catch
exceptions via caml_callbackN_exn, free it, and then re-raise the
exception.
Note that if you have no control over the C functions higher up the
call chain (say an external library which calls your function), they
could exhibit similar problems if they are unaware of the possibility
of your function raising an exception. The best thing to do in such a
case would be to return an error condition if possible, or at the very
least, print a warning and return or exit gracefully (the functions in
caml/printexc.h help here).
> Which actually brings me to another quick question: if
> I throw an exception, say caml_failwith("..."), is it necessary to
> still call CAMLreturn after it? Or will the exception cause the
> function to exit?
The exception causes the function to exit. You can see which
functions act like this in the header files by looking for the
"Noreturn" attribute at the end of their declaration.
> Is it an invalid assumption that it is unnecessary to bother with the
> CAMLparam/CAMLlocal stuff since there's nothing to trip the GC? If so,
> what is the best way to handle all the CAMLparam/CAMLlocal stuff?
Yes, it is an invalid assumption, because your code may in fact trip the GC.
BUT
Look over the function you wrote carefully. Notice that values obj
and *args are used only before the call to caml_callbackN, and that
the value r is used only after that call. Your function is indeed
safe, only because you don't use after the "unsafe" call any value
which was initialized before.
Of course, for the sake of maintainability, I wouldn't in general
endorse such eliding of CAMLparam/CAMLlocal. I'd recommend putting a
big ol' warning in there :)
> For
> example, CAMLlocalN(args, n + 1) is invalid because C does not allow
> you to declare dynamic arrays.
K&R C doesn't, but GCC does. If you're using another compiler or some
compatibility flag, then the alloca function (usually found in
alloca.h) should do the trick. It allocates space on the stack
exactly like an array declaration does, so the guts of CAMLlocalN
should apply to it.
> I know values are just pointers so it is syntactically correct, but
> what I'm asking is: is it safe to do? Should I be using some function
> instead to create a copy of the value?
Copying values with assignment is perfectly legal, provided the
locations to which they are copied are registered with the GC first
(just like any other value).
Hope this was able to clear things up, I've hit many of these bumps
myself while learning to write extensions. The best thing to remember
is that Caml's GC is not a reference counter but a generational
collector and can move blocks from right under your nose. Then the
reasons to use CAMLlocal/CAMLparam become clear.
Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).
:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1
zM
If you know of a better way, please let me know.
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.