Fixes remove partials

looks good, thanks Joaquin! it looks like there are still a few cells that still use partials or this base_cell wrapper. just wanted to check if that was intentional or not

i finished removing the base_cell wrapper


training dies after first epoch (2.0.0-rc7)

Describe your environment

GPU: mps
VRAM: 128GB unified
CPU arch: arm
OS: macOS
Python: miniconda
Branch: HEAD detached at 2.0.0-rc7
Commit: commit 7a701506a4f1344d1d5125800da512407c5a03f5 (HEAD, tag: 2.0.0-rc7)

Describe the bug
training results in crash after first epoch with:
AttributeError: 'DDIMSampler' object has no attribute 'ddim_timesteps'
| invoke-ai-dev-rc/InvokeAI/ldm/models/diffusion/sampler.py:397 in get_timesteps   │
│                                                                                │
│   394 │   │   ddim_timesteps are created in make_schedule(), and selects the portion of          │
│   395 │   │   timesteps that will be used for sampling, depending on the t_enc in img2img.       │
│   396 │   │   '''                                                                                │
│ ❱ 397 │   │   return self.ddim_timesteps[:ddim_steps]                                            │
│   398 │                                                                                │
│   399 │   def q_sample(self,x0,ts):                                                              │
│   400 │   │   '''                                                                                │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯

To Reproduce
Steps to reproduce the behavior:

attempt to train an embedding

Expected behavior
training proceeds thru epochs making training and validation images.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
just looking around at the code it seems like make_schedule() might never be called. is there a way to switch samplers for training?

also - i see this same error if i try to run txt2img.py

Could you post a full stack trace? This should be easy to fix.
Thanks!

Never mind. I've just pushed a commit that I think will fix the issue. Please check.

thanks, i will update and check.

I had same problem and https://github.com/invoke-ai/InvokeAI/commit/318eb35ea0d3f9aa30762b4dfa2368ae1ebbb0f3 fixed it

yes, this appears to be fixed. thank you.


multivariate plotting

i think you can handle multivariate pd plots in the same way that you handle class probs or interactions. the only difficulties i can think of is when a interaction plot for multivariate outcomes is requested

i added a multivariate flag as an attribute but didn't implement this yet

i added multivariate plots with one explanatory variable with 09e3a684e57a08cfd8a6505b1d2f0446c940d251

we need to add multivariate plots with multiple variables (facet along the second dimension using facet_grid) and interactions (same).

labelled this as a bug as i need it for an applied project as soon as possible

i think this is too complicated


Ported to 1.10

Still works on 1.9.4 too :)

Forge just came out for Minecraft 1.10.2 earlier today - this works on that too :)

Great! Sorry I haven't had a chance to merge it yet, should get around to it tonight.


MetroWindow acts as though Topmost is enabled until disabled while running

Describe the bug
All of the MetroWindow objects in my application are acting as though I've set Topmost = true when I haven't. Explicitly configuring Topmost = false in XAML or as part of a DataContext does not change this - but copying the logic from MenuItem logic from the most recent develop branch example does fix it.
To Reproduce

Create new .NET Core 3.1 WPF project in Visual Studio.
Add latest prerelease NuGet for MahApps.
Change default MainWindow to leverage MahApps.Metro namespace and to inherit MetroWindow instead of Window.
Add the following to App.xaml:

<ResourceDictionary.MergedDictionaries>
    <!-- MahApps -->
<ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Controls.xaml" />
    <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Themes/Light.Blue.xaml" />
    <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Fonts.xaml" />
    <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/FlatButton.xaml" />
</ResourceDictionary.MergedDictionaries>

Run the application and find that the window is always Topmost, system-wide.
Stop application. Add an object like a ToggleSwitch and tie the IsOn attribute as follows:
IsOn="{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type MahAppsControls:MetroWindow}}, Path=Topmost}"
Restart application. Find that although the ToggleSwitch is false, the window is Topmost. Enable the ToggleSwitch, and then disable it. The window is now nolonger Topmost

I have found you can replace the last steps with the Visual Studio debugger by viewing the properties of the MetroWindow. If I forcefully enable Topmost and then disable it, the window well then act as though Topmost is disabled.
I have also found this occurs for not just my MainWindow but any other MetroWindow I add to the application.
Expected behavior
I expect MetroWindow objects to default to Topmost = false, and I expect that if I explicitly configure this in the XAML that the MetroWindow will respond to this configuration.
Environment:

MahApps.Metro 2.0.0-alpha0775
OS: Windows 10 Pro 1909 18363.778
Visual Studio 2019 16.4.3
.NET Core 3.1

@EricLauber Can you try this simple app https://github.com/punker76/MahApps.Metro.netcoreapp30 ? I have the same specs and can't reproduce this issue. Thx.

@EricLauber My specs
dotnet --version
3.1.201

Windows 10 Pro 1909 18363.778

I hadn't checked my .NET version, I'm on 3.1.101.
I cloned that app and it worked fine. The MahApps sample also had worked.

Is there something I could enable or be looking for in console output to see if some other portion of my application is interacting with MahApps and contributing to the issue?

@EricLauber Can you put your sample here on GitHub? It seems curious that your sample doesn't work but the main demo and my one.

I'm working on a business application and cannot share much of the code. I will remove the business logic and see what I can upload. It probably won't be today.

@EricLauber You can try to use this code inside your window. Maybe it helps to see if the TopMost is set on sart.
using ControlzEx;

private PropertyChangeNotifier topMostChangeNotifier;

public TestWindow()
{
    this.topMostChangeNotifier = new PropertyChangeNotifier(this.AssociatedObject, Window.TopmostProperty);
    this.topMostChangeNotifier.ValueChanged += this.TopMostChangeNotifierOnValueChanged;
}

private void TopMostChangeNotifierOnValueChanged(object sender, EventArgs e)
{
}

I placed TestWindow contents in the constructor underneath InitializeComponent. It did not fire with instantiating or showing the window, and it did not fire when I did the maximize/minimize actions. If I actually modified the property (such as through Visual Studio) the event would fire two or three times.

@EricLauber Can you say which version of ControlzEx you have referenced?

It's 4.3.0-alpha0085
Okay. Thank you for the help - I have found my issue. It has nothing to do with MahApps. I began removing code to prepare to upload a copy and upon removing a section I believed to be unrelated, the Topmost behavior began working correctly. I'm not sure why this is, but it's clearly something I did and not part of the library.
Do you have any special procedure for closing issues or otherwise removing them?

Could you tell us what that code did? Maybe it's still something we can prevent or at least add to a list.

My WPF application overrides OnStartup in order to display our own customer splash screen (this is a Window). While the splash screen is up, we load database information. When everything is complete, we:

Instantiate a MetroWindow that is our MainWindow
Set the Owner of the MetroWindow to the splash screen Window. Our MetroWindow is configured with WindowStartupLocation="CenterOwner" - this provides some user experience consistency with the MetroWindow appearing on the same monitor and directly behind the splash screen.
Use MetroWindow.Show() to display it in a non-modal way. Now that it is centered behind the splash screen, we change its Owner to null.
Do some final object-cleanup and and call .Close() on the splash screen.

As soon as I removed configuring the Owner of the MetroWindow to the splash screen (just comment that line out), the weird Topmost issue went away.

That's interesting as normally your window should get closed when you close it's owner.
Having a topmost owner seems to break this behavior.
May i say that making a splash screen topmost is not nice application behavior? It always annoys me when applications do that 😉


Convert to named export and add native esm support

References
https://github.com/alexreardon/memoize-one/issues/37
https://github.com/rollup/rollup/blob/master/build-plugins/emit-module-package-file.js
<EMAIL_ADDRESS>Node supports unflagged esm since v13. In this diff I changed default
import to memoizeOne named one.
import { memoizeOne } from 'memoize-one';
const { memoizeOne } = require('memoize-one');
const { memoizeOne } = window.memoizeOne;

The main reason is TS support without fighting with default commonjs/esm
interop which forces to import a function as a namespace.
import * as memoizeOne from 'memoize-one';

This is incorrect. Module namespace is an object due spec.
Libraries like nanoevents and nanoid ended with named export aswell.
See details here https://github.com/ai/nanoid/issues/128
Also I simplified generated bundles to one umd and one esm because project does not have dependencies and process.env.NODE_ENV usages.

A breaking change :(

Or inconsistent usage

I am not sure what to do with this one. Open to advice!

Major release won't break anybody. See here's big migration guide
https://github.com/ai/nanoid/releases/tag/3.0.0

Well, @alexreardon, what about bumping major version and realising a simple codeshift(or what we are using nowadays) to make migration a joy?

Is this still needed @TrySound ?

Maybe node es modules support but it will require major bump.

Named import is now supported
// default export
export default memoizeOne;
// named export
export { memoizeOne };

Any esm support stuff still needed?
(i'll reopen if so)

Named import is now supported
// default export
export default memoizeOne;
// named export
export { memoizeOne };

Any esm support stuff still needed?
(i'll reopen if so)


New package: robinovitch61.webtoon-dl 0.0.7

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Automated with GoReleaser
Microsoft Reviewers: Open in CodeFlow

I think this is likely a false positive error similar to https://github.com/microsoft/winget-pkgs/pull/132238.

Automatic Validation ended with:

Installation failed with exit code -1978335187 2024-01-15 03:20:58.231 [FAIL] Installer failed security check. Url: https://github.com/robinovitch61/webtoon-dl/releases/download/v0.0.7/webtoon-dl_0.0.7_Windows_x86_64.zip Result: 0x80004005

(Automated response - build 570.)

/AzurePipelines run

What feedback from me is required? I'm not sure what is going wrong in CI unfortunately

Automatic Validation ended with:

Installation failed with exit code -1978335187 2024-01-17 16:19:19.464 [FAIL] Installer failed security check. Url: https://github.com/robinovitch61/webtoon-dl/releases/download/v0.0.7/webtoon-dl_0.0.7_Windows_i386.zip Result: 0x80004005

(Automated response - build 602.)

Hi @robinovitch61,
The package didn't pass a Defender or similar security scan. This might be a false positive and we can rescan tomorrow.
(Automated response - build 602.)

Automatic Validation ended with:

Installation failed with exit code -1978335187 2024-01-17 16:19:19.464 [FAIL] Installer failed security check. Url: https://github.com/robinovitch61/webtoon-dl/releases/download/v0.0.7/webtoon-dl_0.0.7_Windows_i386.zip Result: 0x80004005

(Automated response - build 602.)

What feedback from me is required? I'm not sure what is going wrong in CI unfortunately

Hi @robinovitch61,
Sorry for the automation spam. The package has failed a Defender scan twice.

Please virus scan your systems, just to be sure.
Please scan and check your production systems.
Please verify that your CI/CD pipeline has a virus scan or is otherwise not introducing virii.
Please try to avoid online image and icon generation sites, as a few of them might inject viruses into the file, after the image data.

I'm fairly confident there are no viruses in this package.

What are next steps here @stephengillie ? Thanks for your patience with this

/AzurePipelines run

What are next steps here @ stephengillie ? Thanks for your patience with this

Hi @robinovitch61,
The package has to pass a Defender scan to proceed. We can keep rescanning periodically.

What are next steps here @ stephengillie ? Thanks for your patience with this

Hi @robinovitch61,
The package has to pass a Defender scan to proceed. We can keep rescanning periodically.

Sounds good. Looks like it may have passed this time

@wingetbot waivers Add Validation-Executable-Error

Sounds good. Looks like it may have passed this time

Yes! We're past the virus scan part of Validation, and into installing and launching. This label might indicate an error, missing dependency, or maybe that the application is CLI, tray-based, etc.
In this case, it's a CLI, so I've added a waiver.


New version: Wondershare.Repairit version <IP_ADDRESS> (5.6.1)

Created by 🥟 Dumplings in workflow run #6966.

Log
Updated: 5.6.0 → 5.6.1
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request

Microsoft Reviewers: Open in CodeFlow

/azp run


Help: Handling \n

Hi Farling,
I've been bashing my head against this one for about 2 weeks now. Nothing I try results in success so hoping you can help.
Note: I am not that technical, stumbling my way through this!
Objective: I am trying to create a Handlebar that can handle Monsters exporting from Foundry.
Issue: Some of the fields contain a \n. I have tried all sorts of solutions and created handlebars to handle the '\n' but so far I have had 0% at removing the breaklines. The breakline instantly breaks the rendering of the statblock in Obsidian.
Example Source Data
Blood Ooze.md
Example of Problematic Data
      "system": {
        "description": {
          "gm": "",
          "value": "
Trigger The blood ooze is damaged by a piercing or slashing attack.
\n
\n
Effect The blood ooze forms a clot around the wound, reducing the damage taken by 5 (to a minimum of 0).
"

My current handlebar template:
Uploading PF2e_Foundry_Monster_Handlebar_v1.1_Foundry.md…
Pre-Requirements
I am using Kgar's More-Handlebars-Helpers in the process.
https://github.com/kgar/foundry-vtt-more-handlebars-helpers/releases/latest/download/module.json
Example Handlebar Template:
Here are some of the things I have tried.
	raw: {{system.description.value}}
	raw: {{{system.description.value}}}
	version1: {{more-handlebars-helpers-replaceAll system.description.value '\n' ''}}
	version1: {{more-handlebars-helpers-replaceAll system.description.value '\\n' ''}}
	Version2: {{more-handlebars-helpers-replaceAll system.description.value '\\n' '' }}
	Version2: {{{more-handlebars-helpers-replaceAll system.description.value '\\n' '' }}}
	version1: {{more-handlebars-helpers-replaceAll system.description.value '
\n
\n
' ''}}
	Version4: {{more-handlebars-helpers-sanitize system.description.value}}
	Version5: {{{more-handlebars-helpers-sanitize system.description.value}}}

I have tried this through both the JSON/CSV Importer on the Obsidian side and the Foundry Markdown Exporter. In both situations the handlebar does not seem to recognise the '\n' is there. I get different variations in the results above but in all cases the breakline exists in the output.
Example output:
	version1:
Trigger The blood ooze is damaged by a piercing or slashing attack.

Effect The blood ooze forms a clot around the wound, reducing the damage taken by 5 (to a minimum of 0).

	Version4: Trigger The blood ooze is damaged by a piercing or slashing attack.

Effect The blood ooze forms a clot around the wound, reducing the damage taken by 5 (to a minimum of 0).

Is it possible the \n is processed before the handlebar is applied? That's what it feels like.

You can see in your final example outputs that the string "" is the reason the blank line is being put in. So you could try replacing that string instead. On 2 Nov 2023 03:13, ObsidianTTRPGProject @.***> wrote:
Hi Farling,
I've been bashing my head against this one for about 2 weeks now. Nothing I try results in success so hoping you can help.
Note: I am not that technical, stumbling my way through this!
Objective: I am trying to create a Handlebar that can handle Monsters exporting from Foundry.
Issue: Some of the fields contain a \n. I have tried all sorts of solutions and created handlebars to handle the '\n' but so far I have had 0% at removing the breaklines. The breakline instantly breaks the rendering of the statblock in Obsidian.
Example Source Data
Blood Ooze.md
Pre-Requirements
I am using Kgar's More-Handlebars-Helpers in the process.
https://github.com/kgar/foundry-vtt-more-handlebars-helpers/releases/latest/download/module.json
Example Handlebar Template:
Here are some of the things I have tried.
raw: {{system.description.value}}
raw: {{{system.description.value}}}
version1: {{more-handlebars-helpers-replaceAll system.description.value '\n' ''}}
version1: {{more-handlebars-helpers-replaceAll system.description.value '\n' ''}}
Version2: {{more-handlebars-helpers-replaceAll system.description.value '\n' '' }}
Version2: {{{more-handlebars-helpers-replaceAll system.description.value '\n' '' }}}
version1: {{more-handlebars-helpers-replaceAll system.description.value '\n\n' ''}}
Version4: {{more-handlebars-helpers-sanitize system.description.value}}
Version5: {{{more-handlebars-helpers-sanitize system.description.value}}}
I have tried this through both the JSON/CSV Importer on the Obsidian side and the Foundry Markdown Exporter. In both situations the handlebar does not seem to recognise the '\n' is there. I get different variations in the results above but in all cases the breakline exists in the output.
Example output:
version1: Trigger The blood ooze is damaged by a piercing or slashing attack.

Effect The blood ooze forms a clot around the wound, reducing the damage taken by 5 (to a minimum of 0).
Version4: Trigger The blood ooze is damaged by a piercing or slashing attack.

Effect The blood ooze forms a clot around the wound, reducing the damage taken by 5 (to a minimum of 0).
Is it possible the \n is processed before the handlebar is applied? That's what it feels like.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

You can see in your final example outputs that the string "" is the reason the blank line is being put in.

I've tried a few variations of removing that with no luck so far. Here's the latest attempt.
abilities_mid:{{#each items}}{{#if (eq system.category "defensive")}}
  - name: "{{name}} ({{system.actions.value}}{{system.actionType.value}})"
    desc: {{more-handlebars-helpers-sanitize (more-handlebars-helpers-replaceAll (more-handlebars-helpers-replaceAll system.description.value '\n' '') '
' '')}}{{/if}}{{/each}}

This results in:
abilities_mid:
  - name: "Blood Pool (passive)"
    desc: Whenever a creature adjacent to a blood ooze takes bleed damage, the blood ooze regains an amount of Hit Points equal to the damage dealt.
  - name: "Clot (reaction)"
    desc: Trigger The blood ooze is damaged by a piercing or slashing attack.

Effect The blood ooze forms a clot around the wound, reducing the damage taken by 5 (to a minimum of 0).

from source
      "system": {
        "description": {
          "gm": "",
          "value": "
Trigger The blood ooze is damaged by a piercing or slashing attack.
\n
\n
Effect The blood ooze forms a clot around the wound, reducing the damage taken by 5 (to a minimum of 0).
"
        },

Here's another variant
abilities_mid:{{#each items}}{{#if (eq system.category "defensive")}}
  - name: "{{name}} ({{system.actions.value}}{{system.actionType.value}})"
    desc: {{more-handlebars-helpers-sanitize (more-handlebars-helpers-replaceAll system.description.value '\n
\n' '')}}{{/if}}{{/each}}

abilities_mid:
  - name: "Blood Pool (passive)"
    desc: Whenever a creature adjacent to a blood ooze takes bleed damage, the blood ooze regains an amount of Hit Points equal to the damage dealt.
  - name: "Clot (reaction)"
    desc: Trigger The blood ooze is damaged by a piercing or slashing attack.

Effect The blood ooze forms a clot around the wound, reducing the damage taken by 5 (to a minimum of 0).

I've added a request to the handlebars helper module for https://github.com/kgar/foundry-vtt-more-handlebars-helpers/issues/6
This will allow the newlines to be removed using the string in the example given in that image.

You should try with https://github.com/kgar/foundry-vtt-more-handlebars-helpers/releases/tag/v1.2.0
and the new regex function that the author has added.


C#: Enable nullable environment for GodotTools

Enables nullability in majority of GodotTools projects. At first I didn't think this would be possible without GodotSharp getting nullable first (see #83117), but it turns out there was quite a lot that could be setup as-is! The only real area that didn't get expanded upon were certain GodotObject fields (mirroring the selectively disabled nullability seen on a handful of files beforehand), which is likely to be more feasible when GodotSharp gets full-project nullability.

Updated to include GodotTools.IdeMessaging as well; while it's still a touchy file, I realized that it was perfectly safe to upgrade to C# 9 without issue, which does include nullability!

Could you please rebase on the current master? We had an issue with macOS builds which failed your CI.

Done and done!

Thanks!


Clarify PBMT and PBMTE rule when implicit memory access for VS-stage address translation

Although the leaf PTE is not a stage leaf PTE, the specification does not explicitly assign meaning to PBMT in this scenario. Please clarify the following two questions::

Does the leaf PTE's PBMT of implicit memory access for VS-stage address translation affect the memory attribute of accessing the guest's PTE?
If the answer to Q1 is YES, which PBMTE, menvcfg or henvcfg, controls the PBMT?"

#1.  The last paragraph of the Svpbmt spec specifies the behavior for two-stage translations.  In general PBMTs don't affect the PMAs for page tables and the implicit accesses to them.  They only affect the final explicit access after the access's VA has been translated to a PA.

#1. The last paragraph of the Svpbmt spec specifies the behavior for two-stage translations. In general PBMTs don't affect the PMAs for page tables and the implicit accesses to them. They only affect the final explicit access after the access's VA has been translated to a PA.

Got it, no further question.

For henvcfg.PBMTE the spec says "When PBMTE=1, Svpbmt is available for VS-stage address translation. When PBMTE=0, the
implementation behaves as though Svpbmt were not implemented for VS-stage address translation."
And for menvcfg .PBMTE the spec says "The PBMTE bit controls whether the Svpbmt extension is available for use in S-mode and G-stage address translation (i.e., for page tables pointed to by satp or hgatp). When PBMTE=1, Svpbmt is available for Smode and G-stage address translation."
In other words, henvcfg.PBMTE controls only VS-stage PBMT, while menvcfg.PBMTE controls both G-stage and VS-stage (i.e. when vsatp substitutes for satp while V=1).  This is also reflected in the following excerpt from later in the spec: "Similarly, if the setting of the PBMTE bit in menvcfg is changed, an HFENCE.GVMA instruction with rs1=x0 and rs2=x0 suffices to synchronize with respect to the altered interpretation of G-stage and VS-stage PTEs' PBMT fields."
Lastly, Svpbmt does not apply to implicit accesses (nothing in the spec explicitly says otherwise).  This is reflected by the last paragraph in the Svpbmt spec that only talks about determining the final attributes that apply to the explicit access being translated:
"When two-stage address translation is enabled within the H extension, the page-based memory types are
also applied in two stages. First, if hgatp.MODE is not equal to zero, non-zero G-stage PTE PBMT bits
override the attributes in the PMA to produce an intermediate set of attributes. Otherwise, the PMAs serve
as the intermediate attributes. Second, if vsatp.MODE is not equal to zero, non-zero VS-stage PTE PBMT
bits override the intermediate attributes to produce the final set of attributes used by accesses to the page
in question. Otherwise, the intermediate attributes are used as the final set of attributes."

Hi @gfavor ,
"Svpbmt does not apply to implicit accesses."
There are two PBMT illegal conditions:
PBMT = 3 (reserved encoding)
PBMT = 1 or 2 but PBMTE = 0
How should the above conditions be handled? Should they be raised or suppressed?

The specs for the *envcfg PBMTE bits specify that if Svpbmt is disabled for a stage of translation, then the implementation behaves as though Svpbmt were not implemented (for that stage of translation).
For reserved PBMT encodings the Svpbmt spec specifies taking a page fault.

Hi @gfavor
Thanks for your kindly reply.

In other words, henvcfg.PBMTE controls only VS-stage PBMT, while menvcfg.PBMTE controls both G-stage and VS-stage
Do you want to express the following SPEC statement?
I am assuming you had some typo.
The menvcfg.PBMTE bit controls whether the Svpbmt extension is available for use in S-mode and G-stage address translation (i.e., for page tables pointed to by satp or hgatp).

BTW,
As your state in previous post:

Lastly, Svpbmt does not apply to implicit accesses
Does it mean it is Svpbmt is not implemented for implicit access, subject to G-stage address translation, for VS-stage address translation?
If yes, following the SPEC says,
If Svpbmt is not
implemented, bits 62-61 remain reserved and must be zeroed by software for forward compatibility, or
else a page-fault exception is raised
I wonder If we can say PBMT=1/2/3 on leaf PTEs along with implicit access, subject to G-stage address translation, for VS-stage address translation raise a guest page-fault?
And following the SPEC statement:
For non-leaf PTEs, bits 62-61 are reserved for future standard use. Until their use is defined by a
standard extension, they must be cleared by software for forward compatibility, or else a page-fault
exception is raised.
I wonder If we can say PBMT= 1/2/3 on non-leaf PTEs along with implicit access, subject to G-stage address translation, for VS-stage address translation raise a guest page-fault?

Yes, I misspoke.  henvcfg.PBMTE controls VS-stage PBMT availability, while menvcfg.PBMTE controls S-mode and VS-stage PBMT availability.
The question of applicability to implicit accesses is orthogonal to the type of fault taken when non-zero PBMT is encountered and the corresponding PBMTE bit is 0.  The presence or absence of non-zero PBMT and of the Svpbmt extension does not affect implicit accesses and the memory type of implicit accesses is only determined by the PMAs.
Conceptually, from the perspective of a guest OS, it is managing VS-stage PBMT to control the memory type of explicit memory accesses.  The PBMT in the VS-stage PTE controls the memory type of the translated explicit access, and does not control the memory type of any tablewalk implicit accesses.  And of course it is unaware of there being any two-stage translation.  So it would be strange for that leaf PBMT to have affect over G-sage implicit accesses.
But as the spec says for an overall two-stage tablewalk to translate the address of an explicit access, if during a given stage of translation either a reserved PBMT encoding is encountered, or a non-zero encoding is encountered and Svpbmt is effectively not implemented for that stage, then a page-fault exception is raised.
But, when raising a page-fault in connection with G-stage translation, what is actually raised is a guest-page-fault.  As the H spec says:  "guest-page-fault exceptions are raised instead of regular page-fault exceptions."

@gfavor
Please confirm the following two questions whether they are both true?

If we can say PBMT=1/2/3 on leaf PTEs along with implicit access, subject to G-stage address translation, for VS-stage address translation should raise a guest page-fault without referring to any PBMTE(of menvcfg or henvcfg)?
If we can say PBMT= 1/2/3 on non-leaf PTEs along with implicit access, subject to G-stage address translation, for VS-stage address translation should raise a guest page-fault without referring to any PBMTE(of menvcfg or henvcfg)?

The terminology "implicit G-stage" and "PTEs along with implicit access" are not present in the arch specs and are subject to (mis)interpretation.  In any case (and this is back-pedaling from part of what I said earlier), I think the following answers the original and follow-on questions in this issue (excluding the *envcfg-related questions and answers which still stand).

The VS-stage leaf PTE's PBMT does not affect any implicit PTE memory accesses (versus other types of implicit memory accesses).
The G-stage leaf PTE's PBMT that is used to translate a VS-stage implicit PTE access does affect the implicit memory access of that PTE (in combination with the PMAs for that access).
The G-stage leaf PTE's PBMT that is used as part of a two-stage translation of an explicit access's address does affect the explicit memory access as specified by the Svpbmt spec for determining the final attributes of the access.
Non-zero PBMT bits and use of the Reserved PBMT encoding, as defined in the arch spec and based on *envcfg.PBMTE bits, results in a page-fault when encountered in VS-stage PTEs, and a guest-page-fault when encountered in G-stage PTEs.

Hopefully this resolves the outstanding questions.

Fyi, I am working with Andrew Waterman to create a clarification to the Svpbmt spec that more explicitly covers Svpbmt wrt VS-stage implicit PTE memory accesses.

Hi @gfavor
The term I used in this thread refers to the text in section 10.15. Two-stage Address Translation, RISC-V Privileged Version 20240411:

When V=1, memory accesses that would normally bypass address translation are subject to G-stage
address translation alone. This includes memory accesses made in support of VS-stage address
translation, such as reads and writes of VS-level page tables.

I question were based on such memory accesses:

If we can say PBMT=1/2/3 on leaf PTEs along with implicit access, subject to G-stage address translation, for VS-stage address translation should raise a guest page-fault without referring to any PBMTE(of menvcfg or henvcfg)?

If we can say PBMT= 1/2/3 on non-leaf PTEs along with implicit access, subject to G-stage address translation, for VS-stage address translation should raise a guest page-fault without referring to any PBMTE(of menvcfg or henvcfg)?

Or allow me to revise the questions from confusing since they didn't have formal terms to describe:

If we can say PBMT=1/2/3 of leaf PTEs on memory access, subject to G-stage address translation, made in support of VS-stage address translation should raise a guest page-fault without referring to any PBMTE(of menvcfg or henvcfg)?
If we can say PBMT= 1/2/3 of non-leaf PTEs on memory access, subject to G-stage address translation, made in support of VS-stage address translation should raise a guest page-fault without referring to any PBMTE(of menvcfg or henvcfg)?

I'm not 100% certain I fully understand the exact questions being asked, but let's see if this answers them:
If PBMTE=0 for a given stage of translation, then the behavior is as if Svpbmt is not implemented.  Which means a page-fault for a non-zero VS-stage PBMT field, and a guest-page-fault for a non-zero G-stage PBMT field
And if PBMTE=1, then it's the same story as far as fault type, but for a more constrained set of PBMT field cases.

@gfavor
Please be informed, here, that originating questions are concerned about PBMT=1/2 or 3 on leaf PTEs.
Hopefully it helps.

Yes, and the arch spec directly specifies what happens fault-wise for PBMT on leaf PTEs when the relevant PBMTE= 0 or 1.  And for PBMT=1/2 it directly specifies what happens during a two-stage translation.  And my post https://github.com/riscv/riscv-isa-manual/issues/1377#issuecomment-2418234399 specified what happens for G-stage leaf PTE PBMT that is used to translate a VS-stage implicit PTE access.
What am I missing that is unanswered?

@gfavor
I am assuming the following text in https://github.com/riscv/riscv-isa-manual/issues/1377#issuecomment-2418234399 contradict the texts you had answered

The G-stage leaf PTE's PBMT that is used to translate a VS-stage implicit PTE access does affect the implicit memory access of that PTE (in combination with the PMAs for that access).

contradicts

Lastly, Svpbmt does not apply to implicit accesses (nothing in the spec explicitly says otherwise). This is reflected by the last paragraph in the Svpbmt spec that only talks about determining the final attributes that apply to the explicit access being translated:

and

The last paragraph of the Svpbmt spec specifies the behavior for two-stage translations. In general PBMTs don't affect the PMAs for page tables and the implicit accesses to them. They only affect the final explicit access after the access's VA has been translated to a PA.

In https://github.com/riscv/riscv-isa-manual/issues/1377#issuecomment-2418234399, when I said "In any case (and this is back-pedaling from part of what I said earlier), ..." I was essentially saying to ignore any earlier statement that appeared to be contradictory to what I proceeded to say in https://github.com/riscv/riscv-isa-manual/issues/1377#issuecomment-2418234399.

Fyi, I am working with Andrew Waterman to create a clarification to the Svpbmt spec that more explicitly covers Svpbmt wrt VS-stage implicit PTE memory accesses.

Thanks, it's helpful for developers. Please paste the commit link for the riscv-isa-manual after you finish.

Closing this issue since it sounds like the questions have been resolved and a clarification has been added to the Svpbmt spec (see Andrew's PR).

@gfavor @Wangrodman
Thansk for your great support. For me, it clarified all questions throughout the thread, including the quesiton @Wangrodman makde at the first of it.

We're glad to have helped!

Hi @aswaterman
Due the latest PR supplement

These final attributes apply to implicit and explicit accesses that are subject to both stages of address translation. For accesses that are not subject to the first stage of address translation, e.g. VS-stage page-table accesses, the intermediate attributes apply instead.

I wonder whether the following statement needs adjustment as well.

Similarly, if the setting of the PBMTE bit in menvcfg is changed, an HFENCE.GVMA instruction with rs1=x0 and rs2=x0 suffices to synchronize with respect to the altered interpretation of G-stage and VS-stage PTEs PBMT fields.

Because the intermediate attributes (from G-stage translation) apply to VS-stage page-table accesses, when menvcfg.PBMTE is changed, an HFENCE.GVMA doesn't suffice to synchronize with respect to the altered interpretation of G-stage PTE's PBMT filed.
For this case, an extra HFENCE.VVMA, if needed, with rs1=x0 and rs2=x0 is needed to synchronize overall VS-stage translation, composed of VS-stage page-table accesses affected by the intermediate attributes.

Conceptually, an implementation might contain two address-translation caches: one that maps guest virtual addresses to guest physical addresses, and another that maps guest physical addresses to supervisor physical addresses. HFENCE.GVMA need not flush the former cache, but it must flush entries from the latter cache that match the HFENCE.GVMA’s address and VMID arguments.

Hi @aswaterman
The fact that attributes used for VS-stage page-table accesses have changed will change the effect of VS-stage page-table accesses. For example, attributes used for VS-stage page-table accesses changed are of reserved value (0/1/2) when menvcfg.PBMTE is changed from 1 to 0.

@terranfund I agree that not executing an HFENCE.GVMA instruction in the scenario you mentioned might be semantically visible, but it corresponds to a scenario that is uninteresting in practice.  Properly behaved M-mode software will never change the value of PBMTE from 1 to 0 under the feet of an OS or hypervisor.
I think the semantics of these instructions are quite clear from the normative text, and providing extra non-normative guidance to software that discusses situations that would never occur in proper operation is not helpful.

Hi @aswaterman

The fact that attributes used for VS-stage page-table accesses have changed will change the effect of VS-stage page-table accesses. For example, attributes used for VS-stage page-table accesses are of reserved value (1/2/3) when menvcfg.PBMTE is changed from 1 to 0 (from having no guest page-fault to having guest page-fault). HFENCE.GVMA need not flush the cache entries that cached guest virtual addresses to guest physical addresses.

The following question is the originating one I wondered, since HFENCE.GVMA need not flush the cache entries that cached guest virtual addresses to guest physical addresses:
For this case, an extra HFENCE.VVMA, as needed, with rs1=x0 and rs2=x0 is needed to synchronize overall VS-stage translation, composed of VS-stage page-table accesses affected by the intermediate attributes.

I'm a little confused by the missing of questions about PBMT affecting VS-stage page table accesses, PBMT affecting VS-stage translations, and G-stage PBMT affecting VS-stage PTE accesses.  So ...
To the statement above saying "For this case, an extra HFENCE.VVMA, as needed, with rs1=x0 and rs2=x0 is needed to synchronize overall VS-stage translation, composed of VS-stage page-table accesses affected by the intermediate attributes.", changes to G-stage translations affect VS-stage PTE accesses but do NOT affect VS-stage translations.  So there would be no need for an HFENCE.VVMA.

Because the intermediate attributes (from the G-stage translation the memory access made in support of VS-stage address translation is subject to) apply to VS-stage page-table accesses, when menvcfg.PBMTE is changed, an HFENCE.GVMA, obeying current SPEC, doesn't suffice to synchronize with respect to the altered interpretation of G-stage PTE's PBMT field(above-mentioned intermediate attributes), since HFENCE.GVMA need not flush the cache entries that cached guest virtual addresses to guest physical addresses(the VS-stage address translation).
Thus, to reflect the influences of menvcfg.PBMTE on the intermediate attributes, I think an extra HFENCE.VVMA, in addition to HFENCE.GVMA, is needed actually.

As already stated, the intermediate attributes affect how PTE accesses are performed, but they do not affect VS-stage translations themselves (and the values returned by PTE accesses from the addressed memory locations).

OK. Thanks for your great insights while we did care that intermediate attributes affect how PTE accesses are performed in our platform. We will note this.


Update input in examples for windows

Hi I saw the user_input example was already updated to work on windows but I just did the rest of them that use input other than quit.
Also added a hack in panic.rs because on windows/powershell a release event is sent from when you originally press enter to cargo run. No more double presses now either.
Fix https://github.com/tui-rs-revival/ratatui/issues/120
Edit: I just looked at the conventional commit thing and it's just a fix, you can merge this now

Closing this because it's being reverted https://github.com/crossterm-rs/crossterm/pull/778

Any reason for the reopen ?

This can actually be merged, https://github.com/crossterm-rs/crossterm/pull/778#issuecomment-1500910673.
It's not 100% needed if crossterm puts release events behind a feature, but this will stop it from breaking whenever the feature is enabled on both windows and using kitty keyboard protocol on other platforms.
At this moment all the modified examples aren't compatible with release events, and without this PR they don't work as intended because of "double" events.