pmeira

Apparently it also needs Clang to achieve the same performance: https://news.ycombinator.com/item?id=40875968

Don't forget BLIS itself!

It's a muddy comparison given that NumPy is commonly used with other BLAS implementations, which the author even lists, but doesn't properly address. Anaconda defaults to Intel oneAPI MKL, for example, and that's a widely used distribution. Not that I think MKL would do great on AMD hardware, BLIS is probably a better alternative.

The author also says "(...) implementation follows the BLIS design", but then proceeds to compare *only* with OpenBLAS. I'd love to see a more thorough analysis, and using C directly would make it easier to compare multiple BLAS libs.

Compression and other features use the non-Apache license:

https://github.com/timescale/timescaledb/tree/main/tsl

Some packages already use those. For previous Python versions, those are available in typing_extensions: https://typing-extensions.readthedocs.io/en/latest/

To be fair, linking to the Releases page when there are no release notes are all here was completely useless for browsing. Linking directly to the tag on the Git repo would make it obvious that submodules are being used and allows browsing directly:

https://github.com/apple-oss-distributions/distribution-macO...

I doubt most readers on HN are going to clone this locally and I also doubt anyone expects a release archive to contain Git submodules. This isn't to fault the repo authors, since we have to note that there isn't an actual "GitHub Release" here, it's just the automatic archive from GitHub for a certain tag.

"Linux x86_64" is present on my UA on Linux, and "Windows NT 10.0; Win64; x64" on Windows. Probably a bug or just untested on Firefox. Just a bit annoying.

I'll add that this is the first site that misdetects anything like that.

Not only that, when using Firefox (Chrome seems fine), it's selected by default on Windows and Linux.

Interesting, thanks for the links. By the way, the one I mentioned was in r/learnpython, which is probably not exactly the ideal audience for such a feature.

I maintain a few niche (electric power systems) packages, and I wouldn't mind a one-time or yearly fee, or a fee per project created. I say this as a Brazilian who lived in the middle of nowhere and managed to have a website in the 90's as a teen. If a monetary fee is not desirable, some other hurdle/challenge would probably work fine.

Recently I've seen someone on Reddit trying to automate the creation of PyPI projects through GitHub Actions. The person was complaining that the first deployment couldn't use an API key for that project since it didn't exist. So I'm not surprised some people are trying to do the same for malicious purposes.

The PyPI front page lists 455k projects. If you search for "test", you'll see there's a lot of throwaway projects (note that test.pypi.org is a thing). I'm mostly an EE researcher and I'm not sure students need a low barrier to entry to PyPI, since pip and other tools support installing from GitHub without too much hassle and there are also other non-PyPI package indices. Student packages/projects tend to be abandoned soon after graduation. An archived repo (with a license...), on GitHub or somewhere else, sounds more reasonable and also has more visibility that could end in code reuse someday (through the service's own search and search engines in general). I'd love to understand why so many people repeat this meme that student and teens need trivial access to production infra like PyPI.

So, I'd say being too inclusive, allowing fully unrestricted trivial creation of projects is kinda foolish. There needs to be some extra step, be it a fee, identity confirmation, manual moderation/approval, or something else. I'm sure the PyPA devs/maintainers have ideas.

Last year when something like this happened, it came out that there's a legal representative in Rio: https://www1.folha.uol.com.br/internacional/en/brazil/2022/0...

It uses Mapbox GL JS v2.x, which is no longer open-source and is tied to the TOS, so the distinction of using Mapbox tiles or not doesn't seem to matter. Just loading the library requires a token from Mapbox.

GIMP already supported ARM though, this is about "Apple Silicon". Since the post itself doesn't mention specific challenges, I guess it serves more to inform macOS users of the availability than foster discussion or provide any insight.

You could use NumExpr: https://github.com/pydata/numexpr#what-is-numexpr

FreeXL is another alternative: https://www.gaia-gis.it/fossil/freexl/index

Another benefit that is often overlooked is that Parquet support various compression methods, right? SQLite's official support for compression is a commercial product, so basically useless for general usage in free open-source software. There are a few 3rd party alternatives, but it becomes cumbersome.

Considering DuckDB's and Parquet's features, if DuckDB manages to support the emerging GeoParquet standard someday, I believe it could be a nice alternative to the typical SQLite + Spatialite combo, and GeoPackage as a whole.

To complement, dynamic arrays ("array of ...") are always 0-based in Delphi and Free Pascal. This was apparently introduced in Delphi 4 (1998).

I was just looking into that and couldn't find much besides this: https://twitter.com/lIlIIllIIllIlll/status/13160140587393884...

I guess they don't like that people can generate their own vector tiles more easily nowadays, or services like Maptiler [0] (see [1] for some more context) that provide tiles at lower costs.

[0]: https://www.maptiler.com/mapbox-alternative/

[1]: https://www.maptiler.com/news/2020/05/the-future-of-openmapt...

For physics, I think that's true. For other fields in general, it probably varies a lot (I'd love to see some numbers). We live in bubbles but we should try to remember that our bubbles don't represent the whole world.

> Most people in Julia's target audience know latex already

Is Julia's target audience really that small? Either that or you'd be surprised how many people don't use LaTeX but do write scientific code and papers.