Graffitti breaks on recursive models (Upgrading from 4.3.3 to 5.0.8) RangeError: Maximum call stack size exceeded

When I upgraded from 4.3.3 to 5.0.8 I'm getting an error (RangeError: Maximum call stack size exceeded) in lodash that seems to be related to recursive schemas.
Here is a summary of my model (This worked in 4.3.3):
const RecursiveSchema = new mongoose.Schema({})
RecursiveSchema.add({
  name: {
    type: String,
    required: true,
    match: /^\S+$/
  },
  description: String,
  children: [RecursiveSchema]
})

const mainSchema = new mongoose.Schema({
  fields.....
  recursive: [RecursiveSchema],

}, { timestamps: true })

Here is a stacktrace of the error:
11:07:16 PM web.1  |  /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2309
11:07:16 PM web.1  |      function baseClone(value, isDeep, customizer, key, object, stack) {
11:07:16 PM web.1  |                        ^
11:07:16 PM web.1  |  RangeError: Maximum call stack size exceeded
11:07:16 PM web.1  |      at baseClone (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2309:23)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2358:34
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4127:15
11:07:16 PM web.1  |      at baseForOwn (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2639:24)
11:07:16 PM web.1  |      at baseClone (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2357:39)
11:07:16 PM web.1  |      at baseMergeDeep (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:3175:24)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:3111:11
11:07:16 PM web.1  |      at arrayEach (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:482:11)
11:07:16 PM web.1  |      at baseMerge (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:3104:7)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:11633:7
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4075:13
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:9183:31
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:118:30
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:809:11
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4127:15
11:07:16 PM web.1  |      at baseForOwn (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2639:24)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4096:18
11:07:16 PM web.1  |      at baseReduce (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:806:5)
11:07:16 PM web.1  |      at reduce (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:8096:14)
11:07:16 PM web.1  |      at extractPaths (/src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:117:29)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:84:20
11:07:16 PM web.1  |      at arrayReduceRight (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:669:21)
11:07:16 PM web.1  |      at reduceRight (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:8123:14)
11:07:16 PM web.1  |      at extractPath (/src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:79:34)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:118:39
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:809:11
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4127:15
11:07:16 PM web.1  |      at baseForOwn (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2639:24)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4096:18
11:07:16 PM web.1  |      at baseReduce (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:806:5)
11:07:16 PM web.1  |      at reduce (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:8096:14)
11:07:16 PM web.1  |      at extractPaths (/src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:117:29)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:84:20
11:07:16 PM web.1  |      at arrayReduceRight (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:669:21)
11:07:16 PM web.1  |      at reduceRight (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:8123:14)
11:07:16 PM web.1  |      at extractPath (/src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:79:34)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:118:39
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:809:11
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4127:15
11:07:16 PM web.1  |      at baseForOwn (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2639:24)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4096:18
11:07:16 PM web.1  |      at baseReduce (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:806:5)
11:07:16 PM web.1  |      at reduce (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:8096:14)
11:07:16 PM web.1  |      at extractPaths (/src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:117:29)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:84:20
11:07:16 PM web.1  |      at arrayReduceRight (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:669:21)
11:07:16 PM web.1  |      at reduceRight (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:8123:14)
11:07:16 PM web.1  |      at extractPath (/src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:79:34)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:118:39
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:809:11
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4127:15
11:07:16 PM web.1  |      at baseForOwn (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:2639:24)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:4096:18
11:07:16 PM web.1  |      at baseReduce (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:806:5)
11:07:16 PM web.1  |      at reduce (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:8096:14)
11:07:16 PM web.1  |      at extractPaths (/src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:117:29)
11:07:16 PM web.1  |      at /src/node_modules/@risingstack/graffiti-mongoose/lib/model/model.js:84:20
11:07:16 PM web.1  |      at arrayReduceRight (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:669:21)
11:07:16 PM web.1  |      at reduceRight (/src/node_modules/@risingstack/graffiti-mongoose/node_modules/lodash/lodash.js:8123:14)

Here is the diff of my package.json
-    "@risingstack/graffiti": "2.1.2",
-    "@risingstack/graffiti-mongoose": "4.3.3",
+    "@risingstack/graffiti": "3.0.2",
+    "@risingstack/graffiti-mongoose": "5.0.8",
-    "express-graphql": "0.4.5",
+    "express-graphql": "0.4.9",
-    "graphql": "0.4.14",
-    "graphql-relay": "0.3.5",
+    "graphql": "0.4.18",
-    "lodash": "3.10.1",
+    "lodash": "4.5.1",
     "mongoose": "4.3.4",

Any help would be awesome!
Thanks,
Jon

Confirmed this also happens when bumped to 5.0.

Thanks for the report. I will try to reproduce and fix this.

I've managed to reproduce the error, although I didn't have a solution just yet. :/

Not sure, cause this fix error with mutation objects, which use new introduced code toInputObject few commits ago.
But it can help, if your problem was with mutations. Just try on your project ;)


chart

Just /chart/, not /chart/latest, since we don't keep version here.

In fact, let's move the chart to Longhorn repo. The README contains doc information which is in the Longhorn repo. So we don't need to sync from Longhorn repo then sync this back.

How about directory of the script?

Oh no, that's only for build scripts. And the chart is not even a script.

@shuo-wu  In fact, which scripts you're talking about?

see last commit. version update script.

That script is not a part of the chart. It's more like a release tool. You don't need to check it in, at least before other release tools checked in.


Does this work with Size Classes?

Probably not. I'm not sure how to replicate the "installed" property from Interface Builder in code. I'll look into it more when I get more time or I'm forced to deal with size classes.


Analysis page sometimes shows "No data to display" although reloading the site shows data

Where to find the issue

https://www.coronawarn.app/de/analysis/
https://www.coronawarn.app/en/analysis/

Describe the issue
The CWA dashboard sometimes shows "No data to display" although the data is actually available when reloading the page.
https://user-images.githubusercontent.com/67682506/148298367-5e1f1df5-6f0d-4d18-a73c-969038914289.mov
Suggested change
I have no idea when this issue occurs and can't reliable reproduce it.

@Ein-Tim
In your title you wrote the word "sontemis". Did you perhaps mean "sometimes"?
I would simply suspect a transient network issue if you get the error message "No Data to display" which disappears when you refresh the page.

@MikeMcC399
Thanks, yes, this was a typo. I corrected it.
I'm not too sure whether this is really a network issue, as I can access all other pages correctly and I monitored my network connection on the second monitor and did not see an issue. However, I'll try to reproduce this and dive deeper.

@Ein-Tim
The data comes from the network location https://obs.eu-de.otc.t-systems.com/ which is different to the network location https://www.coronawarn.app/, so you may be able to access other pages successfully at the same time as having difficulty in getting data for the https://www.coronawarn.app/en/analysis/ page.
If it happens again, you could try accessing https://obs.eu-de.otc.t-systems.com/obs-public-dashboard/json/v1/nested_cwa_public_dashboard_data.json directly in a separate browser window.
You could also try network troubleshooting. In a bash terminal on Windows, that would be:
tracert obs.eu-de.otc.t-systems.com
Tracing route to obs.lz01.eu-de.otc.t-systems.com [<IP_ADDRESS>]

@MikeMcC399
What do you think of this? This time, I encountered this on my phone. However, I solved it without reloading the page (which underlines the fact that the data is already there, or?).
Take a look:
https://user-images.githubusercontent.com/67682506/148525413-4c3d038b-d098-4086-9421-3bb474f5c5e7.MOV

@Ein-Tim
We probably need feedback from the JavaScript experts to explain what is happening. I would still guess that it is due to network latency / delays / other issues.
Since there are multiple IP addresses associated with the name obs.eu-de.otc.t-systems.com there may be load balancer hardware in the Open Telekom Cloud or other technology involved. I couldn't see anything wrong when I looked yesterday.
nslookup obs.eu-de.otc.t-systems.com
Server:  nsrcustm1-m1-01.mip-platform.net
Address:  2a02:2457:30c:101::11

Non-authoritative answer:
Name:    obs.lz01.eu-de.otc.t-systems.com
Addresses:  <IP_ADDRESS>
          <IP_ADDRESS>
          <IP_ADDRESS>
          <IP_ADDRESS>
          <IP_ADDRESS>
          <IP_ADDRESS>
Aliases:  obs.eu-de.otc.t-systems.com

Okay, maybe @brifemu could take a look.

@Ein-Tim
If you could catch the error when you have the browser in developer mode, that would show more.
I realised also that if the webpage cannot get the data from
https://obs.eu-de.otc.t-systems.com/obs-public-dashboard/json/v1/nested_cwa_public_dashboard_data.json
it falls back to downloading from
https://www.coronawarn.app/analyseData.json
instead.

@MikeMcC399
I'll try my best!

I have tried to simulate the error and have not been able to. I have tried by simulating a slow connection, cutting the download during the page load, but I have not gotten a similar result. I'll keep trying to reproduce it these days.

Thank you @brifemu!
I will try my best to capture this in the dev console.

I just experienced this again. There seems to be nothing helpful in the console:
https://user-images.githubusercontent.com/67682506/149553820-f93c371a-8292-44c8-8ad2-fdd5e3cde0da.mov

@Ein-Tim
Which browser are you using?
I would be looking in the Network (Netzwerk) tab for issues since the data is fetched over the network.
You would need to have this open before the error occurs (at least that is the way that Chrome and Firefox work).

@MikeMcC399
As always, I'm using Safari. I also think it's necessary to open the console before the issue occurs, I will try to reproduce it with the console active.

@Ein-Tim
Are you still seeing this issue?

I will try to reproduce it.

I'll close this issue for now, as it is neither easy to reproduce nor a problem many users are experiencing. Additionally, it can easily be worked around.


As a user, I want to produce a report of all the countries in the world organized by largest population to smallest so that population report can be analyzed efficiently.

first issue finished


URLs have change

The documentation URLs seem to have changed. For example:
http://quarks-edge.github.io/quarks.documentation/docs/quarks/getinvolved/ became http://quarks-edge.github.io/quarks.documentation/mydoc/getinvolved.html
Can this be undone? Do we want "mydoc" to be part of the path?

Yes, the template I used kept the markdown documents in a different location than before. I can look into changing it back if it's causing issues. Are you having problems with links?

It's only an issue because we were pointing to documentation locations from the Quarks website. Since we're pulling the documentation into the site project at apache (https://issues.apache.org/jira/browse/QUARKS-2) I'm not sure if we should worry about fixing things here. I'm fine with new URLs, as long as that is intended.
I would propose that we have the directory be called something other than "mydoc" so that the URL looks more official.

I agree with @Alex-Cook4.  I think having a directory path called "mydoc" is strange.
The other thing we have to worry about is Google indexing. Changing the links like this causes google index to go out of date.  So, if people search on google, they may potentially get to an old link, and get a 404 error.  Any time we change URL like this, we should look at having some sort of redirect so old links are not broken.

@chanskw, Since we're moving everything to the Apache site, aren't the Google index links out of date anyway? What we could do is make it so that when somebody follows a link from google to the github quarks.documentation site, it automatically redirects them to the correct page in the Apache site.

I think having a directory path called "mydoc" is strange.
Agreed, I'll fix that.

@wmarshall484 +1 to the idea of automatically redirecting the github documentation site to Apache once we have that up.


inference  question

when i'm using  imgs to inferrence through the network,did i must provide the background in the origin img? i can,t understand this,maybe i should go to your paper.

That's right. You must have the original background image.


With the new update, different KtLint rules are being applied.

Maybe it's no longer using my .editorconfig and is now using the default rules?
Also it might be related that my .editor config is full of these now. I don't remember if it had these before:

https://github.com/nbadal/ktlint-intellij-plugin/issues/536

I thought the linked issue was related to this but it isn't.

Found the issue: The plugin uses the last Ktlint version, while my project uses 1.1.0. The 1.3.0 moved some rules from experimental to non-experimental, that's why they are now being applied

Found the issue: The plugin uses the last Ktlint version, while my project uses 1.1.0. The 1.3.0 moved some rules from experimental to non-experimental, that's why they are now being applied

Starting from version 0.23.0 the plugin allows you to run with an older version like 1.1.0 if you don't want or cannot update the ktlint version in the project. See Ktlint Plugin preferences.

Ty! 🤗


Propagate pending user errors

Coverage increased (+0.04%) to 79.85% when pulling dc0df6b3e6c757636c94184c41730524d1a26bb4 on pending into f5db7c1115f38f39eac30d0289ad88d29672894c on master.


Fix markdown table format

👋 We recently updated the Markdown parser on dotcom, and it broke the display of tables that are generated by this action. This is because it was missing an additional newline before the markdown table. The fact that this rendered correctly previously was actually a bug See https://github.com/github/coding/issues/2375 for more info.
This PR updates the action to have another newline, which should allow the tables to be displayed correctly again.
Sorry for the additional diff, but it looks like there were some trailing whitespaces in the README as well, which the editor fixed when I updated the example.
/cc @anuraag016

Thanks a lot for contributing and fixing the issue 😄


Solutions to fix CORS issue

After some digging, i found out that jup api will throw "CORS ERROR" on production when it's "rate limited".
If you wish to remove that error, you have to use a proxy or upgrade your quicknode rpc plan.
if you wish to use an upgraded quicknode endpoint, i have added codes in scooper.tsx -> loadJupyterApi function
If you wish to use a proxy, I have added codes in the scooper.tsx -> sweepTokens function that adds the proxy. Fixing it will only change the error to "rate limited" since you are using the free jup api.
(note: it's using a temporary proxy, you have to get an actual proxy).
.
This pull request was created for https://v2.gib.work/bounties/537d2850-327d-4c63-a1ad-87565ef88a6f in an attempt to solve a bounty #5 . Payment for the bounty is immediately sent to the contributor after merge.

excellent, thank you for the comments as well ser. merging.


Dynamic query in azure-spring-data-cosmos?

I have a use case for filtering data based on the different filter criteria provided by the clients. So, I would like to form a dynamic query depending on whether the input is provided by the user or not.
For eg: if the user has provided filter criteria a, b and c then the query should be something like "Select * from xyz where a = something and b = something and c = something". But if the user has provided only a and c then the query must be something like "Select * from xyz where a = something and c = something".
I think this is something that can be achieved using 'com.azure.spring.data.cosmos.core.query.Criteria' but I am not able to figure out how. Is there any documentation/tutorial/example to explain how to use the library?

@pratikgawali  - I see this issue got closed because of automation, wondering, if you are still facing this issue. Feel free to re-open this if that's the case, apologies for the delay on this issue.


Update the authorization / authentication protocol for the OSPO REST API from PAT to OIDC

DON'T SQUASH THIS PR. INDIVIDUAL PRs INTO THIS BRANCH WERE SQUASHED.
The work on this feature branch updated the authorization and config for using the Open Source Programs Office REST API from Personal Access Tokens to OIDC. In addition, the code using that REST API was made resilient if the config has not be updated. When the OIDC configuration variables are missing, the HTTP client is null, and no API calls are tried.
However, if the new tokens are configured, but are invalid, the service will throw exceptions to indicate the configuration failure.

/cc @jeffwilcox


UnsubscriptionErrors thrown in TestScheduling don't log anything useful.

RxJS version: 5.0.0-beta.3
Code to reproduce:
This should do it:
let example = Observable.create(() => () => { throw 'bad' });
expectObservable(example).toBe('');

Expected behavior:
Respond with a test failure outlining all errors in the errors collection from the UnsubscriptionError thrown.
Actual behavior:
Test failures just show "UnsubscriptionError thrown" with no additional information.
Additional information:

I think this issue is now covered by #1591 and recent #1778 .


Improve AuthZ implemention with Casbin

Casbin is being used to provide AuthZ for our routes. This works well but there is some duplication we need to handle.
This issue is going to capture small tasks to improve this:

document the way our route authz works for gRPC and HTTP
consolidate PublicRoutes with Casbin

run Casbin Enforce for a PublicRoutes policy pre-auth and for all Routes post-auth
this will require a subset of the policy to run for PublicRoutes

reformat our configurable custom csv casbin policy into yaml (see below)

Casbin policy could be more readable and declarative instead of comma separated such as:
org-admin: &orgAdmin org-admin
auth:
   policy:
      roles:
         - name?: *orgAdmin
           level: 0
           # we could open up flattening for this if we want as the below
           claim: .role
           claim_value: org-admin
           # the other option would be just leaning into RBAC over auth routes and hardcoding claims
         - role: admin
           level: 1
      route_rules:
         - route: policy*
           actions: *
           roles:
              - *orgAdmin
              - admin
         - route: unsafe*
           actions: *
           roles:
              - *orgAdmin
      public_routes:
         - kas*
         - /kas*

The one thing I have concerns with here is putting public_routes in the configuration. I feel like that opens up potential for miss configuration.
In the roles block could we define role: admin multiple times which gets mapped from different claims?
That would solve this issue #1031

In the roles block could we define role: admin multiple times which gets mapped from different claims?

I like this. I think that's a good solution to #1031.

The one thing I have concerns with here is putting public_routes in the configuration. I feel like that opens up potential for miss configuration.

While misconfiguration is a valid concern, couldn't the WithPublicRoutes be hijacked by a PEP anyway to short-circuit the casbin policy as it stands today? I am wondering if the potential for issues is greater having four alternate sources of truth (below) than having a single, more powerful source of truth driving everything.

the WithPublicRoutes hook config option func
https://github.com/opentdf/platform/blob/c3828d088a3483b78079cd257b4237291cf7b6f0/service/pkg/server/options.go#L41
casbin defaultPolicy
https://github.com/opentdf/platform/blob/c3828d088a3483b78079cd257b4237291cf7b6f0/service/internal/auth/casbin.go#L27
casbin custom policy in config
https://github.com/opentdf/platform/blob/c3828d088a3483b78079cd257b4237291cf7b6f0/opentdf-dev.yaml#L46
hardcoded allowedPublicEndpoints
https://github.com/opentdf/platform/blob/c3828d088a3483b78079cd257b4237291cf7b6f0/service/internal/auth/authn.go#L45

The one thing I have concerns with here is putting public_routes in the configuration. I feel like that opens up potential for miss configuration.

While misconfiguration is a valid concern, couldn't the WithPublicRoutes be hijacked by a PEP anyway to short-circuit the casbin policy as it stands today? I am wondering if the potential for issues is greater having four alternate sources of truth (below) than having a single, more powerful source of truth driving everything.

the WithPublicRoutes hook config option func
https://github.com/opentdf/platform/blob/c3828d088a3483b78079cd257b4237291cf7b6f0/service/pkg/server/options.go#L41
casbin defaultPolicy
https://github.com/opentdf/platform/blob/c3828d088a3483b78079cd257b4237291cf7b6f0/service/internal/auth/casbin.go#L27
casbin custom policy in config
https://github.com/opentdf/platform/blob/c3828d088a3483b78079cd257b4237291cf7b6f0/opentdf-dev.yaml#L46
hardcoded allowedPublicEndpoints
https://github.com/opentdf/platform/blob/c3828d088a3483b78079cd257b4237291cf7b6f0/service/internal/auth/authn.go#L45

Are you saying a PEP developer could accidentally override the platform's public routes or do it maliciously? Also, it might not be fair to expect someone deploying the platform (who isn’t actively developing it) to know exactly which routes should be public and which shouldn’t.

I think a PEP developer trying to deploy the platform with maliciously overriden public route policy is not something we should necessarily try to control for, but I have had the experience of developing a PEP on the platform, unexpectedly getting a 403 on a route from Casbin, and struggling to find where the route policy is defined (or should defined) within the four places. That said, you're absolutely right that developers will know the APIs and can guard them more effectively than admins.

I thought about this more and instead of mapping to routes I wonder if we can map to defined resource types and a set of actions.

attribute (crud)
subject mapping (crud)
resource mapping (crud)
kas (rewarp)

It would make things easier to understand and users won't have to worry about http vs grpc routes.


Update Install instructions to use Makefile

It looks as if the install_firedrake.sh was recently removed in preference of a Makefile. It would be good to update te documented installation instructions to reflect this change.

Good point! I should've done this indeed.

@acse-ej321 please could you check you're happy with my updates to https://github.com/mesh-adaptation/mesh-adaptation-docs/wiki/Installation-Instructions? If so, please close this issue, thanks.

More changes are necessary :) see #73

@ddundo - I think most users may already have Firedrake installed. However, some of the PETSc flags set for Animate and Goalie might not have been included in their setups - particularly --download-mmg which is not widely used. An existing Firedrake installation with additional PETSc flags appears to require a near-complete firedrake-update --rebuild to update. So, it is probably worth leaving first, as it is the key dependency for the others, but maybe adding a description of how to update a current Firedrake installation?

@jwallwork23 - The instructions for working with the Makefile are clearer. However, the makefile requires all the contents of the install folder to run, including the config folder, which is not included in the installation instructions.
Until the FIREDRAKE_CONFIGURE_OPTIONS become larger, a temporary solution could be adding the contents of the config/*.mk files directly into the current flow control statement at the beginning of the Makefile. That would require no additional changes to the current installation instructions.
Otherwise, @ddundo's suggestion above seems like a good way to maintain the current, more pythonic file structure.
The last idea is to have the user download just the install folder, cd into it, and then run the Makefile.

 And this all sounds great to me @acse-ej321, thanks a lot :)

@jwallwork23 - The instructions for working with the Makefile are clearer. However, the makefile requires all the contents of the install folder to run, including the config folder, which is not included in the installation instructions. Until the FIREDRAKE_CONFIGURE_OPTIONS become larger, a temporary solution could be adding the contents of the config/*.mk files directly into the current flow control statement at the beginning of the Makefile. That would require no additional changes to the current installation instructions.

Yes, I agree. For now let's just inline the contents of ubuntu.mk (etc.) into the Makefile. (It just sets the FIREDRAKE_CONFIGURE_OPTIONS env variable). If one of you has time to do this that'd be much appreciated - I'm unlikely to get to this for a few days.


*.bash files in .bash_it/custom no longer get sourced?

Just installed on a ubuntu 16.04 server and my aliases and functions in ~/.bash_it/custom/*.bash no longer get picked up like they do on my older install. When did this change and why the breaking change? Sigh. custom dir still exists and custom/example.bash is still referenced in the docs but I'm not sure why.
I do see now that the place for various custom files is now inside each component dir like aliases/ /completions /lib /plugins. Is this better? I'm not sure. In any case, very confusing and the docs should probably delete all mention of custom dir.

Also just moved custom/aliases.bash to aliases/custom.aliases.bash as the docs now say to do, with the same result - no sourcing and my custom aliases are not available on login. What is going on here?

Nope. PEBKAC. This was a terraform install and I had $BASH_IT pointing to /home/ubuntu/.bash_it and not my ssh user!


DNS-SD-discovered devices have no device IDs

Describe the bug
For automatically adding printers with the autoadd subcommand but also for drivers automatically adapting to special properties of different printer models the printer's device ID is essential.
Working on a model auto-selection feature (no need to find your printer under ~4000 supported models) in my PostScript Printer Application (ps_autoadd() function, also used for the autoadd subcommand, "Automatic Selection" in the driver list of the web interface) I have found out that it works only when selecting a USB or SNMP-discovered socket entry under the discovered printers, not when using the DNS-SD-based entry.
Looking for the reason I have discovered that devices discovered on USB or via SNMP come with a device ID, DNS-SD-discovered devices are missing the device ID.
Obtaining a device ID for a DNS-SD-discovered device is easy, the printer does not to get polled and woken up for it.
Note that a device ID should contain MFG, MDL, and CMD fields, the latter for assigning a generic driver or for situations like "is the PostScript add-on module installed?").
First look for "usb_MFG", "usb_MDL", and "usb_CMD" entries in the TXT record, each of them which you find you can directly fill into the corresponding field of the device ID. After that you fill the remaining fields with information derived from the "ty", "product", and "pdl" fields appropriately dissected and converted.
One could think that the device URI which is based on the DNS-SD service name of the printer also could be used to extract make and model info, but

Only if the printer's service name is still the factory default and not modified in the printer's web interface it contains make and model names and even this is not 100% safe
We cannot derive the printer's PDLs from the device URI/the service name, so no way to assign generic drivers or check presence of an add-on

To Reproduce
Have a network PostScript printer, with socket printing discoverable by DNS-SD available. In the web interface of the PostScript Printer Application select the DNS-SD-based entry under the discovered printers and as driver "Automatic Selection". The new printer will not get created.
If selecting the SNMP-based entry under the discovered printers, the printer will get added, if not an explicitly supported model, as a "Generic PostScript Printer". Also when connecting the printer via USB and selecting the USB-based entry, the printer will get added.
The same should happen (but I did not test) with a PCL printer and the HP PCL Printer Application.
System Information:

As usual, Ubuntu 20.10 Groovy and the current GIT snapshots of PAPPL, cups-filters, and the PostScript Printer Application

I have reviewed and tested your fix on this. Unfortunately, it does not work for me. There are two issues on it:

Not understandable for me by your code, the device ID which my driver callback, ps_callback(), receives contains only make and model, not the CMD: field with the PDLs, in my case I get MFG:HP;MDL:OfficeJet Pro 8730; for device URI dnssd://HP%5C032OfficeJet%5C032Pro%5C0328730%5C032%5C09108C229%5C093._pdl-datastream._tcp.local/. Your new code puts the componant into a MFG:%s;MDL:%s;CMD:%s; pattern, so I am wondering where this device ID actually comes from.
The way you generate the CMD: field from the pdl TXT record entry is too simple. It extracts only PostScript and PCL, you should extract as many PDLs as possible, in any combination: PDF, PCLXL, PCL5c, PCL5e, PCL3, PCL, JPEG, PCLM, AppleRaster, PWGRaster, ... at least the ones which have corresponding MIME types. Any of them can be useful for driver developers. My HP OfficeJet Pro 8730 has the following CMD entry:

CMD:PCL5c,PCLXL,POSTSCRIPT,NATIVEOFFICE,PDF,PCL3GUI,PCL3,PJL,Automatic,JPEG,PCLM,AppleRaster,PWGRaster,802.11,802.3,DESKJET,DYN;

For (1) I have found the solution. You have made a buffer too small and the device ID got truncated, coincidentally exactly between MDL: and CMD: part.
This patch fixes it and makes the automatic model selection with my PostScript Printer Application work:
diff --git a/pappl/system-webif.c b/pappl/system-webif.c
index f790300..01dd86e 100644
--- a/pappl/system-webif.c
+++ b/pappl/system-webif.c
@@ -310,7 +310,7 @@ _papplSystemWebAddPrinter(
   const char   *status = NULL;         // Status message, if any
   char         printer_name[128] = "", // Printer Name
                driver_name[128] = "",  // Driver Name
-               device_uri[128] = "",   // Device URI
+               device_uri[1024] = "",  // Device URI
                *device_id = NULL,      // Device ID
                hostname[256] = "",     // Hostname
                *ptr;                   // Pointer into string

There is still a solution for (2) needed to improve cooperation with a wider range of Printer Applications.

@tillkamppeter First, we do not need to support printers that support URF or PWG Raster. Those are AirPrint/IPP Everywhere printers that are already supported directly.
Second, if the printer advertises the usb_CMD key in its TXT record, we'll use it. But otherwise we need to map MIME media types to 1284 command set names, of which PostScript and PCL have well-defined mappings. But many vendors (Brother, Canon, EPSON, and others) don't have MIME media types defined for their command sets and don't advertise either usb_CMD or a vendor type in the "pdl" key ("application/octet-stream" and "raw" are two common substitutes... 🙄)
I cannot invent values out of thin air. I absolutely will not add any kind of mapping table for the make and model. That is the job of the printer application, and if every printer with every connection type isn't able to be auto-added, that isn't a failure.
[master d994c6d] Enhance 1284 device ID support (Issue #73)

This commit contains the fix for the device URI buffer size:
[master cc4c979] Add a status message for when we can't add the printer because it already exists (Issue #86)


Fix --warehouses argument in TPCC instructions

The --warehouses argument for loading TPCC fixtures was off by a factor
of 10.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/186bf70cbdbe7d8fcc6b4ea1e99a7b2021f1c352/

@solongordon @jseldess - the first example is running TPC-C 1K: 1,000 warehouses (for a total dataset size of 200GB) on 3 nodes so 1000 is actually correct. I'm going to revert the change, but will add a little more description to point out the difference.

@solongordon @jseldess - sorry! misread the 0s. Closing the revert, thanks for the fix :)

Np, thanks for verifying!


CSS: Use [r]em instead of px for font-size

Relative units such as em or rem scale with the browser's default font size. px do not. I tend to set my browser's default font size a little larger, so it's a minor pet peeve when web pages don't respect / utilize it.
The px values are coming from Bootstrap, and I don't expect Bootstrap to change this anytime soon, so I guess this issue is mostly for posterity.

I'm gonna close this because it's not something we have control over.


No spacing between 2 sections

I have added many sections in the form, but there is no spacing between them:

Here is a part of the code:
...

let section4 = FormSectionDescriptor()
row = FormRowDescriptor(tag: Static.phoneOfficeTag, rowType: .Phone, title: GlobalConstants.PHONE_OFFICE as String)
config = configGlobal
if let val = mUser.PhoneOffice as? String where val.isEmpty==false
{   config["textField.text"] = val }
row.configuration[FormRowDescriptor.Configuration.CellConfiguration] = config
section4.addRow(row)

let section5 = FormSectionDescriptor()
row = FormRowDescriptor(tag: Static.emailTag, rowType: .Email, title: "Email")
config = configGlobal
if let val = mUser.Email as? String where val.isEmpty==false
{   config["textField.text"] = val }
row.configuration[FormRowDescriptor.Configuration.CellConfiguration] = config
section5.addRow(row)

...

Hello vhs123, I just would like to contact you. Can you please tell me if your issue about Linkedin oAuth2 there (https://github.com/p2/OAuth2/issues/43#issuecomment-166116459) is resolved and how ? Thanks.

Hi Nahouto,
Sorry for replying late. I could not resolve the issue. I am currently
using another library: https://github.com/OAuthSwift/OAuthSwift
On Sun, Dec 20, 2015 at 7:42 PM, nahouto<EMAIL_ADDRESS>wrote:

Hello vhs123, I just would like to contact you. Can you please tell me if
your issue about Linkedin oAuth2 there (p2/OAuth2#43 (comment)
https://github.com/p2/OAuth2/issues/43#issuecomment-166116459) is
resolved and how ? Thanks.
—
Reply to this email directly or view it on GitHub
https://github.com/ortuman/SwiftForms/issues/82#issuecomment-166119851.

--
Regards,
Vishalaksh


Xamarin Android Error: Could not resolve reference to 'SQLitePCL.delegate_progress_handler'

App builds fine in UWP and iOS.
Building in Visual Studio 2019, version 16.9.3
Using sqlite-net-sqlcipher, version 1.7.335
When attempting to build Xamarin Android app, receive the following error:
Error		Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA2006: Could not resolve reference to 'SQLitePCL.delegate_progress_handler' (defined in assembly 'SQLitePCLRaw.provider.e_sqlite3, Version=<IP_ADDRESS>0, Culture=neutral, PublicKeyToken=9c301db686d0bd12') with scope 'SQLitePCLRaw.core, Version=<IP_ADDRESS>0, Culture=neutral, PublicKeyToken=1488e028ca7ab535'. When the scope is different from the defining assembly, it usually means that the type is forwarded. ---> Mono.Cecil.ResolutionException: Failed to resolve SQLitePCL.delegate_progress_handler

I have the same problem.

Your project references incompatible mix of the sqlite-net-sqlcipher (1.7) and its dependencies like SQLitePCLRaw.provider.e_sqlite3 (1.1).
Double check your Nuget packages and direct project references.
See also https://github.com/ericsink/SQLitePCL.raw/issues/384.


Cannot store boolean

Describe the bug
Cranelift crashes when storing a boolean.
Expected behavior
RCC stores a value of size 1 byte to memory.
Actual Behavior
RCC gives a fatal error at compilation time.
Code
int main() {
        _Bool my_bool = 1;
}

AST
extern int main() {
auto bool my_bool = (bool)(1);;
}

ASM
function u0:0() -> i32 system_v {
    ss0 = explicit_slot 1

ebb0:
    v0 = bconst.b1 true
    v1 = stack_addr.i64 ss0
    store v0, v1  # inst2
    v2 = iconst.i32 0
    return v2
}

fatal: - inst2: has an invalid controlling type b1

Ideally this would be fixed by https://github.com/CraneStation/cranelift/issues/1117, but in the meantime boolean values should be promoted to i8 in src/ir/expr.rs.


Running Tensorflow on GeForce 940M (Ubuntu 14)

Hi everyone,
I'm running the CIFAR-10 classification from the Tensorflow for the very first time on my laptop with GeForce 940M. I'm running the training with the pre-defined parameters as follows:
python cifar10_train.py
after step 1800 I'm getting the following errors:
E tensorflow/stream_executor/cuda/cuda_event.cc:33] Error polling for event status: failed to query event: CUDA_ERROR_ILLEGAL_ADDRESS E tensorflow/stream_executor/cuda/cuda_driver.cc:1182] failed to enqueue async memcpy from device to host: CUDA_ERROR_ILLEGAL_ADDRESS; host dst: 0x7ff8e9bf26c0; GPU src: 0x5011c0600; size: 16=0x10 F tensorflow/core/common_runtime/gpu/gpu_event_mgr.cc:105] Unexpected Event status: 1 I tensorflow/stream_executor/stream.cc:3304] stream 0x35e7190 did not block host until done; was already in an error state Aborted (core dumped)
Does anybody have any idea?
By the way, the following fix was required on my side to get the training running:
from tensorflow.python.platform import gfile gfile.Exists(...)
without "ts." in front, it didn't work that way... Any ideas why? I've just forked the repository without any changes.
Thanks a lot in advance for your help! Any advice is kindly appreciated!

It looks like the 940M is compute capability 5.0 -- we default to only building for 3.5 and 5.2.
You might want to try building from sources.  See the section here on installing for Cuda 3.0 to see how you can compile for Cuda 5.0.
@zheng-xq: Is https://github.com/tensorflow/tensorflow/blob/8048088bfb82846078f8023bc6199e6424926624/tensorflow/core/common_runtime/gpu/gpu_device.cc#L683 properly capturing this?  We probably want to just iterate over all compute capabilities and check for equality, unless I'm misunderstanding how compute capabilities work :)

Thanks for your response! Yeah, I will try to build it from sources. By the way, will tensorflow run in future for all models of Nvidia GPUs?

Every compute capability you compile for increases the size of the binary significantly, so it is unlikely that we'll support every compute capability Nvidia has ever produced in the default binaries.  But everything >= 3.0 should work if build from sources, although we only test for a small subset.

Well, we'll think about it, maybe some people don't care about binary size and want something that works everywhere.  Once we get our release process a bit more solid we could consider this.

Reported similar issue https://github.com/tensorflow/tensorflow/issues/1477
Actually config is for cuda 5.0 when running ./configure    But used cuda7.5 and cuDNN v3 as source to build from.  Is this an issue?

@vrv: What's the status of this?

Having very similar issues as well:

cifar10 often freezes right after or during local3 (first fc after the two convs)
Now did this right after or during the first conv:
E tensorflow/stream_executor/cuda/cuda_event.cc:49] Error polling for event status: failed to query event: CUDA_ERROR_ILLEGAL_ADDRESS
F tensorflow/core/common_runtime/gpu/gpu_event_mgr.cc:198] Unexpected Event status: 1
Aborted (core dumped)
Havent been able to run training for longer than half an hour. Is there a solution for this in the meantime. I understand this might be solved, but was not really planned for.

Thx

Sorry, forgot:
running GeForce 940M with 2 GB VRAM (Acer Aspire E 17)

From a different issue #2810, we've found some problems with 940M cuda driver. The problem was solved by:
https://github.com/tensorflow/tensorflow/issues/2810#issuecomment-232476283

Build from source while explicitly setting 5.0 build target in "configure".
Or install the latest graphics driver 367.27.

Not sure whether it is related. But it is worth trying.

Latest Driver solved it. Thx a bunch
By the way: Scripts running much faster now. Dodnt measure precisely but about a factor 2 on cifar-10

I meet the same problem with GeForce GTX 1080, I build from source and configure compute capability to 6.1. I run a modified version of cifar10, after 9990 step(I set max_step = 10000), program failed.
`2016-08-11 17:26:23.054839: step 9980, loss = 5.73 (55.6 examples/sec; 2.302 sec/batch)
2016-08-11 17:26:47.250385: step 9990, loss = 5.70 (52.9 examples/sec; 2.420 sec/batch)
E tensorflow/stream_executor/cuda/cuda_event.cc:49] Error polling for event status: failed to query event: CUDA_ERROR_DEINITIALIZED
F tensorflow/core/common_runtime/gpu/gpu_event_mgr.cc:198] Unexpected Event status: 1
Aborted (core dumped)
`

@suiyuan2009 did you try the driver update?
Did it resolve the problem for you?

@gunan I solved the problem, but I forget how to solve...

OK, then I will close this issue.


Thanks @AnomalRoil


Docker connection issue - connection timeout while connecting to https://index.docker.io

Output of docker version:
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        2016-02-22T22:37:33.778002647+00:00
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 8
Images: 3
Server Version: 1.10.2
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 35
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.1.18-boot2docker
Operating System: Boot2Docker 1.10.2 (TCL 6.4.1); master : 611be10 - Mon Feb 22 22:47:06 UTC 2016
CPUs: 1
Total Memory: 1.956 GiB
Name: default
ID: AV52:G4SD:EIAQ:UXXJ:D3DR:33PQ:56IG:P37G:RXT3:GI2S:7ZFC:K4WM
Debug mode (server): true
 File Descriptors: 11
 Goroutines: 24
 System Time: 2016-03-25T18:46:40.280651277Z
 EventsListeners: 1
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Labels:
 provider=virtualbox

I was following along with Docker tutorial over here: https://docs.docker.com/mac/step_three/
I am able to run the docker run hello-world implying the initial set up in working.
Output of docker search whalesay
Error response from daemon: Get https://index.docker.io/v1/search?q=whalesay: dial tcp: lookup index.docker.io on <IP_ADDRESS>:53: read udp <IP_ADDRESS>:58317-><IP_ADDRESS>:53: i/o timeout

Output of docker pull hello-world
Using default tag: latest
Pulling repository docker.io/library/hello-world
Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/hello-world/images. You may want to check your internet connection or if you are behind a proxy.

Output of curl -v https://index.docker.io:443
* Adding handle: conn: 0x7f9c01002200
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f9c01002200) send_pipe: 1, recv_pipe: 0
* About to connect() to index.docker.io port 443 (#0)
*   Trying <IP_ADDRESS>...
* Connected to index.docker.io (<IP_ADDRESS>) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* Server certificate: *.docker.io
* Server certificate: RapidSSL SHA256 CA - G3
* Server certificate: GeoTrust Global CA
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: index.docker.io
> Accept: */*
>
< HTTP/1.1 301 MOVED PERMANENTLY
* Server nginx/1.6.2 is not blacklisted
< Server: nginx/1.6.2
< Date: Fri, 25 Mar 2016 11:19:56 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< X-Frame-Options: SAMEORIGIN
< Location: https://registry.hub.docker.com/
< Strict-Transport-Security: max-age=31536000
<
* Connection #0 to host index.docker.io left intact

I am not sure what's the issue here. Any network settings I need to look into?
I tried to check if I am behind a proxy on http://whatismyipaddress.com/proxy-check and http://amibehindaproxy.com/  Both of them say Proxy server not detected

Looks like it can't reach the DNS server? read udp <IP_ADDRESS>:58317-><IP_ADDRESS>:53: i/o timeout
I'd try restarting the VM.

I did a fresh install of Docker toolbox. However, now I am not able to start the daemon.
Output of docker run hello-world
docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.
See 'docker run --help'.

Output of docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL   SWARM   DOCKER    ERRORS
default   -        virtualbox   Stopped                 Unknown

Output of docker-machine start default
Starting "default"...
(default) Check network to re-create if needed...
(default) Creating a new host-only adapter produced an error: /usr/local/bin/VBoxManage hostonlyif create failed:
(default) 0%...
(default) Progress state: NS_ERROR_FAILURE
(default) VBoxManage: error: Failed to create the host-only adapter
(default) VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory
(default) VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterfaceWrap, interface IHostNetworkInterface
(default) VBoxManage: error: Context: "RTEXITCODE handleCreate(HandlerArg*)" at line 71 of file VBoxManageHostonly.cpp
(default)
(default) This is a known VirtualBox bug. Let's try to recover anyway...
Error setting up host only network on machine start: The host-only adapter we just created is not visible. This is a well known VirtualBox bug. You might want to uninstall it and reinstall at least version 5.0.12 that is is supposed to fix this issue

it said this
(default) This is a known VirtualBox bug. Let's try to recover anyway...
Error setting up host only network on machine start: The host-only adapter we just created is not visible. This is a well known VirtualBox bug. You might want to uninstall it and reinstall at least version 5.0.12 that is is supposed to fix this issue

@HackToday I was doing a fresh install with the latest version of Docker Toolbox.
Also, VirtualBox version is 5.0.16

I've seen this happen on OSX when my laptop IP changes. Restarting docker-machine fixes it.
The error message should be more informative.

@jatins can you open an issue for this in the docker machine issue tracker (https://github.com/docker/machine) to improve the error message? This looks like an issue with docker-machine, so not something we can fix in this repository.
Thanks for reporting!
I'll close the issue here, but feel free to comment after I closed

I had this issue while trying to dockerize a nodejs app.
Was able to correct the problem by restarting the docker-machine - see https://docs.docker.com/machine/reference/restart/
Host Machine: Win10
Docker-toolbox running in MING64


res_pcells lvs testing

Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

drc and lvs testing results after modifications :

metal_resistors (variant_A : 3LM) :

metal_resistors (variant_B : 4LM):

metal_resistors (variant_C : 5LM):

metal_resistors (variant_D : 6LM):

nplus_s :

nplus_u :

pplus_s :

pplus_u :

nwell :

pwell :

npolyf_s :

npolyf_u :

ppolyf_s :

ppolyf_u :

ppolyf_u_high_rs :

@FaragElsayed2 , ready for testing and review


xsimd with clang-cl

I'm trying to compile xsimd with clang-cl and I get the following error:
C:\PROGRA~1\LLVM\bin\clang-cl.exe  /nologo -TP  -IC:\tools\miniconda3\Library\include -ID:\a\1\s\include /DWIN32 /D_WINDOWS /W3 /GR /EHsc /EHsc /MP /bigobj /arch:AVX2 /MD /O2 /Ob2 /DNDEBUG   /EHsc /MP /bigobj /arch:AVX2 /W0 -fms-compatibility /showIncludes /Fotest\CMakeFiles\test_xsimd.dir\xsimd_algorithms.cpp.obj /Fdtest\CMakeFiles\test_xsimd.dir\ -c D:\a\1\s\test\xsimd_algorithms.cpp
In file included from D:\a\1\s\test\xsimd_algorithms.cpp:13:
In file included from D:\a\1\s\include\xsimd/xsimd.hpp:15:
In file included from D:\a\1\s\include\xsimd/math/xsimd_math.hpp:16:
In file included from D:\a\1\s\include\xsimd/math/xsimd_gamma.hpp:16:
In file included from D:\a\1\s\include\xsimd/math/xsimd_trigonometric.hpp:14:
D:\a\1\s\include\xsimd/math/xsimd_trigo_reduction.hpp(116,23): error: no matching function for call to 'horner'
                B y = horner<B,
                      ^~~~~~~~~
D:\a\1\s\include\xsimd/math/xsimd_trigonometric.hpp(112,51): note: in instantiation of member function 'xsimd::detail::trigo_evaluation<xsimd::batch<double, 4>, double>::sin_eval' requested here
                const B se = trigo_evaluation<B>::sin_eval(z, xr);
                                                  ^
D:\a\1\s\include\xsimd/math/xsimd_trigonometric.hpp(168,55): note: in instantiation of function template specialization 'xsimd::detail::trigo_kernel<xsimd::batch<double, 4> >::sin<xsimd::detail::trigo_radian_tag>' requested here
        return detail::trigo_kernel<batch_type_t<B>>::sin(x());
                                                      ^
D:\a\1\s\include\xsimd/math/xsimd_math_complex.hpp(364,32): note: in instantiation of function template specialization 'xsimd::sin<xsimd::batch<double, 4> >' requested here
            return batch<T, N>(sin(z.real()) * cosh(z.imag()), cos(z.real()) * sinh(z.imag()));
                               ^
D:\a\1\s\include\xsimd/math/xsimd_math_complex.hpp(393,24): note: in instantiation of function template specialization 'xsimd::detail::sin_complex_impl<std::complex<double>, 4>' requested here
                return sin_complex_impl(z);
                       ^
D:\a\1\s\include\xsimd/math/xsimd_trigonometric.hpp(168,55): note: in instantiation of member function 'xsimd::detail::trigo_kernel<xsimd::batch<std::complex<double>, 4> >::sin' requested here
        return detail::trigo_kernel<batch_type_t<B>>::sin(x());
                                                      ^
D:\a\1\s\test\xsimd_algorithms.cpp(219,15): note: in instantiation of function template specialization 'xsimd::sin<xsimd::batch_proxy<xsimd::batch<std::complex<double>, 4> > >' requested here
    *cbegin = sin(*cbegin);
              ^
D:\a\1\s\include\xsimd/math/xsimd_horner.hpp(42,14): note: candidate template ignored: substitution failure: too many template arguments for function template 'horner'
    inline T horner(const T&) noexcept
             ^
D:\a\1\s\include\xsimd/math/xsimd_horner.hpp(48,14): note: candidate template ignored: invalid explicitly-specified argument for template parameter 'c0'
    inline T horner(const T&) noexcept
             ^
D:\a\1\s\include\xsimd/math/xsimd_horner.hpp(54,14): note: candidate template ignored: invalid explicitly-specified argument for template parameter 'c0'
    inline T horner(const T& x) noexcept
             ^

Any suggestions on a possible fix? This is the bulld log on Azure Pipelines: https://dev.azure.com/robertodr/xismd/_build/results?buildId=71

Does it work if you replace the lines
                B y = horner<B,
                             0xbfc5555555555548ll,
                             0x3f8111111110f7d0ll,
                             0xbf2a01a019bfdf03ll,
                             0x3ec71de3567d4896ll,
                             0xbe5ae5e5a9291691ll,
                             0x3de5d8fd1fcf0ec1ll>(z);

with
                B y = horner<B,
                             0xbfc5555555555548ull,
                             0x3f8111111110f7d0ull,
                             0xbf2a01a019bfdf03ull,
                             0x3ec71de3567d4896ull,
                             0xbe5ae5e5a9291691ull,
                             0x3de5d8fd1fcf0ec1ull>(z);

Indeed! Thanks, here is the Azure build log: https://dev.azure.com/robertodr/xismd/_build/results?buildId=76 I'll prepare a PR

Fixed in #280

@robertodr Do you need a release with this fix? Or is it ok for you to work with the master branch?

A release with conda package would be preferable. I can then submit PRs for xtensor, xtensor-blas, and xtensor-python with clang-cl support.

Ok done ;) Let's wait for the conda bot to open the PR for us.

Much appreciated! The xtensor and xtensor-blas PRs are next in line.


RPC Subscribe unit test (RIPD-1076)

Reviewers: @ximinez @scottschurr

It looks like something's not quite right on gcc.  I see this error on both of the Travis gcc builds:
In file included from src/ripple/wsproto/wsproto.h:23:0,
                 from src/ripple/test/impl/WSClient.cpp:26,
                 from src/ripple/unity/test.cpp:53:
src/ripple/wsproto/basic_socket.h: In function ‘auto wsproto::detail::asio_handler_is_continuation(wsproto::detail::read_op<Stream, MutableBuffers, Handler>*)’:
src/ripple/wsproto/basic_socket.h:434:13: error: expected primary-expression before ‘:’ token
             : boost_asio_handler_cont_helpers::
             ^
src/ripple/wsproto/basic_socket.h:434:13: error: expected ‘;’ before ‘:’ token
src/ripple/wsproto/basic_socket.h:434:13: error: expected primary-expression before ‘:’ token

This isn't ready, because of the issues with the Server and the websocket client.


helo_argument IP should be encapsulated in []'s

This is a patch proposed by Chris Knadle<EMAIL_ADDRESS>to make torbirdy compliant with RFC 5821 §4.1.3.
Also see Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812115
Also look at which has a related issue:
https://trac.torproject.org/projects/tor/ticket/13006

Merged; thanks and sorry for the delay.


skypeforlinux: <IP_ADDRESS> -> <IP_ADDRESS>

Motivation for this change
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] 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/)
[ ] Fits CONTRIBUTING.md.

We do not merge to stable without first merging to master.
We do not upgrade stable without good reason. Why do you want it upgraded? Skype 5 seems to work fine.
Currently skypeforlinux 8 will require a lot of effort to maintain because they delete old minor versions as soon as they release new ones, and they change 8 much more often than 5.

One thing we could definitely do is add skypeforlinux 8 under a new attribute skypeforlinux8 if either its name is not skypeforlinux-${version}, or it is adjusted with lowPrio.

We do not merge to stable without first merging to master.

Sorry, this was my first time submitting changes and I found the manual a bit confusing, suggesting I edit off the release branch (and then obviously rebasing to master is a mess). Furthermore, the CONTRUBTING document did not specify which branch to pull request. Still, point taken. This change (if wanted) should be merged to master instead.

We do not upgrade stable without good reason. Why do you want it upgraded? Skype 5 seems to work fine.
Currently skypeforlinux 8 will require a lot of effort to maintain because they delete old minor versions as soon as they release new ones, and they change 8 much more often than 5.

Fair enough.

One thing we could definitely do is merge skypeforlinux 8 into master under a new attribute skypeforlinux8 if either its name is not skypeforlinux-${version}, or it is adjusted with lowPrio.

This would be an interesting solution, but I feel I do not have the knowledge to properly discuss it.

@cruizh Thank you for the feedback, we will improve CONTRIBUTING.
lowPrio is just a prefix for callPackage, you can find examples in all-packages.nix. It is needed so that users of skypeforlinux 5 will not upgrade to 8 with a nix-env -u (if both derivations have the same name; otherwise 8 will not be a candidate for update from 5). I believe it is best not to upgrade to skypeforlinux 8 for the time being.


[meta] Should we install code-server ourselves or adjust Dive CI settings on wasted size?

About this Issue
As per https://github.com/code-server-boilerplates/starter-pack/pull/11#issuecomment-896863702, the Dive CI for code-server upgrades was failed because /tmp/code-server-*.deb files are left intact, possibly due to image layering-related stuff.
Options?

Install code-server and other stuff ourselves. Instead of using codercom/code-server as the base image, we'll use debian:10 if we do that, while keeping the version locking stuff, probably.
Temporary: bump highestwastedBytes to at least 300 MB up to 512 MB. This way, we can pass our test CI and merge it

@ajhalili2006 speaking:
As of commit https://github.com/code-server-boilerplates/starter-pack/commit/9e2e5d70d7f47fd4d96fd450c9a8a7065d6e880d, we bumped that to 512 MB, so we should be probably fine for the next automated PRs.

Bumping is fine, but we really need to install code-server ourselves now. Will update you later.


Upgrade to Ruby 3.0.5

Fixes #3225

Upgrade to Ruby version 3.0.5
Bumped all Github actions to use ruby 3.0
Cleaned up Gemfile by:

removing gems that were already commented out
removed selenium-webdriver and capybara-webmock
removing version restrictions on: danger, font-awesome-sass, webdrivers

Ran into issue with @import 'font-awesome-sprockets'; line in app/assets/stylesheets/application.scss. Removed that line after referring to the latest font-awesome install/setup guide which no longer includes it.
Updated places that were incorrectly using keyword args. See this article for an overview
Removed .freeze from Regex and Range constants since those types are already immutable
Fixed Rubocop complaint about redundancy of r.nil? ? nil : r.user, so changed it to r&.user in app/models/plan.rb
Fixed Rubocop complaint about redundant :: in config.log_formatter = ::Logger::Formatter.new in config/environments/production.rb
Froze deprecator constants that were Strings
Cleaned up spec/rails_helper.rb and spec/spec_helper.rb
Simplified the spec/support/capybara.rb helper to work with the latest version of Capybara and use its built in headless Chrome driver

I will have to check, the column sorts looked ok. I will do a more thorough check though.

great! thanks for reviewing it @pengyin-shan


parameters and MACs

Thank you for your research and the code.
Is it possible to share the number of parameters and MACs of this model?

The model has 33G FLOPs and 454MB storage cost.


Feature Idea: 3D rendering with three.js

I learned about Kino customization
https://qiita.com/RyoWakabayashi/items/33b41f2f0efcc9710d15
I don't know much about three.js, but I was able to get a 3D rendering using three.js to work on Livebook
It would be interesting to add such a feature
defmodule KinoCustom.Three do
  use Kino.JS

  def new(color) do
    Kino.JS.new(__MODULE__, color)
  end

  asset "main.js" do
    """
    import<EMAIL_ADDRESS>
    export function init(ctx, color) {
      const canvas = document.createElement("canvas");
      ctx.root.appendChild(canvas);

      const renderer = new THREE.WebGLRenderer({canvas: canvas});
      const width = 320;
      const height = 320;
      renderer.setSize(width, height);

      const scene = new THREE.Scene();

      const camera = new THREE.PerspectiveCamera(45, width / height, 1, 1000);

      camera.position.set(0, 0, 500);

      const size = 80;
      const geometry = new THREE.BoxGeometry(size, size, size);
      const material = new THREE.MeshStandardMaterial({color: color});

      const box = new THREE.Mesh(geometry, material);
      scene.add(box);

      const light = new THREE.DirectionalLight(0xffffff);
      light.intensity = 2;
      light.position.set(1, 1, 1);
      scene.add(light);

      light.position.set(1, 1, 1);

      renderer.render(scene, camera);

      tick();

      function tick() {
        requestAnimationFrame(tick);

        box.rotation.x += 0.05;
        box.rotation.y -= 0.05;

        renderer.render(scene, camera);
      }
    }
    """
  end
end

Hi @RyoWakabayashi! Thank you for all the great writing you do on Livebook. If we want to include this in Livebook, I think the biggest question is how we are going to define this from the Elixir side. If the user has to write JavaScript, then perhaps a custom Kino.JS is indeed the best route (although we can likely make it a bit easier to define!).

@RyoWakabayashi using kino main you can do this:
Kino.HTML.new("""
<canvas id="canvas"></canvas>

<script type="module">
import<EMAIL_ADDRESS>
const canvas = document.querySelector("#canvas");

const renderer = new THREE.WebGLRenderer({canvas: canvas});
const width = 320;
const height = 320;
renderer.setSize(width, height);

const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(45, width / height, 1, 1000);

camera.position.set(0, 0, 500);

const size = 80;
const color = "green";
const geometry = new THREE.BoxGeometry(size, size, size);
const material = new THREE.MeshStandardMaterial({color: color});

const box = new THREE.Mesh(geometry, material);
scene.add(box);

const light = new THREE.DirectionalLight(0xffffff);
light.intensity = 2;
light.position.set(1, 1, 1);
scene.add(light);

light.position.set(1, 1, 1);

renderer.render(scene, camera);

tick();

function tick() {
  requestAnimationFrame(tick);

  box.rotation.x += 0.05;
  box.rotation.y -= 0.05;

  renderer.render(scene, camera);
}
</script>
""")

and if there's need for parameterizing the component with options, then it makes more sense to implement it as a custom Kino.JS. kino_vega_lite is one example of Elixir API on top of JS rendering :)


GH labels reorg

Following https://github.com/zephyrproject-rtos/zephyr/pull/15054 (Assuming it is merged),
this issue aims at settling other fixes for the labels which were not trivially agreed yet.
I list each proposal in a separate point below, if you agree just give it a thumbs-up, if you disagree a down (and create a separate comment for it). Maybe we can handle the discussion just in this fashion.

Create/Rename labels for issues to be discussed in a following meeting,
review: {TSC|Securty|API|dev-review}
Purpose: To clearly communicate to the issue/PR author that he his issue will probably be discussed there.
To have a quick filter in the meeting of issues which are meant to be discussed.
To avoid confusion with an issue simply being related to the APIs or Security area (but not meant to be discussed).

Rename the "TSC", "Maintainer", "Trivial" & "Security" labels into
review time: {4h (trivial)| 2d (maintainer)| 3d | 1w (contentious)}
(Also update the figure and text in https://docs.zephyrproject.org/latest/development_process/review_process.html? highlight=review%20time , to reflect this new naming)
Purpose: To decouple what needs to be discussed in a meeting, and how long something should be review. Hopefully avoiding some confusion.

Create labels "area:Security" and "area:API"

CC (run out of assignments): @jhedberg , @jfischer-phytec-iot , @nategraff-sifive , @mgielda , @ruuddw , @smijovic-si

Great work! +1 to all the above. I'd like to propose for up/down voting:
Remove DNM label and just use "Draft" PRs: https://github.blog/2019-02-14-introducing-draft-pull-requests/

Remove DNM label and just use "Draft" PRs

The thing with this one, is that you cannot take a normal PR into draft. While quite a few times, DNM is added to a PR for some reason afterwards. I would promote people using Draft PRs, but would not remove the DNM label.

I would promote people using Draft PRs, but would not remove the DNM label.

Fair enough; I didn't know that.

Remove DNM label and just use "Draft" PRs

The thing with this one, is that you cannot convert a normal PR into draft. While quite a few times, DNM is added to a PR for some reason afterwards. I would promote people using Draft PRs, but would not remove the DNM label.

Yes, I think this is a good approach.

(and create a separate comment for it). Maybe we can handle the discussion just in this fashion.

Unfortunately github issues don't seem to support any form of threading, so while voting works, discussing particular changes doesn't really seem posssible here :-(  On the other hand you could stack a modification PR on top of the "current state" PR #15054
https://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/
Or even better: just expedite PR #15054

To clearly communicate to the issue/PR author that the issue will probably be discussed there.

Can it also be set by the author to request discussion in the meeting?
This is a common problem with a number of labels: From: whom To: whom? This needs to be clarified in the doc, hopefully on a per prefix basis to keep things consistent and simple.

Or even better: just expedite

That depends only on people approving that PR, and somebody merging it. Today both @carlescufi & @nashif have old addressed rejections which are pending their re-review..
@marc-hb If you like that PR, you can show so by approving it. If you like any of the proposals above you can indicate it with a thumb-up

Can it also be set by the author to request discussion in the meeting?

Yes, at least for collaborators it should be possible.

Rename the "TSC", "Maintainer", "Trivial" & "Security" labels into
review time: {4h (trivial)| 2d (maintainer)| 3d | 1w (contentious)}
(Also update the figure and text in https://docs.zephyrproject.org/latest/development_process/review_process.html? highlight=review%20time , to reflect this new naming)
Purpose: To decouple what needs to be discussed in a meeting, and how long something should be reviewed. Hopefully avoiding some confusion.

I'm not sure renaming TSC/Maintainer to a review time is useful. The intent of the label is to highlight who needs to pay attention. I know the TSC label gets used a good bit in the TSC meetings.

Should we close? Looks like the process PR was merged. Nice work @aescolar!

Closing this as further progress seems very unlikely.
@mbolivar That PR was a precursor to what was proposed here. None of these proposals has been taken in.

Closing this as further progress seems very unlikely.

Is this disappointment at the low number of votes, lack of consensus off-line or just lack of time? In the first case and now that PR #15054 has been merged  (thx!), I hope following-up with more "traditional" PRs would get more attention than this issue and its less "familiar" voting system.

@marc-hb lack of consensus.


How to use 6 DoF robot localization

I followed your instructions and applied "3 DoF robot localization / mapping" to my real robot successfully. (https://github.com/carlosmccosta/dynamic_robot_localization/issues/18#issuecomment-640266635)
And I want to try 6 DoF robot localization now.
First, I wonder if I must use this file(https://github.com/carlosmccosta/dynamic_robot_localization_tests/blob/hydro-devel/launch/environments/labiomep/labiomep_6dof.launch).
Or should I use octo_map.launch?
Can you tell me which parameters to change and which launch file to use?

Good night,
For 6 DoF tracking you can use as a starting point the launch files from labiomep_6dof.launch or ethzasl_kinect_dataset.launch (mainly to see the yaml configurations for the drl pipeline, the rest is for configuring the test environment and automatically load the bag files).
OctoMap can be used for adding the mapping functionality with ray tracing and dynamic addition and removal of geometry.
drl can do additive mapping internally (it can keep adding the registered point clouds to its reference map, if you enable that feature). But if you require dynamic maps in which there are dynamic objects moving around the 3D space, octomap allows the removal of these points, because it does ray tracing -> when several sensor rays from consecutive scans pass through voxels that were marked as occupied (using data from previous sensor scans), then, those 3D cells are marked as "free space", effectively removing geometry / points from the map (because they no longer occupy that 3D space).
But in the weekend I will make a more user friendly launch file within the dynamic_robot_localization launch folder.
The drl pipeline is highly reconfigurable, so you can optimize it further to your particular use case. Nevertheless, I will add a generic 6 DoF tracking launch, so you can have a more user friendly starting point.
Have a nice day :)

Thanks for your detailed explanation. :)
I'm looking forward to your more launch file.
I will use your outdated launch file until your next update.

Hi Carlos,
I also wanted to mention, that I'm looking forward to a more generic 6 dof tracking launch file.
Keep up the great work!

Tobias

Hello,
I am occupied with other research projects right now, but I might be able to allocate some time during the end of this week to create the launch file after I finish the implementation of the Meijster distance transform in my PCL fork for initializing the correspondence estimation using look up tables that I implemented in my PCL fork -> it can significantly speedup ICP.
Have a nice day,

Great, I'm looking forward to it. The results in your paper look very promising, too. That could result in much better real-time 6dof localization.

Hi Carlos! @carlosmccosta
In recent days, I'm trying to implement your 3-D (6 DoF) Global Localization approach to achieve initial pose estimation and pose recovery. I'm wondering:

Which launch file should I use?
Is there any recommended demo dataset that I can use for testing?
Should I follow similar steps as the previous 2D localization case you guided me ?

Thanks again!
Wish you & your family a Merry Christmas and Happy New Year ! :)
Best Regards,
William

Hello,
As a starting point you can look at labiomep_6dof.launch and ethzasl_kinect_dataset.launch, which have both the configurations for drl and datasets.
I haven't had time yet to finish the lookup tables initialization with the Meijster algorithm. When I finish implementing it, I will create a more generic 6 DoF launch file using lookup tables for faster localization (when compared with kd-trees).
Merry Christmas and happy new year :)

Dear Carlos,
Thanks for your speedy reply.
I'm very looking forward to your more generic 6 DoF launch file :)
Best Regards,
William

Hi Carlos,
I wonder whether you had success implementing and testing the lookup tables initialization with the Meijster algorithm. Any news on that topic?
Best, T

Good night,
I am involved in other research projects and haven't had time to finish the Meijster lut initialization.
Nevertheless, the lut initialization with kd-trees is implemented, but it takes longer to initialize the lut when compared with the Meijster algorithm.
I may have some time next month, depending on how long it takes to finish the other projects tasks.
Have a nice day :)

Hello,
I refactored ethzasl_kinect_dataset.launch into a more generic 6 dof launch file available at dynamic_robot_localization_system_6dof.launch.
Examples on how to use it in use_cases.md.
For now, the usage of lookup tables (LUTs) in 6 DoF requires the initialization with k-d trees (when I have some time I will finish the Meijster algorithm to speedup its initialization).
For activating the LUTs it is only necessary to change the correspondence_estimation_approach from CorrespondenceEstimation to CorrespondenceEstimationLookupTable in the cluttered_environments_dynamic_large_map_3d.yaml.
The lookup tables can speedup the correspondence estimation phase of the iterative closest point (ICP) algorithm from 20 to 60 times, depending on the sensor data, reference point cloud and configurations of drl.
But keep in mind that a LUT with small cell size (below 1 cm) for large reference point clouds (bounding box with several meters) requires a lot of RAM, while the corresponding k-d tree is extremely efficient in memory usage (at the cost of being slower than the LUT).
Also, k-d trees by being sparse search data structures initialize much faster than LUTs.
Have a nice day :)


WIP: Amplicon support

Amplicon support added. Tested on qiita-rc.
sample-information-file generation and qiita sample-id validation not present.
additional unit-tests not added yet.

Superseded by https://github.com/qiita-spots/qp-knight-lab-processing/pull/37. Closing.


fix(camera-plus): fixes outstanding issues

fixes #12
The first issue in #12 was fixed by https://github.com/NathanWalker/SwiftyCam/pull/10.
The second issue is fixed by this pull request, the methods needed to be exposed to objective-c so they could be called natively.
Leaving this as a WIP for now because it relies on https://github.com/NativeScript/ns-v8ios-runtime/pull/116 being merged and a new version of the runtime being released.

Thank you for this @Logikgate and sorry for delay on processing. We are going to bring several patches together on ios runtime including your PR and publish another 'rc' to validate this changeset against and will try to get a patch published next week on this.

@nativescript/ios rc published now containing https://github.com/NativeScript/ns-v8ios-runtime/pull/116 - we are merging this into a release staging branch to confirm.

@Logikgate testing this and appears a crash still occurs. It's interesting as it seems to crash and the previewLayer accessor, I added the info here:
https://github.com/nstudio/nativescript-plugins/commit/0057a92ea29e63cc3d02553b6a78d7902eae0a39
Not sure if you had seen anything similar at anytime?


fix: Backport #13229

This takes the spirit of https://github.com/knative/serving/pull/13229 and backports it to our version.
Upstream change was made after the refactoring/moving of this code in
To avoid bumping the knative/pkg dependency, an updated Drainer was
copied over.
Relevent commits:
Queue Proxy: https://github.com/knative/serving/commit/ea5c5354d959cad488a30d78be5f3aa38ea255fe
Drainer: https://github.com/knative/pkg/blob/97c7258e3a98b81459936bc7a29dc6a9540fa357/network/handlers/drain.go

This should go to the cw/1.1.4 branch.

Have the changes from this branch been merged in? Was worried about stomping those changes.

The debug changes are not going to stick around long term.  I don't really want them in the cw branch.  We will not be updating the activator deployment so these changes will not impact those deployments.


Ensuring that the private blob properties matches that of the container

This commit fixes a bug where the private property in blob properties is set using the x-ambry-private header which can be different from the private property of the container being uploaded to.

Codecov Report

Merging #758 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #758      +/-   ##
============================================
+ Coverage     65.39%   65.47%   +0.07%
- Complexity     3868     3869       +1
============================================
  Files           336      336
  Lines         25766    25766
  Branches       3224     3224
============================================
+ Hits          16849    16869      +20
+ Misses         8013     7994      -19
+ Partials        904      903       -1

Impacted Files
Coverage Δ
Complexity Δ

...src/main/java/com.github.ambry/rest/RestUtils.java
96.21% <100%> (ø)
54 <0> (ø)
:arrow_down:

....github.ambry.clustermap/StaticClusterManager.java
75.11% <0%> (-1.85%)
77% <0%> (-1%)

.../com.github.ambry.router/GetBlobInfoOperation.java
79.86% <0%> (-1.39%)
30% <0%> (-1%)

...java/com.github.ambry.router/GetBlobOperation.java
88.32% <0%> (-0.27%)
30% <0%> (-1%)

...src/main/java/com.github.ambry.commons/BlobId.java
82.45% <0%> (+0.87%)
32% <0%> (+1%)
:arrow_up:

...in/java/com.github.ambry.store/BlobStoreStats.java
85.64% <0%> (+1.91%)
92% <0%> (+2%)
:arrow_up:

.../main/java/com.github.ambry.store/HardDeleter.java
81.93% <0%> (+1.93%)
42% <0%> (+1%)
:arrow_up:

...b.ambry.network/BlockingChannelConnectionPool.java
66.22% <0%> (+2.19%)
8% <0%> (ø)
:arrow_down:

...github.ambry.rest/AsyncRequestResponseHandler.java
90.81% <0%> (+2.29%)
23% <0%> (ø)
:arrow_down:

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 15787a0...a92de98. Read the comment docs.


jackknifed hierarchical clustering

Jackknifing/bootstrapping is really easy to do with the new TabularMSA object, just generate a random index with np.random.choice!

This would be jackknifing based on counts in a feature table (for clustering samples), not columns in a TablularMSA. Good to know for the future though.


Istio does not allow domain name with more than 64 characters

(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities/
To ask questions about how to use Istio, please visit https://discuss.istio.io
)
Bug description
Istio does not allow domain name with more than 64 characters
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
Since there is no such limitation on domain name, Istio should be able to create them.
Steps to reproduce the bug
$ cat vs.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: test
spec:
  gateways:
  - istio-system/gateway
  hosts:
  - [HOST WITH MORE THAN 64 CHARS]
  http:
  - route:
    - destination:
        host: WHATEVER
***
$ kubectl apply -f vs.yaml
Error from server: error when creating "/tmp/routing.yaml": admission webhook "pilot.validation.istio.io" denied the request: configuration is invalid: domain name "[HOST WITH MORE THAN 64 CHARS]" invalid (label "[HOST WITH MORE THAN 64 CHARS]" invalid)

Version (include the output of istioctl version --remote and kubectl version)
$ istioctl version --remote
client version: version.BuildInfo{Version:"1.1.1", GitRevision:"2b1331886076df103179e3da5dc9077fed59c989", User:"root", Host:"7077232d-4c6c-11e9-813c-0a580a2c0506", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Clean", GitTag:"1.1.0-17-g2b13318"}
citadel version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d-dirty", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Modified", GitTag:"1.1.7-14-g145b18a"}
galley version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d-dirty", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Modified", GitTag:"1.1.7-14-g145b18a"}
galley version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d-dirty", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Modified", GitTag:"1.1.7-14-g145b18a"}
ingressgateway version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Clean", GitTag:"1.1.7-14-g145b18a"}
ingressgateway version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Clean", GitTag:"1.1.7-14-g145b18a"}
pilot version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d-dirty", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Modified", GitTag:"1.1.7-14-g145b18a"}
pilot version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d-dirty", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Modified", GitTag:"1.1.7-14-g145b18a"}
policy version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d-dirty", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Modified", GitTag:"1.1.7-14-g145b18a"}
telemetry version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d-dirty", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Modified", GitTag:"1.1.7-14-g145b18a"}
telemetry version: version.BuildInfo{Version:"1.1.8", GitRevision:"145b18a441045d6fad33d7916380d8642c7bf21d-dirty", User:"root", Host:"11387264-87af-11e9-b00d-0a580a2c0205", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Modified", GitTag:"1.1.7-14-g145b18a"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.7-gke.25", GitCommit:"d4c79083ab6dea5d26ef4ed8d50b145268349bc3", GitTreeState:"clean", BuildDate:"2019-06-22T16:10:31Z", GoVersion:"go1.10.8b4", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
Using Helm Chart
Environment where bug was observed (cloud vendor, OS, etc)
GKE
Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.

@bappr is this something you ran into through normal Istio use, or just something you are noting?  This requirement was added due to a limitation with max number of characters allowed in cluster names within Envoy in coordination with how Istio uses hostnames in the cluster name generation logic

This is how kubernetes behaves as well - our validation logic is the same. DNS 1123 labels can be a max of 63 characters. See https://stackoverflow.com/questions/32290167/what-is-the-maximum-length-of-a-dns-name

Ok ok then I am closing this one.
I was not aware of that. This is something I am running through normal Istio use, we are basically creating subdomains on demand on our product. Gonna change the logic behind that on our end then>
Thanks guys


Send notification when order is ready

For now that this project is monolithic it's ok to have a notification system implemented within the project. However later on this needs to be sent to a celery task.
It's better to have an abstract class for notification system in case it grows into multiple types of notification (SMS, Email, Push notification, etc.)

Notification when order is set (with an order id)
Notification when order is ready
Scheduled notifications for previous customers (based on specific statistics) (using celery)

This task and the branch notification-system branch will be pended since the notification system is based on User model in the database which currently does not exist.
Once the #181 is completed (merged to develop branch), we will merge develop with notification-system and continue this task.


Performance improvement on large amount of items

Codecov Report

Merging #7 (e6fc546) into master (01fc479) will increase coverage by 1.07%.
The diff coverage is 65.82%.

@@            Coverage Diff             @@
##           master       #7      +/-   ##
==========================================
+ Coverage   33.75%   34.83%   +1.07%
==========================================
  Files          20       21       +1
  Lines        1576     1625      +49
==========================================
+ Hits          532      566      +34
- Misses       1044     1059      +15

Impacted Files
Coverage Δ

ChatLayout/Classes/Core/ChatLayout.swift
0.00% <0.00%> (ø)

ChatLayout/Classes/Core/Model/LayoutModel.swift
70.00% <59.45%> (-8.58%)
:arrow_down:

ChatLayout/Classes/Core/Model/SectionModel.swift
75.90% <76.92%> (+0.18%)
:arrow_up:

...hatLayout/Classes/Core/Model/StateController.swift
77.84% <78.94%> (+0.44%)
:arrow_up:

ChatLayout/Classes/Core/Model/ModelState.swift
100.00% <100.00%> (ø)

ChatLayout/Classes/Core/Model/ItemPath.swift
100.00% <0.00%> (ø)

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 01fc479...e6fc546. Read the comment docs.


Internal Python Language Server error

Description
What steps will reproduce the problem?

Pasting something in the editor. I don't know what ekse.
Traceback
  File "/usr/local/lib/python3.7/site-packages/pyls_jsonrpc/endpoint.py", line 113, in consume
    self._handle_request(message['id'], message['method'], message.get('params'))
  File "/usr/local/lib/python3.7/site-packages/pyls_jsonrpc/endpoint.py", line 182, in _handle_request
    handler_result = handler(params)
  File "/usr/local/lib/python3.7/site-packages/pyls_jsonrpc/dispatchers.py", line 23, in handler
    return method(**(params or {}))
  File "/usr/local/lib/python3.7/site-packages/pyls/python_ls.py", line 352, in m_text_document__signature_help
    return self.signature_help(textDocument['uri'], position)
  File "/usr/local/lib/python3.7/site-packages/pyls/python_ls.py", line 284, in signature_help
    return self._hook('pyls_signature_help', doc_uri, position=position)
  File "/usr/local/lib/python3.7/site-packages/pyls/python_ls.py", line 153, in _hook
    return hook_handlers(config=self.config, workspace=workspace, document=doc, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/pluggy/hooks.py", line 286, in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/local/lib/python3.7/site-packages/pluggy/manager.py", line 93, in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/local/lib/python3.7/site-packages/pluggy/manager.py", line 337, in traced_hookexec
    return outcome.get_result()
  File "/usr/local/lib/python3.7/site-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/usr/local/lib/python3.7/site-packages/pluggy/callers.py", line 52, in from_call
    result = func()
  File "/usr/local/lib/python3.7/site-packages/pluggy/manager.py", line 335, in <lambda>
    outcome = _Result.from_call(lambda: oldcall(hook, hook_impls, kwargs))
  File "/usr/local/lib/python3.7/site-packages/pluggy/manager.py", line 87, in <lambda>
    firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
  File "/usr/local/lib/python3.7/site-packages/pluggy/callers.py", line 208, in _multicall
    return outcome.get_result()
  File "/usr/local/lib/python3.7/site-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/usr/local/lib/python3.7/site-packages/pluggy/callers.py", line 187, in _multicall
    res = hook_impl.function(*args)
  File "/usr/local/lib/python3.7/site-packages/pyls/plugins/signature.py", line 17, in pyls_signature_help
    signatures = document.jedi_script(position).call_signatures()
  File "/usr/local/lib/python3.7/site-packages/pyls/workspace.py", line 250, in jedi_script
    return jedi.Script(**kwargs)
  File "/usr/local/lib/python3.7/site-packages/jedi/api/__init__.py", line 132, in __init__
    raise ValueError('`line` parameter is not in a valid range.')

 I say it because (although I understand you didn't know what happened) this is not helpful:

Pasting something in the editor. I don't know what ekse.

Well the traceback is useful isn't it?

Without a reproducible source code we can't report this upstream, so there's no way this can be solved.
We could catch the ValueError in the PyLS, but that would just swallow the bug and silently pass on it.

From the traceback, it looks like pyls doesn't have the current version of the script (for some unknown reason), so in this case it would make sense to send back the content of the editor to pyls?

I don't think so. It look like an error in Jedi when trying to get the signature of an object.

I don't think so. It looks like an error in Jedi when trying to get the signature of an object.

Yes but the error is that the line number is not between 0 and whatever jedi thinks the end of the file is.

Ok, makes sense. However, I haven't seen this error before.
If you manage to reproduce it consistently, you could submit a PR to the PyLS to skip the error (because it seems a problem with the file contents in the PyLS not being updated correctly before passing them to Jedi).

I never saw that issue again. Closing.


Input data format

Hello, thank you very much for sharing your code.
My question will be very basic. While training how the structure of input data should be organized? So I've got full BP4D dataset and how I can get train.txt and val.txt files. I'll be very grateful for answer.

Hello, thank you for your interest in our work.
It is quite simple, it must have the following form:
Faces/file_name0.jpg 0
Faces/file_name1.jpg 1
Faces/file_name2.jpg 1
Faces/file_name3.jpg 0
...

And a different folder with the pre-calculated Optical Flow
Faces_Flow/file_name0.jpg 0
Faces_Flow/file_name1.jpg 1
Faces_Flow/file_name2.jpg 1
Faces_Flow/file_name3.jpg 0
...

Please take a look at data_loader script and change variables accordingly.

Thank you for answer! Now it's more clear to me.
But I've got one more qustion so in fact you're not using 2D and 3D Features from BP4D dataset?
I just need to convert AUCoding to your above format and it should work. Is that correct?

Yes to both of them, you are right.

Thank you again!


OADP-3395: Unbreak unsupportedOverrides field in DPA

Description
Revert add of enum validation to unsupportedOverrides field. Enum validation works with string fields, not object. To have field truly typed, it should be a struct. For development flexibility (no need to change DPA structure, only description) the field does not enforce typing.
How to test
Run new test in master branch and this PR branch. It should fail in master and succeed here.
Also, create DPA with unsupportedOverrides field. It should work.
Discussion points

For a false validation, another structure of E2E test needs to be created, as passing wrong image, does not break DPA reconcile, only Velero deployment.

Should we add in code validation for wrong keys?

Infra flake
INFO[2024-01-28T17:11:21Z] Step e2e-test-aws-e2e succeeded after 1h10m17s.

/override ci/prow/4.12-e2e-test-aws

looks good!
https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_oadp-operator/1290/pull-ci-openshift-oadp-operator-master-4.13-e2e-test-aws/1751626580477612032/artifacts/e2e-test-aws/e2e/build-log.txt
 > Enter [It] unsupportedOverrides should succeed - /go/src/github.com/openshift/oadp-operator/tests/e2e/dpa_deployment_suite_test.go:726 @ 01/28/24 16:25:54.286
2024/01/28 16:26:14 Waiting for velero pod to be running
2024/01/28 16:26:14 velero pods are running
2024/01/28 16:26:14 Checking for bsl spec
2024/01/28 16:26:14 Waiting for NodeAgent daemonset to be deleted
2024/01/28 16:26:14 Checking if NodeAgent daemonset has been deleted...
2024/01/28 16:26:14 Waiting for velero deployment to have expected plugins
2024/01/28 16:26:14 Checking for default plugins
2024/01/28 16:26:14 Waiting for velero deployment to have expected custom plugins
2024/01/28 16:26:14 Waiting for restic daemonSet to have nodeSelector
2024/01/28 16:26:14 Waiting for nodeAgent daemonSet to have nodeSelector
2024/01/28 16:26:14 Waiting for 1 minute after reconciled: 38.471156ms elapsed
2024/01/28 16:26:19 Waiting for 1 minute after reconciled: 5.038899452s elapsed
2024/01/28 16:26:24 Waiting for 1 minute after reconciled: 10.039994769s elapsed
2024/01/28 16:26:29 Waiting for 1 minute after reconciled: 15.043856419s elapsed
2024/01/28 16:26:34 Waiting for 1 minute after reconciled: 20.044148091s elapsed
2024/01/28 16:26:39 Waiting for 1 minute after reconciled: 25.048250381s elapsed
2024/01/28 16:26:44 Waiting for 1 minute after reconciled: 30.048918707s elapsed
2024/01/28 16:26:49 Waiting for 1 minute after reconciled: 35.053003333s elapsed
2024/01/28 16:26:54 Waiting for 1 minute after reconciled: 40.053167585s elapsed
2024/01/28 16:26:59 Waiting for 1 minute after reconciled: 45.057259872s elapsed
2024/01/28 16:27:04 Waiting for 1 minute after reconciled: 50.058365212s elapsed
2024/01/28 16:27:09 Waiting for 1 minute after reconciled: 55.062457708s elapsed
2024/01/28 16:27:14 Waiting for 1 minute after reconciled: 1m0.063301015s elapsed
  < Exit [It] unsupportedOverrides should succeed - /go/src/github.com/openshift/oadp-operator/tests/e2e/dpa_deployment_suite_test.go:726 @ 01/28/24 16:27:14.385 (1m20.099s)
  > Enter [AfterEach] Configuration testing for DPA Custom Resource - /go/src/github.com/openshift/oadp-operator/tests/e2e/dpa_deployment_suite_test.go:47 @ 01/28/24 16:27:14.385
  < Exit [AfterEach] Configuration testing for DPA Custom Resource - /go/src/github.com/openshift/oadp-operator/tests/e2e/dpa_deployment_suite_test.go:47 @ 01/28/24 16:27:14.385 (0s)
• [80.099 seconds]

/lgtm

INFO[2024-01-28T17:11:21Z] Step e2e-test-aws-e2e succeeded after 1h10m17s.
/override ci/prow/4.12-e2e-test-aws

last test failed on deprovision.
could not run steps: step e2e-test-aws failed: "e2e-test-aws" post steps failed: "e2e-test-aws" pod "e2e-test-aws-gather-aws-console" failed: pod pending for more than 30m0s: containers have not started in 30m0.000667439s: ci-scheduling-dns-wait, cp-entrypoint-wrapper, place-entrypoint, sidecar, test:

/cherry-pick oadp-1.3