I am running the trial and it seems great except for two crucial deviations from Dock behavior. Clicking on a button ("chip") does not bring the associated window to the foreground. It does work when I hover over a chip and then click the preview of a specific window. But nothing happens when I directly click the button in the bar. The issue occurs regardless of whether an app has 1 or >1 windows open. In the latter case, I would prefer if clicking the button brings the most recently used window to the top.
Another observation: many macOS apps (e.g. pages, mail, keynote, etc.) like to stay open even without having any active windows. This is completely hidden by boringBar, which leads to tons of apps being open without the user being aware of it (-> memory waste). Furthermore, actually using such an app then requires me to awkwardly type the name of the app even though it's already open.
I think it would be better if such passive apps without windows still have chips, perhaps smaller ones without a window title.
Regarding the foreground issue, in case it's relevant: The app has all the permissions it requested. This is on a macOS 26.2 on a M4 MBP.
I am very worried by feature creep in libc++ and libstdc++ and the harm that this inflicts on the wider C++ ecosystem. Transitive inclusion of large parts of the STL, and entangling of STL with core language features are both extremely bad. This should IMO be topic #1 of the committee but is barely even noticed. The mantra "It's okay, modules will save us" is naive and will not work.
> Why would you recommend that? [..] It's a bunch of work for no benefit.
nanobind/pybind11 (co-)author here. The space of python bindings is extremely diverse and on the whole probably looks very different from your use case. nanobind/pybind11 target the 'really fancy' case you mention specifically for codebases that are "at home" in C++, but which want natural Pythonic bindings. There is near-zero overlap with Cython.
Caution: if you rely on pybind11 or a project using pybind11 (many projects do, like NumPy/SciPy/Tensorflow/PyTorch..), hold off on upgrading to Python 3.9.0 for now.
A change in Python 3.9.0 introduces undefined behavior in combination with pybind11 (rarely occurring crashes, but could be arbitrarily bad). We will work around it in an upcoming version of pybind11, and Python will separately also fix this problem in 3.9.1 slated for release in December.
The extra-painful part about this whole situation is that it's apparently only due to Apple blocking NVIDIA from signing and publishing their drivers. (for whatever bizarre reason they may have to do that)
I've long been really excited about SCons but eventually decided to move away because it became unbearably sluggish for a large-ish codebase with >180K lines of C++ code split into many files. Another issue are cross-platform builds. SCons breaks every time there is a new version of Visual Studio, and it takes many months until an updated version restores compatibility.
Lack of NVIDIA support is a deal-breaker. The AMD ecosystem is just so far behind when it comes to frameworks like CUDA, OptiX, cuDNN, etc.. Why can't Apple open up kernel-level support by cooperating more with NVIDIA? This state of things seems completely bizarre to me.
The material database provides broad coverage of common and more specialized materials, including isotropic and anisotropic BRDFs of metals, paper, car paints, organic samples, fabrics, etc. Each material is available in a spectral version that covers the 360(UV) - 1000nm (NIR) range with ~4nm sample spacing, as well as a RGB version for compatibility with renderers that do not support color spectra. The representation is extremely compact, requiring approximately 16KiB and 544KiB per channel for isotropic and anisotropic materials, respectively. Furthermore, it provides a natural importance sampling operation that does not require numerical fits or complex additional data structures. Technical details on the underlying parameterization and measurement methodology are available in the paper
The renderer accurately simulates a good chunk of geometric optics -- light propagation along rays, multiple scattering, specular reflection, refraction, and surface roughness due to random microstructure using state-of-the-art models.
It does not simulate wave-optical effects, polarization, fluorescence, and phosphorescence. Some of them are easy to add (e.g. polarization), others such as wave optics are very challenging to solve in a fully general setting and would make the resulting system impractical to use.
However, that's not the whole story: even when simulating the underlying optics meticulously, a rendering of plane is not going to look photorealistic. Some detail must also go into modeling of the input, which is beyond the scope of the book (though Section 10.6 talks a bit about creating detail with noise functions).
Matt, Greg, and I are super-excited to release a free online edition of the Physically Based Rendering Book with hyperlinked cross-referencing, beautiful SVG figures and equations as well as interactive image comparisons. The details of how all of this came to be are explained in the preface to the online edition. (http://www.pbr-book.org/3ed-2018/Preface_to_the_Online_Editi...)
This analysis is somewhat dated and leaves out one important fact: nowadays, floating point arithmetic is carried out using a set of special scalar SSE instructions (and not the ancient x87 co-processor, as was done in the author's benchmark).
SSE instructions remove performance pitfalls related to infinities and NaNs. The only remaining case where slowdowns are to be expected denormals (which can be set to flush-to-zero if desired.)
In other words: it's perfectly fine to work with infinities and NaNs in your code.
Not quite -- while pybind11 was originally inspired by boost::python, it is an entirely different project that is intended to address many of its problems.
pybind11 shares some of the motivation of boost::python, but it is designed to be considerably easier to use. Out of the box, it is aware of a large set of C++ types that are automatically translated to their Python equivalents and vice versa (STL data structures, C++17 types like optional<> and variant<>, std::function<> for callbacks, and even sparse and dense matrices for numerical linear algebra).