On 02/24/2016 02:53 AM, Michael du Breuil wrote: > The following (this is interop with libgdx if anyone is curious, > hud-corner-top-left is a delayed TextureRegion > > (.draw batch ^TextureRegion @hud-corner-top-left > (float -199) > (float -32)) > > Which yields the following: > > .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()), > > RT.uncheckedFloatCast(-199L), > RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)
I think the best response to this is a far more polite than I can manage "so what?". Which is not to imply that was meant to be impolite, just as a way to prompt for more, it can seem impolite. Bytecode is a means to end, the execution of Clojure on the JVM. So in some sense, who cares what it looks like, as long as Clojure is running well. The most common answer to "Why does the bytecode look like this?" is going to be something like "It was the easiest bytecode to generate for the given Clojure code". What you really should be asking yourself here is, why when you call the function `float`; which is a Clojure function, held in a var, represented as an Object implementing IFn, does all that var lookup, and IFn invocation code disappear and is replaced with one call to the static uncheckedFloatCast method. Is this a quantifiable issue, or an aesthetic issue to you? If it is an aesthetic issue, I would not expect other people to care that much about it one way or another. Which means if you want to change it, you need to write the patch yourself, and hope the patch gets reviewed and accepted. If you do end up writing a patch, please also add uncheckedFloat to Intrinsics.java. If it is a quantifiable issue (these are usually performance issues), many more people will care about it, and someone else may care enough to write a patch. I would be really surprised if this effects performance at all, since it seems like the kind of a jit would eat for breakfast, but I am far from an expert, so who knows. > > Unless I'm missing something on how to interpret bytecode :) I can post > more source if you want but that is one interop call and its generated > code, the rest will look the same. > > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote: > > Can you post the code? > > > On 24 Feb 2016, at 10:26, Michael du Breuil > <wicked.she...@gmail.com <javascript:>> wrote: > > > > I have some interop code that I have carefully specified all the > arguments to be in the correct type (IE the function signature takes > 3 floats, so I cast everything to float so that I can avoid > reflection). What I'm surprised by is compile time constants such as > (float -173) or (float 8.5) are not saved as the correct primitive > type, using jd-gui I see that these were actually turned into > RT.uncheckedFloatCast(-173L), and RT.uncheckedFloatCast(8.5D), > respectively. Why isn't this just saved as a the correct primitive > directly in the generated bytecode? This is with clojure 1.8.0 > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clo...@googlegroups.com > <javascript:> > > Note that posts from new members are moderated - please be patient > with your first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > <http://groups.google.com/group/clojure?hl=en> > > --- > > You received this message because you are subscribed to the Google > Groups "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, > send an email to clojure+u...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to clojure+unsubscr...@googlegroups.com > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
