I can give a hint: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L97

When Rich did the numerics for Clojure, he decided that everything was going 64 bit at the bottom and it only made sense to support the 64 bit numeric types

Thanks for replying. I am writing some code to manipulate bytes and shorts and if they cannot use invokePrim functions, then it may slow down the speed I think.

Consider using https://github.com/clj-commons/virgil to write the part that is primitive-centric in plain Java and integrate it into your Clojure project

Printing is consistent with (class ...), not (type ...). And only for things that aren't special-cased, so there's plenty of inconsistency there. My bad, was testing on 1.11. Plus, changing how something is printed can break more things that necessary when introducing a new feature. And you can always change how something is printed on your end yourself, if you so desire:

user=> (defmethod print-method (class (long-array [])) [_x w] (.write w "#object[long/1]"))
#object[clojure.lang.MultiFn 0x45f24169 "clojure.lang.MultiFn@45f24169"]

user=> (long-array [])
#object[long/1]

Yeah, I was just wondering if this was an oversight - strange to think that it would be a breaking change as the printed #object representation can't be fed back into the reader anyway

I'm speculating here but I can see how some dev libraries would parse that #object[...] in order to do something.

hmm, I guess one still has to learn the awful [[J / [LClassname; syntaxes either way, to make sense of the error messages originating beyond Clojure's control

user => (longs (into-array [1 2 3]))
;; => Execution error (ClassCastException) at user/eval50 (REPL:1).
;;    class [Ljava.lang.Long; cannot be cast to class [J ([Ljava.lang.Long; and [J are in module java.base of loader 'bootstrap')

I think, the Hiccup macro tries to optimise something at compile time. But as I have a few function calls, this is a hard job for Hiccup. Can I tell Hiccup not trying to optimise at compile time?

@U06HJSACE4C hiccup generates a ton of code, just look at the macro-expansion and be in awe... I have an alternative hiccup here which generates way less code, but still optimizes what it can at compile time. It's not a drop-in replacement since it's more restricted (it doesn't support generating HTML tags from dynamic vectors for example) https://github.com/borkdude/html

for hiccup to not do any optimizations at compile time, you can probably use hiccup.compiler/render-html directly:

user=> (hiccup.compiler/render-html [:a 1])
"1"

What is the p in p/html5?

"method code too large" is a rather ambiguous error message imo. Is that really what it says? The index out of bounds aspect seems 'more' useful. Of course i still have no idea what the issue is, but at least that gives me some idea.

@U0DJ4T5U1 the IndexOutOfBoundsException with "method code too large" is an exception thrown by the asm library (clojure.asm) used by the Clojure compiler when the generated bytecode for a class method goes over the limit defined by the JVM spec (65535 bytes). It is a common exceptions to see on macros which expands into functions with very big bodies that don't fit in a JVM method.

Can the limit be adjusted? Why is there a limit? Fwiw, I'm just curious, i don't have a pain point here myself. Though... That's like 6gbs right? I mean that's a lot lol. Still a modern computer could easily have double that memory on hand yeah?

it has to do with the https://docs.oracle.com/javase/specs/jvms/se6/html/ClassFile.doc.html#1546.

The Code attribute has the following format:


    Code_attribute {
    	u2 attribute_name_index;
    	u4 attribute_length;
    	u2 max_stack;
    	u2 max_locals;
    	u4 code_length;
    	u1 code[code_length];
    	u2 exception_table_length;
    	{    	u2 start_pc;
    	      	u2 end_pc;
    	      	u2  handler_pc;
    	      	u2  catch_type;
    	}	exception_table[exception_table_length];
    	u2 attributes_count;
    	attribute_info attributes[attributes_count];
    } 

That's interesting, I'm trying to wrap my head around this. Thanks for the link!!!

here are those u* types in openjdk C++ files defined https://github.com/openjdk/jdk/blob/fd741a88e8bc73a9db6d4283bb54daab1760b442/src/java.base/share/native/libjimage/inttypes.hpp#L39

on one hand, I imagine that if a macro expands into 65k of bytecode it probably needs redesigning

On the other hand, these hard-wired limits are just so unbelievably annoying. At least this one is reasonable, some time ago I banged my head against Postgres having a 64 character limit for identifiers (which is implemented in the dumbest way possible, PG just silently truncates the string) that is just so incredibly tiny.

h is hiccup.core in my case. I tried with hiccup2.core.html , and that works. macroexpand-all of the hiccup.core version gives me a huge output. It looks like binary data. I think, Calva is not able to work with this output. I have a few macros in the HTML data structure. I think, this confuses Hiccup. I suppose when breaking the html into smaller pieces it would work. So I try this and try to find out what part of the HTML data structure exactly causes the problem. But in principle it is not always good, that Hiccup does this optimisation. Sometime you want to hiccup something that is very danamic.

I found out that this phenomonen is known behaviour of Hiccup (https://github.com/weavejester/hiccup/issues/205 and https://github.com/weavejester/hiccup/issues/210). It looks like Hiccup is a very complicated thing considering the job it does is very simple.

@U06HJSACE4C it's not so hard to write your own hiccup in 20 lines of code (I can dig up one version I used in bb in the beginning) but there's a trade-off between compile time optimizations/performance and the size of the generated code. I believe https://github.com/borkdude/html does a pretty good job balancing those ;)

I was already aware of https://github.com/borkdude/html. I follow a bit what happens in this area. But to be honest, I have really problems to understand what is going on there. That html library comes from Squint and Cherry. And these are things that for me as someone who never did anything like JavaScript or React are very hard to understand. I am still a bit sceptical if this is is the right world for me, because so far I am happy with a naive and very easy approach of server based rendering. Hiccup was for me the first choice. I don't plan to develop public web applications. I only use web technologies for user interfaces for local running applications, because this is easier than all the UI Toolkits, which I used for years. But I will try Squint soon and also the html part of it. I really try to learn what all this is about.

well maybe the description is a bit misleading then, since the html library is just for hiccup -> html generation, regardless of what you are using the html for

I found the answer to my problem. When the code is too complex for Hiccup, I can return a vector instead and at the very end call the Hiccup macro.

that's one way to do it, call the hiccup/html macro on a non-statically known value, which will boil down to the same thing as: https://clojurians.slack.com/archives/C03S1KBA2/p1721584583488159?thread_ts=1721582500.973949&cid=C03S1KBA2