anyone know what software are these nice ASCII graphs made of? https://github.com/binaryage/dirac/blob/master/docs/about-repls.md#the-lisp-machine

@linshuai2012 https://monodraw.helftone.com/

Would it be possible to support custom formatting of values received over WebSockets? E.g. I'm using https://github.com/ptaoussanis/sente that can send e.g. EDN or transit via a WS connection. Transit is more or less tolerable when sent in its verbose form (not sure how DevTools understands that it's JSON). But its packed form is rather hard to read. EDN is readable but not browseable - it's just a string since the browser has no idea how to work with it.

@p-himik this? https://github.com/binaryage/dirac/issues/37

Ah, I was looking for WebSockets so didn't find it. Yeah, more or less the same. Although I'm not sure if supporting WebSockets could be handled with the same code as for regular requests since there's no content-type attached to messages. Also, the "Transit EDN" phrase confuses me a bit since tansit and EDN are different formats.

by “transit EDN” I meant the packed form

I see. I'm definitely interested in that, plus regular EDN. 🙂 On a separate note - I started looking at how it would be possible to implement it in Firefox since its dev tools appear to have matured more or less to the comparable level to Chrome's DevTools. But no, they still haven't implemented the ability to create custom formatters. 😞

They have a bug thread somewhere about it

still open: https://bugzilla.mozilla.org/show_bug.cgi?id=1262914

just briefly looked at the devtools sources, web socket data frames and normal network request previews are handled differently

web socket frame can be either text or binary and devtools creates corresponding view for it (in case of text type, it creates JSON view), no detection of mime type or anything like that

in network requests it tries to look at response headers or request headers and then interpret the mime type

https://github.com/binaryage/dirac/blob/cff8e6c40b7a989744b70d40eff918f3221c5b2d/resources/unpacked/devtools/front_end/network/ResourceWebSocketFrameView.js#L179-L197

actually if JSON view cannot be provided, it falls back to Common.resourceTypes.WebSocket type, whatever it is

here seems to be the logic for normal network requests: https://github.com/binaryage/dirac/blob/cff8e6c40b7a989744b70d40eff918f3221c5b2d/resources/unpacked/devtools/front_end/network/RequestResponseView.js#L75-L91

we would have to implement a new SourceFrame.ResourceSourceFrame type and detect packed transit there