Clojurians Log v2

@mauricio.szabo If it helps with debugging that issue, the new tab that is opened is named filename... for an original file filename.clj -- note the ... -- so I'm wondering if whatever logic is finding the location of the definition is returning an invalid filename now sometimes?

(I only just noticed that behavior)

(I have repro'd it on both Adopt OpenJDK 11 which I was using before and (Oracle) OpenJDK 14 which I'm using now -- so it's not related to the JDK)

(and it's the same behavior on 0.4.13 and 0.4.14)

Yes, I don't think that it's an issue with the JDK. Java is only involved when the var is inside a jar file, and it opens a read-only editor...

If you could, can you tell me the filename that's giving problems? Or, maybe try to save the empty file and see what filename appears... I'm out of ideas (because I'm not seeing this issue on Linux and, as far as I remember, I just copy-pasted the code from a place to another)

I'll diff the code and see if I can find anything strange.

It does seem to be just in certain files, which is weird, and I've just discovered that if I attempt 'go to def' in another file on one of the symbols in this notifications.clj file, I get the same weird notifications... behavior. So I'll try to narrow it down within this file.

So I saved the file and it is, indeed, called notifications... and it saves to the same folder as the original notifications.clj file.

I renamed it to notification_file.clj (and updated the ns to worldsingles.notification-file) and eval'd it, and I see the same wrong behavior: it opens a new, empty notification_f... file which saves to the same folder. Note that the filename is truncated: it's not notification_file...

OK, I experimented with a bunch of filenames... We have several files in different parts of the monorepo that have notification in their names and all of these seem to behave the same weird way. If I rename them to pretty much anything that doesn't have notification in it, things work as expected.

Ok, I'll look at it. Thanks, I think you helped a lot already :)

notificatio triggers the behavior, notificati is fine.

Ok, the issue is... UNREPL elisions. I didn't copy-paste the old code correctly. I'll issue a fix right now 🙂

Pesky old unrepl! 🙂

Yes, it helped me a lot in the beginning of the project, but currently is giving me trouble. I'll look into a way to not get in the way, there are some new features I want to add on Chlorine and UNREPL is currently on the way of these too.

I think the main "benefits" it brings, over having just a bare prepl, are: chunking of results so you don't crash the system by eval'ing a very, very large data structure; the ability to interrupt execution. Anything else?

Ability to parse (keyword "foo bar") and non-edn results (like Java objects) is another. It's harder than it seems (I'm trying to replicate it in ClojureScript, and it's kinda complicated).

Also, some java objects behave like EDN structures but are not (for example, Datomic query results)

Just published a new version. This version fixes the error (I was able to replicate it here on my machine after your help debugging). I hope I didn't miss anything 🙂

Confirmed fixed! Thank you!

Great, thanks for helping me debug the problem!

So why was it just that one filename pattern seemingly?

Probably because the path of that filename was too large - then when Chlorine runs (meta #'var-name), it'll give a filename path too large, and UNREPL will cut it to:

#unrepl/string ["/path/to/filename/too-la" #unrepl/... (some-function <some-id)]

To be able to parse it, Chlorine will generate a type IncompleteStr that reimplements toString to "/path/to/filename/too-la..."

I'm surprised I haven't tripped over it with other files then since we have quite a few things with longer paths. Anyways, good to know the cause (and have the fix so quickly -- thank you!).

Well, the bug happened at version 0.4.13 and 0.4.14. Older versions were using another structure. I'm trying to unify everything so it becomes easier to test (and also to migrate to VSCode, for example)

Ah, yeah, that's a small enough window I might just have missed it on other files. I've been working hard on a new notification-related feature for the last week or so 🙂