Laurens: I know on Clojurians Slack you pointed out this repository: https://github.com/simonpure/clojure-match-io-exception
This is not really an issue on a file system that can have very long file names. My recommendation is if you can arrange that, you should be good to go. There is a 'quick workaround' section in the README of the repository above showing one way to do that on a Linux machine, if your base Linux kernel imposes file name length limitations that are being exceeded (apparently some encrypted Linux file systems have such limits). I haven't seen the file system name issue on a Mac OS X system. I haven't tried Windows to know what its file name length limitations might be, or whether there are similar workarounds to enable longer file names. There are a couple of relevant Clojure JIRA tickets I know of, which anyone is welcome to vote on, but waiting for them to be resolved before deciding what you are going to do about this issue doesn't seem like a viable approach. Kevin Downey has worked on patches for the Clojure ticket https://dev.clojure.org/jira/browse/CLJ-701 that change the Clojure compiler so that instead of wrapping various things in (fn* ...) that the compiler does today, instead creates separate methods for those things. I don't know how production-worthy any of them are, but the comments seem to imply that there are non-working edge cases for those approaches at the moment. You can vote on that issue https://dev.clojure.org/jira/browse/CLJ-1852 comments mention some ideas of changing the Clojure compiler to use shorter class file names, e.g. via hashing the contents of long names to shorter ones. Andy On Sun, Oct 7, 2018 at 10:42 AM Andy Fingerhut <andy.finger...@gmail.com> wrote: > I was able to fork your repo and created a different 'growing expression' > that nests each one inside the 'catch' clause of the enclosing try > expression, which is what the macro-expansion of core.match `match` > expressions do as they get longer. > > It shows that the longest class file names are getting longer. I believe > that at least the body of the catch clause is enclosed in a new function by > the Clojure compiler, if not the main body of the try. > > https://github.com/jafingerhut/nestedrepro > > Andy > > > On Sun, Oct 7, 2018 at 8:36 AM Laurens Van Houtven <_...@lvh.io> wrote: > >> FWIW: I tried to reproduce it here: https://github.com/lvh/nestedrepro >> but I was unable to cause these sorts of errors using try/catch and do. >> >> On Sat, Oct 6, 2018 at 6:17 PM Laurens Van Houtven <_...@lvh.io> wrote: >> >>> I'm hitting CLJ-1852 [0] (Clojure-generated class names length exceed >>> file-system limit) with a large core.match expression. I have verified that >>> it is the number of clauses in core.match: compilation works as soon as I >>> reduce it, and looking at `target/` it is actually producing very long >>> filenames a la: >>> >>> >>> 'iddqd$xyzzy$fn__19779$fn__19788$fn__19789$fn__19790$fn__19793$fn__19794$fn__19795$fn__19796$fn__19797$fn__19814$fn__19815$fn__19816$fn__19819$fn__19820$fn__19823$fn__19824$fn__19825$fn__19826.class' >>> >>> However, I don't quite understand _why_ core.match produces such long >>> filenames. The error and filename suggest the problem is deeply nested >>> fn*s. Judging by macroexpand-all it's just a ton of let and try/catch which >>> I'd expect don't compile to fn*s internally (I'm aware of the equivalent >>> between let and lambda but I expect that's not really how it's >>> implemented). I am trying to understand why it's producing all of these >>> nested fns as compiled classes to see if I can somehow work around this >>> (without rewriting the function completely, hopefully!). >>> >>> I've found a similar reproducer here[1]. Unfortunately it doesn't do a >>> better job explaining _why_ the compiler emits that. Any tools for helping >>> me understand the compiler would be helpful. I'm already quite comfortable >>> with JVM bytecode and asm. Is the best way to figure this out just to read >>> Compiler.java? >>> >>> >>> [0]: https://dev.clojure.org/jira/browse/CLJ-1852 >>> [1]: https://github.com/simonpure/clojure-match-io-exception >>> >>> -- >> 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. >> > -- 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.
