Creator of Cirru here. Cirru is confusing since it's a syntax of data, not a standalone language. Calcit(<https://calcit-lang.org/>) is the language I built. However Calcit does not store source code in files called `blabla.calcit` or something. Instead, Calcit stores code in data, which is called "Cirru EDN" since it's a variant of Clojure EDN. And it uses Cirru as a data format so stored in files called `compact.cirru` or `calcit.cirru`, which might confuse you PLDB data.
I think the back button is fine, it's the keyboard shortcut for Go Back, `alt-left`, that's broken. The `scrollKeyboardNav` element's "press left/right to go to the prev/next language" keydown handler is triggering even when alt is being held is preempting the Go Back shortcut.
Workaround is to swipe back furiously, presumably before the page is able to add additional locations to browser history.
Without actually pulling this code or doing any debugging, I believe the issue is this line here, at some point during the initial page load you are setting `location.hash` (watching the actual URL I can see that it happens) which adds a navigation event to your history and interferes with the back button.
It also doesn't happen in Chrome in Android. I do not know why one browser would trigger that code path while another would not, perhaps they all trigger the code but most of them discard JS induced navigation events that fire during a page load.
You could probably go ahead and start using `location.replace` with a minor refactor. The difference in behavior there would be when someone updates their query, a new entry is not added to history. Whether that's a regression or an improvement is probably user dependent. IMO, it's better not to have a bunch of history items for playing with one table.
I was viewing this page in the Harmonic app and had to quit since the Android back button was unable to exit the webview.
Allowing developers to mess with the back button was a mistake, I've never used a website where that functionality didn't present a problem rather than solving one.
Looking at the code, the issue is most likely a modification of window.location or its child properties. Any modification of these things will cause the browser to navigate to the new page, adding a new browser history entry.
Then, whenever a user tries to go back, it will rerun the code that causes the browser to nagivate to the new page, so you end up on the same page you started on. It feels like the back button was hijacked.
To fix this, usually the two ways to change the URL without changing the browser history are either using window.location.replace() which will navigate there as well, or using window.history.replaceState() which will only change the URL without naviating there.
They are cramped in a tiny table where you can barely see them.
The PDF button did work for me, but only the second time: the first time, for some reason, the blob:// scheme was transformed into blob.com, a scammy SEO parking website.
Add to that the hijacking of the back button, and boy what a terrible experience...
Obviously this is the opposite of what I'm trying to create.
I actually design the site for it to work 100% offline. You can download it to your computer. Some pages, such as this advanced explorer, are designed really with desktop in mind, and mobile is an afterthought. I gave my smart phone up 2 years ago, and that made my life a lot better, and I won't be going back. However, I do test on a low powered burner phone, and try to make sure the site works, but this explorer page is more advanced, and is literally doing clientside search and transforms on the entire database with no server calls. So it's just something better used on a computer.
Unfortunately time and resources are limited (the site has no business model yet, but perhaps if the WWS catches on we'll have funds to bring on more people...or maybe someone has a great idea for grants we could win or other business models?) .
If anyone wants to volunteer time to make this run better on mobile phones, I'd love to help unblock you! Source code is:
Why does this site list CUDA as a programming language? I also don't see why we need to include versioning tools or APIs and many other things. I suppose this evolved beyond the PLDB naming. The interface is nice and simple though.
> Why does this site list CUDA as a programming language?
Our original taxonomy was pretty weak due to tooling. Much better now (switched away from "type" to "tags"), but still work to be cleaning up the old categorizations.
It is my understanding that CUDA extends the c/c++ langs though, right? It's not simply a library? My own knowledge of CUDA is a little weak (so pull requests welcome!)
> I suppose this evolved beyond the PLDB naming.
Yup! It turned out to be quite hard to tell the story of programming languages without including other concepts from the ecosytem. But the focus is on languages. The schema and language underneath (ScrollSets) evolved so it's simple for us to extend beyond the core and include things 1 degree of separation out. This Explorer is new and the first step toward making it easier for people to include/exclude the set of things they are interested in.
Cuda is a programming language. It's a dialect of C++ which leaks compiler implementation quirks into the application layer. A best effort approximation to the Nvidia one is available in clang by passing -x cu or naming a file something.cu.
For me it's a labor of love and I was doing it anyway to try and make my own languages good.
But yes, a lot of work still ahead.
If anyone wants to give us grants/donations, we can make a dollar go far, and there are some people that have been helping for years who I would love to be able to support to work on the site adding data.
I'm also all ears to any business model ideas (of course nothing that would involve paywalls or non-public domain).
That being said, LLMs have changed the game and made a lot of things tremendously easier, so we should see a lot of useful data added this year regardless (all human reviewed, of course!).
