Failed to fetch instance destinations. (Timed out after 10000ms)

Description of erroneous behaviour
We have a Node.js CAP application edom-retailer-core. In MDIClient.js, we are making a request via destination connecting to MdiDestination.
// package.json
"MdiDestination": {
   "kind": "rest",
   "credentials": {
      "destination": "mdi-dest",
      "requestTimeout": 1000000

The API in the destination retrieves 2000 items at a time and if it has more data, it will provide a deltaToken that we use to make the same call but with the deltaToken to retrieve the next 2000 items. We repeat this till all the items are retrieved. Currently our API has 19000+ items.
// MDIClient.js
const MDIDest = await cds.connect.to('MdiDestination');
const logRequest = new cds.Request();
const baseQuery = `GET /log/sap.odm.businesspartner.BusinessPartner`;

let moreData = true;
while (moreData) {
   if (deltaToken !== false) {
     logRequest.query = `${baseQuery}?since=${deltaToken}`;
   }
   const response = await MDIDest.tx(logRequest).run(logRequest.query);

   ...

   if (!response.hasMoreEvents) {
      moreData = false;
   }
}

The request is successful for the first 6-9 iterations but throws an error afterwards:
Error: Timed out after 10000ms
    at buildError (/mnt/c/Users/C5315270/Desktop/projects/edom-retailer-core/node_modules/opossum/lib/circuit.js:710:17)
    at Timeout.<anonymous> (/mnt/c/Users/C5315270/Desktop/projects/edom-retailer-core/node_modules/opossum/lib/circuit.js:511:29)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7) {
  cause: ErrorWithCause: Failed to fetch instance destinations.
      at new ErrorWithCause (/mnt/c/Users/C5315270/Desktop/projects/edom-retailer-core/node_modules/@sap-cloud-sdk/util/dist/error-with-cause.js:31:16)
      at /mnt/c/Users/C5315270/Desktop/projects/edom-retailer-core/node_modules/@sap-cloud-sdk/core/dist/connectivity/scp-cf/destination/destination-service.js:116:27
      at runNextTicks (internal/process/task_queues.js:62:5)
      at listOnTimeout (internal/timers.js:523:9)
      at processTimers (internal/timers.js:497:7)
      at async Promise.all (index 0)

I attached the console log and console error below.
log.txt
error.txt
Detailed steps to reproduce

For example (→ replace by appropriate ones for your case):

git clone https://github.wdf.sap.corp/c4u/edom-retailer-core.git
git checkout feat/25-mdiclient-outbound
npm install
cds deploy
cds run
In Postman, make a GET request to http://localhost:4004/api/alpha/mdiclient/MDIClient

Details about your project

edom-retailer
https://github.wdf.sap.corp/c4u/c4u-cn-edom-retailer

CAP Java Runtime
version

OData Version
version

@sap/cds-compiler
2.1.6

@sap/cds-dk
4.0.7

Used Versions:

node version via node -v: v12.22.1
npm version via npm -v: 6.14.12
SAP Cloud SDK version you used as dependency

"@sap-cloud-sdk/core": "^1.41.0",

Hi @LaxOn,
Thanks for bringing this up. We'll take a look into this shortly and get back to you with ideas.

@LaxOn, we'll have to provide an API to override the default timeout. Can you please share your deadline to have this solved? We'll also communicate with CAP to make sure their configuration for destinations is properly passed down to the Cloud SDK APIs.
cc @jjtang1985 @marikaner

Thanks @artemkovalyov for the quick response! We need it by the 2105 release (May 30, 2021). Thanks a lot!

Hi @LaxOn ,
thanks for sharing more information about the timeline.
The timeout configuration ticket is planned to be started in the next week. (not guaranteed).
Please keep in mind, you might NOT meet your deadline even with the new configuration because of the reasons:

we assume having a longer timeout can help in your case, which might not be the case
we need a new stable release for the configuration instead of using canary version, because you are not consuming the SDK directly, and CAP needs stable version.
CAP is able to use our new configurations

Best regards,
Junjie

Hey @LaxOn,
I am currently investigating this issue more closely and found some things that might be of interest for you:

The first issue in the given logs actually states that a "Possible EventEmitter memory leak [was] detected".
I found that, although I wasn't able to reproduce this, it is likely happening because of a bug in the SAP Cloud SDK. We will fix this as soon as we can.
I was able to reproduce the timeout issues by retrieving the same destination over and over. I have a few follow up questions and ideas for you.
If I am not mistaken you call this line:
const dest = await cloudSDK.getDestination('mdi-dest');
(or previously this line const MDIDest = await cds.connect.to('MdiDestination');)
for every incoming request.
However, the result of this request is always the same destination.
Therefore, in theory it would suffice to make this request once and reuse the destination for all subsequent requests.

If this is correct, you might be able work around this whole issue by requesting the destination once initially and reusing it for all subsequent requests. It would be great if you could try this approach and let us know if it solves your issue. I am afraid there might be a second, similar issue with the XSUAA service down the line.
Still under the assumption that this is correct, it would be even better to be able to use the SAP Cloud SDK's caching mechanisms for this. We realized, that we have potential for improvement here. As of today, the SAP Cloud SDK's caching cannot be used by CAP.
That said, I believe increasing the timeout might also solve your problem, however there are a few issues with this:

If my assumptions above are correct, it is a waste of resources to make the same requests over and over.
We are currently running into this timeout, because we are using a circuit breaker that shall protect the underlying systems. This circuit breaker is overarching all tenants and can therefore not be configured individually. It can however be turned off. That functionality again (similar to the caching) is not exposed in a manner, that it could be used with CAP (as of today).

We will discuss options internally. In the meantime it would be very helpful to know if my proposal above helps with your problem.

Hey @LaxOn,
btw, you can enable the SDK caching if you transform this line:
const dest = await cloudSDK.getDestination('mdi-dest');
to this:
const dest = await cloudSDK.getDestination('mdi-dest', { useCache: true });

Thanks for looking into this. I'll ping the CAP team to take a look at this as they're the one directly using cloudSDK.getDestination(). We would only be using the wrapper they provide.
I just noticed the MDIClient.js implementation I linked in the main post changed to the workaround we just implemented. I updated it to the original implementation that we had an issue with.

Hi @marikaner and @LaxOn,
within CAP we only use the executeHttpRequest method, that the Cloud SDK provides.
Is caching possible with that as well?

@LaxOn It would be very helpful for us to understand whether enabling the cache solves your problem. If so we would consider to prioritize the exposure of the caching capabilities to executeHttpRequest.

Hi @marikaner

Thanks for looking into this. I'll ping the CAP team to take a look at this as they're the one directly using cloudSDK.getDestination(). We would only be using the wrapper they provide.
I just noticed the MDIClient.js implementation I linked in the main post changed to the workaround we just implemented. I updated it to the original implementation that we had an issue with.

But did it work with the workaround? This might be helpful for an intermediate solution.

Our workaround is to use axios and manually building an http request. That workaround did not use executeHttpRequest so I don't know if enabling the cache would for sure solve our problem. Any thoughts @johannes-vogel ?

Hi @LaxOn,

Our workaround is to use axios and manually building an http request. That workaround did not use executeHttpRequest so I don't know if enabling the cache would for sure solve our problem. Any thoughts @johannes-vogel ?

Are you using cloudSDK.getDestination('mdi-dest', { useCache: true }) to retrieve the actual information of your endpoint and then use axios to retrieve the actual content?
If yes and if I understand @marikaner correctly, they would prioritize the destination caching feature for executeHttpRequest which is used by @sap/cds under the hood.

@johannes-vogel, yes, you understand correctly ;)

@johannes-vogel We do use cloudSDK.getDestination('mdi-dest', { useCache: true }) and axios for our workaround but we want to use our original implementation:
const MDIDest = await cds.connect.to('MdiDestination');
const logRequest = new cds.Request();
const baseQuery = `GET /log/sap.odm.businesspartner.BusinessPartner`;
const response = await MDIDest.tx(logRequest).run(logRequest.query);

as we are under the impression that this is the CAP way of sending requests where we don't explicitly use cloudSDK.getDestination('mdi-dest', { useCache: true }) and axios.  Would destination caching feature for executeHttpRequest  solve our issue with our original implementation as well?

@LaxOn If cloudSDK.getDestination('mdi-dest', { useCache: true }) fixes your issue, then yes, it could solve your problem as well. I take it that the workaround in fact does fix the issue?

Yes,

@LaxOn If cloudSDK.getDestination('mdi-dest', { useCache: true }) fixes your issue, then yes, it could solve your problem as well. I take it that the workaround in fact does fix the issue?

Yes, our workaround currently works. Please let the CAP team know once the update with the fix is released. Thanks!

@marikaner We currently think of applying this workaround also in CAP.
However, I have a short question regarding cloudSDK.getDestination('mdi-dest', { useCache: true }).
How would that behave if this is a multi tenant destination that is maintained in the subscriber accounts?

@johannes-vogel That depends on the isolation strategy. The default is "Tenant", which means that this is tenant aware. I hope that explains it?
We have discussed how to proceed on this, today. We were wondering whether the approach of calling getDestination is good enough and does not require adding the DestinationOptions to the parameters of executeHttpRequest.
The reason is, that we don't want to overcomplicate the signature of this function and getDestination already can handle this.
I remember that in the initial API design, we actually discussed this and decided to not add it for the mentioned reasons.
Let me know whether you think it would suffice to improve the documentation on this or whether you still would like to have this feature.

As discussed offline, the SDK API will remain as is, but we will improve the documentation on these possibilities.

@marikaner Wanted to further clarify the multitenant scenario:
Currently the behavior we have is that
const dest = await cloudSDK.getDestination('mdi-dest', { useCache: true });
connects to the destination service in the provider subaccount.
What do we need to do so it instead connects to the destination service in the consumer subaccount?

Hi @marikaner just wanted to follow up on this.
I've tried running const dest = await cloudSDK.getDestination('mdi-dest',{ useCache: true, isolationStrategy: "Tenant"})
and this connects to the provider subaccount still. How do we connect to the consumer subaccount?

Feel free to close this issue. I'm able to connect to the consumer subaccount uby providing a userJwt
await cloudSDK.getDestination('mdi-dest',{ useCache: true, isolationStrategy: "Tenant", userJwt:jwt})

Thanks for the update, @LaxOn. Don't hesitate to come to us if you need help with anything else.


Delete endpoints not used #3286

Renamed branch, PR already reviewed in https://github.com/CartoDB/cartodb/pull/3322

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)


cannot use BCryptSwift via cocoapods when targeting macOS (platform :osx)

Error when executing pod install:
$ pod install
[!] The platform of the target `TestBCSwift` (macOS 10.15) is not compatible with `BCryptSwift (1.1)`, which does not support `macOS`.

Podfile attached
Podfile.txt

To clarify, 1.1 loaded directly from github works, but 1.1 loaded from standard pod repository does not. Seems like a new version 1.2 should be released that contains macos support.


Resolve permission issue when updating submodules

What was changed

Switches to Commander token to resolve the push access when updating submodules
Why?

Submodules update pipeline fails with permission issue
Checklist

Closes

How was this tested:

not tested

Any docs updates needed?

@dnr it seems necessary to be set explicitly when making a push into a protected branch

I'm confused.. can you remove the other usage of the token or not?

it seems necessary to be set explicitly when making a push into a protected branch

I'm confused.. can you remove the other usage of the token or not?

@dnr is was required yes. I've went through the docs again to see exactly why this works this way. Also went checking if "Allow specified actors to bypass pull request requirements" would affect the need to set the token to a remote. So far seems it's just required at least with https and not ssh

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: feedmeapples:x: temporal-dataYou have signed the CLA already but the status is still pending? Let us recheck it.


Initial PR to support storing account metadata in MySql database

Joint dev work from @lightningrob and @Arun-LinkedIn

Codecov Report

Merging #1619 into master will decrease coverage by 0.33%.
The diff coverage is 25.57%.

@@             Coverage Diff              @@
##             master    #1619      +/-   ##
============================================
- Coverage     73.73%   73.39%   -0.34%
- Complexity     8493     8524      +31
============================================
  Files           595      605      +10
  Lines         46361    46800     +439
  Branches       5886     5903      +17
============================================
+ Hits          34182    34350     +168
- Misses        10419    10687     +268
- Partials       1760     1763       +3

Impacted Files
Coverage Δ
Complexity Δ

...rc/main/java/com/github/ambry/account/Account.java
95.83% <ø> (+1.04%)
30.00 <0.00> (ø)

...in/java/com/github/ambry/account/DatabaseTest.java
0.00% <0.00%> (ø)
0.00 <0.00> (?)

.../com/github/ambry/account/MySqlAccountsDBTool.java
0.00% <0.00%> (ø)
0.00 <0.00> (?)

.../github/ambry/account/mysql/MySqlDataAccessor.java
43.47% <43.47%> (ø)
6.00 <6.00> (?)

...va/com/github/ambry/account/AccountSerdeUtils.java
75.00% <75.00%> (ø)
4.00 <4.00> (?)

...a/com/github/ambry/account/mysql/ContainerDao.java
78.57% <78.57%> (ø)
6.00 <6.00> (?)

...ava/com/github/ambry/account/mysql/AccountDao.java
80.64% <80.64%> (ø)
4.00 <4.00> (?)

...va/com/github/ambry/account/mysql/MySqlConfig.java
100.00% <100.00%> (ø)
1.00 <1.00> (?)

...ambry/network/http2/Http2NetworkClientFactory.java
75.00% <0.00%> (-25.00%)
3.00% <0.00%> (+1.00%)
:arrow_down:

...github/ambry/rest/AsyncRequestResponseHandler.java
86.86% <0.00%> (-3.37%)
22.00% <0.00%> (ø%)

... and 38 more

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 3e163f7...6509cc9. Read the comment docs.


0.3.6 Docs broken link

The following link is broken:
http://flask-restful.readthedocs.io/en/0.3.6/
And although http://flask-restful.readthedocs.io/en/0.3.5/ works, it shows the following:

Also the API Docs page is broken as well http://flask-restful.readthedocs.io/en/0.3.5/api.html

Indeed @expobrain, this has been reported in #661 by the way ;).


python bindings for wellen

this PR adds python bindings for wellen. many of these APIs mirror what is in rust, with the change that functions that would return refs (e.g. ScopeRefs, VarRefs) just return the object itself (Scope, Var, etc).
Performance hasn't been a focus, and there is a bunch of inefficient things that are happening -- not looking to solve that with this PR. core functionality and processes (CI, pypi releases) are the main focus.
I have a Makefile for convience in the pywellen/ path. To build and test the code, execute
make deps # creates a venv, installs deps
make test #builds the wheel, installs it, calls pytest

To look at the python code "in action", checkout tests/. Currently we expect python3.8 and above to be supported, this was done arbitrarily (python38 was used a lot in circles i used to run in)
Remaining blockers are:

[x] add post commit CI, testing pywellen on every push
[x] add release flow to PYPI -- my current proposal would be any push to tag X.X.X will build and upload pywheels to pypi
[x] implement all features so we can slot pywellen into wal. We wouldnt be blocked on merging any changes into WAL, it would just be a good exercise to pipeclean pywellen interfaces
[x] clean up the code (naturally) -- pretty much everything is implemented in lib.rs right now, and it's not too crowded yet

only action item left is to add a PYPI_API_TOKEN to the project secrets -- everything else looks good. punted on trying to get pywellen working with WAL with this PR, will do that in the Future

@1024bees : looks like publishing is working now: https://pypi.org/project/pywellen/

We should probably write a separate Readme for the python bindings at some point.

great! thanks for adding that in, i'll put the README on todos for future releases

Sounds good! Thanks for the great PR!
Depending on the envisioned use-cases, there might be some fun higher level APIs we could provide. One thing I have needed in the past is a "sampled" view of a signal. For that, the user would supply which signals they are interested in + which signal functions as the clock signal + whether they want to sample on the posedge or the negedge. Then we would return signal values based on clock ticks instead of time steps (ideally, as an iterator).

yes! that would be great.
in the same vein i've been thinking of a generic "virtual signal" builder, that can build signals from other signals. e.g. deriving the cumulative counts of an enable signal going high through the duration of a waveform -- i think there is an interesting tradeoff between creating an entirely new Signal object, or having an object that contains references to other Signal objects and lazily produces values as next is called.
Practically, I think there is a compelling case for both, will be what I focus on next

Just as someone who's interested in these python bindings, is there any way to get the timescale out of the hierarchy? I can't see any way to get a timescale, so we just have the timetable major time events without any reference for how often they are.

Thanks for the suggestion, I'll add that in shortly


Quarterly Earnings (yf.Ticker.quarterly_earnings) returns very different results from session to session.

I just upgraded to latest yfinance, but still noticing this issue:
When pulling quarterly earnings for ticker ASAN, I notice the values change from session to session. I've taken screenshots where I've managed to capture this difference in result. I've been able to replicate the error but it seems to be random.  I also noticed it with AAPL but that's as far as I got and haven't been able to QA any other tickers.

Notice that one is simply two periods back
I mentioned before (after thorough checks) that yahoo finance takes the
data randomly from various websites, per run
yfinance just mitigates it to the caller
So not a yfinance issue
בתאריך יום ה׳, 9 בדצמ׳ 2021 ב-19:55 מאת enigma @.***>:

I just upgraded to latest yfinance, but still noticing this issue:
When pulling quarterly earnings for ticker ASAN, I notice the values
change from session to session. I've taken screenshots where I've managed
to capture this difference in result. I've been able to replicate the error
but it seems to be random. I also noticed it with AAPL but that's as far as
I got and haven't been able to QA any other tickers.
[image: ASAN3]
https://user-images.githubusercontent.com/34148109/145449705-184df4b2-7401-4b92-8ead-ec0ab084ac57.PNG
[image: ASAN2]
https://user-images.githubusercontent.com/34148109/145449709-351a7bde-59f9-48ae-a061-50ed270cfbcd.PNG
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ranaroussi/yfinance/issues/904, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK7ZJS6IPEXMEZTXD5QXLHDUQDURVANCNFSM5JXC6GAA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Asaf - אסף

oh i see, that is interesting. ok good to know, thanks


Crash in the room with the piano in the Clock Tower

Version
3.0.1 (412b94e)
Seed
R730-RL6G-XXHHCACZ1UJ00NJMXH20KC060J70ZZZZZZZ
Scenario
RE 3 (Jill)
Player Character
Nikolai (RE3R)
What happened?
Hi, i found a crash
When entering the room with the piano in the clock tower the game immediately crash all the time, i hear a Brain Sucker in the room before it crash

Duplicate of #314


[feature][typechat] add support for task detection in chat interface

We would like to integrate TypeChat in the project. An example idea would be to use it to detect specific tasks in the human message, like for example the "send email" task that would allow to send AI results to a list of emails.
Ideally, the task detection implementation should be extensible so other additional tasks could be implemented in a similar way.
Tasks

[ ] add TypeChat integration to detect the "send email" task and allow to send AI replies to specified emails
[ ] add backend API to support sending emails

Contributing upstream to LangChain as dependency.


[BEAM-6740] Add comment explaining unused combine.globally translation

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

It might be pretty easy to follow the example at
beam/runners/core-construction-java/src/main/java/org/apache/beam/runners/core/construction/CombineTranslation.java
Line 56 in b83b302
public static class CombinePayloadTranslator
to create the translator.
Thanks Kenn for taking a look.
Sure it is just that I don't have time right now to create one and deal with the impacts and tests for all the runners. So I prefer to focus on making combine work on the new POC runner even if I temporary get back to translator resolution based on classes.

closing because the fix is ongoing


x-ms-client-name failing for some keyvault code

There are still problems in x-ms-client-name. Here are some of the issues I found in KeyVault (there are probably more issues)
https://github.com/Azure/autorest.python/issues/252
This is the swagger I'm using: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/keyvault/data-plane/Microsoft.KeyVault/stable/7.0/keyvault.json

Try --version:3.0.6181  and --use<EMAIL_ADDRESS>inlined enums with x-ms-client-name should be picking up the property correctly.
https://github.com/Azure/autorest.modelerfour/blob/master/modelerfour/test/scenarios/keyvault/namer.yaml#L1374


Consume price data from Coingecko to standardise Total Volume calc

The Chore
We need a feed / API call / webservice or something that consumes prices from Coingecko for any settlement assets we have in Vega.  I'm assuming something like this, but we can explore options.
Tasks

[ ] Get the list of settlement assets from /api/v2/assets where "status": "STATUS_ENABLED"
[ ] For each of these retrieve a price from the Coingecko API somehow (based on symbol or erc20 contractAddress)
[ ] Store this somewhere as we might use it a few places
[ ] Immediate task is to use this to enhance https://github.com/vegaprotocol/vega.xyz/issues/509
[ ] Currently that task filters for only USDT and USDC, but once the above is available we shoudl convert all asset balances into USD equivalent and sum them up to get the Total Volume
[ ] We may then use this elsewhere too

Additional details / background info
This change will not be needed until we have markets settling in non-USD equivalent assets.  We have a live proposal for WETH so if someone built markets on that it would suddenly be needed.

@fryd
has built some sort of feed from Coingecko for prices for his monitoring. Potentially we can steal this and then we'd be able to convert our total volume numbers All you need to do is call this API https://api.coingecko.com/api/v3/simple/price?ids=vega-protocol,tether,usd-coin,weth&vs_currencies=usd&include_last_updated_at=true

This will become redundant if Oli makes the changes on the existing ticket as I have just requested

The ticket @JonRay15 is referring too is https://github.com/vegaprotocol/vega.xyz/issues/509 which is in progress so closing this. Jon, please verify this is correct, thanks


Custom resolvers

I have added resolve entry in generated webpack config to allow referencing imports without '../..'. They can now be referenced relative to the workspace.
I have also added a resolve entry that allow referencing files created by genrules, again, using path relative to the workspace.

I have fixed the JS linting. The Bazel linting was fine, it seems to have failed when installing buildifier in CI.
About the deprecated notice, that function has been deprecated, but no replacement was offered. There's more details in this conversation https://github.com/bazelbuild/bazel/issues/5859
I think it's better to keep using that function until a replacement is implemented. What do you think?

@schoren thanks for pointing the ticket, using the deprecated function seems fine in that case.
I've fixed up CircleCI, please merge the latest master :)


Builtin Lambda Calculus Experiment

zulip thread discussing this PR
This is a test branch to experiment with a way of allowing users to define lambda terms in the e-graph.
Current (known) limitations:

Only works when functions input as an e-class not a primitive
Function with duplicate variable names will break. (Could have a fix for this with desugaring pass)
Can only use functions with one sort currently, i.e. if you want i64 -> i64, cannot also use i64 -> String in one program. I believe this is partially due to  https://github.com/egraphs-good/egglog/issues/113. This means we can't do higher order functions sadly!

Changes:

Add new Lambda builtin sort, with functions var,lambda, and apply.
Pass the EGraph into apply() method on sorts so that when applying a lambda function can muck about in the EGraph
Add a register_egraph method to sorts, so that the Lambda sort can register two regular functions var and lambda. I couldn't figure out a way to do this otherwise, registering non-primitive functions in a sort based on the types based in.
Adds a vec-map function for vectors map a function across them.

Examples:
(define double (lambda (var "x") (Mul (var "x") (Num 2))))
(define two (apply double (Num 1)))
(run 1)
(check (= two (Num 2)))

(sort MathVec (Vec Math))
(define vec (vec-of (Num 1) (Num 2) (Var "3")))
(define doubled-vec (vec-map vec double))
(run 1)
(check (= doubled-vec (vec-of (Num 2) (Num 4) (Mul (Var "3") (Num 2)))))

Closing this because it's rather outdated and https://github.com/egraphs-good/egglog/pull/348 was merged which is another way to approach this problem.


Avoid include binary metadata in echo app grpc response

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

@bianpengyuan: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
8d347b2da95a781194197e9d565a2f20ed449f73
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

In a stackdriver e2e test, opencensus tracer adds grpc-binary-bin header which cannot be encoded into a proto message due to non-utf8 data.

/retest

@bianpengyuan: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
8d347b2da95a781194197e9d565a2f20ed449f73
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

In response to a cherrypick label: new pull request created: #25051


fix(wallet): Upgrade beignet

Description

Upgrades beignet to 0.0.19.
Dev Mode Only: Allows devs to set p2tr/taproot addresses as the wallets default.
Adds p2tr/taproot support to AddressViewer without need for dev mode.
p2tr was added to the wallet structure as migration 34.
Adds addressTypesToMonitor to reduce bandwidth for unused address types.
Removed unused create-hmac dependency.
Beignet upgrade also contains bug fix for p2sh input calculations.

Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

Tests

[x] No test

QA Notes

With this change, only the selected address type (bech32 default) will be monitored for new wallets similar to before the Beignet migration. As address types are selected from the the Address Preference view, address types will get push to an array for continued monitoring during subsequent sessions. Restored wallets will add all address types for monitoring during the wallet creation/restore flow.
Taproot address support is currently soft-blocked behind dev mode for testing and available to view in the AddressViewer without needing to switch to dev mode.

After a first successful tx to a taproot address (regtest) I can't seem to send another one:
https://github.com/synonymdev/bitkit/assets/8538369/1776c316-d114-4817-a644-742155d33f39

Issue created here. This PR is mostly to get Bitkit up-to-date with Beignet for some bug fixes. Taproot was just a requirement that needed to be handled with the upgrade. We'll need another round of testing for taproot addresses prior to removing the soft-block in a future release. We could hard block it if you feel it necessary, but thought it might be good for us devs to slowly start testing.

After a first successful tx to a taproot address (regtest) I can't seem to send another one:

Should be resolved as of this commit.

Not sure this was caused by this PR so won't block but onchain feels pretty broken to me:

I couldn't switch (to my local) electrum server
Made a bunch of transactions from another simulator
receive notifications popped up randomly, sometimes on sender side after send
balance suddenly 0, restarted app, after that I had a wrong balance and duplicated receives, other tx 'removed from mempool'

https://github.com/synonymdev/bitkit/assets/8538369/5ac12153-df6b-46e3-b32f-0784b80b264f

Not sure this was caused by this PR so won't block but onchain feels pretty broken to me:

I couldn't switch (to my local) electrum server
Made a bunch of transactions from another simulator
receive notifications popped up randomly, sometimes on sender side after send
balance suddenly 0, restarted app, after that I had a wrong balance and duplicated receives, other tx 'removed from mempool'

EDIT: ok all of this seems to come from the electrum connection being quite bugged
Have an Electrum fix coming in a separate PR.


Added Pigmeat to projects list

Heyo! Just adding my static site generator, Pigmeat, to the project list. Check it out!

Hey @limeschool, thanks for the PR—can you provide any context behind your project’s name and the logo?

I named it after Pigmeat Markham, with the logo being a vectorized version of his depiction on the poster for Mr. Smith Goes Ghost, a comedy film from 1940 whose copyright expired on the promotional art (photographs of him are still copyrighted, you see, so I couldn't use those). I had just heard the song Here Comes The Judge at the time so I just went ahead and named it after him because I often overthink what to name things, haha.

Ah, I’m concerned a little bit about the history, specifically after reading this article linked up from the Wikipedia page: https://blog.wfmu.org/freeform/2010/11/the-forgotten-pigmeat-markham.html
Would there be strong resistance to a rename before we add it in here? I can help brainstorm some names if you’re open to it!

Look, if you want me to rename it, maybe I will, maybe I won't, it's not like I'm invested in the name or your list.
However, the fact that you're so concerned about this puzzles me. From my point of view, you just come off as some guy with a savior complex.  You plug me into a calculator and it makes a goddamn happy face. I've dealt with my fair share of discrimination, and let me tell you, this is some fantastic piece of slacktivism right here that would never be of true help to anyone.
You could find racially insensitive things in the past of any historical figure, so of course Pigmeat Markham is no exception. You're not concerned about Markham as an individual, he's an excuse for you. In the very blog post you linked, he was shown as having performed as he did because it was the norm, not because he was some self-hating black man. He was an influential black American artist who made great contributions to the arts and culture of this country, and if I'd picked an influential white artist you wouldn't have batted an eye.
 I'm reminded of (this article)[https://www.thetimesnews.com/opinion/20190104/editorial-blacks-biggest-enemy-is-white-liberal] by Professor Walter E. Williams. But, eh, maybe I'll change the name to something quirky so you can boost your social credit for having taken down the big bad software project. People like you, scared that I'll ruin their Starbucks-brand of 'wokeness' with my stories of real discrimination, have always presented some sort of arbitrary challenge in the name of 'tolerance.'
I'm not doing this pissing match you're so eager for.

Sounds like there is some resistance to a rename and that's fine. I think it's incredible work that you've done here and I'm personally sorry for our delay in responding here—the timing was no more than a recent sprint to close a bunch of active and old PRs in the repo. That said, I do wish you and the project all the best. If you want to discuss it further in private, feel free to email me<EMAIL_ADDRESS>


Creating error callbacks

[X] I agree to follow the project's code of conduct.
[X] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

I've attached two options for setting up the global GDAL error callback. One is thread-safe and comes with a new dependecy and the other one is not.
The reason for storing the callback in a static variable is that we cannot pass the ownership to GDAL. We can access a generic pointer via the pUserData field and cast it to our function type. Therefore, in order not to leak our FnMut, we have to store it somehow and drop it later on.
When we decide on which version to use, I can remove the other one and convert the draft to a PR.

Can you use once_cell instead? It might get folded into std at some point.

Can you use once_cell instead? It might get folded into std at some point.

Done that in da4c2ac

Okay, I've done two things:

0111fbd
I removed the non-thread-safe variant.
Moreover, I noticed that the previous version had a potential race condition when we would switch the callback in the mutex and then install the new callback. Thus, we have to first install the new callback to not have the old callback point to a dangling pointer. However, we have to first call it and then move the callback into the mutex without changing the reference that GDAL uses in p_user_data. This is why I wrapped the Box into a Pin<Box<_>>. If you have any improvement on that, I will try it.
6387a29
I moved the error type enum to error.rs

@ChristianBeilschmidt Thanks for the implementation.  Since concurrency is a bit hard to debug / reason about, I wanted to discuss a few points on the overall impl.

Callback Storage. Currently you're storing the callback both in the static variable, and in GDAL's ErrorHandlerUserData. We should have a single source of truth; I think just using the static variable is simpler.

Function Type.  I was a bit worried about the FnMut possibly being called in parallel in error_handler.  However, it seems GDAL uses a mutex to ensure the error handler is not called / assigned in parallel.  Could you add some comments or GDAL doc links  explaining this.  The function needs Sync in addition to Send + 'static as it is being accessed from different threads.

Poison Handling. I think the only panic while holding the mutex in your implementation is if CPLSetErrorHandler panics.  Thus, the function pointer is valid even if poisoned.  Pls. explain this in the code for future reference.

Locking.  The mutex code seems good to me.  I still think just a Box<ErrorCallbackType> suffices, as the locking mechanism ensures the pointer doesn't change while being accessed.
If you are feeling brave, there is a way to fully avoid using any locks at all.  The idea is to use an AtomicPtr as the static variable, initialized to null (Box pointers are never null).
Before setting the handler, use AtomicPtr::swap:
// Swap should be done before CPLSetHandler
let old_ptr = ERROR_CALLBACK.swap(Box::into_raw(callback), Ordering::SeqCst);
CPLSetHandler(...)
// Drop logic must happen after CPLSetHandler
if old_addr > 0 {
    // Convert back to Box to destruct properly
    unsafe { Box::from_raw(old_addr as *mut ErrorCallbackType) };
}

Removal is simple:
// Set None before swapping
CPLSetHandler(None);
// DO NOT swap out and drop the old addr

This is somewhat like the Treiber stack, but much simpler as we just store one value and piggy-back on GDAL's mutex.  See this neat rust exposition  that explains why we can't free stuff easily in lock-free algorithms.  In our case, we may leak at most one Box which seems reasonable.
Calling is simple.   If our fn error_handler is called, then we know a handler we set is currently active.  So we can use AtomicPtr::load to read the ptr, and call the function.  We could even assert the pointer is not null.  We can also be sure the pointed memory is not freed as the CPLSetHandler call won't finish before the error handler return.

@ChristianBeilschmidt Thanks for the implementation. Since concurrency is a bit hard to debug / reason about, I wanted to discuss a few points on the overall impl.
1. Callback Storage. Currently you're storing the callback both in the static variable, and in GDAL's `ErrorHandlerUserData`. We should have a single source of truth; I think just using the static variable is simpler.

I guess we can't. GDAL doesn't take the ownership of that pointer, it treats it as a reference. Thus, we would leak if we transfer the ownership to GDAL nevertheless and it gets discarded by a call to CPLSetErrorHandler (or whatever) that is not covered by our two functions.

2. Function Type.  I was a bit worried about the `FnMut` possibly being called in parallel in `error_handler`.  However, it seems GDAL [uses a mutex](https://github.com/OSGeo/gdal/blob/543d6ffd39b66a727da49cb398591959a8f644cf/gdal/port/cpl_error.cpp#L355) to ensure the error handler is not called / assigned in parallel.  Could you add some comments or GDAL doc links  explaining this.  The function needs `Sync` in addition to `Send + 'static` as it is being accessed from different threads.

I changed it here: bd4beaa

3. Poison Handling. I think the only panic while holding the mutex in your implementation is if `CPLSetErrorHandler` panics.  Thus, the function pointer is valid even if poisoned.  Pls. explain this in the code for future reference.

I've addressed it here: bd4beaa

4. Locking.  The mutex code seems good to me.  I still think just a `Box<ErrorCallbackType>` suffices, as the locking mechanism ensures the pointer doesn't change while being accessed.

if you only use one Box and you move it into the Mutex, the address changes. The inner Box makes the address stable.
And we need two stable addresses while swapping our new Box into the mutex while simultaneously ensuring that all error callbacks that happen in-between (from actual errors, not our function calls) have a valid pointer.

   If you are feeling brave, there is a way to fully avoid using any locks at all.  The idea is to use an `AtomicPtr` as the static variable, initialized to null (`Box` pointers are never null).
   Before setting the handler, use `AtomicPtr::swap`:
   ```rust
   // Swap should be done before CPLSetHandler
   let old_ptr = ERROR_CALLBACK.swap(Box::into_raw(callback), Ordering::SeqCst);
   CPLSetHandler(...)
   // Drop logic must happen after CPLSetHandler
   if old_addr > 0 {
       // Convert back to Box to destruct properly
       unsafe { Box::from_raw(old_addr as *mut ErrorCallbackType) };
   }
   ```

   Removal is similar, swap in `null_mut`
   ```rust
   let old_ptr = ERROR_CALLBACK.swap(null_mut(), Ordering::SeqCst);
   CPLSetHandler(None);
   // Drop old_ptr
   ```

   This is somewhat like the [Treiber stack](https://en.wikipedia.org/wiki/Treiber_stack), but much simpler as we just store one value and piggy-back on GDAL's mutex.  See also this neat [rust exposition](https://aturon.github.io/blog/2015/08/27/epoch/).  Unlike the treiber stack, we can in fact safely drop the memory as we piggy-back on GDAL's mutex mechanism.
   Calling is simple.   If our `fn error_handler` is called, then we know a handler we set is currently active.  So we can use `AtomicPtr::load` to read the ptr, and call the function.  If the pointer is not null, we can be sure the pointed memory is not freed as the `CPLSetHandler` call won't finish before the error handler return.  Only edge case is if the handler is called while we're removing the handler, in which case the ptr may be null.  We just need to exit without calling in this case.

Edit: fix lock-free logic to not require leaking the box ptr.

I could try it and see if we don't introduce new race conditions. However, the function is most likely not called in huge concurrency. So I don't see the benefit in locking, here.

can we merge it like it is or do we need more discussion / changes?

@ChristianBeilschmidt

Callback Storage. Currently you're storing the callback both in the static variable, and in GDAL's ErrorHandlerUserData. We should have a single source of truth; I think just using the static variable is simpler.

I guess we can't. GDAL doesn't take the ownership of that pointer, it treats it as a reference. Thus, we would leak if we transfer the ownership to GDAL nevertheless and it gets discarded by a call to CPLSetErrorHandler (or whatever) that is not covered by our two functions.

I'm suggesting not using user-data of GDAL at all, and only using our locked structure.  So the only pointer being passed to GDAL is the error_handler function which is a static function.   It's mostly for code clarity, so optional.

Locking.  The mutex code seems good to me.  I still think just a Box<ErrorCallbackType> suffices, as the locking mechanism ensures the pointer doesn't change while being accessed.

if you only use one Box and you move it into the Mutex, the address changes. The inner Box makes the address stable.
And we need two stable addresses while swapping our new Box into the mutex while simultaneously ensuring that all error callbacks that happen in-between (from actual errors, not our function calls) have a valid pointer.

If you move a Box into a Mutex, the data pointed to by the Box doesn't move.  For instance:
let mut boxed = Box::new(0usize);
let ptr: *mut _ = boxed.as_mut() as *mut _;

let mutex = Mutex::new(boxed);
assert_eq!(
    mutex.lock().unwrap().as_mut() as *mut _,
    ptr
);

If you are feeling brave, there is a way to fully avoid using any locks at all.  The idea is to use an AtomicPtr as the static variable, initialized to null (Box pointers are never null).
I could try it and see if we don't introduce new race conditions. However, the function is most likely not called in huge concurrency. So I don't see the benefit in not locking, here.

Ok.
@jdroenner A few minor suggestions, mostly for clarity and remove extra allocations.

@ChristianBeilschmidt

Callback Storage. Currently you're storing the callback both in the static variable, and in GDAL's ErrorHandlerUserData. We should have a single source of truth; I think just using the static variable is simpler.

I guess we can't. GDAL doesn't take the ownership of that pointer, it treats it as a reference. Thus, we would leak if we transfer the ownership to GDAL nevertheless and it gets discarded by a call to CPLSetErrorHandler (or whatever) that is not covered by our two functions.

I'm suggesting not using user-data of GDAL at all, and only using our locked structure. So the only pointer being passed to GDAL is the error_handler function which is a static function. It's mostly for code clarity, so optional.

I hesitate to switch to AtomicPtr since we then guarantee to not drop the Box<Fn> at the end of our program. But I haven't used it before. If you have an idea for that, I could try it.

Locking.  The mutex code seems good to me.  I still think just a Box<ErrorCallbackType> suffices, as the locking mechanism ensures the pointer doesn't change while being accessed.

if you only use one Box and you move it into the Mutex, the address changes. The inner Box makes the address stable.
And we need two stable addresses while swapping our new Box into the mutex while simultaneously ensuring that all error callbacks that happen in-between (from actual errors, not our function calls) have a valid pointer.

If you move a Box into a Mutex, the data pointed to by the Box doesn't move. For instance:
let mut boxed = Box::new(0usize);
let ptr: *mut _ = boxed.as_mut() as *mut _;

let mutex = Mutex::new(boxed);
assert_eq!(
    mutex.lock().unwrap().as_mut() as *mut _,
    ptr
);

If you are feeling brave, there is a way to fully avoid using any locks at all.  The idea is to use an AtomicPtr as the static variable, initialized to null (Box pointers are never null).
I could try it and see if we don't introduce new race conditions. However, the function is most likely not called in huge concurrency. So I don't see the benefit in not locking, here.

Ok.

In your example, you have a pointer to a usize. However, we have to store a pointer to a Box<dyn Trait>, since we can't have a pointer to a dyn Trait. Thus, we have to wrap this into another Box<_> for which then your examined behavior holds.

I hesitate to switch to AtomicPtr since we then guarantee to not drop the Box<Fn> at the end of our program. But I haven't used it before. If you have an idea for that, I could try it.

Rust actually never drops any static variable, so even now things won't get dropped when the program exits unless remove_handler is called explicitly.  The lock-free stuff is probably unnecessary complexity, so let's stick with the current impl.

In your example, you have a pointer to a usize. However, we have to store a pointer to a Box<dyn Trait>, since we can't have a pointer to a dyn Trait. Thus, we have to wrap this into another Box<_> for which then your examined behavior holds.

See this playground for example of boxing a FnMut into a Mutex and calling it via a raw ptr.  Basically the same use-case as here.
Also, pls. add a line in CHANGES.md about this feature.

I hesitate to switch to AtomicPtr since we then guarantee to not drop the Box<Fn> at the end of our program. But I haven't used it before. If you have an idea for that, I could try it.

Rust actually never drops any static variable, so even now things won't get dropped when the program exits unless remove_handler is called explicitly. The lock-free stuff is probably unnecessary complexity, so let's stick with the current impl.

In your example, you have a pointer to a usize. However, we have to store a pointer to a Box<dyn Trait>, since we can't have a pointer to a dyn Trait. Thus, we have to wrap this into another Box<_> for which then your examined behavior holds.

See this playground for example of boxing a FnMut into a Mutex and calling it via a raw ptr. Basically the same use-case as here.

The playground, unfortunately, disregards one aspect as far as I see:
Currently, we store a pointer to a Box<Fn>. This is a 64-bit pointer type.
However, a pointer to dyn Fn is a 128-bit pointer type. Rust uses a fat pointer to store the length information that it can derive for sized structs.
Thus, I can cast the *mut c_void from pUserData, which is 64-bit, to *mut Box<Fn> but I cannot cast it to *mut dyn Fn.
This is why we need the doubled box.

Also, pls. add a line in CHANGES.md about this feature.

a4df453

The playground, unfortunately, disregards one aspect as far as I see:
Currently, we store a pointer to a Box<Fn>. This is a 64-bit pointer type.
However, a pointer to dyn Fn is a 128-bit pointer type. Rust uses a fat pointer to store the length information that it can derive for sized structs.
Thus, I can cast the *mut c_void from pUserData, which is 64-bit, to *mut Box<Fn> but I cannot cast it to *mut dyn Fn.
This is why we need the doubled box.

Hmm, that's interesting.  Could you add the explanations in the code for future reference?  I suppose we can avoid the extra allocation if we don't use user-data at all, and just use the lock within the error handler.

I'll go ahead and approve the pr as I don't see any major issues.  Thanks @ChristianBeilschmidt

The playground, unfortunately, disregards one aspect as far as I see:
Currently, we store a pointer to a Box<Fn>. This is a 64-bit pointer type.
However, a pointer to dyn Fn is a 128-bit pointer type. Rust uses a fat pointer to store the length information that it can derive for sized structs.
Thus, I can cast the *mut c_void from pUserData, which is 64-bit, to *mut Box<Fn> but I cannot cast it to *mut dyn Fn.
This is why we need the doubled box.

Hmm, that's interesting. Could you add the explanations in the code for future reference? I suppose we can avoid the extra allocation if we don't use user-data at all, and just use the lock within the error handler.

44db095


Kubeless function overwrite containers resource in deployment template

Is this a BUG REPORT or FEATURE REQUEST?:
BUG REPORT
What happened:
kubeless overwrite the deployment template (containers part) in kubeless config map
What you expected to happen:
My initial idea was to make functions share same volume. If deployment template propagate to function pod, it would be possible.
How to reproduce it (as minimally and precisely as possible):
Deployment json in kubeless config map:
deployment: |-
     {
        "spec": {
          "template": {
            "spec": {
              "containers": [{
                "resources": {
                  "requests": {
                    "nvidia.com/gpu": "1"
                  },
                  "limits": {
                    "nvidia.com/gpu": "1"
                  }
                },
                "volumeMounts": [{
                  "mountPath": "/racelab",
                  "name": "fs-store"
                }]
              }],
              "nodeSelector": {
                "gpu-type": "1080Ti"
              },
              "volumes": [{
                "name": "fs-store",
                "flexVolume": {
                  "driver": "ceph.rook.io/rook",
                  "fsType": "ceph",
                  "options": {
                    "clusterNamespace": "rook",
                    "fsName": "nautilusfs",
                    "path": "/racelab",
                    "mountUser": "racelab",
                    "mountSecret": "ceph-fs-secret"
                  }
                }
              }]
            }
          }
        }
      }

Volumes:
  fs-store:
    Type:       FlexVolume (a generic volume resource that is provisioned/attached using an exec based plugin)
    Driver:     ceph.rook.io/rook
    FSType:     ceph
    SecretRef:  nil
    ReadOnly:   false
    Options:    map[clusterNamespace:rook fsName:nautilusfs mountSecret:ceph-fs-secret mountUser:racelab path:/racelab]

Mounts:
      /kubeless from mnist-tf (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-f8rzs (ro)

In the pod, volume is found, but not mounted.
Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version): Major:"1", Minor:"13"
Kubeless version (use kubeless version): v1.0.2
Cloud provider or physical cluster: Nautilus

Hi @Heronalps,
You need to mount the volume in the runtime container, right? (The one that runs the function, not the one that install dependencies). In theory, the controller should be maintaining whatever exists in the deployment template:
https://github.com/kubeless/kubeless/blob/master/pkg/utils/kubelessutil.go#L609
Can you paste here the full deployment spec of the deployment generated for your function? (kubectl get deployment -o yaml <your-func>)

Hi @andresmgot ,
I'm having the same issue, volume is added to the pod but not mounted in the runtime container.
Deployment in kubeless-config configmap
deployment: |-
    {   "spec": {
        "template": {
            "spec": {
                "containers": [
                    {
                        "volumeMounts": [
                            {
                                "mountPath": "/mnt/data",
                                "name": "kubeless-storage"
                            }
                        ]
                    }
                ],
                "volumes": [
                    {
                        "name": "kubeless-storage",
                        "persistentVolumeClaim": {
                            "claimName": "kubeless-storage"
                        }
                    }
                ]
            }
        }
      }
    }

here is my function deployment
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2019-10-29T14:05:55Z"
  generation: 1
  labels:
    created-by: kubeless
    function: anaik-test
  name: anaik-test
  namespace: ops-serverless
  ownerReferences:
  - apiVersion: kubeless.io/v1beta1
    kind: Function
    name: anaik-test
    uid: 39585c81-fa55-11e9-8b5a-12d299f34b42
  resourceVersion: "28111117"
  selfLink: /apis/extensions/v1beta1/namespaces/ops-serverless/deployments/anaik-test
  uid: 395f65a5-fa55-11e9-8b5a-12d299f34b42
spec:
  progressDeadlineSeconds:<PHONE_NUMBER>
  replicas: 1
  revisionHistoryLimit:<PHONE_NUMBER>
  selector:
    matchLabels:
      created-by: kubeless
      function: anaik-test
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      annotations:
        prometheus.io/path: /metrics
        prometheus.io/port: "8080"
        prometheus.io/scrape: "true"
      creationTimestamp: null
      labels:
        created-by: kubeless
        function: anaik-test
    spec:
      containers:
      - env:
        - name: FUNC_HANDLER
          value: handle
        - name: MOD_NAME
          value: worker
        - name: FUNC_TIMEOUT
          value: "180"
        - name: FUNC_RUNTIME
          value: python3.7
        - name: FUNC_MEMORY_LIMIT
          value: "0"
        - name: FUNC_PORT
          value: "8080"
        - name: KUBELESS_INSTALL_VOLUME
          value: /kubeless
        - name: PYTHONPATH
          value: $(KUBELESS_INSTALL_VOLUME)/lib/python3.7/site-packages:$(KUBELESS_INSTALL_VOLUME)
        image: kubeless/python@sha256:dbf616cb06a262482c00f5b53e1de17571924032e0ad000865ec6b5357ff35bf
        imagePullPolicy: Always
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 3
          periodSeconds: 30
          successThreshold: 1
          timeoutSeconds: 1
        name: anaik-test
        ports:
        - containerPort: 8080
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /kubeless
          name: anaik-test
      dnsPolicy: ClusterFirst
      initContainers:
      - args:
        - echo '7bde05ae320a405796d12654d8b6651f62c791b1d34e6d098015831a15ed0644  /src/worker.py'
          > /tmp/func.sha256 && sha256sum -c /tmp/func.sha256 && cp /src/worker.py
          /kubeless/worker.py && cp /src/requirements.txt /kubeless
        command:
        - sh
        - -c
        image: kubeless/unzip@sha256:f162c062973cca05459834de6ed14c039d45df8cdb76097f50b028a1621b3697
        imagePullPolicy: IfNotPresent
        name: prepare
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /kubeless
          name: anaik-test
        - mountPath: /src
          name: anaik-test-deps
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext:
        fsGroup: 1000
        runAsUser: 1000
      terminationGracePeriodSeconds: 30
      volumes:
      - name: kubeless-storage
        persistentVolumeClaim:
          claimName: kubeless-storage
      - emptyDir: {}
        name: anaik-test
      - configMap:
          defaultMode: 420
          name: anaik-test
        name: anaik-test-deps
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2019-10-29T14:05:59Z"
    lastUpdateTime: "2019-10-29T14:05:59Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

mm, that's indeed weird. Seems like a bug. Apparently the volumeMounts from the deploymentSpec is empty instead of containing the one in the function:
https://github.com/kubeless/kubeless/blob/master/pkg/utils/kubelessutil.go#L618
I am not sure why at that point that list is empty.

I think the configmap deployment container specs are not getting merged here
https://github.com/kubeless/kubeless/blob/master/pkg/controller/function_controller.go#L310
https://github.com/kubeless/kubeless/blob/master/pkg/utils/k8sutil.go#L376
I'm not familiar with go but if you can suggest how to fix the issue I can try

Could be, we would need to investigate at which point the container loses the volumeMount (or if it has it at any point).
If you can help with that, what I would do is to just print the content of funcObj.Spec.Deployment.Template.Spec.Containers in different points until we figure out where it's missing.
If you modify some code, you can rebuild the image executing make function-controller in the root directory of this project but you need a working Golang environment. Then you can replace the image in your cluster with the one you have just built.

I console logged destination & source objects before and after MergeDeployments. The volumes get merged but the VolumeMounts in the containers don't
Before utils.MergeDeployments::
funcObj.Spec.Deployment.Spec.Template.Spec.Containers[0].VolumeMounts:
[]
deployment.Spec.Template.Spec.Containers[0].VolumeMounts:
[{Name:kubeless-storage ReadOnly:false MountPath:/mnt/data SubPath: MountPropagation:<nil>}]

funcObj.Spec.Deployment.Spec.Template.Spec.Volumes:
[]
deployment.Spec.Template.Spec.Volumes:
[{Name:kubeless-storage VolumeSource:{HostPath:nil EmptyDir:&EmptyDirVolumeSource{Medium:,SizeLimit:<nil>,} GCEPersistentDisk:nil AWSElasticBlockStore:nil GitRepo:nil Secret:nil NFS:nil ISCSI:nil Glusterfs:nil PersistentVolumeClaim:nil RBD:nil FlexVolume:nil Cinder:nil CephFS:nil Flocker:nil DownwardAPI:nil FC:nil AzureFile:nil ConfigMap:nil VsphereVolume:nil Quobyte:nil AzureDisk:nil PhotonPersistentDisk:nil Projected:nil PortworxVolume:nil ScaleIO:nil StorageOS:nil}}]

After utils.MergeDeployments::
funcObj.Spec.Deployment.Spec.Template.Spec.Containers[0].VolumeMounts:
[]
deployment.Spec.Template.Spec.Containers[0].VolumeMounts:
[{Name:kubeless-storage ReadOnly:false MountPath:/mnt/data SubPath: MountPropagation:<nil>}]

funcObj.Spec.Deployment.Spec.Template.Spec.Volumes:
[{Name:kubeless-storage VolumeSource:{HostPath:nil EmptyDir:&EmptyDirVolumeSource{Medium:,SizeLimit:<nil>,} GCEPersistentDisk:nil AWSElasticBlockStore:nil GitRepo:nil Secret:nil NFS:nil ISCSI:nil Glusterfs:nil PersistentVolumeClaim:nil RBD:nil FlexVolume:nil Cinder:nil CephFS:nil Flocker:nil DownwardAPI:nil FC:nil AzureFile:nil ConfigMap:nil VsphereVolume:nil Quobyte:nil AzureDisk:nil PhotonPersistentDisk:nil Projected:nil PortworxVolume:nil ScaleIO:nil StorageOS:nil}}]
deployment.Spec.Template.Spec.Volumes:
[{Name:kubeless-storage VolumeSource:{HostPath:nil EmptyDir:&EmptyDirVolumeSource{Medium:,SizeLimit:<nil>,} GCEPersistentDisk:nil AWSElasticBlockStore:nil GitRepo:nil Secret:nil NFS:nil ISCSI:nil Glusterfs:nil PersistentVolumeClaim:nil RBD:nil FlexVolume:nil Cinder:nil CephFS:nil Flocker:nil DownwardAPI:nil FC:nil AzureFile:nil ConfigMap:nil VsphereVolume:nil Quobyte:nil AzureDisk:nil PhotonPersistentDisk:nil Projected:nil PortworxVolume:nil ScaleIO:nil StorageOS:nil}}]

good catch! I have no clue why that's behaving that way but at least we can workaround it. Can you add a small piece of code that appends deployment.Spec.Template.Spec.Containers[0].VolumeMounts to funcObj.Spec.Deployment.Spec.Template.Spec.Containers[0].VolumeMounts? Something like:
https://github.com/kubeless/kubeless/blob/master/pkg/controller/function_controller.go#L333
Then you can check if that solves your issue (and send a PR to fix it :) )

Will check if that works, is there a test case that needs to be updated?

here is the pr
https://github.com/kubeless/kubeless/pull/1093


Fix SSP deploy fail due to timeouts on db-server

SSP deploy should be fixed:

I modified timeouts on proxy server (not included in this pull request)
I modified timeouts within al-nginx service (this pull request)

There still might be a case when SSP deploy fails in ETL linked pipes, which I will fix when it happens ... Currently, I tested the SSP deploy and it did not fail 14 times in a row.


Add WASM results to the technical report

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: nkcr:x: gnarulaYou have signed the CLA already but the status is still pending? Let us recheck it.


Build Contributors Wall of Fame

Contributors wall of fame...you mean list of contributors? I would like to work on this.

Contributors wall of fame...you mean list of contributors? I would like to work on this.

Assigned to @sb2356-iiitr

Assigned to @sb2356-iiitr

It should be integrated into the readme file, right? @anushka23g

It should be integrated into the readme file, right? @anushka23g

yes

yes

OK

OK

Ok I am in a bit of fix...do I need to just add a section for contributors in the Readme file, or do I also need to implement something like a bot (eg. all-contributors) @anushka23g

Ok I am in a bit of fix...do I need to just add a section for contributors in the Readme file, or do I also need to implement something like a bot (eg. all-contributors) @anushka23g

Bot would be a better idea

Bot would be a better idea

Ok

Ok

I am creating the section in the README.md file, but it seems that the all-contributors bot can be added only by someone who has maintain access to the repo...

I am creating the section in the README.md file, but it seems that the all-contributors bot can be added only by someone who has maintain access to the repo...

I have made a PR for the required README.md edits #34 . Please check.

I have made a PR for the required README.md edits #34 . Please check.

I want to contribute

I want to contribute

Can I work on this issue?


Access overlayed changes from host function

We're building a benchmarking framework bencher for benching small methods/amount_of_code so we can use weight_meter to measure actual weight.
We need to know during execution how many reads/writes is happening without having to commit changes. Current frame_benchmarking doesn't help because it counts writes on commit but we need to know during execution how many potential writes might happen.
The easiest solution I found is to add a new method into externalities like read_write_count and then implement it to return overlayed_changes_count. I know there's no guarantee all the changes will be written on commit but in our case that's what we need. We might over count writes but will be better than nothing.
I also found StateMachineStats but not sure if I can get use of it.
Do you guys think it will be easy to just introduce a new method to externalities or we need to think a better approach?

I solved this by creating a Externalities wrapper and added storage tracker https://github.com/open-web3-stack/open-runtime-module-library/blob/master/bencher/src/bench_ext.rs


feat(Data/Nat/Choose): add basic lemmas

Adds basic lemmas for writing Nat.choose as a sum of two previous Nat.choose.

bors r+


Add bioformats support

Add instructions for installing bioformats -- run it on another lab members computer; there seem to be common issues.
Integrate bioformats into nd2ToTIFF
Introduce new format into the rest of the codebase.

Done! This is a fallback option, but it does work.


Use %AZP25 instead of %25 for escaping

Using %25 has introduced a lot of false positives where people don't expect their value to be decoded, specifically because %25 is used in a lot of Urls that people might set as variables.
Using %VS_TS should help us avoid this problem since it is a very uncommon string for people to intentionally use. It is less efficient and breaks from the standard URL encoding scheme, but that is probably outweighed by avoiding breaking customers.
This will require task-lib changes to use %VS_TS instead of %25 once it is fully rolled out.
I chose %VS_TS because I thought that would be obvious that it was something we were doing from the Azure DevOps side, but I was worried %VSTS might actually collide with something

This is only failing the dotnet install script tests - https://dev.azure.com/mseng/PipelineTools/_build/results?buildId=14291067&view=ms.vss-test-web.build-test-results-tab - so the broken CI can be mostly ignored (though I'll still wait for a fix there before merging)

What does %VS_TS stand for out of interest?

Oh I see it's just the previous name of Azure DevOps isn't it 😂😅

Yeah, VSTS is used to prefix some of our other variables as well, its a legacy holdover from before we were renamed 😃

I think the issue is that other characters that get decoded/endcoded (e.g. ']' to '%5D') trigger the warning since the coded value has a '%' character in it.

I think the issue is that other characters that get decoded/endcoded (e.g. ']' to '%5D') trigger the warning since the coded value has a '%' character in it.

I don't think this is right. We only warn when we detect a %VS_TS (or previously a %25) - https://github.com/microsoft/azure-pipelines-agent/blob/c5de11bd207770ac188b147559d02bcbe27f3132/src/Agent.Worker/WorkerCommandManager.cs#L135

specifically because %25 is used in a lot of Urls that people might set as variables.

As a data point, I can assert that I have received the warning in circumstances where I was not using any percent at all, so I'm not entirely convinced by the analysis here.
Breaking the standard should not be needed as the standard is resistant to multiple encode/decode (as long as they are the same number), but if you really need to, I'd go for a more explicit name, say %VSTS_PERCENT.

Hey @garyverhaegen-da

As a data point, I can assert that I have received the warning in circumstances where I was not using any percent at all, so I'm not entirely convinced by the analysis here.

One unfortunate consequence of using %25 is that many tasks end up either setting variables or just using debug statements that print using %25. So while your script isn't using %25, the task itself is probably emitting a %25. You can verify this by performing a run in diagnostic mode (which shows the ##vso commands that are normally hidden)

Breaking the standard should not be needed as the standard is resistant to multiple encode/decode (as long as they are the same number)

Unfortunately, the standard doesn't allow certain strings to be encoded without a way to encode/decode %. A good example of this is trying to encode the string %3B. Since ] is a reserved character, we encode/decode it with %3B - so any time our agent sees %3B it decodes it to ] when it gives it back to the user. Unfortunately, that means there's not a way to represent the string %3B itself without it getting decoded, since there's currently no escaping for %, 3, or B. With this change, you could represent it as %VS_TS3B.

but if you really need to, I'd go for a more explicit name, say %VSTS_PERCENT.

I think this is a fair suggestion. My guiding principles here were a desire to (1) keep the encoding short (so we don't overly expand strings that we're encoding since % is a fairly common character) and (2) Make it fairly unique to minimize collisions. Making it identifiable shouldn't really matter much since if all goes right it won't be visible to an end user, but it was a nice perk of %VS_TS, and IMO that string hits on both of my other goals.

but if you really need to, I'd go for a more explicit name, say %VSTS_PERCENT

After talking with a teammate, we settled on %AZP25 so it has a relationship to the regular encoding and azure pipelines, while maintaining the uniqueness and conciseness.

When can we expect this to be released to Azure DevOps pipelines?

When can we expect this to be released to Azure DevOps pipelines?

I would like to know as well. March is getting closer and I would like to see if with this fix, the errors dissapear for us.

When can we expect this to be released to Azure DevOps pipelines?

Looks like this has been released somewhere around 10-11 feb.

We have had a similar issue with the version 2.204.0 of the agent we need to set in the PipAuthenticate@1 component the job parameter DECODE_PERCENTS to true otherwise the % from '%20' space characters in the project path gets converted to %AZP25 and it doesn't get interpreted correctly as a valid http link leading us to pip not being able to find the right library => failing build. Seems that we MUST set the variable to TRUE otherwise this is FALSE by default. And the default values and behaviour described here are misleading in this case.


Hard crash (process exit), something causes importing client entry during SSR

This is a spin-off of https://github.com/frandiox/vite-ssr/issues/43 where I incorrectly identified the problem at first.
Problem
In a small reproducible case, something causes importing client entry during SSR, which leads to hard crash (process exit). I had this on a larger project, but then simplified the setup to bare minimum for the reproduction.
Reproduction
https://github.com/IlyaSemenov/vite-ssr-crash
~/tmp/4
❯ git clone https://github.com/IlyaSemenov/vite-ssr-crash.git
Cloning into 'vite-ssr-crash'...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 26 (delta 5), reused 25 (delta 4), pack-reused 0
Receiving objects: 100% (26/26), 13.52 KiB | 157.00 KiB/s, done.
Resolving deltas: 100% (5/5), done.

~/tmp/4
❯ cd vite-ssr-crash

~/tmp/4/vite-ssr-crash master
❯ nodenv local 16.0.0

~/tmp/4/vite-ssr-crash master
❯ yarn
yarn install v1.22.10
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning "vite-ssr ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^2.0.0".
warning "vite-ssr ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^17.0.0".
warning "vite-ssr > @rollup/plugin-replace ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning Workspaces can only be enabled in private projects.
[4/4] 🔨  Building fresh packages...
✨  Done in 1.69s.

~/tmp/4/vite-ssr-crash master
❯ yarn dev
yarn run v1.22.10
$ vite-ssr
Pre-bundling dependencies:
  vite-ssr
  vue
  vite-ssr/vue/entry-client
  vite-ssr/vue/entry-server
(this will be run only when your dependencies or config have changed)

  vite v2.3.8 dev server running at:

  > Local: http://localhost:3000/
  > Network: use `--host` to expose

 -- SSR mode

>>>>>>>>>>>>>> (in a separate console) curl localhost:3000

[Function (anonymous)]
TypeError: render is not a function
    at handleSsrRequest (/Users/semenov/tmp/4/vite-ssr-crash/node_modules/vite-ssr/dev/server.js:88:37)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
12:57:31 AM [vite] Internal server error: render is not a function
      at handleSsrRequest (/Users/semenov/tmp/4/vite-ssr-crash/node_modules/vite-ssr/dev/server.js:88:37)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
/node_modules/vite-ssr/vue/entry-client.js:20
    const url = window.location;
                ^

ReferenceError: window is not defined
    at Module.viteSSR [as default] (/node_modules/vite-ssr/vue/entry-client.js:20:17)
    at eval (/Users/semenov/tmp/4/vite-ssr-crash/src/main.ts:12:61)
    at instantiateModule (/Users/semenov/tmp/4/vite-ssr-crash/node_modules/vite/dist/node/chunks/dep-0ed4fbc0.js:69982:166)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

The two key points are:

non-empty alias section in vite config
importing (not even using - just importing and accessing) onServerPrefetch

UPDATE:
I came up with even simpler version without onServerPrefetch, which crashes the same way.
https://github.com/IlyaSemenov/vite-ssr-crash/tree/no_routes
git clone https://github.com/IlyaSemenov/vite-ssr-crash.git -b no_routes

Thanks for the repro, I'll try to check it soon 👍

So it was grabbing the first alias that contained vite-ssr for some internal logic, and it was finding your custom alias instead of the correct one. Should be fixed in 0.10.6 👍


Question about how to calculate m in margin ReLU

Hi,
Thanks for your cool work. It obtains the best performace on Res50 for all feature-distillation works.
I have a question about how to calculate m in margin ReLU.
Actually, I noticed that you implement it as margin.append(- s * math.exp(- (m / s) ** 2 / 2) / math.sqrt(2 * math.pi) / norm.cdf(-m / s) + m) at here. Can you give me some ideas about what does it mean?

Hi
I assume that the features after BN is Gaussian distribution, and calculates the expectation of negative values on Gaussian distribution.
You can find more details on Appendix A of my paper (https://arxiv.org/pdf/1904.01866.pdf)
I hope it helps you understand the formula.

Hi
I assume that the features after BN is Gaussian distribution, and calculates the expectation of negative values on Gaussian distribution.
You can find more details on Appendix A of my paper (https://arxiv.org/pdf/1904.01866.pdf)
I hope it helps you understand the formula.

Thanks!

Thanks!


Fixes leak with CopyToFbShaderRD

Fixes leak introduced in d81911490b447541b21305c16d27b078c184f9fe
ERROR: 1 shaders of type CopyToFbShaderRD were never freed
   at: ~ShaderRD (servers/rendering/rasterizer_rd/shader_rd.cpp:489)

Thanks!


Update euclid

@bors-servo r+

:pushpin: Commit 1d58cd9 has been approved by frewsxcv

:hourglass: Testing commit 1d58cd9 with merge b5f6fc2...

:hourglass: Testing commit 1d58cd9 with merge d1885f1...

:sunny: Test successful - travis


[Enhancement] Edit docker-compose file for existing services

The ability to clone services is great, as these can be edited in-browser, saved and run. However for existing services there is no way (that I can see) to modify the compose file and re-'up' the service to apply changes made to containers within the service.
Can the functionality of editing a cloned service be extended to allow for editing of existing services?

Technically this should be possible, since clone already includes the existing env & docker-compose (from what I remember). I'd just have to add the endpoint to "update" an existing project (assuming that functionality doesn't exist).

When you say existing services you're referring to externally managed docker-compose projects, right?
If so, I think it would be pretty difficult to clone a running project since there is no way to create a docker-compose.yml file from a bunch of running containers.

Sorry I think I may have confused the issue by mentioning clone.
Essentially what I am trying to do is simply edit the compose file for an existing service within the UI.

Sorry for the misunderstanding, I've implemented this feature and it is now available using francescou/docker-compose-ui:latest
I am now testing it and it should be included in the next release in the upcoming days.

I've tested this on the latest release and looks good! There's a small cosmetic issue that the message displayed in the bottom right displays 'created project' rather than 'updated project', but functionality wise I can't see any issues. Thanks for implementing this so quickly!

the feature has been released in francescou/docker-compose-ui:1.13.0 (I've corrected the message as well)

I'm closing this issue, feel free to reopen if necessary.


TypeError: Cannot read property 'visitClass' of undefined

I had this issue while I tried to run "npm run build":

<EMAIL_ADDRESS>build /Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master
./scripts/build

TypeError: Cannot read property 'visitClass' of undefined
at monkeypatch (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/babel-eslint/index.js:199:40)
at Object.exports.parse (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/babel-eslint/index.js:410:5)
at parse (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint/lib/eslint.js:453:27)
at EventEmitter.module.exports.api.verify (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint/lib/eslint.js:607:15)
at processText (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint/lib/cli-engine.js:201:27)
at CLIEngine.executeOnText (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint/lib/cli-engine.js:361:26)
at lint (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint-loader/index.js:26:20)
at Object.module.exports (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint-loader/index.js:120:7)
at WEBPACK_CORE_LOADER_EXECUTION (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
at runSyncOrAsync (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
at nextLoader (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
at /Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
at Storage.finished (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:38:16)
at /Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/graceful-fs/graceful-fs.js:78:16
at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:380:3)
TypeError: Cannot read property 'visitClass' of undefined
at monkeypatch (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/babel-eslint/index.js:199:40)
at Object.exports.parse (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/babel-eslint/index.js:410:5)
at parse (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint/lib/eslint.js:453:27)
at EventEmitter.module.exports.api.verify (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint/lib/eslint.js:607:15)
at processText (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint/lib/cli-engine.js:201:27)
at CLIEngine.executeOnText (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint/lib/cli-engine.js:361:26)
at lint (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint-loader/index.js:26:20)
at Object.module.exports (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/eslint-loader/index.js:120:7)
at WEBPACK_CORE_LOADER_EXECUTION (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
at runSyncOrAsync (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
at nextLoader (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
at /Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
at Storage.finished (/Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:38:16)
at /Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/node_modules/graceful-fs/graceful-fs.js:78:16
at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:380:3)
npm ERR! Darwin 15.2.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "build"
npm ERR! node v4.2.6
npm ERR! npm  v3.5.3
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>build: ./scripts/build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>build script './scripts/build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the webpack-react-starter package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     ./scripts/build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs webpack-react-starter
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls webpack-react-starter
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/arthu.rsilva/GitHub/ReactJS/webpack-react-starter-master/npm-debug.log
To solve it and make it work I had to delete the .eslintrc file and comment the preloaders inside the modules in webpack.config.js file.

Hi @ArxdSilva. Tranquilo? Então brother eu não estou usando mais este repo pela velocidade que as coisas tem se atualizado. Não consegui mais manter o peace. Estou usando https://github.com/gaearon/react-transform-boilerplate quando preciso de um boilerplate.

https://github.com/babel/babel-eslint/issues/243 -- this resolved the issue for me. Basically removing escope, and then 'downgrade' to an earlier version: npm install --save-dev<EMAIL_ADDRESS>

Thanks @aspic!


Label/InfoBox with non-static access

Hi! First I want to thank you for the awesome work, it's really useful as I prefer not to waste time with custom editors. Everything is working fine and as expected.
Would it be imaginable to add a "Label" attribute that could display non-static informations about the object? A quick example :
[Label]
private string MyLabelText
{
    get { return transform.childCount + " childs."; }
}

I was thinking something with the same design than InfoBox.
Thank you !

I think I can make it. The problem with Properties is that I am limited to displaying only value types and string, because they aren't serialized, and the Unity Editor is pretty limited for non-serialized data.

So it's not possible ?
I'm willing to try to do it, but I'm not certain how you deal with calling methods with strings. Are you using reflection ?
What I imagine should be doable with a logic similar to the OnValueChanged attribute (specifying a method/propriety to evaluate when showing in the inspector, but instead of returning a bool, the method returns a string that is in turn displayed in the inspector)
Thanks again

It is possible mate. I am actually doing it right now. I closed the issue in advance :D
I was a little busy these days, and didn't have the time to do it

Oh, sweet! Thanks a lot 👍

Finished. I called it [ShowNativeProperty]
However, it's pretty limited. It can display only value types and string properties, because the EditorGUILayout class is very limited for non-serialized properties.


[1.3] Disabling Encounter Rate Disables Sirens

Setting the encounter rate to 0 in the options prevents you from using Sirens

I'll be taking a look at this.  I saw this with another streamer.  I may have to set the encounter rate to something like 1/9999 or something ridiculous like that.

This has been taken care of in version 2.0 with a 1/10000 encounter rate replacing the 0 rate.  This will enable the sirens for use.  It will be very unlikely to get a random encounter unless you try to find one deliberately.


Ethan: Blacklist baidudownloader.com

Ethan requests the blacklist of the website baidudownloader\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

baidudownloader\.com has been seen in 6 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


toReactComponent for Hooks is reactComponent?

https://github.com/lumihq/purescript-react-basic/blob/d8087ade742a7070e35bbd999f45e373551c716d/src/React/Basic.purs#L70-L71
I have a question about toReactComponent.
I see it has moved to React.Basic.Classic, but it's still referenced here in React.Basic (and this documentation is re-exported in React.Basic.Hooks).
https://github.com/lumihq/purescript-react-basic-classic/blob/e0c21d61a92f36ff1f12fe972fb88d65e48cd927/src/React/Basic/Classic.purs#L280
It seems like for React FFI with Hooks toReactComponent has been replaced by reactComponent (and family) instead, right?
https://github.com/spicydonuts/purescript-react-basic-hooks/blob/5e43ca349a960c238e88219d0121603ae0c9889b/src/React/Basic/Hooks.purs#L88
So in reactComponent, what is the equivalent of the foreign-props-to-Purescript-props function ({ | jsProps } -> props) which was an argument to toReactComponent?

It has to do with requiring props to be an object. JS React requires this, but React.Basic.Classic.Component/ComponentSpec/make and React.Basic.Hooks.component do not. With React.Basic.Hooks.reactComponent/reactComponentWithChildren you're already interacting directly with JS React components and the object requirement is already there.


python310Packages.connexion: 2.14.0 -> 2.14.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.connexion is: "Swagger/OpenAPI First framework on top of Flask"
meta.homepage for python310Packages.connexion is: "https://github.com/spec-first/connexion"
meta.changelog for python310Packages.connexion is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 2.14.1 with grep in /nix/store/30jml4pv2mwi5fibbs695c26nj71psag-python3.10-connexion-2.14.1
found 2.14.1 in filename of file in /nix/store/30jml4pv2mwi5fibbs695c26nj71psag-python3.10-connexion-2.14.1

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.connexion
python39Packages.connexion

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/30jml4pv2mwi5fibbs695c26nj71psag-python3.10-connexion-2.14.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.connexion https://github.com/r-ryantm/nixpkgs/archive/71509843c96484dca90319e2fe98ee4c657ca644.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/30jml4pv2mwi5fibbs695c26nj71psag-python3.10-connexion-2.14.1
ls -la /nix/store/30jml4pv2mwi5fibbs695c26nj71psag-python3.10-connexion-2.14.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python310Packages.connexion
python39Packages.connexion

Maintainer pings
cc @elohmeier for testing.

@GrahamcOfBorg eval

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

2 packages built:

python310Packages.connexion
python39Packages.connexion


firebase_auth

Hi everyone, please could you please help me with the next error (Thanks a lot):

FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:lintVitalRelease'.

Could not resolve all artifacts for configuration ':app:profileRuntimeClasspath'.
Failed to transform libs.jar to match attributes {artifactType=processed-jar, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
Execution failed for JetifyTransform: E:\ANDROID\PROYECTOS\rodapp\build\app\intermediates\flutter\profile\libs.jar.
Transform's input file does not exist: E:\ANDROID\PROYECTOS\rodapp\build\app\intermediates\flutter\profile\libs.jar. (See https://issuetracker.google.com/issues/158753935)

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 54s
Running Gradle task 'assembleRelease'...
Running Gradle task 'assembleRelease'... Done                      55,7s
The built failed likely due to AndroidX incompatibilities in a plugin. The tool is about to try using Jetfier to solve the incompatibility.
Building plugin firebase_auth...
Running Gradle task 'assembleAarRelease'...
Running Gradle task 'assembleAarRelease'... Done                    2,2s
FAILURE: Build failed with an exception.

Where:
Build file 'E:\ANDROID\flutter.pub-cache\hosted\pub.dartlang.org\firebase_auth-0.18.4+1\android\build.gradle' line: 26

What went wrong:
A problem occurred evaluating root project 'firebase_auth'.

Could not find the firebase_core FlutterFire plugin, have you added it as a dependency in your pubspec?

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 1s
The plugin firebase_auth could not be built due to the issue above.
line 26 code in file build.gradle:
def firebaseCoreProject = findProject(':firebase_core')
if (firebaseCoreProject == null) {
throw new GradleException('Could not find the firebase_core FlutterFire plugin, have you added it as a dependency in your pubspec?')
} else if (!firebaseCoreProject.properties['FirebaseSDKVersion']) {
throw new GradleException('A newer version of the firebase_core FlutterFire plugin is required, please update your firebase_core pubspec dependency.')
}
def getRootProjectExtOrCoreProperty(name, firebaseCoreProject) {
if (!rootProject.ext.has('FlutterFire')) return firebaseCoreProject.properties[name]
if (!rootProject.ext.get('FlutterFire')[name]) return firebaseCoreProject.properties[name]
return rootProject.ext.get('FlutterFire').get(name)
}

@DiegoEros
firebase is a 3rd party plugin please open an issue in the dedicated github

@DiegoEros
firebase is a 3rd party plugin please open an issue in the dedicated github

Hi @DiegoEros
From what I can see, the issue is related to a FlutterFire plugin rather than to Flutter itself. Please open the issue in the dedicated repository.
Closing, as this isn't an issue with Flutter itself.
If you disagree, please write in the comments,
providing your flutter doctor -v, your flutter run -v,  your pubspec.yaml
a minimal reproducible code sample that does not use 3rd party plugins,
and I will reopen it.
Thank you

Hi @DiegoEros
From what I can see, the issue is related to a FlutterFire plugin rather than to Flutter itself. Please open the issue in the dedicated repository.
Closing, as this isn't an issue with Flutter itself.
If you disagree, please write in the comments,
providing your flutter doctor -v, your flutter run -v,  your pubspec.yaml
a minimal reproducible code sample that does not use 3rd party plugins,
and I will reopen it.
Thank you

while building the app after the latest update, but then I disabled the lint task in android/app/build.gradle
lintOptions {
disable 'InvalidPackage'
checkReleaseBuilds false
}
and this worked for me.
Thanks a lot!!

while building the app after the latest update, but then I disabled the lint task in android/app/build.gradle
lintOptions {
disable 'InvalidPackage'
checkReleaseBuilds false
}
and this worked for me.
Thanks a lot!!

Hi @DiegoEros
From what I can see, the issue is related to a FlutterFire plugin rather than to Flutter itself. Please open the issue in the dedicated repository.
Closing, as this isn't an issue with Flutter itself.
If you disagree, please write in the comments,
providing your flutter doctor -v, your flutter run -v, your pubspec.yaml
a minimal reproducible code sample that does not use 3rd party plugins,
and I will reopen it.
Thank you

Yes, thanks

Hi @DiegoEros
From what I can see, the issue is related to a FlutterFire plugin rather than to Flutter itself. Please open the issue in the dedicated repository.
Closing, as this isn't an issue with Flutter itself.
If you disagree, please write in the comments,
providing your flutter doctor -v, your flutter run -v, your pubspec.yaml
a minimal reproducible code sample that does not use 3rd party plugins,
and I will reopen it.
Thank you

Yes, thanks


htop isn't working

At the moment, when we start htop inside a mosaic pane, it panics (because of an unhandled CSI).

This was partially fixed, but there's still some work to do here.


Should also have a link to report a problem with the content / documentation

Currently, there is an easy way to report a problem with the website (which brings you here).
There should also be a link in the "More" pulldown to report a problem with the content, aka the documentation.

We already have tickets that come here; We can easily transfer tickets between github repos. I've updated the ticket template for this repo to point to raku/doc.
I'm not convinced we need this on the site itself, we can't include enough explanatory text there.

Duplicate of #214

It's definitely not a bad thing that you did - at least we can revise the possibilities, and I for one definitely prefer having two links.


Feature/fill circle

Feature request done for issue 48
Changelog:

Ability to set general.accessibility in config.toml file for viddy
Change to fill circle upon setting on the option of Suspend, Diff, Bell when accessibility is set to true
And change the foreground color to black and background color to white (for better contrast)
If accessibility is set to false, viddy behaves as it did before

@coolabhays Thank you. Accessibility mode is great.
I consider it enough to start with that it will be a filled circle.
I would like to avoid changing the foreground color to black and the background color to white because it conflicts with the theme setting.

@coolabhays I want to merge this.
If there is no comment here in 3 days, I would like to fix and merge this PR

@sachaos Yes, changing foreground and background color to black and white does stands out from the theme, but since this was for accessibility setting, it was not so bad payoff. Also, since there are different types of colour-blindness, white-black combination seemed a pretty valid choice.
Also, mention the usage (maybe in wiki for viddy) all the different color value settings like you used for viper configuration under [color],  as going through code I wasn't sure, like what's secondary_text, tertiary_text, graphics etc., as it would help in using them in development.
The color combination of for diff which is I think [white:green]' by default, is also not a good combination for colour-blindness.
What I think is that accessibility should be a toggle switch, which should set necessary settings on the little payoff for the theme (which will not be of much usage for them anyway). Do tell what do you think ?


Move AppTP and VPN matching attrs out of rmf modules

Task/Issue URL: https://app.asana.com/0/488551667048375/1207135101272551/f
Description
Move NetP and AppTP to matching attributes plugin point
Steps to test this PR
Feature 1

[ ]
[ ]

#4455  👈
develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @aitorvs and the rest of your teammates on  Graphite

Merge activity

Apr 25, 7:09 AM EDT: @aitorvs started a stack merge that includes this pull request via Graphite.