From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id EAA02624; Wed, 14 Nov 2001 04:03:29 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA02490 for ; Wed, 14 Nov 2001 04:03:28 +0100 (MET) Received: from mail.mimuw.edu.pl (paf87.warszawa.sdi.tpnet.pl [217.96.225.87]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fAE33Q509085 for ; Wed, 14 Nov 2001 04:03:26 +0100 (MET) Received: (from news@localhost) by mail.mimuw.edu.pl (PLD/8.9.3) id EAA05579 for caml-list@inria.fr; Wed, 14 Nov 2001 04:04:01 +0100 X-Authentication-Warning: qrnik.zagroda: news set sender to Marcin 'Qrczak' Kowalczyk using -f From: "Marcin 'Qrczak' Kowalczyk" Subject: Re: [Caml-list] A few questions regarding the compiler Date: Wed, 14 Nov 2001 03:03:57 +0000 (UTC) Organization: Klub Nieszkodliwych =?iso-8859-2?Q?Manjak=F3w?= Message-ID: References: <9smdf7$511$1@qrnik.zagroda> <9ssfsl$fa4$1@qrnik.zagroda> X-Trace: qrnik.zagroda 1005707037 5574 192.168.0.1 (14 Nov 2001 03:03:57 GMT) X-Complaints-To: abuse@localhost NNTP-Posting-Date: Wed, 14 Nov 2001 03:03:57 +0000 (UTC) User-Agent: slrn/0.9.7.2 (Linux) To: caml-list@inria.fr Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Tue, 13 Nov 2001 21:36:57 +0100, Xavier Leroy pisze: > For standalone executables, it is very easy to wrap your generated > program in a catch-all "try...with" construct, and print the escaping > exception as you see fit. Then it would be impossible to dump the backtrace. A backtrace which shows OCaml source positions might be better than nothing. Well, I could reraise the exception after printing, but then it would be printed twice, formatted by me and by OCaml, which is a bit silly especially when there is no backtrace (the usual case). It would be ideal to be able to obtain the backtrace programmatically after I catch an exception. I could even think about translating positions to real source in this case. Is that possible? > Camlp4 (among other features) provides an easy way to construct OCaml > abstract syntax trees and have then compiled or executed by the OCaml > compilers or toplevel. It exploits a number of hooks in the compilers > and toplevel to achieve fairly tight integration with them. So, I'm > pretty sure it could help, provided your compiler is written in OCaml > indeed. It will be "written" in OCaml after I rewrite it in itself. It's not going to happen soon, but it would not be much of work. The gap between being so small to be easily implemented and so big to implement something is shrinking as I'm completing the library. >> [toplevel interface not doing what you want] >> I don't want to have to compile a custom OCaml version - it should >> work with whatever is installed with OCaml. > > Methinks you're asking for too much here :-) It's so close... Why else would topmain.cmo be separate? Don't say that it's because the linker would otherwise throw the library out, treating it as unused. I know that it's separate for being able to replace topmain with a customized version :-) The only problem is that some key features are not exported. > The ocamlc and ocamlopt compilers honor '# lineno "filename"' > directives. Ah, I could have checked before asking. BTW, I think it's not quite true that special-casing the representation of float arrays while pretending it's the same type has little cost. Almost all functions in the Array module do a check in their inner loop. Since code generated by my compiler uses arrays very often, I don't call functions like Array.of_list but use inline loops or specialized functions. Besides float arrays, I see that writing to an array whose element type is statically known to be always an immediate word is faster than the other case which must call 'modify'. Are such details described somewhere? I guess that it's fine to initialize an array of non-floats with 'Obj.magic 0' even if the type doesn't have nullary constructors, provided that I overwrite elements with valid objects before use? I don't always have a proper element at hand. Is it true that the Array module cares to always find a valid element for initialization only because of float arrays? And is it true that 'Obj.magic 0' can be sometimes more efficient than a pointer because some case in make_vect uses 'initialize(&Field(res, i), init)' instead of 'Field(res, i) = init' in its inner loop? Or slightly less efficient because later initialization must do one round more... Why are small arrays and large arrays treated differently? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr