From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 991F17FD07 for ; Thu, 30 Apr 2015 22:58:10 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of omeragacan@gmail.com) identity=pra; client-ip=209.85.212.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="omeragacan@gmail.com"; x-sender="omeragacan@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of omeragacan@gmail.com designates 209.85.212.176 as permitted sender) identity=mailfrom; client-ip=209.85.212.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="omeragacan@gmail.com"; x-sender="omeragacan@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f176.google.com) identity=helo; client-ip=209.85.212.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="omeragacan@gmail.com"; x-sender="postmaster@mail-wi0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgAQAtl0JVm7DUVdFcg19cBYMWuhyJcYYIAoFQBzwQAQEBAQEBAREBAQEBAQYLCwkhLoQhAQEEEhEEGQEbHgMMBgULDQICJgICIQEBEQEFARwGEyKHdAEDEQ2oVz4xizmBa4J2iQEKGScNVYRKAQEIAgEZAQUOgROKF4JNHoFnOoJogUUFhkiPK4RrgVSBYI1ChRESI4EMCYIqHIFtIjGCRQEBAQ X-IPAS-Result: A0CgAQAtl0JVm7DUVdFcg19cBYMWuhyJcYYIAoFQBzwQAQEBAQEBAREBAQEBAQYLCwkhLoQhAQEEEhEEGQEbHgMMBgULDQICJgICIQEBEQEFARwGEyKHdAEDEQ2oVz4xizmBa4J2iQEKGScNVYRKAQEIAgEZAQUOgROKF4JNHoFnOoJogUUFhkiPK4RrgVSBYI1ChRESI4EMCYIqHIFtIjGCRQEBAQ X-IronPort-AV: E=Sophos;i="5.11,678,1422918000"; d="scan'208";a="138388282" Received: from mail-wi0-f176.google.com ([209.85.212.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Apr 2015 22:57:58 +0200 Received: by wiun10 with SMTP id n10so31551784wiu.1 for ; Thu, 30 Apr 2015 13:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=0NEzba7T8Q9ZUDuAMMt5438AgOCcV+Cy+xhnPIu+6AE=; b=ZlKS2aWmc7B28y1K4/Jv/VcOBO+GqTDrikEgVoQeipoBNbIlSRwg9v63Lk9LHMeF79 L8zAi259FolOKQeCaiW5Wl+6+cR/l6Jo1lxdAYIQuCIAOZf52F6/IQJVhq+gB8QarALe WCsuQF4qcqSd6t5Z3n/DNe/g61q8UHQ6alqJmgFY5KjpBvdjm2x/q6oIPW5L+dk24Q1I xAE1uEWBqa52x2PhRkePRq+IRCQp5LueBK13R9bH2XxQq9TcNURTIXNjTazKR7ZJFOnb YjM7iYIDV6TxKuarZ8znjvnGyW7q0Tu+mj7cXUOdSSJFeSnRCel3NVIVv1MwUF0fOeph yERw== X-Received: by 10.180.91.76 with SMTP id cc12mr9034235wib.67.1430427478588; Thu, 30 Apr 2015 13:57:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.187.212 with HTTP; Thu, 30 Apr 2015 13:57:18 -0700 (PDT) In-Reply-To: References: <5542880D.2060008@mcmaster.ca> From: =?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?= Date: Thu, 30 Apr 2015 16:57:18 -0400 Message-ID: To: OCaml Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Problems with printing MetaOCaml generated code Let's talk on an example: -- contents of TestData.ml type foo =3D Foo of int -- contents of main open TestData let global_ref : int ref =3D ref 0 let gen_inc =3D .< let _ =3D global_ref :=3D !global_ref + 1 in () >. let gen_read =3D .< !global_ref >. let gen_write i =3D .< match i with | Foo i -> global_ref :=3D i >. let gen_cls_wrt cls =3D .< global_ref :=3D cls () >. let f_toplevel () =3D Random.int 10 let _ =3D print_string "\n----------------------------\n"; let _ =3D Print_code.print_code Format.std_formatter gen_inc in print_string "\n----------------------------\n"; let _ =3D Print_code.print_closed_code Format.std_formatter (Runcode.close_code gen_inc) in print_string "\n----------------------------\n"; let _ =3D Print_code.print_closed_code Format.std_formatter (Runcode.close_code (gen_write (Foo 10))) in print_string "\n----------------------------\n"; let _ =3D Print_code.print_closed_code Format.std_formatter (Runcode.close_code gen_read) in print_string "\n----------------------------\n"; let f () =3D Random.int 10 in let _ =3D Print_code.print_closed_code Format.std_formatter (Runcode.close_code (gen_cls_wrt f)) in print_string "\n----------------------------\n"; let _ =3D Print_code.print_closed_code Format.std_formatter (Runcode.close_code (gen_cls_wrt f_toplevel)) in print_string "\n----------------------------\n"; () MetaOCaml does some very interesting/weird stuff here: * In printed code it doesn't always show the CSP values, it just says "CSP global_ref" for example, but it does that only sometimes. As an example, = it does that for global_ref, but doesn't do that for f_toplevel. I don't understand how are these two any different. I can refer to top level names but only sometimes... It shows the CSP values in some simple cases, for example if the value is= an int than it just shows the literal. (not shown in this example) * I don't know if this is MetaOCaml related, but output of this program is interleaved. Instead of printing a line than code it prints two lines and then two code etc. How is this possible?? For the reference, the output I'm getting: =E2=9E=9C metaocaml_test git:(master) =E2=9C=97 ./a.out File "metaocaml_test.ml", line 17, characters 19-22: Warning 22: The CSP value is a closure or too deep to serialize File "metaocaml_test.ml", line 17, characters 19-22: Warning 22: The CSP value is a closure or too deep to serialize ---------------------------- ---------------------------- .. .< let _ =3D (* CSP global_ref *) :=3D ((! (* CSP global_ref *)) + 1) in ()>. ---------------------------- .< match (* CSP i *) with | TestData.Foo i_1 -> (* CSP global_ref *) :=3D i_= 1>. ---------------------------- .< ! (* CSP global_ref *)>. ---------------------------- .< ---------------------------- (* CSP global_ref *) :=3D ((* CSP cls *) ())>. .< (* CSP global_ref *) :=3D ((* CSP cls *) ())>. ---------------------------- 2015-04-30 16:25 GMT-04:00 =C3=96mer Sinan A=C4=9Facan : > Thanks for the answer. > > My main problem is not that some generated code are not printable -- rath= er, > it's not clear at all when a code is not printable. Now I have to play ar= ound > with code until suddenly it's printable... > > Certainly not all code is printable even in theory, for example, what hap= pens > if my generated code captures a file handle from code generator? Or a heap > object that's completely opaque to runtime system.(no type information et= c.) In > those cases it may be possible to directly run the code but it's not poss= ible > to print it. > > But IMHO MetaOCaml should have done a better job at reporting those. Or at > least at least documenting when it's not possible. > > I guess I have to play around and see if some of my random changes make it > printable. > > --- > =C3=96mer Sinan A=C4=9Facan > http://osa1.net > > > 2015-04-30 15:52 GMT-04:00 Jacques Carette : >> You will have some difficulties printing complex closures, especially wh= en >> they refer to values built in the generator (CSPs) which are not simple >> values (strings, integers, etc). >> >> Sometimes, very simple changes to the generator can allow closures and C= SPs >> to be printable or not -- without very specific examples, I can't help (= it's >> been a few years since I dug into this deeply). >> >> I have been able to print rather complex, large codes with metaocaml. B= ut >> one has to structure the generator rather carefully to ensure this >> possibility. >> >> Jacques >> >> >> On 2015-04-30 14:36 , =C3=96mer Sinan A=C4=9Facan wrote: >>> >>> Hi all, >>> >>> I'm working on a MetaOCaml program and I want to save generated programs >>> to >>> files instead of directly running them within the same program using >>> `Runcode.(.!)` or `Runcode.run`. The problem is MetaOCaml never prints >>> generated code, it's always failing with `Warning 22: The CSP value is a >>> closure or too deep to serialize`. >>> >>> I can't see anything related in it's web page: >>> http://okmij.org/ftp/ML/MetaOCaml.html. What I understand from that page >>> is >>> once I have a closed code, I should be able to print it no matter what. >>> However in my experience even the simplest realistic MetaOCaml program >>> fails to >>> generate the code because of this error I mentioned above. >>> >>> (One thing to note here is that my program generates the code on a coup= le >>> of >>> inputs, but fails in most of them with this error message.) >>> >>> In "Many ways to run the code" section it's said that "Since closed code >>> is >>> essentially OCaml AST, after closing the generated code, the user may >>> examine >>> and `run' it in many ways. One way of running the code is printing it." >>> and >>> then it lists some API functions for printing. In my experience none of >>> them >>> really work, I have closed code which I successfully closed using >>> `Runcode.close_code`, but `print_closed_code` is still failing with the >>> error, >>> and `print_code_as_ast` is printing something that definitely doesn't l= ook >>> like >>> an AST for any imaginable programming language.(okay... I might have >>> exaggerated a bit, but it's definitely not OCaml AST and it contains so= me >>> references to generator program source, like "Generator.ml[248]" for >>> example) >>> >>> One relevant thing I could find in the documentation is this: "If the c= ode >>> includes CSP only as literals or external references (and any code can = be >>> arranged that way), the code can be stored into a file and then passed = to >>> ocamlopt." If we remove this sentence from the documentation, I don't >>> think it >>> mentions about any possible failures in code printing. >>> >>> So now that I've expressed my frustration about this, I guess my main >>> question >>> is: In what cases does MetaOCaml prints generated code? In what cases it >>> doesn't? Note that it fails to generate code even after calling >>> `print_closed_code (close_code ...)`, so being closed or not doesn't se= em >>> very >>> relevent here. Is this a bug in MetaOCaml? Are there any workarounds? A= ny >>> ideas >>> what am I doing wrong? >>> >>> Thanks in advance for any answers, >>> >>> =C3=96mer >>> >>