wjakob

Besides boringBar, the following are enabled: Claude, Dropbox, MacWhisper.

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.

There is also IINA that somehow seems more snappy/better-integrated on macOS.

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.

Details available here: https://pybind11.readthedocs.io/en/latest and https://github.com/python/cpython/pull/22670.

What's wrong with red-black trees? :) Since you mention C++: you do realize that std::map will typically be implemented with one?

Here are links to more concrete studies concerning this effect.

Action spectrum for melatonin regulation in humans: evidence for a novel circadian photoreceptor. Brainard et al. https://www.jneurosci.org/content/jneuro/21/16/6405.full.pdf

Phototransduction by retinal ganglion cells that set the circadian clock. Berson et al. https://science.sciencemag.org/content/sci/295/5557/1070.ful...

Note that this is only for OpenGL ES!

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)

The maintainers of SCons have long argued perceived performance and scalability issues do not exist (https://github.com/scons/scons/wiki/WhySconsIsNotSlow).

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

An Adaptive Parameterization for Efficient Material Acquisition and Rendering (http://rgl.epfl.ch/publications/Dupuy2018Adaptive)

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).

Thanks! We'd love to have a new print edition at some point in the future, but the details of this are yet to be determined.

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).

@aldanor recently gave a nice overview talk of what pybind11 can do: https://speakerdeck.com/aldanor/pybind11-seamless-operabilit...

Also, take a look at our documentation (http://pybind11.readthedocs.io) -- it contains detailed examples of many tricky use cases.

I wish Apple would internationalize this program to make it accessible to children in non-English-speaking countries.

That's a commercial emulation layer -- this may be fine for some use cases but is definitely not a satisfactory state for the graphics ecosystem on Mac.

I find Apple's lack of commitment to Vulkan incredibly short-sighted on their part and downright offensive to developers. At a higher level, both Metal and Vulkan address the same technical issues in previous APIs. The sheer waste of effort and squandered opportunities resulting from this type of fragmentation sometimes make me wonder if we need a regulatory agency to step in when big players show such obvious disregard for interoperability.

To be fair, pybind11 is not an ETHZ codebase ;). (original author here)

beer o'clock

I finished VIM adventures a few years ago and found this approach quite helpful to improve my VIM muscle memory.

What's very unfortunate though is that the licenses are limited to 6 months. Occasionally I wish I could go back to one of the levels focusing on a specific feature, but paying another $25 every time just seems excessive.

I'm curious as to how AWS plans to prevent users from generating malicious FPGA bitcode that physically damages the FPGA itself and/or the host machine over PCI Express. The possibility of instantiating arbitrary logic gates in the cloud seems very dangerous.

The latest release wraps up ~5 months of work and includes support for PyPy, multiple inheritance, and extensive C++ bindings for NumPy arrays.

A detailed changelog is available here: http://pybind11.readthedocs.io/en/stable/changelog.html

Yes, that's the plan! (eventually...) :)