Re: [Caml-list] Ocaml debugger under Windows
On Wed, Feb 6, 2008 at 9:12 PM, Xavier Leroy <[EMAIL PROTECTED]> wrote: [...] > Actually, I would be happy with a Win32 implementation of Unix.select > that works over any combination of sockets and file descriptors. > Unfortunately, it looks like we'd need a gross hack involving threads, > WaitForMultipleObjects() and select(), but if someone comes up with an > implementation that isn't too gross, I'll be interested. OK, I have found some spare time and finally done that. Both select() and ocamldebug now work on Win32. Console, pipes, disk files, sockets can now be tested for reading; write and exceptional condition lists are not supported yet (write probably cannot be implemented, at least Cygwin and GDB don't care, but exceptional conditions probably can if someone explains me an expected semantics). The patch is attached. Please let me know what do you think of it. - Dmitry Bely win32_select_debug.diff Description: Binary data ___ 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] Core has landed
On Sat, May 3, 2008 at 1:39 AM, Yaron Minsky <[EMAIL PROTECTED]> wrote: > We are proud to announce the first public release of core, Jane > Street's own alternative to OCaml's standard library. We use this > library as the base for our own development, and we hope people on the > outside will find some use for it as well. As usual, Windows is not supported? - Dmitry Bely ___ 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: Re : [Caml-list] Road to native windows OCaml...
On Tue, Oct 14, 2008 at 1:41 PM, Adrien <[EMAIL PROTECTED]> wrote: >>> Can I ask what the motivation is for this (out of interest, not >>> criticism)? >> >> Maybe because if you want to distribute executables using cygwin you >> have to release your code under a GPL compatible license [1]. >> >> Daniel >> >> [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 > > I would give another explanation : cygwin is big and slow. > A base cygwin install is at least 1GB (when fully configured, after > carefully reviewing *each* package), a regular one is 2GB. XP itself > is not that big, I've not seen many applications that big, only CAD > ones. No way. My Cygwin installation (quite enough for building Ocaml and many other things) is just 274Mb. Not a big deal. > Cygwin is also slow, though it will probably not impact a student use > (networking is slower due to the translation, I have mldonkey in > mind). What exactly is slow when building Ocaml? make? Can you prove that? > ./configure are also painfully slow, the need to run several > small commands where startup time is more important than runtime gives > cygwin no chance [1]. Where did you find any ./configure script used for building the native Win32 Ocaml? - Dmitry Bely ___ 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: Road to native windows OCaml...
On Wed, Oct 15, 2008 at 1:37 AM, Kuba Ober <[EMAIL PROTECTED]> wrote: >> > I've looked briefly at what it'd take to have OCaml >> > fully working natively (with mingw/VS), without any Cygwin >> > needed for compilation. >> > >> > 3. I need to look at the bytecode debugger and figure out why doesn't it >> > work on non-Cygwin builds. >> >> OCaml 3.11 will ship a debugger for Win32 (mingw/msvc). Everything >> should be working except the replay part which depends on fork. >> >> I have worked on this, based on a patch provided few months ago by >> Dimitry Bely. All in all, I have reimplemented "select" for win32 && >> pipe. > > Why do we need fork? I need to look at the code... http://caml.inria.fr/pub/ml-archives/caml-list/1999/03/f44178e212e78826bcbdee52ddf6fd91.en.html Concerning bytecode debugging under Windows, the major issue is the way our debugger performs periodic checkpointing of the running program (in order to implement reverse execution). We just use the Unix fork() system call, which does everything we want (checkpointing of memory and file descriptors, using lazy copy-on-write to minimize copying). - Dmitry Bely ___ 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] Road to native windows OCaml...
On Wed, Oct 15, 2008 at 1:38 AM, Kuba Ober <[EMAIL PROTECTED]> wrote: > On Tuesday 14 October 2008, David Allsopp wrote: >> Kuba Ober wrote: >> > I've looked briefly at what it'd take to have OCaml >> > fully working natively (with mingw/VS), without any Cygwin >> > needed for compilation. >> >> Can I ask what the motivation is for this (out of interest, not criticism)? >> It only takes a matter of minutes to install Cygwin and it can be >> completely ignored once OCaml is compiled (I don't even have Cygwin in my >> PATH). > > The motivation is that I'm allergic to Cygwin. And you're not quite right that > Cygwin is not needed later on: it is if you need to generate native code, > or link with native code. No, if you use MSVC-build Ocaml it's not needed at all. - Dmitry Bely ___ 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: Road to native windows OCaml...
On Wed, Oct 15, 2008 at 6:35 PM, Kuba Ober <[EMAIL PROTECTED]> wrote: > On Wednesday 15 October 2008, Dmitry Bely wrote: >> On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <[EMAIL PROTECTED]> wrote: >> >> For example, if you download and install OCaml MSVC from >> >> http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell, >> >> you can perfectly compile a native application (well I have not done it, >> >> but I will try tomorrow ;-) >> >> >> >> All you need is "cl", "ml" and "link" I think (all are MSVC tools). >> > >> > And you need masm too, right? >> >> "ml" is just that masm. It's included into MS Visual Studio >> Professional edition and up. For Standard edition and below there is >> free www.masm32.com. > > masm32 has an absolutely horrendous license -- have you read it? It's > crazy. OK, I was wrong: masm (ml.exe) is already included into all non-free Visual Studio 2008 editions and into free Express edition since 2008 SP1. So now it's not a problem at all. > ml of course should be used if available, but otherwise nasm is there and > is what should be used whenver masm is called for and unavailable. Nasm and masm syntaxes differ. You cannot simply interchange them. - Dmitry Bely ___ 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: Road to native windows OCaml...
On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <[EMAIL PROTECTED]> wrote: >> For example, if you download and install OCaml MSVC from >> http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell, >> you can perfectly compile a native application (well I have not done it, >> but I will try tomorrow ;-) >> >> All you need is "cl", "ml" and "link" I think (all are MSVC tools). > > And you need masm too, right? "ml" is just that masm. It's included into MS Visual Studio Professional edition and up. For Standard edition and below there is free www.masm32.com. - Dmitry Bely ___ 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] What does Jane Street use/want for an IDE? What about you?
On Mon, Oct 20, 2008 at 5:19 PM, Kuba Ober <[EMAIL PROTECTED]> wrote: > I have questions to the kind folks at Jane Street, > and others who use OCaml for commercial/non-research > development: what do you guys use for your development > environment? What would be the minimal set of functionality > that would make you happy for an IDE? What are killer features > you dream of? I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/). It's Eclipse plugin so Windows is fully supported (including graphical debugging). IMHO it's (almost) ready for commercial development. Many features are very convenient: hyperlink jumps, code outline, type tooltip on mouse hoovering, completion etc. Give it a try. - Dmitry Bely ___ 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] Portable Ocaml multiprocessing?
There are numerous environments/libraries that support process-based Ocaml multiprocessing: jocaml, OCamlP3l, OcamlMPI (and probably others). Do I get it right that all of them are Unix-only? - Dmitry Bely ___ 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 wrappers for Ocaml functions
On Tue, Apr 14, 2009 at 3:51 PM, Tim Leek wrote:
> Hello. Not sure if this should have gone to beginners or the regular
> list. Also not sure if its been answered before. If so, please
> redirect me! I did a bunch of searching both on google and in the lists
> and couldn't find the answers I needed. So here goes.
>
> I have written a blob of code in Ocaml that I like very much. I'd love
> to keep it in ocaml and not have to worry about things like memory leaks
> and so on. However, much of what I do is in C and can't be in Ocaml.
> So I am investigating packing my nice Ocaml code into a library and
> writing C bindings so that I can talk to it.
>
> Virtually all of the tutorials out there and documentation cover how to
> create Ocaml bindings to a C library. I don't want to do that. The few
> examples I have found that are relevant are toy ones. How to write C
> bindings to an Ocaml "fib" function, e.g. In particular, I have found
> none that cover how to obtain pointers to OCaml function return values
> that are not strings or ints, how to store them in C-land, and how to pass
> them back to Ocaml as parameters.
>
> Let's take as a concrete example the following: creating C bindings for
> a simple hash table mapping string keys to integer values. If I can
> generate bindings for this that work I should be able to do so for the
> library I really care about.
>
> Here's what I put together for the hash table slightly-less-than-toy
> example. It doesn't even compile. [Oddly, with very similar incantations
> my own code does compiles but then segfaults inside one of the Ocaml fns.]
> Any help much appreciated!
>
> -Tim
>
>
> 1. The implementation.
>
> % cat ht.ml
>
> type ht = (string,int) Hashtbl.t
>
> let create () : ht = Hashtbl.create 100
>
> let add (table:ht) key valu = Hashtbl.add table key valu
>
> let mem (table:ht) key = Hashtbl.mem table key
>
> let remove (table:ht) key = if (Hashtbl.mem table key) then
> Hashtbl.remove table key
>
> let _ = Callback.register "create" create
>
> let _ = Callback.register "add" add
>
> let _ = Callback.register "mem" mem
>
> let _ = Callback.register "remove" remove
>
> 2. The wrappers
>
> % cat ht_wrap.c
> #include
> #include
> #include
>
> void *ht_create (void) {
> static value *create_closure = NULL;
> if (create_closure == NULL)
> create_closure = caml_named_value("create");
> return ((void *) (caml_callback(*create_
> closure, Val_unit)));
> }
>
> void ht_add (void *ht, char *key, int val) {
> static value *add_closure = NULL;
> if (add_closure == NULL)
> add_closure = caml_named_value("add");
> caml_callback3(*add_closure, (value) ht, caml_copy_string(key),
> Val_int(val));
> }
>
> void ht_mem (void *ht, char *key) {
> static value *mem_closure = NULL;
> if (mem_closure == NULL)
> mem_closure = caml_named_value("mem");
> caml_callback2(*mem_closure, (value) ht, caml_copy_string(key));
> }
>
> void ht_remove (void *ht, char *key) {
> static value *remove_closure = NULL;
> if (remove_closure == NULL)
> remove_closure = caml_named_value("remove");
> caml_callback2(*remove_closure, (value) ht, caml_copy_string(key));
> }
>
>
> 3. Header file for those wrappers
>
> % cat ht.h
>
> void *ht_create (void);
> void ht_add (void *ht, char *key, int val);
> void ht_mem (void *ht, char *key);
> void ht_remove (void *ht, char *key);
>
> 4. The test program, with main() function.
>
> % cat ht_test.c
> #include
> #include "ht.h"
>
> int main (int argc, char **argv) {
> void *ht;
>
> caml_startup(argv);
>
> ht = ht_create();
> ht_add(ht, "foo", 1);
> ht_add(ht, "foo", 1);
> ht_add(ht, "bar", 1);
> ht_remove(ht, "foo");
> }
>
>
> 5. And this is how I am attempting to compile it. Note that error I'm
> getting here is in link. If I add "-lm" it gets less noisy but still is
> mad at me. Why am I having to add math library? Again, help!!
>
> % ocamlopt -output-obj -o ht.o ht.ml
Wrong! You cannot specify ht.o as an output as ht.o is an intermediate
result of ht.ml compilation. Activate -verbose flag and you'll see.
Replace it with something like
ocamlopt -output-obj -o ht_out.o ht.ml
> % ocamlopt -c ht_wrap.c
> % cp /usr/lib/ocaml/3.10.0/libasmrun.a ./ht.a
> % ar r ht.a ht_wrap.o ht.o
> % gcc -o htt ht_test.c ht.a -lcurses
> ht.a(floats.o): In function `caml_ceil_float':
> (.text+0x193): undefined reference to `ceil'
> ht.a(floats.o): In function `caml_atan2_float':
> (.text+0x1ae): undefined reference to `atan2'
(...)
Why simply not to use
ocamlopt -c ht_wrap.c
gcc -o htt ht_test.c ht_out.o ht_wrap.o -L${OCAMLLIB} -lasmrun -lcurses -lm
?
- Dmitry Bely
___
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] Ocamlopt code generator question
For amd64 we have in asmcomp/amd64/proc_nt.mlp: (* xmm0 - xmm15 100 - 115 xmm0 - xmm9: Caml function arguments xmm0 - xmm3: C function arguments xmm0: Caml and C function results xmm6-xmm15 are preserved by C *) let loc_arguments arg = calling_conventions 0 9 100 109 outgoing arg let loc_parameters arg = let (loc, ofs) = calling_conventions 0 9 100 109 incoming arg in loc let loc_results res = let (loc, ofs) = calling_conventions 0 0 100 100 not_supported res in loc What these first_float=100 and last_float=109 for loc_arguments and loc_parameters affect? My impression is that floats are always passed boxed, so xmm registers are in fact never used to pass parameters. And float values are returned as a pointer in eax, not a value in xmm0 as loc_results would suggest. - Dmitry Bely ___ 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] Re: Ocamlopt code generator question
On Wed, Apr 29, 2009 at 8:28 PM, Jeffrey Scofield wrote: > Dmitry Bely writes: > >> For amd64 we have in asmcomp/amd64/proc_nt.mlp: >> >> (* xmm0 - xmm15 100 - 115 xmm0 - xmm9: Caml function arguments >> xmm0 - xmm3: C function arguments >> xmm0: Caml and C function results >> xmm6-xmm15 are preserved by C *) >> >> let loc_arguments arg = >> calling_conventions 0 9 100 109 outgoing arg >> let loc_parameters arg = >> let (loc, ofs) = calling_conventions 0 9 100 109 incoming arg in loc >> let loc_results res = >> let (loc, ofs) = calling_conventions 0 0 100 100 not_supported res in loc >> >> What these first_float=100 and last_float=109 for loc_arguments and >> loc_parameters affect? My impression is that floats are always passed >> boxed, so xmm registers are in fact never used to pass parameters. > > I don't have any experience with amd64, but I have looked at the ARM code > generator of OCaml 3.10.2. The first_float and last_float values there are > used > for unboxed calls to internal float functions--most notably, the C standard > functions like floor(). No - for external C functions loc_external_arguments and loc_external_results are used. And of course unboxed floats can be acceptable there. But my question was about loc_arguments and loc_parameters. E.g. what is the reason to have first_float=100 and last_float=109 for loc_arguments? - Dmitry Bely ___ 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] Assembly labels overflow
On Sat, May 2, 2009 at 3:59 PM, Geoffroy wrote: > I am currently working on a tool which is generating a lot of ocaml code. > The problem comes during compilation : due to the amount of source code or > the length of function, i got some "already define symbol" error when the > camlasm is build. Basically assembly labels appear more than one time. Probably label_counter exceeds 10 and local labels overlap L1x and L2xx labels that ocamlopt uses for some internal purposes. Does your module really need more that 10 labels? What does your code do? > To avoid this i decided to split my generated ocaml code in several small > pack (down to 5 functions by .ml files) and to use the "-compact" option. > With this the problem was push back a little. > > But now i am once again facing this problem and i didn't have any more idea > for it. In theory you can hack ocamlopt, making internally used labels to start from 100 and 200 or more. See files asmcomp//emit.mlp and asmcomp/emitaux.ml. > So i wanted to know if someone got enough knowledge in ocaml internal to > explain me the perfect form for function to minimise the label production > during assembly generation. No, I think it's not possible. If you need to do some action conditionally, how can you manage without jumps and labels? - Dmitry Bely ___ 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] Ocamlopt code generator question
On Tue, May 5, 2009 at 1:24 PM, Xavier Leroy wrote: >> For amd64 we have in asmcomp/amd64/proc_nt.mlp: >> >> (* xmm0 - xmm15 100 - 115 xmm0 - xmm9: Caml function arguments >> xmm0 - xmm3: C function arguments >> xmm0: Caml and C function results >> xmm6-xmm15 are preserved by C *) >> >> let loc_arguments arg = >> calling_conventions 0 9 100 109 outgoing arg >> let loc_parameters arg = >> let (loc, ofs) = calling_conventions 0 9 100 109 incoming arg in loc >> let loc_results res = >> let (loc, ofs) = calling_conventions 0 0 100 100 not_supported res in loc >> >> What these first_float=100 and last_float=109 for loc_arguments and >> loc_parameters affect? My impression is that floats are always passed >> boxed, so xmm registers are in fact never used to pass parameters. And >> float values are returned as a pointer in eax, not a value in xmm0 as >> loc_results would suggest. > > The ocamlopt code generators support unboxed floats as function > parameters and results, as well as returning multiple results in > several registers. (Except for the x86-32 bits port, because of the > weird floating-point model of this architecture.) You're right that > the ocamlopt "middle-end" does not currently take advantage of this > possibility, since floats are passed between functions in boxed state. I see. Why I asked this: trying to improve floating-point performance on 32-bit x86 platform I have merged floating-point SSE2 code generator from amd64 ocamlopt back end to i386 one, making ia32sse2 architecture. It also inlines sqrt() via -ffast-math flag and slightly optimizes emit_float_test (usually eliminates an extra jump) - features that are missed in the original amd64 code generator. All this seems to work OK: beyond my own code all tests found in Ocaml CVS test directory are passed. Of course this is idea is not new - you had working IA32+SSE2 back end several years ago [1] but unfortunately never released it to the public. Is this of any interest to anybody? - Dmitry Bely [1] http://caml.inria.fr/pub/ml-archives/caml-list/2003/03/e0db2f3f54ce19e4bad589ffbb082484.fr.html ___ 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: Ocamlopt code generator question
On Tue, May 5, 2009 at 6:58 PM, Sylvain Le Gall wrote: > On 05-05-2009, Jean-Marc Eber wrote: >> Hi Dimitry, >> >> LexiFi for instance _is_ clearly interested by a sse2 32bit code generator. >> >> One should probably have the following in mind and/or ask the following >> questions: >> >> - it is probably not a good idea to support both backends (sse2 and old >> stack fp >> i386 architecture). It will be necessary to make a choice (especially taking >> in >> account the limited INRIA resources and the burden of already supporting >> different windows ports). >> > > Maybe this point can be discussed. I think 3 ports for windows is a bit > too much... I don't know Dimitry point of view, but maybe INRIA can just > consider MSVC (or mingw). If this is a way to free INRIA resources, it > is a good option. You should ask Xavier but I personally don't think that two Windows ports (Cygwin is quite a different beast) are really the problem for INRIA. They use (almost) the same C runtime library, the same makefiles and I don't know a single Ocaml bug that was MSVC or Mingw specific. Yes, you have two different emit_nt.mlp and emit.mlp, but the only way to make things simpler is to abandon MASM syntax completely. In principle it's possible - GNU as under Windows generates the same COFF files as MASM, although many Windows people that are not familiar with AT&T syntax would not be very glad... >> - would INRIA be ok to switch to a sse2 code generator (based on Dimitry's >> patch >> supposing that he is ok to donate it to INRIA - or Xavier's work or >> whatever)? >> >> - I also guess that a sse2 code generator would be simpler than the current >> one >> (that has to support this horrible fp stack architecture) and would >> therefore be >> a better candidate for further enhancements. >> >> - what is the opinion on this list, as a switch to a sse2 backend would >> exclude >> "old" processors from being OCaml compatible (I don't have a precise list at >> hand for now) ? > > I would like to say "go on", but SSE2 will limit OCaml to P4 on i386. > In Debian, this is the "low limit" of our build daemon. I think it is > quite dangerous not having the option of the older code generator... I also would like to retain support for i386. Hopefully, one more code generator (mostly a copy/paste combination of two already existing ones) would not require too much efforts to support. > If INRIA choose to switch to SSE2 there should be at least still a way > to compile on older architecture. Doesn't mean that INRIA need to keep > the old code generator, but should provide a simple emulation for it. In > this case, we will have good performance on new arch for float and we > will still be able to compile on old arch. > >> >> My opinion is that this support of legacy hardware is not important, but I >> guess >> others are arguing in opposite directions... :-) >> > > I would say that "the performance of legacy hardware is not important" > -- support is still important. > >> But again, having better floating point performance (and predictable >> behaviour, >> compared to the bytecode version) would be a big plus for some applications. >> > > Indeed. Don't quite understand what is "predictable behavior" - any generator should conform to specs. In my tests x87 and SSE2 backends show the same results (otherwise it would be called a bug). - Dmitry Bely ___ 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: Ocamlopt code generator question
On Tue, May 5, 2009 at 8:06 PM, Jean-Marc Eber wrote: > Hi Dimitry, > > Firstly thanks for looking again at the sse2 stuff! > > A difference may occur, if I'm not wrong, from the intermediate results > precision: > > in sse2, eveything is done on 8 bytes (if you "do" doubles at least), while, > in x87, intermdiate results (kept on the stack) are 10 bytes precision. > > This may result in differences (and the bytecode runtime never uses x87 > intermediate storage, so it behaves _numerically_ like the sse2 code > generator, I guess). I wouldn't be so sure. Bytecode runtime is C compiler-dependent (that does use x87 for floating-point calculations), so rounding errors can lead to different results. Floating point is always approximate... - Dmitry Bely ___ 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] ocamlfind question on cygwin
On Wed, May 6, 2009 at 7:57 PM, Alan Schmitt wrote: > Hello, > > I'm trying to debug some installation issue on godi/mingw, and it seems to > be a problem with ocamlfind using a cygwin console. When I try: > > $ ocamlfind install lwt -destdir > "/home/Administrateur/godi/lib/ocaml/pkg-lib" META > ocamlfind: Bad configuration: Cannot mkdir > /home/Administrateur/godi/lib/ocaml/pkg-lib\lwt because a path component > does not exist or is not a directory Probably your ocamlfind is a mingw (native Win32) application, and so you cannot use cygwin paths (/home/...). - Dmitry Bely ___ 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] Ocamlopt x86-32 and SSE2
On Fri, May 8, 2009 at 2:21 PM, Xavier Leroy wrote: >> I see. Why I asked this: trying to improve floating-point performance >> on 32-bit x86 platform I have merged floating-point SSE2 code >> generator from amd64 ocamlopt back end to i386 one, making ia32sse2 >> architecture. It also inlines sqrt() via -ffast-math flag and slightly >> optimizes emit_float_test (usually eliminates an extra jump) - >> features that are missed in the original amd64 code generator. > > You just passed black belt in OCaml compiler hacking :-) Thank you, sensei :-) >> Is this of any interest to anybody? > > I'm definitely interested in the potential improvements to the amd64 > code generator. > > Concerning the i386 code generator (x86 in 32-bit mode), SSE2 float > arithmetic does improve performance and fit ocamlopt's compilation > model much better than the current x87 float arithmetic, which is a > bit of a hack. Several options can be considered: > > 1- Have an additional "ia32sse2" port of ocamlopt in parallel with the > current "i386" port. > > 2- Declare pre-SSE2 processors obsolete and convert the current > "i386" port to always use SSE2 float arithmetic. > > 3- Support both x87 and SSE2 float arithmetic within the same i386 > port, with a command-line option to activate SSE2, like gcc does. > > I'm really not keen on approach 1. We have too many ports (and > their variants for Windows/MSVC) already. Moreover, I suspect > packagers would stick to the i386 port for compatibility with old > hardware, and most casual users would, too, out of lazyness, so this > hypothetical "ia32sse2" port would receive little testing. > > Approach 2 is tempting for me because it would simplify the x86-32 > code generator and remove some historical cruft. The issue is that it > demands a processor that implements SSE2. For a list of processors, see > http://en.wikipedia.org/wiki/SSE2 > As a rule of thumb, almost all desktop PC bought since 2004 has SSE2, > as well as almost all notebooks since 2006. That should be OK for > professional users (it's nearly impossible to purchase maintenance > beyond 3 years, anyway) and serious hobbyists. However, packagers are > going to be very unhappy: Debian still lists i486 as its bottom line; > for Fedora, it's Pentium or Pentium II; for Windows, it's "a 1GHz > processor", meaning Pentium III. All these processors lack SSE2 > support. Only MacOS X is SSE2-compatible from scratch. > > Approach 3 is probably the best from a user's point of view. But it's > going to complicate the code generator: the x87 cruft would still be > there, and new cruft would need to be added to support SSE2. Code > compiled with the SSE2 flag could link with code compiled without, > provided the SSE2 registers are not used for parameter and result > passing. But as Dmitry observed, this is already the case in the > current ocamlopt compiler. I am curious if passing unboxed floats is possible in the current Ocaml data model? As for proposed options - I tend to vote for #3 (and implement it if there is a consensus). Still there is a plenty of low-power/embedded x86 hardware that does not support SSE2. And one will be able to compare x87 and SSE2 backends performance to convince him/herself that the play really worths the candle :-) - Dmitry Bely ___ 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] Ocamlopt x86-32 and SSE2
On Sun, May 10, 2009 at 7:50 AM, Jon Harrop wrote: > On Sunday 10 May 2009 03:16:49 Seo Sanghyeon wrote: >> 2009/5/10 Goswin von Brederlow : >> > Having ocaml require SSE2 is quite unacceptable for someone with a Via >> > C7 cpu (they don't have SSE2, right?) Is it really that much work for >> > ocaml to use option 3? >> >> Maybe not, but don't underestimate tiny inconveniences! Even if it is >> tiny more work to support x87, it could be a difference of doing it and >> not doing it. >> http://lesswrong.com/lw/f1/beware_trivial_inconveniences/ > > If you want to avoid inconvenience, why not use LLVM to replace several of the > existing backends? I think it would be the major code rewrite (if ever possible). Merging SSE2 from amd64 into i386 code generator took about a day of my efforts. How much time LLVM integration would require? If it is that simple can you provide a proof-of-the-concept implementation? - Dmitry Bely ___ 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] Ocamlopt x86-32 and SSE2
On Mon, May 11, 2009 at 1:26 PM, Jon Harrop wrote: > On Monday 11 May 2009 09:05:08 Dmitry Bely wrote: >> I think it would be the major code rewrite (if ever possible). Merging >> SSE2 from amd64 into i386 code generator took about a day of my >> efforts. How much time LLVM integration would require? If it is that >> simple can you provide a proof-of-the-concept implementation? > > Well, I can provide a complete garbage collected VM. :-) > > http://hlvm.forge.ocamlcore.org/ We are talking about a new backend to Ocaml compiler, aren't we? > The hard part of writing an LLVM backend for ocamlopt is probably getting LLVM > to generate code that is compatible with OCaml's GC, particularly the stack. > However, I believe Gordon Henriksen already did this: > > "Included in the pending LLVM garbage collection code generation > changeset is an Ocaml frametable emitter." - > http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-November/011527.html So it's just pie in the sky. No working implementation has been demonstrated since then. The answer to your "why not use LLVM to replace several of the existing backends?" question is quite obvious. - Dmitry Bely ___ 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] Is it possible to debug (multithreaded) lablgtk2 apps?
On Tue, Jun 9, 2009 at 11:17 AM, Matthieu Dubuget wrote: > Hello, > > I'm trying to use camldebug. But I'm afraid I'm accumulating difficulties: > > - under mingw > - lablgtk2 + multithreaded app Ocaml Win32/MSVC+camldebug+OcaIDE - works for me (single-threaded lablgtk2 application, but I don't think multiple threads are the real problem). > With a very simple app, the programs run and works once started from > camldebug (from emacs), but my breakpoints are ignored. Can you try to set a breakpoint directly from camldebug? I am afraid emacs could introduce some line ending inconsistency and so incorrectly calculate the place. > With the more complex app I wanted to work on, the IHM is never shown. > > I think that I will revert to the good old Printf method. It's up to you but first I would try to find out why it does not work. - Dmitry Bely ___ 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] Why don't use batteries
On Sat, Sep 5, 2009 at 11:35 AM, David Rajchenbach-Teller wrote: > I take it to be a complaint against Batteries in particular > (helloworld.native is several Mb, when linked statically) and agains the > compiler in particular (in any given program, most of this is dead code > which the compiler fails to remove). > > Xavier Leroy is aware of the issue. Maybe either he or Xavier Clerc will > be able to look at it someday. Returning to an old discussion http://caml.inria.fr/pub/ml-archives/caml-list/2005/11/048f8f60868cf31d27d7fd66e3914023.en.html I don't think it can be (and will be) done. We should live with these big executables with considerable amount of dead code. > Cheers, > David > > On Fri, 2009-09-04 at 15:00 +0100, Richard Jones wrote: >> On Fri, Sep 04, 2009 at 02:49:52PM +0200, Julien Signoles wrote: >> > 3) It makes my executables too big >> > Yes, even if it seems to be improved in a close future. >> >> Is this a complaint against Batteries in particular or OCaml in >> general? OCaml binaries in general are rather large, and it appears >> to be because the runtime / GC is statically linked. Do you know how >> much this would improve with dynamic linking of libasmrun.a (which >> IIRC was a feature added in 3.11)? >> >> Rich. - Dmitry Bely ___ 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] testers wanted for experimental SSE2 back-end
On Tue, Mar 9, 2010 at 7:33 PM, Xavier Leroy wrote: > Hello list, > > This is a call for testers concerning an experimental OCaml compiler > back-end that uses SSE2 instructions for floating-point arithmetic. > This code generation strategy was discussed before on this list, and I > include below a summary in Q&A style. > > The new back-end is being considered for inclusion in the next major > release (3.12), but performance testing done so far at INRIA and by > Caml Consortium members is not conclusive. Additional results > from members of this list would therefore be very welcome. > > We're not terribly interested in small (< 50 LOC), Shootout-style > benchmarks, since their performance is very sensitive to code and data > placement. However, if some of you have a sizeable (> 500 LOC) body > of float-intensive Caml code, we'd be very interested to hear about > the compared speed of the SSE2 back-end and the old back-end on your > code. I cannot provide any benchmark yet but even not taking into account the better register organization there are at least two areas where SSE2 can outperform x87 significantly. 1. Float to integer conversion Is quite inefficient on x87 because you have to explicitly set and restore rounding mode. Typical let round x = truncate (x +. 0.5) Translates to _camlT__round_58: sub esp, 8 L100: fld L101 faddREAL8 PTR [eax] sub esp, 8 fnstcw [esp+4] mov ax, [esp+4] mov ah, 12 mov [esp], ax fldcw [esp] fistp DWORD PTR [esp] mov eax, [esp] fldcw [esp+4] add esp, 8 lea eax, DWORD PTR [eax+eax+1] addesp, 8 ret but just to _camlT__round_58: L100: movlpd xmm0, L101 addsd xmm0, REAL8 PTR [eax] cvttsd2si eax, xmm0 lea eax, DWORD PTR [eax+eax+1] ret with SSE2. 2. Float compare Does not set flags on x87 so let fmin (x:float) y = if x < y then x else y ends up with _camlT__fmin_58: sub esp, 8 L101: mov ecx, eax fld REAL8 PTR [ebx] fld REAL8 PTR [ecx] fcompp fnstsw ax and ah, 69 cmp ah, 1 jne L100 mov eax, ecx addesp, 8 ret L100: mov eax, ebx addesp, 8 ret on SSE2 you just have _camlT__fmin_58: L101: movlpd xmm1, REAL8 PTR [ebx] movlpd xmm0, REAL8 PTR [eax] comisd xmm1, xmm0 jbe L100 ret L100: mov eax, ebx ret As for SSE2 backend presented I have some thoughts regarding the code (fast math functions via x87 are questionable, optimization of floating compare etc.) Where to discuss that - just here or there is some entry in Mantis? - Dmitry Bely ___ 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] testers wanted for experimental SSE2 back-end
On Tue, Mar 23, 2010 at 12:07 PM, Daniel Bünzli wrote: >> let round x = truncate (x +. 0.5) > > Side note, if you are also interested in negative numbers Sure, it was just an code generation example. Probably I should use round_positive name. > that's not what you want. You want : > >> let round x = floor (x +. 0.5) ...and you get a floor() C call. I would better use let round x = truncate (x +. (if x > 0. then 0.5 else -0.5)) - Dmitry Bely ___ 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] User-defined printers and external C code
On Sun, Mar 28, 2010 at 2:24 PM, Stefan Ratschan wrote: >> The printing of Big_int is possible and AFAIK Big_int is an abstract >> data type. > >> let print_big_int (value_big_int:Big_int.big_int) = >> Format.printf "%s" (Big_int.string_of_big_int value_big_int);; > > I see, thanks. If I interpret this correctly, then the same code is > loaded twice. Once in the program to be debugged, once for the printer. > > Now I have the following problem: The ADT I want to print uses an > external C library. Ocamldebug refuses to load it, saying: > (ocd) load_printer ../smath/libsmath.a > Error during code loading: ../smath/libsmath.a is not a bytecode object > file How is this C library linked into your Ocaml program? Probably the custom runtime? > Any ideas? Dynamic loading should help you (see ocamlmklib chapter in the manual). Then the C code will be placed into .so file and loaded automatically then needed. - Dmitry Bely ___ 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] testers wanted for experimental SSE2 back-end
ng branch_opcode} {emit_label lbl}\n`
end else begin
let next = new_label() in
` jp {emit_label next}\n`;
` {emit_string branch_opcode} {emit_label lbl}\n`;
`{emit_label next}:\n`
end
else begin
` {emit_string branch_opcode} {emit_label lbl}\n`
end
2. My variant of fast math functions (see explanation above)
let emit_floatspecial = function
"sqrt" -> `sqrtsd `
| _ -> assert false
3. Loading st(0) can be two instructions shorter :)
` sub esp, 8\n`;
` fstpREAL8 PTR [esp]\n`;
` movsd {emit_reg dst}, REAL8 PTR [esp]\n`;
` add esp, 8\n`
can be written as
` fstpREAL8 PTR [esp-8]\n`;
` movlpd {emit_reg dst}, REAL8 PTR [esp-8]\n`;
4. Unnecessary instruction in Lop(Iload(Single, addr))
` movss {emit_reg dest}, REAL4 PTR {emit_addressing addr
i.arg 0}\n`;
` cvtss2sd {emit_reg dest}, {emit_reg dest}\n`
can be written as
` cvtss2sd {emit_reg dest}, REAL4 PTR {emit_addressing
addr i.arg 0}\n`
- Dmitry Bely
___
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] Optimizing Float Ref's
On Thu, Sep 3, 2009 at 1:44 PM, Xavier Leroy wrote: (...) >> But, I thought that float ref's were automatically unboxed by the compiler >> when they didn't escape the local context. > > Yes, if all uses of the float ref are unboxed, which is the case in > your code. let max_val (a:float array) = let m = ref min_float in for i = 0 to (Array.length a) - 1 do if a.(i) > !m then m := a.(i) done; !m !m is not unboxed (Ocaml 3.11). Should it? - Dmitry Bely ___ 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] Optimizing Float Ref's
On Wed, Mar 31, 2010 at 9:55 PM, Jake Donham wrote: > On Wed, Mar 31, 2010 at 10:21 AM, Dmitry Bely wrote: >> let max_val (a:float array) = >> let m = ref min_float in >> for i = 0 to (Array.length a) - 1 do >> if a.(i) > !m >> then m := a.(i) >> done; >> !m >> >> !m is not unboxed (Ocaml 3.11). Should it? > > Why do you say that? It looks unboxed in the lambda code: > > (let > (max_val/58 > (function a/59 > (let (m/60 (field 13 (global Pervasives!))) > (seq > (for i/61 0 to (- (array.length a/59) 1) > (if (>. (array.get a/59 i/61) m/60) > (assign m/60 (array.get a/59 i/61)) 0a)) > m/60 No. "assign" is translated into memory allocation inside the loop. > My x86 assembler is not very good but it looks to me like m is kept in %esi. Ok, probably returning float makes allocation place not obvious. Try this variant: let max_val (a:float array) = let m = ref min_float in for i = 0 to (Array.length a) - 1 do if a.(i) > !m then m := a.(i) done; truncate !m It's translated into the following C-- code (-unsafe flag): (function camlT__max_val_58 (a/59: addr) (let m/60 (load (+a "camlPervasives" 52)) (let (i/61 1 bound/65 (+ (or (>>u (load (+a a/59 -4)) 10) 1) -2)) (catch (if (> i/61 bound/65) (exit 3) (loop (if (>f (load float64u (+a (+a a/59 (<< i/61 2)) -4)) (load float64u m/60)) (assign m/60 (alloc 2301 (load float64u (+a (+a a/59 (<< i/61 2)) -4 []) (let i/64 i/61 (assign i/61 (+ i/61 2)) (if (== i/64 bound/65) (exit 3) [] with(3) [])) (+ (<< (intoffloat (load float64u m/60)) 1) 1))) See "alloc 2301" inside the loop? That's boxed float. - Dmitry Bely ___ 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] Optimizing Float Ref's
On Wed, Mar 31, 2010 at 10:59 PM, Alain Frisch wrote: > On 31/03/2010 19:21, Dmitry Bely wrote: >> >> On Thu, Sep 3, 2009 at 1:44 PM, Xavier Leroy >> wrote: >> (...) >>>> >>>> But, I thought that float ref's were automatically unboxed by the >>>> compiler >>>> when they didn't escape the local context. >>> >>> Yes, if all uses of the float ref are unboxed, which is the case in >>> your code. >> >> let max_val (a:float array) = >> let m = ref min_float in >> for i = 0 to (Array.length a) - 1 do >> if a.(i)> !m >> then m := a.(i) >> done; >> !m >> >> !m is not unboxed (Ocaml 3.11). Should it? > > As far as I can tell, the boxing for the reference cell is removed by the > compiler (that is, the reference is implemented as a mutable local > variable), but not the boxing for the float contained in the reference. > Since a is a float array, it is needed to box the float before putting it in > the reference, hence the allocation. Hmm, my interpretation of Xavier's words was that the compiler would completely optimize out memory allocation and keep !m in register. I can live with the allocation but not at every iteration... How to rewrite the function to get rid of it? My best achievement so far is let max_val (a:float array) = let m = [|-.min_float|] in for i = 0 to (Array.length a) - 1 do if a.(i) > m.(0) then m.(0) <- a.(i) done; m.(0) but it looks ugly... - Dmitry Bely ___ 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] Optimizing Float Ref's
On Wed, Mar 31, 2010 at 11:52 PM, Ted Sandler wrote: >> rpretation of Xavier's words was that the compiler would >> completely optimize out memory allocation and keep !m in register. I >> can live with the allocation but not at every iteration... How to >> rewrite the function to get rid of it? My best achievement so far is > > Try tail-recursion. Won't work. Show the code. - Dmitry Bely ___ 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] Building ocaml on Win32 using VS 2008
On Wed, Apr 14, 2010 at 9:32 PM, Alain Frisch wrote: > On 14/04/2010 19:13, Lally Singh wrote: >> >> Do you have a build procedure I could use? My own attempts have been >> rather terrible so far :-( > > I don't think we do anything special (regular configuration steps for the > Win32, and then "make -f Makefile.nt world"). Just to confirm that: it's build with my VS2008 without any special efforts. Lally, are you sure that the correct bootstrap compiler is used? - Dmitry Bely ___ 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] Statically linked win32 libcamlrun.lib?
On Thu, Apr 15, 2010 at 3:39 AM, Lally Singh wrote: > Is it possible to statically link libcamlrun.lib, so it'll work with > libcmtd.lib instead of msvcrt.dll? I've tried: > > FLEXLINK=flexlink -merge-manifest -link /nodefaultlib:msvcrt.lib -link > libcmtd.lib Please don't use "brute force" methods. If you need statically linked MSVC runtime, just replace /MD with /MT (or /MTd) in config/Makefile. > in config/Makefile, and it all builds. However, I still get: > > libcamlrun.lib(sys.obj) : error LNK2019: unresolved external symbol > __imp__system referenced in function _caml_sys_system_command > libcamlrun.lib(floats.obj) : error LNK2019: unresolved external symbol > __imp__frexp referenced in function _caml_frexp_float > libcamlrun.lib(floats.obj) : error LNK2019: unresolved external symbol > __imp__modf referenced in function _caml_modf_float > libcamlrun.lib(startup.obj) : error LNK2019: unresolved external > symbol __imp__sscanf referenced in function _scanmult > libcamlrun.lib(startup.obj) : error LNK2019: unresolved external > symbol __imp___beginthread referenced in function _caml_main > > Any thoughts? Ocaml expects C runtime functions exported from a DLL (they have __implib prefix). No surprise - MSVC runtime is not a link time choice and requires correct compile time flags. > Sadly I have to do it this way -- we're linking a -output-obj'd .obj > into our DLL (which must be statically linked to the runtime) and then > linking libcamlrun.lib to that -- or at least hoping to. > > Thanks in advance for any help! - Dmitry Bely ___ 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] Statically linked win32 libcamlrun.lib?
On Thu, Apr 15, 2010 at 11:16 PM, Lally Singh wrote: > On Thu, Apr 15, 2010 at 2:59 AM, Dmitry Bely wrote: >> On Thu, Apr 15, 2010 at 3:39 AM, Lally Singh wrote: >> >>> Is it possible to statically link libcamlrun.lib, so it'll work with >>> libcmtd.lib instead of msvcrt.dll? I've tried: >>> >>> FLEXLINK=flexlink -merge-manifest -link /nodefaultlib:msvcrt.lib -link >>> libcmtd.lib >> >> Please don't use "brute force" methods. If you need statically linked >> MSVC runtime, just replace /MD with /MT (or /MTd) in config/Makefile. > > Thanks, I've tried this instead, and I can't get through make -f > Makefile.nt bootstrap without: > ../../boot/ocamlrun ../../ocamlc -nostdlib -I ../../stdlib -w s -c > -warn-error A -g -I ../win32unix bigarray.mli > File "bigarray.mli", line 384, characters 4-19: > Error: Unbound type constructor Unix.file_descr > make[2]: *** [bigarray.cmi] Error 2 > > I guess using the flexlink hack just moved whatever underlying problem > I'm having to a later stage. Why boostrap? Does simple "make -f Makefile.nt world" succeeds? Please use the clean distribution with minimal changes in config/Makefile; I suspect you have already broken something during your experiments. - Dmitry Bely ___ 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] Statically linked win32 libcamlrun.lib?
On Thu, Apr 15, 2010 at 11:16 PM, Lally Singh wrote: > On Thu, Apr 15, 2010 at 2:59 AM, Dmitry Bely wrote: >> On Thu, Apr 15, 2010 at 3:39 AM, Lally Singh wrote: >> >>> Is it possible to statically link libcamlrun.lib, so it'll work with >>> libcmtd.lib instead of msvcrt.dll? I've tried: >>> >>> FLEXLINK=flexlink -merge-manifest -link /nodefaultlib:msvcrt.lib -link >>> libcmtd.lib >> >> Please don't use "brute force" methods. If you need statically linked >> MSVC runtime, just replace /MD with /MT (or /MTd) in config/Makefile. > > Thanks, I've tried this instead, and I can't get through make -f > Makefile.nt bootstrap without: > ../../boot/ocamlrun ../../ocamlc -nostdlib -I ../../stdlib -w s -c > -warn-error A -g -I ../win32unix bigarray.mli > File "bigarray.mli", line 384, characters 4-19: > Error: Unbound type constructor Unix.file_descr > make[2]: *** [bigarray.cmi] Error 2 > > I guess using the flexlink hack just moved whatever underlying problem > I'm having to a later stage. And you have to recompile flexdll_msvc.obj/flexdll_initer_msvc.obj with /MT option. - Dmitry Bely ___ 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] Statically linked win32 libcamlrun.lib?
On Tue, Apr 20, 2010 at 7:48 PM, Lally Singh wrote: > On Thu, Apr 15, 2010 at 4:16 PM, Dmitry Bely wrote: >> On Thu, Apr 15, 2010 at 11:16 PM, Lally Singh wrote: >>> On Thu, Apr 15, 2010 at 2:59 AM, Dmitry Bely wrote: >>>> On Thu, Apr 15, 2010 at 3:39 AM, Lally Singh wrote: (...) /DEFAULTLIB:"MSVCRT"> LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of > other libs; use /NODEFAULTLIB:library > LIBCMTD.lib(crt0.obj) : error LNK2019: unresolved external symbol > _main referenced in function ___tmainCRTStartup > .\dllunix.dll : fatal error LNK1120: 1 unresolved externals > > I verified that every object file in that directory was compiled with > /MTd. Is there something else I need to feed into the Makefile to > make ocamlmklib do the right thing? Nevertheless some of your files are compiled with /MD. Use /VERBOSE linker option to find which one. I believe FLEXLINK=flexlink -merge-manifest -link /VERBOSE will do the job. BTW, have you recompiled flexdll.c/flexdll_initer.c files in FlexDLL directory with /MTd? - Dmitry Bely ___ 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 OcamIL
On Wed, May 5, 2010 at 11:16 PM, Ed Keith wrote: > It bothers me that the Ocaml community seems to consider Windows developers > as second class citizens. Until this changes > Ocaml will never be a main stream language. I think it's not really that bad. Ocaml developers support Windows as a first class platform. Many Ocaml libraries can be build under Windows without a problem. And now GODI supports Windows too. > F# may eat it's lunch. But F# is tied to Windows, Ironically it's also not entirely true. F# works well under Mono/Unix. Maybe it will even be faster than Ocaml for some applications due to threads running in parallel on multiple cores. But F# is very different from Ocaml. - Dmitry Bely ___ 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 OcamIL
> On Thursday 06 May 2010 06:43:21 am Dmitry Bely wrote: >> Ironically it's also not entirely true. F# works well under Mono/Unix. >> > A little off topic, but how is Mono/Unix these days? Last I checked (>2 years > ago) it implemented the basic libraries and runtimes but had terrible > performance. Is it now on par with Windows? It's hard to say: personally I don't use Mono (neither Windows nor Linux) yet. But indeed I was overoptimistic. Mono still uses Boehm GC so it should be slow enough. Nevertheless things are changing: http://www.mono-project.com/Compacting_GC http://lists.ximian.com/pipermail/mono-devel-list/2009-November/033421.html Let's wait for mono 2.8 and see how the new generational GC works. - Dmitry Bely ___ 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] 8-bit characters on command line
On Fri, May 14, 2010 at 8:36 AM, Paul Steckler wrote: > I have an OCaml 3.11 program that prints out the arguments on the command > line: > > let main =Array.iter (Printf.printf "arg = %s\n") Sys.argv > > On Linux, if I provide a command line argument containing 8-bit characters, > like é (an e with an acute accent), the program above, compiled with ocamlopt > or ocamlc, prints them faithfully. > > For Windows, I can compile the program above with ocamlc on Windows, or > cross-compile > it with MinGW-ocaml on Linux. In both cases, any 8-bit characters in the > command > line are printed as garbage. I've tried running the program from rxvt (a > shell for > Cygwin) and Windows cmd.exe. I believe that's because there are actually two current code pages in Windows: "OEM" code page for console input/output and "ANSI" one for everything else. In mode detail: http://msdn.microsoft.com/en-us/library/dd317752%28VS.85%29.aspx E.g. in my system ANSI/OEM code pages are 1251/866. In your case they are probably 1252/437. Program arguments and any 8-bit character strings inside an application are considered to have ANSI encoding (as that's what non-Unicode Windows API functions expect), but console output functions perform ANSI->OEM code page translation. So you see a garbage. - Dmitry Bely ___ 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] 8-bit characters on command line
On Fri, May 14, 2010 at 10:20 AM, Paul Steckler
wrote:
> 2) if I write the equivalent C program and compile it on Windows, 8-bit
> characters are passed as arguments and spat back just fine
Just tested with MSVC 9.0 - exactly the same problem. Try this
#include
int main(int argc, char** argv)
{
for (int i=0; i < argc; ++i) {
puts(argv[i]);
}
return 0;
}
and you'll see.
- Dmitry Bely
___
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: [ANN] Camomile 0.7.3
How "heavy-weight" is Camomile? I was a bit scared with the size of its distribution. Currently I use under Windows the following my own simple Unicode-support module (implemented via WideCharToMultiByte/MultiByteToWideChar Win32 API functions). Maybe it's time to switch to Camomile? (** Wide char/string operations. *) type codePage = CP_ACP (* ANSI code page *) | CP_MACCP (* Macintosh code page *) | CP_OEMCP (* OEM code page *) | CP_SYMBOL (* Symbol code page (42) *) | CP_THREAD_ACP (* The current thread's ANSI code page *) | CP_UTF7 (* Translate using UTF-7 *) | CP_UTF8 (* Translate using UTF-8 *) | CP_NUMERIC of int module Wchar: sig (*IF-OCAML*) type t = private int (*ENDIF-OCAML*) (*F# type t = char F#*) val compare: t -> t -> int val of_int: int -> t val to_int: t -> int val encode: codePage -> t -> Bytes.bytes val decode: codePage -> Bytes.bytes -> t end module Wstring: sig (*IF-OCAML*) type t = private int array (*ENDIF-OCAML*) (*F# type t = string F#*) val compare: t -> t -> int val length : t -> int val get: t -> int -> Wchar.t val make: int -> Wchar.t -> t val append: t -> t -> t val uppercase: t -> t val lowercase: t -> t val of_array: Wchar.t array -> t val to_array: t -> Wchar.t array val of_int_array: int array -> t val to_int_array: t -> int array val of_list: Wchar.t list -> t val to_list: t -> Wchar.t list val empty: t (*IF-OCAML*) external pack_to_string: t -> string = "w32_unicode_pack_to_string" (** convert to packed 2-byte UCS2 string, stored as Caml string *) external unpack_from_string: string -> t = "w32_unicode_unpack_from_string" (** inverse function for pack_to_string *) (*ENDIF-OCAML*) val encode: codePage -> t -> Bytes.bytes val decode: codePage -> Bytes.bytes -> t end type wchar = Wchar.t type wstring = Wstring.t (**/**) - Dmitry Bely ___ 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] Bigarrays and blocking_section..
On Tue, May 25, 2010 at 8:25 PM, Romain Beauxis wrote:
> Hi all !
>
> I am trying to understand some segfault that we observe and I have a question
> about the relationships between bigarrays in C and the Gc.
>
> We have the following code:
>
> static frame *frame_of_value(value v, frame *f)
> {
> f->data = Caml_ba_data_val(Field(v,0));
> f->width = Int_val(Field(v,1));
> f->height = Int_val(Field(v,2));
> f->stride = Int_val(Field(v,3));
>
> return f;
> }
Are you sure that you correctly calculate the bigarray size in your
Caml code? Why not just use struct caml_ba_array fields? I suspect
it's not GC problem but just a buffer overrun in memset().
- Dmitry Bely
___
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 3.12.0+beta1
On Thu, Jun 24, 2010 at 10:59 PM, wrote: > Martin Jambon a écrit : >> >> I disagree. The syntax is a new and optional feature. Authors who want >> their >> new code to compile with an earlier version of OCaml should simply avoid >> using >> the new feature, as always. > > The 3.12 version number is just minor increment. It should keep backward > compatibility with the 3.x branch as much as possible. I'm sorry but where do you see a violation of backward compatibility? Can you provide an example that compiles OK with Ocaml 3.11 and generates an error with Ocaml 3.12? - Dmitry Bely ___ 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 compiling native code on windows platform
On Mon, Aug 9, 2010 at 9:10 AM, MayX wrote: > > I have some program to compiling native code on windows platform. > > when I use the command: > ocamlopt -ccopt "-LC:/out/gtk/lib" -I +lablgtk2 lablgtk2 lablgtk.cmxa > gtkInit.cmx testgtk.ml -o testgtk.exe > > it display a fatal error like this: > cannot find file "libgtk-win32-2.0" > error:error during linking > > how to solve this problem? Read LablGtk2-install.txt and follow the instructions. - Dmitry Bely ___ 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: Question about float refs.
On Mon, Aug 23, 2010 at 4:42 PM, Sylvain Le Gall wrote: > On 23-08-2010, Ethan Burns wrote: >> On Mon, Aug 23, 2010 at 8:06 AM, Christophe TROESTLER >> wrote: >>> On Thu, 19 Aug 2010 07:52:33 -0400, Ethan Burns wrote: >>>> >>>> let r = ref 0.0 ;; >>>> for i = 0 to 10 do r := float i done; >>>> Printf.printf "%f\n" !r; >>>> Printf.printf "words: %f\n" (Gc.stat ()).Gc.minor_words >>> >>> To add a precision to others' answers : float refs are unboxed >>> _locally_. If you rewrite your code as >>> >>> let r = ref 0.0 in >>> for i = 0 to 1000_000_000 do r := float i done; >>> Printf.printf "%f\n" !r; >>> Printf.printf "words: %f\n" (Gc.stat ()).Gc.minor_words >>> >>> then it runs at about the same speed as you other version. >> >> >> $ time ./a.out >> 10.00 >> words: 200367.00 >> >> real 0m2.655s >> >> It does seem to run a lot faster than my first version, but it also >> seems to allocate a whole lot. If it is still allocating just as much >> why is this version so much faster? >> > > Allocation on the minor heap is very cheap compared to assignement into > the major heap. It is better to allocate a lot on the minor heap than to > do operations on the major heap. Some black magic is needed: let r = ref 0.0 in for i = 0 to 1000_000_000 do r := float i done; Printf.printf "%f\n" (!r +. 0.); Printf.printf "words: %f\n" (Gc.stat ()).Gc.minor_words and the reference will be placed in a register (Caml heap will not be used inside the loop) - Dmitry Bely ___ 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: Question about float refs.
On Tue, Aug 31, 2010 at 11:41 PM, Jon Harrop wrote: > You might prefer to multiply by 1.0 because adding 0.0 changes -0.0. > > Cheers, > Jon. > >> Some black magic is needed: >> >> let r = ref 0.0 in >> for i = 0 to 1000_000_000 do r := float i done; >> Printf.printf "%f\n" (!r +. 0.); >> Printf.printf "words: %f\n" (Gc.stat ()).Gc.minor_words >> >> and the reference will be placed in a register (Caml heap will not be >> used inside the loop) Do you have any idea why the optimizer needs that? - Dmitry Bely ___ 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] Chain Camlp4 syntax extensions?
I have two similar syntax extension that generate some functions for
each type in the module:
EXTEND Gram
str_item:
[ [ "type"; tdl = LIST1 type_declaration SEP "and" ->
...
END;
So I use them as usual:
ocamlc -c -pp "camlp4o pa_ext1.cmo" file.ml
or
ocamlc -c -pp "camlp4o pa_ext2.cmo" file.ml
Now I need to apply them both to the same source file in sequence
(without rewriting the extensions if possible). What is the right way
to do that? Of course, If I write
ocamlc -c -pp "camlp4o pa_ext1.cmo pa_ext2.cmo" file.ml
only pa_ext2 extension is actually applied. Calling camlp4o twice with
an intermediate text representation works but is actually unacceptable
(the error location info is lost etc.). Any advice?
And another question. For camlp5 it was possible to inject some code
into the beginning of the generated file (the code is taken from IoXML
syntax extension):
value first = ref True;
Pcaml.parse_implem.val :=
fun strm ->
let (sil, stopped) = Grammar.Entry.parse Pcaml.implem strm in
let sil =
if first.val then
let _ = do { first.val := False } in
let _loc =
Stdpp.dummy_loc
in
[(<:str_item< open IoXML >>, _loc) :: sil]
else sil
in
(sil, stopped)
;
How to do the same with camlp4?
- Dmitry Bely
___
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] Chain Camlp4 syntax extensions?
On Tue, Sep 28, 2010 at 8:07 PM, Jake Donham wrote: > On Tue, Sep 28, 2010 at 6:13 AM, Dmitry Bely wrote: >> I have two similar syntax extension that generate some functions for >> each type in the module: >> >> EXTEND Gram >> str_item: >> [ [ "type"; tdl = LIST1 type_declaration SEP "and" -> >> ... >> END; > > There is not a good solution without modifying the extensions; looking > at the signature of the Grammar module, you can modify a grammar but > not look up or call existing rules / actions. > > This problem of combining extensions for type-derived functions is the > motivation for the type-conv framework: > > http://www.ocaml.info/home/ocaml_sources.html#toc9 > > It's trivial to convert an extension to use type-conv. Thanks. But I have not found any docs for type-conv package. Is there any example demonstrating how to make Camlp4 grammar compatible with type-conv framework? >> And another question. For camlp5 it was possible to inject some code >> into the beginning of the generated file > > It should be doable with a filter and a bool ref---inject the code > into the first str_item then set the flag so you don't add it to the > others. Thanks again. Indeed this is the way to go. - Dmitry Bely ___ 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
