Fork me on GitHub

this sort of skips some bits, but here's a draft


I'm getting this with the windows executable:

PS C:\Users\roger\Downloads\clj-kondo-2019.11.08-SNAPSHOT-windows-amd64> cat .\foo.clj
(def x (def x 1))

PS C:\Users\roger\Downloads\clj-kondo-2019.11.08-SNAPSHOT-windows-amd64> .\clj-kondo.exe --lint .\foo.clj
.\foo.clj:1:1: error: unresolved symbol ??
.\foo.clj:1:12: error: unresolved symbol x
.\foo.clj:1:16: error: unresolved symbol
.\foo.clj:1:18: error: unresolved symbol def
.\foo.clj:1:30: error: unresolved symbol 1
linting took 16ms, errors: 5, warnings: 0


Although the very first test worked:

PS C:\Users\roger\Downloads\clj-kondo-2019.11.08-SNAPSHOT-windows-amd64> echo '(def x (def x 1))'| .\clj-kondo.exe --lint -
<stdin>:1:8: warning: inline def


@roger429 can you maybe share that file?


you mean the foo.clj?


@sogaiu thanks, good start :-)


@roger429 I think there might be something wrong with that file? When I lint it locally (thanks for sending it):

$ clj-kondo --lint ~/Downloads/foo.clj
/Users/borkdude/Downloads/foo.clj:1:1: error: unresolved symbol ��
/Users/borkdude/Downloads/foo.clj:1:12: error: unresolved symbol x
/Users/borkdude/Downloads/foo.clj:1:16: error: unresolved symbol
/Users/borkdude/Downloads/foo.clj:1:18: error: unresolved symbol def
/Users/borkdude/Downloads/foo.clj:1:30: error: unresolved symbol 1
linting took 120ms, errors: 5, warnings: 0


$ cat ~/Downloads/foo.clj
��(def x (def x 1))


hmm, in Emacs it works fine. It might be the Unix vs Windows line separator issue?


This is what I see in hexl-mode:

fffe 2800 6400 6500 6600 2000 7800 2000  ..(.d.e.f. .x. .                  


So the first character is fffe which is not a valid Unicode character?


VSC shows that file to have an UTF-16LE encoding (little endian?). Probably has to do with the way Powershell pipes the result of echo into the file. I created a file in VSC and it has UTF8 encoding. That file is handled as expected by clj-konde.exe.


The UTF-8 file is 17 bytes; the UTF-16 LE 36 bytes: double the UTF-8 + a BOF marker or some such thingy.


Do you have more suggestions for testing on windows?


@roger429 You could try @marc-omorain's clojure-lint plugin in VSStudio and disabling the clj-kondo plugin. When you have clj-kondo.exe on the path, it should use that I think


I'll have a go with that tonight


also linting a classpath could be a nice test:

clj-kondo --lint $(lein classpath)


@sogaiu feel free to PR your flow diagram including the sources. And feel free to improve it over time


ok. any specific feedback? e.g. technical inaccuracies or omissions? aesthetic points fine too 🙂


I think it's better to discuss in a PR, since Slack gets a little bit all over the place for me

👍 1
Marc O'Morain12:11:16

I’ve never tried my plugin on Windows - so YMMV. Please do try it though.


I wonder if it will recognize the binary correctly... .exe is different from other platform names


if clj-kondo was a commercial product, I would buy a windows machine to test 😉

Marc O'Morain12:11:45

Windows has Opinions about binary names. We had fun porting our golang “build agent” at CircleCI to Windows.

Marc O'Morain12:11:31

We first ran the Linux version of the code on Windows, - we copy the binary into a tmp folder, and invoke it. c:\tmp\build-agent

Marc O'Morain12:11:47

but that’s won’t execute - you need to name it .exe 😂

Marc O'Morain12:11:13

but you can invoke the binary without specifying .exe

Marc O'Morain12:11:47

Windows will see if the path that you are invoking has a corresponding .exe or .cmd file, and it runs that.


then with a little bit of luck it should already work on Windows I guess


I would test this in a Windows VM, but for some reason VirtualBox crashes often on my new Macbook Pro


as in: totally crashes the machine, hard reboots it


Maybe in Catalina things are better, but I'm also afraid to upgrade to that 😛

Filipe Silva12:11:26

binary execution on windows is further complicated by the fact that some extensions are only picked up from a given shell


there is no global path variable?

Filipe Silva12:11:44

it's just that .cmd files won't run without a windows shell

Filipe Silva12:11:06

neither will bat


ah... hm. maybe that also conflicts with how scoop does things, because it makes these .cmd wrappers?


what a pain

Filipe Silva12:11:35

so depending on how you try to spawn the process, it might fail to find some executable

Filipe Silva12:11:13

I understand the feeling from a maintainers point of view, but from a consumer POV it is also a pain that half the open source software doesn't work on windows

Filipe Silva12:11:55

everyone can install linux, but in practice development happens not on linux but on mac


Please don't claim your experiences are the same everyone else has. I have done all my professional development work, since 1997, on Linux. Working around Europe I noticed most development machines my colleagues had were a ThinkPad running Linux. I would not presume to tell anyone that there is only one machine that development is done on, as it would make me sound quite arrogant.

Filipe Silva18:11:15

you know what, I was totally wrong to assume that and should have copped on when I linked the stack overflow survey

Filipe Silva18:11:38

it showed 50% windows, 25% osx, ~25% linux

Filipe Silva18:11:04

my experience was indeed most of my colleagues were on osx and I was always the lone windows

Filipe Silva18:11:26

but I guess that's mostly a siloed thing, where whole places buy in to one OS or another

👍 1
Filipe Silva12:11:08

so it ends up almost being a matter of privilege

Filipe Silva12:11:25

if you don't work on a mac, you're a second class citizen in the open source world 🙂

Filipe Silva12:11:20

I don't hear this topic being discussed as much but I think it ended up being yet another mac-related lock-in

Filipe Silva12:11:19

windows sure could be easier to work on but at the end of the day windows hosts around half the developers


I would disagree with that statement development happens not on linux but on a mac


That's a very sweeping generalisation. At our place of work, it's 99% linux, with one windows machine.


There may be many more people using mac's - but how many of those are using mac's for the adobe range of software, rather than just cutting code.


Also, there's probably a reason why people gravitate towards linux or mac for development. The shell experience has been behind for years in Windows.


In regards the stackoverflow survey, 1. it's stackoverflow so inherently biased and 2. what is the error margin? One survey does not make a statement about fact.


I've never considered myself a second class citizen by using linux (and I also have a few macs) - I would indeed argue with the recent changes that Apple are pushing out to developers with the changes to their OS, life for a developer on mac's is becoming more difficult! I've always found - as a linux user - to be catered for in terms of development - software, documentation, processed, tools - everything I need is available on Linux. I've never had to go scrambling to a Mac to continue working.


interested in seeing what kind of quantified evidence there is for "development happens not on linux but on mac" -- a bit broad perhaps too. in terms of actually making command line tools, my impression has been that stuff gets ported to the mac, but often starts on some other *nix. i wonder if there is some way to comb repository histories for evidence.


i've used macos on and off for a while, but for the kinds of things i wanted to do, found i often had to reach for another *nix because what i wanted wasn't available for macos (yet). may be this would make an interesting topic for #off-topic.

Filipe Silva18:11:51

@jr0cket called me out on that as well, and it true: that was an unwarranted generalization based on my experience

Filipe Silva18:11:33

but to be fair I never argued that Linux users were second class to mac users, I argued that windows users are second class in open source (on the topic above)


To err is human, to correct that error is divine 😁

Filipe Silva18:11:16

I think linux is a first class citizen in open source, because it's the gold standard for where the software should run


thanks for pointed out the topic above -- had not digested it 🙂


still think it would make for an interesting discussion on #off-topic -- not to mention an interesting study (especially if evidence could be gathered in a semi-automated fashion)


i would argue that closed source operating systems compose way worse with open source development systems. linux is still poor, it is no match to the integration lisp machines had, but at least you can go in and adapt parts, if needed. despite all the open source propaganda from microsoft they still have not open sourced any of their core infrastructure. they just make it convenient enough for people to integrate all the free labor on their platform so that they don't become obsolete


that is the same strategy that apple has used to great success. yet i would never consider running infrastructure on macs, because you have to buy into a giant black box.


i also would like to say that countless open source man years have been put into proving the microsoft model of developing software wrong. that they have adapted does not mean that they are really for open source. the github source code is also not open source for instance, although it would be maybe the most logical thing to do from an open source perspective.


i think times have changed and the terms of this struggle are shifted because of the role of data, but it is important to be aware of who has brought us the open source world and what a pain it was 15 or 20 years ago