Hacker Newsnew | past | comments | ask | show | jobs | submit | urschrei's commentslogin

Another approach is to teach Claude Code how to use your Zotero library's full-text search: https://github.com/urschrei/zotero_search_skill.

> A side effect of the geometry simplication is that there are some very small gaps between states. Based on your use case, you'll need to handle the case of the point not being within any state borders. In these rare cases, you could fall back to a different method, such as distance checking centroid points, adding an episilon to all state borders, or simply asking the user. (The user may also be in another country or in the ocean...)

If your pre-simplification input geometries form a coverage[0], you can use e.g. ST_CoverageSimplify[1] or coverage.simplify[2] to simplify them without introducing gaps.

[0] http://lin-ear-th-inking.blogspot.com/2022/07/polygonal-cove... [1] https://postgis.net/docs/ST_CoverageSimplify.html [2] https://shapely.readthedocs.io/en/2.1.0/reference/shapely.co...


I wouldn't say it's correct to say that GEOS isn't particularly sophisticated. A lot of (certainly not all) GEOS algorithms are now ported from JTS, the primary author of which is Martin Davis (aka Dr JTS), who works at Crunchy Data, who provide the PostGIS extension. So the chain (again, mostly) goes JTS -> GEOS -> {PostGIS, Shapely} -> … . Martin's work is at the cutting edge of open-source GIS-focused computational geometry, and has been for a long time (of course, industry has its own tools, but that's not what we're talking about).

I can sort of see your point about the merits of global, spheroidal geometry, certainly from a user's perspective. But there's no getting around the fact that the geometry calculations are both slower (I'm tempted to say "inherently"…) and far more complex to implement (just look at how painful it is to write a performant, accurate r- or r*-tree for spherical coordinates) along every dimension. That's not going to change any time soon, so the projection workflow probably isn't going anywhere.


I'm not a regular Zed user, but this isn't true: I simultaneously ran the Ruff and Pyright LSPs when I used it last week.


In the same file?


You can run multiple LSPs on the same file.

In my currently opened project I have: vtsls (for typescript), biome, emmet, and the snippets LSP running on the same file.

You can configure which LSPs you can run on a language basis. Globally and per project. You can also configure the format on save actions the same way. Globally and per project.

I have astro project that on save runs biome for the front-matter part followed by prettier for the rest.

I would say that's pretty flexible.


You are confused or wrong, and you are making incorrect assertions about a system "lying" to you on that basis: you can see this for yourself by typing `jj git init` (or just `jj init`) in an empty directory, touching some files, then running `jj status`. You will see a listing of the added files. The same happens if you commit these files, then make some changes to their contents: `jj status` will show the changed files, and `jj diff` will show the diff per file.


!!Con (pronounced “bang bang con”) 2024 is the last ever !!Con event, featuring two days of talks to celebrate the joyous, exciting, and surprising moments in computing. It takes place on the weekend of August 24-25, in the courtyard of the Baskin School of Engineering at UC Santa Cruz, in Santa Cruz, California, United States.


Agreed. As someone who often advocates for the use of Rust to speed up perf-sensitive Python functions (and in particular, in the GIS domain), this sounds like they haven't fully understood the problem or thought about how to solve it more efficiently with a spatial index (which is easily done in Geopandas, let alone PostGIS). However, the post is a bit vague on details so who really knows.


I see two sibling comments with reports of patchy reliability, so I'll note that it's been rock-solid for me (multiple daily deploys every weekday) since I last commented on it (about a year ago?)


From the site:

UPDATE: Previously, Apple announced plans to remove the Home Screen web apps capability in the EU as part of our efforts to comply with the DMA. The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS. We have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS. Developers and users who may have been impacted by the removal of Home Screen web apps in the beta release of iOS in the EU can expect the return of the existing functionality for Home Screen web apps with the availability of iOS 17.4 in early March.


These are the Mesa drivers linked from the blog post: https://gitlab.freedesktop.org/asahi/mesa, so not Rust AFAICS


The rust part is in the Kernel


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: