> To those who are going to EuroClojure: are you going to have a re-tooling meetup?
Good idea. It’s a pity I won’t be there. Have very little time for Clojure these days, but I do keep an eye on what’s going on here from time to time.
> what’s your take on Stu’s “swing is great for dev tools”?
Java Swing?
> Java Swing Yes :) see this talk
I’ve opened it in my browser, guess I’ll have to find the time to see it. Funny enough I was a Swing dev for a pretty long time back in the day - it’s still my favourite GUI toolkit, but knowing how buggy it is I wouldn’t call it exactly “great”. There’s a reason why IDEA and NetBeans are only major dev tools written in Swing.
(or to be more precise - the only ones having a Swing UI)
@bozhidar I've never been much of a GUI dev, what makes Swing your favorite toolkit despite its bugs?
The API is really simple, it’s based on ideas from MVC. There are a also a ton of layout management options that don’t require using a GUI designer and XLM (eg MiG) and with the pluggable look and feels you can make an application look like a Windows, Cocoa or GTK app.
I personally worked with Eclipse databinding facilities and I found them fascinating
It was the early Angular2
@cgrand https://github.com/pallet/ritz something about JPDA debugger & Clojure. No idea if that's useful to continue your previous line of work?
https://github.com/pallet/ritz/tree/develop/debugger probably should link this really.
Just wrappers around jdi, not worth adding as a dependency. JDI API is ok to deal with directly. In Poucet there's some added complexity because tooling jars are not on the jvm class path and also because the debugger and debuggee are the same vm.
Acrobatics (unpublished yet) to mirror or "unmirror" objects doesn't usually happen since mirrors and their target live in separate processes.
I was thinking more about the issues you had with a debugger. I wasn't sure if they had solved it. I might be misremembering though
The only issue I had was with Clojure forgetting to write debug info.
@dominicm this was debugger which was intended to be used with CIDER via nREPL middleware. Hugo even did a presentation about it at Clojure/conj a few years ago. When he stopped maintaining we looked at the code and we decided take some inspiration from Lisp debuggers instead and ended up with the current CIDER debugger.
Interesting. @bozhidar I'm curious to know if there's anything you specifically remember about JVM vs Lisp debuggers that stood out as important.
Actually this started as a plugin for SLIME, then it was ported to nREPL
Anyways, the presentation has much more info.
And this https://github.com/razum2um/clj-debugger and edebug were our inspiration with CIDER
Basically we wanted to focus on instrumenting Clojure forms instead of on the underlying machinery as Hugo had
In theory it would be relatively easy to port the CIDER debugger to cljs, but as both of us had almost no time to work on open-source this remained hanging in the air
Will check it out when I get a chance
https://github.com/clojure-emacs/cider/blob/master/doc/debugging.md#internal-details
I think you’ll find this interesting.
That part of the doc seems like it belongs in cider-nrepl 😛
It is interesting.
@plexus did you end up writing an edn parser for elisp or you are using the old one for unrepl?
We're working on it
https://github.com/lambdaisland/clj-parse/blob/master/DESIGN.md