This looks great. I would love something that can just incrementally ingest all of the unread messages across various platforms locally and give a summary about what needs a reply most urgently
Readit Newsjclay commented on Show HN: Semantic search and ask your Gmail using Local LLMs github.com/yahorbarkouski... · Posted by u/mantegna
jclay commented on Modern C++ – A collection of resources on modern C++ awesomecpp.com/... · Posted by u/gjvc
I find the Chromium codebase to be one of the best resources for learning large-scale, high quality modern C++ best practices. They stay on a bleeding edge toolchain: near tip of tree clang, lld and libc++ is used on all platforms. They stay pretty recent on c++ standards — they’re on C++20 for the last year or so.
I think they are also contributing a lot of the new libc++ hardening features that have been landing: https://libcxx.llvm.org/Hardening.html IIRC, production chrome ships with Extensive hardening.
They also roll out massive code changes via automated clang rewrites. Recent examples are replacing all raw pointer members with their raw_ptr wrappers that bring some additional safety. They also switched from absl::optional to std::optional in one swoop.
If you haven’t done it before, take a browse through //base sometime, it’s got a lot of well commented code to learn from. You’ll see they’re already using c++20 concepts and requires clauses in a number of places.
jclay commented on Trolltech's Documentation Process rant.gulbrandsen.priv.no/... · Posted by u/whatever3
Qts doc is good but REALLY lacks in the details. For example how things composit with each other is generally undocumented and the fact that their codebase is quite old and full of techdebt makes that part very annoying for advanced use.
An example: how in QML the Repeater element works inside an ObjectModel.
I agree. Topics like “how is the lifetime of a QObject exposed to the QML engine managed?” lack coverage and clarity. On the surface it is simple, but in practice it’s an extremely complex topic that has been a source for many bugs in our medium to large QML desktop app.
We contribute upstream a bit and we had documentation updates to clarify the stability of pointers to QHash elements rejected. ¯\_(ツ)_/¯
Personally, we superbuild bleeding edge Qt with the source code in tree so that it’s trivial to go to definition and inspect behavior. Makes the experience substantially better.
jclay commented on Intel's woes with Core i9 CPUs crashing look worse than we thought techradar.com/computing/c... · Posted by u/signa11
I was seeing constant instability when running basically any large C++ build that was saturating all of the cores. I was getting odd clang segfaults indicating an AST was invalid, that would succeed on a re-run.
This was getting very frustrating, at various points I tried every other option online (including restoring bios to Intel Baseline settings), etc.
I came across Keean's investigations into the matter on the Intel forums:
> I think there is an easy solution for Intel, and that is to limit p-cores with both hyper-threads busy to 5.8GHz and allow cores with only one hyper-thread active to boost up to 5.9/6.2 they would then have a chip that matched advertised multi-core and single-thread performance, and would be stable without any specific power limits.
> I still think the real reason for this problem is that hyper-threading creates a hot-spot somewhere in the address arithmetic part of the core, and this was missed in the design of the chip. Had a thermal sensor been placed there the chip could throttle back the core ratio to remain stable automatically, or perhaps the transistors needed to be bigger for higher current - not sure that would solve the heat problem. Ultimately an extra pipeline stage might be needed, and this would be a problem, because it would slow down when only one hyper-thread is in use too. I wonder if this has something to do with why intel are getting rid hyper-threading in 15th gen?
From: https://community.intel.com/t5/Processors/14900ks-unstable/m...
Based on this, I set a P-Core limit to 5.8 in my bios and after several months of daily-use building Chromium I can say this machine is now completely stable.
If you're seeing instability on an i9 14900k or 13900k see the above forum post for more details, and try setting the all-core limit. I've now seen this fix instability in 3+ build machines we use so far.
I'll also add that I was never able to get the instability to show up when running the classic stress testing tools: MemBench, Prime95, and Intel's own stability tests could all run for hours and pass.
There's something unique about the workload of ninja launching a bunch of clang processes that draws this out.
On my machine, a clean build of the llvm-project would consistently fail to complete, so that may be a reasonable workload to A/B test with if you're looking into this.
The user quoted above was running gentoo builds on specific p-cores to test various solutions, ultimately finding that the p-core limit was the only fix that yielded stability.
jclay commented on Intel's woes with Core i9 CPUs crashing look worse than we thought techradar.com/computing/c... · Posted by u/signa11
I was seeing constant instability when running basically any large C++ build that was saturating all of the cores. I was getting odd clang segfaults indicating an AST was invalid, that would succeed on a re-run.
This was getting very frustrating, at various points I tried every other option online (including restoring bios to Intel Baseline settings), etc.
I came across Keean's investigations into the matter on the Intel forums:
> I think there is an easy solution for Intel, and that is to limit p-cores with both hyper-threads busy to 5.8GHz and allow cores with only one hyper-thread active to boost up to 5.9/6.2 they would then have a chip that matched advertised multi-core and single-thread performance, and would be stable without any specific power limits.
> I still think the real reason for this problem is that hyper-threading creates a hot-spot somewhere in the address arithmetic part of the core, and this was missed in the design of the chip. Had a thermal sensor been placed there the chip could throttle back the core ratio to remain stable automatically, or perhaps the transistors needed to be bigger for higher current - not sure that would solve the heat problem. Ultimately an extra pipeline stage might be needed, and this would be a problem, because it would slow down when only one hyper-thread is in use too. I wonder if this has something to do with why intel are getting rid hyper-threading in 15th gen?
From: https://community.intel.com/t5/Processors/14900ks-unstable/m...
Based on this, I set a P-Core limit to 5.8 in my bios and after several months of daily-use building Chromium I can say this machine is now completely stable.
If you're seeing instability on an i9 14900k or 13900k see the above forum post for more details, and try setting the all-core limit. I've now seen this fix instability in 3+ build machines we use so far.
jclay commented on Longer and Longer Freight Trains Drive Up the Odds of Derailment scientificamerican.com/ar... · Posted by u/jyunwai
Here’s another great article on the topic. I particularly like the animations in this one.
https://www.propublica.org/article/train-derailment-long-tra...
jclay commented on Multitasking, parallel processing, and concurrency in Swift eclecticlight.co/2024/06/... · Posted by u/ingve
The article isn't about Swift; it's about the history of concurrency on mac's dating the to the last millennium.
The article doesn't even really explain the modern push - the difference between threads and fibers, or between actors and concurrency domains, or most critically between x86 and ARM in their memory models.
Would someone please write that article?
I wrote about a small fraction of this, CFRunLoop: https://blog.meldstudio.co/macos-cfrunloop-internals-schedul...
libdispatch source code is an enlightening read for those interested in diving deeper into the C Runtime powering Swift concurrency.
As another huge rust fan myself, Swift 6 has really won me over.
I find myself reaching for Swift as the default for a lot of things rather than Rust, especially with the advent of C++ Interoperability and the new Swift embedded stack and ownership model.
The only thing I really need is a UI story on other platforms, but it’s an area Rust is lacking great solutions too. I suspect the C++ interop might eventually make Swift have great Qt bindings to compete with PySide as an accessible way to make multi platform UIs.
There’s a very minimal example using C++ interop in Qt’s test suite:
https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he...
I’ve kicked around with the C++ interop a few times. Projects like Qt that use raw pointers extensively seem hard to expose. Ended up having to wrap Qt classes to model as a value type which was straight forward but it’s not nearly as seamless as the Objective-C++ experience
We build meldstudio.co (a performance oriented desktop app) using Qt/QML and managed to entirely avoid Qt Creator. It’s like traveling back in time coming from a VS Code configured with clangd and LLDB debugger.
Really wish they would invest in getting QML LSP to a working state. It’s been in development for well over a year now and still not used by Qt Creator itself. qmlls is missing proper formatting support, syntax aware highlighting (although we paid a contributor to land this upstream over a year ago, the PR is still pending). It has unusable latency compared to other LSPs, the list goes on.
This is the first in a series of posts I have planned about working with low-level run loop APIs provided by the CoreFoundation C library. I demonstrate how they can be used in a C++ app by building up some higher level abstractions and RAII wrappers.
The next post I have planned goes over how to use the CFRunLoop to post cross-thread tasks, and will include some benchmarks comparing with an alternative C++ lock-free SPSC task queue implementation.