From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 42CEBBB84 for ; Thu, 29 Jun 2006 01:17:23 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k5SNHNSe028029 for ; Thu, 29 Jun 2006 01:17:23 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA27927 for ; Thu, 29 Jun 2006 01:17:22 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k5SNHK0r028016 for ; Thu, 29 Jun 2006 01:17:22 +0200 Received: from rosella (ppp28-237.lns1.syd2.internode.on.net [59.167.28.237] (may be forged)) by smtp3.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k5SNH4Pe062132; Thu, 29 Jun 2006 08:47:04 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Typing unmarshalling without marshalling types From: skaller To: Jonathan Roewen Cc: caml-list@inria.fr In-Reply-To: References: <449BB0C6.5040204@ensta.fr> <1151533191.5339.46.camel@rosella.wigram> Content-Type: text/plain Date: Thu, 29 Jun 2006 09:17:04 +1000 Message-Id: <1151536624.5339.73.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44A30E03.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 44A30E00.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; marshalling:01 ocaml:01 bytecode:01 bytecode:01 ocaml:01 compiler:01 gcc:01 2006:98 wrote:01 sourceforge:01 caml-list:01 imho:01 typing:01 executables:01 executables:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Thu, 2006-06-29 at 10:27 +1200, Jonathan Roewen wrote: > > It isn't broken. The need to search the environment for the > > interpreter is mandated by the requirement scripts invoking > > the names of ocaml executables are transparent with respect > > to both: > > > > (a) whether the code is bytecode or native code > > (b) the machine it runs on > > > > Hard coding the location of the interpreter breaks > > requirement (b): it prevents shipping bytecode > > from one machine to another because two people may > > have installed the interpreter in different places > > (indeed may be running different OS!) > > Err, what? OCaml already embeds the full path in bytecode (on > unix-like systems). Then the codes won't be shippable. > How should this be any different for an ocaml > compiler tool? It can be different for an installed tool set of ocaml tools, but not for external executables such as CL.EXE, gcc, etc. I not only can but DO upgrade these tools independently of Ocaml. Hard coding paths in executables is a bad idea. The right way to do this is to make the client executables (or libraries) arguments, and then provide a shell script which has these arguments hard coded. That way it's easy to reconfigure your system with a text editor. IMHO of course. Hard coded paths are easier for dumb usage .. until you get tied in a knot upgrading things and have no idea what the problem is because the encoding isn't visible. Coupling should be explicit -- basic design principle (see OOSC, Meyer). -- John Skaller Felix, successor to C++: http://felix.sf.net