From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 51FBCBCA7 for ; Tue, 1 Mar 2005 07:40:45 +0100 (CET) Received: from hosting.commandprompt.com (128.commandprompt.com [207.173.200.128]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j216egLb008673 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 1 Mar 2005 07:40:44 +0100 Received: from hosting.commandprompt.com (crazypenguins [127.0.0.1]) by hosting.commandprompt.com (8.12.8/8.12.8) with ESMTP id j216dNkh007016; Mon, 28 Feb 2005 22:39:23 -0800 Received: (from jhenrikson@localhost) by hosting.commandprompt.com (8.12.8/8.12.8/Submit) id j216dMDk007014; Mon, 28 Feb 2005 22:39:22 -0800 X-Authentication-Warning: hosting.commandprompt.com: jhenrikson set sender to jehenrik@yahoo.com using -f Date: Mon, 28 Feb 2005 22:39:22 -0800 From: Jeff Henrikson To: Paul Snively Cc: Mike Hamburg , ml-labo@epimac.org, Julien Roussel , Oliver Bandel , caml-list@yquem.inria.fr, tipoix@free.fr Subject: Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) Message-ID: <20050301063922.GA5981@hosting> References: <20050205000208.GB1364@first.in-berlin.de> <3a2f4a1305020508377ec6ddaf@mail.gmail.com> <617f41a9a7ef08a96d3bd59b00a9ae47@mac.com> <20050217071238.GA19872@hosting> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Miltered: at nez-perce with ID 42240E6A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; henrikson:01 jehenrik:01 ocaml:01 merging:01 parsing:01 parsing:01 ast:01 parser:01 gcc:01 flags:01 gcc:01 vastly:01 rewriting:01 parsers:01 parser:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=2.4 required=5.0 tests=FORGED_YAHOO_RCVD, UPPERCASE_25_50 autolearn=disabled version=3.0.2 X-Spam-Level: ** > >I have an email out with Mr. Casse regarding how he feels about=20 > >merging these changes. An Obj-C and/or C++ extension should=20 > >preferably begin with a "blessed" starting point. > > > I agree, and wonder whether there's consensus as to whether 3.1 should=20 > be that starting point, or whether we should (need to, for Forklift's=20 > sake?) integrate the Cil and 3.1 changes. Upon superficial examination, the Frontc 2.0 -> 3.1 changes seem to mostly = revolve around XML output. The Cil frontc changes are more about parsing h= eader files "in the wild". Look at the Cil manual chapter 17 for the level= of energy put into parsing messy stuff: http://manju.cs.berkeley.edu/cil/cil017.html > This sounds very nice! How would you suggest that we proceed toward=20 > Objective-C coverage in conjunction with your other requirements and=20 > observations about the status of Frontc and Cil? Well, I see three possible paths. =20 1) get Frontc and Cil Frontc merged. Extend the ast and parser for Obj-C a= nd/or C++. I know C++ much better than ObjC, but my sense is that ObjC is = easier for this. 2) gccxml is a patch for gcc made for a java C++ stub generator. The idea = is that you specify some flags to gcc and it spews XML of the parse tree. = gccxml was build for doing C++, so there may be some additions necessary to= get all the ObjC primitives. Below I attach some output from gccxml on th= e semi-commercial C++ 3D toolkit Nebula2. Messy as you can see, but vastly= easier than dealing with raw text. I personally mourn the fact that massi= ve amounts of open source labor is wasted rewriting parsers. In my mind a = parser is a generic thing=20 3) yaxx is an extension to yacc which takes any .y file, and generates a mo= dified C program which outputs .xml and a .dtd instead of just running. Th= is means that one can take, for example the gcc .y file, and get a .xml out= put C program without modifying gcc. I really like this approach, the beau= ty is that it holds promise for maybe someday not needing to write a parser= for every last target language. (It seems wrong to me that we need an oca= mlyacc to begin with. There needs to be available some standard behavior w= hich ignores the actions of a .y file and just spews an AST. Not to mentio= n tree walkers and other useful things.) They have tried the gcc parser ha= ck, and the comments say it is supposed to handle C and Obj-C (not C++?) bu= t I can't get that part to work. I can get the ansic, sql and java parts t= o work. I copy paste below xml output for the ansi parser. Incidentally, = there's some incompatibility in the build for darwin, I needed to use a lin= ux box. If you search and replace all instances of stdout to another ident= ifier in the generated ansic/gram.tab.c, it compiles on darwin but I haven'= t checked if the behavior is right. Any of the three solutions basically entail getting the output back to a Ca= bs (frontc) similar representation. It will be necessary to add a named at= tributes for parent class, language and so on, but that would be my basic s= trategy. Cheers, Jeff gccxml on nebula2 test: ****************************gfx2/nmesh2.h*********************************** class N_PUBLIC nMesh2 : public nResource { public: enum Usage { WriteOnce, // (default) CPU only fills the vertex buffer once,= and=20 never touches it again ReadOnly, // CPU reads from the vertex buffer, which can neve= r be=20 rendered WriteOnly, // CPU writes frequently to vertex buffer, but neve= r rea d data back }; enum VertexComponent { Coord =3D (1<<0), Normal =3D (1<<1), Tangent =3D (1<<2), Binormal =3D (1<<3), /// constructor nMesh2(); /// destructor virtual ~nMesh2(); /// unload mesh resource virtual void Unload(); /// lock vertex buffer virtual float* LockVertices(); /// unlock vertex buffer virtual void UnlockVertices(); ******************************XML output***********************************= ***** =2E. =2E.. =2E.. =2E.. yaxx on hello world test, xml, dtd follows: int main ( ) { return ( yyparse ( ) ) ; } dtd, hmm this doesn't seem to match much: