[Admin] Replace Core Concepts landing page

Replaced PR https://github.com/OfficeDev/office-js-docs-pr/pull/1918.

Docs Build status updates of commit 7ced365:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/images/i_code-blocks.png
:white_check_mark:Succeeded
View

docs/images/i_deploy.png
:white_check_mark:Succeeded
View

docs/images/i_design.png
:white_check_mark:Succeeded
View

docs/images/i_recommended-testing.png
:white_check_mark:Succeeded
View

docs/overview/core-concepts-office-add-ins.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Use Export/Version on package-info to describe the OSGi meta-data

Thanks for submitting this @stbischof. Could you please also log an issue in our tracker that describes this enhancement, and link it to your PR? Also, given that this is an enhancement rather than a bug fix, if would be good if you could rebase this against the develop branch.
Originally posted by @jeenbroekstra in https://github.com/eclipse/rdf4j/issues/3736#issuecomment-1073126062

@laeubi can you give some background on what this improvement actually does? I don't know a lot about a OSGi - how does this improvement benefit developers who use OSGi?

@laeubi maybe you should copy the MANIFEST.MF file that is generated here. There you will see that we mainly generate manifest-entrys that describe whick packages are exported (for externat use). without this enty an osgi framework will not be able to load the jar and/or gives other classes that import rdf4j access to not exported classes..

I have recently seen https://github.com/eclipse/rdf4j/commit/eb239114cc33fab91baa67007ae06317ab9416cf (revert incompatible changes to interface) The version annotations, together with BND-Baseline plugin can be used to enforce Semantic Versioning 2.0.0, so maybe this would be interesting for RDF4j even though it does not use OSGi directly (yet)?

I have recently seen eb23911 (revert incompatible changes to interface) The version annotations, together with BND-Baseline plugin can be used to enforce Semantic Versioning 2.0.0, so maybe this would be interesting for RDF4j even though it does not use OSGi directly (yet)?

We actually use the japicmp maven plugin to verify semver compliance in our code base.
I wouldn't be against using OSGi for this (and other) purposes, but nobody has ever been able to satisfactorily explain to me what OSGi is for, and what benefits adopting it would give us. Then again the problem has always been that there's really no one with OSGi expertise on our core team, so if you're interested in being our resident expert, I'd love to hear more :)


Unary Ops Test: Fixes gradient method call for tf.floor

This PR fixes gradient method call to dl.floor in unary ops tests.

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable


Unreachable 'break' after 'return'

Challenge Selecting from many options with Switch Statements has an issue.
User Agent is: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:
function myTest(val) {
  var answer = "";
  // Only change code below this line
  switch(val) {
    case 1:
      return "alpha";
      break;
        case 2:
      return "beta";
      break;
        case 3:
      return "gamma";
      break;
        case 4:
      return "delta";
  }

  // Only change code above this line
  return answer;
}

// Change this value to test
myTest(1);

Please ask your queries at Help Chat, GitHub Issues are for bugs in the site only.

Good luck and happy coding!


Create MCQA for Array.reduceRight() method

Please create an MCQA to be added as question number 28.
The multiple choice question should be on the topic .reduceRight() method of an array. The difficulty level should be "Medium/Hard"
Tasks:

[ ] add your code to 028 folder under code
[ ] add your question to 28 in README.md file
[ ] create a video explanation (optional)

Sample interview question for inspiration

What is the difference between reduce() and reduceRight()?

reduceRight() loops from right to left

Plz assign to me.


Add spec reproducing issue with custom type with and nested hashes validation

This is meant to reproduce an issue where custom types in nested hashes do not take effect.
This is my first time with this project, I hope the spec is in the right place. If not I'd be happy to move it to the appropriate place.
This PR is related to this Issue: https://github.com/dry-rb/dry-schema/issues/396
I tried but could not figure out how to get it to pass.

@flash-gordon  I tried to get the spec to pass but had a very hard time following the code, if you could point me in the right direction I'd be happy to try again.
For example, what file or files would need to change to make it pass.

I didn't mean making it pass :) Just make it pending by changing specify to xspecify, it'll stop failing the CI.

I didn't mean making it pass :) Just make it pending by changing specify to xspecify, it'll stop failing the CI.

I added the pending to the spec.
But I'd be happy to work on it if someone could point me in the right direction.

Your type crashes, that's why it doesn't work:
(byebug) Test::ExpirationDate["2021-11-11T00:00:00+00:00"]
*** Dry::Types::CoercionError Exception: undefined method `to_time' for "2021-11-11T00:00:00+00:00":String
Did you mean?  to_i

If you change it so that it does DateTime.parse(value), the spec will pass.
@flash-gordon it seems like Safe constructor rescues silently this crash though - THAT is probably a bug 🙂

Your type crashes, that's why it doesn't work:
(byebug) Test::ExpirationDate["2021-11-11T00:00:00+00:00"]
*** Dry::Types::CoercionError Exception: undefined method `to_time' for "2021-11-11T00:00:00+00:00":String
Did you mean?  to_i

If you change it so that it does DateTime.parse(value), the spec will pass.
@flash-gordon it seems like Safe constructor rescues silently this crash though - THAT is probably a bug 🙂

Thank you! I think that definitely cleared it up. And yeah the silent failure is certainly confusing to users of the library.
I'll close this PR.


type references between CommonJS modules are not recognized

According to the wiki, it should be possible to reference types from other modules:
var A = require('a').A;
/**@type{A}*/
var a = new A();

var a = require('a');
<EMAIL_ADDRESS>var my_a = new a.A();

This seems to be broken in Closure Compiler 20160911. The files and command below can be used to reproduce the problem.
a.js
/**
 * @constructor
 * @param {!number} size
 */
function A(size) {
    this.size = size;
}
exports.A = A;

b.js
var A = require('a').A;

/**
 * @constructor
 * @param {!A} a1
 */
function B(a1) {
    this.a1 = a1;
    this.a2 = new A(10);
}
exports.B = B;

c.js
var b = require('b');
var a = require('a');
new b.B(new a.A(10));

$ java -jar compiler.jar --process_common_js_modules --jscomp_error checkTypes \
    --entry_point c.js --js a.js --js b.js --js c.js --js_output_file out.js
b.js:5: ERROR - Bad type annotation. Unknown type A$$module$b
 * @param {!A} a1
            ^
1 error(s), 0 warning(s)

The imports need to be constants for this to work:
/** @const */
var A = require('a').A;

I changed b.js as you indicated and still get the same error.

@vandenoever Did you change 'c.js' as well?

Also, the require statements have to be relative or absolute paths:
/** @const */
var A = require('./a').A;

I have. I'm using relative paths now. Leaving out the ./ did not hinder compilations without the @param annotation. Using @const and paths that start with ./ does not fix the issue for me.
I'm running Linux 4.4 with OpenJDK 1.8.0.
I've tried both var A = require('./a').A; with @param {A} and var a = require('./a'); with @param {a.A}. @param {./a.A} is also not recognized.

This is the test code with your hints applied.
a.js
/**
 * @constructor
 * @param {!number} size
 */
function A(size) {
    this.size = size;
}
exports.A = A;

b.js
/** @const */
var A = require('./a').A;

/**
 * @constructor
 * @param {A} a1
 */
function B(a1) {
    this.a1 = a1;
    this.a2 = new A(10);
}
exports.B = B;

c.js
/** @const */
var b = require('./b');
/** @const */
var a = require('./a');
new b.B(new a.A(10));

java -jar compiler.jar --process_common_js_modules --jscomp_error checkTypes \
    --entry_point c.js --js a.js --js b.js --js c.js --js_output_file out.js
b.js:6: ERROR - Bad type annotation. Unknown type A$$module$b
 * @param {A} a1
           ^
1 error(s), 0 warning(s)

Is there a module system where this does work in Closure Compiler, perhaps with an example?

@vandenoever I think goog.module should work, although technically CommonJS should also work.

I'll take a look this weekend with the repo case posted.

So this is super tricky and not at all obvious: the export must be const.
/**
 * @constructor
 * @param {!number} size
 */
function A(size) {
  this.size = size;
}
/** @const */
exports.A = A;

Also, the entry point is a module name - not a file name:
java -jar compiler.jar --process_common_js_modules --jscomp_error checkTypes \
    --entry_point=c --js a.js --js b.js --js c.js --js_output_file out.js

That works fine. It's indeed not so obvious. I'm happy that it works now.
This issues can hopefully help others to use CommonJS with Closure Compiler.

The @const is automatically added to module.exports, but apparently not just exports. I have work in progress that should make this smoother.

I've found another case where type exporting does not work. Here are a working goog version and a corresponding CommonJS modules version which does not work.
goog modules
a.js
goog.provide("a");
/**
 * @constructor
 */
a.A1 = function() {}
/**
 * @constructor
 */
a.A2 = function() {}
/**@typedef{Object.<string,string>}*/
a.A3;

b.js
goog.provide("b");
goog.require("a");

/**
 * @constructor
 * @param {a.A1} a1
 */
b = function(a1) {
    this.a1 = a1;
    this.a2 = new a.A2();
    /**@type{!a.A3}*/
    this.a3 = {};
}

java -jar compiler.jar --entry_point goog:b --js_output_file out.js --jscomp_error checkTypes a.js b.js

CommonJS
a.js
/**
 * @constructor
 */
function A1() {}
/**
 * @constructor
 */
function A2() {}
/**@typedef{Object.<string,string>}*/
var A3;
/**@const*/
exports = {
    A1: A1,
    A2: A2,
    A3: A3
};

b.js
var a = require('./a');

/**
 * @constructor
 * @param {a.A1} a1
 */
b = function(a1) {
    this.a1 = a1;
    this.a2 = new a.A2();
    /**@type{!a.A3}*/
    this.a3 = {};
}
/**@const*/
exports.B = B;

$ java -jar compiler.jar --process_common_js_modules --entry_point b --js_output_file out.js \
    --jscomp_error checkTypes a.js b.js
b.js:5: ERROR - Bad type annotation. Unknown type a$$module$b.A1
 * @param {a.A1} a1
           ^

b.js:10: ERROR - Bad type annotation. Unknown type a$$module$b.A3
    /**@type{!a.A3}*/
              ^

2 error(s), 0 warning(s)

That is not a valid way to export common js symbols. You didn't export anything - you just redefined the exports variable. This is one of the reasons commonjs rewriting is hard for the compiler. Here's your test case in NodeJS:
a.js
/**
 * @constructor
 * @param {!number} size
 */
function A(size) {
  this.size = size;
}
exports = { // This assignment is wrong - it doesn't actually export
  A: A
};

c.js
/** @const */
var a = require('./a');

console.log((new a.A(4)).size);

output
$ node c.js
/Users/chad/git/closure-compiler/c.js:5
console.log((new a.A(4)).size);
             ^

TypeError: a.A is not a constructor
    at Object.<anonymous> (/Users/chad/git/closure-compiler/c.js:5:14)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Function.Module.runMain (module.js:575:10)
    at startup (node.js:160:18)
    at node.js:456:3

See https://nodejs.org/docs/latest/api/modules.html#modules_module_exports

Ok, good to know. I tried some variations also does not work. I've ported quite some code from a custom module system to CommonJS with Closure Compiler now. The @typedef is where I'm currently stuck.
/**@typedef{Object.<string,string>}*/
var A3;
modules.export.A1 = A1;
modules.export.A2 = A2;
modules.export.A3 = A3;

I haven't tried exporting typedefs personally, but I seem to remember someone else complaining it's a problem. Typedefs are kind of weird because they are just type information to the compiler.
Regardless, your test case should look something more like:
/**@typedef{Object.<string,string>}*/
var A3;
module.exports.A1 = A1;
module.exports.A2 = A2;
module.exports.A3 = A3;

But again, I don't know if that actually works or not.

Right, the modules.export instead of module.exports was a typo in the comment, not in the code I tested. @typedefs indeed do not work. I might be able to work around that by copying the definition in the modules that use the type.
Shall I open a separate issue for @typedef?


Integrate a (container) monitoring/management solution

[x] Integrate metrics + prometheus
[x] Integrate alert manager + slack notifications
[x] Integrate grafana dashboard
Defined relevant alerts in alert manager

[ ] container/service down
[ ] memory/cpu/disk consumption on host

Intersting:

http://rancher.com/comparing-10-container-monitoring-solutions-rancher/
http://rancher.com/comparing-monitoring-options-for-docker-deployments/
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html
https://blog.codeship.com/docker-guis/
https://www.midvision.com/10-open-source-docker-tools-you-should-be-using/

Started PoC on https://github.com/kalisio/kaabah with traefik + portainer. We should add promotheus for alerting and enhanced stats.

https://github.com/stefanprodan/dockprom
https://github.com/stefanprodan/swarmprom

Linked to https://github.com/kalisio/kApp/issues/35

Since kApp is now able to be deployed on a Kaabah infrastructure we can close this issue. Check out https://github.com/kalisio/kaabah


Fix typo.

Just a small typo fix for CONTRIBUTING.md.

Thanks a lot for taking the time to correct this!


error prone fix suggestion rejected by google-java-format

Running most recent EP on latest gerrit flagged this warning:
java/com/google/gerrit/pgm/http/jetty/ProjectQoSFilter.java:151: warning: [ClassCanBeStatic] Inner class is non-static but does not reference enclosing class
  private final class Listener implements ContinuationListener {
                ^
    (see http://errorprone.info/bugpattern/ClassCanBeStatic)
  Did you mean 'private static final class Listener implements ContinuationListener {'?

Running gjf (version 1.3) rejected the suggested fix:
diff --git a/java/com/google/gerrit/pgm/http/jetty/ProjectQoSFilter.java b/java/com/google/gerrit/pgm/http/jetty/ProjectQoSFilter.java
index 61a94bde3d..260f695a6e 100644
--- a/java/com/google/gerrit/pgm/http/jetty/ProjectQoSFilter.java
+++ b/java/com/google/gerrit/pgm/http/jetty/ProjectQoSFilter.java
@@ -148,7 +148,7 @@ public class ProjectQoSFilter implements Filter {
   @Override
   public void destroy() {}

-  private final static class Listener implements ContinuationListener {
+  private static final class Listener implements ContinuationListener {
     final Future<?> future;

     Listener(Future<?> future) {

Never mind, i messed something up here.


Security management related fixes

Fixes+tests for some of the issues reported recently by QE
@romartin Can you review and ack please?

+1

@dgutierr  could you please take a look on this minor fixes?

@ederign Done.

thanks @dgutierr


Traefik OOM when in use with http01 challenges and cert-manager

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?
We're using traefik as an k8s ingress controller on multiple of our clusters. In one of these clusters, we manage > 3000 TLS-certificates with cert-manager. The renewal is done with http01 challenge.
Because of some issue with cert-manager in the past, the distribution of certs over the complete timespan (60d) is currently very uneven. On some days, with a lot of scheduled renewals (> ~ 150), we see traefik pods struggling with OOM kills and disruptions in the service. We help ourselfs with throwing more resources (and with that more money) at the cluster, but nonetheless traefik pods die and with that some requests are not processed properly.
We'd like to understand, why the http01 challenges cause so much memory usage and learn about ways of mitigating this issue.
What did you see instead?
We see traefik pods collapsing under the "load" of the http01 challenges with that disruptions in the service.
As seen in the picture, the memory load is very varying (the 32 instances of traefik-pod occure b/c we're using the HorizontalPodAutoscaler).

What version of Traefik are you using?
Container ID:  docker://909716563a6083c5c3422c421c701a9cca7c9484aa04aab24968ead6cb414b24
Image:         traefik:2.7.0

What is your environment & configuration?
traefik-ingress:
    Container ID:  docker://909716563a6083c5c3422c421c701a9cca7c9484aa04aab24968ead6cb414b24
    Image:         traefik:2.7.0
    Image ID:      docker-pullable://traefik@sha256:433f851c0abcaa5999301c46d7129a96a6df95a52d09f16847b00ce5f7c1b6ae
    Ports:         9100/TCP, 9000/TCP, 8000/TCP, 8443/TCP
    Host Ports:    0/TCP, 0/TCP, 0/TCP, 0/TCP
    Args:
      --entrypoints.metrics.address=:9100/tcp
      --entrypoints.traefik.address=:9000/tcp
      --entrypoints.web.address=:8000/tcp
      --entrypoints.websecure.address=:8443/tcp
      --api.dashboard=true
      --ping=true
      --metrics.prometheus=true
      --metrics.prometheus.entrypoint=metrics
      --providers.kubernetescrd
      --providers.kubernetesingress
      --entrypoints.websecure.http.tls=true
      --log.level=INFO
      --accesslog=true
      --accesslog.fields.defaultmode=keep
      --accesslog.fields.headers.defaultmode=drop
      --api
      --api.insecure
      --api.dashboard
      --metrics.prometheus=true
      --providers.kubernetesingress.ingressendpoint.publishedservice=traefik-ingress/traefik-ingress
      --serverstransport.insecureskipverify=true
    State:          Running
      Started:      Fri, 21 Oct 2022 12:02:02 +0200
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1800m
      memory:  3500Mi
    Requests:
      cpu:        1300m
      memory:     3500Mi

If applicable, please paste the log output in DEBUG level
No response

Hey @grieshaber , If you have the resources to spare for a little bit, there's one way that would greatly help us in knowing whether we have to suspect a memory leak.
If it's a memory leak, no matter how much resources you throw at the pod, it's eventually always going to OOM. However if it's "just" high memory usage, there has to be a point where the pod has enough memory to sustain the load. Do you think you could afford to investigate that for us?

Hey @mpl - unfortunately, that is not so easy. It only occurs on the productions environment of one of our customers where the amount of certificates is significantly higher than on any test system we have.
The next time when it occurs will be 60 days from now (when the certificates will be renewed). But ideally, we want to achieve a better distribution of the certs renewal date by then and avoid the "broken" situation we had last week. When the issue occurs, the customers observes severe impact to its production system.
We're planing several improvements (better distribution, seperation of traffic etc. onto multiple ingress classes etc.). This will (hopefully) solve the issue for us, but the root cause may still exist.
We increased the amount of RAM three times already (currently ~3GB) and also increased the number of replicas of traefik pods - i'd assume, that "normally" the pods should tolerate the amout of ram available. Just "high mem usage" should, imho, be resolvable with scaling horizontally instead of vertically.. But, never the less, is there an amount of RAM you suggest as some sort of best practice or something?

Hey @grieshaber,
Thanks for your answer and the additional information.

is there an amount of RAM you suggest as some sort of best practice or something?

It is complicated to give you an answer, it depends on some parameters such as the number of requests per second, the middlewares used, the dynamic configuration refresh frequency, and the number of resources managed by Traefik (secrets, Ingress, etc).
To help us to move forward on the issue:

Could you update your Traefik version to v2.9 to check if it fixes the issue?
Could you provide the logs when the OOM occurred, and a reproducible environment (manifest files)?

Hey @nmengin, sorry for the delay. We finally updated to v2.9 - so far, avg memory on days with only a few renewals look similar. We'll observe what happens when the huge number of certs will be renewed and try to grab some logs.
I'll paste the manifests for reproduction later this day.


Use of this package in meteor

Hi, can anyone help me on how to use this package with Meteor? I properly installed it, but I can't figure out how to add theses helpers to recognized standard helpers used by the meteor version of Blaze...

Looks like the Blaze Templates docs has information on registering helpers.
Individual templates have a .helpers method that takes an object.
Looks like you'll have to loop over all the keys on the returned helpers object from here and register each directly if you want to use the .registerHelper method.
You should ask this on stack overflow also to get more eyes on it.


Custom layouts dir

From this line https://github.com/nuxt/nuxt.js/blob/fbca3d7f78da1edb04bde21fddcc981f562f8fb4/lib/build.js#L148
It seems layouts can only be loaded from srcDir/layouts, is there any chance to add a layoutDir option in nuxt config?  My use case is that I want to put all pages in srcDir but put layouts elsewhere.

Hi @egoist
We don't support this since we want more convention than configuration.
What you can do it to keep the layout folder and import your layouts from there directly, so everyone who knows the doc of nuxt will know how to use your project :)


Is it posible to set the ambient_light setting via an automation?

Just purchased a Winix and installed this package...working well, however it took me some time to realize that just because the preset_mode was in "sleep" didn't mean that it wasn't in "auto" mode.  Please correct me if I'm not understanding this correctly.
This isn't an issue, but rather a question - is it possible to set the ambient_light attribute through a service call of some sort?  I've noticed this go up and down and would like it as low as it can go at night if possible.  Thanks!

Sorry, the ambient light cannot be set from the mobile App which is what the underlying library is based on.


Redo "Add per-queue stats for rabbitmq"

This reverts commit b3b46fa595619293dd0ca314b309e493edf986be.

"Revert the revert of "Add per-queue stats for rabbitmq""
Add missing dependency that was breaking the dev VM

The original PR is https://github.com/alphagov/govuk-puppet/pull/4304
Reverted by https://github.com/alphagov/govuk-puppet/pull/4309
Part of: https://trello.com/c/Ipl9UVsA/578-monitor-rummager-s-current-queue-size-with-statsd-graphite-m
The dev VM was breaking with this error: Error: Could not find dependent File[/etc/collectd/conf.d/rabbitmq.conf] for File[/usr/share/collectd/types.db.rabbitmq] at /var/govuk/govuk-puppet/modules/collectd/manifests/plugin/rabbitmq.pp:25
This is because the file we create requires a directory owned by the collectd package, so we need an explicit dependency on this.
The only difference from the previous pull request should be +    require => Package['collectd-rabbitmq'],.

Seems like this is still running into problems :sob:
Error: Could not find dependency Package[collectd-core] for File[/usr/share/collectd/types.db.rabbitmq] at /var/govuk/govuk-puppet/modules/collectd/manifests/plugin/rabbitmq.pp:27

This is now working on expected on the dev VM, as well as a freshly created rabbitmq-1.backend VM.
The previous attempt at this caused some problems in development
because we were running collectd plugins on nodes where we didn't
install the collectd package.
On dev, we disable a lot of monitoring functionality, so that's why the problem only occurred there.
We now use an explicit require dependency and use virtual resources so that the plugins are only set up when collected into the collectd::plugins class.
@tijmenb @benhyland

Heroes! :+1: when tests are green.


[AutoPR storSimple1200Series/resource-manager] typo: storSimple1200Series/resource-manager/Microsoft.StorSimple

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/4806

This PR has been merged into https://github.com/Azure/azure-sdk-for-js/pull/836


Run exec commands as specified user

When running exec commands from a devFile within a container we may need to run the commands as a different user to the user that is the default user within the container. I am therefore proposing we have a runAsUser within the exec, for example:
commands:
  - exec:
      id: init-deps
      name: init image dependancies
      component: java-openliberty-build
      commandLine: /project/bin/init-stack.sh
      runAsUser: root
 - exec:
      id: stack-prep
      name: stack-prep
      component: java-openliberty-build
      commandLine: /project/bin/run-stack.sh prep
      runAsUser: java_user
  - composite:
      id: setupContainer
      commands:
        - init-deps
        - stack-prep
      parallel: false
      group:
        name: init
        isDefault: true

So in this example there is a need to run some setup that requires to be run as root, and then some other setup that needs to be run as java_user.
It is not easy to switch userids within a shell script (bash) then different shell scripts need to be run and need to be run as different userids.

That would be useful but we need to be cautious. Running as root may work on some Kubernetes clusters and not on others with more restrictive security policies. That would lead in situations where a devfile works on one cluster and fails on another one...
cc @elsony @kadel @davidfestal what do you think?

I see the usefulness here as well, but agree with @l0rd; this would be exclusively Kubernetes functionality, as runAsUser is typically not possible on OpenShift clusters (nor Kubernetes clusters for some configurations). The general recommendation on Kubernetes is to not allow running as root, as well. In general, relying on the default user for a container has been nothing but a headache for me.
However, it might also unblock some use cases, so it's definitely worth considering.

Reviewed and approved

For the records PodSecurityContext has runAsGroup and others fields. I think that for our use case and to keep things simple enough I would not add those ones in this first 2.0.0 release.

I started implementing the mode here, but now I have a question:
The exec command is mainly to execute a command line in an already-existing and already started container.
How could we change the userId the container is running as ?
Shouldn't this runAsUser information be in the container component itself ?

@davidfestal yes you are right

How could we change the userId the container is running as ?

we cant' The only way how we could execute the command as a different user would be using sudo or su. But we can't do that, those binaries might not be in the container, and also I'm not sure if OpenShift with default securityContext would allow this.

Shouldn't this runAsUser information be in the container component itself ?

+1

Community call discussion 3/28:

No plan to implement. In general, it is problematic to implement running as a specific user. Some of the managed Kubernetes may not even allow switching to some users, e.g. root.
It is generally not a good practice to run containers as root users and it should be avoided if possible. See https://www.redhat.com/en/blog/understanding-root-inside-and-outside-container for reference.


Make page smaller overall

Received feedback that the content appears very large on the screen, which I agree with

refer to college app case study figma for sizing adjustments (overall smaller font, thinner navbar)


HyperLinkButton cannot navigate to an email URI

Describe the bug
In my application, I added a HyperLinkButton with a mailto: navigation URI for users to submit inquiries, which looked like this:
<HyperlinkButton Content="hyperlink"<EMAIL_ADDRESS>/>
However, I clicked the button, and nothing happened.
Steps to reproduce the bug

Create an empty Windows App SDK 1.2 packaged app
Add a HyperLinkButton as shown above
Run the application and click the button

Expected behavior
The default email application should launch and ask you to send an email.
Screenshots
No response
NuGet package version
Windows App SDK 1.2.2: 1.2.221209.1
Packaging type
Packaged (MSIX)
Windows version
Insider Build (xxxxx)
IDE
Visual Studio 2022
Additional context
No response

There was a similar issue : Hyperlinkbutton not working with uri of type<EMAIL_ADDRESS>#4438

Closing as dupe of https://github.com/microsoft/microsoft-ui-xaml/issues/4438, thanks @castorix for linking


Fix enable_legacy_abac issue #79

Added
resource "google_container_cluster" "cluster" {
  enable_legacy_abac = var.enable_legacy_abac
  ...
}

in file modules/gke-cluster/main.tf block resource "google_container_cluster" "cluster" {...}
fix issue #79

Thanks for your contribution and apologies for the long delay in getting back to you on this! Can you rebase on master to get all the test fixes in? At that point, we should be able to get a green build to merge this in.

Sorry for the long answer. Rebase is done. All tests passed.

Thanks! Just kicked off a build.

Ok the build passed, so will go ahead and merge this. Thanks for your contribution!


Drop and recreate MySQL and ES.

I'd like to drop and recreate MySQL and ES schema while developing the Python part of OM. I don't have to do it so often in Java because the Java unit test class is doing it for me.
I was trying to use bootstrap/bootstrap_storage.sh but it complains that the directory libs doesn't exist.
I was thinking to change the code of the script like this:
LIBS_DIR="${BOOTSTRAP_DIR}"/../libs/
if [ -d "${LIBS_DIR}" ]; then
  for file in "${LIB_DIR}"*.jar;
  do
      CLASSPATH="$CLASSPATH":"$file"
  done
else
  CLASSPATH=`mvn -pl catalog-rest-service -q exec:exec -Dexec.executable=echo -Dexec.args="%classpath"`
fi

WDYT?

@amiorin That sounds good to me.


add jitter argument to gp models

From a discussion with @Sayam753, cholesky decomposition fails with tf.float64 datatype when tf.math.nextafter is used. This PR removes this from stabilize function and instead lets user choose the amount of noise to add via a jitter argument in prior and conditional methods.

requesting @AlexAndorra to merge (if no other comments or changes required...).

We gave it 24 hours --> merging 🎉


wasm-pack should check if it's the latest version and warn if not

when you run build, wasm-pack should check and see what version is latest on crates.io and if the current installed version is latest. if not, it should suggest the user update.

I would love to work on this one!

@daubaris: Hey, I discussed this very briefly on IRC with @ashleygwilliams. One approach to this is to check the behavior of the npm client or yarn and see what they output for outdated packages. Npm outputs something like: "npm WARN ..." with a yellow background and black text. Yarn outputs something like: "warning ..." in yellow text. So maybe, the text could be something like: "warning (in yellow) :warning: There's a newer version of wasm-pack available, the new version is x.x.x and you're using version x.x.x".
Regarding the approach to this issue. I first had the idea of using something like hyper for this. Make a request to the crates api and fetch the latest version of the crate and then compare that to installed one. However, wasm-pack already depends on the curl crate so I think that's a better choice. So, use curl to fetch the latest version of the crate from the crates api and then compare that version with the locally installed one, then output a warning if there's a newer one available.
This is my understanding of the feature request, so anyone, please correct me if I'm wrong.

closed by #409


hooking to jest require mechanism

Hello jest people and thanks for open-sourcing and maintining this delightful framework.
I am working on an auto-instrumentation library for jest for the opentelemetry project, to support automatic collection of traces while running local/distributed tests with jest. By collecting traces, a developer can examine internal and remote events that occurred for each test, which can aid debugging (and maybe in the future also trace-based assertions).
to implement the "auto-instrumentation" magic, open-telemetry-js sdk is using [require-in-the-middle] package to be notified on module imports and patch instrumented libraries. This is done by modifying the moudleExports object before it is returned to the "require"ing app. To my understanding, jest is replacing the "require" implementation as well, in a way that breaks require-in-the-middle integration.
Is there any mechanism in jest that can be used to register and get notified on requires that jest is performing? Tried to look into the implementation in jest-runtime package, but couldn't spot anything relevant.
Maybe jest can be configured to use the original nodejs require function? (hoping it will not break anything else in the framework)
Any help on that will be very appreciated
Other discussions relevant to this issue:
https://github.com/facebook/jest/issues/7722
https://github.com/elastic/require-in-the-middle/issues/50

Another option that crossed my mind is for "require in the middle" to somehow patch the jest require function like it is currently doing:
  this._require = Module.prototype.require = function (id) {

Maybe the Module.prototype.require patching can be replaced with a relevant jest object that exposes the same interface? Can someone experienced with jest recommend what this object and function might be?

Using the "real" require is not gonna happen as that breaks the sandbox, mocking, transpilation etc (basically all that makes Jest different from Mocha or Jasmine bar watch mode).
What you could do here is use a custom transformer. You'd then insert source code which does the instrumentation. This would also work with native ESM, which a require based approach cannot.
If a custom transformer is not feasible (i.e. you want people to be able to use TS or whatever) you'll probably need to plug in your own runtime as you briefly mention (option is called moduleLoader). This is undocumented, but I'd start by extending the one exported from jest-runtime. In there you can add code to either _loadModule (for CJS) or loadEsmModule (for ESM) to do whatever you want. I'm not sure how much you can really do, though. Please experiment! 🙂

You can work around require with a jest-runtime, and you can get the tracing code called. However, it still doesn't produce spans, for me. The tracing code believes there's no active context, so creates NoopSpans. I wonder if jest is also interfering with the async context (I'm on 14 so using the 'modern' provider), or if the library is fundamentally broken with Contexts.
Some experiments https://github.com/FauxFaux/jest-otel , but you can't really see anything unless you breakpoint around https://github.com/open-telemetry/opentelemetry-js/blob/c0b021be5782ebee6a23015c992dc496b105dad2/packages/opentelemetry-instrumentation-http/src/http.ts#L537-L538 (node_modules/@opentelemetry/instrumentation-http/build/src/http.js:336), all the logging is broken too.
Wild guess: http module is in a different Context (i.e. globals are different?), so it can't find itself, so it does nothing. I don't understand Contexts nor what otel is trying to do, enough to be sure about that.

Tests are definitely running in a different context (vm.Context). Globals in node core libraries will be different (#2549, https://github.com/nodejs/node/issues/31852), but globals in user code is consistent

Thinking out loud here. otel needs to be able to look up various components in the globals object.
Options are:

runtime's constructor initialises otel (in the "outside-tests" Context), and ... sets it ... so the test's otel code can see it? So .. adds a global function in the inside-tests globals (or attaches it to .. the test object) which you can get the real globals from, and then .. get otel to use that?
when we patch the http client library, we ... get access to the inside-tests' Context's globals, and reference them from the patch, otel doesn't look like it supports this at all, tonnes of globals references all over the place
when we patch the http client library we .. pass in the test's globals, and copy them on to the outside-tests' globals.

First thought on 3, make the prelude be function (blah, blah, require) { require = () => require(globals, ...arguments);, which I'm sure has some other unbelievably horrible edge cases.

this._environment.global from runtime will be the global in tests

Thanks for taking the time to comment and research the issue 👍

What you could do here is use a custom transformer. You'd then insert source code which does the instrumentation. This would also work with native ESM, which a require based approach cannot.

This sounds to me like the most robust solution which also requires minimal changes to setup. Do you know any resources that explain how it works maybe? is it possible to concatenate transformers so I can run my own transformer and then run whatever other transformer user has configured?

You can work around require with a jest-runtime, and you can get the tracing code called.

Cool, I wasn't aware that private functions can be overridden in subclasses this way. definitely can be useful, although dangerous.

The tracing code believes there's no active context, so creates NoopSpans

It will not surprise me if the async context will also need some adjustments to jest. Currently, I'm trying to resolve the auto-instrumentation loading and patching issue, hope to look deeper into your example later.

Thinking out loud here. otel needs to be able to look up various components in the globals object.

Now that you bring it up, the global context will probably also break opentelemetry as it will sometimes use the VM global and sometimes the core global. good catch.
Looks like this issue is much more complicated than I anticipated. I'll move to other tasks in the meantime and try to crack it again later.

3 sounds impossible unless you never run tests in parallel again as different tests will override what's in the core module (as that's outside the sandbox)

The http's "outside-tests" context would be different in different workers (as they're different node processes), and each worker is only running one test suite at a time? I'm okay with it only working on a test-suite basis, and/or the test-suite having to handle it if it want to change the context on a per-test basis.

It appears that enough of the state is stored in the API package, which is designed for abuse. You can just directly expose it to tests, like https://github.com/FauxFaux/jest-otel/commit/82d11eb5deb95788d00712650293583cb322f3f5 , or presumably by fiddling with one of the other require calls.
With that, I get HTTP spans from the needle test, although not from the http test (I think it finishes too quickly, and stop() isn't sufficiently flushing it, not a jest/jest-otel problem).

Can use the same technique to provide a working mock for enough of require-in-the-middle, making the runtime not depend on test code(!). https://github.com/FauxFaux/jest-otel/commit/914da973fcd52b188d360f6091382b4a6a9b9788

I think someone has had a crack at this, but there are no docs and it seems to be published from a private repo: https://www.npmjs.com/package/@heliosphere/opentelemetry-instrumentation-jest


VARMA serialization

Issue Description
The VARMA cannot be pickled in Python3 under statsmodels 0.8.
This is fixed in statsmodels 0.9, so we should upgrade the library when we can.
The mechanics for testing the serialization are included in tests/framework/ROM/TimeSeries/ARMA/varma.xml but have been disabled until this improvement can be made.

For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.

[x] 1. Is it tagged with a type: defect or task?
[x] 2. Is it tagged with a priority: critical, normal or minor?
[x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.

[ ] 1. If the issue is a defect, is the defect fixed?
[ ] 2. If the issue is a defect, is the defect tested for in the regression test system?  (If not explain why not.)
[ ] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[ ] 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
[ ] 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

@wangc regarding the library updates


$mapper->update() doesn't update

I have a webform, that passes its values to my code.
I "manipulate" the answers into the $dataRecord
            $entity = $mapper->build($dataRecord);
            $result = $mapper->update($entity);

The result = 0, but if that means it was successfull or not, idk.
Anyway, when I look into the table, there is no evidence of the record being updated.
When I look at which query was made, it was just only the DateTime fields of the entity:
UPDATE `users` SET `appcreatedon` = ?, `appdeletedon` = ?, `appmodifiedon` = ? WHERE `id` = ? (Params: 2016-05-31 11:40:28,2016-05-31 11:40:28,2016-05-31 11:40:28,8,)

and to show there is more, here's my entity:
object(Entities\User)[253]
  protected '_objectId' => string 'entity_574d6d348fe497.955268510000000014b75720000000001b2c4cb4' (length=62)
  protected '_data' =>
    array (size=13)
      'id' => string '8' (length=1)
      'email' => string<EMAIL_ADDRESS>(length=22)
      'login' => string 'Marcello' (length=8)
      'name' => string 'Marcel Holland' (length=15)
      'password' => string 'mh' (length=2)
      'role_id' => null
      'appdepartment_id' => null
      'appcreatedby_id' => null
      'appcreatedon' =>
        object(DateTime)[250]
          public 'date' => string '2016-05-31 11:40:28.000000' (length=26)
          public 'timezone_type' => int 3
          public 'timezone' => string 'Europe/Amsterdam' (length=16)
      'appdeletedby_id' => null
      'appdeletedon' =>
        object(DateTime)[242]
          public 'date' => string '2016-05-31 11:40:28.000000' (length=26)
          public 'timezone_type' => int 3
          public 'timezone' => string 'Europe/Amsterdam' (length=16)
      'appmodifiedby_id' => null
      'appmodifiedon' =>
        object(DateTime)[243]
          public 'date' => string '2016-05-31 11:40:28.000000' (length=26)
          public 'timezone_type' => int 3
          public 'timezone' => string 'Europe/Amsterdam' (length=16)
  protected '_dataModified' =>
    array (size=0)
      empty
  protected '_isNew' => boolean true
  protected '_inGetter' =>
    array (size=0)
      empty
  protected '_inSetter' =>
    array (size=0)
      empty
  protected '_errors' =>
    array (size=0)
      empty

I found out, that it has something to do with Entity->dataModified. Which magically finds out, only the 3 fields have changed. Which is not the case, since I created the entity via $entity = $mapper->build($dataRecord);

I changed the part in line 818 of the mapper into:
        // Prepare data
        if ($entity->isNew())
        {
            $data = $entity->data();
        }
        else
        {
            $data = $entity->dataModified();
        }

What is the actual problem in here? Return value of $mapper->update($entity) call?

In this case, shouldn't create be used instead of update?


Expose manifest error chain in CargoErrors

Adds new ManifestErrors to the CargoError causal chain. These errors pass on their display, but provide more detail on which manifests are at fault when failing to build a Workspace. This is useful for lib users, in particular rls, allowing lookup of a particular manifest file that caused the error. See #6144.
For example a workspace foo where a member bar has an invalid toml manifest would have the error chain:

failed to parse manifest at /home/alex/project/foo/bar/Cargo.toml
ManifestError: /home/alex/project/foo/Cargo.toml
failed to parse manifest at /home/alex/project/foo/bar/Cargo.toml
ManifestError: /home/alex/project/foo/bar/Cargo.toml
failed to parse manifest at /home/alex/project/foo/bar/Cargo.toml
could not parse input as TOML
expected a value, found an equals at line 8

This will allow rls to point to a particular workspace member's manifest file when that manifest fails to deserialize, has invalid paths, etc.
This change should not affect binary use.

Thanks for the PR! I wonder though if the filtering of "don't wrap I/O errors" can happen in a different location? Ideally we'd deterministically wrap an error in a manifest error after a certain point instead of filtering after-the-fact (which seems like it could be lossy)

Yes i think that probably can be removed, it'll mean finding the correct manifest to plonk the error on will be a little harder.
But it also makes it simpler.

Looks like some tests are failing, but is this also the best place perhaps? I would have expected error wrapping like this to happen somewhere within src/cargo/util/toml/*.rs as that's where all our various toml-parsing utilities are

Simply wrapping in read_manifest would only wrap the root cause I think, rather than produce a chain of manifest errors. The chain is important so I can pick the nearest manifest inside the project for highlighting.
However, the initial manifest error could come from there. I'll see if that works.

Thanks! I'm not really sure what the displayable part is doing now though, was that necessary to keep the tests passing? (it's also ok to just update the output of the tests)

Well these errors are to provide a chain of info to lib users, they don't add any "displayable" info for the message / bin users. Because of this I thought it made sense to filter them out of the text output, plus having them in caused a bunch of tests to fail as some error messages became duplicated.
I added the trait to make the meaning clearer, rather than filtering ManifestErrors directly. This'll make it easier to add another such error chain to other areas, which I'd like to do with the compile errors.

I think we have at least one or two instances of "marker errors" in Cargo, and I think those strategies could be used to avoid duplication of error messages? I think the internal constructor is an example of one which flags an error as internal but doesn't affect the backtrace of displayed errors that show up

The difference here though is that I'm intending to change the backtrace. The backtrace is added to in order to trace the manifests involved in an error.

Yes it should be possible to have type-level markers in the backtrace which don't affect how it's printed (without the addition of a new method). I believe that's how internal errors work in Cargo today (although they're specifically used to change printing, but only because it's special cased)

The wrapped error indeed doesn't affect the display. The filtering is used when we're printing each cause in the chain. ManifestErrors will have the same display as their cause, so if you just print the chain you get a bunch of duplication.

failed to parse manifest at /home/alex/project/foo/bar/Cargo.toml
could not parse input as TOML
expected a value, found an equals at line 8

becomes

failed to parse manifest at /home/alex/project/foo/bar/Cargo.toml
failed to parse manifest at /home/alex/project/foo/bar/Cargo.toml
failed to parse manifest at /home/alex/project/foo/bar/Cargo.toml
could not parse input as TOML
expected a value, found an equals at line 8

When printing out the displays this isn't useful, hence the filtering. Yet I do want this "duplication", because each extra link has extra info. In particular which manifest inside a project is "nearest" to the error.
I guess I'm doing a bad job at explaining this. I feel like I'm dancing around the same points and probably missing what you're after.

@alexheretic er sorry well my point is that displayable probably does not need to be added to this PR. That's some extra infrastructure being added in this PR which is going to be difficult to maintain going forward. I think you can instead remove DisplayableError and fix the problem with duplicate outputs of errors in the error chain printing elsewhere.
I would recommend looking at Internal, which is a type-level marker for an error which doesn't affect the output display chain.

As I'm currently using the cause-chain to get the manifests involved I don't think Internal will work for this, it doesn't affect the display chain because it takes the place of it's cause and doesn't allow adding potentially lots of links.
Perhaps I could provide a different chain of ManifestErrors outside of the cause-chain. I'll give it a try anyway.

Ok maybe this is what you're after, now lower impact outside of the intended usage as a new method ManifestError::manifest_causes returns the ManifestError chain I need, but general cause chain acts the same way as Internal as you suggested.

@bors: r+
Ah yeah that looks good to me, thanks so much!

:pushpin: Commit 25b7ad267629287774d09afdddb8e6fc54917240 has been approved by alexcrichton

:hourglass: Testing commit 25b7ad267629287774d09afdddb8e6fc54917240 with merge 04c689ebf17be091e7a173034422e4fee5a0a208...

@bors: retry

:hourglass: Testing commit 25b7ad267629287774d09afdddb8e6fc54917240 with merge 6d4be789ffadd659f60787114932418100be3ee7...

@alexcrichton thanks for patiently reviewing this!

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 6d4be789ffadd659f60787114932418100be3ee7 to master...


Licensing: Is it MIT or LGPL?

Good morning,
We love the library and it is truly awesome but I'm trouble convincing my team that this is suitable for our next commercial venture. The issue only centres around licensing. Most of the source code still references LGPL. The GitHub repo and various files in DotSpatial.Positioning all reference MIT. Are portions licensed under other terms? or can the whole project be considered MIT?
Many thanks

It is MIT. I think we have to update all source code files to avoid confusions.

Thank you :), perhaps a paragraph could be added to the landing page on the GitHub project, something like: "The original DotSpatial (dotspatial.codeplex.com) was released under the LGPL, the new version is released under the MIT license."
Awesome project btw

Thanks :)


Prevent past appointments

In this branch, I have made some changes in frontend so that when a user tries to go to yesterday or before that, we display an alert (in frontend). Although the user can't now ask from the frontend, to handle malicious requests, if backend receives a request with date before today, it just straightaway changes it to today.
For now, I have created a lambda function "test_get_supporters_before_match" in AWS which could be used to test the backend part. Once this pull request is approved, that could be deleted and changes applied to the main get_supporters_before_match.

I have requested merge into main because this pull request has parts of both frontend and backend.

I have done some basic changes to make the alert look as better as I could. I do not have much experience with frontend UX design and would ask someone else to style the alert further if more changes are needed.

Hey @powellsl99,
I have split the PR into 2, one for frontend changes and one for backend since the changes for backend don't affect the frontend (the frontend could function even without those changes). Also, I had disabled time chips from earlier time of the day, as you had asked.

@ishchhabra I think this accidentally made them disabled before the current time for every day rather than just the current day. I think it would be good to if rather than disabled they should just be not rendered as well. So maybe we pass the currently displayed date into generateTimeChip() and if it is the same as today and the time in minutes < current time you just break and dont generate the chip

Hey @powellsl99,
There was just a small bug that I just fixed. Could you please review it now? My idea behind showing disabled time chips was that usually supporters have recurring appointment blocks and so if the time suits the student, he might potentially search for the same time next week.

Hey @powellsl99,
There was just a small bug that I just fixed. Could you please review it now? My idea behind showing disabled time chips was that usually supporters have recurring appointment blocks and so if the time suits the student, he might potentially search for the same time next week.

Fair enough, we'll merge in for now and if we ever wanna change it we always can!


Modules params: Tolerate missing description strings

For upcoming module updates.
Hotfix - doesn't properly render the new nested arrays, but at least prevents the page from crashing hard.
Should tide us over for a few days until @mashehu gets back and works his magic to make this work properly 😬
Unblocks @mirpedrol to merge her module update PRs.

@mirpedrol reviewd over zoom


remove irrelevant, basic testing side thought

Q
A

Fixed Issues?
Fixes #1, Fixes #2

Patch: Bug Fix?

Major: Breaking Change?

Minor: New Feature?

Tests Added + Pass?
Yes

Any Dependency Changes?

closing this because apparently sagas is more obsessed with testing than clear management of async operations


More conservative SCC tagging for Haskell libraries

all-functions corresponds to -fprof-auto which places an SCC on every binding. It is well known that SCCs hinder GHC from doing its optimization magic and really slows down profiled code to a point where the profiling reports are completely skewed towards things that were completely optimized away in production settings. Concretely this shows up with things like lenses which do not carry runtime overhead when properly simplified.
exported-functions corresponds to GHCs -fprof-auto-exported which doesn't put SCCs on INLINEd code and in turn doesn't influence simplification of this basic but important stuff.
This is even more important as per GHC-8.4 SCCs are also put into unfoldings which make you pay for it at each call site.
Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] 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)
[ ] Fits CONTRIBUTING.md.

@ryantm @peti @basvandijk Would like confirmation from at least one of you before going ahead, but this seems to be the right default to me.

@alexbiehl You can change the merge base of your PR by clicking the edit button at the top of the PR near the title.

You can change the merge base of your PR by clicking the edit button at the top of the PR near the title.

Interesting, that must be new stuff!

However you probably don't care about the inner workings of your dependencies. You just want to see how much time is being spent in the functions you call from your dependencies.

Exactly!

@peti

are there any use-cases where people would actually want profiling for all-functions rather than exported-functions?

When you're working on a collection of packages people might want to profile with all-functions to investigate how the packages work together. However in that case people are likely in full control of those packages and will be able to override them with profilingDetail="all-functions".

I wonder because the authors of ghc and Cabal chose all-functions profiling as their default, and I have to assume there are reasons for that choice?

I think the reason is what I explained above. It's the proper default for profiling the package your working on. Probably not for dependencies.
We could ask the GHC devs for advise if we're unsure.


Setup tech (firebase, repo with empty project etc.)

cra
chakra
express
initialize Firebase and begin using the SDKs for the products you'd like to use.
npm install firebase

// Import the functions you need from the SDKs you need
import { initializeApp } from "firebase/app";
import { getAnalytics } from "firebase/analytics";
// TODO: Add SDKs for Firebase products that you want to use
// https://firebase.google.com/docs/web/setup#available-libraries

// Your web app's Firebase configuration
// For Firebase JS SDK v7.20.0 and later, measurementId is optional
const firebaseConfig = {
  apiKey: "AIzaSyAi56mYLyJhmsyqjlmpSDDZ9R9VStb_LKE",
  authDomain: "finops-9a824.firebaseapp.com",
  projectId: "finops-9a824",
  storageBucket: "finops-9a824.appspot.com",
  messagingSenderId: "667753376532",
  appId: "1:667753376532:web:42914fb1da9c0cffa73001",
  measurementId: "G-9KYZ3GKW0Q"
};

// Initialize Firebase
const app = initializeApp(firebaseConfig);
const analytics = getAnalytics(app);

To host your site with Firebase Hosting, you need the Firebase CLI (a command line tool).
Run the following npm command to install the CLI or update to the latest CLI version.
npm install -g firebase-tools

You can deploy now or later. To deploy now, open a terminal window, then navigate to or create a root directory for your web app.
Sign in to Google
firebase login
Initiate your project
Run this command from your app’s root directory:
firebase init
When you’re ready, deploy your web app
Put your static files (e.g., HTML, CSS, JS) in your app’s deploy directory (the default is “public”). Then, run this command from your app’s root directory:
firebase deploy
After deploying, view your app at finops-9a824.web.app
Need help? Check out the Hosting docs

I've recently found this: https://supabase.com/
looks cool, I might get into this


Error using datetime

Hi,
I am new to this lib and I played around with timestamps in my graph.
When I run my example below I get the following error:
gqlalchemy\connection.py", line 92, in execute_and_fetch
    cursor.execute(query)
mgclient.DatabaseError: Function 'datetime.datetime' doesn't exist.

I tested it with gqlalchemy 1.3.1.
Example:
from datetime import datetime
from gqlalchemy import Memgraph, Node, Relationship, Field

class User(Node):
    id: str = Field(index=True, unique=True, db=db)
    name: str = Field()
    timestamp: datetime = Field()

User(id="1", name="myUser", timestamp=datetime.now()).save(db)

After running into this error I did a little bit of debugging.
I printed the underlying cypher statement:
MATCH (node: User) WHERE  node.id = '1'  RETURN node;
CREATE (node:User)   SET node.id = '1'  SET node.name = 'myUser'  SET node.timestamp = datetime.datetime(2022, 7, 24, 0, 32, 51, 583238)  RETURN node;

Here one can see 'datetime.datetime(2022, 7, 24, 0, 32, 51, 583238)'. This seems to be the datetime object representation instead of 'localDateTime(...)'. See: https://github.com/memgraph/gqlalchemy/blob/8324c2fb6ef41771ad39c75bd3620fc4fec0f212/tests/test_utilities.py#L69
I also found out that 'to_cypher_value(...)' is never called in my case.
If I switch the type to 'str' instead of 'datetime' I do not get any error.
Btw., nice lib :-)!
BR,
Alexander

Hi @alexanderseik, thank you for reporting this. I will check this out and get back to you 😄
Also, thanks for the nice words for the GQLAlchemy 😊


infer type of tuple from single elements

hi,
while working on await-to-ts i discovered that i cannot publish the to function with the return type of Promise<[Error, null] | [null, T]> but only with Promise<[Error, T]> because it cannot infer correctly the tuple type on partial informations on elements. you can find a live example of this in this branch

TypeScript Version:  2.3.1
Code
playground link
function f(flag: boolean): [number] | [string] {
	if (flag) {
		return [0]
	}

	return ['0']
}

const res = f(true)[0]
if (typeof res === 'number') {
	res // is a number, it works correctly
} else {
	res // is a string, it works correctly
}

const res2 = f(true)
if (typeof res2[0] === 'number') {
	const tmp1 = res[0] // is string | number, it should be number
} else {
	res // is a string, it works correctly
}

function g(flag: boolean): [number, string] | [string, number] {
	if (flag) {
		return [0, '0']
	}

	return ['0', 0]
}

const res1 = g(true)
if (typeof res1[0] === 'number') {
	const tmp1 = res1[0] // is string | number, it should be number
	const tmp2 = res1[1] // is string | number, it should be string
} else {
	const tmp1 = res1[0] // is string | number, it shuold be string
	const tmp2 = res1[1] // is string | number, it should be number
}

Expected behavior:
based on partial informations, the type system should be able to infer tuple type correctly.
Actual behavior:
the type system fails to infer tuple types with partial informations about elements.

suggestion workaround with objects instead tuples: 15482

Yeah, I still think fixing this or #15482.  TypeScript could narrow these types.  Certainly related though.

i think that it should be a killing feature because in my case i can use the type system to signal to the user that is trying to access the resolved value of the promise without checking before the error, because if you don't check the err variable the resolved value will have a null | T type, after checking the error the type will be correctly T.
@jurajkocan i was thinking about that, maybe i can give it a try and see, but the tuple syntax is for sure more elegant in this case.

no plan to see this FR approved soon?

Duplicate of https://github.com/Microsoft/TypeScript/issues/12849

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.


Is there a bower package for this plugin?

Great plugin.
Would be nice to be able to install this using bower.
Thoughts?

+1

+1

bower install jquery-tokenize


[DI] Fixup alloc_box borrow scope ends.

After https://github.com/apple/swift/pull/40793, alloc_boxes all have their lifetimes protected by a lexical borrow scope.  In that PR, DI had been updated to see through begin_borrow instructions from a project_box to a mark_uninitialized.  It did not, however, correct the end_borrow instructions when destroy_values of mark_uninitializeds were replaced with destroy_addrs of project_boxes.  That is done here.
In a bit more detail, in the following context
%box = alloc_box
%mark_uninit = mark_uninitialized %box
%lifetime = begin_borrow [lexical] %mark_uninit
%proj_box = project_box %lifetime

When it is not statically known whether a field is initialized, we arereplacing the instruction
// before
destroy_value %mark_uninit
// after

with the following diamond
  // before
  %initialized = load
  cond_br %initialized, yes, no

yes:
  destroy_addr %proj_box
  br bottom

no:
  br bottom

bottom:
  dealloc_box %box
  br keep_going

keep_going:
  // after

Doing so is problematic, though, because by SILGen construction the destroy_value is always preceded by an end_borrow:
end_borrow %lifetime
destroy_value %mark_uninit

Previously, that end_borrow remained above the
%initialized = load

instruction in the above.  That was invalid because the the newly introduced
destroy_addr %proj_box

was a use of the borrow scope (%proj_box is a projection of the begin_borrow) and consequently must be within the borrow scope.
Note also that it would not be sufficient to simply emit the diamond before the end_borrow.  The end_borrow must come before the destruction of the value whose lifetime it is protecting (%box), and the diamond contains the instruction to destroy that value (dealloc_box) in its bottom block.
To resolve this issue, just move the end_borrow instruction from where it was to before the dealloc box.  (This is actually done by moving it to the top of the diamond's "continue" block prior to the emission of that dealloc_box instruction.)
rdar://89984216

@swift-ci please test

@swift-ci please test source compatibility

@atrick Added a function adjustAllocBoxEndBorrow which

scans backwards in the current block from the instruction prior to the release for a matching end_borrow
doesn't nest
has the highlevel explanatory comment outside

@swift-ci please test

@swift-ci please test

@swift-ci please clean test linux platform

@swift-ci please test linux platform

@swift-ci please clean test linux platform


Error:  TypeError: Cannot read property 'reduce' of undefined

Start local node using staging branch from nearcore:
rm -rf testdir; ./scripts/start_unittest.py --local

Make sure the most recent near-shell is installed:
npm install -g near-shell

At the time of reporting it is: 0.10.5.
Create new project:
near new_project ./myproject; cd ./myproject

Edit src/config.js to have: nodeUrl: 'http://localhost:3030',.
Try creating new account:
near create_account cross_contract --masterAccount=test.near --homeDir=../../../../nearcore/testdir

You would need to modify homeDir path.
Observe the error message:
Error:  TypeError: Cannot read property 'reduce' of undefined
    at Account.signAndSendTransaction (/usr/local/lib/node_modules/near-shell/node_modules/nearlib/lib/account.js:84:46)
    at processTicksAndRejections (internal/process/task_queues.js:89:5)
    at async LocalAccountCreator.createAccount (/usr/local/lib/node_modules/near-shell/node_modules/nearlib/lib/account_creator.js:16:9)
    at async Near.createAccount (/usr/local/lib/node_modules/near-shell/node_modules/nearlib/lib/near.js:41:9)
    at async Object.exports.createAccount (/usr/local/lib/node_modules/near-shell/index.js:66:5)
    at async exitOnError (/usr/local/lib/node_modules/near-shell/bin/near:8:5)

@nearmax I think this is getting fixed by https://github.com/nearprotocol/nearlib/pull/80


Azure.Core backlog

This epic will track the backlog work items for Azure.Core.
Issues will be moved from this backlog when they are assigned to an active Epic.

Tracking via projects; this issue is no longer needed.


Docs are broken

Creating an issue incase it hasn't been noticed.

Here's what I'm seeing

Ping @simonihmig

Holler if I can help with this.

@averydev if you have time to work on a PR, I'm sure all of us would appreciate it 😄

Sorry for the delay! I think I have found the root cause: https://github.com/CrowdStrike/ember-oss-docs/pull/23.
Hope to get this fixed asap here!


Consider replacing the fallback parser with GithubMarkdown.jl

At the moment, "basic text" is processed via Julia's Markdown module which has a number of flaws.
GithubMarkdown.jl is a new package that wraps around a binary libcfm which implements CommonMark.
This would require a fair bit of testing but what is nice is that the only place in the code where things would change is md2html so it would be a reasonably easy thing to try.

Might need a combination of the two actually in order to respect the gymnastics around these crappy indented code blocks.

superseded by #498


Reduce Dependencies

The goal of this series of patches is to reduce dependencies throughout the peginator system. The first few patches remove dependencies that don't provide a lot of value. Afterwards, we restructure the peginator code to have the following structure:
      ┌───────────────────┐   ┌───────────────────┐
      │                   │   │                   │
      │ peginator_codegen │◄──┤ peginator_runtime ├──┐
      │                   │   │                   │  │
      └─────────┬────┬────┘   └───────────────────┘  │
                │    │                               │
                │    └──────────────────┐            │
                ▼                       ▼            │
      ┌───────────────────┐   ┌───────────────────┐  │
      │                   │   │                   │  │
      │  peginator (cli)  │   │    buildscript    │  │
      │                   │   │                   │  │
      └──────────────┰────┘   └────┰──────────────┘  │
                     ┇             ┇                 │
                     ┇  generates  ┇                 │
                     ▼             ▼                 │
                  ┌───────────────────┐              │
                  │                   │              │
                  │  generated code   │◄─────────────┘
                  │                   │
                  └───────────────────┘

clap (and its large dependency graph) is used only by paginator which contains only the cli.
peginator_runtime contains the fewest dependencies and is used by generated code.

There are a few places that still look like dependencies could be removed. The most obvious is colored which could be optional.

Damn, thanks for this, I've been meaning to do this split for ages. I'll review it right away.

All the code and changes look good.
I'm wondering though, how will this affect the discoverability and navigation on docs.rs and crates.io? Shouldn't all crates have a proper README, and some basic information (or links to the other crates) in the lib.rs files?

Both colored and nohash-hasher could be made optional. Colored is only needed for pretty tracing and error reporting, which is not really important for a lot of runtime-only users.
Nohash-hasher is only needed to speed memoization up somewhat. The speedup is not that big, and if you don't use memoization, it's useless. I think the generated code does not depend on it directly.

This looks great, thanks.

I'll make an effort to push this up to crates.io in the next few days.

I published the changes. It's important to note that my idea for the documentation was wrong, because it's somewhat pointless to document in a main.rs, because docs.rs will not process binary crates.
In the end I renamed peginator_runtime to peginator, and moved the CLI to peginator_cli.


support of fieldMask

Added fieldMask parameter in ListDeviceRegistriesRequest
Updated fieldMask to support URL encoding.

@mikoaro @sky-sharma I have merged the main changes into this branch. It should be okay now.


Examples of ARGA or ARGVA

❓ Questions & Help

Can you give me an example that redo the experiments about using the ARGA or ARVGA models on citation datasets appear in the paper "Adversarially Regularized Graph Autoencoder for Graph Embedding"
Thank you very much!

I definitively plan to do this.

Thank you again.
And, why the performance is very lower than the source paper when I run the VGAE model on the citeseer dataset? The performance of the pubmed dataset is similary to the source paper. When it run on the cora dataset, the ap metric is between on 80-90. This is very serious.

Hi and thank you for your interest,
IMO, we achieve best results when omitting KL regularization and simply use standard autoencoders. The results of VGAE can be different (this is REALLY split dependent) to the original paper, because we use a slightly different kl_loss, which we did not additionally normalize by the number of nodes (see https://github.com/tkipf/gae/issues/20).

Hi, I’m doing about node classification, now. I had rerun the G2G model, which the code is provided by the author, on the node classification task.
I also want to run the task using the VAGE or ARVGE model which provided by your team. I don't know whether this is feasible. If so, can you give me an example?
thank you very much!

Hi, I hava used the GAE to do the node classification task by using the embedding come form the GAE as the input of a linear model. Now, I also want to this task with ARGA model. I wonder if it is convenient for you to give me the correct example to produce embedding for each node by using the ARGA model, similary to the GAE example you have gived?
Thank for your help!

also need the examples for ARGA and ARGVA


Update Ignite blurb with current Ignite version

Removed ignite bowser link as it is no longer relevant and maverick doesn't have its own

Can you sign the CLA @KrastanD otherwise we can't merge this PR

I signed it when I made the pr and emailed the cla support yesterday.

Did you get any response? As without CLA we can't merge this. Rebasign will trigger a re-check if it gets stuck

I signed it when I made the pr and emailed the cla support yesterday.

Did you get any response? As without CLA we can't merge this. Rebasign will trigger a re-check if it gets stuck

No response from the CLA team. I tried to rebase but there haven't been any changes to main since I forked. I tried adding another commit but it didn't trigger the rechecks. Should i just close this PR and make a new one?


cov changes

Codecov Report

Merging #6 (af8d4f8) into main (96f9a5c) will decrease coverage by 13.56%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #6       +/-   ##
==========================================
- Coverage   13.56%   0.00%   -13.57%
==========================================
  Files          12       6        -6
  Lines        1246     906      -340
==========================================
- Hits          169       0      -169
+ Misses       1077     906      -171

Impacted Files
Coverage Δ

qtrangeslider/_style.py
0.00% <0.00%> (ø)

qtrangeslider/__init__.py
0.00% <0.00%> (ø)

qtrangeslider/_float_slider.py
0.00% <0.00%> (ø)

qtrangeslider/_qrangeslider.py
0.00% <0.00%> (ø)

qtrangeslider/_tests/test_float.py

qtrangeslider/qtcompat/QtCore.py

qtrangeslider/qtcompat/__init__.py

qtrangeslider/qtcompat/QtGui.py

qtrangeslider/qtcompat/QtWidgets.py

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 96f9a5c...af8d4f8. Read the comment docs.


Deploy

This is an automatically generated release PR!

@MounirDhahri assigning the Deploy PR to you because you were testing https://github.com/artsy/convection/pull/1349.
Please make sure to not deploy before https://github.com/artsy/convection/pull/1348 is part of it.

sounds good, thanks for tagging me here

It's there now


Link.equals is broken (A->B == A->C)

Link.java de-duplicates itself incorrectly.
MutableGraph.add(MutableNode) with (A -> B) and (A -> C) de-duplicates the second call because Link ignores its target and these two are deemed equal.
MutableGraph.add(MutableNode) with (A -> {B,C}) and (A -> D) works because the count is differs !

This was because doing equals in a circular data structure is tricky ;)
Finally fixed in 0.12.1


When logged in with GDM, some e-mail clients cannot connect to e-mail servers

Issue description
I encountered a strange and hard to debug and to reproduce issue, i think i need some advice.
In my main user account, when i log into a GNOME 3 session using GDM display manger, Evolution and Geary e-mail clients cannot refresh the inboxes and cannot send messages. Evolution shows small interrogation mark (?) in front of the account names in the left panel (where it normally shows pairs of small left and right arrows). Trying to send an e-mail message with Evolution results in an "Unknown error on connect" message. Thunderbird seems to work fine, though.
If i set LightDM as the display manager, Evolution and Geary work fine.
I created a fresh user account to debug this issue, but from a new account Evolution worked fine even if i logged in with GDM (but first i had to log in with LightDM once, see #19164).
I managed to reproduce the issue with Evolution in a fresh account by creating there ~/.config/dconf/user with a key-value pair /system/proxy/mode='auto'.
Steps to reproduce

Configure NixOS to use GDM as display manager.

Boot NixOS.

Log in from a console.

Optionally, rm ~/.config/dconf/user.

Set the value of /system/proxy/mode to 'auto' in dconf:

dconf write /system/proxy/mode "'auto'"

Log in graphically with GDM and try to set up an Evolution account or use an existing one.

Technical details

NixOS: 17.03.1203.58e227052d
Nix version: 1.11.8
Nixpkgs version: 17.03.1203.58e227052d
Sandboxing enabled: build-use-sandbox = false

Updated 2017-06-11.

I have updated the issue description with my latest findings.  In the process of debugging, i've observed another issue, which complicates debugging a bit, but i do not have enough information yet for a separate report.
It looks like GDM is somehow caching information from user home folder between logins. Because of this, i have to restart the machine after each modification of my dot-files. Just logging out and in is not enough.
For example, if i log out from a GNOME session, log in from a console, remove my .config, and log in to a GNOME session again, all the application launchers on the dash are still there.  Strange...

I tested my .config in a fresh account under Ubuntu GNOME 17.04 with GDM.  There were no issue, Evolution (3.22.6) worked fine.

I've found out how to reproduce the issue, see the updated description.

Still an issue on NixOS 18.09beta78.

Seems like nixos-20.03.2059.05a32d8e771 does not have this issue anymore.


Chat - Message that are bigger than 10240 characters does not appear without reload

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue was found when executing #6673
Action Performed:

Launch the app and login
Open two different accounts and start a chat with each other
Write any messages that are bigger than 10240 characters

Expected Result:
Verify that the message will appear for the receiver without needing to reload the chat.
Actual Result:
The message will appear for the receiver after reload of the chat.
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: 1.1.20-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/145657100-adaca0d0-dc80-40ce-8a91-91c2145ebad4.mp4
Issue was found when executing #6673
Expensify/Expensify Issue URL:
Issue reported by: Applause
Slack conversation:
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

Triggered auto assignment to @mountiny (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

I think this is quite edge case so it does not have to be a deploy blocker. Gonna remove the label and make this an External issue

Triggered auto assignment to @NicMendonca (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

cc @danieldoglas as it is related to the issue you worked on: https://github.com/Expensify/App/issues/3797
It should not work on production as the linked PR has been only deployed only to staging so far, but the issue body says it also happens in Staging.

Sorry @NicMendonca for a ping, upon further investigation, this should not be external yet. This issue is about merged PR not behaving as expected.

Issue not reproducible during KI retests. (First week)

Thanks for tagging me @mountiny .
@mvtglobally , you could not reproduce this issue too? I downloaded the branch and it was working as expected.

@danieldoglas i was able to repro the issue on Desktop app yesterday with the build 1.1.20-2
See tread https://expensify.slack.com/archives/C01GTK53T8Q/p1639532748263800

Assigning Daniel after chatting in DM together.

Ok, so I just downloaded the latest code in Main and tested this locally to check if it was happening.
This video has the production verion (1.18) and the one in Mani (1.21).
Seems to be working as expected.
https://user-images.githubusercontent.com/5818999/146268569-0286a928-15f9-4737-9a90-403e98b19382.mov
Also, testing staging.new.expensify produced the same results:
https://user-images.githubusercontent.com/5818999/146268868-bcb103b2-7f76-4930-b25c-60fc3ef81755.mov
I'll try to install the specific version you're testing.

@mvtglobally Can you run a quick test for me? Can you logout and login the application again and see if this continues?
I may have found the reason.

@danieldoglas, sorry missed this earlier. I am still able to reproduce this issue after log out.

I see.
Seems like we've deployed version 1.1.22 version in prod now. I just tested the Lorem Ipsum generated text and it did work. I've tried from 10 to 50 thousand bytes.
For some reason I cant simulate what's happening to you. Are you trying a specific text, or any text with 10240+ chars are not working for you?
if it's a specific test, can you provide it so I can see if it's something specific?

@mvtglobally please tell me if this continues happening. I'm changing it to monthly for now.


Allow key expirations higher than 90 days

For automation I need long lasting (99y) preauth keys and it's annoying having to go to the console for that.

I'm unsure if the API even supports this.

Oh wait, if the CLI supports it the API should, let me look into it.

Yeah you can use -e 99y in the CLI.

yes, d(ays), h(ours), w(eeks) are also supported, so I'm told.

This has been implemented, but to preserve the UX I kept it in days. Just tested and generated a key that lasts 365,000 days (1000 years).

Live in 0.3.9!


Add functioning preview and description display and handling

New commits start at 6686d06 : builds on from previous PR #51
Add functioning description, preview, and go back buttons

Upon pressing description or preview button, Dialogflow detects the index of the book to get information on, and returns that book to the JS, which handles creating an information display
In order to do so, add order property to Book objects (so that JS can access these unique indices and fetch the book at that index)

Add handling for books.description, books.preview, and books.results intents in BooksAgent

Add frontend handling to display this information as well

All requested changes by @aliu917 are fixed in commit b18a77d of SessionsStorage PR


Translate in Italian for Brackets 1.4

Translate in Italian for Brackets 1.4

@nicolo-ribaudo Would you mind doing a quick review for these changes?

I've not finished yet.
@Fredev, can you start reviewing my corrections?

Done

@nicolo-ribaudo I started review the comments :)

I've translated some JSLint-related strings differently from nls/root/strings.js to make them clearer.

good translation for me!

Good for me!

@Denisov21 I've corrected these errors: Denisov21/brackets#1

I think @nicolo-ribaudo can close this PR becouse @MarcelGerber merge this PR (https://github.com/adobe/brackets/pull/11117).

That PR was about other strings

@Denisov21 @nicolo-ribaudo @Fredev @MarcelGerber
Is this PR ready to be merged?

No, because @Denisov21 hasn't merged Denisov21/brackets#1yet.

Scusa @nicolo-ribaudo che cosa significa "No, because @Denisov21 hasn't merged Denisov21/brackets#1yet ? Io non posso unire nulla!

@Denisov21 You should merge Denisov21/brackets#1 . Here is a guide on how to merge a pr: https://help.github.com/articles/merging-a-pull-request/

@abose @MarcelGerber Now this pr can be merged

@nicolo-ribaudo I have some problems ("This branch has failed checks, but can be merged."). Why?

There should be a comma at the end of line 650

@nicolo-ribaudo I've done! I merge with success. Thank @nicolo-ribaudo very much!

@Denisov21 @nicolo-ribaudo @Fredev Thanks everyone for the quick changes.
Merging.


Document Databroker VSS Struct Support and give better errors

This issue is created based on https://github.com/COVESA/vss-tools/issues/241#issuecomment-2052713664
In short:

VSS Syntax support the use of types/structs, it is however not used in standard VSS catalog yet
For JSON VSS-tools two supports two variants when using struct, if the -ot argument is used the type/struct information will end up in a separate JSON file, otherwise in the same file
KUKSA Databroker does not support structs, it does not support having a type JSON as (second) input and the Proto files does not support sending struct data.

In the referenced comment above the user gets Error: ParseError
The goal of this issue is not to introduce struct support, that is a topic for later, if ever. Instead it intend to make it more visible that we do not support structs. Proposed measures:

Make sure that we in documentation clearly state what part of VSS (syntax) that we do not support.
Make sure that we give a reasonable error message if using structs, both for the variant when the JSON file actually contain struct information and for the case when no struct input is given (i.e. only signal file, no struct/type file) or only struct input (i.e. no signal file)

Possibly something like: "Databroker does not support VSS Structs"
There is a possibility that VSS_project may add signals using structs in a later release. We could consider changing Databroker behavior so it just ignores signals signals using struct data  (but give warning) rather than exit. That way we could provide partial support for VSS-models including struct data.

Result using tests from https://github.com/COVESA/vss-tools/tree/master/tests/vspec/test_structs.
erik@debian4:~/kuksa-databroker$ cargo run --bin databroker -- --metadata t2.json
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s
     Running `target/debug/databroker --metadata t2.json`
2024-04-15T11:10:43.220901Z  INFO databroker: Init logging from RUST_LOG (environment variable not found)
2024-04-15T11:10:43.220958Z  INFO databroker: Starting Kuksa Databroker 0.4.4
2024-04-15T11:10:43.222415Z  INFO databroker: Populating metadata from file 't2.json'
Error: ParseError("unknown variant `VehicleDataTypes.TestBranch1.NestedStruct`, expected one of `string`, `boolean`, `int8`, `int16`, `int32`, `int64`, `uint8`, `uint16`, `uint32`, `uint64`, `float`, `double`, `string[]`, `boolean[]`, `int8[]`, `int16[]`, `int32[]`, `int64[]`, `uint8[]`, `uint16[]`, `uint32[]`, `uint64[]`, `float[]`, `double[]` at line 5 column 63")


PayU gateway entegrated to omnipay.

You should create your own package,  you can add the link here.

@efesaid this looks great, and thank you for your work on this gateway, but @barryvdh is correct. You'll need to create your own package for this, and then am happy to link to it from the main Omnipay repo.
If you need help with that, let me know. Thanks again!

@kayladnls i created repo and added to packagist. can you please link with omnipay ? https://github.com/efesaid/omnipay-payu

Added it. Thank you!

@kayladnls can you add it to composer.json too please?

Yup, sorry about the oversight.


Establish proof-of-concept for deprecating legacy functions

What
Establish a best practice for deprecating our legacy log functions. Will roll out to other functions once this is approved.
Turns out the most universal support for this is via typing_extensions which implements support for the decorator suggested in https://peps.python.org/pep-0702/
Pylance support for showing warnings is still somewhat limited so we have to type out the full string (can't use a function to generate these notices).
Runtime warning:
$ python point3d_random.py
/home/jleibs/fakeproj/point3d_random.py:16: DeprecationWarning: Please migrate to `Points3D` or `Points2D`.
  See: https://www.rerun.io/docs/howto/migration-0.9 for more details.
  rr.log_points("random1", positions=positions, colors=colors, radii=radii)

Pyright CLI warning:
$ pyright .
/home/jleibs/fakeproj/point3d_random.py
  /home/jleibs/fakeproj/point3d_random.py:16:8 - warning: The function "log_points" is deprecated
    Please migrate to `Points3D` or `Points2D`.
    See: https://www.rerun.io/docs/howto/migration-0.9 for more details. (reportDeprecated)
0 errors, 1 warning, 0 informations

VSCode Pylance warning:

API Docs:

Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested demo.rerun.io (if applicable)

PR Build Summary
Docs preview
Examples preview
Recent benchmark results
Wasm size tracking

Doesn't show up in vim when using pyright's LSP server but we can't have it all :man_shrugging:


InvalidArgumentError (see above for traceback): Restoring from checkpoint failed. This is most likely due to a mismatch between the current graph and the graph from the checkpoint. Please ensure that you have not altered the graph expected based on the checkpoint. Original error:  No OpKernel was registered to support Op 'Correlation' with these attrs.  Registered devices: [CPU], Registered kernels:   device='GPU'  	 [[Node: FlowNet2/FlowNetCSS/FlowNetCS/FlowNetC/Correlation = Correlation[kernel_size=1, max_displacement=20, pad=20, stride_1=1, stride_2=2](FlowNet2/FlowNetCSS/FlowNetCS/FlowNetC/conv3/lrelu/add, FlowNet2/FlowNetCSS/FlowNetCS/FlowNetC/conv3_1/lrelu/add)]]

Should run Flownet2 on GPU only.

Should run Flownet2 on GPU only.

Sorry,  I meet the same problem. Could you please explain how to fix this problem in details, i.e. how to run Flownet2 on GPU only?
My env is Python2.7, cuda 10, tensorflow 1.12.0, without install cudnn, on Ubutun 18.
BTW, I can run flownet_s, flonet_sd, but fail with the others.

@lamanorange I'm running on GPU only, still facing the same problem.


guide: update to use exp show --drop/keep

https://dvc.org/doc/user-guide/experiment-management/comparing-experiments#customize-the-table-of-experiments still references --include-params and similar options instead of --drop/--keep.

Also in https://dvc.org/doc/user-guide/experiment-management/persisting-experiments#create-a-git-branch-from-an-experiment

Do you want me to jump into this?
There is https://github.com/iterative/dvc.org/issues/3118 and during the P.R. updating the ref I recall being told to wait for user guide updates.

Sorry, missed that #3118 exists.
@iesahin Should we pinging you for issues like this one and #3340, or should the core team be handling themselves?


Async client and server

Codecov Report

Merging #28 (681fe10) into main (a37c79d) will decrease coverage by 42.30%.
The diff coverage is 18.00%.

@@             Coverage Diff              @@
##              main      #28       +/-   ##
============================================
- Coverage   100.00%   57.70%   -42.30%
============================================
  Files            2        4        +2
  Lines          204      409      +205
  Branches        41       76       +35
============================================
+ Hits           204      236       +32
- Misses           0      173      +173

Files Changed
Coverage Δ

src/simple_websocket/aiows.py
13.93% <13.93%> (ø)

src/simple_websocket/__init__.py
100.00% <100.00%> (ø)

src/simple_websocket/errors.py
100.00% <100.00%> (ø)

src/simple_websocket/ws.py
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


update getting started doc

Fix #91 by adding an introduction and other relevant links to getting started doc.

Thanks for sending the pull request @apoorvkhare07. Unfortunately, this isn't quite right as you've included a lot of changes outside of the scope of the original issue. There should only be a single Markdown file in this pull request.
To give you some general feedback about your suggestion, this project is built on the open source Docsy project: https://github.com/google/docsy-example
You can see that Docsy organizes documentation by type, such as conceptual, how-to, getting started. The getting started documentation should be kept to a minimum:
https://example.docsy.dev/docs/
If you are interested and have experience, there is lots of work to do for getting started related to Windows installation. However I don't think it is a good idea to mix concepts and getting started.
I hope that helps.

ok @sharifsalah. Looks like I misunderstood the issue.
So what you are asking is to only change the getting started's index.md file to include the new detailed introduction and the new links you mentioned in the issue ?

Yes @apoorvkhare07, that sounds like a good description of the issue. Thanks for confirming your understanding.

@sharifsalah please review now, I have updated the PR accordingly.

I had a quick look @apoorvkhare07 and I can still see 5 files included in this pull request. Please update the pull request so that only content/docs/Getting started/_index.md is included.

@sharifsalah Updated the PR.


Remove &rtp search for ultisnips

Use vim.F.npcall to catch error instead, allowing ultisnips to be added to &rtp after nvim startup. Useful for those who do on-demand loading using built-in packages.
Also, the match() was reliant on the ignorecase setting; in my case (noignorecase set), it failed to match ultisnips even though it is installed and added via packadd! ultisnips in init.vim.
With this change, vim.F.npcall() will return nil if the call to UltiSnips#{...} fails -- meaning someone has added ultisnips as a completion source but doesn't have it loaded in nvim.

I've understand. Thank you.

I've understand. Thank you.


[lit-ssr] Reflected booleans show up as attributes with value

Description
When server rendering an element with a reflected boolean property, the attribute reflected will be rendered as bool="false" which Lit will interpret as true since the default converter uses hasAttribute('bool')
Steps to Reproduce

Write this code

// client
import {LitElement} from 'lit';
import {customElement, property} from 'lit/decorators.js';

@customElement('my-el')
class MyEl extends LitElement {
  @property({type: Boolean, reflect: true})
  bool = false;
}

//server
import { LitElementRenderer } from<EMAIL_ADDRESS>const instance = new LitElementRenderer('my-el');
const attrIter = instance.renderAttributes();

let next = attrIter;
for (let attribute of attrIter) {
  console.log(attribute);
}

See Console log output

Live Reproduction Link
None, can't get it to run on stackblitz containers.
Expected Results
''
Actual Results
'bool="false"'
Browsers Affected

[x] NodeJS

This is WAI. The user should be calling instance.connectedCallback() before accessing the attributes. This will solve the attribute reflection, attribute option, and willUpdate / updated property mutations.


Differentiate proposed bad blocks from imported bad block

Signed-off-by: Gabriel Fukushima<EMAIL_ADDRESS>

PR description
This PR uses a new parameter to distinguish between bad imported blocks vs bad proposed blocks.
Main objective is stop adding proposed bad blocks to the badBlockManager.
Tested on local devnet beku + txfuzzer
Fixed Issue(s)

Fixes #5058
Documentation

[x] I thought about documentation and added the doc-change-required label to this PR if
updates are required.

Acceptance Tests (Non Mainnet)

[x] I have considered running ./gradlew acceptanceTestNonMainnet locally if my PR affects non-mainnet modules.

Changelog

[ ] I thought about the changelog and included a changelog update if required.

pining @jflo since he worked on this before


Simple bash deployment script hangs

This seems to have regressed with the new git 2.8.x. The repro is quite trivial. Here is a repo: https://github.com/KuduApps/KuduDeployBash
It just has two files. .deployment has:
[config]
command = deploy.sh

And deploy.sh has:
#!/bin/bash
echo "Hello"

Which push to Kudu, it hangs trying to launch the script.

Here is the process stack.

And the command line of the 3 top processes:
cmd.exe: D:\Windows\system32\cmd.exe /c ""C:\Program Files (x86)\SiteExtensions\Kudu\55.50610.2267\bin\Scripts\starter.cmd" deploy.sh"
git-bach.exe: "D:\Program Files (x86)\Git\git-bash.exe" --no-cd "D:\home\site\repository\deploy.sh"
mintty.exe: usr\bin\mintty.exe -o AppID=GitForWindows.Bash -o RelaunchCommand="D:\Program Files (x86)\Git\git-bash.exe" -o RelaunchDisplayName="Git Bash" -i /mingw32/share/git/git-for-windows.ico /usr/bin/bash --login -i "D:\home\site\repository\deploy.sh"

The simplest repro is to just run deploy.sh from Kudu console, which hangs in the same way.
This triggers the .sh extension handler. HKEY_CLASSES_ROOT\sh_auto_file\shell\open\command maps to "D:\Program Files (x86)\Git\git-bash.exe" --no-cd "%L" %*, which is why would end up launching git-bash.exe.
Note that running bash deploy.sh from the command line works fine.

I found that if I change the shell reg key to "D:\Program Files (x86)\Git\bin\bash.exe" --no-cd "%L" %*, the issue doesn't happen.
@dscho can you explain the difference between git-bash.exe and bash.exe? Why does one use mintty but not the other?

@davidebbo git-bash.exe is supposed to run a graphical terminal, set up the environment variables appropriately, and then call the real Bash. bin/bash.exe does the same, but without the graphical shell (it is a console program). So it looks like you found the correct solution.

Instead of hacking the registry, a simpler change is to run the script shell explicitly instead of relying on Windows shell.
e.g. in .deployment file, instead of:
[config]
command = deploy.sh

We should have:
[config]
command = bash deploy.sh

Users who already generated this file will need to change it, but we should change our KuduScript generator to do it.

It turns out that our generator already does the right thing. So only users hitting this probably hand won't their .deployment file, and can easily change that.
So I don't think we need to fix anything here.