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

Does DuckDB supports partial reading of .duckdb files hosted externally?


I wish this recent backlash was also spent on removing this rootkit. It's a PvE game, I hardly see why a rootkit is warranted.


You think people wouldn’t be cheating in a multiplayer PvE running the joy for others?


I definitely don't think that. Most of the time people are playing coop with those they know, not random matchups.


We nerd sniped ourselves into testing the latencies of a whole bunch of wireless communication links and protocols for microcontrollers.

We’ll probably do a series of power consumption / range tests later on, let me know if there are any setups in particular that you’d be interested in seeing test cases for.

Raw data, firmware and post processing scripts are here on GitHub:

https://github.com/Scottapotamas/embedded-wireless-latency-e...


Once there's decent embedded HaLow options, I would love to see analysis of this level on it.


I nearly did, but the write-up was getting pretty long.

I'll try to find something for the planned range/interference tests. Morse Micro is also an Australian company so I'll probably look into their parts first unless there's any recommendation?


That sounds good if you're an Aussie. I'm honestly confused why there's still so few options, but I guess most radically new standards got a comparatively slow start.


I work on a product for building user interfaces for hardware devices. All the state management is done via incrementally updated, differential DataFlow systems. The interface is defined in code instead of graphically, but I think that's a feature, so that code can be version controlled.

I think there has been evolution in the underlying data computation side of things, but there are still unsolved questions about 'visibility' of graphical node based approaches. A node based editor is easy to write with, hard to read with.


We've been using (the old) Shiki Twoslash for a few years now for our docs pages:

https://electricui.com/docs/components/LineChart

https://electricui.com/docs/operators/aggregations

Our product, Electric UI, is a series of tools for building user interfaces for hardware devices on desktop. It has a DataFlow streaming computation engine for data processing which leans heavily on TypeScript's generics. It's pretty awesome to be able to have examples in our docs that correctly show the types as they flow through the system. I certainly learn tools faster when they have good autocomplete in the IDE. Twoslash helps bring part of that experience earlier in the development process, right to when you're looking at documentation.

Our site is built with GatsbyJS, the docs are a series of MDX files rendered statically, then served via Cloudflare Pages. We use the remark plugins to statically render the syntax highlighting and hover tag information, then some client-side React to display the right tooltips on hover.

We build a Twoslash environment from a tagged commit of our built TypeScript definitions, from the perspective of our default template. The Twoslash snippets as a result have all the required context built in, given they are actual compiled pieces of code. The imports we display in the docs are the actual imports used when compiling from the perspective of a user. It bothers me when docs only give you some snippet of a deeply nested structure, and you don't know where to put it. Even worse when it's untyped JS! Using Twoslash lets us avoid that kind of thing systematically.

The CI system throws errors when our docs snippets "don't compile", which is very helpful in keeping our docs up to date with our product. Nothing worse than incorrect docs!

We use React components extensively, and I'm not really happy with our prop reference tables which use Palintir's Documentalist. Our components are increasingly using complex TypeScript generics to represent behaviour. The benefits in the IDE are huge, but the relatively dumb display of type information in the prop table leaves something to be desired. I'm most likely going to replace the data for those tables with compile-time generated Twoslash queries.

My only complaints have been around absolute speed of compilation, but I haven't dug deep into improving that. I just set up a per snippet caching layer, and once files are cached, individual changes are refreshed quickly. After all, it's invoking the full TypeScript compiler, and that's its biggest feature.

Overall I've been very happy with Twoslash, and I'm looking forward to refactoring to use this successor and Shikiji (the ESM successor to Shiki), hopefully it improves our performance. The new Twoslash docs are look great, a huge improvement on when we started using it.


WebAssembly in something like wasmtime is probably the closest we've got to this. Though I wish WebAssembly supported more (wider) SIMD instructions.


There was a recent post by Voultapher from the sort-research-rs project on Branchless Lomuto Partitioning

https://github.com/Voultapher/sort-research-rs/blob/main/wri...

Discussion here:

https://news.ycombinator.com/item?id=38528452

This post by orlp (creator of Pattern-defeating Quicksort and Glidesort) was linked to in the above post, and I found both to be interesting.


We've been running TS + PnP + VSCode on MacOS throughout the entire lifetime of Yarn, through versions 1 - 4.

The plugins system has been extremely valuable to us, and the hoisting / peer dependency behavior has been consistently correct, where other package managers have caused bugs.


Richard Sutton is now working with John Carmack at Keen Technologies.


Teddy is a SIMD accelerated multiple substring matching algorithm. There's a nice description of Teddy here: https://github.com/BurntSushi/aho-corasick/tree/f9d633f970bb...

It's used in the aho-corasick and regex crates. It now supports SIMD acceleration on aarch64 (including Apple's M1 and M2). There are some nice benchmarks included in the PR demonstrating 2-10x speedups for some searches!


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: