raft: avoid the unnecessary clone of the raft unstable log

When we new the Raft Ready, we will clone all unstable logs, see:
        let mut rd = Ready {
            entries: raft.raft_log.unstable_entries().unwrap_or(&[]).to_vec(),
            messages: raft.msgs.drain(..).collect(),
            ..Default::default()
        };

But this is unnecessary, the unstable logs will not be changed until we commit the append ready.

This code doesn't seem to exist anymore. Is this issue still relevant?

yes, @brson
It still exists in the raft-rs library.

I must have been grepping the wrong repo. Here it is: https://github.com/pingcap/raft-rs/blob/3eb423597d6650d3dbe4346a47ca12c6022fd154/src/raw_node.rs#L130
This seems like it should be relatively easy for someone with some understanding of the crate, but personally it's not obvious to me how to do it from a glance. More detail would help a contributor. As a naive contributor I'd start by just removing the entries field from Ready and seeing what happens.

To be perfectly clear, the problem is the call to to_vec here:
raft.raft_log.unstable_entries().unwrap_or(&[]).to_vec(),

It might copy a lot of data for no reason. This task is to figure out how to delay that copy until it is definitely needed.

To get rid of copy, is it possible to change the entries field's type to &[Entry] in Ready struct?
However this would lead to first mutable borrow on raw_node ends later than second mutable borrow, thus introduce some compile time error I can't solved by myself.
error[E0499]: cannot borrow `raw_node` as mutable more than once at a time
   --> tests/integration_cases/test_raw_node.rs:455:5
    |
453 |     let rd = raw_node.ready();
    |              -------- first mutable borrow occurs here
454 |     assert!(cmp_ready(&rd, &None, &None, &[], entries.clone(), false));
455 |     raw_node.advance(rd);
    |     ^^^^^^^^         -- first borrow later used here
    |     |
    |     second mutable borrow occurs here

Thanks for giving it a look @liyuntao.
It seems that simply storing a slice for Ready::entries won't work, because that borrows from the RawNode; and RawNode::advance needs to be called mutably with the Ready that is already mutably borrowing it.
My inclination on seeing that is to not store 'entries' in Ready at all, but to just store an index or other value that will allow entries to be retrieved later, when 'advance' is called. I note that the 'advance' method doesn't even use the entries array except to grab the index of the very last entry, then advances the raft log with it.
Sadly though, Ready has an 'entries' method to access the Entry array, and it's used in a number of examples and test cases.
A common construct in the test cases shows all these APIs:
    let s = new_storage();
    let mut raw_node = new_raw_node(1, vec![], 10, 1, s.clone(), vec![new_peer(1)]);
    let rd = raw_node.ready();
    s.wl().append(rd.entries()).expect("");
    raw_node.advance(rd);

So to get rid of the extra clone of unstable entries one has to have a way to feed those entries to Storage::append and also to advance the log in raw_node.advance.
It seems like accomplishing this will require changes to APIs that I don't have a good understanding of. Maybe @Hoverbear has some insight.

/cc @BusyJay


[Documentation] How to configure db connection

I see a cloudfoundry environment configuration and a local configuration, how would I configure this to use a different cloud provider?
For example, my database uri is provided as an environment variable, how can I tell mage what this is?

@benhosmer you need create a new environment module.  Both the local and cloudfoundry envs are modules.  The easiest way would be to copy the contents of the cloudfoundry directory to a new directory in the environment dir.
From there just change the the mongo variable to pull what it needs from the environment: https://github.com/ngageoint/mage-server/blob/master/environment/cloudfoundry/env.js#L11-L20
You would need to change this file to key off of some unique env for your cloud provider:
https://github.com/ngageoint/mage-server/blob/master/environment/env.js
IE
var env;
if (process.env.CLOUDFOUNDRY) {
 env = require('cloudfoundry-environment');
} else if (process.env.OPENSHIFT) {
 // not sure if open shift provides an OPENSHIFT env variable.
 // if not change process.env.OPENSHIFT to something unique that is does provide to indicate
 // your env is open shift
 env = require('local-environment');
} else {
 env =  require('local-environment');
}

module.exports =  env;

If you have already done an npm install you will either need to bump the version number on the environment module or wipe out the environment-* modules in the node_modules directory.  Then npm install again.  This will pick up and install the changes that you made to the environment module.

@newmanw thanks for the quick response on this. I haven't had a chance to try it out, but I'll report back if I have any more issues.


proposal: src/bufio: consider add one function for handle multi delimeter one by one

example:<PHONE_NUMBER>000000080101e2000000000000000000000000030004510100462323
0x23 0x23 is end of protocol example from network flow,is necessary new add function to handle multi delimeter
for examle .
func reader.ReadBytes(delim byte,count int)

instead of
 func reader.ReadBytes(delim byte)

or other way?

See Scanner.Split, it covers a wider range of usecases than just repeated byte delimiters
Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.
For questions please refer to https://github.com/golang/go/wiki/Questions


How to store a RenderPass in a struct

Hi vulkano people,
hope this is the right place to ask. I'm hacking on a small renderer and just can't get my head around the descriptor type of RenderPass<T>.
the RenderPass gets created as follows:
let render_pass = Arc::new(single_pass_renderpass!(device.clone(),
    attachments: {
        color: {
            load: Clear,
            store: Store,
            format: swapchain.format(),
            samples: 1,
        }
    },
    pass: {
        color: [color],
        depth_stencil: {}
    }
).unwrap());

and i would like to store it inside a struct
pub struct Renderer {
    // ...
    render_pass: Arc<RenderPass<_>>,
}

It looks like the macro creates a new type for the render pass. My main goal is to not have the loop { } inside the renderer as the examples do, but it feels like i'm programming against the library. Any suggestions would help a lot!
Cheers!

Same. The macro generates a private module with a CustomRenderPassDesc struct, which is not usable outside the function.

Weird, the $device was once removed from the macro and added back in commit https://github.com/tomaka/vulkano/commit/738b16cb0700f9747054327cffe593e7c5e15271

You can cast the Arc<_> into a Arc<RenderPassAbstract>.
This is a problem I'm well aware of, and in fact many traits of vulkano exist for the sole purpose of behind able to cast to Arc<Trait>.
I need to add a "real-world" example somewhere in order to show how things are designed.

Thanks, will try that later.

The hint to cast things to their trait type helped a lot! I think we can close this :D

Any chance of something like this for the GraphicsPipeline? I was trying to return one from a function, by tricking the compiling into telling me the expected return type I got as far as:
type Pipeline<L> = GraphicsPipeline<SingleBufferDefinition<VertexDefinition<vs::MainInput>>, Box<PipelineLayoutAbstract + Send + Sync>, Arc<L>>;

And it still needed some associated type hints. At that point I tried to give up and just wrapped it in a macro but ended up with the exact same problem.
Now I'm just blindly copying the genetics from the docs and trying to guess what the types are.
Really not convinced that Rusts safety warrant this kind of arcane syntax overhead, especially since any halfway sane drivers shouldn't crash or anything.

@dcbishop There's GraphicsPipelineAbstract.


Add dockerignore file

Similar to a .gitignore file,  .dockerignore prevents unwanted files (Data, configs) from ending up accidentally baked into Docker images!

Apparently I can't convert back to a draft from a normal PR so this label will have to do.
Reverting to draft status because I need to check whether this affects the git hash based version checking (Adding -dirty where undesired)

Oh I found the button to convert to draft, it shows up when there's no pending reviewers.
Good thing to know for future, no longer considered draft because I fixed that concern in https://github.com/Yuuki-Discord/Yuuki-Bot/pull/72/commits/5eed9c5b1e96e714c9b526570e1dc727cdf43d0a
Review away 🚀


feat(model): remove tracing

The tracing ecosystem of crates allow for recording events which can then be viewed when debugging. Most twilight crates therefore record useful data with it, but its unnecessary for twilight-model to do so. This is because deserializers most necessary data on deserialization error for troubleshooting. Including further details is left to dependants. twilight-gateway, for example, includes the full gateway event in ReceiveMessageError.

While I am generally in favor of this change (I was the author of the PR a few years ago when it was made optional, #1203), we have made tracing mandatory again with #1684.
Things I'd like to clarify before merging this:

Why exactly are we doing this?
Why would we drop support for it in one crate, but not the others?
Is making it optional not the better long-term solution?
Why are we even reverting our previous stance (that it is so widely used in the ecosystem that we have no gains from making it optional) which reverted a previous stance (that it should be possible to disable a feature to remove dependencies and overhead)?

I've said this a few times with some of the recent PRs: We should not change design decisions with every minor release. If we want to keep or remove tracing in some or all crates, we should have good reasoning for our way of dealing with it and stand by our decisions instead of reverting them every once in a while.

@Gelbpunkt I filled in the PR description with some info, but to answer your points one by one:

The usage of tracing in twilight-model is largely historical and (no longer?) serves any use
twilight-model contains just data definitions so there can be no logic issues (serde errors do not count). Compared to, for example, twilight-gateway which needs to check a bunch of conditions to correctly implement the Discord gateway protocol. As there's much more that can go wrong, and more branching points, usage of tracing is crucial to debug issues.
I argue that there's no benefit to tracing at all, making it optional would just introduce more conditionals inside Twilight.
This is not a reversal as the previous stances covered all of Twilight, this is just for the model.


Angular 9 compiler error

Current behavior
ERROR in node_modules/@ngx-translate/http-loader/lib/http-loader.d.ts:4:22 - error NG6002: Appears in the NgModule.imports of AppModule, but could not be resolved to an NgModule class.

This likely means that the library (@ngx-translate/http-loader) which declares TranslateHttpLoader has not been processed correctly by ngcc, or is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if so. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.

4 export declare class TranslateHttpLoader implements TranslateLoader {
                       ~~~~~~~~~~~~~~~~~~~

How do you think that we should fix this?
I think that is an  IVY compiler compatibility problem
Environment

ngx-translate version: X.Y.Z
Angular version: X.Y.Z

For Tooling issues:

Angular CLI: 9.0.7
Node: 13.5.0
OS: darwin x64

Angular: 9.0.7
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.7
@angular-devkit/build-angular     0.900.7
@angular-devkit/build-optimizer   0.900.7
@angular-devkit/build-webpack     0.900.7
@angular-devkit/core              9.0.7
@angular-devkit/schematics        9.0.7
@angular/localize                 9.1.1
@ngtools/webpack                  9.0.7
@schematics/angular               9.0.7
@schematics/update                0.900.7
rxjs                              6.5.5
typescript                        3.7.5
webpack                           4.41.2

I'm closing this issue cause apparently war my mistake. I leave here what I did to solve the error
app.module.ts
    TranslateModule.forRoot({       loader: {         provide: TranslateLoader,         useFactory: httpTranslateLoader,         deps: [HttpClient],       },     }),
changed for:
    TranslateModule.forRoot({       loader: {         provide: TranslateLoader,         useFactory: (http: HttpClient) => { return new TranslateHttpLoader(http, './assets/i18n/', '.json'); },         deps: [HttpClient]       }     }),


Prototype for showing runtime errors in codemirror

Hi, I'd like to add functionality to show runtime errors in the codemirror frame (similar to the endless loop warning and lint errors).
Background: Jsbin seems ideal for learning JS, but finding errors in the JS console adds an additional hurdle for beginners, and the console takes up a lot of space on small screens.
I have created a proof of concept in this pull request, would like to get feedback on

whether you think this is a reasonable improvement
what's needed for an initial version

Known issues:

The existing endless loop detection code adds additional lines, which breaks the mapping. I think this can be fixed by making sure the endless loop detection doesn't add additional code lines
The line numbers are off in FF -- I think it starts counting at the start of the file instead of the start of the corresponding script tag. This should be fixable, too, e.g. by handing over the position from the processor somehow.
I have only tested this on Chrome and Firefox on Ubuntu 15.10 so far.

Bit late, but do you have any screenshots to add to this?


Why custom ObservableList?

Hello,
Could you please explain why do you create custom 'ObservableList' and didn't use 'ObservableCollection' from System.Collections.ObjectModel?
This makes usage of UnityWeld very limited. You force users of UnityWeld to has tight coupling with it. Which provides limitations like: can't switch between mvvm frameworks, can't use different frameworks for different platforms/engines, can't have common UI code for view implementations, constantly has a ref to UnityWeld everywhere.
As far as I know .Net 3.5 is deprecated long time ago
https://forum.unity.com/threads/net-3-5-runtime-has-been-deprecated-in-unity-2018-3.601384/
and .netstandard 2.0 and 4.x api (in Unity) perfectly support ObservableCollection.
Can we just get rid of .net 3.5 already and use standard ObservableCollection?
Thanks.

I've made this change in my rep if you interested:
https://github.com/TimGameDev/Unity-Weld/commit/b961d82f0ea609e8adf501ac3953e1fa3ba21d55
Also checked examples and if update this file with ObservableCollection everything works perfectly
https://github.com/Real-Serious-Games/Unity-Weld-Examples/blob/master/Assets/Collection/MyUI3.cs

I like the idea, however in Unity 2017.4 (LTS Release) .NET 3.5 is still supported and will be until 2020 from my understanding

Thanks for the answer.
Good catch. According to official site

Each LTS stream will be supported for a period of two years.

2017 LTS was released in 20 March 2018. So yeah...until 2020.
I'm going to use my version (since I need abstract UI dll which is not relate to any plugins), so if you want I can keep my PR to discuss it later.

Yeah I'd like to keep support for .NET 3.5 at least until the 2017.4 LTS is no longer officially supported. Would have to have another discussion to figure out if we still want to support .NET 3.5 for the duration of the 2018.4 LTS period too because that version does still support .NET 3.5, although I think it's marked as deprecated.
One way we could potentially make the transition smoother would be to refactor the existing ObservableList to match the API of ObservableCollection so that when it is time to switch over, we can seamlessly transition from the custom implementation to the built-in one. Would also require renaming our ObservableList "ObservableCollection" but since it isn't ever serialised to the Unity scene and the API isn't considered stable yet I think that breaking change would be worth it. If we did that we could even start conditionally compiling against .NET ObservableCollection for the .NET Standard build target right now.

Thanks for your time.
I'm pretty sure that the number of .net3.5 users in 2018.4 LTS is very close to 0. It's marked as deprecated since 2018.3 (link in my original post).
imho UnityWeld can safely omit .net3.5 support after 2020.
I think there is no reason to change current ObservableList at the moment because it implements IList and ObservableCollection has Collection as base class which also implements IList.
In fact the whole transition will look like 'replace ObservableList with ObservableCollection in project' and fix namespaces.
I can easily keep my version up to date until 2020 (and I'm going to).
PS: UnityWeld is great idea. And the main reason of my question is help to improve this plugin.


Add CDNJS version badge in README.md

This badge will show the version on CDNJS!

Thanks for the PR!
Maybe it would be better if we add this link to the website http://craftyjs.com, under the installation section, alongside these other variants.


1 FAILED TEST: testDPGO.testRobustSinglePoseAveraging

@yuluntian in extending testStiefelProjection to cover an increased number of iterations (say j < 100 in tests/testUtils.cpp, Line 32), testRobustSinglePoseAveraging fails with the following error:
/home/alex/catkin_ws/src/dpgo/tests/testPGO.cpp:120: Failure
Expected: ((ROpt - RTrue).norm()) <= (RMaxError), actual: 2.77197 vs 0.0282838
[  FAILED  ] testDPGO.testRobustSinglePoseAveraging (2 ms)

Emperically, it seems repeat calls to Matrix::Random() in tests/testUtils.cpp, Line 33 produces this error (replacing Matrix::Random() with Matrix::Identity(), for example, seems to indicate this is the case).

Alternatively, changing the number of iterations directly within testRobustSinglePoseAveraging to trial < 500, for example:
https://github.com/mit-acl/dpgo/blob/a238090c6427ad509370bd6c302bcac82c1be95f/tests/testPGO.cpp#L87
reproduces the identical error


Sample mutate policy for pod security context attributes

See: https://kubernetes.slack.com/archives/C8P1DRTJA/p1626520243195800

Anyone know of a mutating webhook that will inject default security contexts into a pod?  Ie if you don't specify a runas it creates it for you?  Something similar to how openshift mutates pods

A Kyverno policy can check of runAs and other securityContext attributes like runAsNonRoot are specified and automatically inject them if needed.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-securitycontext
spec:
  background: false
  rules:
  - name: add-default-securitycontext
    match:
      resources:
        kinds:
        - Pod
    mutate:
      patchStrategicMerge:
        spec:
          securityContext:
            +(runAsUser): 1000
            +(runAsGroup): 3000
            +(fsGroup): 2000


AAAANd - Crash ;)

Update to latest version, manager and LTN. Map Runs a minute r two, then crashes (without any related ation from me, I am just leaving it running doing some watching).
Error whle running event LogisticsTrainNetwork:on_train_changed_state(ID 23)
LtnManager/scripts/dataManager.lua:588 attempt to perform arithmetic on field "started" (a nil value)
LtnManager/scripts/data-manager.lua:588 in function Whandler"
RailLuaLib/lualib/event.lua:127

As stated in the template... please send me the save file. :)

I can't fix the bug unless you send me the save file where the bug occured!

Please send me a save file so I can fix this!


Access to Subject without And

At the moment I'm doing the following in order to squash a type assertion and assignment into an expression for xBehave.net:
"And the event should indicate that a widget has been added"
   .f(() => widgetAdded = (WidgetAdded)@event.Should().BeAssignableTo<WidgetAdded>().And.Subject);

The And.Subject is really odd when you read that back. I've no idea if it's feasible but, in cases such as this, it would be nice to have the option to drop the conjunction And:
"And the event should indicate that a widget has been added"
   .f(() => widgetAdded = (WidgetAdded)@event.Should().BeAssignableTo<WidgetAdded>().Subject);

Of course I could just drop the assertion and just cast only, but then if the test were to fail I'd have a nasty InvalidCastException in my test output instead of a lovingly crafted FluentAssertions exception.
I guess even nicer would be if BeAssignableTo() already casts Subject to the asserted type, removing the need for me to cast:
"And the event should indicate that a widget has been added"
   .f(() => widgetAdded = @event.Should().BeAssignableTo<WidgetAdded>().Subject);

Even if dropping the need for And is not possible, it would be great if this casting could happen. I'd be happy to raise a separate issue for that if you think it's feasible.

@adamralph, you still think this is a wise idea?

I think so, yes. I'm wondering if it may be worth deprecating Which in favour of Subject?

That'll break the fluent API I introduced in 3.2.

I'm only suggesting a deprecation, not a removal. I.e. [Obsolete].
Although, that's not really necessary, you could just have Subject as a synonym for Which, doing exactly the same thing.

:+1:


[Bug] wrong permutation indices when task scheduling reordering occurs

Running concurrency test on sort revealed that we have a reordering issue somewhere.
    shuttle::check_random(
        || {
            shuttle::future::block_on(execute_sort()).unwrap();
        },
        5,
    );

fails with
test panicked in task 'main-thread'
index out of bounds: the len is 50 but the index is<PHONE_NUMBER>
thread 'tests::randomized::sort' panicked at 'index out of bounds: the len is 50 but the index is<PHONE_NUMBER>', src/protocol/sort/apply.rs:23:24
stack backtrace:
   0: rust_begin_unwind
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:142:14
   2: core::panicking::panic_bounds_check
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:84:5
   3: core::slice::<impl [T]>::swap
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/slice/mod.rs:619:36
   4: raw_ipa::protocol::sort::apply::apply
             at ./src/protocol/sort/apply.rs:23:17
   5: raw_ipa::protocol::sort::compose::compose::{{closure}}
             at ./src/protocol/sort/compose.rs:50:5
   6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/future/mod.rs:91:19
   7: raw_ipa::protocol::sort::generate_sort_permutation::generate_sort_permutation::{{closure}}
             at ./src/protocol/sort/generate_sort_permutation.rs:69:9
   8: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/future/mod.rs:91:19
   9: <F as futures_core::future::TryFuture>::try_poll
             at /Users/koshelev/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.25/src/future.rs:82:9
  10: <futures_util::future::try_future::into_future::IntoFuture<Fut> as core::future::future::Future>::poll
             at /Users/koshelev/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.25/src/future/try_future/into_future.rs:34:9
  11: <F as futures_core::future::TryFuture>::try_poll
             at /Users/koshelev/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.25/src/future.rs:82:9
  12: <futures_util::future::try_maybe_done::TryMaybeDone<Fut> as core::future::future::Future>::poll
             at /Users/koshelev/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.25/src/future/try_maybe_done.rs:79:57
  13: <F as futures_core::future::TryFuture>::try_poll
             at /Users/koshelev/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.25/src/future.rs:82:9
  14: <futures_util::future::try_join_all::TryJoinAll<F> as core::future::future::Future>::poll
             at /Users/koshelev/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.25/src/future/try_join_all.rs:148:27
  15: raw_ipa::test_fixture::sort::execute_sort::{{closure}}
             at ./src/test_fixture/sort.rs:53:9
  16: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/future/mod.rs:91:19
  17: shuttle::future::block_on
             at /Users/koshelev/.cargo/registry/src/github.com-1ecc6299db9ec823/shuttle-0.4.1/src/future/mod.rs:148:15
  18: raw_ipa::tests::randomized::sort::{{closure}}
             at ./src/tests/randomized.rs:10:13

Permutation slice contains some weird values
permutation = [
    29,
    1,
    7,
    37,
    434506957,
    16,
    14,
    44,
    776628359,
    41,
    13,
    31,
    8,
    23,
    42,
    35,
    27,
    40,
    5,
    12,
    36,
    19,
    25,
    49,
    17,
    9,
    33,
    39,
    15,
<PHONE_NUMBER>,
    34,
    38,
    4,
    21,
    43,
    0,
    28,
    2,
    20,
    32,
    3,
<PHONE_NUMBER>,
    48,
    26,
    6,
    45,
    11,
    22,
    30,
    10,
]

Reveal in isolation works fine
 cargo test --features shuttle --package raw-ipa --lib tests::randomized::reveal
   Compiling raw-ipa v0.1.0 (/Users/koshelev/workspace/raw-ipa)
    Finished test [unoptimized + debuginfo] target(s) in 5.34s
     Running unittests src/lib.rs (target/debug/deps/raw_ipa-13f7cbe4f34a1d27)

running 1 test
test tests::randomized::reveal ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 104 filtered out; finished in 6.70s

this is the test
  async fn reveal() -> Result<(), Error> {
        let mut rng = rand::thread_rng();
        let world: TestWorld = make_world(QueryId);
        let ctx = make_contexts::<Fp31>(&world);

        for i in 0..10_u32 {
            let secret = rng.gen::<u128>();
            let input = Fp31::from(secret);
            let share = share(input, &mut rng);
            let record_id = RecordId::from(i);
            let results = try_join_all(vec![
                ctx[0].clone().reveal(record_id, &share[0]),
                ctx[1].clone().reveal(record_id, &share[1]),
                ctx[2].clone().reveal(record_id, &share[2]),
            ])
                .await?;

            assert_eq!(input, results[0]);
            assert_eq!(input, results[1]);
            assert_eq!(input, results[2]);
        }

        Ok(())
    }

Infra stays strong and denies my allegations
 cargo test --features shuttle --package raw-ipa --lib tests::randomized::arithmetic
   Compiling raw-ipa v0.1.0 (/Users/koshelev/workspace/raw-ipa)
    Finished test [unoptimized + debuginfo] target(s) in 8.44s
     Running unittests src/lib.rs (target/debug/deps/raw_ipa-13f7cbe4f34a1d27)

running 1 test
test tests::randomized::arithmetic ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 105 filtered out; finished in 16.86s

#[test]
fn arithmetic() {
    shuttle::check_random(|| {
        shuttle::future::block_on(circuit::arithmetic::<Fp32BitPrime>(100, 5))
    }, 100);
}

I found my suspect but still don't have the root cause. Running two futures concurrently causes data corruption.
        let ctx_bit = ctx.narrow(&Sort(bit_num));
        let ((shuffled_compose_permutation, random_permutations_for_shuffle), bit_i) = try_join(
            shuffle_and_reveal_permutation(
                ctx_bit.narrow(&ShuffleRevealPermutation),
                input_len,
                composed_less_significant_bits_permutation,
            ),
            convert_shares_for_a_bit(ctx_bit.narrow(&ModulusConversion), input, num_bits, bit_num),
        )
        .await?;

if I remove try_join everything works fine.
I also wrote a simpler test that drives shuffle and convert in parallel and it shows the same symptom. I have a chance to validate shares produced by shuffle and they are corrupted
    x1           x2           x2        x3           x3            x1
(1950749719,<PHONE_NUMBER>), (367963562,<PHONE_NUMBER>),<PHONE_NUMBER>,<PHONE_NUMBER>)

clearly helper 1's view of X2 does not match helper 2's view.

got some more samples of data corruption. Interestingly they all have x2 share corrupted
<PHONE_NUMBER>_mod4294967291,<PHONE_NUMBER>_mod4294967291), (471208790_mod4294967291, 978905089_mod4294967291),
 (978905089_mod4294967291,<PHONE_NUMBER>_mod4294967291)

(2051700797_mod4294967291,<PHONE_NUMBER>_mod4294967291),<PHONE_NUMBER>_mod4294967291, 623362995_mod4294967291), (623362995_mod4294967291,<PHONE_NUMBER>_mod4294967291)

Narrowed down the issue to reshare. Here is the test that reproduces it (forgive the copy paste and syntax)
#[test]
fn reshare_just_reshare() {
    shuttle::check_random(
        || {
            shuttle::future::block_on(reshare_just_reshare_inner());
        },
        100,
    );
}

async fn reshare_just_reshare_inner() {
    let world = make_world(QueryId);
    const NUM_BITS: u8 = 24;
    const ROUNDS: usize = 50;

    let match_keys = {
        let mut rng = thread_rng();
        const MASK: u64 = u64::MAX >> (64 - NUM_BITS);
        let mut match_keys: Vec<u64> = Vec::new();
        for _ in 0..ROUNDS {
            match_keys.push(rng.gen::<u64>() & MASK);
        }

        let mut shares = [
            Vec::with_capacity(ROUNDS),
            Vec::with_capacity(ROUNDS),
            Vec::with_capacity(ROUNDS),
        ];
        for match_key in match_keys.clone() {
            let share_0 = rng.gen::<u64>() & MASK;
            let share_1 = rng.gen::<u64>() & MASK;
            let share_2 = match_key ^ share_0 ^ share_1;

            shares[0].push((share_0, share_1));
            shares[1].push((share_1, share_2));
            shares[2].push((share_2, share_0));
        }

        shares
    };

    let mut input = (0..ROUNDS).map(|v| Fp32BitPrime::from(v as u128)).collect::<Vec<_>>();
    let expected_sum = input.iter().map(|v| v.as_u128()).sum::<u128>();
    for bit in 0u8..24 {
        let match_keys = &match_keys.clone();
        let [shares0, shares1, shares2] = world.semi_honest(input.clone(), |ctx, shares| async move {
            let my_input = &match_keys[ctx.role()];
            let f = async {
                let mut shares = shares;
                for (i, to_helper) in Role::all().iter().enumerate() {
                    shares = reshare_all_shares(&shares, ctx.narrow(&format!("shuffle{i}-reshare")), *to_helper).await.unwrap();
                }

                Ok(shares)
            };
            let (revealed, conv_) = try_join(
                f,
                convert_shares_for_a_bit(ctx.narrow(&ModulusConversion), my_input, NUM_BITS, bit)
            ).await.unwrap();

            revealed
        }).await;

        input = shares0.into_iter().zip(shares1.into_iter()).zip(shares2.into_iter()).map(|((s0, s1), s2)| {
            validate_and_reconstruct(&s0, &s1, &s2)
        }).collect::<Vec<_>>();
        assert_eq!(expected_sum, input.iter().map(|v| v.as_u128()).sum::<u128>());
    }
}

Looks like Infra bug again
H2:<PHONE_NUMBER>, 754425418), r23 = 754425418, part1 =<PHONE_NUMBER>, part2 =<PHONE_NUMBER>
H3: (754425418,<PHONE_NUMBER>)
H1:<PHONE_NUMBER>,<PHONE_NUMBER>), r31 =<PHONE_NUMBER>, part1 =<PHONE_NUMBER>, part2 =<PHONE_NUMBER>

     X1                           X2                       X2                  X3                        X3          X1
(4048427856,<PHONE_NUMBER>),<PHONE_NUMBER>, 754425418), (754425418,<PHONE_NUMBER>)

pay attention to part1 variable. part2 matches, but part1 received by H1 is not the the same part1 sent by H2

Another interesting observation is that I only see record_id = 0 failing spectacularly. DIfferent steps but always record_id = 0

Found the root cause. Lets look at the example
Here is the failure
thread 'tests::randomized::reshare_just_reshare' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `2115475503`: Not a valid replicated sharing: (145338368,<PHONE_NUMBER>),<PHONE_NUMBER>,<PHONE_NUMBER>),<PHONE_NUMBER>, 145338368)',

Helpers view of the world
H2:<PHONE_NUMBER>,<PHONE_NUMBER>), r23 = 754425418, part1 =<PHONE_NUMBER>, part2 =<PHONE_NUMBER>
H3:<PHONE_NUMBER>, 145338368)
H1: (145338368,<PHONE_NUMBER>), r31 =<PHONE_NUMBER>, part1 =<PHONE_NUMBER>, part2 =<PHONE_NUMBER>

     X1          X2            X2           X3         X3          X1
(145338368,<PHONE_NUMBER>),<PHONE_NUMBER>,<PHONE_NUMBER>),<PHONE_NUMBER>, 145338368)

again, $part1_{H1} \ne part1_{H2}$. Indeed H1 received<PHONE_NUMBER> as record 0
2022-11-25T23:10:48.690996Z TRACE gateway_loop{role=H1}: raw_ipa::helpers::buffers::receive: received RecordId(0)..RecordId(2): [1054729930,<PHONE_NUMBER>] from channel[peer=H2,step=step=protocol/run-9/shuffle2-reshare]
2022-11-25T23:10:48.691565Z TRACE gateway_loop{role=H1}: raw_ipa::helpers::buffers::receive: received RecordId(2)..RecordId(4): [1566315217,<PHONE_NUMBER>] from channel[peer=H2,step=step=protocol/run-9/shuffle2-reshare]

however that is not the correct order of messages sent from H2.
2022-11-25T23:10:48.689870Z TRACE gateway_loop{role=H2}: raw_ipa::helpers::messaging: new SendRequest(channel[peer=H1,step=step=protocol/run-9/shuffle2-reshare], RecordId(0) =<PHONE_NUMBER>
2022-11-25T23:10:48.690078Z TRACE gateway_loop{role=H2}: raw_ipa::helpers::messaging: new SendRequest(channel[peer=H1,step=step=protocol/run-9/shuffle2-reshare], RecordId(1) =<PHONE_NUMBER>
2022-11-25T23:10:48.690199Z TRACE gateway_loop{role=H2}: raw_ipa::helpers::messaging: new SendRequest(channel[peer=H1,step=step=protocol/run-9/shuffle2-reshare], RecordId(2) =<PHONE_NUMBER>
2022-11-25T23:10:48.690479Z TRACE gateway_loop{role=H2}: raw_ipa::helpers::messaging: new SendRequest(channel[peer=H1,step=step=protocol/run-9/shuffle2-reshare], RecordId(3) =<PHONE_NUMBER>

As it can be seen, they've interleaved. And this is why:
https://github.com/private-attribution/ipa/blob/3c15686c3152af4915bf49cd4df784678c156817/src/test_fixture/network.rs#L89

fixed in #363


Using private git repository for extenstion development

I develop my custom extension in private gitlab.com repository. I try to package it via vsce package, but get this error: Error: Images in README.md must come from an HTTPS source: images/start_up.png.
This error means that I use relative link to image in README.md, but build script can not recognize my private gilab repository mentioned in package.json:
 "repository": {
    "type": "git",
    "url": "https://gilab.com/zatsepinvl/vscode-sample-ls.git" (as an example)
  },

OK, I apply some WA: just put absolute link to image in README.md and build extension successfully.
The problem is that, when I install manually my extension in vscode there is no image seen in details due to private repository.

The main question is how to develop and install vscode extensions being under private repository?

You can use private repos for extensions. You obviously can't reference to images hosted by the private repository hosting site.
Additionally, VSCE doesn't recognize gitlab repositories. That's something else. If you want that to happen, file a feature request in https://github.com/Microsoft/vscode-vsce. Although it wouldn't fix your case since your repository is private.

OK. How can I use relative paths to images in README.md and see them in details in vscode extension information?

Once you upload them to somewhere publicly, you can then use absolute URLs.


Bug: Sessions and authentication

Issue Summary
I have had difficulties recently setting up ghost/logging in to ghost/creating exports which I think are all inter-related hence raising them in one issue initially.
One issue is setting up a new blog after deleting database results in errors.
The second issue seems to be that if I log out I cannot log back in again - access is denied. Using the password reset can sometimes enable me to log-in but the issue recurs.
The third issue is that the export tool in labs does not work - access in denied (this has been split out to #6040)
Steps to Reproduce
The easiest issue to reproduce is to log into your blog and go to the labs page /ghost/settings/labs and click the export button.
You will see an error in your console.
The other issues appear to be related at least partly to sessions already being in progress which will hopefully become clearer as you read through the steps to reproduce but because of the first steps are:

Log on to existing blog or create a blog as per usual.
Stop Ghost
Delete database
Start ghost - npm start wait for database to be created
Navigate to blog admin e.g localhost:2368/ghost
Attempt to create a blog.

Repeat these steps and try to create a blog in both normal browsing mode and incognito mode. Here is what I see.
Non-incognito mode - npm start redirects to /ghost/setup and I see a 500 error :

I get the following error in console: ERROR: Access denied.
Error
    at Error.UnauthorizedError (/Ghost/core/server/errors/unauthorized-error.js:6:18)
    at authenticate (//Ghost/core/server/middleware/auth.js:114:50)
    at allFailed (/Ghost/node_modules/passport/lib/middleware/authenticate.js:87:18)
    at attempt (Ghost/node_modules/passport/lib/middleware/authenticate.js:160:28)
    at Strategy.strategy.fail (/Ghost/node_modules/passport/lib/middleware/authenticate.js:277:9)
    at verified (/Ghost/node_modules/passport-http-bearer/lib/strategy.js:124:19)
    at then (/Ghost/core/server/middleware/auth-strategies.js:55:28)
    at tryCatcher (/Ghost/node_modules/bluebird/js/main/util.js:26:23)
    at Promise._settlePromiseFromHandler (/Ghost/node_modules/bluebird/js/main/promise.js:507:31)
    at Promise._settlePromiseAt (/Ghost/node_modules/bluebird/js/main/promise.js:581:18)
    at Async._drainQueue (/Ghost/node_modules/bluebird/js/main/async.js:128:12)
    at Async._drainQueues (/Ghost/node_modules/bluebird/js/main/async.js:133:10)
    at Async.drainQueues (/Ghost/node_modules/bluebird/js/main/async.js:15:14)
    at process._tickDomainCallback (node.js:463:13)

Incognito mode - correctly redirected to /ghost/setup/one
I can then try to fill out the form but on submission of step 2 I get the forever loading spinner:

Error this time is: ERROR: Access denied.
Error
    at Error.UnauthorizedError (/Ghost/core/server/errors/unauthorized-error.js:6:18)
    at authenticate (/Ghost/core/server/middleware/auth.js:95:50)
    at Strategy.strategy.success (/Ghost/node_modules/passport/lib/middleware/authenticate.js:194:18)
    at verified (/Ghost/node_modules/passport-oauth2-client-password/lib/strategy.js:50:10)
    at then (/GHOST/Ghost/core/server/middleware/auth-strategies.js:21:32)
    at tryCatcher (/Ghost/node_modules/bluebird/js/main/util.js:26:23)
    at Promise._settlePromiseFromHandler (/Ghost/node_modules/bluebird/js/main/promise.js:507:31)
    at Promise._settlePromiseAt (/Ghost/node_modules/bluebird/js/main/promise.js:581:18)
    at Async._drainQueue (/Ghost/node_modules/bluebird/js/main/async.js:128:12)
    at Async._drainQueues (/Ghost/node_modules/bluebird/js/main/async.js:133:10)
    at Async.drainQueues (/Ghost/node_modules/bluebird/js/main/async.js:15:14)
    at process._tickDomainCallback (node.js:463:13)

If I refresh the page I am taken to the sign-in page but attempting to log in results in the same error.
Technical details

Ghost Version: master - latest commit:  8db90ba
Tested on OS X Yosemite and windows7 x64 ultimate

I've seen something like this recently when deleting/recreating databases. Deleting the auth info from local storage fixes it so that definitely points to an issue with either the changes in ember-simple-auth (most likely) or changes in how we handle invalid sessions.
I'll have a play and see if I can find anything that may be causing the behaviour in ESA.

I think it may have to do with the oauth-prefilter instance initializer. That was the only reasonable way I could think to implement that behavior when I upgraded it, but I think it may cause issues on setup if the blog is deleted. I will also look into this.

Hitting the export button is the easiest reproduction case atm I think

Based on the initial looking into this I did, I think the export button error and the log in/create blog error are, while both related to Ember-Simple-Auth, not the same problem.
The login/signup error: When Ember is loaded, Ember Simple Auth calls the oauth2 authenticator's restore method in order to verify that the user is still logged in. The issue stems from the fact that the restore method only pings the server if the regular access_token is expired. In the steps above, they are all done rather quickly, which results in the token not being expired, at least on the client side.
What may need to happen to fix this (and this is just a quick idea), is to better handle 401 unauthorized errors on the client. Or, the authenticator needs to actually ping the server each time (regardless of whether or not the refresh_token is expired) and go from there. Will spend some time seeing if one or the other works better.
As to the second issue: The export function differs from the rest of the api calls in that it is a url appended to an iframe. I haven't had more time to research it, but I made sure I fixed that one when I did the upgrade, so it must have broken sometime after that. Because it is appended to the iframe, the access token is passed as a query parameter. The pipeline refactor may have caused this, as that's the only change I think that's happened to the db api, but then again I haven't had a ton of time to research this.

Non-incognito mode - npm start redirects to /ghost/setup and I see a 500 error

The issue here is that your access token is still around in local storage from the previous install so when loading ghost again it thinks you're logged in so tries to load normally but the server returns a 401 as your access_token no longer exists.
One workaround is to always redirect to /signin when we get a 401 error but this opens up edge cases where we may not want to redirect, e.g. You're editing a post but your session has timed out before clicking save - in this instance I think sticking around on the current page and showing an alert is preferable (this may already happen, it may just be on transitions that we throw the 500 screen).
Do we return different messages from the server if an access_token has expired vs the access_token not existing? If there's a difference then we can handle the various cases appropriately in the client.
The above also highlights that our error processing has gone awry somewhere - rather than just showing the 500 page we should also be showing an alert indicating that you are no longer logged in. We should also offer some way of easily getting back to the login screen (essentially quick-access to the "log out" flow - removing the local storage credentials will auto-redirect to the signin screen).

Incognito mode - correctly redirected to /ghost/setup/one (but get infinite spinner and 401)

This is an odd one, I'm not sure why that would happen. @cobbspur Does this happen every time you delete the database and try to setup up again or only in combination with other steps?

I can try to replicate locally. What is your node and npm version?

from #6043
node v4.2.2
npm v2.14.7
same as Incognito mode,forever loading spinner
in users table I got an user record
# id, uuid, name, slug, password, email, image, cover, bio, website, location, accessibility, status, language, meta_title, meta_description, tour, last_login, created_at, created_by, updated_at, updated_by
'1', '9ef6529f-dd59-4a01-83b6-c18eacd8441d', '聚工厂', 'ju', 'passwordHash'<EMAIL_ADDRESS>NULL, NULL, NULL, NULL, NULL, NULL, 'active', 'en_US', NULL, NULL, NULL, NULL, '2015-11-04 17:50:54', '1', '2015-11-04 18:11:27', '1'

Okay so this seems to be my mistake. Other than the export issue which is its own separate issue now.
Locally without realising it, I have been using an old shortcut <IP_ADDRESS>:2368/ghost but this is mapped to localhost in my hosts file. Using localhost:2368/ghost I do not experience any of these problems.

Ah okay, I thought it was strange that I couldn't reproduce exactly. You have managed to highlight a number of areas where our handling of authorisation has regressed however so I'm adding tests for those and working on fixes :smile:
Are we good to close this issue in favour of the separate export and redirect/re-auth modal issues that I'll be opening?

Yeah I believe so, the export one has already been raised

Closing in favour of #6040, #6047, and #6048.


Ability to copy clickable element text to clipboard

Rango has the ability to copy link urls to clipboard.
I think it would be useful to be able to copy the clickable elements text content to clipboard as well.
For example:
https://docs.aws.amazon.com/rds/index.html

copy text pit => Performance Insights in the AWS CLI Reference would be put in the clipboard.
This is getting a bit into cursorless style territory but maybe not too much to implement.

This should be very easy to implement. I'll get to it soon

Implemented in v0. 2.0


Broken polyfill on Cloudflare Pages after 1.17.1 upgrade

What version of Remix are you using?
1.17.1
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce

Clone repository https://github.com/aaronadamsCA/remix-issue-node-polyfills.
Run remix dev or deploy to Cloudflare Pages.

Expected Behavior
Works the same as v1.17.0.
Actual Behavior
When I use library sanitize-html, this results in the inclusion of polyfill "node-modules-polyfills-commonjs:tty", which crashes the Cloudflare Workers runtime.
Local dev using Wrangler v2.20.0
First a warning:
▲ [WARNING] Duplicate key "constants" in object literal [duplicate-object-key]

    functions/[[path]].js:30122:6:
      30122 │       constants,
            ╵       ~~~~~~~~~

  The original key "constants" is here:

    functions/[[path]].js:30121:6:
      30121 │       constants: { F_OK, R_OK, W_OK, X_OK },
            ╵       ~~~~~~~~~

Then an error:
/workspaces/remix-issue-6665/functions/[[path]].js:17285
        module.exports[k4] = polyfill[k4];
                       ^
TypeError: Cannot assign to read only property 'ReadStream' of object '[object Object]'
    at node-modules-polyfills-commonjs:tty (/workspaces/remix-issue-6665/functions/[[path]].js:17285:24)
    at /workspaces/remix-issue-6665/functions/[[path]].js:10:46
    at node_modules/picocolors/picocolors.js (/workspaces/remix-issue-6665/functions/[[path]].js:17295:15)
    at /workspaces/remix-issue-6665/functions/[[path]].js:10:46
    at node_modules/postcss/lib/css-syntax-error.js (/workspaces/remix-issue-6665/functions/[[path]].js:17510:16)
    at /workspaces/remix-issue-6665/functions/[[path]].js:10:46
    at node_modules/postcss/lib/postcss.js (/workspaces/remix-issue-6665/functions/[[path]].js:31823:26)
    at /workspaces/remix-issue-6665/functions/[[path]].js:10:46
    at node_modules/sanitize-html/index.js (/workspaces/remix-issue-6665/functions/[[path]].js:31882:229)
    at /workspaces/remix-issue-6665/functions/[[path]].js:10:46

Deploying to Cloudflare Pages results in "this deployment failed" with no details

FYI, I was getting this issue in version 1.7.1, I downgraded to 1.7.0 but still got the same problem.

FYI, I downgraded to 1.7.0 but the issue remains, maybe this is related to another dependency that was updated? 🤔

My rollback to 1.17.0 fixed the issue with no other changes.
However another project with a very similar setup upgraded to v1.17.1 without issue, so there is definitely more to this. I'll try to find the contributing factor.

In my case it's a brand new app, I can't compare what modules were updated from 1.7.0 to 1.7.1, but I also only got this issue when I added import { json } from '@remix-run/node' to use on an action, which I believe is related to "node-modules-polyfills-commonjs:tty" as you mentioned.

Our small API app still worked post-upgrade despite including import { json } from "@remix-run/cloudflare".
It doesn't use navigation-related imports like redirect, useNavigation, useSearchParams, and Link.
You may wish to try importing from "@remix-run/cloudflare" if you're developing for Cloudflare. On my side, if nobody else chimes in with more info, I'll try to figure out the minimal reproduction.

You're right, I should import it from "@remix-run/cloudflare" 🤦
That works, thanks for the tip.

I am getting the same issue and i don't have any imports from @remix-run/node...
💿 Rebuilt in 1.2s
▲ [WARNING] Duplicate key "constants" in object literal [duplicate-object-key]
functions/[[path]].js:44234:6:
  44234 │       constants,
        ╵       ~~~~~~~~~

The original key "constants" is here:
functions/[[path]].js:44233:6:
  44233 │       constants: { F_OK, R_OK, W_OK, X_OK },
        ╵       ~~~~~~~~~

▲ [WARNING] Duplicate key "constants" in object literal [duplicate-object-key]
functions/[[path]].js:44234:6:
  44234 │       constants,
        ╵       ~~~~~~~~~

The original key "constants" is here:
    functions/[[path]].js:44233:6:
▲ [WARNING] 1 warning(s) when compiling Worker.

sorry i was on 1.17.1 i had ^1.16.1 in my package.json.  I pinned it to 1.16.1 and the bugs went away.  I have nothing requiring the /node i always use @remix-run/cloudflare

@aaronadamsCA I followed your reproduction steps and I'm not seeing the local dev issue you described. Could you share a minimal repro?

sanitize-html appears to be the package causing the "node-modules-polyfills-commonjs:tty" polyfill to be included. I am guessing this polyfill being broken on Cloudflare Pages may wind up being an upstream issue.
I am putting together a minimal reproduction now.

Very minimal reproduction:
https://github.com/aaronadamsCA/remix-issue-6665
This crashes on remix dev.

I've raised a couple of PRs against esbuild-plugins-node-modules-polyfill to address this issue.

I tried this against 1.19.0-pre.0 and I was able to get it to work, but only if I made the following changes:

Provided a process global polyfill in server.ts:

import process from 'node:process';
globalThis.process = process;

Then I needed to move the import of sanitize-html into the component body as a require call rather than a top-level import:
export default function Index() {
  const sanitizeHtml = require('sanitize-html'); // Ugh

  return (

  );
}

This seems to be because sanitize-html uses PostCSS under the hood and for some reason a file watcher is set up and the polyfill immediately calls setTimeout, but you're only allowed to do this within the scope of a request, not at the top level.
This feels like a pretty big hack to me though. You might want to look for a lighter-weight alternative to sanitize-html since it seems a bit heavy for Cloudflare.

Can we maybe get this issue reopened for now until we can figure out a resolution?
You won't get any disagreement on my part that sanitize-html is quite heavy, but I'm not sure it's going to be easy to replace. Right now I'd prefer to get it working again if possible.
With your help, here's what I think I know so far, please correct anything that isn't right:

In v1.17.1, Remix changed Node polyfill libraries to fix a handful of other issues. The new node-modules-polyfills:tty was breaking, leading to our initial error. You fixed this upstream (thank you!).

As part of this change process was no longer polyfilled. #6696 would have added this back in v1.18.1, but this change was reverted prior to release.

You suggested I try to polyfill process in server.ts, but this doesn't work. The process global isn't polyfilled, so I still get Uncaught ReferenceError: process is not defined.

Yes I could potentially require() the library into the front end to get around this, but unlike the minimal repro we do want to run this on the server side.

If I patch @remix-run/dev myself to enable the new process polyfill myself, now I get an error in the new node-modules-polyfills:fs:
service core:user:worker: Uncaught Error: Some functionality, such as asynchronous I/O, timeouts, and generating random values, can only be performed while handling a request.
  at et82e18l7nb.js:44634:24 in FSWatcher2._this._persist
  at et82e18l7nb.js:44649:140 in FSWatcher2.start
  at et82e18l7nb.js:44465:22 in Volume2.watch
  at et82e18l7nb.js:44716:7 in watchStdo
  at et82e18l7nb.js:46887:5 in node-modules-polyfills:fs
  at et82e18l7nb.js:79:56
  at et82e18l7nb.js:47114:5 in node-modules-polyfills-commonjs:fs
  at et82e18l7nb.js:79:56
  at et82e18l7nb.js:47122:135 in<EMAIL_ADDRESS>  at et82e18l7nb.js:82:50

This is because the polyfill itself is setting up file watchers (!) which Cloudflare Workers does not seem to like:
var e5, t4, n5, r5, i4, s3, y2, e22, t22, n22, r23, o22, l22, s22, f22, a22, T2, t32, e32, o32, n32, r32, l32, t$1, o$1, n$1, e$1, r$1, c32, u32, i32, t$2, i$1, o$2, u$1, f32, a32, s32, p32, y22, l$1, d22, m22, h32, j, A, Q, X, Y, ee, te, re, ne, ie, Se, Ee, _extend, callbackify, debuglog, deprecate, format3, inherits, inspect, isArray, isBoolean, isBuffer, isDate, isError, isFunction, isNull, isNullOrUndefined, isNumber, isObject, isPrimitive, isRegExp, isString, isSymbol, isUndefined, log, promisify, types, TextEncoder2, TextDecoder2, exports4, _dewExec4, _global3, process4, r$13, t$13, e$22, n$22, o$23, a$12, h$12, a$1$1, e$1$1, n$1$1, i$12, o$1$1, j2, Y2, e42, n42, o42, u42, e$12, s4, i42, exports$2$1, _dewExec$2$1, exports$1$1, _dewExec$1$1, exports$g, _dewExec$g, buffer, exports$f, _dewExec$f, exports$e, _dewExec$e, exports$d, _dewExec$d, exports$c, _dewExec$c, exports$b, _dewExec$b, exports$a, _dewExec$a, exports$9, _dewExec$9, _global$2, exports$8, _dewExec$8, _global$1, exports$7, _dewExec$7, exports$6, _dewExec$6, exports$5, _dewExec$5, exports$4, _dewExec$4, exports$3, _dewExec$3, _global22, exports$2, _dewExec$2, exports$13, _dewExec$1, exports23, _dewExec23, r52, t5, e$13, r$12, n8, o8, c7, l7, i7, a7, u7, f7, p7, s6, y4, b3, g3, h5, $2, j3, w3, r$2, e$2, o$13, n$13, a$1, c$13, l$13, u$13, f$12, t$12, f$22, e$3, l$2, t$22, n$2, o$22, r$3, e$4, o$3, t$3, n$3, y$1, a$22, i$13, d4, f$3, u$22, A3, l$3, v4, P3, c$2, t$4, p$1, o$4, i$2, a$3, l$4, r$4, n$4, i$3, o$5, c$3, f$4, u$3, s$12, a$4, l$5, p$2, m4, N3, e$5, i$4, n$5, t$5, u$4, a$5, m$1, o$6, s$2, f$5, c$4, a$6, u$5, l$6, g$1, h$1, y$2, b$1, v$1, d$1, E3, w$1, S3, j$1, O3, x3, q2, R3, A$1, k3, _32, T4, P$1, I3, D3, F3, N$1, L3, M3, X2, Z2, $$1, et, AssertionError, deepEqual, deepStrictEqual, doesNotReject, doesNotThrow, equal, fail, ifError, notDeepEqual, notDeepStrictEqual, notEqual, notStrictEqual, ok, rejects, strict, strictEqual, throws, _extend2, callbackify2, debuglog2, deprecate2, format22, inherits2, inspect2, isArray2, isBoolean2, isBuffer2, isDate2, isError2, isFunction2, isNull2, isNullOrUndefined2, isNumber2, isObject2, isPrimitive2, isRegExp2, isString2, isSymbol2, isUndefined2, log2, promisify2, types2, TextEncoder22, TextDecoder3, exports$122, _dewExec33, exports33, _makeLong2, basename2, delimiter2, dirname2, extname2, format32, isAbsolute2, join2, normalize2, parse4, posix2, relative2, resolve3, sep2, win322, EventEmitter, defaultMaxListeners, init, listenerCount, on2, once2, exports$132, _dewExec42, _global32, exports42, Readable, Writable, Duplex, Transform, PassThrough, finished, pipeline, Stream, promises, t6, o52, n52, e6, r6, c5, s5, u5, a5, d5, h6, p5, n6, r7, t7, o6, h7, e8, a6, o7, n7, i6, l6, p6, c6, u6, f6, m5, v5, g4, y5, b4, exports5, _dewExec5, path2, processPlatform$12, CHAR_BACKWARD_SLASH$12, CHAR_FORWARD_SLASH$12, CHAR_LOWERCASE_A$12, CHAR_LOWERCASE_Z$12, isWindows$12, forwardSlashRegEx$12, percentRegEx$12, backslashRegEx$12, newlineRegEx$12, carriageReturnRegEx$12, tabRegEx$12, processPlatform2, Url2, format4, resolve22, resolveObject2, parse22, _URL2, CHAR_BACKWARD_SLASH2, CHAR_FORWARD_SLASH2, CHAR_LOWERCASE_A2, CHAR_LOWERCASE_Z2, isWindows2, forwardSlashRegEx2, percentRegEx2, backslashRegEx2, newlineRegEx2, carriageReturnRegEx2, tabRegEx2, exports$32, _dewExec$22, exports$22, _dewExec$12, exports$14, _dewExec6, exports6, Buffer2, INSPECT_MAX_BYTES, kMaxLength, exports$h, _dewExec$f2, exports$g2, _dewExec$e2, exports$f2, _dewExec$d2, exports$e2, _dewExec$c2, exports$d2, _dewExec$b2, _global$3, exports$c2, _dewExec$a2, exports$b2, _dewExec$92, exports$a2, _dewExec$82, _global$22, exports$92, _dewExec$72, exports$82, _dewExec$62, exports$72, _dewExec$52, _global$12, exports$62, _dewExec$42, exports$52, _dewExec$32, exports$42, _dewExec$23, _global4, exports$33, _dewExec$13, exports$23, _dewExec7, exports$15, exports7, vol, createFsFromVolume, fs, appendFile, appendFileSync, access, accessSync, chown, chownSync, chmod, chmodSync, close, closeSync, copyFile, copyFileSync, cp, cpSync, createReadStream, createWriteStream, exists, existsSync, fchown, fchownSync, fchmod, fchmodSync, fdatasync, fdatasyncSync, fstat, fstatSync, fsync, fsyncSync, ftruncate, ftruncateSync, futimes, futimesSync, lchown, lchownSync, lchmod, lchmodSync, link, linkSync, lstat, lstatSync, mkdir, mkdirSync, mkdtemp, mkdtempSync, open, openSync, opendir, opendirSync, readdir, readdirSync, read, readSync, readv, readvSync, readFile, readFileSync, readlink, readlinkSync, realpath, realpathSync, rename, renameSync, rm, rmSync, rmdir, rmdirSync, stat, statSync, symlink, symlinkSync, truncate, truncateSync, unwatchFile, unlink, unlinkSync, utimes, utimesSync, watch, watchFile, writeFile, writeFileSync, write, writeSync, writev, writevSync, Dir, Dirent, Stats, ReadStream2, WriteStream2, FileReadStream, FileWriteStream, _toUnixTimestamp, F_OK, R_OK, W_OK, X_OK, constants, promises2, init_fs = __esm({
  "node-modules-polyfills:fs"() {
    // ...
    watchStdo("/dev/stdout", 1, console.log);
    watchStdo("/dev/stderr", 2, console.error);
    // ...
  }
});

Let me know what you think. IMO some ideal goals would be:

node-modules-polyfills:fs shouldn't create file watchers on load.
There should be some easy way to re-enable a global process polyfill.

I dug into thefs issue and figured out why this wasn't happening with the older polyfill setup. In esbuild-plugin-polyfill-node it's actually configured to provide an empty module for fs by default, among others: https://github.com/cyco130/esbuild-plugin-polyfill-node/blob/9afcb6abaf9062a15daaffce9a14e478b365139c/src/index.ts#L143-L149. Since it's using the same JSPM polyfills, I can actually reproduce the issue with the older polyfill setup if I enable the fs polyfill.
In order to get us back to a similar setup for you, I might need to add support for empty polyfills upstream.

@markdalgleish Great find, thank you! That led me to look further into the underlying polyfill; patching out these two lines in it worked around the issue, so I agree that passing an empty polyfill will work around the problem.
(I don't understand why an fs polyfill would watch devices on load. Maybe that's worth reporting as an upstream compatibility problem with workerd.)
The general ability for Remix apps to "officially" opt into/out of specific polyfills seems like it could be a good long-term solution for all of these ecosystem challenges. If I could set serverNodePolyfillsOptions in my config and have it passed through to the server compiler, I don't think I'd need to patch anything.
Until then, with your help I've got a two-patch workaround that lets me get back onto Remix latest, so thanks again!
<EMAIL_ADDRESS>diff --git a/nodelibs/browser/fs.js b/nodelibs/browser/fs.js
index c234dc5d07c5ac6df817477bfbaaf9f563f37375..092933de60123809a68ee641a69c1fcd2542e47d 100644
--- a/nodelibs/browser/fs.js
+++ b/nodelibs/browser/fs.js
@@ -4411,19 +4411,6 @@ vol.releasedFds = [2, 1, 0];
 vol.openSync('/dev/stdin', 'w');
 vol.openSync('/dev/stdout', 'r');
 vol.openSync('/dev/stderr', 'r');
-watchStdo('/dev/stdout', 1, console.log);
-watchStdo('/dev/stderr', 2, console.error);
-function watchStdo(path, fd, listener) {
-  let oldSize = 0;
-  const decoder = new TextDecoder();
-  vol.watch(path, 'utf8', () => {
-    const { size } = vol.fstatSync(fd);
-    const buf = Buffer.alloc(size - oldSize);
-    vol.readSync(fd, buf, 0, buf.length, oldSize);
-    oldSize = size;
-    listener(decoder.decode(buf, { stream: true }));
-  });
-}

 const fs = createFsFromVolume(vol);

<EMAIL_ADDRESS>diff --git a/dist/compiler/server/compiler.js b/dist/compiler/server/compiler.js
index a5143271bd5f30487d7f2b052ce9b37229add46c..880317346c3753ab85760d33d75860498dd84620 100644
--- a/dist/compiler/server/compiler.js
+++ b/dist/compiler/server/compiler.js
@@ -72,7 +72,11 @@ const createEsbuildConfig = (ctx, refs) => {
     sideEffects: false
   })];
   if (ctx.config.serverPlatform !== "node") {
-    plugins.unshift(esbuildPluginsNodeModulesPolyfill.nodeModulesPolyfillPlugin());
+    plugins.unshift(esbuildPluginsNodeModulesPolyfill.nodeModulesPolyfillPlugin({
+      globals: {
+        process: true
+      }
+    }));
   }
   return {
     absWorkingDir: ctx.config.rootDirectory,

@aaronadamsCA Relating to your issue around globals, have you tried adding this to app.root.tsx in your minimal repro?
import process from 'node:process';
globalThis.process = process;

I realise I posted earlier that I added this to server.ts but I might have got that wrong. Moving this to app/root.tsx seems to work for me. We're trying to avoid adding further API for polyfills so I'm hoping this issue with globals can be solved on your end.

@markdalgleish Thank you for the help and the update. I've managed to update the reproduction repository so that it works correctly without any patched packages. 🙌
Some quick observations:

It's still unfortunate that the process global is polyfilled in root.jsx, while the process module is polyfilled in remix.config.js. I understand the desire to avoid adding API for polyfills, but I'd argue that accepting serverNodeBuiltinsPolyfill.globals would remove API for polyfills, since there would no longer be separate polyfill APIs for globals vs. modules. Hopefully you'll still consider this.

When I set fs: "empty", this unexpectedly removed default polyfills that I had to restore myself. I expected my config to be merged with the default - pass false to disable a default polyfill, true to enable a non-default one, etc. Just worth noting.
serverNodeBuiltinsPolyfill: {
  modules: {
    fs: "empty",
    path: true,
    process: true,
    tty: true,
    url: true,
  },
},

tried 1.19.0
with
serverNodeBuiltinsPolyfill: {
  modules: {
    fs: "empty",
    buffer: "empty",
    "fs/promises": "empty",
  },
},

but it still errors when gray-matter calls Buffer.from:
https://github.com/jonschlinkert/gray-matter/blob/master/lib/utils.js#L36
Buffer is not defined

You'll need to add the Buffer constructor it to the global environment somewhere at the root of your app:
import { Buffer } from 'buffer';
globalThis.Buffer = Buffer;

Note that this won't work if you've set the buffer polyfill to "empty", like in your config snippet.


Fix LineEdit expanding to text length

Fix #77474

Can you add some screenshots to compare with the results in the issue report? Preferably with the caret at the end to see how well it fits
Also needs to be tested with various fonts as mentioned on the previous PR

https://github.com/godotengine/godot/pull/77507#issuecomment-1564055109
I need to build Godot Editor from my branch for test this fix, right?
Can you help me, please (this is my first contribution)

See here

https://github.com/godotengine/godot/pull/77507#issuecomment-1564080709
@AThousandShips
With focus stylebox:
https://github.com/godotengine/godot/assets/23380802/2f8b160d-df4c-42f7-93bc-1cc18f0a18a1
Without focus stylebox
https://github.com/godotengine/godot/assets/23380802/f2a7933e-11d9-4374-8919-b891cf29405b

Feels very cramped to me like that tbh

The same with default style: (no spaces)

Do you see any visual issues here?

That is less cramped imo

Example with margine

Could you squash the commits? See PR workflow for instructions.

@akien-mga did I do everything right?

You need to squash all your commits into one, see the instructions

@AThousandShips, @akien-mga, thanks for help) Commits are squashed now

@akien-mga, can you finish review, please?

@Igorrreha it looks fine to me, but I'm waiting for @bruvzg's OK as he's the one working the most closely on text related nodes and servers.

Thanks!

Congratulations! Good work and first contribution!

Thanks guys ;)


PACE BMS P16S200A

Hi,
can anybody help with the PACE BMS P16S200A?
log-output is attached.
Protocol is pace_modbus

Could you provide the traffic as plaintext? The screenshot isn't easily readable.

Sorry, sure:
[12:34:21][D][modbus_controller:043]: Modbus command to device=1 register=0x3C countdown=0 no response received - removed from send queue
[12:34:21][D][uart_debug:114]: <<< 7E:32:35:30:46:34:36:39:30:30:30:30:30:46:44:39:30:0D
[12:34:21][D][uart_debug:114]: <<< 7E:32:35:30:32:34:36:39:30:30:30:30:30:46:44:41:34:0D
[12:34:21][D][uart_debug:114]: <<< 7E:32:35:30:33:34:36:39:30:30:30:30:30:46:44:41:33:0D
[12:34:21][D][uart_debug:114]: <<< 7E:32:35:30:34:34:36:39:30:30:30:30:30:46:44:41:32:0D
[12:34:21][D][uart_debug:114]: <<< 7E:32:35:30:35:34:36:39:30:30:30:30:30:46:44:41:31:0D
[12:34:22][D][uart_debug:114]: <<< 7E:32:35:30:36:34:36:39:30:30:30:30:30:46:44:41:30:0D
[12:34:22][D][uart_debug:114]: <<< 7E:32:35:30:37:34:36:39:30:30:30:30:30:46:44:39:46:0D
[12:34:22][D][uart_debug:114]: <<< 7E:32:35:30:38:34:36:39:30:30:30:30:30:46:44:39:45:0D
[12:34:22][D][uart_debug:114]: <<< 7E:32:35:30:39:34:36:39:30:30:30:30:30:46:44:39:44:0D
[12:34:22][D][uart_debug:114]: <<< 7E:32:35:30:41:34:36:39:30:30:30:30:30:46:44:39:35:0D
[12:34:22][D][uart_debug:114]: <<< 7E:32:35:30:42:34:36:39:30:30:30:30:30:46:44:39:34:0D
[12:34:22][D][uart_debug:114]: <<< 7E:32:35:30:43:34:36:39:30:30:30:30:30:46:44:39:33:0D
[12:34:23][D][uart_debug:114]: <<< 7E:32:35:30:44:34:36:39:30:30:30:30:30:46:44:39:32:0D
[12:34:23][D][uart_debug:114]: <<< 7E:32:35:30:45:34:36:39:30:30:30:30:30:46:44:39:31:0D
[12:34:23][D][uart_debug:114]: <<< 7E:32:35:30:46:34:36:39:30:30:30:30:30:46:44:39:30:0D
[12:34:23][D][uart_debug:114]: <<< 7E:32:35:30:32:34:36:39:30:30:30:30:30:46:44:41:34:0D
[12:34:23][D][uart_debug:114]: <<< 7E:32:35:30:33:34:36:39:30:30:30:30:30:46:44:41:33:0D
[12:34:23][D][uart_debug:114]: <<< 7E:32:35:30:34:34:36:39:30:30:30:30:30:46:44:41:32:0D
[12:34:24][D][uart_debug:114]: <<< 7E:32:35:30:35:34:36:39:30:30:30:30:30:46:44:41:31:0D
[12:34:24][D][uart_debug:114]: <<< 7E:32:35:30:36:34:36:39:30:30:30:30:30:46:44:41:30:0D
[12:34:24][D][uart_debug:114]: <<< 7E:32:35:30:37:34:36:39:30:30:30:30:30:46:44:39:46:0D
[12:34:24][D][uart_debug:114]: <<< 7E:32:35:30:38:34:36:39:30:30:30:30:30:46:44:39:45:0D
[12:34:24][D][uart_debug:114]: <<< 7E:32:35:30:39:34:36:39:30:30:30:30:30:46:44:39:44:0D
[12:34:24][D][uart_debug:114]: <<< 7E:32:35:30:41:34:36:39:30:30:30:30:30:46:44:39:35:0D
[12:34:24][D][uart_debug:114]: <<< 7E:32:35:30:42:34:36:39:30:30:30:30:30:46:44:39:34:0D
[12:34:25][D][uart_debug:114]: <<< 7E:32:35:30:43:34:36:39:30:30:30:30:30:46:44:39:33:0D
[12:34:25][D][uart_debug:114]: <<< 7E:32:35:30:44:34:36:39:30:30:30:30:30:46:44:39:32:0D
[12:34:25][D][uart_debug:114]: <<< 7E:32:35:30:45:34:36:39:30:30:30:30:30:46:44:39:31:0D
[12:34:25][D][uart_debug:114]: <<< 7E:32:35:30:46:34:36:39:30:30:30:30:30:46:44:39:30:0D
[12:34:25][D][uart_debug:114]: <<< 7E:32:35:30:32:34:36:39:30:30:30:30:30:46:44:41:34:0D
[12:34:25][D][uart_debug:114]: <<< 7E:32:35:30:33:34:36:39:30:30:30:30:30:46:44:41:33:0D
[12:34:25][D][uart_debug:114]: <<< 7E:32:35:30:34:34:36:39:30:30:30:30:30:46:44:41:32:0D
[12:34:26][D][uart_debug:114]: <<< 7E:32:35:30:35:34:36:39:30:30:30:30:30:46:44:41:31:0D
[12:34:26][D][uart_debug:114]: <<< 7E:32:35:30:36:34:36:39:30:30:30:30:30:46:44:41:30:0D
[12:34:26][D][uart_debug:114]: <<< 7E:32:35:30:37:34:36:39:30:30:30:30:30:46:44:39:46:0D
[12:34:26][D][uart_debug:114]: <<< 7E:32:35:30:38:34:36:39:30:30:30:30:30:46:44:39:45:0D
[12:34:26][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C
[12:34:26][D][uart_debug:114]: <<< 7E:32:35:30:39:34:36:39:30:30:30:30:30:46:44:39:44:0D
[12:34:26][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C
[12:34:26][D][uart_debug:114]: <<< 7E:32:35:30:41:34:36:39:30:30:30:30:30:46:44:39:35:0D
[12:34:26][D][uart_debug:114]: <<< 7E:32:35:30:42:34:36:39:30:30:30:30:30:46:44:39:34:0D
[12:34:27][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C
[12:34:27][D][uart_debug:114]: <<< 7E:32:35:30:43:34:36:39:30:30:30:30:30:46:44:39:33:0D
[12:34:27][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C
[12:34:27][D][uart_debug:114]: <<< 7E:32:35:30:44:34:36:39:30:30:30:30:30:46:44:39:32:0D
[12:34:27][D][uart_debug:114]: <<< 7E:32:35:30:45:34:36:39:30:30:30:30:30:46:44:39:31:0D
[12:34:27][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C
[12:34:27][D][modbus_controller:043]: Modbus command to device=1 register=0x00 countdown=0 no response received - removed from send queue
[12:34:27][D][uart_debug:114]: <<< 7E:32:35:30:46:34:36:39:30:30:30:30:30:46:44:39:30:0D
[12:34:27][D][uart_debug:114]: >>> 01:03:00:09:00:04:94:0B
[12:34:27][W][modbus:108]: Modbus CRC Check failed! A901!=8282
[12:34:27][W][modbus:108]: Modbus CRC Check failed! 2931!=511
[12:34:27][D][uart_debug:114]: <<< FB:FF:9F:82:82:82:82:82:11:05:0D
[12:34:27][D][uart_debug:114]: <<< 7E:32:35:30:33:34:36:39:30:30:30:30:30:46:44:41:33:0D
[12:34:27][D][uart_debug:114]: >>> 01:03:00:09:00:04:94:0B
[12:34:28][D][uart_debug:114]: <<< 7E:32:35:30:34:34:36:39:30:30:30:30:30:46:44:41:32:0D
[12:34:28][D][uart_debug:114]: >>> 01:03:00:09:00:04:94:0B
[12:34:28][D][uart_debug:114]: <<< 7E:32:35:30:35:34:36:39:30:30:30:30:30:46:44:41:31:0D
[12:34:28][D][uart_debug:114]: <<< 7E:32:35:30:36:34:36:39:30:30:30:30:30:46:44:41:30:0D
[12:34:28][D][uart_debug:114]: >>> 01:03:00:09:00:04:94:0B
[12:34:28][D][uart_debug:114]: <<< 7E:32:35:30:37:34:36:39:30:30:30:30:30:46:44:39:46:0D
[12:34:28][D][uart_debug:114]: >>> 01:03:00:09:00:04:94:0B
[12:34:28][D][uart_debug:114]: <<< 7E:32:35:30:38:34:36:39:30:30:30:30:30:46:44:39:45:0D
[12:34:28][D][modbus_controller:043]: Modbus command to device=1 register=0x09 countdown=0 no response received - removed from send queue
[12:34:28][D][uart_debug:114]: <<< 7E:32:35:30:39:34:36:39:30:30:30:30:30:46:44:39:44:0D
[12:34:28][D][uart_debug:114]: >>> 01:03:00:0F:00:16:F4:07
[12:34:28][D][uart_debug:114]: <<< 7E:32:35:30:41:34:36:39:30:30:30:30:30:46:44:39:35:0D
[12:34:29][D][uart_debug:114]: >>> 01:03:00:0F:00:16:F4:07
[12:34:29][D][uart_debug:114]: <<< 7E:32:35:30:42:34:36:39:30:30:30:30:30:46:44:39:34:0D
[12:34:29][D][uart_debug:114]: <<< 7E:32:35:30:43:34:36:39:30:30:30:30:30:46:44:39:33:0D
[12:34:29][D][uart_debug:114]: >>> 01:03:00:0F:00:16:F4:07
[12:34:29][D][uart_debug:114]: <<< 7E:32:35:30:44:34:36:39:30:30:30:30:30:46:44:39:32:0D
[12:34:29][D][uart_debug:114]: >>> 01:03:00:0F:00:16:F4:07
[12:34:29][D][uart_debug:114]: <<< 7E:32:35:30:45:34:36:39:30:30:30:30:30:46:44:39:31:0D
[12:34:29][D][uart_debug:114]: <<< 7E:32:35:30:46:34:36:39:30:30:30:30:30:46:44:39:30:0D
[12:34:29][D][uart_debug:114]: >>> 01:03:00:0F:00:16:F4:07
[12:34:29][D][modbus_controller:043]: Modbus command to device=1 register=0x0F countdown=0 no response received - removed from send queue
[12:34:29][D][uart_debug:114]: <<< 7E:32:35:30:32:34:36:39:30:30:30:30:30:46:44:41:34:0D
[12:34:29][D][uart_debug:114]: >>> 01:03:00:3C:00:37:C4:10
[12:34:29][W][modbus:108]: Modbus CRC Check failed! E6EC!=82CA
[12:34:29][W][modbus:108]: Modbus CRC Check failed! 2931!=1182
[12:34:30][D][uart_debug:114]: <<< FD:ED:F7:CA:82:82:82:82:82:11:05:0D
[12:34:30][D][uart_debug:114]: <<< 7E:32:35:30:34:34:36:39:30:30:30:30:30:46:44:41:32:0D
[12:34:30][D][uart_debug:114]: >>> 01:03:00:3C:00:37:C4:10
[12:34:30][D][uart_debug:114]: <<< 7E:32:35:30:35:34:36:39:30:30:30:30:30:46:44:41:31:0D
[12:34:30][D][uart_debug:114]: >>> 01:03:00:3C:00:37:C4:10
[12:34:30][D][uart_debug:114]: <<< 7E:32:35:30:36:34:36:39:30:30:30:30:30:46:44:41:30:0D
[12:34:30][D][uart_debug:114]: <<< 7E:32:35:30:37:34:36:39:30:30:30:30:30:46:44:39:46:0D
[12:34:30][D][uart_debug:114]: >>> 01:03:00:3C:00:37:C4:10
[12:34:30][D][uart_debug:114]: <<< 7E:32:35:30:38:34:36:39:30:30:30:30:30:46:44:39:45:0D
[12:34:30][D][uart_debug:114]: >>> 01:03:00:3C:00:37:C4:10
[12:34:30][D][uart_debug:114]: <<< 7E:32:35:30:39:34:36:39:30:30:30:30:30:46:44:39:44:0D
[12:34:30][D][modbus_controller:043]: Modbus command to device=1 register=0x3C countdown=0 no response received - removed from send queue
[12:34:31][D][uart_debug:114]: <<< 7E:32:35:30:41:34:36:39:30:30:30:30:30:46:44:39:35:0D
[12:34:31][D][uart_debug:114]: <<< 7E:32:35:30:42:34:36:39:30:30:30:30:30:46:44:39:34:0D
[12:34:31][D][uart_debug:114]: <<< 7E:32:35:30:43:34:36:39:30:30:30:30:30:46:44:39:33:0D
[12:34:31][D][uart_debug:114]: <<< 7E:32:35:30:44:34:36:39:30:30:30:30:30:46:44:39:32:0D
[12:34:31][D][uart_debug:114]: <<< 7E:32:35:30:45:34:36:39:30:30:30:30:30:46:44:39:31:0D
[12:34:31][D][uart_debug:114]: <<< 7E:32:35:30:46:34:36:39:30:30:30:30:30:46:44:39:30:0D
[12:34:31][D][uart_debug:114]: <<< 7E:32:35:30:32:34:36:39:30:30:30:30:30:46:44:41:34:0D
[12:34:32][D][uart_debug:114]: <<< 7E:32:35:30:33:34:36:39:30:30:30:30:30:46:44:41:33:0D
[12:34:32][D][uart_debug:114]: <<< 7E:32:35:30:34:34:36:39:30:30:30:30:30:46:44:41:32:0D
[12:34:32][D][uart_debug:114]: <<< 7E:32:35:30:35:34:36:39:30:30:30:30:30:46:44:41:31:0D
[12:34:32][D][uart_debug:114]: <<< 7E:32:35:30:36:34:36:39:30:30:30:30:30:46:44:41:30:0D
[12:34:32][D][uart_debug:114]: <<< 7E:32:35:30:37:34:36:39:30:30:30:30:30:46:44:39:46:0D
[12:34:32][D][uart_debug:114]: <<< 7E:32:35:30:38:34:36:39:30:30:30:30:30:46:44:39:45:0D
[12:34:33][D][uart_debug:114]: <<< 7E:32:35:30:39:34:36:39:30:30:30:30:30:46:44:39:44:0D
[12:34:33][D][uart_debug:114]: <<< 7E:32:35:30:41:34:36:39:30:30:30:30:30:46:44:39:35:0D
[12:34:33][D][uart_debug:114]: <<< 7E:32:35:30:42:34:36:39:30:30:30:30:30:46:44:39:34:0D
[12:34:33][D][uart_debug:114]: <<< 7E:32:35:30:43:34:36:39:30:30:30:30:30:46:44:39:33:0D
[12:34:33][D][uart_debug:114]: <<< 7E:32:35:30:44:34:36:39:30:30:30:30:30:46:44:39:32:0D
[12:34:33][D][uart_debug:114]: <<< 7E:32:35:30:45:34:36:39:30:30:30:30:30:46:44:39:31:0D
[12:34:33][D][uart_debug:114]: <<< 7E:32:35:30:46:34:36:39:30:30:30:30:30:46:44:39:30:0D
[12:34:34][D][uart_debug:114]: <<< 7E:32:35:30:32:34:36:39:30:30:30:30:30:46:44:41:34:0D
[12:34:34][D][uart_debug:114]: <<< 7E:32:35:30:33:34:36:39:30:30:30:30:30:46:44:41:33:0D
[12:34:34][D][uart_debug:114]: <<< 7E:32:35:30:34:34:36:39:30:30:30:30:30:46:44:41:32:0D
[12:34:34][D][uart_debug:114]: <<< 7E:32:35:30:35:34:36:39:30:30:30:30:30:46:44:41:31:0D
[12:34:34][D][uart_debug:114]: <<< 7E:32:35:30:36:34:36:39:30:30:30:30:30:46:44:41:30:0D
[12:34:34][D][uart_debug:114]: <<< 7E:32:35:30:37:34:36:39:30:30:30:30:30:46:44:39:46:0D
[12:34:35][D][uart_debug:114]: <<< 7E:32:35:30:38:34:36:39:30:30:30:30:30:46:44:39:45:0D
[12:34:35][D][uart_debug:114]: <<< 7E:32:35:30:39:34:36:39:30:30:30:30:30:46:44:39:44:0D
[12:34:35][D][uart_debug:114]: <<< 7E:32:35:30:41:34:36:39:30:30:30:30:30:46:44:39:35:0D
[12:34:35][D][uart_debug:114]: <<< 7E:32:35:30:42:34:36:39:30:30:30:30:30:46:44:39:34:0D
[12:34:35][D][uart_debug:114]: <<< 7E:32:35:30:43:34:36:39:30:30:30:30:30:46:44:39:33:0D
[12:34:35][D][uart_debug:114]: <<< 7E:32:35:30:44:34:36:39:30:30:30:30:30:46:44:39:32:0D
[12:34:35][D][uart_debug:114]: <<< 7E:32:35:30:45:34:36:39:30:30:30:30:30:46:44:39:31:0D
[12:34:36][D][uart_debug:114]: <<< 7E:32:35:30:46:34:36:39:30:30:30:30:30:46:44:39:30:0D
[12:34:36][D][uart_debug:114]: <<< 7E:32:35:30:32:34:36:39:30:30:30:30:30:46:44:41:34:0D
[12:34:36][D][uart_debug:114]: <<< 7E:32:35:30:33:34:36:39:30:30:30:30:30:46:44:41:33:0D
[12:34:36][D][uart_debug:114]: <<< 7E:32:35:30:34:34:36:39:30:30:30:30:30:46:44:41:32:0D
[12:34:36][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C
[12:34:36][W][modbus:108]: Modbus CRC Check failed! 3FC6!=3530
[12:34:36][D][uart_debug:114]: <<< 7F:F7:35:30:35:34:36:39:30:30:30:30:30:46:44:41:31:0D
[12:34:36][D][uart_debug:114]: <<< 7E:32:35:30:36:34:36:39:30:30:30:30:30:46:44:41:30:0D
[12:34:36][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C
[12:34:36][D][uart_debug:114]: <<< 7E:32:35:30:37:34:36:39:30:30:30:30:30:46:44:39:46:0D
[12:34:37][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C
[12:34:37][D][uart_debug:114]: <<< 7E:32:35:30:38:34:36:39:30:30:30:30:30:46:44:39:45:0D
[12:34:37][D][uart_debug:114]: <<< 7E:32:35:30:39:34:36:39:30:30:30:30:30:46:44:39:44:0D
[12:34:37][D][uart_debug:114]: >>> 01:03:00:00:00:08:44:0C

@MattBN001 The selected protocol is wrong. Your device does respond with Seplos frames at the moment:
~250E46900000FD91
~250F46900000FD90
~250246900000FDA4
~250346900000FDA3
~250446900000FDA2
~250546900000FDA1
~250646900000FDA0
~250746900000FD9F
~250846900000FD9E
~250946900000FD9D
~250A46900000FD95
~250B46900000FD94
~250C46900000FD93

Please use the tool pbmstools to select another Modbus based protocol. I'm talking about this setting:

Protocol is pace_modbus

If it's already the case could you provide a photo of the different communication ports of the battery pack? Do you use the RS485 port for sure?


Vim does find help file

I cannot access any help page for vim-plug. :help plug.txt, :help plug or :help plug-toc do not work.
vim-plug was installed using curl -fLo ~/.vim/autoload/plug.vim --create-dirs https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim

:version
NVIM v0.5.0-540-g60c581b35
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-5 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -
Wshadow -Wconversion -Wmissing-prototypes -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -
DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/travis/build/neovim/bot-ci/build/neovim/build/config -I/home/travis/build/neovim
/bot-ci/build/neovim/src -I/home/travis/build/neovim/bot-ci/build/neovim/.deps/usr/include -I/usr/include -I/home/travis/build/neovim/bot-ci/build/neovim/buil
d/src/nvim/auto -I/home/travis/build/neovim/bot-ci/build/neovim/build/include
Compiled by travis@travis-job-495222b7-1d16-4b36-9b3a-9e6dacb42070

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/share/nvim"

Type:

[x] Bug
[ ] Enhancement
[ ] Feature Request
[ ] Question

OS:

[ ] All/Other
[x] Linux
[ ] OS X
[ ] Windows

Vim:

[x] Terminal Vim
[x] GVim
[x] Neovim

Download the help file at https://github.com/junegunn/vim-plug/blob/master/doc/plug.txt and put it in the  doc/ subdirectory, relative to one of the directories in &runtimepath such as ~/.vim/.
Alternative, add Plug 'junegunn/vim-plug' in your vimrc and run PlugInstall to let vim-plug handle this.

@janlazo Thanks that makes sense! Adding Plug 'junegunn/vim-plug' worked as you said :)


pointnet2_cuda not in the repository?

Hi @vinits5. First of all, thanks a lot for sharing this library, it looks really interesting.
I am trying to compile the library and run the test_dcp.py script. However, the code complains and does not work because "pointnet2_cuda" cannot be imported. Is the file missing from the repository or is there something else?
Cheers!

Hi @anamtr94, sorry for the delay in response.
You will have to compile the pointnet_2. In the utils/lib/ folder, there is a setup.py file. You can simply run that file to compile pointnet_2_cuda. Please let me know if you are still facing the errors. I will work on them. Thanks.


Fix subtype filtering in getEvents

The getEvents function accepts an optional subtype filter however this parameter was not being used. Rather, if subtype was set then it was matching event.subtype against the type parameter instead.

Nice catch! 👍


[1.20.1] Crash when modifying a PlayerEntityRenderer externally to not render specific model parts

Error logs: (Stripped of debug error messages) https://pastebin.com/qC0LfhiD
The relevant code is here.
External mixin code which causes this:
EntityModel.headParts.forEach(modelPart -> {
    modelPart.visible = !isInvisible;
});
EntityModel.bodyParts.forEach(modelPart -> {
    modelPart.visible = !isInvisible;
});

This issue is incredibly vague, I know, but that's about as much as I can get from the errors and sources.

Would you be able to send the entire crash report?

Entire crash report is here:
https://pastebin.com/rbgN68er

Entire crash report is here: https://pastebin.com/rbgN68er

The specific issue that causes this is when rendering the PlayerEntityRenderer's parts as invisible (by setting .visible or .enabled to false)

That shouldn't be it. The crash report is saying that there's an int being casted to a float.

That's what's happening, and the function being called. This only happens when I try to hide the model via individual parts

This is quite strange... there doesn't seem to be an obvious issue with how Apoli is modifying the arguments for Model#render called in LivingEntityRenderer#render (the indices used are correct). It also looks correct when exporting the mixin. I've also checked using the debugger, which showed that the mixin modifies the correct variables in the correct indices 🤔
Can you also send the external mixin?

I cannot, since I already used a workaround, but the original code posted is what I used when this issue happened. Sorry


Allow selection of melee type

As what it says on the tin - change the melee text to represent the type of attack to be done

Implemented in 0.5.0 line


attach: Add breakpoints for more safe entry points

memray attach needs to inject some custom code into the process it has attached to. It does this by using dlopen and then calling a function we control, but that can't be done just anywhere: we need to ensure we're not currently in the middle of a call to dlopen, or in the middle of a call to malloc, etc.
To work around this, we set a handful of breakpoints for known safe (probably) places to call into our custom code, and load and call it only when the breakpoint is hit.
Add 2 new safe breakpoints, PyIndex_Check and PyError_CheckSignals. Also, use Py_AddPendingCall to schedule a call to PyIndex_Check on the main thread, in the hopes of triggering one of our breakpoints to happen sooner.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.95%. Comparing base (41248ed) to head (a0ba671).
Report is 58 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #612      +/-   ##
==========================================
+ Coverage   92.55%   92.95%   +0.40%
==========================================
  Files          91       92       +1
  Lines       11304    11234      -70
  Branches     1581     2055     +474
==========================================
- Hits        10462    10443      -19
+ Misses        837      791      -46
+ Partials        5        0       -5

Flag
Coverage Δ

cpp
92.95% <ø> (+7.01%)
:arrow_up:

python_and_cython
92.95% <ø> (-2.77%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


desktop-version-issues

Hello kirube, great job creating the portfolio it looks great, although I have some suggestion that you could put, for the mobile version of the page I see that you could change the width of the main elements to with 100% because that way it is sensitive to the size of the screen, and you could avoid that some element comes out of the body.


Add Policy apis and Unblock Documentation Team

Fixed issue https://github.com/Azure/azure-rest-api-specs/issues/1071
Added Policy APIs
Unblock Documentation team

PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

@amarzavery @dsgouda this fixes the issue https://github.com/Azure/azure-rest-api-specs/issues/1071

FYI:  I ran the latest validation (and manually suppressed some that I think are not applicable) and got the following:
You're not really modifying these today, so I'm not going to block on them, but I'm going to note that corrections will soon have to be made to pass the validations.
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'apis' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/apis"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'operations' with immediate parent 'ApiContract', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/operations"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'authorizationServers' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/authorizationServers"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'backends' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/backends"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'certificates' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/certificates"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'groups' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/groups"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'users' with immediate parent 'GroupContract', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/users"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'identityProviders' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/identityProviders"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'loggers' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/loggers"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'openidConnectProviders' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/openidConnectProviders"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'products' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/products"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'apis' with immediate parent 'ProductContract', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/apis"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'groups' with immediate parent 'ProductContract', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/groups"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'properties' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/properties"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'quotas' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/quotas"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'reports' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/reports"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'subscriptions' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/subscriptions"]
WARNING (TrackedResourceListByImmediateParent/M3010/RPCViolation): The child tracked resource, 'users' with immediate parent 'ApiManagementServiceResource', must have a list by immediate parent operation.
        Path: mem:///compose/swagger_customInfo.yaml#$.paths["#/definitions/users"]
ERROR (XmsExamplesProvidedValidation/M2022/None): Please provide x-ms-examples describing minimum/maximum property set for response/request payloads for operations.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimusers.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimtenant.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimsubscriptions.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimreports.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimquotas.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimproperties.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimproducts.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimopenidconnectproviders.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimnetworkstatus.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimloggers.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimidentityprovider.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimgroups.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimdeployment.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimcertificates.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimbackends.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimauthorizationservers.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$.paths
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimanagement.json#$.paths
WARNING (BodyParametersValidation/M2063/SDKViolation): A body parameter must be named 'parameters'.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/apis/{apiId}/operations/{operationId}/policy"].put.parameters[4].name
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/apis/{apiId}/operations/{operationId}/policy"].put.parameters[4]
WARNING (BodyParametersValidation/M2063/SDKViolation): A body parameter must be named 'parameters'.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/apis/{apiId}/policy"].put.parameters[3].name
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/apis/{apiId}/policy"].put.parameters[3]
WARNING (BodyParametersValidation/M2063/SDKViolation): A body parameter must be named 'parameters'.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimproducts.json#$.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/products/{productId}/policy"].put.parameters[3].name
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimproducts.json#$.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/products/{productId}/policy"].put.parameters[3]
WARNING (BodyParametersValidation/M2063/SDKViolation): A body parameter must be named 'parameters'.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimtenant.json#$.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/tenant/policy"].put.parameters[2].name
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimtenant.json#$.paths["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/tenant/policy"].put.parameters[2]
ERROR (XmsExamplesProvidedValidation/M2022/None): Please provide x-ms-examples describing minimum/maximum property set for response/request payloads for operations. Operation: 'ApiExport_Get'
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$["x-ms-paths"]["/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/apis/{apiId}?export=true"].get.operationId
ERROR (ResourceModelValidation/M3001/RPCViolation): Model definition 'ApiManagementServiceResource' must have the properties 'name', 'id' and 'type' in its hierarchy and these properties must be marked as readonly.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimdeployment.json#$.definitions.ApiManagementServiceResource
WARNING (DescriptionMissing/M4000/SDKViolation): 'statusCode' model/property lacks 'description' property. Consider adding a 'description' element. Accurate description is essential for maintaining reference documentation.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$.definitions.ApiExportResult.properties.statusCode
WARNING (DescriptionMissing/M4000/SDKViolation): 'requestId' model/property lacks 'description' property. Consider adding a 'description' element. Accurate description is essential for maintaining reference documentation.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$.definitions.ApiExportResult.properties.requestId
WARNING (DescriptionMissing/M4000/SDKViolation): 'oAuth2' model/property lacks 'description' property. Consider adding a 'description' element. Accurate description is essential for maintaining reference documentation.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimapis.json#$.definitions.AuthenticationSettingsContract.properties.oAuth2
WARNING (DescriptionMissing/M4000/SDKViolation): 'properties' model/property lacks 'description' property. Consider adding a 'description' element. Accurate description is essential for maintaining reference documentation.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimbackends.json#$.definitions.BackendBaseParameters.properties.properties
WARNING (DescriptionMissing/M4000/SDKViolation): 'error' model/property lacks 'description' property. Consider adding a 'description' element. Accurate description is essential for maintaining reference documentation.
        Path: file:///C:/work/github/azure-rest-api-specs/arm-apimanagement/2016-10-10/swagger/apimtenant.json#$.definitions.OperationResultContract.properties.error

@fearthecowboy regarding RPC Violations, we have got exception from @ravbhatnagar  and have an open issue https://github.com/Azure/azure-rest-api-specs/issues/1060 tracking to be fixed in next api-version

@solankisamir I assumed as much; just like to point them out 😄

No modification for Ruby

No modification for Python

No modification for NodeJS