I saw that workaround, but I’m hitting the much harder 255 ext4 (and every
other major Linux filesystem) limit than the limit ecryptfs introduces by
layering on top of other filesystems. It’s a big match statement :-)
A lot of the match clauses could be case clauses. They’re just not because one
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
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
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-sys
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
filename
