tag:blogger.com,1999:blog-4262147391488425950.post5124384513861801379..comments2023-08-14T03:11:17.311-05:00Comments on ClojureCLR: Code gen redo previewDavid Millerhttp://www.blogger.com/profile/07657040519395296684noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-4262147391488425950.post-42858944281168264822016-11-05T22:31:04.616-05:002016-11-05T22:31:04.616-05:00This comment has been removed by a blog administrator.for ict 99https://www.blogger.com/profile/01234222908168002434noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-28345096184787858722012-08-25T07:57:23.414-05:002012-08-25T07:57:23.414-05:00Next in the queue.Next in the queue.David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-9314460431565807742012-08-23T18:10:20.689-05:002012-08-23T18:10:20.689-05:00Hey Dave, did you ever get a chance to look at my ...Hey Dave, did you ever get a chance to look at my changes? Maybe there's some way we could chat about how to best approach this? I'm wondering if maybe I should create a patch for you rather than trying to merge the branches. aaronchttps://www.blogger.com/profile/15213742152099652024noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-11525693423450046002012-06-19T14:00:10.183-05:002012-06-19T14:00:10.183-05:00There's some pretty ugly history in there. :) ...There's some pretty ugly history in there. :) It was about 30 commits before I got the new code gen to work on core.clj. Then there were the tests. But they are mostly marked by WIP on the comment, so the two people who will look at it (you and me, I'm guessing) will know to go whistling past those commits.<br /><br />My plan after moving the new code gen to master is first to catch up on the last four months of commits on ClojureJVM. This will allow me to get an official 1.4 release out. Your changes are next on the list.David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-5352471003656412222012-06-19T12:32:33.128-05:002012-06-19T12:32:33.128-05:00My vote is to preserve the history. Always better...My vote is to preserve the history. Always better to be able to go back and see what was done.<br /><br />I'll see if I can look at the latest commit soon - will be going on vacation in a few days so it might be tough. Btw, did you get a chance to look at any of my changes?aaronchttps://www.blogger.com/profile/15213742152099652024noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-16187161168777212092012-06-19T11:57:48.239-05:002012-06-19T11:57:48.239-05:00I'm finally ready to push the new code gen ove...I'm finally ready to push the new code gen over to the master branch.<br /><br />The hard question: squash the 65 commits on the nodlr branch down to 2 or 3 milestones or let the master branch preserve history?David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-53035208678337967572012-06-17T22:08:08.311-05:002012-06-17T22:08:08.311-05:00Aaron: Try the latest commit in the nodlr branch. ...Aaron: Try the latest commit in the nodlr branch. I worked on the by-ref problem.David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-40086752057028201592012-05-03T22:47:53.394-05:002012-05-03T22:47:53.394-05:00I'll take a look. I did have to rewrite inter...I'll take a look. I did have to rewrite interop code for this redo, may have mangled it. That's a piece of interop not covered by the standard Clojure tests--a gap I need to fill. Something I'll work on before going live with this work.David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-50277451944653538812012-05-02T19:58:07.966-05:002012-05-02T19:58:07.966-05:00Also, I'm not able to get by-ref working. May...Also, I'm not able to get by-ref working. Maybe it's broken... Looking at the AOT compiled code in reflector it seems like the parameter is being passed with "ref" to the __interop_ method, but no values change. I can't seem to get type hinting to generate code that invokes the method without reflection when I use by-ref.aaronchttps://www.blogger.com/profile/15213742152099652024noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-19985820214366456882012-04-20T11:28:39.573-05:002012-04-20T11:28:39.573-05:00I can leave full compile as the default. As I sa...I can leave full compile as the default. As I said, I may be the only one who really finds light-compile all that useful.<br /><br />Consistency of behavior between eval and AOT-compiled is useful.<br /><br />I'll look at the GenClass situation. Probably an artifact from long ago, not necessary.David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-76583593871259382402012-04-20T09:44:30.863-05:002012-04-20T09:44:30.863-05:00Oh, well if I had to vote, I would keep the defaul...Oh, well if I had to vote, I would keep the default for the repl as it is now (i.e. full compile). 1) I really appreciate the meaningful class names in stacktraces and 2) it more accurately reflects how code will behave when AOT compiled - before, I mistakenly wrote code that I thought was what I wanted because it worked at the REPL, with the new version - although it was frustrating at first, I eventually came up with a better and more performant solution.<br /><br />One other question, is there a reason that GenClass doesn't generate a type in the *.clj.dll assembly and instead creates its own somewhat oddly named .dll? Couldn't it be made to work just like GenProxy where the type is defined dynamically when at the REPL and in the output assembly when compiling?aaronchttps://www.blogger.com/profile/15213742152099652024noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-46453479434569719592012-04-19T10:01:25.800-05:002012-04-19T10:01:25.800-05:00Probably so. Not having made any errors lately, I...Probably so. Not having made any errors lately, I hadn't noticed. :)<br /><br /><br />I was planning on making it switchable in the new version. I may need it more than anyone else. It has an effect when loading the clojure core evaluated during bootstrap compilation. It also keeps devenv.exe from going memory-crazy when running the test suite under the debugger. So, I may be the only one who cares.David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-5662389518425252362012-04-18T21:28:26.984-05:002012-04-18T21:28:26.984-05:00Ok, so is the lack of light compilation the reason...Ok, so is the lack of light compilation the reason why I am now seeing meaningful stack traces for my repl-defined functions? Personally, I'd take the better stack traces over faster compilation.<br /><br />Also, I found another way write my macros that doesn't require that live object and the code is actually faster.aaronchttps://www.blogger.com/profile/15213742152099652024noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-31231424333388510772012-04-18T21:11:39.530-05:002012-04-18T21:11:39.530-05:00You won't be able to embed live objects in com...You won't be able to embed live objects in compiled code without a print-dup method for the type. That is actually true in the current master branch.<br /><br />Light compilation is only used when not compiling. It does not apply to deftypes and related. (Internally, it is only for FnExpr, not for NewInstanceExpr.) Light compilation vs regular:<br /><br />Regular: every fn generates a class<br />Light: simple fns reuse the same class<br /><br />Regular: non-emittable constants are held in static fields in the class for the fn -- require static initialization code.<br />Light: non-emittable constants are held in an array. The value stored in the array is the value passed in.<br /><br />Regular: closed over variables become instance fields in the class for the fn<br />Light: closed over variables accesses become references to a 'closure' array<br /><br />Regular: methods are Reflection.Emit-generated<br />Light: methods are DynamicMethods -- faster generation<br /><br />So the tradeoff is: save a class gen, faster method generation vs array accesses instead of field accesses.<br /><br />Reflection is not an issue -- same in either case.David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-76321510017797144102012-04-18T16:10:54.695-05:002012-04-18T16:10:54.695-05:00So, this might not actually be a problem. Would y...So, this might not actually be a problem. Would you in general say that it is better to not embed the live objects, at least in terms of performance? The reason for embedding the live objects was actually to reduce reflection which may be defeated anyway because of this light compilation.aaronchttps://www.blogger.com/profile/15213742152099652024noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-51981798145139184372012-04-17T21:41:48.820-05:002012-04-17T21:41:48.820-05:00I think the main thing is having the WPF assemblie...I think the main thing is having the WPF assemblies (Presentation Framework, WindowsBase, etc.) loaded in your AppDomain.aaronchttps://www.blogger.com/profile/15213742152099652024noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-76164108872524721322012-04-17T16:37:07.004-05:002012-04-17T16:37:07.004-05:00This is the 'live object' problem. I'...This is the 'live object' problem. I'll have to look at this particular example to see what the deal is. ClojureJVM has the same problem -- it would be interesting to find a parallel example.<br /><br />The reason that it works in the master branch and not in the nodlr branch is that the master branch has a special 'light compilation' mode that uses the DLR to play some tricks that allows embedding of otherwise-disallowed live objects. My last remaining task on this code gen redo is reproducing light compilation without using the DLR. It makes playing at the REPL easier and faster -- you're seeing 'easier' here.<br /><br />Whether or not I pull off light compilation, I'll do a blog entry with the details on what's going on. Your example might well serve as an illustration.<br /><br />Speaking of which: is there anything I need to know in order to pull your code into the REPL for testing?David Millerhttps://www.blogger.com/profile/07657040519395296684noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-22896611384235631362012-04-13T17:32:36.344-05:002012-04-13T17:32:36.344-05:00Mostly looks pretty good. I really like the fact ...Mostly looks pretty good. I really like the fact that functions defined at the repl get a meaningful type name so that the stacktraces are more readable.<br /><br />I'm getting the following error with one part of my code:<br />CompilerException System.InvalidOperationException: Can't embed object in code, maybe print-dup not defined: System.Xaml.Schema.XamlMemberInvoker<br /> at clojure.lang.CljCompiler.Ast.ObjExpr.EmitValue(Object value, CljILGen ilg)<br /> at clojure.lang.CljCompiler.Ast.ObjExpr.EmitConstantFieldInits(CljILGen ilg)<br /> at clojure.lang.CljCompiler.Ast.ObjExpr.EmitStaticConstructorBody(CljILGen ilg)<br /> at clojure.lang.CljCompiler.Ast.ObjExpr.DefineStaticConstructor(TypeBuilder fnTB)<br /> at clojure.lang.CljCompiler.Ast.ObjExpr.Compile(Type superType, Type stubType, IPersistentVector interfaces, Boolean onetimeUse, GenContext context)<br /> at clojure.lang.CljCompiler.Ast.FnExpr.Parse(ParserContext pcon, ISeq form, String name)<br /> at clojure.lang.Compiler.AnalyzeSeq(ParserContext pcon, ISeq form, String name), compiling: (NO_SOURCE_PATH:50) <br /><br />This is in a library I am writing for creating WPF apps in Clojure. With all the appropriate WPF assemblies (PresentationFramework, etc.) loaded and this namespace loaded https://github.com/aaronc/ClojureWpf/blob/master/ClojureWpf/core.clj, entering something like (caml (:StackPanel (:TextBlock))) at the REPL will produce the above stacktrace. The code works fine with the ClojureCLR master branch. Other than that, most things seem to load up just fine. If there is anything I can do to help with debugging this, let me know.aaronchttps://www.blogger.com/profile/15213742152099652024noreply@blogger.comtag:blogger.com,1999:blog-4262147391488425950.post-76485254314933561612012-03-27T01:55:46.801-05:002012-03-27T01:55:46.801-05:00Come on, Hero!Come on, Hero!wizzardcloudhttps://www.blogger.com/profile/16081816130579063615noreply@blogger.com