gotta double check, but I think you are right, at same time I think it shouldn't be hard to add, we just need for each ref attribute, generate the reverse during the schema analysis part of the process

what pathom version are you using?

for it to work with Pathom 3 you need to setup the boundary interface at the border, this tutorial contains a full working example of it: https://pathom3.wsscode.com/docs/tutorials/serverless-pathom-gcf

also, for fully featured, it requires transit with proper setup for the Pathom 3 types encoding (also demonstrated in the tutorial I mentioned)

cool, I will take a look at that tutorial. getting tired of emacs freezing for 10 seconds every time an error happens because it can't render the HUGE env I have

have you tried using #portal or something like it? I find its a game changer to work with large data structures

I haven't, is that what you're using to read pathom errors?

portal is something that's basic on my workflow nowadays, any time I want to inspect data I use it 🙂

do you output anything to the cider-error buffer (if you're still using emacs) or does everything go to portal

its a different channel, you send things to portal via tap>

ah, I just want emacs to stop freezing tbh.. basically feels like I'm recompiling my program every time an error happens inside of a pathom resolver with how slow it gets

I use intellij, which Portal has a plugin to, so I can have it baked inside my editor, but it has options that you can run it as a stand alone app

so you can see my REPL history on the lower right, and portal in the top right

its an UI that allows me to interactively navigate though large data structures, has different views you can use (because the best view depends on the kind of data you are looking at)

so if you do p.eql/process env [:broken-attribute] does that print the whole error in the lower right repl?

yup

only what I tap> goes to portal

and it doesn't lag? :O

nope

on a multi-MB datafied env anyway

I think it's probably all on one line which emacs hates

no, its connected to your REPL, so it can defer loading parts of data in the UI as you navigate

I mean the intellij repl, I can see how portal can navigate known structured data well, it's the huge stuff that pops up accidentally that kills me

I rarely have performance problems with the standard REPL on IntelliJ too, it also has a button where you can cancel if things starting to print forever

its just that even it it can print fast, still quite messy to read the data there (when its large)

one detail there is that the way Cursive does the highlight on the REPL window uses some library that can do it partially (it doesn't require knowing the end of the contents to colorize it)

but a quick tip, if you just want to ignore the output, you can run something like: (do (p.eql/process env ...) nil), so you don't get the output and prevent the issue

but if you want to look at it, then you still need to place it somewhere else (like portal) with: (tap> (p.eql/process env ...)) (tap just returns true or false)

the problem is not the output, just in debugging. I want to see the error thrown in my resolver but pathom will also include the entire env in the causes, so cider tries to write all that and it explodes

can you send exceptions automatically to portal? seems pretty easy for a plugin

yeah emacs font-lock is notoriously slow, definitely not lazy. maybe today's the day I finally try tree-sitter

you would have to capture it somehow, easy enough to make a macro that handles the whole thing

but are you using strict or lenient mode?

because on strict mode the errors shouldn't be that huge I guess

but I dunno how emacs handles exceptions

this is what I see in my REPL when I get a pathom exception

it's only on strict mode that pathom will try to print it and it gets slow I think

if you have a big query with big params then ::pcp/graph gets huge

e.g. fetch the HTML of a page and store that in an attribute

hit 1000 sites with that in one query

thats what I mean by I dunno how emacs handles exceptions, its showing automatically the ex-data of it?

because on Cursive, it just prints the error message, so I never get anything big from it

(pa/q api [:eouoeeu :oeueu :eeoueoue {:>/uoeueo [:oeueou]}])

yup, seems like it does automatically tries to print the ex-data indeed 😛

so with intellj how does it work? is the last exception saved somewhere, then you can throw it into portal?

and yeah, ex-data is big to allow detailed handling, but can be a mess if you editor tries to get it out every time

Clojure itself already saves the last error as *e, so you can start from it

to be honest I rarely need to check on it, its more an exceptional case than the norm, usually the error message is enough for me to work from

(also I can click on the line to get just the stack trace, that's the thing I use more often)

hmm yeah there's no middle ground in cider between seeing the message of the immediate exception, vs seeing everything of the entire chain

and it looks like printing big exceptions is an old issue that probably isn't getting fixed https://github.com/clojure-emacs/cider/issues/2936 https://github.com/clojure-emacs/cider/issues/1873

as a workaround, you may want to have a fn wrapping the thing, so you cna for instance for the print of just the message, instead of eagerly printing the whole ex-data every time

so you can iterate faster

brilliant idea! life is better now thanks 🙂