Missing modules while opening UE 4.27.2 project

Hello,
After deleteing the OpenXR plugin (official plugin from UE Market place) from UE 4.27.2, I created a "Plugin" folder in my project directory and copied the "Plugins" folder from MsftOpenXRGame/Plugins/MicrosoftOpenXR to my project "Plugin" directory. However, after opening the project, I get the following error message:

If I try to rebuild the modules I get the following error:

Am I doing something wrong here? Is there a solution for my problem?
Thank you for your help.
P. S. TestUnit is the name of my project and I currently am using Visual Studio 2019 along with UE 4.27.2

Can you tell me the full path to your MicrosoftOpenXR directory?
It should be %YourGameName%/Plugins/MicrosoftOpenXR
But it sounds like it might be %YourGameName%/Plugin/Plugins/MicrosoftOpenXR

I encountered the same problem when I opened the MsftOpenXRGame project after uninstalling the official MicrosoftOpenXR plug-in following the tutorial

I encountered the same problem when I opened the MsftOpenXRGame project after uninstalling the official MicrosoftOpenXR plug-in following the tutorial

same there

Can you right-click on the uproject and select "Switch Unreal Engine Version"
This will retarget the project to your Unreal version

Can you right-click on the uproject and select "Switch Unreal Engine Version"
This will retarget the project to your Unreal version

When I right click I don't find this option.


Radio button group issue

I'm currently experiencing a weird issue around filters and radio buttons.
In my table I have a column that is displaying a radio button group.
Here is the code:

    User
    First Name
    Last Name

    {#each $rows as row}

	    {row.firstName}
	    {row.lastName}

              {#each [0, 1, 2] as permission}

		    <input
			    class="radio"
			    type="radio"
			    bind:group={row.applicationPermission}
			    name={`userpermissions-${row.id}`}
			    on:change={() => updatePermissions(row.id, permission)}
			    value={permission}
		    />
		    {#if permission == 0}

Not shared

		    {:else if permission == 1}

View

		    {:else}

View & Edit

		    {/if}

              {/each}

    {/each}

On table load everything is fine. The radio button groups are checked correctly according to the value of row.applicationPermission
However when applying a filter, some of the rows have their radio button group become unchecked.
I've placed logging statements everywhere and the values are correct so the radio should be checked accordingly but they aren't.
The strange thing is that only a few lose being checked, most rows are fine.
Its also not with one specific value, it can happen with different applicationPermission values.
Example images:
No filter

Filter applied

The issue does however go away if you order one of the columns in the table.
For example if you click the First Name column and reorder it, all the radio buttons get the correct checked value back.

Thank you

I just thought about it, have you tried using keyed each block for radio buttons?

https://learn.svelte.dev/tutorial/keyed-each-blocks

Permission in this instance is just a number, either 0, 1 or 2.

I have tried the following, but the issue still remains

It seems the problem comes from svelte rendering the DOM. Idk the reason why exactly.
Instead of an each block, dupplicating HTML works:

        <input type="radio" checked={row.permission === 0}
            on:change={() => console.log(`changed to ${0}`)}
        />

Not shared

        <input type="radio" checked={row.permission === 1}
            on:change={() => console.log(`changed to ${1}`)}
        />

View

        <input type="radio" checked={row.permission === 2}
            on:change={() => console.log(`changed to ${2}`)}
        />

View & Edit

https://vincjo.fr/datatables/test/radio-group


[FLINK-30668][table-api] Introduce ExplainFormat to Explainable and TableEnvironment

What is the purpose of the change
This PR is the first subtask of FLIP-280 to introduce enum ExplainFormat to Public API  Explainable and TableEnvironment.
Brief change log
11b6f0af

Introduce an enum ExplainFormat to categorize the output format of EXPLAIN statement.
Add a new methodexplain(ExplainFormat format, ExplainDetail... extraDetails) to Explainable.
Add a new methodexplainSql(String statement, ExplainFormat format, ExplainDetail... extraDetails) to TableEnvironment.

Verifying this change
This change is already covered by existing tests.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no/ don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduces a new feature? (yes / no)
If yes, how is the feature documented? FLINK-30673

@flinkbot run azure


There is a successful activity log when uploading more than one file that have been deleted in the source location

Storage Explorer Version: 1.23.0-dev
Build Number: 20211220.7
Branch: main
Platform/OS: Windows 10/Linux Ubuntu 20.04/MacOS Big Sur 11.6.1
Architecture: ia32/x64
How Found: AD hoc testing
Regression From:  Not a regression
Steps to Reproduce

Expand one storage account -> Blob Containers.
Create a blob container -> Click 'Upload -> Upload Files...'.
Select two files from a native location.
Go to the native location -> Delete the two files.
Go to Storage Explorer -> Click 'Upload' on the 'Upload Files' dialog.
Check whether there is a failed activity log.

Expected Experience
There is a failed activity log.
Here is the screenshot when trying to upload one file which has been deleted in the source location:

Actual Experience
There is a successfully activity log indicating 0 items transferred.

Additional Context
This issue also reproduces for file shares/ADLS Gen2 blobs.

Won't fix for now. AzCopy does not consider this to be a failure scenario.


Enable SetFieldConfig for nested Resource Fields

Issue #, if available: #1146
Description of changes:

Adds currentPath parameter to setResource funcs so SetConfig for nested fields can be accessed
Updates SetResourceForStruct to consider/consume SetConfig when target and source shape members do not align

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/approve

closing in favor of https://github.com/aws-controllers-k8s/code-generator/pull/292


API before/afterExtend now support parameters passed by reference

Closes #4810

3.3 is in beta, so this has to go into 3.4

PHP 5.6:
function foo(&...$args) {
    $args[0] = 'bar';
}

That's cool @dhensby :D


Preserve whitespace in debug hover expresion value

Fixes #73241

This is a great PR, thanks a lot for it!
However I would only do the change for the debug hover, not for the variables view.
In the variables view we have limited space so we on purpose do not preserve whitespace but instead squash it.
However for hover we should preserve it.
Can you please update your changes to only change the debugHover and I will merge them?
Thanks!

Looks good, thanks a lot. Let's merge.


Remote reader do not support regex filtering in label

What did you do?
I run query like this
node_cpu_load{host_name=~".*"}
What did you expect to see?
metrics that stored on influxdb and prometheus local storage
What did you see instead? Under which circumstances?
Only metrics that stored locally inside Prometheus DB under its own retention policy
Environment
I run Prometheus with configured remote read and wright to influxdb 1.4

System information:

Ubuntu 16.04.03
Linux 4.4.0-93-generic x86_64

Prometheus version:

prometheus, version 1.8.0 (branch: HEAD, revision: 3569eef8b1bc062bb5df43181b938277818f365b)
build user:       root@bd4857492255
build date:       20171006-22:12:46
go version:       go1.9.1

Prometheus configuration file:

# my global config
global:
  scrape_interval:     60s # By default, scrape targets every 15 seconds.
  evaluation_interval: 30s # By default, scrape targets every 15 seconds.
  scrape_timeout: 10s
  # scrape_timeout is set to the global default (10s).

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).

# Load and evaluate rules in this file every 'evaluation_interval' seconds.

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:

  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  # Auto-discovery via consul tags by Registrator
  - job_name: 'federate_lr_metrics_node'
    scrape_interval: 30s

    honor_labels: true
    metrics_path: '/federate'

    params:
      'match[]':
         - '{__name__="node_load1"}'

    static_configs:
      - targets:
        - 'some_server:9090'

# Remote write configuration (for Graphite, OpenTSDB, or InfluxDB).
remote_write:
  - url: "http://localhost:8086/api/v1/prom/write?db=lr_prom"
# Remote read configuration (for InfluxDB only at the moment).
remote_read:
  - url: "http://localhost:8086/api/v1/prom/read?db=lr_prom"

@dmitriy-lukyanchikov Thanks for the report. You are saying you are using InfluxDB 1.4, but I don't think that version exists yet? (at least at https://github.com/influxdata/influxdb/releases, it only goes up to 1.3.7).
Are you using a version of InfluxDB that already has a built-in Prometheus remote read/write endpoint, or using an adapter?

@juliusv Hello! Its version that not released yet but you can build a dcoker image using this repository https://github.com/influxdata/influxdata-docker/tree/master/influxdb/nightly or use oficial site and download version named nightly, also in the link that you provide there is already 1.4 version https://github.com/influxdata/influxdb/releases/tag/v1.4.0
This version of InfluxDB already has built-in Prometheus remote read/write endpoint

@dmitriy-lukyanchikov interesting, https://github.com/influxdata/influxdb/releases/tag/v1.4.0 just gives me a 404, and that tag also does not show for me in the list.
But I guess just checking with nightly would be sufficient.

hm strange indeed the error, ok try to use docker it works perfect for me, it builds in a minute without any problem

Can it be reproduced with released InfluxDB 1.4.x?

Looks like this was resolved, and it would be an issue in InfluxDB rather than Prometheus anyway.


[Protocol] Support secrets in protocol

Support secrets in protocol
Users may need sensitive information including password or API key in their jobs, secrets section is used to help user hide those sensitive information in plain text and avoid sharing.
Work items

[x] Agree on an approach to add secrets in protocol.
[x] Update the protocol implementation to support read secret from yaml and mask with * when storing.
[x] Hide the secrets in webportal, including submission, config view, and job clone.

default:

should be "defaults"?

Refers to: docs/pai-job-protocol.yaml:235 in 9e65442. [](commit_id = 9e654422c09dff193594b7f9eb313d46227799f7, deletion_comment = False)

default:

should be "defaults"?

right, fixed

Coverage increased (+0.3%) to 53.345% when pulling fa444a666f687960cc854f72d88cd095c861324b on xiongyf/protocol-secrets into 0eb286f029d78865c24feb6aabcc990c44336c11 on master.

Coverage increased (+0.3%) to 53.345% when pulling fa444a666f687960cc854f72d88cd095c861324b on xiongyf/protocol-secrets into 0eb286f029d78865c24feb6aabcc990c44336c11 on master.


mujoco: 3.2.2 -> 3.2.3

Description of changes
Changelog: https://github.com/google-deepmind/mujoco/releases/tag/3.2.3

mujoco: 3.2.2 -> 3.2.3
python312Packages.mujoco: 3.2.2 -> 3.2.3
mujoco: move to pkgs/by-name
mujoco: format with nixpkgs

cc @samuela

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 342456 run on x86_64-linux 1

2 packages marked as broken and skipped:

python312Packages.shimmy
python312Packages.shimmy.dist

15 packages built:

mujoco
python311Packages.dm-control
python311Packages.dm-control.dist
python311Packages.mujoco
python311Packages.mujoco.dist
python311Packages.shimmy
python311Packages.shimmy.dist
python311Packages.torchrl
python311Packages.torchrl.dist
python312Packages.dm-control
python312Packages.dm-control.dist
python312Packages.mujoco
python312Packages.mujoco.dist
python312Packages.torchrl
python312Packages.torchrl.dist

Result of nixpkgs-review pr 342456 run on x86_64-darwin 1

17 packages marked as broken and skipped:

mujoco
python311Packages.dm-control
python311Packages.dm-control.dist
python311Packages.mujoco
python311Packages.mujoco.dist
python311Packages.shimmy
python311Packages.shimmy.dist
python311Packages.torchrl
python311Packages.torchrl.dist
python312Packages.dm-control
python312Packages.dm-control.dist
python312Packages.mujoco
python312Packages.mujoco.dist
python312Packages.shimmy
python312Packages.shimmy.dist
python312Packages.torchrl
python312Packages.torchrl.dist

Result of nixpkgs-review pr 342456 run on aarch64-darwin 1

17 packages marked as broken and skipped:

mujoco
python311Packages.dm-control
python311Packages.dm-control.dist
python311Packages.mujoco
python311Packages.mujoco.dist
python311Packages.shimmy
python311Packages.shimmy.dist
python311Packages.torchrl
python311Packages.torchrl.dist
python312Packages.dm-control
python312Packages.dm-control.dist
python312Packages.mujoco
python312Packages.mujoco.dist
python312Packages.shimmy
python312Packages.shimmy.dist
python312Packages.torchrl
python312Packages.torchrl.dist

Result of nixpkgs-review pr 342456 run on aarch64-linux 1

2 packages marked as broken and skipped:

python312Packages.shimmy
python312Packages.shimmy.dist

14 packages built:

python311Packages.dm-control
python311Packages.dm-control.dist
python311Packages.mujoco
python311Packages.mujoco.dist
python311Packages.shimmy
python311Packages.shimmy.dist
python311Packages.torchrl
python311Packages.torchrl.dist
python312Packages.dm-control
python312Packages.dm-control.dist
python312Packages.mujoco
python312Packages.mujoco.dist
python312Packages.torchrl
python312Packages.torchrl.dist


feat: allow customizing setting tokens through the interceptor

Allow other ways of setting tokens. In our application, the token is sent in the form { 'x-auth-token': token }, not the default bearer token.
This might catch a few users by surprise, as so far it's been in the docs to implement (rather than extend) the AuthService. I'd recommend creating bumping a minor version, not releasing this as a patch.

Hi @duizendnegen, thanks for the PR, that's definitely good addition to the library. But what if we'll adjust it a little bit and will add small snippet to the auth service itself, which will provide default header by default ? E.g.
export abstract class AuthService {
  // ...

  public abstract addToken(req: HttpRequest<any>): Observable<HttpRequest<any>>;

  // ...
}

@Injectable()
export class AuthInterceptor implements HttpInterceptor {
  // ...

  private addToken(req: HttpRequest<any>): Observable<HttpRequest<any>> {
    const authService: AuthService =
      this.injector.get<AuthService>(AUTH_SERVICE);

    if (typeof authService.addToken === 'function') {
      return authService.addToken(req);
    }

    return first(map(
      authService.getAccessToken(),
      (token: string) => {
        if (token) {
          return req.clone({
            setHeaders: { Authorization: `Bearer ${token}` }
          });
        }

        return req;
      }
    ));
  }

  // ...
}

In this case no-one would need to adjust anything in the current setup. Less breaking changes :)

Excellent suggestion - I agree. Implemented that now, however, nested inside the first(map( ... )), that brings down the responsibilities of the AuthenticationService itself. Added docs to the README for how to use.
Let me know if I should squash this still.

Nice, but could you fix extends back to implements, plus adjust the things accordingly ?

Yep, done.
I thought to keep those there anyway as extending would be more flexible than implementing for future additions, but any future addition would be breaking as per semver anyway, so :+1:

Done, let me know if there's anything else.

Ok, nice, merged. But I forgot to ask you to bump the version, but that's not a problem, going to do that tonight. Hold on 👍


Add cap_drop and userns_mode fields to Service

Closes #32, adds cap_drop and userns_mode fields to Service. Also bumped the major version as this is a breaking change (see https://doc.rust-lang.org/cargo/reference/semver.html#struct-add-public-field-when-no-private).

Thanks!


overflow-y issue with bootstrap

I am using sidebar with bootstrap and I came across weird issue: using sidebar even with no content inside or children makes a 15px gap to the right:

It helpes when I override overflow-y:
overflow-y: auto !important; on contentClassName.

I just updated from v2.3.0 to v2.3.2 and I now have this issue. Previously the div had overflow: auto but now it has overflow-y: scroll and there is an extra gap between the sidebar and the content whether the sidebar is open or closed.
This commit is where the problem is introduced. https://github.com/balloob/react-sidebar/commit/8f2e24092ba70625af6901cf14074869e3daef63
In my case, my main content should never be scrollable (there is a div within the main content that is scrollable instead).
I have worked around it like this:
    return (
      <ReactSidebar
        ...
        styles={{
          content: {
            // prevents unwanted padding to the right from default 'scroll'
            overflowY: 'auto'
          }
        }}
        ...>
        {this.props.children}
      </ReactSidebar>
    )


[question] Routing all traffic through one peer

I've spent a good few hours trying to figure out how I can configure Drago to route one peer's traffic through another to reach the internet, yet I haven't managed to figure it out thus far. Could anyone point me in the right direction?

Think what you're looking for is the allowed IPs? You should be able to set it on the connection between the peers, just like normal Wireguard configuration, if you set it to <IP_ADDRESS>/0 then it should route all traffic on that Peer through the other

That's what I thought too but I ran into issues with the RPC connection (or, at least, that's what I think it was). Basically, assuming the public IP of the peer I'm trying to route traffic through is <IP_ADDRESS>, and it's also the Drago server, the Drago client will try to connect to rpc://<IP_ADDRESS>:8081, but because of AllowedIPs=<IP_ADDRESS>/0, it will try to route that request through the tunnel, meaning that it will arrive on the drago-... interface on that peer. I don't think this request is then routed internally to the correct interface, just dropped, so as soon as one sets AllowedIPs to <IP_ADDRESS>/0 any further RPC connections fail.
I figured out a workaround: first, Allowed IPs should point to the majority of the internet except for the IP of the peer you're connecting to (and possibly local IPs), since this appears to cause issues with Drago's RPC connection (that's what tripped me up). This is difficult to do with WireGuard, but fortunately, sites like this one allow for calculating the correct Allowed IPs easily. Once those are set, the following iptables rules must be added:
Pre Up
iptables -A FORWARD -i <DRAGO_INTERFACE_NAME> -j ACCEPT; iptables -A FORWARD -o <DRAGO_INTERFACE_NAME> -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Pre Down
iptables -D FORWARD -i <DRAGO_INTERFACE_NAME> -j ACCEPT; iptables -D FORWARD -o <DRAGO_INTERFACE_NAME> -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Remembering to replace <DRAGO_INTERFACE_NAME> with the actual interface name.
So, in the end, you have a split tunnel where packets to <IP_ADDRESS> are sent outside of the tunnel allowing for RPC to work correctly. In the long run though, I think Drago would need to be able to figure this out and connect to the private IP of the peer through the tunnel for RPC.

I agree, it would be great to have exit node capability baked into Drago itself.


VSCode extension adds new fields to a model when saving file

I have the following model:
model Video {
  ytId       String  @id
  snippet    Json
  topicId    Int
  voteScore  Int?    @default(0)
  uploader   User    @relation("UserVideos", fields: [uploaderId], references: [uid])
  uploaderId String
  languageId Int
}

model User {
  uid       String  @id
  videos    Video[] @relation("UserVideos")
  bookmarks Video[]
}

When I save the file, VSCode extension adds the following fields to the Video model:
  User       User?   @relation(fields: [userUid], references: [uid])
  userUid    String?

Why does this happen? Am I doing something wrong or is this a bug?

When I added the following fields myself:
model Video {
  ...
  bookmarkers User[]     @relation("UserBookmarks")
}
model User {
  ...
  bookmarks Video[] @relation("UserBookmarks")
}

this doesn't happen anymore.
Seems that prisma is missing these fields for correct reference, so the extension is configured to add it automatically.
It would be nice to have some sort of notification about why this is necessary when this happens.

The only concern left is if the automatically added fields are correct. I don't think so. It adds User and userUid fields to the Video model that are singular while a video can be bookmarked by multiple users. So it seems it should be fixed anyway.

I just tested this:
model Test {
  id        String   @default(cuid()) @id
}

model Tester {
  id        String   @default(cuid()) @id
}

When adding tests  Tester[] to the Test model, vscode automatically adds:
  Test     Test? @relation(fields: [testId], references: [id])
  testId  String?

When trying to create a relation on TESTER first, vscode doesn't add the correlating code to model Test.
The auto-generated code seems correct to me, this is making your life easier. Are you saying the fields are incorrect?

If I understand everything correctly, in the code which is automatically added:
User       User?   @relation(fields: [userUid], references: [uid])
userUid    String?

User and userUid are single values, where a video can have only one user (bookmarker) while it should be many to many relation:
Video {
  bookmakers: User[]

and
User {
  bookmarks: Video[]
}

And in your example it's also single Test, not Test[].


add Unicode code page flag for resource compiler

On CJK Windows, it does not accept UTF-8 or other non-ascii characters. Because MSVC assumes that sources are in traditional DBCS(Doublei-byte Character Set) such as CP932 for Japanese and CP936 for Chinese, etc.
Here is a place and problem explanation where curl have non ASCII characters in CP1252.
curl/curl#1217
Same issue also exist in src/main/windows/version.rc#L28
MSVC detect source encoding and character set from source. A source with BOM code recognized
to Unicode encoded with UTF-8. Without BOM, MSVC assumes local code page character set and enccding, that is defined above Windows configuration, except for English Windows default is UTF-8 and Unicode. It is a character set  problem rather than encoding.
Will fix #3128

Thanks for the PR!
Instead of adding code to each port, this looks like something we should always do. I've therefore added it to our master toolchain file for Windows in 58be848. Let me know if that fixes the issue!


Stale issue check

Description
Stale bot
Issue Type
No response
Operating System
No response
Coral Device
No response
Other Devices
No response
Programming Language
No response
Relevant Log Output
No response

Please dont close issue for 7 days to test stale

@rthadur There was no stale label and update from the bot on this issue even after 7 days ?


Fix the undeterministic storage proof recorded for the same execution

The storage proof generated for the same execution should be always the same, while HashMap was used to store the records which lead to the proofs generated for the same execution are in fact not deterministic. More background can be found in https://github.com/paritytech/substrate/discussions/10783#discussioncomment-2242000

IMO I would remove PartialEq implementation from the StorageProof. This also returns to the outside "Hey these kind of things can not be compared".

@bkchr This makes some sense, but I'm not clear about how we handle the usages in the following cases, simply compare the inner trie nodes? That's the actual PartialEq impl.
https://github.com/paritytech/substrate/blob/3254cdabd12a1114f800a624e673ba251ff8b4d1/client/network/src/protocol/message.rs#L126-L131
https://github.com/paritytech/substrate/blob/3254cdabd12a1114f800a624e673ba251ff8b4d1/client/network/src/protocol/message.rs#L135-L140
https://github.com/paritytech/substrate/blob/3254cdabd12a1114f800a624e673ba251ff8b4d1/client/network/src/protocol/message.rs#L535
Also, I ran cargo +nightly fmt --all from the project root, causing some unrelated format changes. I can revert them if necessary.

Alternative approach could also be to change StorageProof to store the data in a BTreeSet.

@bkchr Updated, please have another look.

@arkpar @cheme Any clue why this test failed with the root mismatch error?
https://github.com/paritytech/substrate/blob/4d1b6fa12bae09be890b27df33c94e23845ba5ce/client/network/test/src/sync.rs#L1183
https://github.com/paritytech/substrate/blob/4d1b6fa12bae09be890b27df33c94e23845ba5ce/primitives/trie/src/trie_codec.rs#L117-L122

It's pretty easy to find a workaround for the tests once PartialEq is removed. What I'm confused about is how to handle the messages that contain a StorageProof field (see the comment above https://github.com/paritytech/substrate/pull/10915#issuecomment-1049807188), these messages require PartialEq, adding some compare method won't help it.
https://github.com/paritytech/substrate/blob/c6acf0f7a6284ba588e3221f6fae265d63710f53/client/network/src/protocol/message.rs#L268-L269
So if I understand correctly, the conclusion is that we keep the original HashMap and instead sort the trie nodes in to_storage_proof to make the final proof for an execution deterministic, which sounds good to me as well.
Then the last thing is how to deal with PartialEq, there are no good solutions for the problems missing PartialEq, it's okay to leave it as is since IMO it's also reasonable to think it in this way: there can be multiple proofs for the same execution because the order can be different even they have the same set of trie nodes, they are equivalent regarding the point that they all can be used to verify an execution(we could add a method is_same_execution_proof for this purpose), but they are not equivalent in terms of the order(this Eq is not pretty useful though).

I always thought that this is as the trie "independent" of the order of the proof

Actually the proof got a deterministic order of node, isn't it better?

Changing the internals of StorageProof may breaks other stuff like CompactProof

Not sure I understand here, there is no issue in sorting nodes of StorageProof.

Changing the internals of StorageProof may breaks other stuff like CompactProof

Not sure I understand here, there is no issue in sorting nodes of StorageProof (using BTreeSet internally for instance). The order is already random.

I think I was confused :see_no_evil: We should just ensure that we never change the format of CompactStorageProof

What I'm confused about is how to handle the messages that contain a StorageProof field (see the comment above #10915 (comment)), these messages require PartialEq, adding some compare method won't help it.

I removed PartialEq for Message and the code still compiled for me.

What I'm confused about is how to handle the messages that contain a StorageProof field (see the comment above https://github.com/paritytech/substrate/pull/10915#issuecomment-1049807188), these messages require PartialEq, adding some compare method won't help it.

I removed PartialEq for Message and the code still compiled for me.

@bkchr Thanks for confirming this! I thought it was necessary before. PR updated as requested.

@bkchr cumulus check is green, could you please take another look? This feature is crucial for our development.

@liuchengxu , IIUC last @bkchr comments, the only remaining thing would be to restore the partialEq and Eq derive in this PR. (I am also a bit lost in the conversation, but otherwhise LGTM)

Thanks for the clarification @cheme. Once @bkchr confirms, I'll close the cumulus companion.

@bkchr Only the labels check is red now :D

bot merge


Distance Calculation

Hi. According to the tutorial. I found that target information is used while building the binary and generating the distance.
It seems that we have to build the binary once again with the generated distance. Actually, I want to know when the target information is used during the whole work flow.
In other words, if I changed my targets. What information could be used and what are need to be generated once again? Is the distance information related to the targets or it is the information for the whole binary and could be reused no matter how we change the targets. Many Thanks

The target information is used in the first step to determine the corresponding target basic blocks and target functions in the LLVM-IR. The dot-files are generated. The distance values are computed. A second LLVM-pass instruments the program. Of course, with some more work this could all be done in a single LLVM-pass. Volunteers welcome :)


RFC: Custom DSTs

This has been a long time coming - similar to #2580, but more general.
On the unresolved question about ?Sized -> DynamicallySized, and the need for ?DynamicallySized. I think this is actually a reasonable change which makes extern types act much nicer around generic functions that already exist, and fixes all the Rust code that has been written already. No longer is, for example, Box<extern-type> allowed. I've chosen to make this change.
Note that DynamicallySized is a new language trait, on the level of Sized and Copy.
Rendered

It's likely that this RFC should be merged with some amount of #2580, specifically the stuff for mentioning VTables.

https://github.com/rust-lang/rfcs/issues/2255 also seems like a relevant link, since I'm not entirely sure whether those issues are settled. I think the current status of that discussion is:

introducing any new ?Trait bounds like ?Move or ?DynamicallySized, such that Trait is a new implicit bound on all existing generics, is backwards incompatible and therefore can never be done (not even with editions)
the only loophole would be traits that are "not really new" because they're already implied by Sized, such as DynamicallySized
the contention that ?Move was a brute force solution seems to have proven accurate now that we've discovered the alternative of Pin, so DynamicallySized appears to be the only plausible new implicit trait bound
the only alternative to DynamicallySized that we've been able to find is panicking at runtime

This seems like a crucial (albeit not obviously crucial) piece of the argument in favor of this RFC, though I've never seen it spelled out like this before, so it seems worth asking whether I got all of that right.

My only actual concern with the RFC is the same one that niko articulated last time: this doesn't appear to be a hard blocker or a game changer for anything, so do we really want to prioritize work on it in the near future? But we can always accept the RFC and not implement it for a while; this is clearly the best proposal so far and the design space seems pretty thoroughly explored at this point.
To double-check: The CStr and FAM use cases are not "hard blockers" because you can do all that stuff with unsafe shenanigans today, right? i.e. there isn't any C code that's impossible to soundly integrate with Rust because of this, and this is "just" (emphasis on the scare quotes) a really huge ergonomics win for those use cases?

Rendered: https://github.com/ubsan/rust-rfcs/blob/custom-dst/text/0000-custom-dst.md

@glaebhoerl I would argue that an extern type solution would make using FAMs far more annoying. Also, I think this is the most ergonomic way of doing this, even if it's slightly odd. Sized, Move, and DynamicallySized are odd traits.
Places the language calls size_of_val/align_of_val - afaik, just in the intrinsics (which could probably be removed). Otherwise, only in the library, when dealing with allocators.

@Ixrec technically you're right, but it's such an incredible ergonomics win, and it's been suggested so many times. It also is an incredible ergonomics win for Matrix libraries, imo, since they'll suddenly be able to use the Deref/Index traits.

Yeah, I'm totally on board with actually doing this. Just wanted to be sure I understood it all correctly.

I'd also argue it should be a blocker for extern type, since as it currently stands, they're fairly broken.

Interestingly, the extern types RFC states "before this is stabilized there should be some trait bound or similar on them that prevents [size_of_val's and align_of_val's] use statically", but does not list this as an unresolved question. Fortunately, the tracking issue comments also seem to imply that nobody wants to stabilize it before we figure this out.

@Ixrec ah, good, I literally started writing this because someone was suggesting we panic on size_of_val.

Since we have a reasonable type system solution in this RFC, I don't think panicking is a reasonable choice.

Something like this RFC would be really nice for the ndarray crate. It would greatly simplify handling of array views (ArrayView/ArrayViewMut) and would make it possible to do things like return n-D array views from Index and use the standard library's Cow with arrays.
However, ndarray supports arrays with a dynamic number of dimensions (axes), so we would need the Metadata (the shape and strides of a view) to support being dynamically sized (or sized with heap-allocated data). Would it be possible to extend this RFC to handle this use-case?  Maybe we could change the Copy bound on Metadata to Clone, and then provide a special implementation of Copy for &T that actually clones the metadata?

@jturner314 That's unworkable because it would break existing code generic over references and pointers. I think what you'd want to be able to use this feature is const generics and actually parametrize those types by the number of dimensions, e.g. ArrayView<A, 4>.

I think what you'd want to be able to use this feature is const generics and actually parametrize those types by the number of dimensions, e.g. ArrayView<A, 4>.

ndarray supports arrays with the number of dimensions (axes) known at compile time (e.g. arrays with "const dimensionality" Ix3) and arrays with the number of dimensions known only at runtime (arrays with "dynamic dimensionality" IxDyn). For const-dimensionality arrays, the shape and strides are represented as [T; NDIM], while for dynamic-dimensionality arrays, the shape and strides are represented Vec<T>1. The "known only at runtime"/"dynamic dimensionality" case is what I'm asking about, since const generic [T; N] doesn't work for this case.
1We actually use a small-vector optimization for four axes or less, but that's irrelevant for this discussion.

That's unworkable because it would break existing code generic over references and pointers.

Yeah, that's what I was afraid of. Another possible approach that would enable this use-case is providing an owned equivalent of &[T] that could be placed on the stack, used in Metadata, etc. (This would be similar to C99's variable length arrays.) That feature is probably outside the scope of this RFC, though.
Out of curiosity, what's a case where the "use Clone bound on Metadata, and implement Copy for &T/*const T/etc. in terms of cloning the metadata" proposal would break things?

Out of curiosity, what's a case where the "use Clone bound on Metadata, and implement Copy for &T/*const T/etc. in terms of cloning the metadata" proposal would break things?

I guess the simplest case would be any code relying on the fact that copying a Copy type cannot panic.

I guess the simplest case would be any code relying on the fact that copying a Copy type cannot panic.

Good point. We could treats panics as aborts in this case, though. (We already do this kind of thing for panic inside drop when unwinding from another panic.)
I thought of another potentially breaking case – code could rely on the original and copy from Copy being equal, but .clone() doesn't necessarily guarantee that. We could say that ensuring clones of Metadata are equal is a safety requirement for implementing DynamicallySized, but if code relies on the copies being bitwise identical, that wouldn't work.
Another potentially breaking case is dealing with uninitialized memory. If the type of the uninitialized memory is Copy, it's usually considered safe to assign to it normally (without using ptr::write) because Copy requires that the type not implement Drop. With only a Clone bound that's not the case. Unlike the other issues, I don't see a backwards compatible workaround for this that would enable using Vec in Metadata. [Is normal assignment in the Copy case really safe, though? In order to perform the assignment without ptr::write, you have to create an &mut T. Is creating an &mut T always defined behavior for uninitialized T where T: Copy?]
Yeah, I'm coming to the conclusion that a Clone bound instead of Copy bound on Metadata is unworkable without breaking changes.

@jturner314 Rust is designed with "moves and copies are literally bitwise copies always" as a core promise, as contrasted with C++. Unsafe code is free to rely on this as much as it wants to.
So yeah, it's a serious breaking change, and one that I don't see happening.
If it's opt-in, maybe it could happen. But I also feel like the dynamic number of dimensions is less common (or will become less common with const generics).

@jturner yeah, I'd love if you fixed it - the size_of_val, in that case, would be either stride * height or width * height, since it's the minimum size that the slice can have. size_of_val is more useful for types which are contiguous... perhaps size_of_val should return just 0, since the type isn't contiguous, and therefore you're not actually allowed to read size_of_val bytes from the pointer?

Okay, here's the example with some fixes and additional functionality:
use std::ops::{Index, Range};

/// Owned, column-major, contiguous array.
struct PlaneBuf<T> {
    /// Number of columns. (Equivalently, length of each row.)
    width: usize,
    /// Array contents.
    buffer: Box<[T]>,
}

impl<T> Deref for PlaneBuf<T> {
    type Target = Plane<T>;

    fn deref(&self) -> &Plane<T> {
        let ptr = &*self.buffer;
        let height = self.buffer.len() / self.width;
        let meta = PlaneMetadata {
            height,
            width: self.width,
            stride: height,
        };
        unsafe { &*std::raw::from_raw_parts::<Plane<T>>(ptr, meta) }
    }
}

/// View of a portion of a `PlaneBuf`. (Not necessarily contiguous.)
struct Plane<T> {
    buffer: [T; 0],
}

#[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
struct PlaneMetadata {
    /// Number of rows. (Equivalently, length of each column.)
    height: usize,
    /// Number of columns. (Equivalently, length of each row.)
    width: usize,
    /// Stride to move between columns while staying on the same row.
    /// (The stride to move between rows while staying on the same column is always 1.)
    stride: usize,
}

unsafe impl<T> DynamicallySized for Plane<T> {
    type Metadata = PlaneMetadata;

    fn size_of_val(&self) -> usize {
        let meta = std::raw::metadata(self);
        if meta.width == 0 {
            0
        } else {
            (meta.stride * (meta.width - 1) + meta.height) * std::mem::size_of::<T>()
        }
    }

    fn align_of_val(_: PlaneMetadata) -> usize {
        std::mem::align_of_header::<Self>()
    }
}

impl<T> Plane<T> {
    /// Returns the pointer to the start of the plane.
    pub fn ptr(&self) -> *const T {
        &self.buffer as *const [T; 0] as *const T
    }

    /// Splits the plane into two pieces along its height.
    pub fn split_height_at_mut(&mut self, mid: usize) -> (&mut Plane<T>, &mut Plane<T>) {
        let meta = std::raw::metadata(self);
        assert!(mid <= meta.height);
        let ptr1 = self.ptr();
        let meta1 = PlaneMetadata {
            height: mid,
            ..meta
        };
        let ptr2 = if self.width == 0 || mid = self.height {
            self.ptr()
        } else {
            unsafe { self.ptr().add(mid) }
        };
        let meta2 = PlaneMetadata {
            height: meta.height - mid,
            ..meta
        };
        (
            unsafe { &mut *std::raw::from_raw_parts::<Plane<T>>(ptr1, meta1) },
            unsafe { &mut *std::raw::from_raw_parts::<Plane<T>>(ptr2, meta2) },
        )
    }

    /// Splits the plane into two pieces along its width.
    pub fn split_width_at_mut(&mut self, mid: usize) -> (&mut Plane<T>, &mut Plane<T>) {
        let meta = std::raw::metadata(self);
        assert!(mid <= meta.width);
        let ptr1 = self.ptr();
        let meta1 = PlaneMetadata { width: mid, ..meta };
        let ptr2 = if self.height == 0 || mid == meta.width {
            self.ptr()
        } else {
            unsafe { self.ptr().add(mid * meta.stride) }
        };
        let meta2 = PlaneMetadata {
            height: meta.width - mid,
            ..meta
        };
        (
            unsafe { &mut *std::raw::from_raw_parts::<Plane<T>>(ptr1, meta1) },
            unsafe { &mut *std::raw::from_raw_parts::<Plane<T>>(ptr2, meta2) },
        )
    }

    /// Returns a reference to the specified column.
    pub fn column(&self, col: usize) -> &Plane<T> {
        let meta = std::raw::metadata(self);
        assert!(col < meta.width);
        let ptr = if meta.height == 0 {
            self.ptr()
        } else {
            unsafe { self.ptr().add(col * meta.stride) }
        };
        let col_meta = PlaneMetadata { width: 1, ..meta };
        unsafe { &*std::raw::from_raw_parts::<Plane<T>>(ptr, col_meta) }
    }

    /// Returns a reference to the specified row.
    pub fn row(&self, row: usize) -> &Plane<T> {
        let meta = std::raw::metadata(self);
        assert!(row < meta.height);
        let ptr = if meta.width == 0 {
            self.ptr()
        } else {
            unsafe { self.ptr().add(row) }
        };
        let row_meta = PlaneMetadata { height: 1, ..meta };
        unsafe { &*std::raw::from_raw_parts::<Plane<T>>(ptr, row_meta) }
    }
}

impl<T> Index<(usize, usize)> for Plane<T> {
    type Output = T;

    fn index(&self, (row, col): (usize, usize)) -> &T {
        let meta = std::raw::metadata(self);
        assert!(row < meta.height && col < meta.width);
        unsafe { &*self.ptr().add(col * meta.stride + row) }
    }
}

impl<T> Index<(Range<usize>, Range<usize>)> for Plane<T> {
    type Output = Plane<T>;

    fn index(&self, (rows, cols): (Range<usize>, Range<usize>)) -> &Plane<T> {
        let meta = std::raw::metadata(self);
        assert!(rows.start < meta.height && rows.end <= meta.height);
        assert!(cols.start < meta.width && cols.end <= meta.width);
        let ptr = unsafe { self.ptr().add(cols.start * meta.stride + rows.start) };
        let meta = PlaneMetadata {
            height: rows.end.saturating_sub(rows.start),
            width: cols.end.saturating_sub(cols.start),
            ..meta
        };
        unsafe { &*std::raw::from_raw_parts::<Plane<T>>(ptr, meta) }
    }
}

You might not want to include all of this, but I think at least split_height_at_mut and Index<(Range<usize>, Range<usize>)> are worth keeping. split_height_at_mut is valuable to demonstrate mutable views that are interlaced (but non-aliasing) in memory, and the Index implementation returns a reference to a 2-D plane (which is impossible in current Rust).
I think the RFC should define how size_of_val should be implemented for non-contiguous types. I've chosen to calculate the span between the start and end of the data, but another approach may make more sense. How will the result of .size_of_val() be used in practice?

Shouldn't size_of_val and align_of_val be const fns?

The "known only at runtime"/"dynamic dimensionality" case is what I'm asking about, since const generic [T; N] doesn't work for this case.

This might be a stupid question, but why wouldn't the following work?
struct ArrayView<T> {
    // The layout of the buffer is `dims` usize
    // dimensions followed by `len` Ts
    data: ([usize; 0], [T; 0]),
}

#[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
struct ArrayViewMetadata {
    dims: usize,
    len: usize,
}

unsafe impl<T> DynamicallySized for ArrayView<T> {
    type Metadata = ArrayViewMetadata;

    fn size_of_val(&self) -> usize {
        let meta = std::raw::metadata(self);
        meta.dims * std::mem::size_of::<usize>()
            + meta.len * std::mem::size_of::<T>()
    }

    fn align_of_val(_: PlaneMetadata) -> usize {
        std::mem::align_of_header::<Self>()
    }
}

impl<T> ArrayView<T> {
    pub fn ptr(&self) -> *const T {
        let meta = std::raw::metadata(self);
        // ptr to the first dimension:
        let ptr = &self.data as *const [usize; 0] as *const usize;
        // ptr to one past the last dimension:
        let ptr = ptr.add(meta.dims) as *const u8;
        // ptr to the first T after the last dimension
        ptr.add(ptr.align_offset(std::mem::align_of::<T>())
    }
    pub fn get(&self, indices: &[usize]) -> &T {
        let meta = std::raw::metadata(self);
        assert_eq!(indices.len(), meta.dims);
        let offset = /* compute 1D offset from indices and dims */;
        &*self.ptr().add(offset)
    }
}

@gnzlbg This array view does not support slicing, i.e. there cannot be an allocation-free pub fn slice(&self, ranges: &[Range<usize>]) -> &ArrayView<T>.

@gnzlbg Let me clarify, suppose there are m dimensions and N elements (the length), if place the dimensions separately from the elements, then for slicing we only need to allocate for those m dimensions and borrow the existing N elements.
However, if these are placed together next to each other, we'll need to allocate for all m + N items.

If place the dimensions separately from the elements, then for slicing we only need to allocate for those m dimensions and borrow the existing N elements.

I think I see what you mean. What I showed is that one can, in some cases (e.g. if the dimensions don't change), do this without allocating at all as long as the dimensions and values are layed out appropriately.
If one wants to create a view with a different number and values of dimensions over an already existing slice of elements, then one has to allocate those dimensions somewhere. I do not see any major problems with the Metadata owning those dimensions by containing a Box<[usize]>, but I don't think the Metadata could borrow them without ATCs because:
struct ViewMetadata<'a> {
    dims: &'a [usize],
    len: usize,
}

unsafe impl<T> DynamicallySized for View<T> {
    type Metadata<'a> = ViewMetadata<'a>;
    ...
}

I think you want DynamicallySized: Sized. Otherwise the T: Sized bound doesn't imply T: DynamicallySized.
You'd then do a impl !Sized for Foo or however those opt-out traits work to implement your own DynamicallySized.

Yes sorry that is correct.

I like this proposal, in essence. A few thoughts:

DynamicallySized is too long. I'd prefer DynSized myself.
If you have a type which you would like to be unsized, you can implement this trait for your type! -- I know "unsized" has traditionally been synonymous with "dynamically sized" in Rust, but it would be clearer to write "dynamically sized" here. Also, I personally like the distinction, especially since the advent of extern type, which are truly unsized from the perspective of the Rust side of FFI (right now).
I'm a "yes" for allowing implementations of DynSized for extern types and types containing them. Sometimes there is no Rust data structure capable of representing a weird foreign type (e.g., with dynamic layout), so this is handy in such cases. It would mean that extern type can be unsized or dynamically sized, but never (statically) sized, of course. This seems reasonable to me.
More bikeshedding: header_size rather than size_of_header, etc., would appeal more to me.

One example is the standard library itself, which doesn't do this for CStr, even though it technically could (CStr is not pointer sized)....

I'm not sure "it technically could" is accurate. How could that be made to work with Rust's current feature set?

How could that be made to work with Rust's current feature set?

We'd make CStr a #[lang_item].

Hi folks,
I love this proposal, especially for parsing and access to some externally defined structs which have variable size.
Does the associated type Metadata have to point to some user defined structure?  What if the info for deriving the size of the structure is in the struct itself (for example, many structures have length headers)?   Would we create some unnecessary Metadata = SizeMetadata struct where SizeMetadata contains what is already in the original (dynamically sized) struct?

The idea would be that you split up your data from your metadata. Because your type is a DST, and you can't have !Sized values without indirection your metadata will live on the pointer, along side your value, but not inside your value.
for example you could define a slice like so
use std::mem::PhantomData;
struct Slice<T>(PhantomData<T>);

unsafe trait DynamicallySized {
    type Metadata = usize; // len

    fn size_of_val(&self) -> usize {
        std::mem::size_of::<T>() * metadata(self)
    }

    fn align_of_val(meta: Self::Metadata) -> usize {
        std::mem::align_of::<T>()
    }
}

How would a person go about actually determining how much space it takes to store a DST value. Like, a slice is a pointer an a len, so the actual size of a slice is usize * 2. Would there be a formalized way to get that number so that you could set aside space to place a DST value?

@Lokathor take a look at https://github.com/rust-lang/rfcs/pull/2580 if you havne't seen it. Hopefully that lands soon, so this Custom DST RFC can not worry about litigating those issues too. Simple divide-and-conquer of the problem space!

@Lokathor One thing to note is that, currently, we can only create DSTs via coercion (with the only exception being string literals). So you would have set aside the space already to create the underlying Sized type and now you are simply pointing to it.

@velvia I think the idea is that you'd use Metadata = () for that case, and only look at the data in the header.

@Lokathor You just reserve size_of::<*const CustomDst>() bytes?

That's the pointer only. You'd then also need the metadata after it. Which you could do with something like size_of::<*const CustomDst>() +  size_of::<<CustomDST as DynamicallySized>::Metadata>() but it should be obvious that such an expression is something long and fiddly that we should give a name to and make a method to avoid errors

@Lokathor why would it only be the pointer? std::mem::size_of<*const str>() is 16 on 64 bit systems, for example, because it includes both the pointer and the length.

That's the pointer only.

The metadata is part of the pointer, e.g., right now *const [T] is 2 words in size.

Oh! Well then ignore me.

I have an API that semantically accepts a &[&str] but that I'd like to use both with &[&str] and &[String]. Right now I always allocate memory to create a Vec<&str> from a Vec<String> and be able to use this API with both.
I wish I had a StridedSlice<&str> custom DST with (len, stride) metadata that I could use in this API instead to accept both &[String] (stride = size_of::<String>()) and &[&str] (stride = size_of::<&str>()).

What's the latest on this RFC in any case?

Some updates from the @rust-lang/lang team:

We are planning to have a design meeting on November 4th to discuss https://github.com/rust-lang/rfcs/pull/2580 and to touch on some of the extensions to it, including this RFC. Feel free to ping me if you'd like more info about the meeting.
To that end, I've been preparing a hackmd that summarizes key points from RFC 2580 and this RFC along with other related work. I'd appreciate any comments on it for inaccuracies or other mistakes.

The rendered link in the OP is broken. Here's a current one.

The rendered link in the OP is broken. Here's a current one.

The lang team discussed this as part of our "Backlog Bonanza" on 2021-03-17.
Custom DSTs are not part of the roadmap for 2021.
We have already accepted https://github.com/rust-lang/rfcs/pull/2580 (tracking issue https://github.com/rust-lang/rust/issues/81513).
We want to see that work completed and gather experience with what it offers; after that has happened, we would consider Custom DSTs as a roadmap item.
@rfcbot postpone


Event Request - Table 904 "Assemble-to-Order Link" OnBeforeUpdateQtyToAsmFromWhseShptLine

🕮 Describe the request
On table 904 "Assemble-to-Order Link", can we add a new Event Request called OnBeforeUpdateQtyToAsmFromWhseShptLine at the beginning of procedure UpdateQtyToAsmFromWhseShptLine
procedure UpdateQtyToAsmFromWhseShptLine(WhseShptLine: Record "Warehouse Shipment Line")
var
    Window: Dialog;
    IsHandled: Boolean;  // NEW
begin
    // NEW +
    IsHandled := false;
    OnBeforeUpdateQtyToAsmFromWhseShptLine(WhseShptLine, IsHandled);
    if IsHandled then
        exit;
    // NEW -

    if AsmExistsForWhseShptLine(WhseShptLine) then
        if GetAsmHeader() then begin
            Window.Open(GetWindowOpenTextWhseShpt(WhseShptLine));
            UpdateQtyToAsm(WhseShptLine."Qty. to Ship");
            Window.Close();
        end;
end;

// NEW +
[IntegrationEvent(false, false)]
local procedure OnBeforeUpdateQtyToAsmFromWhseShptLine(WhseShptLine: Record "Warehouse Shipment Line"; var IsHandled: Boolean)
begin
end;
// NEW -

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 11755.


config, Configure: move the check of removed crypto/ sub-systems

The 'config' script checked for a bunch of crypto/ sub-system
directories, and added 'no-' options if they weren't there.
We move it to 'Configure' in an effort to simplify 'config' for
further work.
Note: this is pretty much a historical thing.  In modern OpenSSL, it's
much simpler to edit the SUBDIRS statement in crypto/build.info.
However, it's been claimed the there are those who still remove some
of these sub-system sources.

Ping.  This helps following up on #11011

This pull request is ready to merge


The efforts available for team member are unalligned in the project detail page

Describe the bug
The efforts for the team members are captured and displayed in the project details page. The efforts are unalligned for the team members.
To Reproduce
Steps to reproduce the behavior:

Go to CRM
Click on Projects
Click on any project which has team member added in the project.

Expected behavior
The team member efforts should be alligned as shown in screenshot

efforts are now aligned properly done this in branch: 1920-fixing-alignment-of-effort sheet-and-status-button


[AVRO-2474][WIP] - unit analysis for Avro python schema

Make sure you have checked all steps below.
Jira

[x] My PR addresses the following Avro Jira issues and references them in the PR title.

https://issues.apache.org/jira/browse/AVRO-2474

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:
This feature requires unit testing, however the initial draft has not added tests. This PR should not be approved or merged until testing is added.

Commits

[x] My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[ ] In case of new functionality, my PR adds documentation that describes how to use it.
This feature would require additional documentation which I haven't written yet.

The following code demonstrates unit analysis with python schema:
#!/usr/bin/env python3

import avro.schema, avro.units
from avro.datafile import DataFileReader, DataFileWriter
from avro.io import DatumReader, DatumWriter

# An example of a unit definition db
# format described in JSON Schema:
# https://github.com/erikerlandson/unit-analysis-json-schema/blob/master/unit-analysis-schema.json
udb = avro.units.parse("""
[
  {"unit": "base", "name": "meter", "abbv": "m"},

  {"unit": "base", "name": "second", "abbv": "s"},

  {"unit": "derived", "name": "minute", "coef": 60, "expr": "second"},

  {"unit": "derived", "name": "hour", "coef": 60, "expr": "minute"},

  {"unit": "derived", "name": "foot", "coef": 0.3048, "expr": "meter"},

  {"unit": "derived", "name": "mile", "coef": 5280, "expr": "foot"},

  {"unit": "derived",
   "name": "liter", "abbv": "L",
   "coef": {"coef": "rational", "num": 1, "den": 1000},
   "expr": {"lhs": "meter", "op": "^", "rhs": 3}
  },

  {"unit": "derived",
   "name": "gravity", "abbv": "g",
   "coef": 9.8,
   "expr": {"lhs": "meter", "op": "/", "rhs": {"lhs": "second", "op": "^", "rhs": 2}}
  },

  {"unit": "derived", "name": "kilo", "coef": 1000, "expr": "unitless"}
]
""")

# An Avro schema with additional "unit" expressions.
# unit expression format is same as in unit db above
writeschema = avro.schema.parse("""
{
     "type": "record",
     "name": "demo_units",
     "fields": [
       { "name": "distance",     "type": "float",  "unit": {"lhs": "kilo", "op": "*", "rhs": "meter"} },
       { "name": "velocity",     "type": "float",  "unit": {"lhs": "meter", "op": "/", "rhs": "second"} },
       { "name": "acceleration", "type": "float",  "unit": {"lhs": "foot", "op": "/", "rhs": {"lhs": "second", "op": "^", "rhs": 2}} }
     ]
}
""")

# write some data assuming the write schema above:
writer = DataFileWriter(open("/tmp/unitdata.avro", "wb"), DatumWriter(), writeschema)
writer.append({"distance": 5, "velocity": 20, "acceleration": 32})
writer.close()

# Now define a reader schema which expects different (but compatible) units:
readschema = avro.schema.parse("""
{
     "type": "record",
     "name": "demo_units",
     "fields": [
       { "name": "distance",     "type": "float",  "unit": "mile" },
       { "name": "velocity",     "type": "float",  "unit": {"lhs": "mile", "op": "/", "rhs": "hour"} },
       { "name": "acceleration", "type": "float",  "unit": "gravity" }
     ]
}
""")

# read our data back in, with read schema having differing units:
reader = DataFileReader(open("/tmp/unitdata.avro", "rb"), \
                        DatumReader(writers_schema=writeschema, \
                                    readers_schema=readschema, \
                                    unit_db=udb))

# Print out the data - verify that proper unit conversions were applied
for record in reader:
    print(record)
reader.close()

The program above will output:
{'distance': 3.1068559611866697, 'velocity': 44.73872584108805, 'acceleration': 0.995265306122449}

cc @nielsbasjes @RyanSkraba

@kojiromike thank you for reviewing!  I can certainly investigate use of abstract base classes.  Most of the code in units.py isn't user/api facing, and so I'm unsure how much payoff there would be.  However a few objects like UnitAnalysisDB are more exposed and might in theory appear in differing implementations.
At some point this will require attention to unit testing and documentation, and I could use some guidance on where each of those lives and how they should be composed.

Is the avro community still interested in this, or should I close it?


Remove vars file and replace with secrets

Signed-off-by: Brent Salisbury<EMAIL_ADDRESS>

/run_bbq


Rocketeer event not fired when --on flag specified

I've defined a custom event to rsync some stuff in my events.php on deploy.after
When I call a simple rocketeer deploy it fires and the event handler executes, but when I use rocketeer deploy --on="production" it doesn't even go through that. It does execute the regular after events specified in remote.php though

My events.php
command->askWith('Sync assets ?', 'no', array('yes','no')) ;
        ...
}


Error in some songs

Sometimes when a song start after download I get this error and the bot stop:
Exception in thread Thread-6:
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.5/dist-packages/discord/voice_client.py", line 127, in run
    super().run()
  File "/usr/local/lib/python3.5/dist-packages/discord/voice_client.py", line 93, in run
    self.player(data)
  File "/usr/local/lib/python3.5/dist-packages/discord/voice_client.py", line 676, in play_audio
    sent = self.socket.sendto(packet, (self.endpoint_ip, self.voice_port))
PermissionError: [Errno 1] Operation not permitted

Can you solve this, restart the bot always is getting annoying

I'm not exactly sure what to tell you on this one.  I can tell you that this isn't a bot issue, its an OS issue.  I was told to refer to this: http://stackoverflow.com/questions/23859164/linux-udp-socket-sendto-operation-not-permitted

This has been fixed in discord.py.


Remove some duplicated languages

Remove the legacy mode of SQL and SQLite.

Thanks!

Sure, I've tagged 0.19.2


MLT: Confirm MLT is automatically associated with all covered Rails methods

The method_level_telemetry branch should be updated so that MLT metrics are automatically included alongside of all existing method level metrics that are gathered in a Rails application context. NOTE: see the existing TODO: MLT comments in the source code for suggested entrypoints for this effort.

We reviewed the scope of the existing Rails instrumented methods and agree that they are sufficient for Code level metrics.  We look forward to hearing from the community if there is additional scope needed after our release of this feature.

For posterity if anyone looks over this issue in the future...
Code level metrics will appear in the IDE when a class file has been loaded that meets any one of the following 3 criteria:

The class is a controller class
The class is a job class
The class has manually applied New Relic method traces

Here are our thoughts on each Rails library:

ActiveController: CLM will be reported for all controller methods that generate ActiveSupport::Notifications content (all CRUD and/or routed operations should be covered)
ActiveJob: CLM will be reported for the perform method of any job
ActionView: Without methods being defined in the view templates, we currently don't map any metrics to those files within an IDE. We could potentially map overall stats for each view to individual files in future.
ActionCable: Given the typical use of ActionCable, the methods involved are actually defined in the ActionCable library itself in classes that are unlikely to be loaded up in the user's IDE. No plans for CLM coverage of ActionCable at present.
ActiveRecord: Given that the vast majority of methods are defined in the base library classes, we do not provide CLM for model classes loaded up in the IDE. Any manually traced model method will have CLM data associated with it. In future, we may wish to provide relevant SQL performance data while on the model file.
ActiveStorage: As with ActionCable, the methods involved are defined in the library itself and not covered by us for CLM data.


Fix pressing escape should close the markdown help dialog but not the…

Issue #3472 was fixed. Now pressing ESC will not close the message box when markdown_help is open. I will submit a gif explaining the fix in some time.
Thanks!

Automated message from Dropbox CLA bot
@khantaalaman, it looks like you've already signed the Dropbox CLA. Thanks!

Following GIFs explain the original and the improvised behaviors.
Originally:

Improvised:

I hope this fixes the issue. Please let me know about further improvements, if any.
Thanks!

Further improvisations made in latest commit:

@timabbott Please let me know about further improvements on this, if any.
Thanks!

Thanks @khantaalaman!  I merged this as 71d58eafb79bc53b5cf8109d00c4482b6df772ed, after squashing the commits and fixing the commit message.  Please write your commit messages in the proper style in the future.  Check out the Zulip commit message guidelines for more details: https://zulip.readthedocs.io/en/latest/version-control.html#commit-messages


wrapper.r2py needs better error messages for function's argument type checking

I defined a function in Sensibility's sensor layer like so:
CHILD_CONTEXT_DEF["tts_speak"] = {
"type": "func",
"args": str,
"return": None,
"exceptions": "any",
"target": getsensor.tts_speak, }
This function should be called like this: tts_speak("hello"), where "hello" is the single argument. When I rant the code, I got this error:
12.8230729103 Fatal Error: Function 'tts_speak' does not specify argument definition as tuple or list!
This error comes from wrapper.r2py https://github.com/SeattleTestbed/seattlelib_v2/blob/master/wrapper.r2py#L427 This effectively does not allow functions to have a single argument, as argument types should be defined as "args": (type1, type2, type3, ...). Even "args": (type1) does not work: it should be "args": (type1,).
A clearer message should say something like Function 'tts_speak' should specify argument definition as tuple or list, such as  "args": (type1, [type2, type3, ...])

My approach would be to make the security layer docs more verbose about this. (I think the error message is okay).

That makes sense to me.
On Mon, Aug 10, 2015 at 9:16 AM, aaaaalbert<EMAIL_ADDRESS>wrote:

My approach would be to make the security layer docs more verbose about
this. (I think the error message is okay).
—
Reply to this email directly or view it on GitHub
https://github.com/SeattleTestbed/seattlelib_v2/issues/173#issuecomment-129441848
.

Newcomers: Anyone who has taken Prof Cappos' security classes should be able to fix this in no time.


[SPARK-13642][Yarn] Changed the default application exit state to failed for yarn cluster mode

What changes were proposed in this pull request?
Changing the default exit state to failed for any application running on yarn cluster mode.
How was this patch tested?
Unit test is done locally.
CC @tgravescs and @vanzin .

Test build #53062 has started for PR 11693 at commit da38bc6.

Test build #53062 has finished for PR 11693 at commit da38bc6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/53062/
Test PASSed.

Test build #53143 has started for PR 11693 at commit c41739c.

Test build #53143 has finished for PR 11693 at commit c41739c.

This patch fails MiMa tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/53143/
Test FAILed.

Jenkins, retest this please.

Test build #53170 has started for PR 11693 at commit c41739c.

Test build #53170 has finished for PR 11693 at commit c41739c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/53170/
Test PASSed.

LGTM, merging to master.


wkhtmltopdf-bin: add support for Linux

Description of changes
Added support for Linux.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@nbr I'm currently on travel without my mac, do you mind testing on yours?

What's the motivation for this? We already have wkhtmltopdf built from source, right?

What's the motivation for this? We already have wkhtmltopdf built from source, right?

The wkhtmltopdf we have is not using a patched QA (see #96379) so we've seen issues using it.

Result of nixpkgs-review pr 181407 run on x86_64-darwin 1

1 package built:

wkhtmltopdf-bin

@nbr I'm currently on travel without my mac, do you mind testing on yours?

@kalbasit The darwin build is OK! Would you mind adding yourself as a maintainer to handle PR's related to the Linux parts and/or tearing it down when https://github.com/NixOS/nixpkgs/pull/96379 is merged?

@nbr I'm currently on travel without my mac, do you mind testing on yours?

@kalbasit The darwin build is OK! Would you mind adding yourself as a maintainer to handle PR's related to the Linux parts and/or tearing it down when #96379 is merged?

Agree, thank you. I've added myself as a maintainer as well.


Crashing when parsing group

Love this tool
Any idea why it would crash multiple times when parsing groups?

Could you please run RustHound again with -vv for Trace output and with RUST_BACKTRACE set to 1.
export RUST_BACKTRACE=1 ; rusthound -d x.x (....) -vv
And could you please send me the 5 lines before the crash?
I would like to know if it crashes all the time on the same group?
Thanks!

Thanks for informations.
I don't understand why the security descriptor doesn't want to be parsed for your GUESTS group.
I take note, I removed the unwrap() to replace it with errors.
These will surely be more verbose.
The execution should not crash anymore but the objects that will have the error will not have their ACL.
Could you please do a test again?
cd RustHound git pull cargo b target/debug/rusthound -d x.x -u username -p password -v -o /tmp/output
And if is possible could you please check the "Aces" value for "GUESTS" group in "/tmp/output/x-x_groups.json"?
Thanks.


"import not found" when using dev server

After upgrading to 2.1.0 I get
SyntaxError: import not found Foo

when importing a .tsx file. The imported file is returned as a commonjs file instead of ESM.
Everything works correctly on 2.0.1 and in the production build.

@ntkoopman Awesome, thanks a bunch for reporting it. Just released a new version with the fix.


Change the way Portainer creates NFS4 volumes

right now, when creating an NFSv4 volume using Portainer, we set the mount type to nfs4.
If we inspect a opts.json for a created volume it looks like:
{"MountType":"nfs4","MountOpts":"addr=example.com,rw,noatime,rsize=8192,wsize=8192,tcp,timeo=14","MountDevice":":/"}

What we should do, is ALWAYS set the mount type to NFS, and instead, set the flag nfsvers=4 so that the file looks like:
{"MountType":"nfs","MountOpts":"addr=example.com,nfsvers=4,rw,noatime,rsize=8192,wsize=8192,tcp,timeo=14","MountDevice":":/"}

Required changes
Volume creation view
When NFSv4 is selected in the UI, set the MountType property to nfs and add the following flag nfsvers=4 to the MountOpts property.

Required changes
Volume creation view
When NFSv4 is selected in the UI, set the MountType property to nfs and add the following flag nfsvers=4 to the MountOpts property.


test cases for special characters

I based this commit on top of 1245ec4 in case you wanted to merge it.
The only problem that I have is for < > and &. The others case in the test are already OK but I thought it could be nice to have them. Maybe they could be spitted (the & and other escaped characters vs the others).
I guess the changes would need to be made in quick-xml but it could be nice to have tests here too.

Thanks
I won't merge failing test but I'll use it to implement special characters support ( via unescape methods on quick-csv).


Add React components for Job list, cards and show

Add react-rails
Add Job > list view component.
Add Job > list view > card component.
Add Job > show component.
isomorphic and server-side rendered.

Closing until we can take a look at this again


Update nostr-tools and others for cache-redis

This cleans out old stuff, makes sure that tests can run (they all fail still), and updates nostr-tools

Shit – looks like the merge borked the whole PR. I'll reconstitute this after we get the main NDK update done.


Write TypeChain just once

What's changed
At this moment our readme says:

TypeChain
TypeChain

After this change, there's only one TypeChain, the one in the image (and its alt text).

I did it for the SEO 😆 but probably having alt is good enough.


output of chef client differs when used with pipe or redirection

First, thank you for providing a great tool for free.
Chef helped my server works so much and I really appreciate it.
(And sorry if anyone already reported the same kind of issue. At leas I searched them and found no answer)
When we run chef-solo in the normal way, the output is like this.
$  sudo chef-solo  -c solo.rb -o hello
Starting Chef Client, version 12.0.3
[2015-06-13T00:43:06+09:00] WARN: Run List override has been provided.
[2015-06-13T00:43:06+09:00] WARN: Original Run List: []
[2015-06-13T00:43:06+09:00] WARN: Overridden Run List: [recipe[hello]]
Compiling Cookbooks...
Converging 1 resources
Recipe: hello::default
  * log[hello world] action write

Running handlers:
Running handlers complete
Chef Client finished, 1/1 resources updated in 3.075497 seconds

This is good.
But If we call chef-solo with pipe  or redirection added, the output format totally changes.
$  sudo chef-solo  -c solo.rb -o hello | cat
[2015-06-13T00:43:10+09:00] INFO: Forking chef instance to converge...
[2015-06-13T00:43:10+09:00] INFO: *** Chef 12.0.3 ***
[2015-06-13T00:43:10+09:00] INFO: Chef-client pid: 25396
[2015-06-13T00:43:12+09:00] WARN: Run List override has been provided.
[2015-06-13T00:43:12+09:00] WARN: Original Run List: []
[2015-06-13T00:43:12+09:00] WARN: Overridden Run List: [recipe[hello]]
[2015-06-13T00:43:12+09:00] INFO: Run List is [recipe[hello]]
[2015-06-13T00:43:12+09:00] INFO: Run List expands to [hello]
[2015-06-13T00:43:12+09:00] INFO: Starting Chef Run for DQNEO-no-MacBook-Air.local
[2015-06-13T00:43:12+09:00] INFO: Running start handlers
[2015-06-13T00:43:12+09:00] INFO: Start handlers complete.
[2015-06-13T00:43:13+09:00] INFO: Processing log[hello world] action write (hello::default line 1)
[2015-06-13T00:43:13+09:00] INFO: hello world
[2015-06-13T00:43:13+09:00] INFO: Chef Run complete in 0.42217 seconds
[2015-06-13T00:43:13+09:00] INFO: Skipping removal of unused files from the cache
[2015-06-13T00:43:13+09:00] INFO: Running report handlers
[2015-06-13T00:43:13+09:00] INFO: Report handlers complete

I want to get information of how many resources are updated.
So I use grep,
sudo chef-solo  -c solo.rb -o hello | grep finished

But this outputs nothing!
I think this behavior is very strange and confuses users.
After many hours of investigation, I finally got the workaround.
a workaround for pipe
sudo chef-solo  -c solo.rb -o hello -F doc -l warn | cat

is the same as
sudo chef-solo  -c solo.rb -o hello

My question is, why the output changes when invoked with pipe or redirection ?

dup of #2514
the explanation of 'why?' is long.  we can't fix it without a major version bump, it was missed in Chef 12.0, it needs to not be missed in Chef 13.0.  the --force-formatter and --force-logger flags are probably what you are looking for in order to override the magical switching between the formatter and logger based on pty presence.

I see.
Thank you for the answer.

Still not working in chef-client 13.5.3.
"chef-client -l debug" produces a lot of good debug info, but running
"chef-client -l debug | tee /tmp/d" produces no output.
"chef-client -l debug --force-logger | tee /tmp/d" also produces no output
"chef-client -l debug --force-formatter | tee /tmp/d" produces normal output (like running with no -l debug)
Like others, I'd just like to have the behavior be identical whether I'm sending to STDOUT vs sending to a pipe.


How to setup for object detection with only one class?

I am trying to train a network from scratch on a database with just one class. My labelmap includes class 0 (none_of_the_above) and class 1 (my class). A couple of questions:

Should I specified 1 or 2 for num_classes, considering that I kept the 0?
Should I include images with only background? How to manage the xml annotation in this case?

you have to consider your actual classes + 1 for background. So, in your case, num_classes is 2.
Background annotation is not needed in ssd as of negative samples do exist implicitly though. All region of your images that do not correspond to a bounding box is a "negative sample".
There are some exceptions to the above with different frameworks and implementations but here we are talking about caffe_ssd, so no background annotations are needed.


Browser view refactor (WIP)

In an effort to solve the freezing issue (https://github.com/beakerbrowser/beaker/issues/1333) I've decided to refactor Beaker to use the BrowserView API rather than <webview>. This was a planned update already, but the freezing issue forced me to prioritize it. There will be other advantages to usability; most notably, devtools will be able to dock!
Implementing this change is a pretty big undertaking. Because I can't render shell-window HTML on top of a BrowserView, I have to reimplement all modals and menus as sub-windows that float over the shell window. Given the magnitude of that change, I decided now would be a good time to reimplement basically all of the shell-window UI code (which was pretty crufty). That includes a switch from yo-yo to LitElement, which I've been getting great results from lately.
Todo list:

[x] Migrate to BrowserViews
[x] Shell-window UI (tabs, navbar)
[x] The window menu
[x] Track view load state
[x] Pinned tabs
[x] Tab dragging
[x] Tab context menu
[x] Location bar w/auto-complete
[x] Location bar context menu
[x] Status bar
[x] Browser menu
[x] Bookmark menu
[x] Page menu
[x] Seeding menu
[x] Donate menu
[x] Site-info menu
[x] Sync folder menu
[x] Browser update available menu
[x] Watchlist indicator button
[x] Downloads UI
[x] In-page context menu
[x] Permission prompts UI
[x] Create dat modal
[x] Fork dat modal
[x] Select dat modals
[x] Basic auth modal
[x] Prompt modal
[x] Live reloading
[x] Zoom control
[x] Inpage find
[x] Retained scroll y on refresh
[x] Fullscreen controls
[x] Tab media paused/playing/muted
[x] Dat / https alternative detection
[x] Markdown renderer
[x] JSON renderer
[x] Swipe-to-navigate (removed)
[x] Dat timeout detection
[x] window.open
[x] Keyboard shortcuts
[x] Focus-location command
[x] Focus the location bar on "new tab"
[x] Location bar autocomplete results need to be clickable
[x] Replace titles in history if they change soon after navigation (updateHistory())
[x] Site load errors
[x] On page.url change, main is notified so that it can reconstruct the window-menu. (shell-window:set-current-location)
[x] Tab-state snapshots
[x] Make sure "onbeforeunload" is working
[x] Restore tests
[x] Final QA: Overall visuals
[x] Final QA: Double check all old behaviors were carried over
[x] Final QA: Windows
[x] Final QA: Linux
[x] Final QA: Test the auto-updater with a live system

Issues:

[x] There appears to be an RPC stream leak (?)
[x] View background color is off sometimes
[x] Keyboard shortcuts stop working after focusing browserview
[x] Subwindows should never handle window-menu events or keyboard shortcut events
[x] Scrollbar shows up in the statusbar UI sometimes
[x] The location bar "replace selected text" doesn't always work
[x] Location bar should show URL that's being loaded, but go back to the old URL if canceled

Frustratingly, BrowserView reduces but doesn't eliminate the freezing issue. Webviews will freeze on any site, whereas BrowserView will only freeze on custom protocols.

Almost there! Minus the vendored LitElement code, this PR is currently +7891/-710 (!)
I'm going to merge without removing some dead code so that I can also merge into the blue branch (which has modifications to some of the dead code). After merging, I'll make another PR that removes the dead code.

👍 This PR is ready to go. Merging now!
This won't fix the freezing issue. That's now being addressed with https://github.com/electron/electron/pull/17221. We'll wait for that fix to land in electron to release a new Beaker with this PR.
Any folks building from source, feel free to give the new master a try and let me know how this refactor works for you. Hopefully there aren't too many new bugs or regressions.


Blue or red cross?

Rdmo help refers to a "red cross" but in the ui the cross is of blue color. This affects the en locale only:
https://github.com/rdmorganiser/rdmo/blob/b87cb5b427f44d8ae53d260d9c30edaf08b5625a/rdmo/projects/templates/projects/project_questions_add_field_help.html#L5
while other locales, eg. de have been corrected already
https://github.com/rdmorganiser/rdmo/blob/f4305549df213282ec6e8728b258ea27ece5d91c/rdmo/locale/de/LC_MESSAGES/django.po#L2201

Fixed here: https://github.com/rdmorganiser/rdmo/commit/9a3c5a66e872b1c7138c0fef48a6ea23289494eb#diff-1f4fdc52a9152b261626bb12e2da5ec5L2197. Will be in the next release.


feat(circuits): add QAOALineCircuit class

Summary
Adds new QAOALineCircuit class to create parameterized QAOA quantum circuits for line acyclic graphs, at varying number of qubits and two-qubit depth.
Details and comments

This is a utility class to avoid building these (well-known) circuits manually in present and upcoming notebooks.
Needed for the Utility Scaling notebook, demoed at IBM Quantum Practitioner's Forum 2023.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 43 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
47

Relevant Lines:
47

💛  - Coveralls

Two thoughts on this QAOA circuit:

A line circuit should be able to handle 2-qubit QAOA as well. Can we add a separate "if" condition that when num_qubits is two, only one of the two Rzz layers will be placed?
I was a bit skeptical about the definition of depth for long. (i) Stating that depth is the two-qubit depth can be confusing since this is meant by keeping Rzz depth in mind. But once the circuit is decomposed, the 2-qubit depth will increase. (ii) The definition of depth by Farhi (cited here) is not the same as the convention in this code. In Farhi's paper depth-1 implied one U(H_P, gamma) and U(H_M,beta). Can we shift to this definition of depth (which then becomes independent of transpilation, decomposition etc)? All we need here is instead of doing depth//2 for parameters, we need to do depth*2.


CME styling

This PR changes the CME to be a single surface highlighting where it is in space.
Additionally, the lat/lon surfaces are now smoother without the cell-like features of before.

Just pushed a few more commits.

Tried to eliminate some unnecessary calculations
Added streamlines to the latitudinal plane, but they are off by default. They don't appear very useful, so we might not even want them at all...
Added the ability to rotate the latitudinal plane as well (I think the refactor made this work so it doesn't segfault now, it was already implemented just needed to remove the blocking line of code).


esp32_spiflash.c: Correctly disable APP's CPU cache.

Summary
Correctly disable APP's CPU cache during SPI flash operation.
Impact
ESP32 SPI Flash driver.
Testing
esp32-devkitc:spiflash with SMP.

@Ouss4
I noticed that esp32-devkitc:wapi_smp does not work with this PR.

@masayuki2009 sorry I didn't see your comment earlier.  Yes, I'm working on this.  The APP CPU needs to be properly paused when the cache is disabled.


High memory usage?

bedrocikifierd seems to use 1GB memory, is that expected?

Couple questions:

How are you measuring? VSZ can be somewhat misleading depending on what's actually going on. It's a representation of the virtual memory address space, and not always real memory.
How do you have things configured?

I took a Quick Look at my install for reference, which backs up two different servers to a NAS for me, using SSH rather than Docker to communicate with the servers. RSS (resident memory) looks normal at about 45MB. I do also see 1GB for VSZ, but digging in further, about half of this is for pages that have zero actual impact on the system other than the virtual address mapping existing. They aren't resident in RAM, have no dirty bytes, and aren't even listed as impacting swap. They only exist as an entry in the process' memory table.
Digging in further, the remaining gap seems to be pages that aren't dirty. So there will be a rather sizable memory mapping done (~64MB), only a fraction of that will be in use. So while the vast majority of this.
So three things I think can be taken away from this:

RSS/USS is going to measure the actual impact on memory, and seems to handle steady state rather well at least. No clear leaks. That said, I'd need to dig in further to see exactly how the memory usage breaks down.
Something about the underlying allocator (glibc) and Swift is causing the higher VSZ reporting. Unfortunately, it also seems to lead to Linux marking quite a bit of the swap file (400MB in my case) as 'used' when there isn't anything there worth keeping in swap. It's 'clean'.
The underlying allocator is also leading to heavily fragmented virtual memory space. I am not sure if this is because allocations are getting padded for security or something else. This is deep into how Swift itself calls into the allocator, and not something I've had to investigate deeply on Linux before.

I can see if one of the other allocators available does better in this scenario.

I observed the 1GB usage in the Stats tab of Portainer for the container, so however that messages usage. Noticed the container had been up for about a month so restarted it and usage dropped down to about 64MB so I don't know if there's some kind of leak or Portainer is doing dodgy reporting!


Ability to extend babel config in Vite?

In the app I'm using Macaron in, we have decorators, which I enable like this in Vite:
plugins: [
  ...
  react({
    babel: {
      plugins: [
        ['@babel/plugin-proposal-decorators', { legacy: true }],
        ['@babel/plugin-proposal-class-properties', { loose: false }],
      ],
    },
  }),
  macaronVitePlugin(),
],

This configuration doesn't extend to Macaron when I add it to the plugins, and I get this error

App.tsx: Support for the experimental syntax 'decorators' isn't currently enabled (39:1):

Would it be possible to extend the API of the Vite plugin to allow users to pass in additional plugins/presets to the babel config in @macaron-css/integration?
https://github.com/macaron-css/macaron/blob/main/packages/integration/src/babel.ts#L11

@Mokshit06 I'd like your feedback on the open PRs and get them merged if possible. I'd appreciate your input!

The PR looks good, will merge. Thanks!


Order Submission Issue

I tried to make 5 KMD/RICK orders very quickly. I did not wait till the orders showed up on the GUI to place the next one. It looks like all 5 is open but on the KMD sell order side, I can see the same line on the KMD sell order side flicking between all the various prices i put up (50/52/53/54) Why are these not their own lines?
Is there a timer value here in terms of how fast new orders can be placed? Should there be a please wait for order to be processed etc?

@dumbo321 thanks for the detailed report, I was able to re-create this.
 However if your order is not filled after a certain amount of time, marketmaker will re-create your order as a maker, and in that case your order will now show in the order book.
Because you are creating an order on a pair with no activity, your orders aren't getting filled, so they are all getting converted to maker orders, which should show in the order book.
I created 5 orders on the CHIPS/RICK pair of prices 0.1, 0.2, 0.3, 0.4, 0.5. They all went to maker orders but I only saw one entry in the order book that constantly shuffled between those 5 prices, as you described.
I can confirm this is definitely a marketmaker issue and not an issue in the GUI. For some reason it is only returning one of the order prices each time we request the order book. Maybe it's using the address/pubkey as a unique ID for orders?
You can see the buggy behaviour isolated to marketmaker here by just requesting the order book with cURL:
$ curl 'http://<IP_ADDRESS>:56497/' -H 'Referer: http://localhost:8080/dev.html' -H 'Origin: http://localhost:8080' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) HyperDEX/0.4.0 Chrome/73.0.3683.121 Electron/5.0.2 Safari/537.36' -H 'Content-Type: text/plain;charset=UTF-8' --data-binary '{"method":"orderbook","base":"CHIPS","rel":"RICK","userpass":"<redacted>"}' --compressed
{"askdepth":0,"asks":[],"base":"CHIPS","biddepth":0,"bids":[{"coin":"RICK","address":"RQm8BNygniNVqVPRYXEosznRZ7uEiooqSm","price":0.01,"numutxos":0,"avevolume":0.0,"maxvolume":0.01,"depth":0.0,"pubkey":"30b4191bd253364abe8c19976f196bbcc2f3e66724816ef70e7fe472b5f59d0c","age":0,"zcredits":0}],"netid":0,"numasks":0,"numbids":1,"rel":"RICK","timestamp":1564675907}%
hyperdex %
$ curl 'http://<IP_ADDRESS>:56497/' -H 'Referer: http://localhost:8080/dev.html' -H 'Origin: http://localhost:8080' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) HyperDEX/0.4.0 Chrome/73.0.3683.121 Electron/5.0.2 Safari/537.36' -H 'Content-Type: text/plain;charset=UTF-8' --data-binary '{"method":"orderbook","base":"CHIPS","rel":"RICK","userpass":"<redacted>"}' --compressed
{"askdepth":0,"asks":[],"base":"CHIPS","biddepth":0,"bids":[{"coin":"RICK","address":"RQm8BNygniNVqVPRYXEosznRZ7uEiooqSm","price":0.05,"numutxos":0,"avevolume":0.0,"maxvolume":0.05,"depth":0.0,"pubkey":"30b4191bd253364abe8c19976f196bbcc2f3e66724816ef70e7fe472b5f59d0c","age":1,"zcredits":0}],"netid":0,"numasks":0,"numbids":1,"rel":"RICK","timestamp":1564675910}%

The first cURL response returns the price as 0.01. The second identical order book request returns the price as 0.05. We are displaying the data in the GUI exactly as we get it from marketmaker.
@artemii235 are you aware of this issue?

@lukechilds The corresponding MM2 issue is closed, the bug should be fixed in the https://github.com/KomodoPlatform/atomicDEX-API/commit/d30c4295805ca39211d5a680a5ddb7494d9afdf2. Please update MM2 in HyperDEX bundle and retest.