Rename SchmetICantFuckingSpellThis to Zergling.

[bitemyapp]

Unless it uhhh, has some sentimental value to somebody that speaks German or something.

[bitemyapp]

06:29 < bitemyapp> ~zergling 06:29 < clojurebot> zergling is https://github.com/prismofeverything/schmetterling

[yayitswei]

+1

[prismofeverything]

I do speak German! It is also kind of sentimental, and I have been working on an awesome butterfly logo.

I do see now that it is not the most accessible name. Let me ponder this... it probably won't be zergling either (as swarms of tiny creatures does not match the theme of what it does really). The butterfly thing really fits in my mind as it is like something hatching out of the cocoon of the original process (maybe it is just me).

Can you find a way to embrace the word into your heart? It is a pretty awesome word. And spelling just takes practice really... (though I will consider alternatives)

[bitemyapp]

Well, it's your baby, you can name it whatever you want, but I'm going to keep calling it Zergling in the IRC channel (#clojure on FreeNode) and the factoid is already named zergling :)

Also, this is a heads up that this should probably get refactored into an nrepl client/server so that Emacs/vi/CCW/etc users can use this in their native environment, with the browser frontend talking to the same nrepl backend as everybody else.

[prismofeverything]

Ha! Well that is as good a code name as any.

As for nrepl, I originally wrote it that way but ran into some issues which made me feel like nrepl was not a good fit.

First, in order to work there have to be two jvm's running, one being debugged and the other doing the debugging. The debugging process waits for an exception to be thrown, and then kicks into action. I am not sure how this kind of sleep/grab execution flow would work with nrepl in the various settings it is inserted in.

Second, on exception schmetterling throws up a stacktrace with an interactive repl at each frame. Nrepl has just one repl, so there would have to be some facility to navigate repls up and down frames... which seems to be forcing things.

Also, schmetterling shows the source for each frame, which could be shown in nrepl as you navigate up and down frames, but it would be very awkward to just either print or swap out as you are navigating frames, rather than just seeing all the frames and the source for each frame as you open them.

It all seemed like a lot of impedance mismatch. For this reason I switched to making it a browser based debugger where I could build a fitting UI that wasn't bound by nrepl limitations and do everything it needs to do.

I see the value of making it an nrepl middleware however, so I am open to any suggestions of how to solve these apparent mismatches between schmetterling and nrepl!

[bitemyapp]

That's not a good excuse for not using the standard protocol that tooling uses to communicate. The web frontend could've just talked to the backend exposing the debugger via nrepl. If the protocol needs enhancements, just ask them, don't make tools that can't integrate with anything else.

This stuff requires effort, if it were easy, everybody's tools would just work.

This sort of thing is why Clojure has such a terrible story for tools.

[prismofeverything]

Is nrepl the standard protocol for tooling? I was under the impression it was just one protocol, specifically for a single repl (not multiple at once).

What I am saying is that the nrepl concept doesn't fit well with what I am trying to do. Changing nrepl to accommodate this workflow seems like it would add a lot of complexity to nrepl for just a single application, and not really fit with the spirit of nrepl in the first place.

Though as I said, I am open to suggestions that address my concerns about why they don't fit. As in, constructive feedback : )

[bitemyapp]

It is the standard protocol for tooling and it's not even really just about REPLs. A repl is just the default mode of "consuming" a service. Ritz, which solves a similar problem to zergling, was designed to be exposed over nrepl.

[noisesmith]

I think supporting the nrepl protocol is a good idea. I don't feel like doing to work to adapt the Schmetterling UI to other frontends, but I think that exposing the events via nrepl so that someone else can attempt to make said UI is just fine.

Also, I would contest that Ritz does not solve the problem Schmetterling does. Schmetterling is designed to be an easy drop-in way to inspect errors in a running application in an external process without adding dependencies or altering your code. This leverages the existing attach-to-process design of JDI and keeps things simple. Ritz is an attempt to make JDI debugging act like the common lisp debugger. There are fundamental differences to the underlying architectures (common lisp versus the jvm) that make Ritz more complex than it should need to be.

[bitemyapp]

We're all here because we didn't like Ritz. They solve a similar problem, the implementation varies.

The JDK debugger functionality should be exposed over a reusable nrepl API so that other tools can integrate it (Emacs, vim, sublime, etc)

[bitemyapp]

20:45 < technomancy> bitemyapp: there's no cider support in zergling tho

Which requires support for the nrepl protocol.

[prismofeverything]

< technomancy> bitemyapp: there's no cider support in zergling tho < bitemyapp> technomancy: I am harassing the shit out of him about that right now

I'm on IRC as well : )

I can't say your attitude really inspires motivation. I have witnessed the indignation and sense of entitlement levied against open source projects before, but now I have experienced it first hand! So thank you for that.

I would like to support nrepl, and I am curious about how that could work. If you want to help, then I am open to any suggestions. Otherwise, maybe you can harass someone else into helping you! Maybe others respond well to that kind of thing.

[bitemyapp]

@prismofeverything If you wanted to get offended, you don't have to contrive it from a flippant comment in IRC.

Closing this for wontfix, moving onto the next issue.