Fork me on GitHub
#clj-kondo
<
2019-11-03
>
lee18:11:42

I did a small amount of poking around with regards to max files. It seems there is a bit of weirdness around macOS https://github.com/neo4j/neo4j/issues/11739#issuecomment-421333078. I thought maybe graal could be influenced by MaxFDLimit but did not find a way. one thing to note is that ulimit affects process and sub-process so a work-around might be to wrap like so:

#!/usr/bin/env bash
set -eou pipefail
ulimit -n 10000
./lockrepro

borkdude19:11:49

yeah, I think the main issue with graal is that it doesn't throw the right exception/message when you hit the limit

alidcastano21:11:30

i'm getting an No matching clause: :boot in a build.boot file. is there a way to fix typing for this file, or at least disable the error?

borkdude21:11:38

@alidcastano I assume this is inside some editor integration?

borkdude21:11:53

or is this from the command line?

borkdude21:11:58

If you're using flymake instead of flycheck in emacs, there's now a plugin for it: https://github.com/turbo-cafe/flymake-kondor

alidcastano21:11:39

@borkdude i'm using vscode's calva extension

borkdude21:11:24

@alidcastano Thanks, I'll make a fix.

borkdude22:11:31

@alidcastano should be fixed in plugin version 0.0.8

borkdude22:11:41

false positives are expected in build.boot files, because it uses non-standard functions names that aren't imported using a namespace form, but at least you won't get this error anymore

borkdude22:11:04

clj-kondo could try to improve on linting build.boot files though

pez22:11:18

There seem to be some special handling of project.clj files in place, right?

pez22:11:19

Maybe it just ignores anything in the defproject form?

borkdude22:11:03

it ignores unresolved symbols in project.clj

borkdude22:11:20

there might be errors that it will still detect, like maps with duplicate keys

borkdude22:11:11

it doesn't do any syntax checking special to leiningen, although that could be added