tooi: Import tooi-0.16.3
tooi is a text-based user interface for Mastodon, Pleroma and friends.
The name is a portmanteau of toot and TUI.
tooi is a re-implementation of the TUI included with toot using the
modern and more powerful Textual framework.
py-textual-image: Import py-textual-image-0.8.5
textual-image offers both Rich renderables and Textual Widgets that
leverage the Terminal Graphics Protocol (TGP) and Sixel protocols to
display images in your terminal. For terminals that don't support these
protocols, fallback rendering using Unicode characters is available.
x11-toolkits/fox17: Update to 1.7.89
Bump PORTREVISION on consumers. Since this is a development version,
rebuild is required even for patch releases due to ABI incompatibility.
http://www.fox-toolkit.org/news.html
devel/gwenhywfar: Update to 5.14.1
Remove libraries for obsolete toolkits unused in the ports tree:
devel/gwenhywfar-gtk2
devel/gwenhywfar-fox16
devel/gwenhywfar-qt5
Technically, FOX 1.6 is still maintained, but no port has used this
support in my almost 16 years of maintainership and allows for some
patching to be dropped.
asmc: improve asmc_dumpall to read actual SMC key count
The asmc_dumpall debug function previously used a hardcoded loop limit
of 0x100 (256) keys with a "XXX magic number" comment.
This change improves asmc_dumpall to:
* Read the actual number of keys from the ASMC_NKEYS SMC key
* Print the key count being dumped for better debugging output
* Loop only up to the actual key count (e.g., 297 on Mac Mini 5,1)
This provides more accurate debug output and removes the magic number.
Tested on Mac Mini 5,1 (FreeBSD 16.0-CURRENT):
* Rebuild kernel with DEBUG enabled in asmc driver
* Boot with new kernel
* Verify dmesg shows "asmc_dumpall: dumping 297 keys" (or actual count)
* Verify all 297 keys are dumped
[3 lines not shown]
asmc: improve asmc_dumpall to read actual SMC key count
The asmc_dumpall debug function previously used a hardcoded loop limit
of 0x100 (256) keys with a "XXX magic number" comment.
This change improves asmc_dumpall to:
* Read the actual number of keys from the ASMC_NKEYS SMC key
* Print the key count being dumped for better debugging output
* Loop only up to the actual key count (e.g., 297 on Mac Mini 5,1)
This provides more accurate debug output and removes the magic number.
Tested on Mac Mini 5,1 (FreeBSD 16.0-CURRENT):
* Rebuild kernel with DEBUG enabled in asmc driver
* Boot with new kernel
* Verify dmesg shows "asmc_dumpall: dumping 297 keys" (or actual count)
* Verify all 297 keys are dumped
[3 lines not shown]
[offload] [test] Mark bug 51781 test as requiring GPU (#174284)
While the main problem with the test is that it requires LLD, given that
it is unlikely to be testing anything meaningful for a CPU-only build,
just mark it as requiring GPU.
Fixes #100780
Signed-off-by: Michał Górny <mgorny at gentoo.org>
jigdo: update to 0.8.2
Upstream says that this mainly contains bugfixes.
Also add a "gtk" option which is on by default. If you disable it, it
disables the GUI. This addresses PR pkg/30837, only 21 years later.
We keep a copy of the old interface.hh from 0.7.3 in FILESDIR; the build
now wants to regenerate it with glade-2, which is long gone from pkgsrc.
New package, docbook-utils.
The docbook-utils is a set of a few small programs intended to ease
everyday's use of technical documentation software and more generally
use of SGML and XML. They are released under the GPL licence.
Tasks they currently accomplish are:
- jw: convert SGML files to other formats (HTML, RTF, Postscript, PDF)
- sgmldiff: detect the differerences in markup between two SGML files
[MLIR][Python] Register Containers as Sequences for `match` compatibility (#174091)
This allows these containers to be used in `match` statements, which
allows extracting properties and asserting a shape at the same time.
It seems to be only possible, to match as _either_ a `Mapping` _or_ a
`Sequence`, so the `OpAttributeMap` is only a `Mapping`.
I couldn't find a way to make these C++ based types properly inherit
from `Sequence` or `Mapping`, so the Mixins are not provided (nanobind
only allows C++ parent classes, modifying `__base__` complains about
differing destructors).
`OpAttributeMap` was lacking the `get` method, so I simply copied it
from `collections.abc.Mapping`.
When writing the tests i ran into the error, that I wrote
`func.FuncOp(body=[Block(...)])` instead of
`func.FuncOp(body=Region(blocks=[Block(...)]))`. So maybe also turning
`Region` itself into a Sequence would be a good addition as well? Would
[7 lines not shown]
