Replace valgrind with ASAN/UBSAN, overhaul debug build

Depends on #44
Valgrind is a great tool, but has a lot of runtime overhead -- especially at startup. We make probably hundreds of calls to secvarctl, and therefore invoke valgrind hundreds of times, causing a large amount of time waiting for valgrind to initialize.
This PR adds new support to the Makefile for building with address and undefined behavior sanitizers, which introduce a negligible amount of overhead to running the binary, with the benefit of catching even more problems than valgrind.
This comes with a free rework to how testing/debuild builds are handled:

secvarctl-cov has been renamed to secvarctl-dbg (and corresponding build targets)
make debug is aliased to building the debug binary
all .cov.o objects are now .dbg.o
debug build now enables coverage, ASAN/UBSAN by default
ASAN/UBSAN can be disabled with DISABLE_ASAN=1
debug and release flags have been defined separately:

debug flags now enable -g -O0 by default
release flags now use -s -O2 by default

in a similar vein -s (strip) is no longer enabled on all builds, making debugging stack traces impossible
$(INCLUDES) is now its own variable and not injected into $(CFLAGS) for some reason

NOTE: for the sake of scope, the test runners have been left alone, as those scripts are probably next on my list to clean up a bit. The MEMCHECK option for running with valgrind will be removed in a later PR.
TL;DR - all debug builds include coverage support and memcheck'd by default, and tests now run like 20x faster or something.

Please rebase onto latest guest-devel and I will merge

build fails due to defined_sb_variables being uint8_t and passed into strcmp:
backends/guest/common/util.c: In function ‘is_secure_boot_variable’:
backends/guest/common/util.c:180:34: error: pointer targets in passing argument 1 of ‘strcmp’ differ in signedness [-Werror=pointer-sign]
   if (strcmp(defined_sb_variables[i], var) == 0)
              ~~~~~~~~~~~~~~~~~~~~^~~
In file included from backends/guest/common/util.c:6:
/usr/include/string.h:137:12: note: expected ‘const char *’ but argument is of type ‘const uint8_t *’ {aka ‘const unsigned char *’}
 extern int strcmp (const char *__s1, const char *__s2)
            ^~~~~~

backends/guest/guest_svc_read.c: In function ‘read_path’:
backends/guest/guest_svc_read.c:284:37: error: pointer targets in passing argument 1 of ‘strcmp’ differ in signedness [-Werror=pointer-sign]
          strcmp(defined_sb_variables[i], PK_VARIABLE) == 0))
                 ~~~~~~~~~~~~~~~~~~~~^~~
In file included from backends/guest/guest_svc_read.c:11:
/usr/include/string.h:137:12: note: expected ‘const char *’ but argument is of type ‘const uint8_t *’ {aka ‘const unsigned char *’}
 extern int strcmp (const char *__s1, const char *__s2)
            ^~~~~~
backends/guest/guest_svc_read.c:289:33: error: pointer targets in passing argument 3 of ‘print_variables’ differ in signedness [-Werror=pointer-sign]
             defined_sb_variables[i]);
             ~~~~~~~~~~~~~~~~~~~~^~~
In file included from backends/guest/guest_svc_read.c:17:
./backends/guest/include/common/read.h:64:5: note: expected ‘const char *’ but argument is of type ‘const uint8_t *’ {aka ‘const unsigned char *’}
 int print_variables(const uint8_t *buffer, size_t buffer_size, const char *var_name);
     ^~~~~~~~~~~~~~~

With the following, build finishes and all tests are passing:
diff --git a/backends/guest/common/util.c b/backends/guest/common/util.c
index 9a25198..faef127 100644
--- a/backends/guest/common/util.c
+++ b/backends/guest/common/util.c
@@ -177,7 +177,7 @@ bool is_secure_boot_variable(const char *var)
        int i = 0;

        for (i = 0; i < defined_sb_variable_len; i++) {
-               if (strcmp(defined_sb_variables[i], var) == 0)
+               if (strcmp( (const char *) defined_sb_variables[i], var) == 0)
                        return true;
        }

I have libc version 2.28 btw.

Please rebase onto latest guest-devel and I will merge

I fully bet that GitHub no longer things these histories are related because of the merge, and that is incredibly frustrating that I now will have to do this for every PR. Awesome.


Catch errors when starting the server

When starting the server, we wait indefinitely until the http port file appears, even when the child process has already exited with an error code.
When the server fails with an error code, it would be nice if we could show feedback of this.

Something like https://github.com/ensime/ensime-node/compare/master...raboof:showErrorStartingEnsime ?
(would need to add polling, tests, and actually handling the failed promise - but I'd like to get feedback on the approach first)


Separation artifacts/systems

Hi,
This PR contains an update to separate artifacts and systems, as talked with @ipa-nhg .
This PR also contains a proposal for the .rossystem files. Examples:
---
rossdl_simple_test:
  fromGitRepo: "https://github.com/jane-doe/project_example.git:branch"
  systems:
    system_1:
      nodes: [rossdl_simple_test::image_filter, rossdl_simple_test::consumer]
      connections:
        - [/image_filter/image_out, /consumer/image_in]
        - [/image_filter/description_out, /consumer/description_in]
        - [/camera/rgb/image_raw, /image_filter/image_in]
        - [/consumer/image_out, /other_node/image_in]
      parameters:
        - [/image_filter/description_label, 'image raw']
        - [/*/use_sim_time, True]
    system_2:
      nodes: [rossdl_simple_test::image_filter, rossdl_simple_test::consumer]
      connections:
        - [/image_filter/image_out, /consumer/image_in]
        - [/image_filter/description_out, /consumer/description_in]
      parameters:
        - [/image_filter/description_label, 'image compressed']
        - [/*/use_sim_time, False]

---
system_a:
  fromGitRepo: "https://github.com/jane-doe/project_example.git:branch"
  systems:
    system_a_basic:
      nodes: [system_a::image_filter]
      connections:
        - [/camera/rgb/image_raw, /image_filter/image_in]
      parameters:
        - [/image_filter/description_label, 'image raw']
        - [/*/use_sim_time, False]

---
application_1:
  fromGitRepo: "https://github.com/jane-doe/project_example.git:branch"
  systems:
    app_1_system_1:
      nodes: [system_a::image_filter, system_b::consumer]
      connections:
        - [/image_filter/image_out, /consumer/image_in]
        - [/image_filter/description_out, /consumer/description_in]
        - [/camera/rgb/image_raw, /image_filter/image_in]
        - [/consumer/image_out, /other_node/image_in]
      parameters:
        - [/image_filter/description_label, 'image raw']
        - [/*/use_sim_time, False]
    app_1_system_2:
      nodes: [system_a::image_filter, system_b::consumer]
      connections:
        - [/image_filter/image_out, /consumer/image_in]
        - [/image_filter/description_out, /consumer/description_in]
      parameters:
        - [/image_filter/description_label, 'image compressed']
        - [/*/use_sim_time, False]

---
application_2:
  fromGitRepo: "https://github.com/jane-doe/project_example.git:branch"
  systems:
    app_2_system_1:
      subsystems: [system_a::system_a_basic]
      nodes: [system_b::consumer]
      connections:
        - [/image_filter/image_out, /consumer/image_in]
        - [/image_filter/description_out, /consumer/description_in]
        - [/consumer/image_out, /other_node/image_in]
      parameters:
        - [/*/use_sim_time, False]

---
application_3:
  fromGitRepo: "https://github.com/jane-doe/project_example.git:branch"
  systems:
    app_3_system_1:
      subsystems: [application_2::app_2_system_1]
      nodes: []
      connections: []
      parameters: []

Let's discuss in this PR any modification until haveing an agreement :)

Thanks a lot for opening the discussion :)
We made some progress also from our side on the models, The current model looks like this:
system:
  nodes:
    image_filter:
      from: "rossdl_test.image_filter"
      interfaces:
        - image_out: pub-> "image_filter::image_out"
        - description_out: pub-> "image_filter::description_out"
        - camera_info: sc-> "image_filter::camera_info"
        - image_info: sc-> "image_filter::camera_info"
      parameters:
       - description: "image_filter::description_label"
         value: "Label"
    consumer:
      from: "rossdl_test.consumer"
      interfaces:
       - image_in: sub-> "consumer::image_in"
       - description_in: sub->"consumer::description_in"
  processes:
    process1:
      nodes: [ image_filter, consumer ]
      threads: 2
  connections:
    -[image_out,image_in]
    -[description_out, description_in]

The main difference between your suggestion and mine is that I define the nodes in detail, the idea is to be able to rename or change namespaces, do you think this is needed? Ideally, I should modify my models to support both versions.
I am also a bit confused about the namespaces you are using for the node (i.e., system_a::image_filter), the nodes come from a ROS packages ( from the point of view of the models from a .ros2 file), or am I mixing things here?
About the composition of subsystems, I have also an open thread, but I am not yet happy.  At IPA these days we are applying the models to a real use case, a UR manipulator with sensors and a gripper. Thanks to this example we are debugging and cleaning up our concept. I will ping you as soon as we have a well-tested version.

Ok, @ipa-nhg , my idea is adapting to all you consider.


perserveWhitespace: false

Version
3.0.0-beta.6
Reproduction link
https://github.com/vuejs/vue-cli/commit/1864cef
Steps to reproduce
https://github.com/vuejs/vue-cli/commit/1864cef
What is expected?
preserveWhitespace: true
What is actually happening?
preserveWhitespace: false

White space is an expected design pattern in HTML. I would expect the default to be true and the few people that want false to have to configure it.  This will be a challenge for anyone new to vue/webpack in that they wont understand why their formatting doesn't look normal.

This is an intended change. If you don't want it, you can configure it by tapping vue-loader's option in vue.config.js. See docs for more details.

I have changed it.
My only concern is that i personally consider false as an advanced feature you wouldn't normally want which in turn means any new developers to Vue will stumble on this.  This version of the CLI is pretty awesome with the zero config but i would expect the defaults to be what a new/entry/mid-level developer would expect and then people that actually know what this setting is for can change it with a config.
Just an opinion and figured i would express it.

I have changed it.
My only concern is that i personally consider false as an advanced feature you wouldn't normally want which in turn means any new developers to Vue will stumble on this. This version of the CLI is pretty awesome with the zero config but i would expect the defaults to be what a new/entry/mid-level developer would expect and then people that actually know what this setting is for can change it with a config.
Just an opinion and figured i would express it.

That's true, I guess this is a tradeoff since having preserveWhitespace: false does result in smaller bundles and slightly better perf in theory, and that's also something we want to have by default.
Maybe we should expose this as a top level option to make it easier to tweak.

Maybe we should provide a enum option for this:
whitespace: strip | collapse | preserve

Setting to collapse may give us smaller bundle size while be consistent to HTML's default behavior in most cases (except for those with white-space: pre in style).

This would be pending https://github.com/vuejs/vue/pull/7598

In case of someone doesn't know how to change the option back, just put the following code in vue.config.js
chainWebpack: config => {
    config.module
      .rule('vue')
      .use('vue-loader')
      .loader('vue-loader')
      .tap(options => {
        options.compilerOptions.preserveWhitespace = true
        return options
      })
  }

@bruceCzK Thank you very much
I have two button elements separated by a space by intention. After upgrading my project to version 3 of the CLI the space is gone.
If preserveWhitespace == false is the new default then it should have not such side effects. No browser I know removes all whitespaces, they collapse multiple whitespaces into one. This should be the default behaviour. This is just my opinion but maybe it is something to consider.

Can somebody actually point at the solution instead of just saying you fixed it do X? That would be useful...
Sorry new to using CLI and not clear how to configure Vue loader in the CLI configuration and the docs are not much help in that space either - assumes way more knowledge of the build process than I have at this point.

Just o add to this have the latest cli and   preserveWhitespace = true still does not work my index.html in public folder is well spaced and laid out but when npm run build the index.html in dist folder has whitespace removed.

In case of someone doesn't know how to change the option back, just put the following code in vue.config.js
chainWebpack: config => {
    config.module
      .rule('vue')
      .use('vue-loader')
      .loader('vue-loader')
      .tap(options => {
        options.compilerOptions.preserveWhitespace = true
        return options
      })
  }

Thank u!!!

For people seeing this with vue-cli 3.*, there's a working solution here: https://github.com/vuejs/vue/issues/10485#issuecomment-528729861
// vue.config.js
module.exports = {
  chainWebpack: config => {
    config.module
      .rule('vue')
        .use('vue-loader')
          .tap(args => {
            args.compilerOptions.whitespace = 'preserve'
          })
  }
}

For people seeing this with vue-cli 3.*, there's a working solution here: vuejs/vue#10485 (comment)
// vue.config.js
module.exports = {
  chainWebpack: config => {
    config.module
      .rule('vue')
        .use('vue-loader')
          .tap(args => {
            args.compilerOptions.whitespace = 'preserve'
          })
  }
}

Thanks, this is what works for vue cli 3 and 4 atm. Should put this in the official docs imo.

For people seeing this with vue-cli 3.*, there's a working solution here: vuejs/vue#10485 (comment)
// vue.config.js
module.exports = {
  chainWebpack: config => {
    config.module
      .rule('vue')
        .use('vue-loader')
          .tap(args => {
            args.compilerOptions.whitespace = 'preserve'
          })
  }
}

This doesn't seem to work anymore with Vue 3, it throws the error: "TypeError: Cannot set property 'whitespace' of undefined". Any workaround for Vue 3?


[Proposal] Unified Nuxt Documentation Experience

Motivation
Nuxt leverage the unjs ecosystem for core parts of the framework, mainly Nitro, H3 and oftech.
While the UnJS ecosystem can be used stand-alone, the majority of its users comes from Nuxt.
Yet, the experience while looking for information about Nuxt in general is often disjointed, due to Nuxt.com and Nitro being separated website, and h3/ofetch currently not having dedicated websites https://github.com/unjs/h3/issues/418
This makes it hard to reason about Nuxt for newcomers, when they will look for how to do something in the docs, won't find it, then have to navigate to the Nitro website, or the github READMEs for H3 or oftech, or googling / finding information in articles.
With separated websites,  the information is not searchable and accessible easily. We could have a single algolia index that search throughout Nuxt/Nitro/H3.
It's something that cloudflare does well, the search bar can jump from one product to the other seamlessly.

Proposal
For Nuxt
Integrate H3, Nitro and ofetch in the nuxt.com website, such so that we have

https://nuxt.com/docs/nitro/
https://nuxt.com/docs/h3/
https://nuxt.com/docs/$fetch/

and one search bar that can be used to reference the content of all 3.
This would remove the duplicated content accross Nuxt and these website, are they would use the same source.
For Nitro, H3 and ofetch
Since these tools are meant to be used either standalone or with Nuxt, we could have a nuxt version for them.
This can be implemented with a NuxtOnly and a StandAlone component that we can use to wrap docs paragraph or code examples.
Using Nitro as an example, this would serve multiple purposes :

Documentation for Nitro and Nuxt would share the same source of truth
Nitro would still have a standalone website that would be identical to what it is today
Nitro would feel more integrated under the Nuxt umbrella as its docs would be accessible without navigating to an external page. Wether they're the same Nuxt app, or there's is one website for each subdocs is an implementation detail.

Additionally, the Nitro website could use a toggle like the vue composition/options api switcher :

This toggle would enable nuxt or standalone instructions. It would be hidden inhttps://nuxt.com/docs/nitro/ which would default to Nuxt, and would be either hidden or visible in https://nitro.unjs.io/ which would default to standalone.
Extra toughts
There are also additional libraries that are used by Nuxt such as vue, vite, vue-router, but this doesn't affect the experience as bad as Nitro/h3. However a similar system can be adopted for unjs libraries that are end-user facing and auto-imported.
Where this makes sense. Perhaps Unstorage/db0 as they come with Nitro/Nuxt.
Additional information

[X] Would you be willing to help implement this feature?
[ ] Could this feature be implemented as a module?

Final checks

[X] Read the contribution guide.
[X] Check existing discussions and issues.

I love this idea, and @Atinux and I have been discussing leveraging multi-source features in nuxt content to make it possible.
cc: @Atinux for his thoughts.

I like the idea.
I also suggest something here https://discord.com/channels/473401852243869706/1125723448694542366/1125723448694542366 because I think that the UnJS ecosystem is also very blurred for newcomers.

Thanks for writing this proposal but I don't believe rerendering direct contents of nitro or h3 docs inside nuxt.com subpaths is a good idea. (algolia cross-ref search might be nice!)
Although we had been thinking of leveraging the multi-source feature of the content module to proxy specific sections (such as deployment guides) to the nuxt website and apply necessary transforms to make content right for now. (One of the reasons to support multi-source in the first place was this). It is not a straightforward thing to do but definitely on the roadmap. In the meantime, nitro docs always have proper switches for Nuxt as the first-class user to make it easy for users.
Also as i have mentioned it frequently, the plan is to expose necessary metadata so that we can directly render h3 utils docs both in h3 (upcoming), nitro and nuxt reference sections, keeping in sync with h3. (it is different than using multi-source copied-over content)

Thanks for writing this proposal but I don't believe rerendering direct contents of nitro or h3 docs inside nuxt.com subpaths is a good idea. (algolia cross-ref search might be nice!)
Although we had been thinking of leveraging the multi-source feature of the content module to proxy specific sections (such as deployment guides) to the nuxt website and apply necessary transforms to make content tailored for Nuxt usage. (One of the reasons to support multi-source in the first place was this). It is not a straightforward thing to do but definitely on the roadmap. In the meantime, nitro docs always have proper switches for Nuxt as the first-class user to make it easy for users.
Also as i have mentioned it frequently, the plan is to expose necessary metadata so that we can directly render h3 utils docs both in h3 (upcoming), nitro and nuxt reference sections, keeping in sync with h3. (it is different than using multi-source copied-over content)

Thank you for providing valuable feedback on my proposal, I appreciate it!
I think that in both cases, we would need to improve the switches for nitro/h3 :
IE create a component similar to code group, but that can save its state from localstorage or equivalent, so that every switch can remember package manager/framework choice.
I understand that you prefer providing specific subsection of the content instead of providing the full path to the docs. In my opinion, since all Nitro and H3 feature are provided for Nuxt, they should be thoroughly documented, one way or another, in the nuxt docs website.
Currently, it makes for a pretty subpar experience when you have to navigate between multiple docs website and README/PRs/source files to understand how to use a feature. I would really love that the final vision for this would be that you can get all the information that you need by staying on nuxt.com/docs.

Saving the state is a good idea by all means! (/cc @Atinux) Also, PRs welcome all the time to improve docs in any of the relevant repos. In nitro, any place that needs an exception for Nuxt, we shall add a switch.
We cannot put everything in one place just like we don't copy Vue documentation and it is directly part of the user's experience as some features are aligned with their own upstream. We can always make mini guides in nuxt and link to upsteam for detailed usage and guides, which again, can be Nuxt tailored when needed no matter where.
I believe cross rendering API references (composables and config) is not only doable, but also good idea because we can select which version to render (and even think of edge/stable toggles!). And as a byproduct of doing so (using JSDocs), user's ideally won't have to even leave their IDEs to know how something works.

Saving the state is a good idea by all means! (/cc @Atinux) Also, PRs welcome all the time to improve docs in any of the relevant repos. In nitro, any place that needs an exception for Nuxt, we shall add a switch.
We cannot put everything in one place just like we don't copy Vue documentation and it is directly part of the user's experience as some features are aligned with their own upstream. We can always make mini guides in nuxt and link to upsteam for detailed usage and guides, which again, can be Nuxt tailored when needed no matter where.
I believe cross rendering API references (composables and config) is not only doable, but also good idea because we can select which version to render (and even think of edge/stable toggles!). And as a byproduct of doing so (using JSDocs), user's ideally won't have to even leave their IDEs to know how something works.

I really like the API reference and having the docs directly in my IDE, we were talking about it with Daniel quite recently => #13653
Your point about making mini guides is very true and its a great way to improve the docs.
I agree that we  shouldn't put things like Vue docs, MDN docs there, yet we have to deal with this Nuxt/Nitro/H3 "problem" that the other meta-frameworks don't have. Don't get me wrong; I love unjs and standalone tools, and my goal here is to address the confusion from users about things that aren't intuitive.
Let me illustrate further what I have now in mind with an example :
How do you create a session with Nuxt ?
Currently :

The nuxt docs search bar doesn't provide any useful information if you search for session.
Googling nuxt-session heavily to the nuxt-session 3rd party module
Googling h3 session links to the h3-session 3rd party module.

Yet, h3 (and nuxt) support sessions out of the box with dedicated composable.
Taking your feedback into consideration we could aim for :

Have all h3 composable documented in JSDOC, and referenced in nuxt.com/docs/api
A dedicated session section in the upcoming h3 website
A mini guide / code example that illustrate how to use these h3 composable and nuxt together.
An authentication section in the nuxt docs that provides concise explanations, and links to these new resources as well as popular modules (including 3rd party).

Have all h3 composable documented in JSDOC, and referenced in nuxt.com/docs/api
A dedicated session section in the upcoming h3 website

Good plan 👍🏼

How do you create a session with Nuxt ?
An authentication section in the nuxt docs that provides concise explanations, and links to these new resources as well as popular modules (including 3rd party).

Your question about the Session is very specific. We currently have an official Nuxt example and it is planned to be well documented in h3 upcoming docs and proposed to be even sooner part of nitro docs (https://github.com/unjs/nitro/pull/1445 by @Barbapapazes). We can link all in the Nuxt docs to guide users.
I think in terms of Auth we should do all better and it is in the scope of the Nuxt something we need to move forward separately. With nuxt/session we shall make best user experience for Nuxt users. H3 session util is too low-level.

A mini guide/code example that illustrates how to use these h3 composable and nuxt together.

This would be nonpractical to make (and keep in sync) 1-* examples for each h3 utility in several places. Neither they are anyhow nuxt or nitro-specific. We shall simply put a link to the h3 reference docs (in JSDocs that are visible in IDE/Nuxt docs) and go to h3.unjs.js/utils/{name} with a more extensive list of examples usable for everyone.
If a util needs nuxt integration (like session) we shall officially support it in Nuxt layer either built-in core or module to give users best practices vs. boilerplates.

I think if you wait little bit more on JSDocs and H3 meta, you would love the integrity and consistency level of docs (have to little bit blindly trust me until we are there and it is not far)

Have all h3 composable documented in JSDOC, and referenced in nuxt.com/docs/api
A dedicated session section in the upcoming h3 website

Good plan 👍🏼

How do you create a session with Nuxt ?
An authentication section in the nuxt docs that provides concise explanations, and links to these new resources as well as popular modules (including 3rd party).

Your question about the Session is very specific. We currently have an official Nuxt example and it is planned to be well documented in h3 upcoming docs and proposed to be even sooner part of nitro docs (unjs/nitro#1445 by @Barbapapazes). We can link all in the Nuxt docs to guide users.
I think in terms of Auth we should do all better and it is in the scope of the Nuxt something we need to move forward separately. With nuxt/auth we shall make best user experience for Nuxt users. H3 session util is too low-level.

A mini guide/code example that illustrates how to use these h3 composable and nuxt together.

This would be nonpractical to make (and keep in sync) 1-* examples for each h3 utility in several places. Neither they are anyhow nuxt or nitro-specific. We shall simply put a link to the h3 reference docs (in JSDocs that are visible in IDE/Nuxt docs) and go to h3.unjs.js/utils/{name} with a more extensive list of examples usable for everyone.
If a util needs nuxt integration (like session) we shall officially support it in Nuxt layer either built-in core or module to give users best practices vs. boilerplates.
I think if you wait little bit more on JSDocs and H3 meta + website, you would love the integrity and consistency level of docs (have to little bit blindly trust me until we are there and it is not far)

I've never seen this example before and it's great we have it. We should find a way to reference it from the docs/search bar; because I think discoverability for them is pretty low. This is exactly what I mean by mini guide/code example that use the h3 composables (session related, not individually) and Nuxt together, so I think we agree 👍🏽


Bot retweets from accounts it has blocked

Our community wants to keep track of our hashtag, but it isn't uncommon for trolls to spam the hashtag with porn, insults, etc.  The retweet bot retweets all these things /even if they come from accounts the bot has blocked/.  This then makes curation impossible, because the blocked tweets do not show up on the bots profile retweets when signed in as the bot.

I think you have to exclude these accounts from search phrase. The blocked accounts are still in the search so the bot find their tweets too.

I think you have to exclude these accounts from search phrase. The blocked accounts are still in the search so the bot find their tweets too.


Bump dependencies, including ring

This brings in unspecified fixes from various upstream libraries, including ring.  I checked explicitly that we didn’t upgrade to a problematic version of async-std.

This does not updates any dependency in a correct way. Nobody is using the Cargo.lock file from the Substrate repo. If you not update Cargo.toml's this pr is useless.


Vulnerability: CVE-2022-40897 - Setuptools needs to be updated to version 65.5.1

https://github.com/docker-library/python/blob/7a54933c66171020473b9a4f06aec4e8ffb43a45/3.10/slim-bullseye/Dockerfile#L124

Duplicate of #781

Is there a reason this hasn't been addressed yet? This is causing my CI/CD scanner to fail all my builds, since the base layer of my image is generating a high alert.


factorio{,-headless}-experimental: 0.18.26 -> 0.18.29

Motivation for this change
Update to the latest (as of 2020-06-03) factorio experimental version.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Thanks for your contribution!

Does it make sense to backport this change to 20.03?
I'm not sure, since currently experimental on 20.03 is still at version 0.17.x. On the other hand:

It's a leaf package.
It makes sense to have the latest version of factorio available, to be able to play on servers.


touch: enable touching a writable file of another user

This PR implements a feature that is explicitly tested by the GNU tests (touch/now-owned-by-other).
Sadly, it also reveals how difficult it is to pull off a specific platform-dependent syscall-trick in a way that kinda mostly remains platform-independent.
This PR uses a yet-to-be-merged feature of crate filetime, because there is no other way to make this particular syscall. Hence, this PR will remain in draft mode until the filetime PR lands and is released.

Changes since last push:

Of course there was a formatting error (&path instead of path)

Changes since last push:

Clippy hates me (#[allow(clippy::collapsible_else_if)])

@BenWiederhake needs rebasing, sorry

Upstream filetime seems to refuse to implement a feature that is required for this feature: https://github.com/alexcrichton/filetime/pull/105
How would you like to proceed?

@BenWiederhake not sure, would it be possible to include this feature into uucore itself ?

@BenWiederhake ping ? :)


Twitter scrapping

closes #3

Also remove the exe file from being tracked by git. Not everyone uses windows, plus we don't want to send exes to peoples system. You can use
`git rm chromedriver.exe` to remove it and then push again. Remove the file too from the git directory as well.

corrected the issue with print.....
changes because am using legacy site without javascript

I thought the legacy also supported passing hashtags?

yes but this way we can get mentions of the tag within texts too because not everyone adds a hashtag

Alright. Can you add a requirements.txt file for this?

okay

okay

LGTM :)


Data link broken

Dear Authors,
Thanks for your great work and codes. The shared data link seems to be broken now. Can you help fix it? Thank you!

My bad, I didn't realize free dropbox accounts have sharing limits. I'll be able to re-upload it in a day or two with a premium account.


Should we manage k8s resources with this module?

This is a general question about the direction of this module.
We get requests that would require this module to manage or create Kubernetes resources. Some examples:

Modifying CNI configuration before worker ASG creation: https://github.com/terraform-aws-modules/terraform-aws-eks/issues/96
Deploying cluster autoscaler: https://github.com/terraform-aws-modules/terraform-aws-eks/issues/71
Manage add-ons: https://github.com/terraform-aws-modules/terraform-aws-eks/issues/19

I think we should have a clear position on this types of issues.

^ we're on the same page here. 100% we should avoid adding bits of shell script, here, there, and everywhere to accommodate individual needs because those would stretch a mile long. Providing adequate facilities for others to flexibly add what they'd want on top of what we have (e.g. pre-userdata and post-userdata) is a better approach and I'm all ears for those sorts of additions. I think what we have will more than likely be flexible enough for the long haul but perhaps you see room for improvement.
I'm a bit more torn if the kubernetes provider gets to the point of useful in conjunction with this module. When/if that happens, I'd at least be interested to see how people would want to use that within the module. My inclination is that most if not all of this would be better suited for a separate state and as a consumer of the module rather than within it, but I'm reserving the chance that some is worth integrating.
Curious to hear any other thoughts you might have. If we're seeing eye to eye on most or all of the above, let's close this out.

OK cool, I think we are definitely on the same page about this! That's great.

Providing adequate facilities for others to flexibly add what they'd want on top of what we have (e.g. pre-userdata and post-userdata) is a better approach and I'm all ears for those sorts of additions.

:100:

I'm a bit more torn if the kubernetes provider gets to the point of useful in conjunction with this module.

Perhaps later but for now I think it's a little tricky due to providers not supporting any sort of depends_on functionality. We had this when trying to create DBs inside an RDS instance using the PostgreSQL terraform provider.

My inclination is that most if not all of this would be better suited for a separate state

Agreed.
Anyway, for now I'll close this and we can refer to this for future issues. And if it changes in the future then we can re-evaluate the situation.


Prompts for authentication for each new repo

I have multiple repositories using VFSforGit stored on the same server. Each time I try to clone a new repository with gvfs clone, I'm prompted to log in again and must enter my username, password, and a 2FA code.
Instead, VFSforGit should prompt once to acquire a personal access token and store it in the credential manager for reuse across all repositories on that server, as upstream Git does. If the user requires different credentials for different repositories, then they can set the credential.useHttpPath option in their configuration to specify this, and VFSforGit can then prompt them each time.

Hi!
Great feedback. We effectively force credential.useHttpPath for all of our VFS4G repositories currently, as some remotes require it to authenticate as expected - in particular internal repositories that we support. This is unnecessary (and has negative consequences) in general.
I think one option is for our team to handle setting the useHttpPath as an internal concern (e.g. in our internal setup) rather than pushing this behavior into the general behavior for VFSForGit.

Addressed with #939


Decompose AvgPool3d Op to Conv3d for Support

Summary:

This PR fixes #713

The core idea behind this transformation is to use Conv3d as a replacement for AvgPool3d by setting the convolution kernel's weights to a constant value. Specifically, the weight for each element in the kernel is set to:

weight_value = 1.0 / (kD * kH * kW)
weight = torch.ones(1, 1, kD, kH, kW) * weight_value

This approach effectively turns the convolution into an average pooling operation, as the weights are identical, and their sum over the receptive field will produce the average. (Note : conv3d is not yet supported in MLIR and TTNN)

eval,shape,decompose fucntions and sanity tests are added for conv3d, avgpool3d

Logs

avgpool3d_test_case_results.log
conv3d_test_case_results.log

@kamalrajkannan78 @nvukobratTT Can you share why we decompose avgpool3d? Since tt-metal has avgpool2d, can we expect it to have avgpool3d support, or ask for it? Do we know if they had the need for avgpool3d themselves?
This decomposition is logical but whenever I see some decomposition lately, I start thinking about how performant decomposed subgraph is compared to native op in ttnn. So if we do decompose, we are less overfitting to ttnn, and if we don't do it and require ttnn support to lower directly, we are maybe overfitting to ttnn.
What is your take in this case @nvukobratTT

@kamalrajkannan78 @nvukobratTT Can you share why we decompose avgpool3d? Since tt-metal has avgpool2d, can we expect it to have avgpool3d support, or ask for it? Do we know if they had the need for avgpool3d themselves? This decomposition is logical but whenever I see some decomposition lately, I start thinking about how performant decomposed subgraph is compared to native op in ttnn. So if we do decompose, we are less overfitting to ttnn, and if we don't do it and require ttnn support to lower directly, we are maybe overfitting to ttnn.
What is your take in this case @nvukobratTT

Few notes before more detailed CR:

I'm okay with doing these decompositions as TTNN lacks support for these ops. Mostly because it's questionable when (if) they are going to add those. That said, @kamalrajkannan78 can you open two issues on tt-metal repo with a op support request and like them here? Ideally, we should like to have those ops on TTNN as well.
Can we decompose avg pool 3d using avg pool 2d? Current solution looks mathematically correct, however, it will impose confusions when when someone starts to debug what is happening here. From my side, it seems cleaner to decompose conv3d using conv2d, and doing similar for avg pool 3d using avg pool 2d. What are your thoughts guys?
For avg pool 3d we can use a similar decomposition approach:

Apply avg pool 2d over on each depth slice (keep intermediate results for each slice)
Stack those results along depth dim
Average those results across depth dim

@kamalrajkannan78 @nvukobratTT Can you share why we decompose avgpool3d? Since tt-metal has avgpool2d, can we expect it to have avgpool3d support, or ask for it? Do we know if they had the need for avgpool3d themselves? This decomposition is logical but whenever I see some decomposition lately, I start thinking about how performant decomposed subgraph is compared to native op in ttnn. So if we do decompose, we are less overfitting to ttnn, and if we don't do it and require ttnn support to lower directly, we are maybe overfitting to ttnn.
What is your take in this case @nvukobratTT

thanks for the review @dgolubovicTT

Alexnet model faced Encountered unsupported op node type: nn.avg_pool3d, on device: tt issue  .  I looked into nn.avg_pool2d decomposition and followed similar way to decompose nn.avg_pool3d.
Inorder to support alexnet osmr model avgpool3d is needed & It will be helpful if we get a support from MLIR for this op
If we decompose it with some other available ops , we may need to add support in those available ops to handle our 5d input tensor.

@kamalrajkannan78 @nvukobratTT Can you share why we decompose avgpool3d? Since tt-metal has avgpool2d, can we expect it to have avgpool3d support, or ask for it? Do we know if they had the need for avgpool3d themselves? This decomposition is logical but whenever I see some decomposition lately, I start thinking about how performant decomposed subgraph is compared to native op in ttnn. So if we do decompose, we are less overfitting to ttnn, and if we don't do it and require ttnn support to lower directly, we are maybe overfitting to ttnn.
What is your take in this case @nvukobratTT

Few notes before more detailed CR:

I'm okay with doing these decompositions as TTNN lacks support for these ops. Mostly because it's questionable when (if) they are going to add those. That said, @kamalrajkannan78 can you open two issues on tt-metal repo with a op support request and like them here? Ideally, we should like to have those ops on TTNN as well.

Can we decompose avg pool 3d using avg pool 2d? Current solution looks mathematically correct, however, it will impose confusions when when someone starts to debug what is happening here. From my side, it seems cleaner to decompose conv3d using conv2d, and doing similar for avg pool 3d using avg pool 2d. What are your thoughts guys?

For avg pool 3d we can use a similar decomposition approach:

Apply avg pool 2d over on each depth slice (keep intermediate results for each slice)
Stack those results along depth dim
Average those results across depth dim

sure @nvukobratTT I will try to decompose avgpool3d in a suggested way!

Decomposing avgpool3d to avgpool2d like @nvukobratTT layed out sounds great. Let's do it like that!

@kamalrajkannan78 @nvukobratTT Can you share why we decompose avgpool3d? Since tt-metal has avgpool2d, can we expect it to have avgpool3d support, or ask for it? Do we know if they had the need for avgpool3d themselves? This decomposition is logical but whenever I see some decomposition lately, I start thinking about how performant decomposed subgraph is compared to native op in ttnn. So if we do decompose, we are less overfitting to ttnn, and if we don't do it and require ttnn support to lower directly, we are maybe overfitting to ttnn.
What is your take in this case @nvukobratTT

Few notes before more detailed CR:

I'm okay with doing these decompositions as TTNN lacks support for these ops. Mostly because it's questionable when (if) they are going to add those. That said, @kamalrajkannan78 can you open two issues on tt-metal repo with a op support request and like them here? Ideally, we should like to have those ops on TTNN as well.

Can we decompose avg pool 3d using avg pool 2d? Current solution looks mathematically correct, however, it will impose confusions when when someone starts to debug what is happening here. From my side, it seems cleaner to decompose conv3d using conv2d, and doing similar for avg pool 3d using avg pool 2d. What are your thoughts guys?

For avg pool 3d we can use a similar decomposition approach:

Apply avg pool 2d over on each depth slice (keep intermediate results for each slice)
Stack those results along depth dim
Average those results across depth dim

https://github.com/tenstorrent/tt-metal/issues/15102
https://github.com/tenstorrent/tt-metal/issues/15103

Thanks for the issues @kamalrajkannan78 !
FYI, I updated labels nad added project information to reflect more precisely what our request is :))

Thanks for adding those details @nvukobratTT

@kamalrajkannan78 @nvukobratTT Can you share why we decompose avgpool3d? Since tt-metal has avgpool2d, can we expect it to have avgpool3d support, or ask for it? Do we know if they had the need for avgpool3d themselves? This decomposition is logical but whenever I see some decomposition lately, I start thinking about how performant decomposed subgraph is compared to native op in ttnn. So if we do decompose, we are less overfitting to ttnn, and if we don't do it and require ttnn support to lower directly, we are maybe overfitting to ttnn.
What is your take in this case @nvukobratTT

Few notes before more detailed CR:

I'm okay with doing these decompositions as TTNN lacks support for these ops. Mostly because it's questionable when (if) they are going to add those. That said, @kamalrajkannan78 can you open two issues on tt-metal repo with a op support request and like them here? Ideally, we should like to have those ops on TTNN as well.

Can we decompose avg pool 3d using avg pool 2d? Current solution looks mathematically correct, however, it will impose confusions when when someone starts to debug what is happening here. From my side, it seems cleaner to decompose conv3d using conv2d, and doing similar for avg pool 3d using avg pool 2d. What are your thoughts guys?

For avg pool 3d we can use a similar decomposition approach:

Apply avg pool 2d over on each depth slice (keep intermediate results for each slice)
Stack those results along depth dim
Average those results across depth dim

https://github.com/tenstorrent/tt-forge-fe/pull/741


UI/UX: Add  boxes to all forms for better user feedback.

I know there are some forms in the app that have no alert boxes. For example, I don't know if I logged in or not as of writing this.

Done in my react branch.


Wrong copyright info on some pages

Currently, the home page footer shows the copyright for OpenPrinting, but on other pages, it shows the copyright for Apple Inc.
Attaching the screenshots for this :

Is this a bug ?
If yes, then I can try to create a PR for fixing this :)

Hi @Rishabh-792 ,
thank you for reporting the issue!
The code copyright can be changed due license, but I'm not quite sure (since IANAL) about the logo - @michaelrsweet , do you know if the open source license can be applied to logos? Like since we forked the project under Apache License 2.0 with CUPS exceptions, is the logo under OpenPrinting, or is it still Apple?

@zdohnal The OpenPrinting CUPS logo is a new design by me, and yes as a creative work it can be copyrighted just like code, text, etc. The footer should be consistent for all pages and languages, specifically pointing to OpenPrinting.

@zdohnal @michaelrsweet Created a PR #349 for fixing this.


17982 - Fixed issue happing after change of event type from change to keydown.

Issue:17982https://github.com/bcgov/entity/issues/17982
Description of changes:

Fixed issue happing after change of event type from change to keydown.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namex license (Apache 2.0).

/gcbrun

Temporary Url for review: https://bcregistry-btr-dev--pr-65-yb14zaqc.web.app

just needs the lint fix

/gcbrun

Temporary Url for review: https://bcregistry-btr-dev--pr-65-yb14zaqc.web.app


[Feature]: Add toggle to SHARE modal for user to enable app forking

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
This request is for a new toggle to be added to the UI of the SHARE modal, to allow users to enable forking of their applications. The toggle should be off by default.
Not all users are familiar with the term forking, so we should be careful with the labeling of this feature, and ensure we clearly communicate to the user that others will be able to copy their app once enabled.
Mockup

Why should this be worked on?
This will allow users to share a copy of their app, rather than give users direct access to the source app itself.

@kocharrahul7 @ginilpg , could we get an update on this feature please?
cc @Nikhil-Nandagopal

So by marking it as forkable we want to see the fork button on the deployed version of the app.

For e.g https://app.appsmith.com/applications/623cca594d9aea1b062b33c6/pages/623cca594d9aea1b062b33cd is a sample app which is forkable.
Currently the fork button shows up only when the application is public. Do we need this to show up when the app is shared to a user and not public? FYI implementation isn't hard just needs testing for the new scenarios.  @GreenFlux @kocharrahul7

thanks @akash-codemonk. Yes, this feature should be independent of the public setting. We should allow for all combinations of public (true/false) and forkable (true/false).
cc @rlnorthcutt @jacquesikot

@GreenFlux hey, If the app isn't public how can the user fork it? for a non-public app, any non-invited user will see this:
In what scenario would it be helpful to make an app forkable and not public?
For users who are invited, they can also fork the application from the home page or within the edit page of the app.
@akash-codemonk We should also speak to TM about GAC. I'll start a thread with them

In what scenario would it be helpful to make an app forkable and not public? For users who are invited, they can also fork the application from the home page or within the edit page of the app.

For users who are invited as App Viewer the menu won't be visible in the home page, so in this case they will see a fork button in the deployed page.
Anyways after thinking about a few scenarios I have some concerns about enabling forking for private apps. One of the use cases we discussed was for support, the user can share view access to the support team and mark the app as forkable. The support team will be able to debug the application having an editable version of the app without being able to edit the original app. Here if the app is shared with 10 users with view access, one of them being the appsmith support team, marking the app as forkable today will make the app forkable for all 10 users which might not be the intention of the user.
So I think the surface area of impact is more and needs more work too look at the different possibilities if the app is forkable for private apps. For now to have minimal change we should allow apps to be forkable only if they are public. For private apps we should consider creating a separate issue.
Eitherways things to be looked at before shipping

should create a seperate permission for forking similar to what we have for marking application as public.
Updating the forking field should reflect in audit logs as well.

I don't think we should conflate these two things. Making an app forkable is a very explicit action to take, so the user should have an awareness of that. Plus, the data connections will not be carried over at this time, which is additional security protection.
Some use cases:

DevRel is working on a new template and want to test it without making it public yet.
A customer team wants to make their own private templates available for users without opening them up to the world
Customer wants support or a consultant to be able to work on an app without being able to alter or modify the original
Freelancer is building a customer's app in their own workspace and wants the customer to be able to fork it into their separate workspace.

We can create a separate issue to look into this, but then it is a question of undoing work, which is not ideal. My suggestion is to add the forkable switch now, and open up another ticket to investigate if the switch should also force the public app (which would be an additive change).

+1 to Permission for forking and forking switch being in the audit log at

Adding in comments after discussing it with @GreenFlux

This setting will go in the app settings under the share and embed settings, not in the share modal. Since we feel like it will not be a very utilised feature, putting it in the share modal seems unwise.
When a user tries to toggle this on, they will have to be served with a double confirmation modal. This modal should have the following text:
Enabling forking of this app means anyone who has access to this app can copy it into their own workspace. When copied, the user will also get access to any connected datasources. Are you sure you would like to enable forking?
This will retain the same permissions as forking on the home page. No new permissions need to be added

Hey folks :wave:,
here is a prototype for how app fork settings can work - https://www.figma.com/proto/aUq991dKP4aW7yepxxFete/App-fork-settings?page-id=0%3A1&[…]7%2C338%2C0.65&scaling=contain&starting-point-node-id=1%3A7912
Github issue - https://github.com/appsmithorg/appsmith/issues/20569
Please check it out and share feedback.

This should actually go in both places (share and settings). This matches the expected behavior we see in other tools like Notion. It also makes sense - sharing the app, making it public, and making it reusable are all related. I think this will actually be more useful than you may think, especially when we build the community library of templates.

Double confirmation is great, but I think the note about connected datasources is incorrect. The forked app will not have the connected datasources unless they are in the same workspace, right? And even then, they are not connected by default on a forked template. There is a separate flag for cloning the data source that will not be set. @GreenFlux to confirm.

Prototype looks good for the settings page. Here are the mockups we have in our internal notes:

@rlnorthcutt it should not share the credentials for the new datasource copy unless exportWithConfiguration=true. However, there's a bug with Authenticated REST API datasources that is ignoring this flag, and including the credentials regardless of the setting. I've just submitted an issue for it.
https://github.com/appsmithorg/appsmith/issues/21691
This issue should probably be prioritized before exposing the forking option on the UI.

@rlnorthcutt I see your point, for why the fork toggle should be added to the Invite modal but I'd recommend we plan it as a phase 2 of the feature for the following reasons -

Keeping the invite modal clutter free is paramount. Any action added to the invite modal should affect 100% of the users. Let's get more data on the feature's adoption before we decide.
The current architecture of the modal is not flexible enough to add new actions. We'd have to expand the scope of the project to make any design changes, and they'll require cross-pod collaboration.

@kocharrahul7 As @GreenFlux pointed out, credentials for the datasource are not shared outside of the workspace, so in that case we should remove the double confirmation in my opinion.

Understood on the invite modal. That is important, but not urgent. I think it makes sense to minimize difficulties and take our time with changes to the modal. Thank you for the detailed explanation!
I think we should get this ready, but block release until issue #21691 is fixed. Are there other related issues we should consider?

https://appsmith-m46itso6q-get-appsmith.vercel.app/ deploy preview.
The forked app will have the connected datasources as per how it works today on prod(for e.g sample apps). So essentially whoever forks the app, they will be able to query the datasources without adding their own credentials.

[ ] Make application forkable toggle switch is not getting displayed for old apps is this expected? Please refer the attached video:- https://jiju8jbmwa.vmaker.com/record/7EY6dXhR4xDgLK7i

On item 1 - I would expect to see the toggle switch for all apps, old and new.
On item 2 - when a user has edit access to an app, then they would see the edit button, not the fork button. My guess is that the forking button is shown by default, and then removed when edit access is asserted.

[ ]  Make application forkable toggle switch is not getting displayed for old apps is this expected? Please refer the attached video:- https://jiju8jbmwa.vmaker.com/record/7EY6dXhR4xDgLK7i

We checked this on call, it wasn't an issue with old apps. The user just didn't have the permission to mark an app as forkable, so the section was hidden.

[ ]  Glitch is observed when the user deploys the app Fork App button is seen for few secs and then goes off is it expected? Please refer the video:- https://jiju8jbmwa.vmaker.com/record/qYaTWXTblzrweSIb

Yup as @rlnorthcutt mentioned it defaults to fork(only if the app is forkable), once we know the user has edit access it replaces with the edit button. Will fix this by waiting to receive all information then show the right button once. Will post the new DP once fixed
@Richarex

Looking good! Just want to check again on the tooltip: the expectation is that when the app is forked, the datasource connection is made, but the credentials are NOT shared. So, you have to reset or reconnect to the datasource: https://github.com/appsmithorg/appsmith/issues/21691
@aakashDesign @GreenFlux @jacquesikot @rahulbarwal

The PR for this is on hold. There are is a prerequisite issue https://github.com/appsmithorg/appsmith/issues/21691 which needs to be closed first.
We are targeting to get this on release by end of this month.


email-validate

while using the command 'pip install -r requirements.txt' I am just running into this error:
ERROR: Could not find a version that satisfies the requirement email-validate (from versions: none)
ERROR: No matching distribution found for email-validate
I have upgraded my pip and python to the latest still have to problem.

Thanks  for the reporting the error , the issued have been fixed with issue #49 , you can find the solution  over there


Constant CORS request issues when loading HLS stream

To preface this, I know my m3u8 file is working correctly. Converted myself with ffmpeg + cuda. I am running Radium, and it is allowing me to auth, as well as chat. The demo loads perfectly fine.
I have used this exact same setup earlier in the week and it worked, using the exact settings I am running below.
When I pulled this backed down on another server, I am met with the following:
I am currently running a basic http server with python, as well as adding the headers as needed, all ports are forwarded correctly :
#!/usr/bin/env python3
from http.server import HTTPServer, SimpleHTTPRequestHandler, test
import sys

class CORSRequestHandler (SimpleHTTPRequestHandler):
    def end_headers (self):
        self.send_header('Access-Control-Allow-Origin', '*')

        SimpleHTTPRequestHandler.end_headers(self)

if __name__ == '__main__':
    test(CORSRequestHandler, HTTPServer, port=int(sys.argv[1]) if len(sys.argv) > 1 else 8000)

And when navigating to the basic http server with a browser and checking the network requests, the headers show:
Content-type: text/html; charset=utf-8
Content-Length: 25353
Access-Control-Allow-Origin: *

But when I changed the HLS_URL either through env variable or by changing the stream url in the interface, I am a met with "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://HOST:27078/output.m3u8. (Reason: CORS request did not succeed)." (I have also tried lower ports as well, and port 80)
As seen above, I am 100% sure the http server is serving the right headers for CORS, but this is now not working.
Am I missing something simple, or did something change with the last push a few days ago?
Thanks :)

Wanted to post here again, it seems that even the previous version isn't working. I am unsure if I am possibly missing something here, but every HTTP server I put up with CORS headers, Radium is giving me grief. I will continue to try on my own

The latest push update the state that is being pushed to new users which wouldn't effect CORS.
I tried your setup and was not able to replicate the CORS issue you are having.
I ran your python script python3 script.py 6898 to create the webserver and made sure to include an hls stream in the directory. I then spun up a radium instance using the default parameters:
docker run -d --name=radium-test -p 6899:3000 -e BASE_URL=http://<IP_ADDRESS>:6899 zibbp/radium:latest

Once setup, I was able to change the HLS url to the stream hosted by the python web server located at http://<IP_ADDRESS>:6898/test/output.m3u8 without CORS issues and the HLS stream playing perfectly.


{Compute} New example in az sig image-version update

Description

I removed an example that does not work and updated it with a new example that works. The examples cover how customers can change the region of an image version
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

/azp run


Add question mark notice lint

Returns a Notice if the commonName or SAN DNSNames has an item that is prepended with ?..
Addresses https://github.com/zmap/zlint/issues/165

*.? is also used: https://crt.sh/?q=*.%3F.%25

@zakird @titanous fixed up those comments.


iPhone 5S

I find offset for iPhone 5S, but get error
sysname: Darwin
nodename: iPhone-Slonick
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:09 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_S5L8960X
machine: iPhone6,1
2017-01-26 06:16:38.111751 yalu102[204:3578] found corruption 38203
2017-01-26 06:16:42.325356 yalu102[204:3578] found kernel text at fffffff015c04000
2017-01-26 06:16:42.327648 yalu102[204:3578] got tfp0 -> f07
2017-01-26 06:16:42.328246 yalu102[204:3578] found procs at fffffff0161af1b0
2017-01-26 06:16:42.328547 yalu102[204:3578] seg: __TEXT
2017-01-26 06:16:42.328619 yalu102[204:3578] seg: __DATA_CONST
2017-01-26 06:16:42.328664 yalu102[204:3578] seg: __TEXT_EXEC
2017-01-26 06:16:42.328743 yalu102[204:3578] seg: __KLD
2017-01-26 06:16:42.328789 yalu102[204:3578] seg: __LAST
2017-01-26 06:16:42.328830 yalu102[204:3578] seg: __DATA
2017-01-26 06:16:42.328871 yalu102[204:3578] seg: __PRELINK_TEXT
2017-01-26 06:16:42.328911 yalu102[204:3578] seg: __PLK_TEXT_EXEC
2017-01-26 06:16:42.328991 yalu102[204:3578] seg: __PRELINK_DATA
2017-01-26 06:16:42.329042 yalu102[204:3578] seg: __PLK_DATA_CONST
2017-01-26 06:16:42.329083 yalu102[204:3578] seg: __PLK_LINKEDIT
2017-01-26 06:16:42.329123 yalu102[204:3578] seg: __PRELINK_INFO
2017-01-26 06:16:42.329162 yalu102[204:3578] seg: __LINKEDIT
2017-01-26 06:16:42.329200 yalu102[204:3578] fffffff014dbc000 - fffffff016498000
2017-01-26 06:16:42.399342 yalu102[204:3578] ffffffff03d9c000
2017-01-26 06:16:42.444078 yalu102[204:3578] fffffff015c655a0
2017-01-26 06:16:42.483456 yalu102[204:3578] pmap: fffffff016114850
2017-01-26 06:16:42.522567 yalu102[204:3578] got phys at 0 for virt fffffff002fc8000
2017-01-26 06:16:42.522748 yalu102[204:3578] found cpu 0
2017-01-26 06:16:42.522790 yalu102[204:3578] found physz: fffffff015c87000
2017-01-26 06:16:42.522836 yalu102[204:3578] found cpu 1
2017-01-26 06:16:42.522873 yalu102[204:3578] found physz: fffffff015c87000
2017-01-26 06:16:42.522969 yalu102[204:3578] fffffff015d8733c - fffffff015d8719c
2017-01-26 06:16:42.524845 yalu102[204:3578] ttbr0: 8024c5000 fffffff015c65590
2017-01-26 06:16:42.525369 yalu102[204:3578] got a cpacr

Make a pull request for the offsets
also refer to https://github.com/kpwn/yalu102/issues/28

Do the closed issues mean they have been officially fixed?

I don't see the offset so i'd guess make a pull request with the new offset
the cpacr problem is because the device is 4k not 16k, and that hasn't been added yet, refer to https://github.com/kpwn/yalu102/issues/28


when ?

Hi !
Your description repository sound great !
But you don't publish the source.
When van you do it ?

Can*

No reponse i close this issue.


Update to zig master

This PR updates the code to be compatible with the zig master, both stage1 and stage2 compilers.
Please refer to each commit's comment for more details.
PS: Amazing work you have done on this project, thanks for sharing!

Thank you so much!


Auto gameplay pipeline

Pack in docker?
Input several student's .py files and output game playback video and statistics.

Running a webots on Docker is introduced at the official website:
https://www.cyberbotics.com/doc/guide/installation-procedure#installing-the-docker-image
On my environment with nvidia GPU, after installing nvidia-docker2 package it works well:

Is there any easy way to run this headless without losing GPU acceleration? I tried and failed...

@dbscoach @aquahika We should probably get together and figure out whether we can actually use GPU acceleration. I am happy to provide a server for testing purposes as well, if that would be of any help.
Would something like that work for you?
Thanks!

@dbscoach @aquahika We should probably get together and figure out whether we can actually use GPU acceleration. I am happy to provide a server for testing purposes as well, if that would be of any help.
Would something like that work for you?
Thanks!


Version 3

Hey there,
I would like to release version 3 with a whole lot of bug fixes and new features. These are the PRs that went into it:

Check if sensors are available by @dabit1
Add linking failure message: If you forget to link the native dependencies you now get "Native modules for sensors not available. Did react-native link run successfully?" as an error by @simonbengtsson
Fix sensor availability checks by @maxkomarychev
Fix startup API by @baygeldin
Magnetometer by @NoaneDan is not merged yet, but it will be included in the 3.0 release

First of all, I would like to thank you a lot for the effort you put into this and for keeping up with my change requests and slow review times. This is my game plan for this release, feel free to give me some feedback on this:

Publish version 3.0.0-1 and get feedback from you
Wait for Magnetometer to be in master
Publish version 3.0.0-2 and get feedback from you
Publish version 3.0.0

I will start releasing the first new version right now. I am a bit dependant on you to give me feedback, please comment here, so that we can get it shipped together 👍

Sounds great! I'll try the npm version soon. Thank you for your work on this.

I just published 3.0.0-2, it would be super nice if you could send in feedback until the end of next week. I will release 3.0.0 once I got two 👍 by you :)

Yeah looks good! Good job guys

@baygeldin did you get to it? I would love to hear a second approval before I release it to the world 🙈

@DanielMSchmidt sorry for delay (I've been busy on the weekend). 3.0.0-2 works fine for me (both accelerometer and gyroscope) :)

Awesome, I will release 3.0.0 later today

We have a website now: https://react-native-sensors.github.io/

I actually forgot to publish 3.0.0, I did it yesterday, sorry about the ~1 month delay -.-

hey, found this issue after trying to use the library, and running the link command, i still receive Native modules for sensors not available. Did react-native link run successfully?. Am new to RN, so am I missing something here?
Its an empty project essentially, with just a header and then using this sensor library.
Misc info:

"react": "16.4.1",
"react-native": "0.56.0",
"react-native-sensors": "^3.0.0"

react-native link command success:

Error screenshot:

components/RNSensorOutput.js:
import React, { Component } from "react";
import { Text, View } from "react-native";
import { decorator as sensors } from "react-native-sensors";

class RNSensorOutput {
  // no lifecycle needed
  render() {
    const { sensorsFound, Accelerometer, Gyroscope } = this.props;

    if (!Accelerometer || !Gyroscope) {
      // One of the sensors is still initializing
      return null;
    }

    return (
      <View style={styles.container}>
        <Text style={styles.welcome}>
          {(sensorsFound["Accelerometer"] &&
            `Acceleration has value: ${Accelerometer}`) ||
            "Acceleration is not available"}
          {(sensorsFound["Gyroscope"] && `Gyro has value: ${Gyroscope}`) ||
            "Gyro is not available"}
        </Text>
      </View>
    );
  }
}

export default sensors({
  Accelerometer: {
    updateInterval: 300 // optional
  },
  Gyroscope: true
})(RNSensorOutput);

I've tried this 100x it doesn't work. Seems expo api is better

@sreubenstone You are free to choose whatever tool you like to :)
If you tell me what you tried and which version of react-native-sensors you used I might be able to help 👍

Sorry I am getting frustrated.   But I just kept on getting the native modules error.

If you create a repository with the error and create an issue with a link to it, I will take a look and try my best to help you 👍


I follow your step by step,and I have gpu ,but when I run train.py,it looks like not use gpu.what is the problem.thanks for help.

this is solution;;https://github.com/hizhangp/yolo_tensorflow/issues/21


[Question] Datasource  Create user oracle  failed

Use  [Datasource]  create a new one use ORACLE ,BUT failed.
I find same may lose some jar
dolphinscheduler
[1.3.1]
Oracle 12c
[<IP_ADDRESS>]
I get api log under  this
[ERROR] org.apache.dolphinscheduler.api.service.DataService;[433] - oracle.jdbc.driver,OracleDriver
java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver
how to solve the problem.

ojdbc.jar Put it in the Lib directory and restart dolphin scheduler

ojdbc.jar 放到lib目录下，重启dolphinscheduler

ojdbc.jar Put it in the Lib directory and restart dolphin scheduler
ojdbc.jar 放到lib目录下，重启dolphinscheduler

Tkssss! !! Its simple and effective


Node.js single thread with image processing question

I have use this lib in my project and it works fine in staging. But Image resizing is a cpu intense task, and I can see my staging server cpu usage almost 100% when uploading and resizing a image. Although the staging server is just EC2 t2.micro, I am still afraid that this will lead to server being blocked once pushed to production. (I have tried to upload using two device at the same time and seems to be fine, but still not sure what will happen in production, and the http response takes almost 3000ms!)
Could you tell me how it is handled when multiple users uploading images at the same time and if there is a possibility that the event loop would be blocked which is a big concern in node.js.
My question is also here:
http://stackoverflow.com/questions/34018487/node-js-with-imagemagick-why-server-is-not-blocked

This is a great question @damonYuan!
This was a concern for us as well when we created this library. Originally we depended upon gm which wraps all the ImageMagick functions for Node.js, this was not very efficient for our case since we had to do n resize operations – one for each version of the original image. Hence we created im-resize which is much more efficient resize of multiple versions using special ImageMagick operations for this purpose.
´im-resizeuses theexec()` function to execute ImageMagick commands which means that all image processing will run as separate processes and not in the main process which is your Node.js application. If you have multiple CPUs or CPU cores this will happen across all of them according to your operating system's prosess schedular.
If you are on a Linux systems you could run your Node.js application with a high process priority using the nice command to ensure that the process will always have priority over other ImageMagic processes. You can also dig deep into ImageMagick internals to see ways to prevent excessive CPU usage, you start by reading this thread and the ImageMagick external resources page.
Make sure you have reasonable enough CPU and memory for the number of uploads and image versions you are handling, I am reluctant to do premature optimization and introduce more complexity to this library without sufficient data to back up that such an optimization is necessary.

Cool @Starefossen ! Thanks a lot!


8muses gives null error on large downloads

[NSFW]

Ripme version: 1.5.14
Java version (output of java -version): 1.7.0_55
Operating system: Windows 10
Exact URL: anything really large (ex: https://www.8muses.com/comix/album/taboolicious_xxx-comics)
Please include any additional information about how to reproduce the problem:  Attempt to download an album with a few hundred (or thousand) images and eventually the program will give the error.

Expected Behavior
Downloads all the albums in an 8muses artists page and puts them in the download directory.
Actual Behavior
Says 'rip complete' then Error: 'null' if the amount of items being downloaded is too large, then deletes the folder that was created in the download directory.
I would assume this may be an API thing, or something to do with too many requests.  It may also be based on the number of albums rather than number of images, but it's difficult to tell.  Downloads work fine in the 0-400 image range on a few albums, but don't seem to work for the same amount of images in 20-30 albums (some of which are inside other directories).
Note that it is possible to save all the same images from an artist by queuing the albums individually.

Please go report at the new repo at https://github.com/ripmeapp/ripme/


Cannot create content nodes from doctypes with no properties.

Apparently if you have this package installed, if you have doctypes with no properties (like for folder nodes, or site-settings), you will not be able to create new items because the name textbox becomes disabled.
Did not test this thoroughly myself, but after asking Uaas support, they did and recommended me to uninstall the package.

[UPDATE] I did uninstall the package and now I can create content from doctypes without props. So this is a bug.

Hi @Andrei-
Which version of the package are you using. In the latest version the content app is not shown anymore when creating a item.
Have you tried upgrading to v2.1.0
Dave

Hi @dawoe,
We were on version 2.0.0.
Didn't try 2.1.0, as we moved to skybrud redirects package.


Fix path to Dockerfile.ubuntu in Readme file instructions

No Scripts directory required in path, otherwise failure occurs
Error Details in -> Fixes #70

I'm busy with a change to the cli so this is not needed anymore, anyhow https://github.com/ipdk-io/ipdk/blob/main/build/scripts/ipdk_default.env#L13 exactly describes what to do. For you removing $scripts will work but not if you use the ipdk command from another directory then build.

Good idea

Replaced with PR https://github.com/ipdk-io/ipdk/pull/73


拆分所有的drivers

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 71.42857% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.01%. Comparing base (b0e3dac) to head (e1aef1c).

Files with missing lines
Patch %
Lines

dcron.go
60.00%
2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #106      +/-   ##
==========================================
+ Coverage   88.24%   90.01%   +1.77%
==========================================
  Files          17       12       -5
  Lines        1097      861     -236
==========================================
- Hits          968      775     -193
+ Misses         98       71      -27
+ Partials       31       15      -16

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


Increase default size of /var partition

Pls increase volume size of /var logical volume
Now by default it takes about 4Gb, but with increasing logs it fills partition very fast by daemon and syslog logs
Maybe swap size with /opt partition

Fixed, not this directory is 7,5 GB.


PyTorch: Slicing expected array

Netron app and version: 5.7.9
OS and browser version: macos 12.3

Steps to Reproduce:
1.got Slicing expected array  error when open the torch pt file

@mollon650 can you share a sample file to reproduce the issue?

https://drive.google.com/file/d/1vZiVxO5YDu4H2Ux_A6NcKLF959Mw-A0M/view?usp=sharing model is here， u can download it and test

Duplicate of #913


[Spark] Optimize query for WHERE partitionkey =

If the query specifies one partition key, instead of scanning the entire column store, we should use the ReadSegments API which reads from one partition only.  This would be much faster and good for point queries.
We should also think about exposing this to non-Spark query API.

This is now implemented on master for exact matches, and verified to speed up these kind of queries.


Having trouble launching tensorboard with HDFS Directory Path mentioned as logdir

When I run the plugin with a local directory, it works well but with the same folder specified as an hdfs path, the plugin does cannot parse the file. I am however able to launch it with the command tensorboard --logdir hdfs://default/user/.../myfolder and it works.  I am using tensorflow version 1.5 and tensorboard version 1.6.

Figured it out, you need to set a few required variables to the environment of the notebook as mentioned in https://www.tensorflow.org/deploy/hadoop.


Installation instructions for SARIF viewer extension references "Visual Studio 2109"

Installation
In Visual Studio 2109, select menu item Extensions > Manage Extensions.
In the tree view, select the Online node.
In the Search text box, type "sarif" and then press ENTER.
In the Microsoft SARIF Viewer tile, select Download.

Hi
we have the same information here: https://github.com/microsoft/sarif-visualstudio-extension/blob/main/Content.md
We will link both in the future.
thanks!


Update DaisyDisk.app to v4.2

Thank you for the contribution. It was merged directly as 37b173607a9d6aa659afc82ff8194886512a243d to keep commit history cleaner. Your contribution is still credited to you.

Also, check out cask-repair, it makes Cask updates like this quite easy (details in CONTRIBUTING)


Sending and receiving file descriptors

Hi, I would like to send/receive file descriptors (unix sockets). I searched the docs but did not find anything, is it possible to do that right now?

Well, it looks like this isn't even supported in regular Unix sockets in rust. Therefore not supported in mio and therefore not supported in tokio.

PRs would of course though be welcome to implement this!


feat: generic byte reader reopen

Pull Request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Please see pull request 199 for background. Reopened here minus Serde which has been added to byte_array of core.

Does this introduce a breaking change?

[ ] Yes
[ ] No

Other information

also can you check if ByteArray doesn't suit all your needs ?

Can you elaborate a bit please? Which part were you thinking of?


chore: 同步 main 最新代码到 next

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.5 out of 6 committers have signed the CLA.:white_check_mark: lyfeyaj:white_check_mark: shujian-cao:white_check_mark: hwaphon:white_check_mark: arcturus011:white_check_mark: BboyZaki:x: gao.ghfgao.ghf seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Add few examples how to use it

Examples and maybe some usecases would be very benefitial. Thank you

Have you seen the example here: https://github.com/sbueringer/kustomize-webhook/blob/master/deploy/webhook.yaml ?
P.S.: I'm not sure how advisable it is to depend on this repository. I probably won't really maintain it, I just use it for my purposes

@sbueringer ok, too bad, project looks promising :)


Allsky common

Move common functions and code blocks in capture.cpp and capture_RPiHQ.cpp into a new "allsky_common.cpp" file.
Updated allsky.sh to use common EXIT codes and act accordingly.
I have tested with my ZWO and RPiHQ cameras, but I urge you to test as well.

check: clone PR, install, start,... looks fine.

@AndreasLMeg Does your test system have all the files from the PR?  And it's currently running?  If so, I agree we should wait a couple days to make sure the day/night changes work at least as well as they did before this PR.
Assuming it goes well, you ok if I merge the PR?

@EricClaeys
The test of the last few days was successful (local only, no ftp)
Note: My comments were for information only. I see no direct need for action.
This means: You can accept/merge the PR without further changes.


CMake: project() problem (with PROJECT_NAME et al.) in subprojects (IDFGH-1321)

Environment

IDF version (run git describe --tags to find it):
[latest version on master] 2c55fae6cf8de7f9776840b533acfc31e2de1b24
Build System: CMake
Operating System: Linux

Problem Description
In CMake, after a project() in a subproject (added via add_subdirectory()), PROJECT_NAME (and PROJECT_VERSION, etc.) are not set correctly.
I'm happy that the newer versions try to restore project(); however, something's not right.
Suppose you modify the hello_world's top-level CMakeLists.txt to::
# The following lines of boilerplate have to be in your project's
# CMakeLists in this exact order for cmake to work correctly
cmake_minimum_required(VERSION 3.5)

include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(hello-world)

add_subdirectory(foo)

and you make a foo/CMakeLists.txt file:
cmake_minimum_required(VERSION 3.5)

project(foo)
message("PROJECT_NAME = " ${PROJECT_NAME})

You get PROJECT_NAME = hello-world, instead of PROJECT_NAME = foo.
I'm not sure what's going on, but it can be a problem with third-party code. (E.g., code I'm importing has write_basic_package_version_file() (from CMakePackageConfigHelpers) failing since PROJECT_VERSION isn't defined.)
Expected Behavior
See above.
Actual Behavior
See above.
Steps to repropduce
See above.

Thank you for bringing this to our attention. A fix for this is in the works.


Publish Windows Binaries

Hi
Would it be possible to publish the windows binaries as i am finding i cant build them ?
Maybe relates to expected SDK, not sure.
THanks

See the *.zip files at https://github.com/lucasg/Dependencies/releases.
Honestly, though, I didn't find them either on my first contact with this project.
Even though the "Installation and Usage" paragraph in the readme states "Just click on one of the release numbers above", I'd suggest adding a big "Download" button at the top of the readme.
At least I didn't skim the rest of the readme after I saw the big screenshot and determined that this program is exactly what I needed.

@GregB-Roberts , @ComFreek : do you talk about https://github.com/lucasg/Dependencies or https://lucasg.github.io/Dependencies/ when you say the download link should be bigger ?
Anyway I've bumped up the download link at the top of the page.

@lucasg I didn't even know https://lucasg.github.io/Dependencies/ existed. I am not sure if linking to it from the repo readme is useful since it essentially provides the same information just in a more beautiful way.
Anyway, the download links in both cases look fine now! Thanks!

Thanks! Great tool and fast
From: ComFreek<EMAIL_ADDRESS>Sent: Wednesday, 25 July 2018 4:14 PM
To: lucasg/Dependencies<EMAIL_ADDRESS>Cc: GregB-Roberts<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [lucasg/Dependencies] Publish Windows Binaries (#25)
@lucasghttps://github.com/lucasg I didn't even know https://lucasg.github.io/Dependencies/https://lucasg.github.io/Dependencies/ existed. I am not sure if linking to it from the repo readme is useful since it essentially provides the same information just in a more beautiful way.
Anyway, the download links in both cases look fine now! Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/lucasg/Dependencies/issues/25#issuecomment-407645132, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVtWNNGLqq1U0_06A5gYhQEqBE7SPjqMks5uKAy5gaJpZM4VaX7f.

This email has been scanned by the Symantec Email Security.cloud service.

The Schneider Electric industrial software business and AVEVA have merged to trade as AVEVA Group plc, a UK listed company. The Schneider Electric and Life is On trademarks are owned by Schneider Electric and are being licensed to AVEVA by Schneider Electric. Please visit

AVEVA Group plc is registered in England at High Cross, Madingley Road, Cambridge, England CB3 0HB. Number 2937296.


feat: port Data.Option.Defs

Hadn't seen that you already opened a PR, I think the procedure is to add yourself to the wiki-list as soon as you start working it.

You're right, I did it late last night. I have no problems with deferring this PR to your PR.


Add robust retry logic when accessing remote datasets

Accessing data from remote datasets now has retrying logic (with exponential backoff) that should make it robust to occasional bad responses from DAP servers.

This looks very nice and useful.

The maximum retry delay here will be in the range of 32-64 seconds. Does that seem appropriate to you?

Thanks for your comments guys, I'm going to merge this now....


Traits in statistics::traits should not require return type be Option

Many distributions will have some summary statistics regardless of their parameters so Option<T> should not be required, e.g. it is not semantically accurate to require unwrapping the mean of a binomial. Regardless of the sample probability, a valid Binomial type will always have some mean, but student's distribution require at least one dof, cauchy has too much tail and has no mean is never valid.
proposed solution
In lieu of generics, we can use associated types for the statistics::traits::Distribution trait[^renameDistribution]. I don't believe this would bound us in terms of generic numerics in the future either, as long as the associated type could support the generic as well, i.e.
impl<T: Float> Distribution for DistributionType {
    type Mu = T;   // or Vector<T, Dimension, ...>
    type Var = T;  // or TensorCube<T, Const<2>, Dimension, ...>
    type Skew = T; // or TensorCube<T, Const<3>, Dimension, ...>
    type Kurt = T; // or TensorCube<T, Const<4>, Dimension, ...>
}

collapse MeanN and VarianceN into statistics::traits::Distribution and add Covariance and Entropy traits

#208 proposed a way to specify Covariance
rely on unimplemented!() over None when more correct. Defaulting to None when we don't have a simple expression isn't correct (may also be a little more motivating for someone to implement it over panicking).
would have to implement Covariance on matrices, Cholesky decompositions, vectors, and likely floats.

types for skewness and kurtosis will be higher order tensors than nalgebra can accomodate. so the signature could have return type of never ! before being plain ol' unimplemented!() before being implemented.

Sample code of the traits I propose adding.
pub trait Moments<T: Float> {
    type Mu;
    type Var: Covariance<T>;
    type Kurt;
    type Skew;
    fn mean(&self) -> Self::Mu;
    fn variance(&self) -> Self::Var;
    fn std_dev(&self) -> <Self::Var as Covariance<T>>::V;
    fn excess_kurtosis(&self) -> Self::Kurt;
    fn skewness(&self) -> Self::Skew;
}

pub trait Covariance<T: Float> {
    type M;
    type V;
    fn dense(&self) -> Self::M;
    fn sparse(&self) -> Self::V;
    fn forward(&self, other: Self::V) -> Self::V;
    fn inverse(&self, other: Self::V) -> Self::V;
    fn determinant(&self) -> T;
}

pub trait Entropy<T: Float> {
    fn entropy(&self) -> T;
}

[^renameDistribution]: I also think renaming it could be helpful, unsure what is better, but since most of them are moments, or central moments, we could make entropy it's own, as entropy is always scalar and have a Moments trait. I think much of this is motivated from reference implementations in Math.NET's interfaces since that's how this project started.

Also going to say that I'm not tied to this implementation, but I align well to the issue title. I don't think it makes sense to return Option for all of them.

I think your proposal is good. It should be a clear benefit to avoid returning Option if it's statically known to not be needed. Some unordered thoughts:

What is the return type of e.g. fn mean for a distribution which has no defined mean. Maybe a unit type ()? Or should these be moved outside of trait Distribution and only be implemented if a distribution supports them?

rely on unimplemented!() over None when more correct

This is great, maybe remove the default implementations of mean etc.[^1] while you're at it. It's not immediately clear if a missing implementation of mean points to it being undefined or not implemented yet. That should probably be handled by the implementor.[^2]

There's a possibility that the new traits don't even need a T: Float trait bound

why is trait Distribution in module statrs::statistics and not statrs::distribution again?

[^1]: Excluding std_dev
[^2]: Another thing: The default implementations have function documentation following the pattern "Returns X, if it exists". But we know that all of these return None unless overridden by a manual implementation (which should have its own, overriding docs) so this text almost always actually means "Returns None"

I hadn't thought of this one, but the API I designed doesn't work well for fallible types,
I can't impl<T> Covariance<Option<T>> for Option<T> separately from impl<T> Covariance<T> for T  because of the standard deviation[^impl_cov_for_option_t]. Standard deviation could be its own trait or simply implemented on types where it is useful[^1], and then I could drop the "note to implementors" on std_dev method, quoted what I came up with below,
[^impl_cov_for_option_t]: I don't think it would be good semantics to do so, even if it is more ergonomic, calling covariance methods in map on Option<T: Covariance> types would be better than Option<f64>::default().forward(1).
[^1]: at the moment, this is my preference.

Note for implementors
Associated types should capture semantics of the distribution, e.g.
[Option] should be used where moments is defined or undefined based on parameter values.
[()] is used for moments that are never defined

I can't impl<T> Covariance<Option<T>> for Option<T> separately from impl<T> Covariance<T> for T because of the standard deviation.

I'm not sure I understand this point.. can you elaborate or maybe give an example? It seems possible but I'm not sure I understand your proposal correctly.

To couple the types for the return of variance and std_dev I have
Type Var: Covariance and the return type of std_dev is <Var as Covariance>::V
Perhaps I should be using the return of variance as the type from dense, Covariance::M, but the other option is not constraining a type relationship between variance and std_dev by removing std_dev or adding another associated type (which I think is unnecessarily flexible).


protoc-gen-fastmarshal doesn't support optional keyword of protobuf3

message info {
string name = 1; // POD name
string addr = 2; // POD IP addr
optional uint32 data = 3;
}
xyz.proto: is a proto3 file that contains optional fields, but code generator protoc-gen-fastmarshal hasn't been updated to support optional fields in proto3. Please ask the owner of this code generator to support proto3 optional.
--fastmarshal_out:

Apologies for the delayed response @rohsaini but I haven't had much time to allocate to OSS lately.
You are correct that we currently don't support proto3 optional fields.  It could be added but it's not something that we (CrowdStrike) needed so it didn't make the cut.
I'd be happy to give input or review a PR if that's something you need.


Allow increasing recursion limit

I am parsing/serializing pretty large JSON files and I regularly encounter RecursionLimitExceeded. I need a way to instantiate a Serializer/Deserializer with a much larger recursion limit.
Could we introduce code to let us tweak that?

Seems reasonable. What do you think the API should look like?

While we iterate on the API in #346, have you been able to figure out the appropriate recursion limit for your use case? If it is not too much more than the current default, we can raise the default without yet making it configurable.

I believe that 1024 should be largely sufficient for my use cases.

Copied from the discussion in #346 -- the most important thing we still need to figure out here:
How to reconcile with an eventual serde_json::Format. I would feel more comfortable if we make more progress on https://github.com/serde-rs/serde/issues/644 before merging this. That issue will involve some data structure that describes JSON as a format, including whether to use indentation when serializing and presumably the recursion limit for deserializing. It may turn out to be a better API to treat that data structure as a builder for serde_json::Deserializer, rather than having builder methods directly on Deserializer.

Any progress/changes here? I've got a project (https://github.com/remexre/extlint) that's storing an OCaml AST in JSON; since in OCaml's AST, a list is transformed into a series of conses (i.e. [1; 2; 3] and 1 :: (2 :: (3 :: ([]))) have the same AST representation), which blows the recursion limit for a list literal of length 50.
I'm fine manually increasing the stack size, but being able to handle this is a high priority. Is the best solution still to apply #346 to the current master and add a note in my README that we use this custom version?

This problem has caused me to switch to json-rust. Doesn't do nearly as many things as serde json, but it doesn't share this specific issue.

Yeah, I need serde for the project though, since I'm essentially transforming JSON -> Rust datastructure -> Custom serialization and I don't wanna write a custom Serialize for each AST node type.

Fixed in 1.0.38: Deserializer::disable_recursion_limit


Update docs version automatically

There is a version in docs/conf.py that is not updated automatically at the moment

Attempt was made to fix this


Initial Values Added to Masked Text Box Placeholder Overlayed

Loading in an initial value into a text box with the library enabled will mean the placeholder is drawn under the text.
I tried to call various events to fix this issue but found a small change to the code based worked by hiding the placeholder if there is already a value in the text box:
createShell : function (t) {
  ....

    mask.appendChild(emphasis);
    //Don't add placeholder if data already exists
    if (t.value.length == 0) {
        mask.appendChild(placeholder);
    }

   ....

  }

I made a proper fix in this pull request:
https://github.com/estelle/input-masking/pull/16

Thank you

I just masked initial text in the filed at activateMasking  t.dispatchEvent(new Event("input", { bubbles: false, cancelable: false }));