tag:blogger.com,1999:blog-27488238.post114776951026343183..comments2024-03-22T11:34:45.165+01:00Comments on taw's blog: OCaml programming best practicetawhttp://www.blogger.com/profile/16972845140253292628noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-27488238.post-84620688111087686402008-11-21T07:39:00.000+01:002008-11-21T07:39:00.000+01:00It should be noted that functions called from Tk (...It should be noted that functions called from Tk (labltk), eg. callbacks in response to user input, *do not* cause a backtrace to be printed - they must be run from the top-level to properly print a backtrace. I wish it were otherwise - this makes debugging a GUI program difficult. <BR/>Anybody know if it is the same for gtk?Timothyhttps://www.blogger.com/profile/14810777981680842172noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-48396204197306155492008-01-26T21:42:00.000+01:002008-01-26T21:42:00.000+01:00Anonymous: If you needed 100% performance you'd be...Anonymous: If you needed 100% performance you'd be writing in <A HREF="http://en.wikipedia.org/wiki/NVIDIA_Tesla" REL="nofollow">Tesla assembly</A> or Fortran, not OCaml.<BR/><BR/>OCaml gives you a good compromise between performance and expressive power, and you can always go slightly lower level with the most performance-critical part of your app to get a few % more power if you need it.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-64205335431521511022008-01-26T21:10:00.000+01:002008-01-26T21:10:00.000+01:00None of these are applicable to getting performanc...None of these are applicable to getting performance out of OCaml, infact your use of functors and supporting of box float data structures will cause your scientific ocaml code to crawl.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-77988400046514105252007-07-25T08:09:00.000+02:002007-07-25T08:09:00.000+02:00I would also recommend you to put a bit of attenti...I would also recommend you to put a bit of attention to the ocamlbuild app.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-82646700902755439792007-03-09T21:02:00.000+01:002007-03-09T21:02:00.000+01:00Anonymous: Thanks for information. It's always gre...Anonymous: Thanks for information. It's always great to see things that I didn't like getting fixed. :-)<BR/><BR/>ocamlbuild looks very interesting too.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-71369722782128192012007-03-09T20:43:00.000+01:002007-03-09T20:43:00.000+01:00Xavier just released a beta of 3.10.0 that might i...Xavier just released a beta of 3.10.0 that might interest you. Some neat improvements are 'ocamlbuild' (http://gallium.inria.fr/~pouillar/ocamlbuild/ocamlbuild-presentation.pdf)<BR/>as well as stack backtraces for native code and bytecode.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-31561590949168615392007-03-09T12:09:00.000+01:002007-03-09T12:09:00.000+01:00Exception backtraces are already available in byte...Exception backtraces are <A HREF="http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/exception_backtraces.html" REL="nofollow"><BR/>already available in bytecode compiled ocaml</A>.<BR/><BR/>Native code exceptions have been added to native compiled ocaml for version 3.10 of the compiler which will be available RealSoonNow(tm).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-1162526975376715262006-11-03T05:09:00.000+01:002006-11-03T05:09:00.000+01:00There are two big reasons why OCamlMakefile is fra...There are two big reasons why OCamlMakefile is fragile. One is the general problem with recursive Makefiles, which are <A HREF="http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html" REL="nofollow">best described here</A>. If you build a single binary, the problem doesn't apply.<BR/><BR/>The second big issue is that OCamlMakefile does some really evil Makefile hackery. As soon as you want your Makefile to do something non-trivial besides compiling OCaml programs, it is pretty likely these things will interfere.<BR/><BR/>A simple example of a common Make thing that doesn't work with OCamlMakefile:<BR/><BR/># First, build a test binary<BR/>define PROJ_test6<BR/> SOURCES=$(TEST_COMMON) test6.ml<BR/> RESULT=test6<BR/>endef<BR/><BR/># And now run the test<BR/># To run a test first build it of course<BR/>run_test_6: test6<BR/> ./test6<BR/> diff --brief img_6.png correct_6.png<BR/><BR/>But with OCamlMakefile test6 is not a valid dependency.<BR/>To build test6 you cannot use:<BR/><BR/># make doesn't even return error,<BR/># it just tries to compile test6.ml<BR/># to test6 ignoring everything in<BR/># the Makefile<BR/>make test6<BR/><BR/>only:<BR/><BR/>make native-code SUBPROJS=test6<BR/><BR/>What doesn't make a valid dependency. It can be worked around, but it's yucky.<BR/><BR/>The other question is rather pointless. As <A HREF="http://en.wikipedia.org/wiki/Bjarne_Stroustrup" REL="nofollow">Saddam Hussein of programming</A> said - "There are only two kinds of languages: the kind everybody bitches about, and the kind nobody uses".<BR/><BR/><A HREF="http://t-a-w.blogspot.com/2006/07/language-popularity-metrics.html" REL="nofollow">You should be more worried when people do not put any energy in proving your favourite language sucks</A>. That would mean it's pretty much dead.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-1161471786538461482006-10-22T01:03:00.000+02:002006-10-22T01:03:00.000+02:00What makes you think OCamlMakefile is fragile? Als...What makes you think OCamlMakefile is fragile? Also, multiple projects work quite well and they don't have to involve recursive makefiles as you're suggesting. And yes, you can share makefile with something else - best way is to include OCamlMakefile in your specialized makefile.<BR/><BR/>No offense, but why are you using the language you don't like? It's counterproductive, your putting your energy in proving that X sucks. Just code in what you like and have fun.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-1161331294768507412006-10-20T10:01:00.000+02:002006-10-20T10:01:00.000+02:00I almost feel bad that I missed that one. :-)Ok, I...I almost feel bad that I missed that one. :-)<BR/><BR/>Ok, I was wrong, there is some way to get Ocaml print backtraces. I must have missed it because I always used native-compiled code, in which case it doesn't work at all.<BR/><BR/>Still, it's pretty limited. It only prints file names and line numbers, and not function names, arguments etc.<BR/><BR/>Another update of the list: <A HREF="http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=399" REL="nofollow">OCamlMakefile</A> is usually better than hand-coded Makefiles calling ocamldep. It is a very fragile piece of Makefile hackery (<A HREF="http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html" REL="nofollow">and can easily screw up dependencies with multiple projects</A>), so it shouldn't share a Makefile with anything else, but when left undisturbed it works quite well.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-1161329623315353522006-10-20T09:33:00.000+02:002006-10-20T09:33:00.000+02:00The following command-line options are recognized ...The following command-line options are recognized by ocamlrun.<BR/><BR/>-b<BR/> When the program aborts due to an uncaught exception, print a detailed “back trace” of the execution, showing where the exception was raised and which function calls were outstanding at this point. The back trace is printed only if the bytecode executable contains debugging information, i.e. was compiled and linked with the -g option to ocamlc set. This is equivalent to setting the b flag in the OCAMLRUNPARAM environment variable (see below).Anonymousnoreply@blogger.com