from:"thomas"


On Friday, April 26, 2024 at 1:31:41 PM UTC-4 Edward K. Ream wrote:

The Easter Egg is the only way to expand the VR pane. An optional floating 
VR window would solve that problem.


Here you go:

ns = c.free_layout.get_top_splitter()
ns.open_window('_leo_viewrendered3')
 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a9734be6-dc2c-44ee-adea-9310dead5cd3n%40googlegroups.com.

[clang] [llvm] [WebAssembly] Add half-precision feature (PR #90248)

2024-04-26 Thread Thomas Lively via cfe-commits


https://github.com/tlively approved this pull request.

LGTM. We can always bikeshed the feature name later if we want.

https://github.com/llvm/llvm-project/pull/90248
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: BPX COND_SETUP/COND_WAIT, the SIR and "pushing back" signals

2024-04-26 Thread Thomas David Rivers

> 
> And - to follow-up one more time, the SIR documentation from the MVSSIGSETUP
> service has this to say:
> 
> 
>If the interrupt cannot be processed at this time, possibly due to general
>register 13 not currently containing the address of a program stack, or 
> the last
>service called on the current thread was cond_setup, then the 
> queue_interrupt
>service request is issued
> 
> So - my question really is "how can the SIR determine that the last service
> called on the current thread was cond_setup?"
> 
>   - Thanks -
>   - Dave R. -
> 

 So -  to follow-up some more, I did find this field in the BPXZOTCB (OMVS TCB 
extension):

OTCBCTWACTIVE EQU X'02'  cond_timed_wait (BPX1CTW) is active

 (it seems to go all the way back to OS/390 2.10.)


 If that flag is also set whe just cond_wait is active (which would make 
sense), then
 perhaps a possible mechanism is:

   1) Set a flag somewhere indicating cond_setup is about to be called

 a) If a signal arrives at the SIR, check that flag and return any
signals to the kernal via queue_interrupt, unless the 
OTCBCTWACTIVE flag
in the OTCB is set, in which case you clear the flag and let 
the signal proceed.

   2) Invoke cond_setup

   3) Do housekeeping

   4) Invoke cond_wait/cond_timed_wait (which presumably turns on OTCBCTWACTIVE 
in the OTCB).

 That is assuming that the OTCBCTWACTIVE flag is set for both cond_wait and 
cond_timed_wait.

 I did find APAR PK80435 that references OTCBCTWACTIVE but couldn't find any 
documentation
 on the bit itself, and I don't know if it's a programmable interface

 IBM very carefully claims:

Only the following fields are externally documented. All other fields are 
reserved for IBM use only.
OtcbThli
OtcbWLMEToken
OtcbSigPending
OtcbOapb

 Any thoughts?

- Thanks -
- Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ENB: Seconds thoughts about Trilium Notes

I'm with you here.  Between VR3 and Freewin, I've tried floating windows, 
new frames, and rendering into a tab in the log frame.  Freewin has a 
switchable display (edit <-> render) and I find that convenient and easy to 
work with, even without a way to set the default to *render*. Having the 
body pane display style be switchable would work very well for me as a UI, 
should not be hard to implement, and would not preclude any of those other 
display modes.

On Friday, April 26, 2024 at 1:52:49 PM UTC-4 gates...@gmail.com wrote:

> Why would a floating window solve any problems here?  How are you 
> envisioning that a floating VR3 window, *which can already be done* *today 
> without any additional coding*, would help the situation?
>
> As a counterpoint, I only have a single display available to me.  I 
> generally do my work (in Leo) on a single desktop monitor, or a tiny laptop 
> screen.  In *both cases* I would much prefer a switchable pane, rather 
> than a floating window.  The current solution of VR eating up a third of 
> the screen by default, or of faffing about with a floating window (even 
> more irksome on a laptop with a touchpad), is such a poor UX that I avoid 
> it. Enough so that I've effectively stopped using Leo for anything that 
> needs to be rendered.
>
> Adding a first-class 'floating window' feature to VR/3 wouldn't fix any 
> issues.  It would strictly exacerbate the issue.  But a context-aware 
> switchable tab, which is eminently doable, would solve *every single one* 
> of my personal problems.  And I know it's a workable solution *because 
> I've done it*.
>
> Leo is, to me, an editor, an IDE, and a platform.  But it is increasingly 
> *not* an authoring tool for me, because of the current implementation of 
> VR.  And that's frustrating, because authoring any sort of complex 
> documentation *should be* where Leo shines, given the first-class 
> outlining and clones.
>
> Just my $0.02.  I wish we wouldn't just discard things out of hand because 
> of perceived 'dubiousness'.  Experimentation is fruitful, and painless, 
> given git branching.
>
> Jake
>
> On Fri, Apr 26, 2024 at 1:31 PM Edward K. Ream  wrote:
>
>> On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin  wrote:
>>
>> >> Trilium undervalues the power of text:
>>
>> > I think that Edward does not appreciate how often users want to use Leo 
>> as a Notebook...
>>
>> I agree. Leonistas *should *be able to use lots of graphics :-) That's 
>> why improving the VR plugins and (maybe) the rst3 plugin seems like a good 
>> idea.
>>
>> > Trillium...shows you a rendered view of its nodes and makes it harder 
>> to edit and work with the content.
>>
>> > Leo makes it easy to edit and work with text, but harder to insert and 
>> look at rendered graphics, etc.
>>
>> That's a reasonable summary. A floating VR pane would be a step forward.
>>
>> > VR3 can display [jupyter] files using an @jupyter node type. Any text 
>> display would only show the raw html...
>>
>> Yes, sometimes the rendered view is preferable. But that's no reason to 
>> complicate Leo's interface.
>>
>> *Summary*
>>
>> The Easter Egg is the only way to expand the VR pane. An optional 
>> floating VR window would solve that problem.
>>
>> Edward
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "leo-editor" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to leo-editor+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/CAMF8tS1WZmuDxfRg8vU-oWsXKRZOoKSqn2ZP0cGX0Duw_5ys4A%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/leo-editor/CAMF8tS1WZmuDxfRg8vU-oWsXKRZOoKSqn2ZP0cGX0Duw_5ys4A%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/47847ae3-a0eb-45ef-993b-957beece1c2cn%40googlegroups.com.

Bug#1069898: mariadb-server: Command History is shared for all users

2024-04-26 Thread Thomas Schlegel

Package: mariadb-server
Version: 1:10.11.6-0+deb12u1
Severity: important
X-Debbugs-Cc: thomas.schle...@posteo.de

Dear Maintainer,

on a link via socket between Client and Server there is only one history of 
Commands.

Especially the root history is seen by normal user.

Thomas Schlegel

Re: ENB: Seconds thoughts about Trilium Notes

On Friday, April 26, 2024 at 1:13:38 PM UTC-4 Edward K. Ream wrote:

On Fri, Apr 26, 2024 at 8:02 AM Thomas Passin wrote:

>> As an option, the VR pane could become a floating window. 

> This is already possible, at least with VR3.  With VR3 enabled, right 
click on the boundary between two frames to get the splitter menu.  Select 
*Window* then *VR3*.  VR3 opens in a new floating window.  

Surely this can be done w/o Terry's Easter Egg.

I wouldn't call it an Easter Egg, exactly, because it's not really hidden.  
But it's awkward to use.  It seems to me that whatever command is called by 
the final splitter menu selection - if we can figure out what it is - 
should be callable by some other means.  I'd rather do that than mess with 
the VR3 code at this stage.  BTW, you can open a standard body editing pane 
as a separate window in the same way.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/64ab1c7c-3594-436a-847d-e61a1343bbe5n%40googlegroups.com.

Re: Refactoring heads up

2024-04-26 Thread Mark Thomas


On 24/04/2024 17:52, Mark Thomas wrote:



My plan is to commit these changes to 11.0.x with the low risk parts 
(e.g. new methods) back-ported. Then, once we can see what is left, we 
can decide how quickly/slowly we want to back-port the complete fix to 
10.1.x and 9.0.x (the issue was reported against 10.1.x).


All is looking good so far.

The complete refactoring has been applied to 11.0.x

10.1.x and 9.0.x have the new header parser and are using it for the 
ChunkedInputFilter.


The question is how long do we want to wait before back-porting the 
standard HTTP header parsing? Essentially this means back-porting this 
commit:


https://github.com/apache/tomcat/commit/e5acf2cf0f745350c85d81532826d92b1882469a

Thoughts?

I'm thinking wait at least one release cycle before back-porting just in 
case of regressions given that this affects every request.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: ENB: Seconds thoughts about Trilium Notes

On Friday, April 26, 2024 at 7:45:11 AM UTC-4 Edward K. Ream wrote:

This Engineering Notebook post contains second thoughts about Trilium Notes.

*Trilium's weaknesses*

Trilium undervalues the power of text:

I think that Edward does not appreciate how often users want to use Leo as
an *Notebook* as opposed to a *writing* tool. For a notebook, one wants to
include all kinds of material, text and graphics, and then *look at and
read* it many times. For writing, developing code, and so on one mostly
wants to *edit and read text*. Trillium by default, it seems to me, shows
you a rendered view of its nodes and makes it harder to edit and work with
the content. Leo makes it easy to edit and work with text, but harder to
insert and look at rendered graphics, etc.

An example is those Mermaid diagrams. Leo can't currently use Mermaid, but
it can create and render Plantum diagrams, which are somewhat similar,
using VR3 with Asciidoc. It's necessary to install a stand-alone Asciidoc
engine with the right plugins, but it's very feasible. Once created, I at
least would like to see a series of diagrams rendered. The text view would
be useless, and it's unlikely I would be changing the diagrams once
perfected. Seeing the textual source would be a distraction.

Think about how Jupyter notebooks are usually used. It's great to be able
to develop your code in one, complete with graphics and notes. But once
developed, they are generally shared as a set of HTML files, and only
looked at not edited. VR3 can display those files using an @jupyter node
type. Any text display would only show the raw html, which is essentially
useless and distracting to look at.

--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/6af83645-d756-4029-b1c4-5e4fa93f4db9n%40googlegroups.com.

[PATCH] qga: Re-enable the qga-ssh-test when running without fuzzing

According to the comment in qga/meson.build, the test got disabled
since there were problems with the fuzzing job. But instead of
disabling this test completely, we should still be fine running
it when fuzzing is disabled.

Signed-off-by: Thomas Huth 
---
 qga/meson.build | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/qga/meson.build b/qga/meson.build
index 1c3d2a3d1b..46c1d83d7f 100644
--- a/qga/meson.build
+++ b/qga/meson.build
@@ -181,12 +181,11 @@ test_env = environment()
 test_env.set('G_TEST_SRCDIR', meson.current_source_dir())
 test_env.set('G_TEST_BUILDDIR', meson.current_build_dir())
 
-# disable qga-ssh-test for now. glib's G_TEST_OPTION_ISOLATE_DIRS triggers
+# disable qga-ssh-test with fuzzing: glib's G_TEST_OPTION_ISOLATE_DIRS triggers
 # the leak detector in build-oss-fuzz Gitlab CI test. we should re-enable
 # this when an alternative is implemented or when the underlying glib
 # issue is identified/fix
-#if host_os != 'windows'
-if false
+if host_os != 'windows' and not get_option('fuzzing')
   srcs = [files('commands-posix-ssh.c')]
   i = 0
   foreach output: qga_qapi_outputs
-- 
2.44.0

Re: [PATCH] .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs


On 26/04/2024 15.46, Eldon Stegall wrote:

On Fri, Apr 26, 2024 at 02:47:20PM +0200, Thomas Huth wrote:

With regards to NetBSD and OpenBSD, this is not a step backward since these
gitlab jobs were never run anyway (they could only be triggered manually,
but hardly anybody did that AFAIK).

If we want to have proper support for those OSes, I think somebody would
need to set up a custom runner on a beefy KVM-capable server somewhere where
we could run the "make vm-build-*bsd" commands. By the way, are Eldon's CI
runners still around? IIRC they were capable of running KVM ?


My datacenter had a power outage recently, so I disable my runner, and
haven't prioritized bringing it back up until now. I am glad to get this
going again, I'll look at it this weekend.


It's not for me to decide, but IMHO it would be a great possibility to run 
some additional KVM-based tests (like the vm-build-*bsd tests) in QEMU's CI!



There should also be plenty of space to build *bsd VM's. Do pre-existing
upstream BSD images have an nocloud support so that we can build from a
stable updated base? Sorry I'm not super familiar with the BSD
ecosystems, but happy to try to fill in the gaps.


QEMU's test suite comes with a handy way of doing tests on OpenBSD, NetBSD 
and FreeBSD: If you've got a KVM-capable Linux host, you just have to type 
"make vm-build-freebsd J=$(nproc)" to build and test the QEMU sources in a 
FreeBSD VM. It will automatically fetch and install a VM image for you.


 Thomas

Re: [OSM-talk-fr] Accès très limité à BD Carthage

2024-04-26 Thread Thomas Gratier

Salut,

J'ai rajouté le WMS https://data.geopf.fr/wms-v/ows, j'ai choisi la couche
"Inventaire national des plans d’eau" et j'ai pu rajouter la couche
correspondante. Par contre, je n'ai pas réussi à consommer le WMTS dans
JOSM. Il me sort des erreurs 400.


Thomas



Le mer. 17 avr. 2024 à 20:34, Cyrille37 OSM  a
écrit :

> Bonjour et Merci Thomas.
>
> Je n'arrive pas à obtenir les tuiles avec ce réglage de base dans JOSM :
>
> Merci
>
> Cyrille37
>
> Le 17/04/2024 à 00:07, Thomas Gratier a écrit :
> > Bonjour,
> >
> > Je n'ai pas de réponse à te donner concernant la BD Carthage. Néanmoins,
> si
> > tu travailles sur les plans d'eau, tu peux te tourner vers l’inventaire
> > national des plans d’eau (INPE) qui date de 2023 et est donc plus récent
> > que la BD Carthage.
> > Il est disponible soit sous forme fichiershttps://
> geoservices.ign.fr/inpe
> > (converti les GPKG en shp pour un usage JOSM) soit en ajoutant le WMTS
> > depuishttps://data.geopf.fr/wmts, soit le WMS
> > https://data.geopf.fr/wms-v/ows  (utile, en particulier si tu utilises
> JOSM)
> >
> >
> > Thomas Gratier
> >
> > Le lun. 15 avr. 2024 à 10:25, rpnpif  a écrit :
> >
> >> Bonjour,
> >> J'ai depuis quelques jours, un accès très limité et très lent à BD
> >> Carthage (plans et cours d'eau). J'ai ai vraiment besoin pour ajouter
> >> des plans d'eau peu visibles à OSM. (L'accès au forum est aussi assez
> >> lent chez moi).
> >> Je me demandais si cela venait de mes accès DNS ou bien si c'est dû aux
> >> serveurs OpenStreetmap.fr. J'ai vu plusieurs rapports de problèmes sur
> >> Github.
> >> Serais-ce lié ?
> >>
> >> --
> >> Rpnpif
> >>
> >>
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [PATCH 3/3] gitlab: remove stale s390x-all-linux-static conf hacks


On 26/04/2024 17.39, Alex Bennée wrote:

The libssh bug references 18.04 which we are no longer running. We
don't need to disable glusterfs because a linux-user build shouldn't
be trying to link to it anyway.

Signed-off-by: Alex Bennée 
---
  .gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)


Reviewed-by: Thomas Huth

Re: [PATCH 2/3] gitlab: migrate the s390x custom machine to 22.04


On 26/04/2024 17.39, Alex Bennée wrote:

20.04 is dead (from QEMU's point of view), long live 22.04!

Signed-off-by: Alex Bennée 
---
  .gitlab-ci.d/custom-runners.yml   |  2 +-
  ...20.04-s390x.yml => ubuntu-22.04-s390x.yml} | 28 +--
  2 files changed, 15 insertions(+), 15 deletions(-)
  rename .gitlab-ci.d/custom-runners/{ubuntu-20.04-s390x.yml => 
ubuntu-22.04-s390x.yml} (88%)


Reviewed-by: Thomas Huth

Re: [PATCH 1/3] build-environment: make some packages optional


On 26/04/2024 17.39, Alex Bennée wrote:

Upgrading the s390x runner exposed some packages are not available for
it. Add an additional optional stage we only enable for arm64/x86_64
for now.

Signed-off-by: Alex Bennée 
---
  scripts/ci/setup/build-environment.yml | 16 +---
  1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/scripts/ci/setup/build-environment.yml 
b/scripts/ci/setup/build-environment.yml
index f344d1a850..de0d866a1e 100644
--- a/scripts/ci/setup/build-environment.yml
+++ b/scripts/ci/setup/build-environment.yml
@@ -95,7 +95,6 @@
- libpam0g-dev
- libpcre2-dev
- libpixman-1-dev
-  - libpmem-dev
- libpng-dev
- libpulse-dev
- librbd-dev
@@ -107,7 +106,6 @@
- libslirp-dev
- libsnappy-dev
- libspice-protocol-dev
-  - libspice-server-dev
- libssh-dev
- libsystemd-dev
- libtasn1-6-dev
@@ -119,7 +117,6 @@
- libvdeplug-dev
- libvirglrenderer-dev
- libvte-2.91-dev
-  - libxen-dev
- libxml2-dev
- libzstd-dev
- llvm
@@ -156,6 +153,19 @@
  - ansible_facts['distribution'] == 'Ubuntu'
  - ansible_facts['distribution_version'] == '22.04'
  
+# not all packages are available for all architectures

+- name: Install additional packages to build QEMU on Ubuntu 22.04
+  package:
+name:
+  - libpmem-dev
+  - libspice-server-dev
+  - libxen-dev
+state: present
+  when:
+- ansible_facts['distribution'] == 'Ubuntu'
+- ansible_facts['distribution_version'] == '22.04'
+- ansible_facts['architecture'] == 'aarch64' or 
ansible_facts['architecture'] == 'x86_64'
+
  - name: Install armhf cross-compile packages to build QEMU on AArch64 
Ubuntu 22.04
package:
  name:


Reviewed-by: Thomas Huth

Re: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range

2024-04-26 Thread Thomas Hellström

On Fri, 2024-04-26 at 09:00 -0300, Jason Gunthorpe wrote:
> On Fri, Apr 26, 2024 at 11:55:05AM +0200, Thomas Hellström wrote:
> > First, the gpu_vma structure is something that partitions the
> > gpu_vm
> > that holds gpu-related range metadata, like what to mirror, desired
> > gpu
> > caching policies etc. These are managed (created, removed and
> > split)
> > mainly from user-space. These are stored and looked up from an rb-
> > tree.
> 
> Except we are talking about SVA here, so all of this should not be
> exposed to userspace.

I think you are misreading. this is on the level "Mirror this region of
the cpu_vm", "prefer this region placed in VRAM", "GPU will do atomic
accesses on this region", very similar to cpu mmap / munmap and
madvise. What I'm trying to say here is that this does not directly
affect the SVA except whether to do SVA or not, and in that case what
region of the CPU mm will be mirrored, and in addition, any gpu
attributes for the mirrored region.

> 
> > Now, when we hit a fault, we want to use hmm_range_fault() to re-
> > populate the faulting PTE, but also to pre-fault a range. Using a
> > range
> > here (let's call this a prefault range for clarity) rather than to
> > insert a single PTE is for multiple reasons:
> 
> I've never said to do a single range, everyone using
> hmm_range_fault()
> has some kind of prefetch populate around algorithm.
> 
> > This is why we've been using dma_map_sg() for these ranges, since
> > it is
> > assumed the benefits gained from 
> 
> This doesn't logically follow. You need to use dma_map_page page by
> page and batch that into your update mechanism.
> 
> If you use dma_map_sg you get into the world of wrongness where you
> have to track ranges and invalidation has to wipe an entire range -
> because you cannot do a dma unmap of a single page from a dma_map_sg
> mapping. This is all the wrong way to use hmm_range_fault.
> 
> hmm_range_fault() is page table mirroring, it fundamentally must be
> page-by-page. The target page table structure must have similar
> properties to the MM page table - especially page by page
> validate/invalidate. Meaning you cannot use dma_map_sg().

To me this is purely an optimization to make the driver page-table and
hence the GPU TLB benefit from iommu coalescing / large pages and large
driver PTEs. It is true that invalidation will sometimes shoot down
large gpu ptes unnecessarily but it will not put any additional burden
on the core AFAICT. For the dma mappings themselves they aren't touched
on invalidation since zapping the gpu PTEs effectively stops any dma
accesses. The dma mappings are rebuilt on the next gpu pagefault,
which, as you mention, are considered slow anyway, but will probably
still reuse the same prefault region, hence needing to rebuild the dma
mappings anyway.

So as long as we are correct and do not adversely affect core mm, If
the gpu performance (for whatever reason) is severely hampered if
large gpu page-table-entries are not used, couldn't this be considered
left to the driver?

And a related question. What about THP pages? OK to set up a single
dma-mapping to those?

> 
> > Second, when pre-faulting a range like this, the mmu interval
> > notifier
> > seqno comes into play, until the gpu ptes for the prefault range
> > are
> > safely in place. Now if an invalidation happens in a completely
> > separate part of the mirror range, it will bump the seqno and force
> > us
> > to rerun the fault processing unnecessarily. 
> 
> This is how hmm_range_fault() works. Drivers should not do hacky
> things to try to "improve" this. SVA granuals should be large, maybe
> not the entire MM, but still quite large. 2M is far to small.
> 
> There is a tradeoff here of slowing down the entire MM vs risking an
> iteration during fault processing. We want to err toward making fault
> processing slowing because fault procesing is already really slow.
> 
> > Hence, for this purpose we
> > ideally just want to get a seqno bump covering the prefault range.
> 
> Ideally, but this is not something we can get for free.
> 
> > That's why finer-granularity mmu_interval notifiers might be
> > beneficial
> > (and then cached for future re-use of the same prefault range).
> > This
> > leads me to the next question:
> 
> It is not the design, please don't invent crazy special Intel things
> on top of hmm_range_fault.

For the record, this is not a "crazy special Intel" invention. It's the
way all GPU implementations do this so far. We're currently catching
up. If we're going to do this in another way, we fully need to
understand why it's a bad thing to do. That's why these que

Re: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib

2024-04-26 Thread Lendacky, Thomas via groups.io


On 4/25/24 01:58, Gerd Hoffmann wrote:

   Hi,


That means the SMMRevId is 0_xx64h for AMD64 processor. But I am not
sure what the value is for AMD32 processor. Maybe 0 according to the
OVMF logic.


The smm emulation in the linux kernel uses 0 and 0x64.


But, I am very suspicious about the logic in AMD's version as below:
--- AMD's version
   SmmSaveStateRegisterLma = (UINT8)EFI_MM_SAVE_STATE_REGISTER_LMA_32BIT;

   LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA;
   if (LMAValue) {
 SmmSaveStateRegisterLma = (UINT8)EFI_MM_SAVE_STATE_REGISTER_LMA_64BIT;
   }
---
The above logic detects the current CPU mode and 64bit save state area layout 
is used if it's running in 64bit.



But if a AMD64 CPU runs in 32bit mode, the above logic causes the
32bit save state area layout is used. It's not right!  The save state
area layout does not depend on the CPU running mode, but whether it's
a legacy CPU or a 64-capable CPU.


Well, that is not entirely clear to me.  Could it be 64-bit processors
support both 32-bit and 64-bit format, for backward compatibility
reasons?

So OvmfPkgIa32 builds could use the 32-bit format, OvmfPkgX64 builds use
the 64-bit format, everything works fine?

The tricky corner case is OvmfPkgIa32X64, where (after applying this
series) 32-bit PEI should setup things for 64-bit SMM/DXE, and checking
the current processor mode will not give use the result we need.


Jiaxin, I agree that the confusion should be cleaned up by AMD
experts. Let's not change any existing behavior.


Agree.  Tom?


I don't have a lot of experience with SMM. I believe Paolo first ported 
over the support into OVMF and might have more insight?


I'll try to take a look at it when I can, but maybe @Abner or @Abdul might 
have more understanding of SMM with which they can comment.


Thanks,
Tom



take care,
   Gerd




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118340): https://edk2.groups.io/g/devel/message/118340
Mute This Topic: https://groups.io/mt/105593568/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: ENB: Seconds thoughts about Trilium Notes

On Friday, April 26, 2024 at 7:45:11 AM UTC-4 Edward K. Ream wrote:

This Engineering Notebook post contains second thoughts about Trilium
Notes.

*tl;dr:* Leo might add only *incremental *improvements inspired by Trilium
Notes. All fundamental aspects of Leo will remain as they are.

*Summary*

*Changing the rendering of Leo's body pane is a dubious idea.* Instead:

- As an option, the VR pane could become a floating window.

This is already possible, at least with VR3. With VR3 enabled, right click
on the boundary between two frames to get the splitter menu. Select
*Window* then *VR3*. VR3 opens in a new floating window. Presumably if
only VR were enabled you could do the same (untested). The whole procedure
is a little awkward but presumably could be made to work from a command or
button.

[Aside - this capability is a tribute to the people who worked up the
splitter mechanism (was that Terry Brown?). Plugins like VR3 were not
written with any code to become free-floating windows, but the basic plugin
mechanism automatically makes them available to the splitter machinery,
which can do the job.]

I have found that using a view like VR3 in a separate window is not as
useful as I would like because window overlaps obscure too much. It would
work fairly well with a very wide monitor. Freewin is also a freefloating
window, and it can switch between text and rendered views, but the expected
usage lends itself better to using several narrower windows next to the
main Leo window. Freewin was intended mostly for comparing two nodes while
being live with its underlying host node so that the host can be edited
while looking at the comparison node.

- The VR pane could use a modular architecture based on plugins. I look
forward to discussing this topic with Thomas.

VR/VR3 basically work in a way that could be more modularized, I would
think. Basically, the plugin must:
1. Figure out what kind of node it is looking at, usually by page
directives like *@language;*
2. Send the contents of the node or subtree to some appropriate code that
transforms it into HTML;
3. Send the HTML to a rendering engine; This is normally the Qt WebEngine
widget (for VR3) but could be something else. As an alternative, for a
node with computer code the code can be extracted and sent to a code engine
for execution. VR3 can collect and display or execute all the code chunks
even if they are separated by non-code parts (so VR3 can do literate
programming basically for free).

- Leo's rst3 command might support VR-related nodes.

I'm not sure just what this means - "VR-related nodes". VR3 can already
render an rst tree because it can (optionally) render any subtree. So you
can get an approximation of what your document will look like, including
any graphics. I use this capability when I author a Sphinx document. It's
very handy. But it is limited because some internal links and other
features have to be created by Sphinx after the rst3 command has been
issued so you can't get a fully complete rendering just from the Leo nodes.

I welcome all comments.

Edward

--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/c81dac45-fec8-4f9b-9a31-6debcea505a4n%40googlegroups.com.

Re: [PATCH] .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs


On 26/04/2024 14.30, Peter Maydell wrote:

On Fri, 26 Apr 2024 at 12:38, Thomas Huth  wrote:


During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.

Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.


So what's the plan to keep BSD CI coverage? This seems
like a step backwards towards "the person handling the
pullreq merges has to do some local private ad-hoc testing
too" :-(


With regards to NetBSD and OpenBSD, this is not a step backward since these 
gitlab jobs were never run anyway (they could only be triggered manually, 
but hardly anybody did that AFAIK).


If we want to have proper support for those OSes, I think somebody would 
need to set up a custom runner on a beefy KVM-capable server somewhere where 
we could run the "make vm-build-*bsd" commands. By the way, are Eldon's CI 
runners still around? IIRC they were capable of running KVM ?


 Thomas

[plasmashell] [Bug 485313] Plasma containment (plus panel) misplaced after interrupting and resuming power to screen (by turning it off or back on again, or unplugging and replugging a USB-C charging

2024-04-26 Thread Thomas Bettler

https://bugs.kde.org/show_bug.cgi?id=485313

Thomas Bettler  changed:

   What|Removed |Added

 CC||thomas.bett...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[PATCH v2] KVM: selftests: Use TAP interface in the set_memory_region test

Use the kselftest_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing. (Note: We are not using the KVM_ONE_VCPU_TEST_SUITE()
macro here since these tests are creating their VMs with the
vm_create_barebones() function, not with vm_create_with_one_vcpu())

Reviewed-by: Andrew Jones 
Signed-off-by: Thomas Huth 
---
 v2:
 - Rebase to linux-next branch
 - Make "loops" variable static
 - Added Andrew's Reviewed-by

 .../selftests/kvm/set_memory_region_test.c| 86 +--
 1 file changed, 42 insertions(+), 44 deletions(-)

diff --git a/tools/testing/selftests/kvm/set_memory_region_test.c 
b/tools/testing/selftests/kvm/set_memory_region_test.c
index 68c899d27561..a5c9bee5235a 100644
--- a/tools/testing/selftests/kvm/set_memory_region_test.c
+++ b/tools/testing/selftests/kvm/set_memory_region_test.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include "kselftest_harness.h"
 
 /*
  * s390x needs at least 1MB alignment, and the x86_64 MOVE/DELETE tests need a
@@ -38,6 +39,8 @@ extern const uint64_t final_rip_end;
 
 static sem_t vcpu_ready;
 
+static int loops;
+
 static inline uint64_t guest_spin_on_val(uint64_t spin_val)
 {
uint64_t val;
@@ -219,6 +222,13 @@ static void test_move_memory_region(void)
kvm_vm_free(vm);
 }
 
+TEST(move_in_use_region)
+{
+   ksft_print_msg("Testing MOVE of in-use region, %d loops\n", loops);
+   for (int i = 0; i < loops; i++)
+   test_move_memory_region();
+}
+
 static void guest_code_delete_memory_region(void)
 {
uint64_t val;
@@ -308,12 +318,19 @@ static void test_delete_memory_region(void)
kvm_vm_free(vm);
 }
 
-static void test_zero_memory_regions(void)
+TEST(delete_in_use_region)
+{
+   ksft_print_msg("Testing DELETE of in-use region, %d loops\n", loops);
+   for (int i = 0; i < loops; i++)
+   test_delete_memory_region();
+}
+
+TEST(zero_memory_regions)
 {
struct kvm_vcpu *vcpu;
struct kvm_vm *vm;
 
-   pr_info("Testing KVM_RUN with zero added memory regions\n");
+   ksft_print_msg("Testing KVM_RUN with zero added memory regions\n");
 
vm = vm_create_barebones();
vcpu = __vm_vcpu_add(vm, 0);
@@ -326,7 +343,7 @@ static void test_zero_memory_regions(void)
 }
 #endif /* __x86_64__ */
 
-static void test_invalid_memory_region_flags(void)
+TEST(invalid_memory_region_flags)
 {
uint32_t supported_flags = KVM_MEM_LOG_DIRTY_PAGES;
const uint32_t v2_only_flags = KVM_MEM_GUEST_MEMFD;
@@ -389,7 +406,7 @@ static void test_invalid_memory_region_flags(void)
  * Test it can be added memory slots up to KVM_CAP_NR_MEMSLOTS, then any
  * tentative to add further slots should fail.
  */
-static void test_add_max_memory_regions(void)
+TEST(add_max_memory_regions)
 {
int ret;
struct kvm_vm *vm;
@@ -408,13 +425,13 @@ static void test_add_max_memory_regions(void)
max_mem_slots = kvm_check_cap(KVM_CAP_NR_MEMSLOTS);
TEST_ASSERT(max_mem_slots > 0,
"KVM_CAP_NR_MEMSLOTS should be greater than 0");
-   pr_info("Allowed number of memory slots: %i\n", max_mem_slots);
+   ksft_print_msg("Allowed number of memory slots: %i\n", max_mem_slots);
 
vm = vm_create_barebones();
 
/* Check it can be added memory slots up to the maximum allowed */
-   pr_info("Adding slots 0..%i, each memory region with %dK size\n",
-   (max_mem_slots - 1), MEM_REGION_SIZE >> 10);
+   ksft_print_msg("Adding slots 0..%i, each memory region with %dK size\n",
+  (max_mem_slots - 1), MEM_REGION_SIZE >> 10);
 
mem = mmap(NULL, (size_t)max_mem_slots * MEM_REGION_SIZE + alignment,
   PROT_READ | PROT_WRITE,
@@ -455,12 +472,21 @@ static void test_invalid_guest_memfd(struct kvm_vm *vm, 
int memfd,
TEST_ASSERT(r == -1 && errno == EINVAL, "%s", msg);
 }
 
-static void test_add_private_memory_region(void)
+static bool has_cap_guest_memfd(void)
+{
+   return kvm_has_cap(KVM_CAP_GUEST_MEMFD) &&
+  (kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM));
+}
+
+TEST(add_private_memory_region)
 {
struct kvm_vm *vm, *vm2;
int memfd, i;
 
-   pr_info("Testing ADD of KVM_MEM_GUEST_MEMFD memory regions\n");
+   if (!has_cap_guest_memfd())
+   SKIP(return, "Missing KVM_MEM_GUEST_MEMFD / 
KVM_X86_SW_PROTECTED_VM");
+
+   ksft_print_msg("Testing ADD of KVM_MEM_GUEST_MEMFD memory regions\n");
 
vm = vm_create_barebones_type(KVM_X86_SW_PROTECTED_VM);
 
@@ -491,13 +517,16 @@ static void test_add_private_memory_region(void)
kvm_vm_free(vm);
 }
 
-static void test_add_overlapping_private_memory_regions(void)
+T

Re: problem with mdadm FAI 6.2

2024-04-26 Thread Thomas Lange

First, check if /dev/md1 is already mounted.
Maybe the FAI boot process (using dracut inside the initrd) detect
this raid and activates it.

You may add a hook which wipes add signature of a soft raid using a
simple script. For e.g. under https://fai-project.org/download/misc/
there are partition.WIPEDISKS and wipe-all

These can also remove the disk partition label.
-- 
regards Thomas

[PATCH] .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs

During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.

Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.

Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/cirrus.yml   | 37 ---
 .gitlab-ci.d/cirrus/kvm-build.yml | 31 --
 2 files changed, 68 deletions(-)
 delete mode 100644 .gitlab-ci.d/cirrus/kvm-build.yml

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 4671f069c3..74de2edbb4 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -89,40 +89,3 @@ aarch64-macos-14-base-build:
 PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
 TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
 QEMU_JOB_OPTIONAL: 1
-
-
-# The following jobs run VM-based tests via KVM on a Linux-based Cirrus-CI job
-.cirrus_kvm_job:
-  extends: .base_job_template
-  stage: build
-  image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:master
-  needs: []
-  timeout: 80m
-  script:
-- sed -e "s|[@]CI_REPOSITORY_URL@|$CI_REPOSITORY_URL|g"
-  -e "s|[@]CI_COMMIT_REF_NAME@|$CI_COMMIT_REF_NAME|g"
-  -e "s|[@]CI_COMMIT_SHA@|$CI_COMMIT_SHA|g"
-  -e "s|[@]NAME@|$NAME|g"
-  -e "s|[@]CONFIGURE_ARGS@|$CONFIGURE_ARGS|g"
-  -e "s|[@]TEST_TARGETS@|$TEST_TARGETS|g"
-  <.gitlab-ci.d/cirrus/kvm-build.yml >.gitlab-ci.d/cirrus/$NAME.yml
-- cat .gitlab-ci.d/cirrus/$NAME.yml
-- cirrus-run -v --show-build-log always .gitlab-ci.d/cirrus/$NAME.yml
-  variables:
-QEMU_JOB_CIRRUS: 1
-QEMU_JOB_OPTIONAL: 1
-
-
-x86-netbsd:
-  extends: .cirrus_kvm_job
-  variables:
-NAME: netbsd
-CONFIGURE_ARGS: --target-list=x86_64-softmmu,ppc64-softmmu,aarch64-softmmu
-TEST_TARGETS: check
-
-x86-openbsd:
-  extends: .cirrus_kvm_job
-  variables:
-NAME: openbsd
-CONFIGURE_ARGS: --target-list=i386-softmmu,riscv64-softmmu,mips64-softmmu
-TEST_TARGETS: check
diff --git a/.gitlab-ci.d/cirrus/kvm-build.yml 
b/.gitlab-ci.d/cirrus/kvm-build.yml
deleted file mode 100644
index a93881aa8b..00
--- a/.gitlab-ci.d/cirrus/kvm-build.yml
+++ /dev/null
@@ -1,31 +0,0 @@
-container:
-  image: fedora:35
-  cpu: 4
-  memory: 8Gb
-  kvm: true
-
-env:
-  CIRRUS_CLONE_DEPTH: 1
-  CI_REPOSITORY_URL: "@CI_REPOSITORY_URL@"
-  CI_COMMIT_REF_NAME: "@CI_COMMIT_REF_NAME@"
-  CI_COMMIT_SHA: "@CI_COMMIT_SHA@"
-
-@NAME@_task:
-  @NAME@_vm_cache:
-folder: $HOME/.cache/qemu-vm
-  install_script:
-- dnf update -y
-- dnf install -y git make openssh-clients qemu-img qemu-system-x86 wget 
meson
-  clone_script:
-- git clone --depth 100 "$CI_REPOSITORY_URL" .
-- git fetch origin "$CI_COMMIT_REF_NAME"
-- git reset --hard "$CI_COMMIT_SHA"
-  build_script:
-- if [ -f $HOME/.cache/qemu-vm/images/@NAME@.img ]; then
-make vm-build-@NAME@ J=$(getconf _NPROCESSORS_ONLN)
-  EXTRA_CONFIGURE_OPTS="@CONFIGURE_ARGS@"
-  BUILD_TARGET="@TEST_TARGETS@" ;
-  else
-make vm-build-@NAME@ J=$(getconf _NPROCESSORS_ONLN) BUILD_TARGET=help
-  EXTRA_CONFIGURE_OPTS="--disable-system --disable-user 
--disable-tools" ;
-  fi
-- 
2.44.0

Re: [PATCH] KVM: selftests: Use TAP interface in the set_memory_region test


On 26/04/2024 12.07, Muhammad Usama Anjum wrote:

On 4/26/24 1:55 PM, Thomas Huth wrote:

Use the kselftest_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing. (Note: We are not using the KVM_ONE_VCPU_TEST_SUITE()
macro here since these tests are creating their VMs with the
vm_create_barebones() function, not with vm_create_with_one_vcpu())

Thank you for the patch. I'm unable to apply the patch on next-20240426.


Ah, I was using the master branch ... it's a context conflict due to 
https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?id=dfc083a181bac ... 
I'll send a v2 rebased to the next branch.


 Thomas

[PATCH 2/3] tools/nolibc: implement strerror()

strerror() is commonly used.
For example in kselftest which currently needs to do an #ifdef NOLIBC to
handle the lack of strerror().

Keep it simple and reuse the output format of perror() for strerror().

Signed-off-by: Thomas Weißschuh 
---
 tools/include/nolibc/stdio.h | 10 ++
 tools/testing/selftests/nolibc/nolibc-test.c |  4 
 2 files changed, 14 insertions(+)

diff --git a/tools/include/nolibc/stdio.h b/tools/include/nolibc/stdio.h
index 16cd4d807251..c968dbbc4ef8 100644
--- a/tools/include/nolibc/stdio.h
+++ b/tools/include/nolibc/stdio.h
@@ -376,6 +376,16 @@ int setvbuf(FILE *stream __attribute__((unused)),
return 0;
 }
 
+static __attribute__((unused))
+const char *strerror(int errno)
+{
+   static char buf[18] = "errno=";
+
+   i64toa_r(errno, [6]);
+
+   return buf;
+}
+
 /* make sure to include all global symbols */
 #include "nolibc.h"
 
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c 
b/tools/testing/selftests/nolibc/nolibc-test.c
index dadc9b8f2727..1c23776713f5 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -1208,6 +1208,10 @@ int run_stdlib(int min, int max)
CASE_TEST(strtol_underflow);EXPECT_STRTOX(1, strtol, 
"-0x8001", 16, LONG_MIN, -1, ERANGE); break;
CASE_TEST(strtoul_negative);EXPECT_STRTOX(1, strtoul, 
"-0x1", 16, ULONG_MAX, 4, 0); break;
CASE_TEST(strtoul_overflow);EXPECT_STRTOX(1, strtoul, 
"0x1", 16, ULONG_MAX, -1, ERANGE); break;
+   CASE_TEST(strerror_success);EXPECT_STREQ(is_nolibc, 
strerror(0), "errno=0"); break;
+   CASE_TEST(strerror_EINVAL); EXPECT_STREQ(is_nolibc, 
strerror(EINVAL), "errno=22"); break;
+   CASE_TEST(strerror_int_max);EXPECT_STREQ(is_nolibc, 
strerror(INT_MAX), "errno=2147483647"); break;
+   CASE_TEST(strerror_int_min);EXPECT_STREQ(is_nolibc, 
strerror(INT_MIN), "errno=-2147483648"); break;
 
case __LINE__:
return ret; /* must be last */

-- 
2.44.0

[PATCH 0/3] tools/nolibc: implement strerror()

Adds a simple implementation of strerror() and makes use of it in
kselftests.

Shuah, could you Ack patch 3?
Willy, this should work *without* your Ack.

Signed-off-by: Thomas Weißschuh 
---
Thomas Weißschuh (3):
  selftests/nolibc: introduce condition to run tests only on nolibc
  tools/nolibc: implement strerror()
  selftests: kselftest: also use strerror() on nolibc

 tools/include/nolibc/stdio.h | 10 
 tools/testing/selftests/kselftest.h  |  8 ---
 tools/testing/selftests/nolibc/nolibc-test.c | 36 ++--
 3 files changed, 33 insertions(+), 21 deletions(-)
---
base-commit: a3063ba97f31e0364379a3ffc567203e3f79e877
change-id: 20240425-nolibc-strerror-67f4bfa03035

Best regards,
-- 
Thomas Weißschuh

[PATCH 1/3] selftests/nolibc: introduce condition to run tests only on nolibc

Some tests only make sense on nolibc. To avoid gaps in the test numbers
do to inline "#ifdef NOLIBC", add a condition to formally skip these
tests.

Signed-off-by: Thomas Weißschuh 
---
 tools/testing/selftests/nolibc/nolibc-test.c | 32 +---
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/tools/testing/selftests/nolibc/nolibc-test.c 
b/tools/testing/selftests/nolibc/nolibc-test.c
index 6161bd57a0c9..dadc9b8f2727 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -64,6 +64,14 @@ static const char *argv0;
 /* will be used by constructor tests */
 static int constructor_test_value;
 
+static const int is_nolibc =
+#ifdef NOLIBC
+   1
+#else
+   0
+#endif
+;
+
 /* definition of a series of tests */
 struct test {
const char *name;  /* test name */
@@ -1125,19 +1133,17 @@ int run_stdlib(int min, int max)
CASE_TEST(strchr_foobar_z);EXPECT_STRZR(1, strchr("foobar", 
'z')); break;
CASE_TEST(strrchr_foobar_o);   EXPECT_STREQ(1, 
strrchr("foobar", 'o'), "obar"); break;
CASE_TEST(strrchr_foobar_z);   EXPECT_STRZR(1, 
strrchr("foobar", 'z')); break;
-#ifdef NOLIBC
-   CASE_TEST(strlcat_0);  EXPECT_STRBUFEQ(1, strlcat(buf, 
"bar", 0), buf, 3, "test"); break;
-   CASE_TEST(strlcat_1);  EXPECT_STRBUFEQ(1, strlcat(buf, 
"bar", 1), buf, 4, "test"); break;
-   CASE_TEST(strlcat_5);  EXPECT_STRBUFEQ(1, strlcat(buf, 
"bar", 5), buf, 7, "test"); break;
-   CASE_TEST(strlcat_6);  EXPECT_STRBUFEQ(1, strlcat(buf, 
"bar", 6), buf, 7, "testb"); break;
-   CASE_TEST(strlcat_7);  EXPECT_STRBUFEQ(1, strlcat(buf, 
"bar", 7), buf, 7, "testba"); break;
-   CASE_TEST(strlcat_8);  EXPECT_STRBUFEQ(1, strlcat(buf, 
"bar", 8), buf, 7, "testbar"); break;
-   CASE_TEST(strlcpy_0);  EXPECT_STRBUFEQ(1, strlcpy(buf, 
"bar", 0), buf, 3, "test"); break;
-   CASE_TEST(strlcpy_1);  EXPECT_STRBUFEQ(1, strlcpy(buf, 
"bar", 1), buf, 3, ""); break;
-   CASE_TEST(strlcpy_2);  EXPECT_STRBUFEQ(1, strlcpy(buf, 
"bar", 2), buf, 3, "b"); break;
-   CASE_TEST(strlcpy_3);  EXPECT_STRBUFEQ(1, strlcpy(buf, 
"bar", 3), buf, 3, "ba"); break;
-   CASE_TEST(strlcpy_4);  EXPECT_STRBUFEQ(1, strlcpy(buf, 
"bar", 4), buf, 3, "bar"); break;
-#endif
+   CASE_TEST(strlcat_0);  EXPECT_STRBUFEQ(is_nolibc, 
strlcat(buf, "bar", 0), buf, 3, "test"); break;
+   CASE_TEST(strlcat_1);  EXPECT_STRBUFEQ(is_nolibc, 
strlcat(buf, "bar", 1), buf, 4, "test"); break;
+   CASE_TEST(strlcat_5);  EXPECT_STRBUFEQ(is_nolibc, 
strlcat(buf, "bar", 5), buf, 7, "test"); break;
+   CASE_TEST(strlcat_6);  EXPECT_STRBUFEQ(is_nolibc, 
strlcat(buf, "bar", 6), buf, 7, "testb"); break;
+   CASE_TEST(strlcat_7);  EXPECT_STRBUFEQ(is_nolibc, 
strlcat(buf, "bar", 7), buf, 7, "testba"); break;
+   CASE_TEST(strlcat_8);  EXPECT_STRBUFEQ(is_nolibc, 
strlcat(buf, "bar", 8), buf, 7, "testbar"); break;
+   CASE_TEST(strlcpy_0);  EXPECT_STRBUFEQ(is_nolibc, 
strlcpy(buf, "bar", 0), buf, 3, "test"); break;
+   CASE_TEST(strlcpy_1);  EXPECT_STRBUFEQ(is_nolibc, 
strlcpy(buf, "bar", 1), buf, 3, ""); break;
+   CASE_TEST(strlcpy_2);  EXPECT_STRBUFEQ(is_nolibc, 
strlcpy(buf, "bar", 2), buf, 3, "b"); break;
+   CASE_TEST(strlcpy_3);  EXPECT_STRBUFEQ(is_nolibc, 
strlcpy(buf, "bar", 3), buf, 3, "ba"); break;
+   CASE_TEST(strlcpy_4);  EXPECT_STRBUFEQ(is_nolibc, 
strlcpy(buf, "bar", 4), buf, 3, "bar"); break;
CASE_TEST(memcmp_20_20);   EXPECT_EQ(1, memcmp("aaa\x20", 
"aaa\x20", 4), 0); break;
CASE_TEST(memcmp_20_60);   EXPECT_LT(1, memcmp("aaa\x20", 
"aaa\x60", 4), 0); break;
CASE_TEST(memcmp_60_20);   EXPECT_GT(1, memcmp("aaa\x60", 
"aaa\x20", 4), 0); break;

-- 
2.44.0

[PATCH 3/3] selftests: kselftest: also use strerror() on nolibc

nolibc gained an implementation of strerror() recently.
Use it and drop the ifdeffery.

Signed-off-by: Thomas Weißschuh 
---
 tools/testing/selftests/kselftest.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/tools/testing/selftests/kselftest.h 
b/tools/testing/selftests/kselftest.h
index 541bf192e30e..f4bfe98c31e4 100644
--- a/tools/testing/selftests/kselftest.h
+++ b/tools/testing/selftests/kselftest.h
@@ -161,15 +161,7 @@ static inline __printf(1, 2) void ksft_print_msg(const 
char *msg, ...)
 
 static inline void ksft_perror(const char *msg)
 {
-#ifndef NOLIBC
ksft_print_msg("%s: %s (%d)\n", msg, strerror(errno), errno);
-#else
-   /*
-* nolibc doesn't provide strerror() and it seems
-* inappropriate to add one, just print the errno.
-*/
-   ksft_print_msg("%s: %d)\n", msg, errno);
-#endif
 }
 
 static inline __printf(1, 2) void ksft_test_result_pass(const char *msg, ...)

-- 
2.44.0

Re: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range

2024-04-26 Thread Thomas Hellström

Hi, Jason.

I've quickly read through the discussion here and have a couple of
questions and clarifications to hopefully help moving forward on
aligning on an approach for this.

Let's for simplicity initially ignore migration and assume this is on
integrated hardware since it seems like it's around the
hmm_range_fault() usage there is a disconnect.

First, the gpu_vma structure is something that partitions the gpu_vm
that holds gpu-related range metadata, like what to mirror, desired gpu
caching policies etc. These are managed (created, removed and split)
mainly from user-space. These are stored and looked up from an rb-tree.

Each such mirroring gpu_vma holds an mmu_interval notifier.

For invalidation only purposes, the mmu_interval seqno is not tracked.
An invalidation thus only zaps page-table entries, causing subsequent
accesses to fault. Hence for this purpose, having a single notifier
that covers a huge range is desirable and does not become a problem.

Now, when we hit a fault, we want to use hmm_range_fault() to re-
populate the faulting PTE, but also to pre-fault a range. Using a range
here (let's call this a prefault range for clarity) rather than to
insert a single PTE is for multiple reasons:

1) avoid subsequent adjacent faults
2a) Using huge GPU page-table entries.
2b) Updating the GPU page-table (tree-based and multi-level) becomes
more efficient when using a range.

Here, depending on hardware, 2a might be more or less crucial for GPU
performance. 2b somewhat ties into 2a but otherwise does not affect gpu
performance.

This is why we've been using dma_map_sg() for these ranges, since it is
assumed the benefits gained from 2) above by far outweighs any benefit
from finer-granularity dma-mappings on the rarer occasion of faults.
Are there other benefits from single-page dma mappings that you think
we need to consider here?

Second, when pre-faulting a range like this, the mmu interval notifier
seqno comes into play, until the gpu ptes for the prefault range are
safely in place. Now if an invalidation happens in a completely
separate part of the mirror range, it will bump the seqno and force us
to rerun the fault processing unnecessarily. Hence, for this purpose we
ideally just want to get a seqno bump covering the prefault range.
That's why finer-granularity mmu_interval notifiers might be beneficial
(and then cached for future re-use of the same prefault range). This
leads me to the next question:

You mention that mmu_notifiers are expensive to register. From looking
at the code it seems *mmu_interval* notifiers are cheap unless there
are ongoing invalidations in which case using a gpu_vma-wide notifier
would block anyway? Could you clarify a bit more the cost involved
here? If we don't register these smaller-range interval notifiers, do
you think the seqno bumps from unrelated subranges would be a real
problem?

Finally the size of the pre-faulting range is something we need to
tune. Currently it is cpu vma - wide. I understand you strongly suggest
this should be avoided. Could you elaborate a bit on why this is such a
bad choice?

Thanks,
Thomas

[NTG-context] Re: start/stopregister

2024-04-26 Thread Thomas A. Schmitz


On 4/26/24 10:22 AM, Hans Hagen wrote:



That's because mkii is AI enhanced. Can you try this:


Ah, I see where I was wrong, thank you! I'm mapping from xml, so I 
became confused with the optional parameters that I write as attributes, 
with a number of ifs... But now it should be clear!


All best

Thomas
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

Re: Control Block field that provides the last USS System-Call?

2024-04-26 Thread Thomas David Rivers

Thanks Rob!

Unfortunately - this is intended to be used in a SIR that needs to answer
the question of "was the last service a cond_setup?" to be able to "push back"
a signal, without calling a BPX service.  (Calling a BPX service breaks
the cond_setup.)

IBM documents that the SIR needs to "push back" the signal after a cond_setup,
but doesn't seem to document how the SIR can determine that happened.

I've been scouring control blocks looking for the flag that cond_setup must
be setting, but can't seem to find it... so I was hoping that there was a field
somewhere that held an indicator of the last service invoked.

Thanks for the pointer!

   - Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

[PATCH] KVM: selftests: Use TAP interface in the set_memory_region test

Use the kselftest_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing. (Note: We are not using the KVM_ONE_VCPU_TEST_SUITE()
macro here since these tests are creating their VMs with the
vm_create_barebones() function, not with vm_create_with_one_vcpu())

Signed-off-by: Thomas Huth 
---
 .../selftests/kvm/set_memory_region_test.c| 86 +--
 1 file changed, 42 insertions(+), 44 deletions(-)

diff --git a/tools/testing/selftests/kvm/set_memory_region_test.c 
b/tools/testing/selftests/kvm/set_memory_region_test.c
index bd57d991e27d..4db6a66a3001 100644
--- a/tools/testing/selftests/kvm/set_memory_region_test.c
+++ b/tools/testing/selftests/kvm/set_memory_region_test.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include "kselftest_harness.h"
 
 /*
  * s390x needs at least 1MB alignment, and the x86_64 MOVE/DELETE tests need a
@@ -38,6 +39,8 @@ extern const uint64_t final_rip_end;
 
 static sem_t vcpu_ready;
 
+int loops;
+
 static inline uint64_t guest_spin_on_val(uint64_t spin_val)
 {
uint64_t val;
@@ -219,6 +222,13 @@ static void test_move_memory_region(void)
kvm_vm_free(vm);
 }
 
+TEST(move_in_use_region)
+{
+   ksft_print_msg("Testing MOVE of in-use region, %d loops\n", loops);
+   for (int i = 0; i < loops; i++)
+   test_move_memory_region();
+}
+
 static void guest_code_delete_memory_region(void)
 {
uint64_t val;
@@ -308,12 +318,19 @@ static void test_delete_memory_region(void)
kvm_vm_free(vm);
 }
 
-static void test_zero_memory_regions(void)
+TEST(delete_in_use_region)
+{
+   ksft_print_msg("Testing DELETE of in-use region, %d loops\n", loops);
+   for (int i = 0; i < loops; i++)
+   test_delete_memory_region();
+}
+
+TEST(zero_memory_regions)
 {
struct kvm_vcpu *vcpu;
struct kvm_vm *vm;
 
-   pr_info("Testing KVM_RUN with zero added memory regions\n");
+   ksft_print_msg("Testing KVM_RUN with zero added memory regions\n");
 
vm = vm_create_barebones();
vcpu = __vm_vcpu_add(vm, 0);
@@ -326,7 +343,7 @@ static void test_zero_memory_regions(void)
 }
 #endif /* __x86_64__ */
 
-static void test_invalid_memory_region_flags(void)
+TEST(invalid_memory_region_flags)
 {
uint32_t supported_flags = KVM_MEM_LOG_DIRTY_PAGES;
const uint32_t v2_only_flags = KVM_MEM_GUEST_MEMFD;
@@ -389,7 +406,7 @@ static void test_invalid_memory_region_flags(void)
  * Test it can be added memory slots up to KVM_CAP_NR_MEMSLOTS, then any
  * tentative to add further slots should fail.
  */
-static void test_add_max_memory_regions(void)
+TEST(add_max_memory_regions)
 {
int ret;
struct kvm_vm *vm;
@@ -408,13 +425,13 @@ static void test_add_max_memory_regions(void)
max_mem_slots = kvm_check_cap(KVM_CAP_NR_MEMSLOTS);
TEST_ASSERT(max_mem_slots > 0,
"KVM_CAP_NR_MEMSLOTS should be greater than 0");
-   pr_info("Allowed number of memory slots: %i\n", max_mem_slots);
+   ksft_print_msg("Allowed number of memory slots: %i\n", max_mem_slots);
 
vm = vm_create_barebones();
 
/* Check it can be added memory slots up to the maximum allowed */
-   pr_info("Adding slots 0..%i, each memory region with %dK size\n",
-   (max_mem_slots - 1), MEM_REGION_SIZE >> 10);
+   ksft_print_msg("Adding slots 0..%i, each memory region with %dK size\n",
+  (max_mem_slots - 1), MEM_REGION_SIZE >> 10);
 
mem = mmap(NULL, (size_t)max_mem_slots * MEM_REGION_SIZE + alignment,
   PROT_READ | PROT_WRITE,
@@ -455,12 +472,21 @@ static void test_invalid_guest_memfd(struct kvm_vm *vm, 
int memfd,
TEST_ASSERT(r == -1 && errno == EINVAL, "%s", msg);
 }
 
-static void test_add_private_memory_region(void)
+static bool has_cap_guest_memfd(void)
+{
+   return kvm_has_cap(KVM_CAP_GUEST_MEMFD) &&
+  (kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM));
+}
+
+TEST(add_private_memory_region)
 {
struct kvm_vm *vm, *vm2;
int memfd, i;
 
-   pr_info("Testing ADD of KVM_MEM_GUEST_MEMFD memory regions\n");
+   if (!has_cap_guest_memfd())
+   SKIP(return, "Missing KVM_MEM_GUEST_MEMFD / 
KVM_X86_SW_PROTECTED_VM");
+
+   ksft_print_msg("Testing ADD of KVM_MEM_GUEST_MEMFD memory regions\n");
 
vm = vm_create_barebones_protected_vm();
 
@@ -491,13 +517,16 @@ static void test_add_private_memory_region(void)
kvm_vm_free(vm);
 }
 
-static void test_add_overlapping_private_memory_regions(void)
+TEST(add_overlapping_private_memory_regions)
 {
struct kvm_vm *vm;
int memfd;
int r;
 
-   pr_info("Testing ADD of overlapping KVM_MEM_GUEST_MEMFD memory 
reg

[NTG-context] Re: start/stopregister

2024-04-26 Thread Thomas A. Schmitz


On 4/26/24 9:30 AM, Thomas A. Schmitz wrote:
And here I am again! Both in mkiv and in mkxl, start/stopregister does 
not work when there is already an index entry before. Example below!


All best

Thomas

\setuppapersize [A6]

\starttext
     A\index{A} B \page
     A\startregister [index] {A} B\startregister [index] [B] {B}
     \dorecurse {10} {\input tufte}
     A\stopregister [index] {A} B\stopregister [index] [B]

\page

\placeregister[index]

\stoptext


And I'm not even sure if this is allowed to say anymore, but: works in 
mkii...


Thomas
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NTG-context] Re: start/stopregister

2024-04-26 Thread Thomas A. Schmitz


On 4/25/24 6:27 PM, Thomas A. Schmitz wrote:
Ah, simple typo! After fixing abel to label, startregister gives the 
expected results again! Thanks Hans! I may be back with more register 
questions soon...


And here I am again! Both in mkiv and in mkxl, start/stopregister does 
not work when there is already an index entry before. Example below!


All best

Thomas

\setuppapersize [A6]

\starttext
A\index{A} B \page
A\startregister [index] {A} B\startregister [index] [B] {B}
\dorecurse {10} {\input tufte}
A\stopregister [index] {A} B\stopregister [index] [B]

\page

\placeregister[index]

\stoptext
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

Re: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll enhance jli tracing [v6]

2024-04-26 Thread Thomas Stuefe

On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken  wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and 
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   remove /jre path check

Change still good

> Still looks good. We should maybe change the synopsis (title) of the bug to 
> something like "libjli GetApplicationHome cleanups"?

Well, it does enhance tracing, so the title is not lying :)

-

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2078751493

[konsole] [Bug 349088] Down arrow (and other arrows) characters display wrong width

2024-04-26 Thread Thomas Landauer

https://bugs.kde.org/show_bug.cgi?id=349088

Thomas Landauer  changed:

   What|Removed |Added

 Status|NEEDSINFO   |REPORTED
 Resolution|WAITINGFORINFO  |---
 Ever confirmed|1   |0

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [PATCH 0/3] Make it possible to compile the x86 binaries without FDC


On 25/04/2024 22.56, Philippe Mathieu-Daudé wrote:

Hi Thomas,

On 25/4/24 20:43, Thomas Huth wrote:

For downstream versions of QEMU, we'd like to be able to compile QEMU
without the FDC code included (since it's not required for modern VMs
anymore and the FDC code has rather a bad reputation, see the VENOM CVE).


IIRC you still need to keep the i440fx+piix machine DS due to
migration compatibility, right?

Are you able to migrate a VM booted with FDC to a non-FDC one?


Migration from a machine with FDC to one without is likely not possible. But 
that's also not the purpose of this series. It's about having the 
possibility to build a QEMU binary without FDC at all in case you don't have 
to support old machine types with FDC anymore.



The q35 machine can already be instantiated without FDC, but for being
able to link a binary without the FDC code, the Kconfig file needs some
tweaks and there are two spots in the pc code that directly call functions
from the FDC code - those need to be disabled via #ifdefs.


Is it useful to you to have q35 without FDC but i440fx+piix with?
Or are you removing it from i440fx+piix due to shared code with q35?


I think it might get useful.

 Thomas

cmake problem with cad/opencascade

2024-04-25 Thread Thierry Thomas

Hello,

A problem has been reported for OpenCascade, and unfortunately I cannot
try to fix it ATM for personal reasons. Reading the log it seems that it
could be a problem with cmake: the PR is 278578:

<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278578>

CMake Error at adm/cmake/occt_toolkit.cmake:35 (include_directories):
  include_directories given empty-string as include directory.
Call Stack (most recent call first):
  CMakeLists.txt:34 (include)
  tools/TKShapeView/CMakeLists.txt:6 (OCCT_INCLUDE_CMAKE_FILE)


CMake Error at adm/cmake/qt_macro.cmake:62 (qt4_add_resources):
  Unknown CMake command "qt4_add_resources".
Call Stack (most recent call first):
  adm/cmake/qt_macro.cmake:97 (FIND_AND_WRAP_RESOURCE_FILE)
  adm/cmake/occt_toolkit.cmake:205 (FIND_AND_INSTALL_QT_RESOURCES)
  CMakeLists.txt:34 (include)
  tools/TKShapeView/CMakeLists.txt:6 (OCCT_INCLUDE_CMAKE_FILE)

Remark: Qt4 is not used with this port!

Did you already see such an error? Any idea of the possible cause?

Best regards.
-- 
Th. Thomas.


signature.asc
Description: PGP signature

Re: Preallocation changes in Postgresql 16

2024-04-25 Thread Thomas Munro

On Fri, Apr 26, 2024 at 4:37 AM Riku Iki  wrote:
> I am wondering if there were preallocation related changes in PG16, and if it 
> is possible to disable preallocation in PostgreSQL 16?

I have no opinion on the btrfs details, but I was wondering if someone
might show up with a system that doesn't like that change.  Here is a
magic 8, tuned on "some filesystems":

/*
 * If available and useful, use posix_fallocate() (via
 * FileFallocate()) to extend the relation. That's often more
 * efficient than using write(), as it commonly won't cause the kernel
 * to allocate page cache space for the extended pages.
 *
 * However, we don't use FileFallocate() for small extensions, as it
 * defeats delayed allocation on some filesystems. Not clear where
 * that decision should be made though? For now just use a cutoff of
 * 8, anything between 4 and 8 worked OK in some local testing.
 */
if (numblocks > 8)

I wonder if it wants to be a GUC.

Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers

Hi Joel,

On 2024-04-25 13:04:12+, Joel Granados wrote:
> On Wed, Apr 24, 2024 at 08:12:34PM -0700, Jakub Kicinski wrote:
> > On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > > The series was split from my larger series sysctl-const series [0].
> > > It only focusses on the proc_handlers but is an important step to be
> > > able to move all static definitions of ctl_table into .rodata.
> > 
> > Split this per subsystem, please.
> It is tricky to do that because it changes the first argument (ctl*) to
> const in the proc_handler function type defined in sysclt.h:
> "
> -typedef int proc_handler(struct ctl_table *ctl, int write, void *buffer,
> +typedef int proc_handler(const struct ctl_table *ctl, int write, void 
> *buffer,
> size_t *lenp, loff_t *ppos);
> "
> This means that all the proc_handlers need to change at the same time.
> 
> However, there is an alternative way to do this that allows chunking. We
> first define the proc_handler as a void pointer (casting it where it is
> being used) [1]. Then we could do the constification by subsystem (like
> Jakub proposes). Finally we can "revert the void pointer change so we
> don't have one size fit all pointer as our proc_handler [2].
> 
> Here are some comments about the alternative:
> 1. We would need to make the first argument const in all the derived
>proc_handlers [3] 
> 2. There would be no undefined behavior for two reasons:
>2.1. There is no case where we change the first argument. We know
> this because there are no compile errors after we make it const.
>2.2. We would always go from non-const to const. This is the case
> because all the stuff that is unchanged in non-const.
> 3. If the idea sticks, it should go into mainline as one patchset. I
>would not like to have a void* proc_handler in a kernel release.
> 4. I think this is a "win/win" solution were the constification goes
>    through and it is divided in such a way that it is reviewable.
> 
> I would really like to hear what ppl think about this "heretic"
> alternative. @Thomas, @Luis, @Kees @Jakub?

Thanks for that alternative, I'm not a big fan though.

Besides the wonky syntax, Control Flow Integrity should trap on
this construct. Functions are called through different pointers than
their actual types which is exactly what CFI is meant to prevent.

Maybe people find it easier to review when using
"--word-diff" and/or "-U0" with git diff/show.
There is really nothing going an besides adding a few "const"s.

But if the consensus prefers this solution, I'll be happy to adopt it.

> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/commit/?h=jag/constfy_treewide_alternative=4a383503b1ea650d4e12c1f5838974e879f5aa6f
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/commit/?h=jag/constfy_treewide_alternative=a3be65973d27ec2933b9e81e1bec60be3a9b460d
> [3] proc_dostring, proc_dobool, proc_dointvec


Thomas

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers

Hi Joel,

On 2024-04-25 13:04:12+, Joel Granados wrote:
> On Wed, Apr 24, 2024 at 08:12:34PM -0700, Jakub Kicinski wrote:
> > On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > > The series was split from my larger series sysctl-const series [0].
> > > It only focusses on the proc_handlers but is an important step to be
> > > able to move all static definitions of ctl_table into .rodata.
> > 
> > Split this per subsystem, please.
> It is tricky to do that because it changes the first argument (ctl*) to
> const in the proc_handler function type defined in sysclt.h:
> "
> -typedef int proc_handler(struct ctl_table *ctl, int write, void *buffer,
> +typedef int proc_handler(const struct ctl_table *ctl, int write, void 
> *buffer,
> size_t *lenp, loff_t *ppos);
> "
> This means that all the proc_handlers need to change at the same time.
> 
> However, there is an alternative way to do this that allows chunking. We
> first define the proc_handler as a void pointer (casting it where it is
> being used) [1]. Then we could do the constification by subsystem (like
> Jakub proposes). Finally we can "revert the void pointer change so we
> don't have one size fit all pointer as our proc_handler [2].
> 
> Here are some comments about the alternative:
> 1. We would need to make the first argument const in all the derived
>proc_handlers [3] 
> 2. There would be no undefined behavior for two reasons:
>2.1. There is no case where we change the first argument. We know
> this because there are no compile errors after we make it const.
>2.2. We would always go from non-const to const. This is the case
> because all the stuff that is unchanged in non-const.
> 3. If the idea sticks, it should go into mainline as one patchset. I
>would not like to have a void* proc_handler in a kernel release.
> 4. I think this is a "win/win" solution were the constification goes
>    through and it is divided in such a way that it is reviewable.
> 
> I would really like to hear what ppl think about this "heretic"
> alternative. @Thomas, @Luis, @Kees @Jakub?

Thanks for that alternative, I'm not a big fan though.

Besides the wonky syntax, Control Flow Integrity should trap on
this construct. Functions are called through different pointers than
their actual types which is exactly what CFI is meant to prevent.

Maybe people find it easier to review when using
"--word-diff" and/or "-U0" with git diff/show.
There is really nothing going an besides adding a few "const"s.

But if the consensus prefers this solution, I'll be happy to adopt it.

> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/commit/?h=jag/constfy_treewide_alternative=4a383503b1ea650d4e12c1f5838974e879f5aa6f
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/commit/?h=jag/constfy_treewide_alternative=a3be65973d27ec2933b9e81e1bec60be3a9b460d
> [3] proc_dostring, proc_dobool, proc_dointvec


Thomas

Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers

Hi Joel,

On 2024-04-25 13:04:12+, Joel Granados wrote:
> On Wed, Apr 24, 2024 at 08:12:34PM -0700, Jakub Kicinski wrote:
> > On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > > The series was split from my larger series sysctl-const series [0].
> > > It only focusses on the proc_handlers but is an important step to be
> > > able to move all static definitions of ctl_table into .rodata.
> > 
> > Split this per subsystem, please.
> It is tricky to do that because it changes the first argument (ctl*) to
> const in the proc_handler function type defined in sysclt.h:
> "
> -typedef int proc_handler(struct ctl_table *ctl, int write, void *buffer,
> +typedef int proc_handler(const struct ctl_table *ctl, int write, void 
> *buffer,
> size_t *lenp, loff_t *ppos);
> "
> This means that all the proc_handlers need to change at the same time.
> 
> However, there is an alternative way to do this that allows chunking. We
> first define the proc_handler as a void pointer (casting it where it is
> being used) [1]. Then we could do the constification by subsystem (like
> Jakub proposes). Finally we can "revert the void pointer change so we
> don't have one size fit all pointer as our proc_handler [2].
> 
> Here are some comments about the alternative:
> 1. We would need to make the first argument const in all the derived
>proc_handlers [3] 
> 2. There would be no undefined behavior for two reasons:
>2.1. There is no case where we change the first argument. We know
> this because there are no compile errors after we make it const.
>2.2. We would always go from non-const to const. This is the case
> because all the stuff that is unchanged in non-const.
> 3. If the idea sticks, it should go into mainline as one patchset. I
>would not like to have a void* proc_handler in a kernel release.
> 4. I think this is a "win/win" solution were the constification goes
>    through and it is divided in such a way that it is reviewable.
> 
> I would really like to hear what ppl think about this "heretic"
> alternative. @Thomas, @Luis, @Kees @Jakub?

Thanks for that alternative, I'm not a big fan though.

Besides the wonky syntax, Control Flow Integrity should trap on
this construct. Functions are called through different pointers than
their actual types which is exactly what CFI is meant to prevent.

Maybe people find it easier to review when using
"--word-diff" and/or "-U0" with git diff/show.
There is really nothing going an besides adding a few "const"s.

But if the consensus prefers this solution, I'll be happy to adopt it.

> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/commit/?h=jag/constfy_treewide_alternative=4a383503b1ea650d4e12c1f5838974e879f5aa6f
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/commit/?h=jag/constfy_treewide_alternative=a3be65973d27ec2933b9e81e1bec60be3a9b460d
> [3] proc_dostring, proc_dobool, proc_dointvec


Thomas

Re: [PATCH 0/2] tools/nolibc: implement strtol() and friends

On 2024-04-25 18:30:39+, Willy Tarreau wrote:
> Hi again Thomas,
> 
> On Thu, Apr 25, 2024 at 06:09:25PM +0200, Thomas Weißschuh wrote:
> > I wanted to implement sscanf() for ksft_min_kernel_version() and this is
> > a prerequisite for it.
> > 
> > It's also useful on its own so it gets its own submission.
> > 
> > Signed-off-by: Thomas Weißschuh 
> 
> Nice work, thank you. For the whole series, modulo my small comments on
> 2/2:

Thanks for those great catches!

I addressed them and pushed the result to nolibc/next.

>   Acked-by: Willy Tarreau 

Thomas

Control Block field that provides the last USS System-Call?

2024-04-25 Thread Thomas David Rivers

I've been scouring control-blocks wondering if there is a field somewhere
that happens to provide the most recent USS system-call (to be able
to, in a SIR, determine of cond_setup was the most recent call.)

Does anyone happen to know if that exists somewhere?

- Many thanks -
- Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

[PATCH 0/3] Make it possible to compile the x86 binaries without FDC

For downstream versions of QEMU, we'd like to be able to compile QEMU
without the FDC code included (since it's not required for modern VMs
anymore and the FDC code has rather a bad reputation, see the VENOM CVE).

The q35 machine can already be instantiated without FDC, but for being
able to link a binary without the FDC code, the Kconfig file needs some
tweaks and there are two spots in the pc code that directly call functions
from the FDC code - those need to be disabled via #ifdefs.

The third patch changes the i440fx and isapc machine types so that
they can work without the FDC device, too, in case it has not been
compiled into the binary. It's marked as RFC since I assume that the
FDC was originally a fix compononent of these motherboards, so I'm
unsure whether we should allow the disablement there. OTOH, it seems
to work fine, and the FDC is only disabled when it is not available
in the binary, so I hope this patch is fine, too.

Thomas Huth (3):
  hw/i386/pc: Allow to compile without CONFIG_FDC_ISA
  hw/i386/Kconfig: Allow to compile Q35 without FDC_ISA
  hw/i386: Add the possibility to use i440fx and isapc without FDC

 hw/i386/pc.c  | 13 +
 hw/i386/pc_piix.c |  6 --
 hw/i386/Kconfig   |  2 +-
 3 files changed, 14 insertions(+), 7 deletions(-)

-- 
2.44.0

[PATCH 2/3] hw/i386/Kconfig: Allow to compile Q35 without FDC_ISA

The q35 machine can be used without floppy disk controller (FDC),
but due to our current Kconfig setup, the FDC code is still always
included in the binary. To fix this, the "PC" config option should
only imply the "FDC_ISA" instead of always selecting it.

The i440fx and the isa-pc machine currently always instantiate
the FDC, so we have to add the select statements now there instead.

Signed-off-by: Thomas Huth 
---
 hw/i386/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index a6ee052f9a..0b08580862 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -32,7 +32,7 @@ config PC
 imply VGA_PCI
 imply VIRTIO_VGA
 imply NVDIMM
-select FDC_ISA
+imply FDC_ISA
 select I8259
 select I8254
 select PCKBD
@@ -70,6 +70,7 @@ config I440FX
 imply VMPORT
 imply VMMOUSE
 select ACPI_PIIX4
+select FDC_ISA
 select PC_PCI
 select PC_ACPI
 select PCI_I440FX
@@ -83,6 +84,7 @@ config ISAPC
 bool
 imply VGA_ISA
 select ISA_BUS
+select FDC_ISA
 select PC
 select IDE_ISA
 # FIXME: it is in the same file as i440fx, and does not compile
-- 
2.44.0

[PATCH 1/3] hw/i386/pc: Allow to compile without CONFIG_FDC_ISA

The q35 machine can work without FDC. But to be able to also link
a QEMU binary that does not include the FDC code, we have to make
it possible to disable the spots that call into the FDC code.

Signed-off-by: Thomas Huth 
---
 hw/i386/pc.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 08c7de416f..93c48f6747 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -439,16 +439,19 @@ static void pc_boot_set(void *opaque, const char 
*boot_device, Error **errp)
 
 static void pc_cmos_init_floppy(MC146818RtcState *rtc_state, ISADevice *floppy)
 {
-int val, nb, i;
+int val, nb;
 FloppyDriveType fd_type[2] = { FLOPPY_DRIVE_TYPE_NONE,
FLOPPY_DRIVE_TYPE_NONE };
 
+#ifdef CONFIG_FDC_ISA
 /* floppy type */
 if (floppy) {
-for (i = 0; i < 2; i++) {
+for (int i = 0; i < 2; i++) {
 fd_type[i] = isa_fdc_get_drive_type(floppy, i);
 }
 }
+#endif
+
 val = (cmos_get_fd_drive_type(fd_type[0]) << 4) |
 cmos_get_fd_drive_type(fd_type[1]);
 mc146818rtc_set_cmos_data(rtc_state, 0x10, val);
@@ -1132,7 +1135,7 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl,
 int i;
 DriveInfo *fd[MAX_FD];
 qemu_irq *a20_line;
-ISADevice *fdc, *i8042, *port92, *vmmouse;
+ISADevice *i8042, *port92, *vmmouse;
 
 serial_hds_isa_init(isa_bus, 0, MAX_ISA_SERIAL_PORTS);
 parallel_hds_isa_init(isa_bus, MAX_PARALLEL_PORTS);
@@ -1142,11 +1145,13 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl,
 create_fdctrl |= !!fd[i];
 }
 if (create_fdctrl) {
-fdc = isa_new(TYPE_ISA_FDC);
+#ifdef CONFIG_FDC_ISA
+ISADevice *fdc = isa_new(TYPE_ISA_FDC);
 if (fdc) {
 isa_realize_and_unref(fdc, isa_bus, _fatal);
 isa_fdc_init_drives(fdc, fd);
 }
+#endif
 }
 
 if (!create_i8042) {
-- 
2.44.0

[RFC PATCH 3/3] hw/i386: Add the possibility to use i440fx and isapc without FDC

The i440fx and the isapc machines can be used in binaries without
FDC, too. We just have to make sure that they don't try to instantiate
the FDC when it is not available.

Signed-off-by: Thomas Huth 
---
 hw/i386/pc_piix.c | 6 --
 hw/i386/Kconfig   | 2 --
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8850c49c66..99efb3c45c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -317,8 +317,8 @@ static void pc_init1(MachineState *machine, const char 
*pci_type)
 }
 
 /* init basic PC hardware */
-pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc, true,
- 0x4);
+pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc,
+ !MACHINE_CLASS(pcmc)->no_floppy, 0x4);
 
 pc_nic_init(pcmc, isa_bus, pcms->pcibus);
 
@@ -501,6 +501,7 @@ static void pc_i440fx_machine_options(MachineClass *m)
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
 m->default_nic = "e1000";
+m->no_floppy = !module_object_class_by_name(TYPE_ISA_FDC);
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_RAMFB_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
@@ -931,6 +932,7 @@ static void isapc_machine_options(MachineClass *m)
 pcmc->has_reserved_memory = false;
 m->default_nic = "ne2k_isa";
 m->default_cpu_type = X86_CPU_TYPE_NAME("486");
+m->no_floppy = !module_object_class_by_name(TYPE_ISA_FDC);
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 }
 
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index 0b08580862..f2ef6d1ef2 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -70,7 +70,6 @@ config I440FX
 imply VMPORT
 imply VMMOUSE
 select ACPI_PIIX4
-select FDC_ISA
 select PC_PCI
 select PC_ACPI
 select PCI_I440FX
@@ -84,7 +83,6 @@ config ISAPC
 bool
 imply VGA_ISA
 select ISA_BUS
-select FDC_ISA
 select PC
 select IDE_ISA
 # FIXME: it is in the same file as i440fx, and does not compile
-- 
2.44.0

Re: A Leo relative in the wild: Trilium Notes

On Thursday, April 25, 2024 at 1:55:38 PM UTC-4 Thomas Passin wrote:

On Thursday, April 25, 2024 at 1:25:21 PM UTC-4 Thomas Passin wrote:

>From an architectural point of view, the current Leo editor widget could
get replaced by a widget with several child widgets (a tabbed widget is one
possibility), of which one is the current editor widget, and most keyboard
and mouse input will go to it no matter whether the text or rendering
widget is visible. This plan would require minimal changes to the rest of
Leo's code.

Once we have such a widget, VR3 could render right to it, just as it does
now to a log pane tab. VR3 may not be exactly what we want to end up with
in the long run, but going this route would very quickly give us a working
prototype to get experience with. The approach is to make the rendering
widget in the new node display widget be VR3's rendering widget.

We already have such a widget and all the machinery we need! It's the Log
frame. We create a frame like the Log frame but with the LeoQt edit widget
instead of the Log widget. We put this frame into the location that
currently holds the edit widget. We use the same technique to insert the
VR3 widget into the Log frame but instead we put it into the new
Edit/Render frame. This would require no changes to VR3 or the LeoQt edit
widget.

If all goes well we could even have a prototype working in hours, or days
at the most. Most of the work would be in constructing the Edit/Render
frame (based on the Log frame), and setting it up when a commander is
constructed.

--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/ac51e552-92c3-41bc-8887-1a6f8c2bcc18n%40googlegroups.com.

Re: [PyMOL] ordering objects in the Object Control Panel in PyMOL 3

2024-04-25 Thread Thomas Stewart

Hello Engin,

This is something I'm actively working on and should be improved in the
near future. I unfortunately had to disable reordering for/within groups
until the feature can be implemented properly (including with groups of
groups, which are also currently disabled). With regard to the Ctrl-single
click drag, this is just an oversight on my part and should be easy to
correct. I tend to always use a mouse when I'm developing/testing, so it's
easy for me to forget where the trackpad controls need special
consideration. Hopefully some or all of these concerns will be addressed in
an upcoming patch and I will go through the rest of the 3.0 changes using
only the trackpad to try to catch any similar issues.

Thanks,
Thomas Stewart

On Thu, Apr 25, 2024 at 10:57 AM Engin Özkan  wrote:

> Hi,
>
> I have been using the new PyMOL 3.0.2 for the last week. One of the
> issues I've come across is that ordering objects and selections appear
> in the Object Control Panel sometimes fails. I can two-finger drag to
> move them sometimes in 1-button-viewing mode (on a MacBook Pro, OS
> 14.4.1 using the trackpad), but I can no longer do that with
> Ctrl-single-click -> drag, which used to be possible in PyMOL 2. I
> cannot figure out why reordering sometimes fails and sometimes does not,
> but it may be that I cannot move an object or selection to a position
> above a group, but only below. Deleting all groups lets me fully order
> the list again using two-finger drag (but ctrl-drag still does not work).
>
> Also I have not managed to move groups at all using mouse actions. I
> have not tried the order command in command line.
>
> Best,
>
> Engin
>
>
> --
> Engin Özkan, Ph.D.
> Associate Professor
> Dept of Biochemistry and Molecular Biology
> University of Chicago
> http://ozkan.uchicago.edu
>
>
>
> ___
> PyMOL-users mailing list
> Archives: http://www.mail-archive.com/pymol-users@lists.sourceforge.net
> Unsubscribe:
> https://sourceforge.net/projects/pymol/lists/pymol-users/unsubscribe

-- 

Thomas Stewart | Developer II | Product Manager, PyMOL

[image: Schrödinger, Inc.] <https://schrodinger.com/>
___
PyMOL-users mailing list
Archives: http://www.mail-archive.com/pymol-users@lists.sourceforge.net
Unsubscribe: 
https://sourceforge.net/projects/pymol/lists/pymol-users/unsubscribe

Re: A Leo relative in the wild: Trilium Notes


On Thursday, April 25, 2024 at 1:25:21 PM UTC-4 Thomas Passin wrote:

>From an architectural point of view, the current Leo editor widget could 
get replaced by a widget with several child widgets (a tabbed widget is one 
possibility), of which one is the current editor widget, and most keyboard 
and mouse input will go to it no matter whether the text or rendering 
widget is visible.  This plan would require minimal changes to the rest of 
Leo's code.


Once we have such a widget,  VR3 could render right to it, just as it does 
now to a log pane tab. VR3 may not be exactly what we want to end up with 
in the long run, but going this route would very quickly give us a working 
prototype to get experience with.  The approach is to make the rendering 
widget in the new node display widget be VR3's rendering widget.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5eb10299-5e92-4e0d-a334-f93a13a6e4e9n%40googlegroups.com.

[pve-devel] applied: [PATCH proxmox-firewall] config: macros: add SPICEproxy macro

Am 25/04/2024 um 19:16 schrieb Stefan Hanreich:
> Signed-off-by: Stefan Hanreich 
> ---
>  proxmox-ve-config/resources/macros.json | 9 +
>  1 file changed, 9 insertions(+)
> 
>

applied, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] applied: [PATCH proxmox-firewall] firewall: improve error handling of firewall

Am 25/04/2024 um 19:23 schrieb Stefan Hanreich:
> Error handling of the firewall binary should now be much more robust
> on configuration errors. Instead of panicking in some cases it should
> now log an error.
> 
> Signed-off-by: Stefan Hanreich 
> ---
>  proxmox-firewall/src/bin/proxmox-firewall.rs |   7 +-
>  proxmox-firewall/src/config.rs   | 239 +--
>  proxmox-firewall/src/firewall.rs |   7 +-
>  proxmox-firewall/tests/integration_tests.rs  |  51 ++--
>  4 files changed, 155 insertions(+), 149 deletions(-)
> 
>

applied, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] applied: [PATCH proxmox-firewall] config: nftables: add support for icmp-type any

Am 25/04/2024 um 19:16 schrieb Stefan Hanreich:
> We support any as wildcard for matching all icmp types. Implement
> parsing logic for parsing the any value and support converting the any
> value into an nftables expression.
> 
> Signed-off-by: Stefan Hanreich 
> ---
>  proxmox-nftables/src/expression.rs |  2 ++
>  proxmox-ve-config/src/firewall/types/rule_match.rs | 12 
>  2 files changed, 14 insertions(+)
> 
>

applied, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: A Leo relative in the wild: Trilium Notes

We are really on the same page here!

On Thursday, April 25, 2024 at 12:39:33 PM UTC-4 Edward K. Ream wrote:

On Thursday, April 25, 2024 at 6:57:17 AM UTC-5 Thomas wrote:

Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
we could overlay the rendering frame over the editing frame. We could 
switch in and out of rendering mode to allow editing.  I bet that wouldn't 
be too hard.

Thomas, you may have solved a problem that has bedeviled me for ages! Here 
are my first thoughts:

I've never liked the VR pane. It seems like a significant waste of real 
estate.

I completely agree about the real estate.  Almost always, I display VR3 
renderings in a tab in the log pane just for this reason even though the 
view is smaller.  I have a button to toggle the VR3 tab on and off.  When 
off, the delay after each few keystrokes for rendering is not incurred, so 
the button gets used a lot.  BTW, whether in a separate frame or in a tab 
in the log frame, the VR3 display will update as you type.  The same is 
true in freewin if you toggle to the rendered view (you don't type into the 
freewin window, you type into the parent node in the main Leo window).

Edit modes are confusing, but *visual modes* will work! Here are some 
preliminary thoughts:

*Rendering modes*

Both headlines and body text will specify a *default rendering mode* for 
*each *node:

I have been thinking exactly this.  We have to make sure that the defaults 
do the right thing almost all the time so that people who don't care, and 
legacy outlines, work right without needing to change.

- Headlines like @movie and @html (and all the others that VR and VR3 
support) would set the default rending mode to some graphics mode.

- Otherwise, @language directives will specify the preferred rendering 
mode, usually *text mode*. However, @language rst would specify *rst mode*.

Exactly; remember that VR3 can handle multiple (software) languages in a 
node (only one rendering language per node, though, i.e., RsT, Md, etc.).  
 It would be nice not to lose that ability.  VR3 can also execute the code 
in a node that has intermixed code and non-code sections.

- A possibility: *@rst-tree* in the headline would specify that the 
rendered contents would consist of the node's body and the bodies of all 
descendant nodes.

Tricky - a long subtree can incur too long a rendering time, or too much 
scrolling, especially when graphics are involved.  That's why VR3 has a 
menu item to render a subtree or only the current node.  I bet we could 
come up with a nearly painless way to do the same, but I have found that I 
want to sometimes see the node and sometimes the tree - so I don't think 
that *@rst-tree* is a good way to go.

*Switching modes*

The *toggle-rendering-mode* command will toggle between the *default *and 
*alternate *rendering modes. Text mode will always be one of those modes.

Users are unlikely to become confused about which mode is in effect because 
graphics look very different from text. If confusion does arise, *graphics 
icons* could mark graphics-capable nodes.

Agree. Again, most of the code we need is already working in VR3 and/or 
freewin.  Mainly we need to work out how to provide the overlay frame, and 
how to provide good user controls for switching between text and rendered 
views.

I assume that this capability will be built into the core, since it will 
involve multiple widgets where now there is only an editing widget. We 
should eventually make sure that there is an extension mechanism (via 
plugins) so that people can add new graphic renderings without needing to 
touch core Leo code.

>From an architectural point of view, the current Leo editor widget could 
get replaced by a widget with several child widgets (a tabbed widget is one 
possibility), of which one is the current editor widget, and most keyboard 
and mouse input will go to it no matter whether the text or rendering 
widget is visible.  This plan would require minimal changes to the rest of 
Leo's code.

*Summary*

Rendering body text as either text or graphics seems like a natural idea. 
Why didn't I ever think of this before? And how did we ever live without it?

The *toggle-rendering-mode* command will toggle between graphics and text 
views.
Users are unlikely to become confused about what body panes contain. 

Rendering either text or graphics in the body pane:
- Significantly increases Leo's effective real estate.
- Promises to give Leo the visual capabilities of the most sophisticated 
outliners.

Today is a milestone in Leo's history. And there is further room for 
invention!

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6d6d44d2-b1ab-489b-8b47-

[kwin] [Bug 486123] New: Allow moving/resizing of windows with mouse extra-button

2024-04-25 Thread Thomas Capricelli

https://bugs.kde.org/show_bug.cgi?id=486123

Bug ID: 486123
   Summary: Allow moving/resizing of windows with mouse
extra-button
Classification: Plasma
   Product: kwin
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: input
  Assignee: kwin-bugs-n...@kde.org
  Reporter: kdebugs.20.orz...@spamgourmet.com
  Target Milestone: ---

On most window managers, you can bind mouse extra button for moving and
resizing windows. Unfortunately not in kwin, and most those window managers are
stuck with x11, not wayland.

To be clear, as an example, this is how it's configured in openbox:
  

  
  

  

What it does is that i can drag and drop a window by using button9, and resize
by holding button8. Without using meta/control on keyboard or the usual
left/middle/right buttons on the mouse. Buttons 8&9 are just additionnal
buttons on the side of the mouse (i use the thumb).

This is extremely convenient. I didn't care not using kwin until now, but with
the move to wayland, this is something i deadly need. Please !

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 475876] Support additional mouse keys as modifiers

2024-04-25 Thread Thomas Capricelli

https://bugs.kde.org/show_bug.cgi?id=475876

--- Comment #5 from Thomas Capricelli  ---
Ok. The patch seems very minimalist. I guess I can not move/resize windows with
just a mouse key, right ?
It's only acting as a modifier. I'll open another ticket for that.

-- 
You are receiving this mail because:
You are watching all bug changes.

[NTG-context] Re: start/stopregister


On 4/25/24 18:16, Hans Hagen wrote:
Let's seen if we can make Thomas more of an expert as he's zooming in on 
the issue:


     extendregister {
     metadata   = { name =  name },
     references = { abel =  label },
     }

Let me know if you't see it.


Ah, simple typo! After fixing abel to label, startregister gives the 
expected results again! Thanks Hans! I may be back with more register 
questions soon...


Thomas
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[pve-devel] applied: [PATCH container] fix #5414: use proper percentages in `pct df`

Am 25/04/2024 um 09:40 schrieb Fabian Grünbichler:
> while some people write percentages as 0.XX , putting a % next to that is just
> confusing. also, combined with the format modifier this would be rather lossy,
> and also not match regular `df` output..
> 

Fixes: c6b5965 ("added 'pct df'")

(but I now forgot to amend it too...)

> Signed-off-by: Fabian Grünbichler 
> ---
>  src/PVE/CLI/pct.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>

applied, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[PATCH 1/2] tools/nolibc: add limits for {u,}intmax_t, ulong and {u,}llong

They are useful for users and necessary for strtol() and friends.

Signed-off-by: Thomas Weißschuh 
---
 tools/include/nolibc/stdint.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/tools/include/nolibc/stdint.h b/tools/include/nolibc/stdint.h
index 6665e272e213..cd79ddd6170e 100644
--- a/tools/include/nolibc/stdint.h
+++ b/tools/include/nolibc/stdint.h
@@ -96,6 +96,10 @@ typedef uint64_t  uintmax_t;
 #define UINT_FAST32_MAX  SIZE_MAX
 #define UINT_FAST64_MAX  UINT64_MAX
 
+#define INTMAX_MIN   INT64_MIN
+#define INTMAX_MAX   INT64_MAX
+#define UINTMAX_MAX  UINT64_MAX
+
 #ifndef INT_MIN
 #define INT_MIN  (-__INT_MAX__ - 1)
 #endif
@@ -110,4 +114,19 @@ typedef uint64_t  uintmax_t;
 #define LONG_MAX __LONG_MAX__
 #endif
 
+#ifndef ULONG_MAX
+#define ULONG_MAX ((unsigned long)(__LONG_MAX__) * 2 + 1)
+#endif
+
+#ifndef LLONG_MIN
+#define LLONG_MIN (-__LONG_LONG_MAX__ - 1)
+#endif
+#ifndef LLONG_MAX
+#define LLONG_MAX __LONG_LONG_MAX__
+#endif
+
+#ifndef ULLONG_MAX
+#define ULLONG_MAX ((unsigned long long)(__LONG_LONG_MAX__) * 2 + 1)
+#endif
+
 #endif /* _NOLIBC_STDINT_H */

-- 
2.44.0

[PATCH 2/2] tools/nolibc: implement strtol() and friends

The implementation always works on uintmax_t values.

This is inefficient when only 32bit are needed.
However for all functions this only happens for strtol() on 32bit
platforms.

Signed-off-by: Thomas Weißschuh 
---
 tools/include/nolibc/stdlib.h| 109 +++
 tools/testing/selftests/nolibc/nolibc-test.c |  59 +++
 2 files changed, 168 insertions(+)

diff --git a/tools/include/nolibc/stdlib.h b/tools/include/nolibc/stdlib.h
index 5be9d3c7435a..f66870e25389 100644
--- a/tools/include/nolibc/stdlib.h
+++ b/tools/include/nolibc/stdlib.h
@@ -438,6 +438,115 @@ char *u64toa(uint64_t in)
return itoa_buffer;
 }
 
+static __attribute__((unused))
+uintmax_t __strtox(const char *nptr, char **endptr, int base, intmax_t 
lower_limit, uintmax_t upper_limit)
+{
+   const char signed_ = lower_limit != 0;
+   unsigned char neg = 0, overflow = 0;
+   uintmax_t val = 0, limit, old_val;
+   char c;
+
+   if (base < 0 || base > 35) {
+   SET_ERRNO(EINVAL);
+   goto out;
+   }
+
+   while (isspace(*nptr))
+   nptr++;
+
+   if (*nptr == '+') {
+   nptr++;
+   } else if (*nptr == '-') {
+   neg = 1;
+   nptr++;
+   }
+
+   if (signed_ && neg)
+   limit = -(uintmax_t)lower_limit;
+   else
+   limit = upper_limit;
+
+   if ((base == 0 || base == 16) &&
+   (strncmp(nptr, "0x", 2) == 0 || strncmp(nptr, "0X", 2) == 0)) {
+   base = 16;
+   nptr += 2;
+   } else if (base == 0 && strncmp(nptr, "0", 1) == 0) {
+   base = 8;
+   nptr += 1;
+   } else if (base == 0) {
+   base = 10;
+   }
+
+   while (*nptr) {
+   c = *nptr;
+
+   if (c >= '0' && c <= '9')
+   c -= '0';
+   else if (c >= 'a' && c <= 'z')
+   c = c - 'a' + 10;
+   else if (c >= 'A' && c <= 'Z')
+   c = c - 'A' + 10;
+   else
+   goto out;
+
+   if (c > base)
+   goto out;
+
+   nptr++;
+   old_val = val;
+   val *= base;
+   val += c;
+
+   if (val > limit || val < old_val)
+   overflow = 1;
+   }
+
+out:
+   if (overflow) {
+   SET_ERRNO(ERANGE);
+   val = limit;
+   }
+   if (endptr)
+   *endptr = (char *)nptr;
+   return (neg ? -1 : 1) * val;
+}
+
+static __attribute__((unused))
+long strtol(const char *nptr, char **endptr, int base)
+{
+   return __strtox(nptr, endptr, base, LONG_MIN, LONG_MAX);
+}
+
+static __attribute__((unused))
+unsigned long strtoul(const char *nptr, char **endptr, int base)
+{
+   return __strtox(nptr, endptr, base, 0, ULONG_MAX);
+}
+
+static __attribute__((unused))
+long long strtoll(const char *nptr, char **endptr, int base)
+{
+   return __strtox(nptr, endptr, base, LLONG_MIN, LLONG_MAX);
+}
+
+static __attribute__((unused))
+unsigned long long strtoull(const char *nptr, char **endptr, int base)
+{
+   return __strtox(nptr, endptr, base, 0, ULLONG_MAX);
+}
+
+static __attribute__((unused))
+intmax_t strtoimax(const char *nptr, char **endptr, int base)
+{
+   return __strtox(nptr, endptr, base, INTMAX_MIN, INTMAX_MAX);
+}
+
+static __attribute__((unused))
+uintmax_t strtoumax(const char *nptr, char **endptr, int base)
+{
+   return __strtox(nptr, endptr, base, 0, UINTMAX_MAX);
+}
+
 /* make sure to include all global symbols */
 #include "nolibc.h"
 
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c 
b/tools/testing/selftests/nolibc/nolibc-test.c
index b9c84d42edbe..6161bd57a0c9 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -621,6 +621,51 @@ int expect_str_buf_eq(size_t expr, const char *buf, size_t 
val, int llen, const
return 0;
 }
 
+#define EXPECT_STRTOX(cond, func, input, base, expected, chars, 
expected_errno)\
+   do { if (!(cond)) result(llen, SKIPPED); else ret += 
expect_strtox(llen, func, input, base, expected, chars, expected_errno); } 
while (0)
+
+static __attribute__((unused))
+int expect_strtox(int llen, void *func, const char *input, int base, intmax_t 
expected, int expected_chars, int expected_errno)
+{
+   char *endptr;
+   int actual_errno, actual_chars;
+   intmax_t r;
+
+   errno = 0;
+   if (func == strtol) {
+   r = strtol(input, , base);
+   } else if (func == strtoul) {
+   r = strtoul(input, , base);
+   } else {
+   result(llen, FAIL);
+   return 1;
+   }
+   actual_errno =

[PATCH 0/2] tools/nolibc: implement strtol() and friends

I wanted to implement sscanf() for ksft_min_kernel_version() and this is
a prerequisite for it.

It's also useful on its own so it gets its own submission.

Signed-off-by: Thomas Weißschuh 
---
Thomas Weißschuh (2):
  tools/nolibc: add limits for {u,}intmax_t, ulong and {u,}llong
  tools/nolibc: implement strtol() and friends

 tools/include/nolibc/stdint.h|  19 +
 tools/include/nolibc/stdlib.h| 109 +++
 tools/testing/selftests/nolibc/nolibc-test.c |  59 +++
 3 files changed, 187 insertions(+)
---
base-commit: f1652790cd374bcf98efc913ec69ed18d20e7747
change-id: 20240415-nolibc-strtol-af77a1f2c766

Best regards,
-- 
Thomas Weißschuh

[pve-devel] applied-series: [PATCH installer] install module: getters: correctly use plural in error messages

Am 25/04/2024 um 10:40 schrieb Alexander Zeidler:
> Signed-off-by: Alexander Zeidler 
> ---
>  Proxmox/Install.pm | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
>

applied both patches, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [PATCH v2 4/7] target/s390x/cpu_models: Make kvm_s390_get_host_cpu_model() return boolean


On 25/04/2024 05.12, Zhao Liu wrote:

As error.h suggested, the best practice for callee is to return
something to indicate success / failure.

So make kvm_s390_get_host_cpu_model() return boolean and check the
returned boolean in get_max_cpu_model() instead of accessing @err.

Signed-off-by: Zhao Liu 
---
  target/s390x/cpu_models.c |  9 -
  target/s390x/cpu_models.h |  2 +-
  target/s390x/kvm/kvm.c| 13 +++--
  3 files changed, 12 insertions(+), 12 deletions(-)


Reviewed-by: Thomas Huth

Re: [PULL 00/17] CI job updates, header cleanups and other misc patches


On 25/04/2024 17.04, Richard Henderson wrote:

On 4/24/24 22:11, Thomas Huth wrote:

On 24/04/2024 18.21, Richard Henderson wrote:

On 4/24/24 00:57, Thomas Huth wrote:
The following changes since commit 
13b1e9667737132440f4d500c31cb69320c6b15a:


   Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into 
staging (2024-04-23 17:35:57 -0700)


are available in the Git repository at:

   https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-24

for you to fetch changes up to 8f29bab03ea22694a127ee33edeb4ce99eeb124e:

   target/s390x: Remove KVM stubs in cpu_models.h (2024-04-24 09:45:02 
+0200)



* Update OpenBSD CI image to 7.5
* Update/remove Ubuntu 20.04 CI jobs
* Update CentOS 8 CI jobs to CentOS 9
* Some clean-ups and improvements to travis.yml
* Minor test fixes
* s390x header clean-ups
* Doc updates


This introduces a failure in the migration-compat-x86_64 job:

https://gitlab.com/qemu-project/qemu/-/jobs/6707154868


It wasn't failing for me:

  https://gitlab.com/thuth/qemu/-/jobs/6702058896

And according to the diffstat of my pull request, it's only touching test 
files, docs, and s390x stuff, so I somehow fail to see how it could 
influence x86 migration at a first glance. It also looks like the job is 
running on opensuse, and not on CentOS or Ubuntu, so it should likely not 
be influenced by the changes in this PR.


Could you please hit the re-run button of that job? If it then passes, 
we're likely rather facing an intermitted failure that might have been 
introduced earlier already...


It did pass when re-run.


Ok, thanks! So it's likely and intermitted problem indeed...

I've now submitted a v2 of the pull request where I just dropped the other 
problematic patch that tried to update the custom CentOS runner ... I hope 
that PR should be fine now.


 Thomas

CVS: cvs.openbsd.org: ports

2024-04-25 Thread Thomas Frohwein

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2024/04/25 09:09:07

Modified files:
editors/novelwriter: Makefile distinfo 
editors/novelwriter/pkg: PLIST 

Log message:
update to novelwriter 2.4, release announcements at: 
https://github.com/vkbo/novelWriter/releases

Re: [PATCH] ci: move external build environment setups to CentOS Stream 9


On 12/04/2024 12.37, Paolo Bonzini wrote:

RHEL 9 (and thus also the derivatives) are available since two years
now, so according to QEMU's support policy, we can drop the active
support for the previous major version 8 now.

Thus upgrade our CentOS Stream build environment playbooks to major
version 9 now.

Signed-off-by: Paolo Bonzini 
---
  .../stream/{8 => 9}/build-environment.yml | 31 ++---
  .../stream/{8 => 9}/x86_64/configure  |  4 +-
  .../stream/{8 => 9}/x86_64/test-avocado   |  0
  scripts/ci/setup/build-environment.yml| 44 +++
  4 files changed, 34 insertions(+), 45 deletions(-)
  rename scripts/ci/org.centos/stream/{8 => 9}/build-environment.yml (75%)
  rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/configure (98%)
  rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/test-avocado (100%)


 Hi Paolo!

Not sure whether you've seen my busted pull request, but anyway: It seems 
like this was not enough to update the custom runner. You also need to 
update .gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml for this.


By the way, who has access to the s390x custom runner and could update it to 
Ubuntu 22.04 now? It still seems to work with 20.04 which will be out of 
support from the QEMU POV next week...


 Thomas

[PULL v2 00/16] CI job updates, header cleanups and other misc patches

The following changes since commit 5da72194df36535d773c8bdc951529ecd5e31707:

  Merge tag 'pull-tcg-20240424' of https://gitlab.com/rth7680/qemu into staging 
(2024-04-24 15:51:49 -0700)

are available in the Git repository at:

  https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-25

for you to fetch changes up to 17523a38194d80f2955c6a8e0702e0fc86dd083d:

  target/s390x: Remove KVM stubs in cpu_models.h (2024-04-25 15:15:25 +0200)


* Update OpenBSD CI image to 7.5
* Update/remove Ubuntu 20.04 CI jobs
* Update (most) CentOS 8 CI jobs to CentOS 9
* Some clean-ups and improvements to travis.yml
* Minor test fixes
* s390x header clean-ups
* Doc updates

v2: Drop the problematic patch that updates the custom CentOS 8 runner


Brad Smith (1):
  tests/vm: update openbsd image to 7.5

Inès Varhol (1):
  tests/qtest : Use `g_assert_cmphex` instead of `g_assert_cmpuint`

Manos Pitsidianakis (1):
  docs/devel: fix minor typo in submitting-a-patch.rst

Peter Lieven (1):
  MAINTAINERS: update email of Peter Lieven

Philippe Mathieu-Daudé (3):
  hw/s390x: Include missing 'cpu.h' header
  tests/unit: Remove debug statements in test-nested-aio-poll.c
  target/s390x: Remove KVM stubs in cpu_models.h

Thomas Huth (8):
  Revert ".travis.yml: Cache Avocado cache"
  .travis.yml: Remove the unused UNRELIABLE environment variable
  .travis.yml: Update the jobs to Ubuntu 22.04
  .travis.yml: Do some more testing with Clang
  tests: Remove Ubuntu 20.04 container
  tests/lcitool/libvirt-ci: Update to the latest master branch
  tests/docker/dockerfiles: Run lcitool-refresh after the lcitool update
  tests: Update our CI to use CentOS Stream 9 instead of 8

Zhao Liu (1):
  docs: i386: pc: Update maximum CPU numbers for PC Q35

 MAINTAINERS|   6 +-
 docs/devel/submitting-a-patch.rst  |   2 +-
 docs/system/target-i386-desc.rst.inc   |   2 +-
 hw/s390x/s390-virtio-hcall.h   |   2 +
 target/s390x/cpu_models.h  |  15 --
 hw/s390x/s390-stattrib.c   |   1 +
 tests/qtest/aspeed_fsi-test.c  |  20 +--
 tests/qtest/cmsdk-apb-dualtimer-test.c |   2 +-
 tests/qtest/cmsdk-apb-watchdog-test.c  |   2 +-
 tests/qtest/erst-test.c|   2 +-
 tests/qtest/ivshmem-test.c |  10 +-
 tests/qtest/libqos/ahci.c  |   4 +-
 tests/qtest/microbit-test.c|  46 +++---
 tests/qtest/sse-timer-test.c   |   4 +-
 tests/qtest/stm32l4x5_exti-test.c  | 138 +-
 tests/qtest/stm32l4x5_syscfg-test.c|  74 +-
 tests/unit/test-nested-aio-poll.c  |   7 -
 .gitlab-ci.d/buildtest.yml |  16 +--
 .gitlab-ci.d/container-core.yml|   4 +-
 .travis.yml|  24 +---
 tests/docker/dockerfiles/alpine.docker |   3 +-
 .../dockerfiles/{centos8.docker => centos9.docker} |  35 ++---
 tests/docker/dockerfiles/debian-amd64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-arm64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-armel-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-armhf-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-i686-cross.docker  |   3 +-
 .../dockerfiles/debian-mips64el-cross.docker   |   3 +-
 .../docker/dockerfiles/debian-mipsel-cross.docker  |   3 +-
 .../docker/dockerfiles/debian-ppc64el-cross.docker |   3 +-
 .../docker/dockerfiles/debian-riscv64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-s390x-cross.docker |   3 +-
 tests/docker/dockerfiles/debian.docker |   1 +
 tests/docker/dockerfiles/fedora-win64-cross.docker |   3 +-
 tests/docker/dockerfiles/fedora.docker |   1 +
 tests/docker/dockerfiles/opensuse-leap.docker  |   1 +
 tests/docker/dockerfiles/ubuntu2004.docker | 157 -
 tests/docker/dockerfiles/ubuntu2204.docker |   1 +
 tests/lcitool/libvirt-ci   |   2 +-
 tests/lcitool/mappings.yml |  20 ---
 tests/lcitool/refresh  |   3 +-
 tests/vm/centos|   4 +-
 tests/vm/openbsd   |   6 +-
 43 files changed, 225 insertions(+), 423 deletions(-)
 rename tests/docker/dockerfiles/{centos8.docker => centos9.docker} (82%)
 delete mode 100644 tests/docker/dockerfiles/ubuntu2004.docker

[NTG-context] Re: start/stopregister


On 4/25/24 16:13, Henning Hraban Ramm wrote:

I’m using it like

\startregister[index][bibliografie]{Bibliografie}
…
\stopregister[index][bibliografie]

i.e. very similar to your example, and can confirm it doesn’t result in 
a page range in the index. Also gives no error.


Since I've become an expert on tuc files since yesterday (ha!): if I 
compare the tuc from a mkiv and a mkxl run, I see that mkiv produces an 
entry ["lastrealpage"]=9 in the references table, mkxl doesn't. This 
appears to be the relevant bit, and it is connected with the replacement 
of realpageno by c_realpageno in line 638 of strc-reg.lmt


references.lastrealpage = texgetcount(c_realpageno)

But that's as far as I could get...

Thomas
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NTG-context] start/stopregister


Hi all,

has \startregister been superseded in luametatex or is it not yet 
implemented? I tried to read strc-reg.lmt but couldn't figure out what 
is going on. The following silly minimal test produces the expected 
result with mkiv but not in mkxl.


All best

Thomas

\setuppapersize [A6]

\starttext
A\index{A} B\startregister [index] [B] {B}
\dorecurse {10} {\input tufte}
A\index{A} B\stopregister [index] [B]

\page

\placeregister[index]

\stoptext
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

Re: [VOTE] FLIP-446: Kubernetes Operator State Snapshot CRD

2024-04-25 Thread Thomas Weise

+1 (binding)


On Wed, Apr 24, 2024 at 5:14 AM Yuepeng Pan  wrote:

> +1(non-binding)
>
>
> Best,
> Yuepeng Pan
>
> At 2024-04-24 16:05:07, "Rui Fan" <1996fan...@gmail.com> wrote:
> >+1(binding)
> >
> >Best,
> >Rui
> >
> >On Wed, Apr 24, 2024 at 4:03 PM Mate Czagany  wrote:
> >
> >> Hi everyone,
> >>
> >> I'd like to start a vote on the FLIP-446: Kubernetes Operator State
> >> Snapshot CRD [1]. The discussion thread is here [2].
> >>
> >> The vote will be open for at least 72 hours unless there is an
> objection or
> >> insufficient votes.
> >>
> >> [1]
> >>
> >>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-446%3A+Kubernetes+Operator+State+Snapshot+CRD
> >> [2] https://lists.apache.org/thread/q5dzjwj0qk34rbg2sczyypfhokxoc3q7
> >>
> >> Regards,
> >> Mate
> >>
>

Re: [weewx-user] PID file not created in version 5.0.2

2024-04-25 Thread Thomas Hackler

Hello Silke,
I added your config for weewx to my monit config file but for my case it 
doesn't work. I have the problem that sometimes my gw1000 driver didn't 
work, probalby because of wifi problems. See topic here:

https://groups.google.com/g/weewx-user/c/muxtBGJWkJs

It happened yesterday again but monit did not start weewx.

Maybe you can help me?
Regards
Thomas

silke schrieb am Samstag, 9. März 2024 um 23:54:02 UTC+1:

> I'm sorry I saw your response a bit too late after posting here! Your 
> comments were really helpful 
>
> In case there are others out there using monit, this is my new working 
> config for weewx (avoiding use of PID altogether):
>
> check program weewx with path "/usr/bin/systemctl --quiet is-active weewx"
> if status != 0 then alert
> if status != 0 then exec "/usr/bin/systemctl start weewx.service"
> if 10 restarts within 10 cycles then timeout
>
> Tom Keffer schrieb am Samstag, 9. März 2024 um 23:35:10 UTC+1:
>
>> I don't know what I can add to the comments I already made on the issues 
>> list: the --pidfile option is only used if you use the --daemon option.
>>
>> On Sat, Mar 9, 2024 at 2:19 PM silke  wrote:
>>
>>> Hello,
>>>
>>> I recently made the switch to v5 and overall the migration was working 
>>> quite smoothly, despite running many extensions and skins. I'm on Ubuntu 
>>> and use DEB installation.
>>>
>>> The one thing that is not working yet is my weewx process health 
>>> monitoring which is based on PID file. I cannot get weewx to create a PID 
>>> file whatever I try. (in v4 this worked out of the box)
>>>
>>> I'm adding the --pidfile option to the systemd file, and it shows 
>>> correctly in the process list:
>>>
>>> weewx 941451 51.1  8.7 1921212 1415068 ? Ssl  23:00   3:23 
>>> python3 /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf --pidfile 
>>> /run/weewx/weewx.pid
>>>
>>> the folder /run/weewx is owned by weewx:weewx 
>>>
>>> silke@enterprise:/etc/weewx$ ls -la /run/weewx/
>>> total 0
>>> drwxrwxr-x  2 weewx weewx   40 Mär  9 23:00 .
>>> drwxr-xr-x 50 root  root  1420 Mär  9 23:00 ..
>>>
>>> but still, no file is getting created upon restart.
>>>
>>> Anyone having an idea what I'm doing wrong?
>>>
>>> Thanks a lot, Silke
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/fb454ef9-ae53-4211-bf15-283bd067c567n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/fb454ef9-ae53-4211-bf15-283bd067c567n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/95e8effe-4eba-4078-8d0a-22a0b79ca9e8n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

This sounds pretty much what I had in mind.  The freewin plugin actually 
does the same (in its own separate window). VR/VR3 also replace the 
rendering widget type depending on what is to be rendered.  Currently VR3 
can optionally render to a tab in the log frame instead of to a new frame 
within the overall Leo window.  So we're not far off.

On Thursday, April 25, 2024 at 8:37:59 AM UTC-4 gates...@gmail.com wrote:

> I actually implemented something similar in a private 'leoapp' (app that 
> lives in a .leo file) I wrote for myself a few years back.  Pretty simple 
> to get done, IIRC.
>
> My general pattern was to have a controller class that contained two 
> 'view' widgets (a QTextBrowser for rendered HTML, and a QTextEdit for 
> editing).  The controller class had a wrapper widget that also had an 
> 'edit' toggle button.  When 'edit' is clicked, a callback is fired off to 
> remove the active view widget and replace it with the new one (and set some 
> state in the controller so it doesn't lose track of things).  Content is 
> updated between the two widgets whenever this swap happens.  Internally 
> they are two completely different objects, but to the user, the swap is 
> fairly seamless.
>
> I did write this app relying on PyQt5, unfortunately, so I have a fair bit 
> of updating to do if I want it to work on modern Leo.  Ah well.
>
> Jake
>
> On Thu, Apr 25, 2024 at 8:10 AM Edward K. Ream  wrote:
>
>>
>>
>> On Thu, Apr 25, 2024 at 6:57 AM Thomas Passin  wrote:
>>
>>> Except that standard Leo nodes don't render graphics and other non-text 
>>> items.  That's a big difference. We get around it to a degree with VR/VR3.  
>>> Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
>>> we could overlay the rendering frame over the editing frame. We could 
>>> switch in and out of rendering mode to allow editing.  I bet that wouldn't 
>>> be too hard. One way would be to use a 2-frame tabbed widget.  Leo would 
>>> then have no disadvantage compared with Trillium and its ilk, and would 
>>> keep all of its advantages.
>>>
>>> Yowee!
>>>
>>
>> I'm interested. Let's see what you can do.
>>
>> Edward
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "leo-editor" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to leo-editor+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/CAMF8tS2oz4FPGXyuztu8e%3DpA3_vLG3DCF2x24p1FM_kSrRPJKw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/leo-editor/CAMF8tS2oz4FPGXyuztu8e%3DpA3_vLG3DCF2x24p1FM_kSrRPJKw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2903cdcc-8f76-456a-9723-f448afecba32n%40googlegroups.com.

Re: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll enhance jli tracing [v5]

2024-04-25 Thread Thomas Stuefe

On Tue, 23 Apr 2024 14:31:44 GMT, Matthias Baesken  wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and 
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   adjust output

LGTM

-

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18699#pullrequestreview-2022399268

Re: A Leo relative in the wild: Trilium Notes

See new issue Allow VR/VR3-style rendering overlaid on standard editing 
nodes <https://github.com/leo-editor/leo-editor/issues/3887>.

On Thursday, April 25, 2024 at 8:10:51 AM UTC-4 Edward K. Ream wrote:

> On Thu, Apr 25, 2024 at 6:57 AM Thomas Passin  wrote:
>
>> Except that standard Leo nodes don't render graphics and other non-text 
>> items.  That's a big difference. We get around it to a degree with VR/VR3.  
>> Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
>> we could overlay the rendering frame over the editing frame. We could 
>> switch in and out of rendering mode to allow editing.  I bet that wouldn't 
>> be too hard. One way would be to use a 2-frame tabbed widget.  Leo would 
>> then have no disadvantage compared with Trillium and its ilk, and would 
>> keep all of its advantages.
>>
>> Yowee!
>>
>
> I'm interested. Let's see what you can do.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3335ebeb-a416-4d23-bf4e-1e741956ee5cn%40googlegroups.com.

Re: 'relocatable' project built without --enable-relocatable

2024-04-25 Thread Reuben Thomas

On Thu, 25 Apr 2024 at 14:07, Bruno Haible  wrote:

> OK, I'm committing as shown below.
>

Great, thanks!

> Is there a reason not to make a similar macro for compute_curr_prefix?
>
> Yes:
>   - For compute_curr_prefix, the need has not been demonstrated.
>   - Even if ENABLE_RELOCATABLE is 1, there are cases when
> compute_curr_prefix
> is not defined.
>

Good reasons.

-- 
https://rrt.sc3d.org

Re: A Leo relative in the wild: Trilium Notes

Except that standard Leo nodes don't render graphics and other non-text 
items.  That's a big difference. We get around it to a degree with VR/VR3.  
Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
we could overlay the rendering frame over the editing frame. We could 
switch in and out of rendering mode to allow editing.  I bet that wouldn't 
be too hard. One way would be to use a 2-frame tabbed widget.  Leo would 
then have no disadvantage compared with Trillium and its ilk, and would 
keep all of its advantages.

Yowee!

On Thursday, April 25, 2024 at 5:12:02 AM UTC-4 Edward K. Ream wrote:

> On Thu, Apr 25, 2024 at 3:49 AM Christoph  wrote:
>
> Of course, dealing with hierarchical data sooner or later requires a 
>> mechanism that allows to put data in more than one branch of the 
>> hierarchy so this seems to be a logical step. However, Leo has taken 
>> this step more than 20 years ago and made it its fundamental design 
>> feature.
>>
>
> And Leo has way better programming features, including c, g, p, 
> generators, @others, @clean, and the Mulder/Ream update algorithm.
>
> I'm not worried about competition, and Félix is several years ahead of 
> would-be imitators.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0589aa0a-96a9-4a47-9531-ac40397f5d56n%40googlegroups.com.

Re: bootable pendrive from zip file

2024-04-25 Thread Thomas Schmitt

Hi,

Max Nikulin wrote:
> I was not aware that partition type might be an issue.

Thanks to the normative power of the facts a "may" in the specs becomes
a reason to return a mainboard with an EFI that chooses to join the
"may not" side.


Have a nice day :)

Thomas

[PULL] drm-misc-fixes

2024-04-25 Thread Thomas Zimmermann

Hi Dave, Sima,

here's the PR for drm-misc-fixes.

Best regards
Thomas

drm-misc-fixes-2024-04-25:
Short summary of fixes pull:

atomic-helpers:
- Fix memory leak in drm_format_conv_state_copy()

fbdev:
- fbdefio: Fix address calculation

gma500:
- Fix crash during boot
The following changes since commit 941c0bdbc176df825adf77052263b2d63db6fef7:

  drm/panel: novatek-nt36682e: don't unregister DSI device (2024-04-16 23:17:59 
+0300)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/misc/kernel.git 
tags/drm-misc-fixes-2024-04-25

for you to fetch changes up to 78d9161d2bcd442d93d917339297ffa057dbee8c:

  fbdev: fix incorrect address computation in deferred IO (2024-04-24 15:03:37 
+0200)


Short summary of fixes pull:

atomic-helpers:
- Fix memory leak in drm_format_conv_state_copy()

fbdev:
- fbdefio: Fix address calculation

gma500:
- Fix crash during boot


Lucas Stach (1):
  drm/atomic-helper: fix parameter order in drm_format_conv_state_copy() 
call

Nam Cao (1):
  fbdev: fix incorrect address computation in deferred IO

Patrik Jakobsson (1):
  drm/gma500: Remove lid code

 drivers/gpu/drm/drm_gem_atomic_helper.c |  4 +-
 drivers/gpu/drm/gma500/Makefile |  1 -
 drivers/gpu/drm/gma500/psb_device.c |  5 +--
 drivers/gpu/drm/gma500/psb_drv.h|  9 
 drivers/gpu/drm/gma500/psb_lid.c| 80 -
 drivers/video/fbdev/core/fb_defio.c |  2 +-
 6 files changed, 4 insertions(+), 97 deletions(-)
 delete mode 100644 drivers/gpu/drm/gma500/psb_lid.c

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

[PULL] drm-misc-fixes

2024-04-25 Thread Thomas Zimmermann

Hi Dave, Sima,

here's the PR for drm-misc-fixes.

Best regards
Thomas

drm-misc-fixes-2024-04-25:
Short summary of fixes pull:

atomic-helpers:
- Fix memory leak in drm_format_conv_state_copy()

fbdev:
- fbdefio: Fix address calculation

gma500:
- Fix crash during boot
The following changes since commit 941c0bdbc176df825adf77052263b2d63db6fef7:

  drm/panel: novatek-nt36682e: don't unregister DSI device (2024-04-16 23:17:59 
+0300)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/misc/kernel.git 
tags/drm-misc-fixes-2024-04-25

for you to fetch changes up to 78d9161d2bcd442d93d917339297ffa057dbee8c:

  fbdev: fix incorrect address computation in deferred IO (2024-04-24 15:03:37 
+0200)


Short summary of fixes pull:

atomic-helpers:
- Fix memory leak in drm_format_conv_state_copy()

fbdev:
- fbdefio: Fix address calculation

gma500:
- Fix crash during boot


Lucas Stach (1):
  drm/atomic-helper: fix parameter order in drm_format_conv_state_copy() 
call

Nam Cao (1):
  fbdev: fix incorrect address computation in deferred IO

Patrik Jakobsson (1):
  drm/gma500: Remove lid code

 drivers/gpu/drm/drm_gem_atomic_helper.c |  4 +-
 drivers/gpu/drm/gma500/Makefile |  1 -
 drivers/gpu/drm/gma500/psb_device.c |  5 +--
 drivers/gpu/drm/gma500/psb_drv.h|  9 
 drivers/gpu/drm/gma500/psb_lid.c| 80 -
 drivers/video/fbdev/core/fb_defio.c |  2 +-
 6 files changed, 4 insertions(+), 97 deletions(-)
 delete mode 100644 drivers/gpu/drm/gma500/psb_lid.c

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

[PULL] drm-misc-fixes

2024-04-25 Thread Thomas Zimmermann

Hi Dave, Sima,

here's the PR for drm-misc-fixes.

Best regards
Thomas

drm-misc-fixes-2024-04-25:
Short summary of fixes pull:

atomic-helpers:
- Fix memory leak in drm_format_conv_state_copy()

fbdev:
- fbdefio: Fix address calculation

gma500:
- Fix crash during boot
The following changes since commit 941c0bdbc176df825adf77052263b2d63db6fef7:

  drm/panel: novatek-nt36682e: don't unregister DSI device (2024-04-16 23:17:59 
+0300)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/misc/kernel.git 
tags/drm-misc-fixes-2024-04-25

for you to fetch changes up to 78d9161d2bcd442d93d917339297ffa057dbee8c:

  fbdev: fix incorrect address computation in deferred IO (2024-04-24 15:03:37 
+0200)


Short summary of fixes pull:

atomic-helpers:
- Fix memory leak in drm_format_conv_state_copy()

fbdev:
- fbdefio: Fix address calculation

gma500:
- Fix crash during boot


Lucas Stach (1):
  drm/atomic-helper: fix parameter order in drm_format_conv_state_copy() 
call

Nam Cao (1):
  fbdev: fix incorrect address computation in deferred IO

Patrik Jakobsson (1):
  drm/gma500: Remove lid code

 drivers/gpu/drm/drm_gem_atomic_helper.c |  4 +-
 drivers/gpu/drm/gma500/Makefile |  1 -
 drivers/gpu/drm/gma500/psb_device.c |  5 +--
 drivers/gpu/drm/gma500/psb_drv.h|  9 
 drivers/gpu/drm/gma500/psb_lid.c| 80 -
 drivers/video/fbdev/core/fb_defio.c |  2 +-
 6 files changed, 4 insertions(+), 97 deletions(-)
 delete mode 100644 drivers/gpu/drm/gma500/psb_lid.c

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

[NTG-context] Re: utiliydata


> 
> Nope, very sorry, can’t figure it out… I see job.register, I see I can access 
> structures.refrences.collected, but what about the next level
> 
> utilitydata.structures.references.collected={
> [""]={
>  [“REF"]={
> 
> What does the empty key do? And how do I retrieve the value of
> 
> REF.references.realpage?
> 
> Thomas

Sigh, as always: just when I had hit “send,” I figured it out:

structures.references.collected[""][REF].references.realpage

But I’m not sure if there is an easier/better way. And I still would like to 
know what the empty string as key does.

Thomas
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers

On 2024-04-24 20:12:34+, Jakub Kicinski wrote:
> On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > The series was split from my larger series sysctl-const series [0].
> > It only focusses on the proc_handlers but is an important step to be
> > able to move all static definitions of ctl_table into .rodata.
> 
> Split this per subsystem, please.

Unfortunately this would introduce an enormous amount of code churn.

The function prototypes for each callback have to stay consistent.
So a another callback member ("proc_handler_new") is needed and users
would be migrated to it gradually.

But then *all* definitions of "struct ctl_table" throughout the tree need to
be touched.
In contrast, the proposed series only needs to change the handler
implementations, not their usage sites.

There are many, many more usage sites than handler implementations.

Especially, as the majority of sysctl tables use the standard handlers
(proc_dostring, proc_dobool, ...) and are not affected by the proposed
aproach at all.

And then we would have introduced a new handler name "proc_handler_new"
and maybe have to do the whole thing again to rename it back to
the original and well-known "proc_handler".

Of course if somebody has a better aproach, I'm all ears.

Thomas

Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers