e2e test: ERROR:v8_initializer.cc(730)] V8 process OOM (Oilpan: Reserving memory.).

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
d35ie698c38wkh
AWS Region
us-east-2
Amplify Hosting feature
E2E Cypress tests
Describe the bug
Test failed because Chromium Renderer process just crashed in the build.
It works well on my local machine.
the Cypress running environments are the same, but the Amplify console build has 2 warnings on top
 Opening Cypress...
2023-01-05T19:19:39.030Z [WARNING]: [17065:0105/191939.029492:ERROR:node_bindings.cc(279)] Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
2023-01-05T19:19:39.970Z [WARNING]: [17221:0105/191939.969753:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.
2023-01-05T19:19:42.259Z [INFO]:
2023-01-05T19:19:42.274Z [INFO]: ================================================================================
2023-01-05T19:19:42.274Z [INFO]: (Run Starting)
2023-01-05T19:19:42.274Z [WARNING]: tput: No value for $TERM and no -T specified
2023-01-05T19:19:42.281Z [INFO]: ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
                                 │ Cypress:        10.11.0                                                                        │
                                 │ Browser:        Electron 106 (headless)                                                        │
                                 │ Node Version:   v16.19.0 (/root/.nvm/versions/node/v16.19.0/bin/node)                          │
                                 │ Specs:          1 found (links.cy.ts)                                                          │
                                 │ Searched:       cypress/e2e/**/*.cy.{js,jsx,ts,tsx}                                            │
                                 └────────────────────────────────────────────────────────────────────────────────────────────────┘

The actually error message is in the log output details.
Expected behavior
Chromium Renderer process should not crash. It should complete all the tests.
Reproduction steps
for (let i = 0; i < 100; i++) {
  describe(`check page ${i}`, () => {
    const baseUrl = 'http://localhost:5001';

    it(`all links on ${i} link should work`, () => {
      const link = allLinks[i];
      cy.task('log', `[TESTING...] page ${baseUrl}/${link}`);
      cy.request(link || '/').then(({ status }) => {
        expect(status).to.eq(200);
        cy.clearLocalStorage();
      });
    });
  });
}

Build Settings
No response
Log output

2023-01-05T19:35:15.938Z [WARNING]: <--- Last few GCs --->
                                    [17313:0x4f4003d8000]   929184 ms: Scavenge 335.6 (366.0) -> 329.4 (366.0) MB, 2.1 / 0.0 ms  (average mu = 0.997, current mu = 0.997) allocation failure;
                                    [17313:0x4f4003d8000]   931672 ms: Scavenge 335.0 (366.0) -> 329.7 (366.0) MB, 3.0 / 0.0 ms  (average mu = 0.997, current mu = 0.997) task;
                                    [17313:0x4f4003d8000]   933572 ms: Scavenge 336.0 (366.0) -> 329.7 (366.0) MB, 2.1 / 0.0 ms  (average mu = 0.997, current mu = 0.997) allocation failure;
                                    <--- JS stacktrace --->
2023-01-05T19:35:15.938Z [WARNING]: [17313:0105/193515.937936:ERROR:v8_initializer.cc(730)] V8 process OOM (Oilpan: Reserving memory.).
2023-01-05T19:35:20.587Z [INFO]:
2023-01-05T19:35:20.592Z [INFO]: We detected that the Chromium Renderer process just crashed.
                                 This is the equivalent to seeing the 'sad face' when Chrome dies.
                                 This can happen for a number of different reasons:
                                 - You wrote an endless loop and you must fix your own code
                                 - You are running Docker (there is an easy fix for this: see link below)
                                 - You are running lots of tests on a memory intense application
                                 - You are running in a memory starved VM environment
                                 - There are problems with your GPU / GPU drivers
                                 - There are browser bugs in Chromium
                                 You can learn more including how to fix Docker here:
                                 https://on.cypress.io/renderer-process-crashed

Additional information
Same code as https://github.com/cypress-io/cypress/issues/24356, but different error since the memory size is no longer an issue.

Hi @0618 👋🏽 it looks like javascript ran out of memory while running your tests. You should be able to resolve this by setting this environment variable:
NODE_OPTIONS=--max-old-space-size=4096
Please let us know if you're still running into this issue after adding that variable.

Thanks. Let me try that.

Thanks @hloriana , NODE_OPTIONS=--max-old-space-size=4096 was already one of our Environment Variables.

Updating for visibility. This issue appears to be related to https://github.com/cypress-io/cypress/issues/24905.
Since these tests were able to run successfully in the past, one suggestion is to try downgrading to Cypress version 10.7.0.

Closing due to no response, please open a new issue if you continue to run into this behavior.


Feature Request : Daily kWh counter

Any thoughts on getting a daily counter added similar to the session and total counters?

this is more a feature request for firmware .
If data is published through the API it can be easily added here.

Thanks @KipK I have logged a feature request (issue) on the main repository... Hopefully they pick it up...

@TommySharpNZ  Not sure what use case is driving your request. However, I have been enjoying the utility of HomeAssistant logging and graphing all of my OpenEVSE use activity. Maybe that would get you the data / display you are looking for as well until this is implemented?

@TommySharpNZ Not sure what use case is driving your request. However, I have been enjoying the utility of HomeAssistant logging and graphing all of my OpenEVSE use activity. Maybe that would get you the data / display you are looking for as well until this is implemented?

Would you mind sharing your config here on on the HomeAssistant forums?
I have tried to use the Total Usage sensor from OpenEVSE but I'm suspecting this only updates at the end of each charging session which means I get a chart with lots of jumps and not a proper usage line...

Yes total usage is only incremented at the end of a session.
What I did to counter that is feeding a virtual counter on smart home side, that use the total +session elapsed while charging. And just the total when session ended.

@TommySharpNZ -
I was able to accomplish this by creating a helper of type "Integration - Riemann sum" using source sensor.openevse_current_power_usage . Then create an automation to reset the helper at the time of day that you wish.

Question: how/when does the OpenEVSE decide the charge session is a new session (reset to zero)? Now sometimes I want to start a new session with an energy limit and I need to add that to the current counter in order for it to work as I intend to, a bit weird...
I am not sure what the advantage would be to have a daily counter in OpenEVSE? I can see that in emoncms, but not in OpenEVSE functionality per se. Just my opinion.

counter is reset at new vehicle connection.

@TommySharpNZ  -
KipK's newest GUI revision has your feature, btw:

Not sure when it will make it to the nightlies, or to a full release, but it is on its way!

Nice Nice Nice!
Although if it's just in @KipK new UI does not mean it will not be available in the "api" that the HomeAssistant integration uses?

It's on the api yes

This is great news, thanks team!

Fixed in EnergyMeter fw branch, waiting for merge


Add new released video to README

title: Issue # | Add new released video to README

Discord Username: @frane_caleta
What type of PR is this? (select all that apply)

[ ] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 🚧 Breaking Change
[ ] 🧑💻 Code Refactor
[x] 📝 Documentation Update

Description

Related Tickets & Documents

Related Issue #
Closes #

QA Instructions, Screenshots, Recordings

UI accessibility concerns?

Added/updated tests?

[ ] 👍 yes
[x] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

[optional] Are there any post deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

Please, someone with permission, retrigger the CI, thanks.


Apply CGI.escape to non-array non-form values

Problem
A string query param described in an rswag integration spec gets escaped in rspec tests and doesn't get escaped in rswag non-dry run.
Solution
Apply the same array and form escaping to everything else.
The changes I made are compatible with:

[X] OAS2
[X] OAS3
[X] OAS3.1

Checklist

[ ] Added tests
[ ] Changelog updated
[ ] Added documentation to README.md
[ ] Added example of using the enhancement into test-app

Steps to Test or Reproduce

Have a query param called x that is a string and contains a #, for example: ?filter[description]=Order for #231
Run the test and inspect the params in the controller

Woops, wrong repository.


Provide a mechanism for "tidying" Node allocate|capacity

Is your feature request related to a problem? Please describe.
Potentially.
Over time, Akri indirectly updates nodes with details of devices. These updates aren't tidied once the devices are deleted.
For example, I have 4 Instances deployed. Each maps an Akri managed device to a Broker:
kubectl get instances
NAME              CONFIG     SHARED   NODES    AGE
zeroconf-8e12f9   zeroconf   true     [akri]   5m49s
zeroconf-90d0fb   zeroconf   true     [akri]   5m49s
zeroconf-9e1938   zeroconf   true     [akri]   5m49s
zeroconf-f1acf2   zeroconf   true     [akri]   5m49s

But, after having used Akri (in the same cluster) for several weeks (even though Akri is being recreated daily), the detritus builds up in the Node:
NODE="akri" # Kubernetes Node name

# 56 of these 62 total `capacity` entries are by Akri
kubectl get node/${NODE} \
--output=json \
| jq '.status.capacity | with_entries(select(.key|contains("akri.sh"))) | length'
56

kubectl get node/${NODE} \
--output=json \
| jq '.status.capacity | with_entries(select(.key|contains("akri.sh/http"))) | length'
41

kubectl get node/${NODE} \
--output=json \
| jq '.status.capacity | with_entries(select(.key|contains("akri.sh/zeroconf"))) | length'
12

A "clean" node contains only 6 entries.
Is your feature request related to a way you would like Akri extended? Please describe.
If not automated pruning, documentation of this (potential!) issue.
Describe the solution you'd like
When Akri is uninstalled, it purges allocatable and capacity entries from K8s Node(s).
Describe alternatives you've considered
I tried patching the Node but have been unable to get this to work:
# Using `kubectl`
kubectl patch node/${NODE} \
--type=json \
--patch="[{'op': 'remove', 'path': '/status/allocatable'}]"

# Using `kubectl proxy` and `curl`
NODE="akri"
PORT="8888"

kubectl proxy --port=${PORT} &

curl \
--header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "remove", "path": "/status/allocatable"}]' \
http://localhost:${PORT}/api/v1/nodes/${NODE}/status

Additional context
Add any other context or screenshots about the feature request here.

I discovered a way to do this....
It's unusual that, even though the UNIX sockets are automatically deleted, the Node annotations aren't.
My mistake previously was in assuming that akri.sh/ mapped to akri.sh~, it actually maps to akri.sh~1.
  The agent is already watching for instance deletion... maybe it could clean up the node capacity&allocatable?  Though neither agent or controller are rbac'd for node patch currently.

I don't understand why this isn't part of the Device Plugin functionality. The sockets are deleted so it feels like this is a referential integrity issue.

I don't understand why this isn't part of the Device Plugin functionality. The sockets are deleted so it feels like this is a referential integrity issue.

I agree.  I think a lot of missing stuff (this and no deallocate) are scenario driven.  I believe Device Plugin was not aimed at dynamic resources.

Would you mind if I ask the Device Plugin folks about this experience to determine whether it's known|understood?
Now I've taken the time to understand Akri's implementation, it seems to be a clever and entirely reasonable use of Device Plugins.
Since the Device Plugins API creates the Node entries, it feels as though it should that API's responsibility to delete them too.

I would love to hear the device plugin folks' take on this.

Emailed the developers as I was unable to determine where to file the issue on Kubernetes|Stackoverflow.
Will report back when they reply.

For completeness, Google's Jiaying replied to me on 201221: "As I remember, there is a 5m stopgraceperiod, and after that, device manager should remove the unhealthy device plugin resources from its capacity."
I replied that: "I think the capacity value may be reduced (will check) but the entry is not deleted from the capacity list. In my example, all those resources will continue to be listed under capacity until they are explicitly deleted by calling PATCH."
That was the end of the thread but they may be out for the Holidays.

I wonder if the Device Plugin Manager doesn't clean up the Node because we are deleting the device plugin sockets, too quickly. Currently, when an instance is deleted, unhealthy devices are sent to the Device Plugin Manager and then the device plugin service for that instance is told to shutdown and the socket is deleted. If the socket is deleted, it may make sense that the Device Plugin Manager doesnt know what to clean up. Maybe the flow should be changed to: send back unhealthy devices for at least 5 minutes and then shutdown the device plugin service and delete the socket.

I wonder if the Device Plugin Manager doesn't clean up the Node because we are deleting the device plugin sockets, too quickly. Currently, when an instance is deleted, unhealthy devices are sent to the Device Plugin Manager and then the device plugin service for that instance is told to shutdown and the socket is deleted. If the socket is deleted, it may make sense that the Device Plugin Manager doesnt know what to clean up. Maybe the flow should be changed to: send back unhealthy devices for at least 5 minutes and then shutdown the device plugin service and delete the socket.

Interesting.
I assumed (incorrectly) that, deleting the socket, would force Kubernetes to tidy up the resource since, without the socket ...
This doesn't appear to be well-documented.
How difficult would it be for you to (or you to tell me how to?) try the hypothesis?

Interesting.
I assumed (incorrectly) that, deleting the socket, would force Kubernetes to tidy up the resource since, without the socket ...
This doesn't appear to be well-documented.
How difficult would it be for you to (or you to tell me how to?) try the hypothesis?

maybe adjusting the code here ?
replace dps.server_ender_sender.clone().send(()).await.unwrap(); with an async call that waited 5 minutes before sending?

maybe adjusting the code here ?
replace dps.server_ender_sender.clone().send(()).await.unwrap(); with an async call that waited 5 minutes before sending?

My async rust foo is weak :disappointed:
Something like this?
let mut all_futures = Vec::new();

while keep_looping {
  let mut clone = dps.server_ender_sender.clone();
  let f =|| async move  {
    delay_for(Duration::from_secs(300)).await;
    clone.send(()).await
  };
   all_futures.push(f());
   keep_looping = false;
}

let _result = futures::future::try_join_all(all_futures).await;

My async rust foo is weak :disappointed:
Something like this?
let mut all_futures = Vec::new();

while keep_looping {
  let mut clone = dps.server_ender_sender.clone();
  let f =|| async move  {
    delay_for(Duration::from_secs(300)).await;
    clone.send(()).await
  };
   all_futures.push(f());
   keep_looping = false;
}

let _result = futures::future::try_join_all(all_futures).await;

yeah ... somthing like that.  you can probably even skip the join:
let mut server_ender_sender_clone = dps.server_ender_sender.clone();
tokio::spawn(async move {
    delay_for(Duration::from_secs(300)).await;
    server_ender_sender_clone.send(()).await.unwrap();
});

yeah ... somthing like that.  you can probably even skip the join:
let mut server_ender_sender_clone = dps.server_ender_sender.clone();
tokio::spawn(async move {
    delay_for(Duration::from_secs(300)).await;
    server_ender_sender_clone.send(()).await.unwrap();
});

Ah, clearly I don't grok the loop. I was expecting it to bundle the entire crop of deleted Instances but, it appears there's only every one future produced by it:
kubectl get instances
NAME              CONFIG     SHARED   NODES    AGE
zeroconf-0d06e7   zeroconf   true     [akri]   72s
zeroconf-44d7c1   zeroconf   true     [akri]   72s
zeroconf-bc5064   zeroconf   true     [akri]   72s
zeroconf-f27f70   zeroconf   true     [akri]   72s

# Includes previous+current resources
kubectl get node/${NODE} --output=json | jq '.status.allocatable'
{
  "akri.sh/webthings-d6097c": "0",
  "akri.sh/zeroconf-0d06e7": "1",
  "akri.sh/zeroconf-129a69": "0",
  "akri.sh/zeroconf-1bef11": "0",
  "akri.sh/zeroconf-320a0c": "0",
  "akri.sh/zeroconf-3ada00": "0",
  "akri.sh/zeroconf-44d7c1": "1",
  "akri.sh/zeroconf-591f22": "0",
  "akri.sh/zeroconf-bc5064": "1",
  "akri.sh/zeroconf-ef5d4a": "0",
  "akri.sh/zeroconf-f27f70": "1",
  "cpu": "2",
  "ephemeral-storage": "8934656Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "8050104Ki",
  "pods": "110"
}

kubectl get node/${NODE} --output=json | jq '.status.capacity'
{
  "akri.sh/webthings-d6097c": "0",
  "akri.sh/zeroconf-0d06e7": "1",
  "akri.sh/zeroconf-129a69": "0",
  "akri.sh/zeroconf-1bef11": "0",
  "akri.sh/zeroconf-320a0c": "0",
  "akri.sh/zeroconf-3ada00": "0",
  "akri.sh/zeroconf-44d7c1": "1",
  "akri.sh/zeroconf-591f22": "0",
  "akri.sh/zeroconf-bc5064": "1",
  "akri.sh/zeroconf-ef5d4a": "0",
  "akri.sh/zeroconf-f27f70": "1",
  "cpu": "2",
  "ephemeral-storage": "9983232Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "8152504Ki",
  "pods": "110"
}

# Delete Instances
kubectl delete --filename=./zeroconf.yaml

# Check the Agent's logs
kubectl logs --follow pod/akri-agent-daemonset-4w7pc | grep "^\[device_plugin_service\]"
[device_plugin_service] Pushing
[device_plugin_service] Try Joining
[device_plugin_service] Sleeping
[device_plugin_service] Pushing
[device_plugin_service] Try Joining
[device_plugin_service] Sleeping
[device_plugin_service] Pushing
[device_plugin_service] Try Joining
[device_plugin_service] Sleeping
[device_plugin_service] Pushing
[device_plugin_service] Try Joining
[device_plugin_service] Sleeping

# 5 minutes later
[device_plugin_service] Done sleeping. Sending
[device_plugin_service] Done sleeping. Sending
[device_plugin_service] Done sleeping. Sending
[device_plugin_service] Done sleeping. Sending

So, I think that's behaving correctly....

Ah, clearly I don't grok the loop. I was expecting it to bundle the entire crop of deleted Instances but, it appears there's only every one future produced by it:
kubectl get instances
NAME              CONFIG     SHARED   NODES    AGE
zeroconf-0d06e7   zeroconf   true     [akri]   72s
zeroconf-44d7c1   zeroconf   true     [akri]   72s
zeroconf-bc5064   zeroconf   true     [akri]   72s
zeroconf-f27f70   zeroconf   true     [akri]   72s

# Includes previous+current resources
kubectl get node/${NODE} --output=json | jq '.status.allocatable'
{
  "akri.sh/webthings-d6097c": "0",
  "akri.sh/zeroconf-0d06e7": "1",
  "akri.sh/zeroconf-129a69": "0",
  "akri.sh/zeroconf-1bef11": "0",
  "akri.sh/zeroconf-320a0c": "0",
  "akri.sh/zeroconf-3ada00": "0",
  "akri.sh/zeroconf-44d7c1": "1",
  "akri.sh/zeroconf-591f22": "0",
  "akri.sh/zeroconf-bc5064": "1",
  "akri.sh/zeroconf-ef5d4a": "0",
  "akri.sh/zeroconf-f27f70": "1",
  "cpu": "2",
  "ephemeral-storage": "8934656Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "8050104Ki",
  "pods": "110"
}

kubectl get node/${NODE} --output=json | jq '.status.capacity'
{
  "akri.sh/webthings-d6097c": "0",
  "akri.sh/zeroconf-0d06e7": "1",
  "akri.sh/zeroconf-129a69": "0",
  "akri.sh/zeroconf-1bef11": "0",
  "akri.sh/zeroconf-320a0c": "0",
  "akri.sh/zeroconf-3ada00": "0",
  "akri.sh/zeroconf-44d7c1": "1",
  "akri.sh/zeroconf-591f22": "0",
  "akri.sh/zeroconf-bc5064": "1",
  "akri.sh/zeroconf-ef5d4a": "0",
  "akri.sh/zeroconf-f27f70": "1",
  "cpu": "2",
  "ephemeral-storage": "9983232Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "8152504Ki",
  "pods": "110"
}

# Delete Instances
kubectl delete --filename=./zeroconf.yaml

# Check the Agent's logs
kubectl logs --follow pod/akri-agent-daemonset-4w7pc | grep "^\[device_plugin_service\]"
[device_plugin_service] Pushing
[device_plugin_service] Try Joining
[device_plugin_service] Sleeping
[device_plugin_service] Pushing
[device_plugin_service] Try Joining
[device_plugin_service] Sleeping
[device_plugin_service] Pushing
[device_plugin_service] Try Joining
[device_plugin_service] Sleeping
[device_plugin_service] Pushing
[device_plugin_service] Try Joining
[device_plugin_service] Sleeping

# 5 minutes later
[device_plugin_service] Done sleeping. Sending
[device_plugin_service] Done sleeping. Sending
[device_plugin_service] Done sleeping. Sending
[device_plugin_service] Done sleeping. Sending

So, I think that's behaving correctly....

But, I'm expecting (?) e.g. 0d06e7 from the just created|deleted Instances to be removed and it is not.
kubectl get node/${NODE} --output=json | jq '.status.allocatable'
{
  "akri.sh/webthings-d6097c": "0",
  "akri.sh/zeroconf-0d06e7": "0",
  "akri.sh/zeroconf-129a69": "0",
  "akri.sh/zeroconf-1bef11": "0",
  "akri.sh/zeroconf-320a0c": "0",
  "akri.sh/zeroconf-3ada00": "0",
  "akri.sh/zeroconf-44d7c1": "0",
  "akri.sh/zeroconf-591f22": "0",
  "akri.sh/zeroconf-bc5064": "0",
  "akri.sh/zeroconf-ef5d4a": "0",
  "akri.sh/zeroconf-f27f70": "0",
  "cpu": "2",
  "ephemeral-storage": "8934656Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "8050104Ki",
  "pods": "110"
}
dazwilkin@akri:~$ kubectl get node/${NODE} --output=json | jq '.status.capacity'
{
  "akri.sh/webthings-d6097c": "0",
  "akri.sh/zeroconf-0d06e7": "1",
  "akri.sh/zeroconf-129a69": "0",
  "akri.sh/zeroconf-1bef11": "0",
  "akri.sh/zeroconf-320a0c": "0",
  "akri.sh/zeroconf-3ada00": "0",
  "akri.sh/zeroconf-44d7c1": "1",
  "akri.sh/zeroconf-591f22": "0",
  "akri.sh/zeroconf-bc5064": "1",
  "akri.sh/zeroconf-ef5d4a": "0",
  "akri.sh/zeroconf-f27f70": "1",
  "cpu": "2",
  "ephemeral-storage": "9983232Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "8152504Ki",
  "pods": "110"
}

But, I'm expecting (?) e.g. 0d06e7 from the just created|deleted Instances to be removed and it is not.
kubectl get node/${NODE} --output=json | jq '.status.allocatable'
{
  "akri.sh/webthings-d6097c": "0",
  "akri.sh/zeroconf-0d06e7": "0",
  "akri.sh/zeroconf-129a69": "0",
  "akri.sh/zeroconf-1bef11": "0",
  "akri.sh/zeroconf-320a0c": "0",
  "akri.sh/zeroconf-3ada00": "0",
  "akri.sh/zeroconf-44d7c1": "0",
  "akri.sh/zeroconf-591f22": "0",
  "akri.sh/zeroconf-bc5064": "0",
  "akri.sh/zeroconf-ef5d4a": "0",
  "akri.sh/zeroconf-f27f70": "0",
  "cpu": "2",
  "ephemeral-storage": "8934656Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "8050104Ki",
  "pods": "110"
}
dazwilkin@akri:~$ kubectl get node/${NODE} --output=json | jq '.status.capacity'
{
  "akri.sh/webthings-d6097c": "0",
  "akri.sh/zeroconf-0d06e7": "1",
  "akri.sh/zeroconf-129a69": "0",
  "akri.sh/zeroconf-1bef11": "0",
  "akri.sh/zeroconf-320a0c": "0",
  "akri.sh/zeroconf-3ada00": "0",
  "akri.sh/zeroconf-44d7c1": "1",
  "akri.sh/zeroconf-591f22": "0",
  "akri.sh/zeroconf-bc5064": "1",
  "akri.sh/zeroconf-ef5d4a": "0",
  "akri.sh/zeroconf-f27f70": "1",
  "cpu": "2",
  "ephemeral-storage": "9983232Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "8152504Ki",
  "pods": "110"
}

yeah ... somthing like that. you can probably even skip the join:
let mut server_ender_sender_clone = dps.server_ender_sender.clone();
tokio::spawn(async move {
    delay_for(Duration::from_secs(300)).await;
    server_ender_sender_clone.send(()).await.unwrap();
});

You're awesome. Thanks... That's better

yeah ... somthing like that. you can probably even skip the join:
let mut server_ender_sender_clone = dps.server_ender_sender.clone();
tokio::spawn(async move {
    delay_for(Duration::from_secs(300)).await;
    server_ender_sender_clone.send(()).await.unwrap();
});

You're awesome. Thanks... That's better

Just to make sure I understand, you added the 5 minute delay but the node still contains the remnants of our device-plugin?  Which, as far as capacity goes, is not what Jiaying expected?

Just to make sure I understand, you added the 5 minute delay but the node still contains the remnants of our device-plugin?  Which, as far as capacity goes, is not what Jiaying expected?

I'll try it again with 6 minutes but...

I'll try it again with 6 minutes but...

LOL.  I'll cross my fingers, but i suspect you've identified something that isn't working in Device-Plugin.

LOL.  I'll cross my fingers, but i suspect you've identified something that isn't working in Device-Plugin.

Here's the state restarting today. I expect there to be no sockets (correct) and I expect status|allocatable to match that. Yesterday's undeleted-by-me entries persist:
kubectl get node/${NODE} --output=json \
| jq '.status.allocatable | with_entries(select(.key|contains("akri.sh/zeroconf")))'
{
  "akri.sh/zeroconf-3c0a74": "0",
  "akri.sh/zeroconf-407949": "0",
  "akri.sh/zeroconf-5b22aa": "0",
  "akri.sh/zeroconf-772363": "0",
  "akri.sh/zeroconf-f4738e": "0"
}
kubectl get node/${NODE} --output=json \
| jq '.status.capacity | with_entries(select(.key|contains("akri.sh/zeroconf")))'
{
  "akri.sh/zeroconf-3c0a74": "0",
  "akri.sh/zeroconf-407949": "0",
  "akri.sh/zeroconf-5b22aa": "0",
  "akri.sh/zeroconf-772363": "0",
  "akri.sh/zeroconf-f4738e": "0"
}
ls -l /var/lib/kubelet/device-plugins/
total 4
-rw-r--r-- 1 root root    0 Jan  6 18:21 DEPRECATION
srwxr-xr-x 1 root root    0 Jan  6 18:21 kubelet.sock
-rw------- 1 root root 3588 Jan  5 22:51 kubelet_internal_checkpoint

Here's the state restarting today. I expect there to be no sockets (correct) and I expect status|allocatable to match that. Yesterday's undeleted-by-me entries persist:
kubectl get node/${NODE} --output=json \
| jq '.status.allocatable | with_entries(select(.key|contains("akri.sh/zeroconf")))'
{
  "akri.sh/zeroconf-3c0a74": "0",
  "akri.sh/zeroconf-407949": "0",
  "akri.sh/zeroconf-5b22aa": "0",
  "akri.sh/zeroconf-772363": "0",
  "akri.sh/zeroconf-f4738e": "0"
}
kubectl get node/${NODE} --output=json \
| jq '.status.capacity | with_entries(select(.key|contains("akri.sh/zeroconf")))'
{
  "akri.sh/zeroconf-3c0a74": "0",
  "akri.sh/zeroconf-407949": "0",
  "akri.sh/zeroconf-5b22aa": "0",
  "akri.sh/zeroconf-772363": "0",
  "akri.sh/zeroconf-f4738e": "0"
}
ls -l /var/lib/kubelet/device-plugins/
total 4
-rw-r--r-- 1 root root    0 Jan  6 18:21 DEPRECATION
srwxr-xr-x 1 root root    0 Jan  6 18:21 kubelet.sock
-rw------- 1 root root 3588 Jan  5 22:51 kubelet_internal_checkpoint

After creating then deleting 4 (Zeroconf) (uniquely-named for unique hashes) Instances:
kubectl get instances
NAME              CONFIG     SHARED   NODES      AGE
zeroconf-f1acf2   zeroconf   true     ["akri"]   0s
zeroconf-8e12f9   zeroconf   true     ["akri"]   0s
zeroconf-52d084   zeroconf   true     ["akri"]   0s
zeroconf-90d0fb   zeroconf   true     ["akri"]   0s

ls -l /var/lib/kubelet/device-plugins/
total 4
-rw-r--r-- 1 root root    0 Jan  6 18:21 DEPRECATION
srwxr-xr-x 1 root root    0 Jan  6 18:21 kubelet.sock
-rw------- 1 root root 2990 Jan  6 18:33 kubelet_internal_checkpoint
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-52d084-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-8e12f9-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-90d0fb-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-f1acf2-1609957962.sock

# Delete

kubectl get instances
No resources found in default namespace.

I expect the .status entries to be incremented by +4 and then, after 5-minutes (and certainly 6-minutes), I expect the sockets (will monitor) and .status entries to be deleted.

After creating then deleting 4 (Zeroconf) (uniquely-named for unique hashes) Instances:
kubectl get instances
NAME              CONFIG     SHARED   NODES      AGE
zeroconf-f1acf2   zeroconf   true     ["akri"]   0s
zeroconf-8e12f9   zeroconf   true     ["akri"]   0s
zeroconf-52d084   zeroconf   true     ["akri"]   0s
zeroconf-90d0fb   zeroconf   true     ["akri"]   0s

ls -l /var/lib/kubelet/device-plugins/
total 4
-rw-r--r-- 1 root root    0 Jan  6 18:21 DEPRECATION
srwxr-xr-x 1 root root    0 Jan  6 18:21 kubelet.sock
-rw------- 1 root root 2990 Jan  6 18:33 kubelet_internal_checkpoint
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-52d084-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-8e12f9-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-90d0fb-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-f1acf2-1609957962.sock

# Delete

kubectl get instances
No resources found in default namespace.

I expect the .status entries to be incremented by +4 and then, after 5-minutes (and certainly 6-minutes), I expect the sockets (will monitor) and .status entries to be deleted.

The Akri device_plugin_service "loop" appears to function correctly.
Here's the sockets:
ls -l /var/lib/kubelet/device-plugins/
total 4
-rw-r--r-- 1 root root    0 Jan  6 18:21 DEPRECATION
srwxr-xr-x 1 root root    0 Jan  6 18:21 kubelet.sock
-rw------- 1 root root 2876 Jan  6 18:38 kubelet_internal_checkpoint
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-52d084-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-8e12f9-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-90d0fb-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-f1acf2-1609957962.sock

Monitoring the Agent's logs:
kubectl logs --follow pod/akri-agent-daemonset-nk8vf | grep "Sleeping\|Sending"
[2021-01-06T18:33:46Z TRACE agent::util::device_plugin_service] Sleeping
[2021-01-06T18:33:46Z TRACE agent::util::device_plugin_service] Sleeping
[2021-01-06T18:33:46Z TRACE agent::util::device_plugin_service] Sleeping
[2021-01-06T18:33:46Z TRACE agent::util::device_plugin_service] Sleeping
[2021-01-06T18:39:46Z TRACE agent::util::device_plugin_service] Sending
[2021-01-06T18:39:46Z TRACE agent::util::device_plugin_service] Sending
[2021-01-06T18:39:46Z TRACE agent::util::device_plugin_service] Sending
[2021-01-06T18:39:46Z TRACE agent::util::device_plugin_service] Sending

As soon as I saw the Sending, I rechecked the sockets (deleted as expected):
ls -l /var/lib/kubelet/device-plugins/
total 4
-rw-r--r-- 1 root root    0 Jan  6 18:21 DEPRECATION
srwxr-xr-x 1 root root    0 Jan  6 18:21 kubelet.sock
-rw------- 1 root root 2876 Jan  6 18:38 kubelet_internal_checkpoint

But no change to the .status entries:
kubectl get node/${NODE} --output=json \
| jq '.status.capacity | with_entries(select(.key|contains("akri.sh/zeroconf")))'
{
  "akri.sh/zeroconf-3c0a74": "0",
  "akri.sh/zeroconf-407949": "0",
  "akri.sh/zeroconf-52d084": "0",
  "akri.sh/zeroconf-5b22aa": "0",
  "akri.sh/zeroconf-772363": "0",
  "akri.sh/zeroconf-8e12f9": "0",
  "akri.sh/zeroconf-90d0fb": "0",
  "akri.sh/zeroconf-f1acf2": "0",
  "akri.sh/zeroconf-f4738e": "0"
}
kubectl get node/${NODE} --output=json \
| jq '.status.allocatable | with_entries(select(.key|contains("akri.sh/zeroconf")))'
{
  "akri.sh/zeroconf-3c0a74": "0",
  "akri.sh/zeroconf-407949": "0",
  "akri.sh/zeroconf-52d084": "0",
  "akri.sh/zeroconf-5b22aa": "0",
  "akri.sh/zeroconf-772363": "0",
  "akri.sh/zeroconf-8e12f9": "0",
  "akri.sh/zeroconf-90d0fb": "0",
  "akri.sh/zeroconf-f1acf2": "0",
  "akri.sh/zeroconf-f4738e": "0"
}

The Akri device_plugin_service "loop" appears to function correctly.
Here's the sockets:
ls -l /var/lib/kubelet/device-plugins/
total 4
-rw-r--r-- 1 root root    0 Jan  6 18:21 DEPRECATION
srwxr-xr-x 1 root root    0 Jan  6 18:21 kubelet.sock
-rw------- 1 root root 2876 Jan  6 18:38 kubelet_internal_checkpoint
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-52d084-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-8e12f9-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-90d0fb-1609957962.sock
srwxr-xr-x 1 root root    0 Jan  6 18:32 zeroconf-f1acf2-1609957962.sock

Monitoring the Agent's logs:
kubectl logs --follow pod/akri-agent-daemonset-nk8vf | grep "Sleeping\|Sending"
[2021-01-06T18:33:46Z TRACE agent::util::device_plugin_service] Sleeping
[2021-01-06T18:33:46Z TRACE agent::util::device_plugin_service] Sleeping
[2021-01-06T18:33:46Z TRACE agent::util::device_plugin_service] Sleeping
[2021-01-06T18:33:46Z TRACE agent::util::device_plugin_service] Sleeping
[2021-01-06T18:39:46Z TRACE agent::util::device_plugin_service] Sending
[2021-01-06T18:39:46Z TRACE agent::util::device_plugin_service] Sending
[2021-01-06T18:39:46Z TRACE agent::util::device_plugin_service] Sending
[2021-01-06T18:39:46Z TRACE agent::util::device_plugin_service] Sending

As soon as I saw the Sending, I rechecked the sockets (deleted as expected):
ls -l /var/lib/kubelet/device-plugins/
total 4
-rw-r--r-- 1 root root    0 Jan  6 18:21 DEPRECATION
srwxr-xr-x 1 root root    0 Jan  6 18:21 kubelet.sock
-rw------- 1 root root 2876 Jan  6 18:38 kubelet_internal_checkpoint

But no change to the .status entries:
kubectl get node/${NODE} --output=json \
| jq '.status.capacity | with_entries(select(.key|contains("akri.sh/zeroconf")))'
{
  "akri.sh/zeroconf-3c0a74": "0",
  "akri.sh/zeroconf-407949": "0",
  "akri.sh/zeroconf-52d084": "0",
  "akri.sh/zeroconf-5b22aa": "0",
  "akri.sh/zeroconf-772363": "0",
  "akri.sh/zeroconf-8e12f9": "0",
  "akri.sh/zeroconf-90d0fb": "0",
  "akri.sh/zeroconf-f1acf2": "0",
  "akri.sh/zeroconf-f4738e": "0"
}
kubectl get node/${NODE} --output=json \
| jq '.status.allocatable | with_entries(select(.key|contains("akri.sh/zeroconf")))'
{
  "akri.sh/zeroconf-3c0a74": "0",
  "akri.sh/zeroconf-407949": "0",
  "akri.sh/zeroconf-52d084": "0",
  "akri.sh/zeroconf-5b22aa": "0",
  "akri.sh/zeroconf-772363": "0",
  "akri.sh/zeroconf-8e12f9": "0",
  "akri.sh/zeroconf-90d0fb": "0",
  "akri.sh/zeroconf-f1acf2": "0",
  "akri.sh/zeroconf-f4738e": "0"
}

Since the deallocate KEP (https://github.com/kubernetes/enhancements/issues/3162) which might provide better node cleanup is still underway, i think it is worth reopening this and providing a daemonset that users can apply across their Akri nodes to clean up no longer existing resources. Or discuss a way to enhance the agent to remove the node level resources but that may be too privileged


Drawings disappear on map re-render (react-map-gl/maplibre)

When rendering just terra-draw and using memo its all good, but when I add a second children (markers) to render in map it causes  the map to re-render whenever the markers change and then all drawn items dissapear.
A simple setup for me looks like this:
const { setEstates, estates, currentEstate } = useContext(ExplorePageContext);
const [geoJson, setGeoJson] = useState<FeatureCollection[]>([]);

  const drawings = useMemo(() => {
    return <TerraDrawing geoJson={geoJson} onFinish={handleGeoJsonChange} />;
  }, [geoJson]);

  const markers = useMemo(() => {
    return <Markers items={estates} />;
  }, [estates]);

  return (
     <GlMap>
          {drawings}
          {markers}
       </GlMap>
   )

Then after the drawn items dissappear and I try to draw something on map, when i click the map i get :
Unhandled Runtime Error
TypeError: Cannot read properties of undefined (reading 'setData')

Call Stack
a._setGeoJSONLayerData
node_modules/terra-draw/dist/terra-draw.modern.js (1:15369)
eval
node_modules/terra-draw/dist/terra-draw.modern.js (1:17641)

Here is how the GlMap looks like:
import React, { memo } from "react";

import "maplibre-gl/dist/maplibre-gl.css";

import Map, {
  NavigationControl,
} from "react-map-gl/maplibre";

const GlMap = memo(({ children }) => {
  console.log("MAP RENDER");

  const mapStyle = {
    version: 8,
    sources: {
      osm: {
        type: "raster",
        tiles: [
          "https://tiles.stadiamaps.com/tiles/alidade_smooth_dark/{z}/{x}/{y}.png",
        ],
        tileSize: 256,
        attribution: "© OpenStreetMap Contributors",
        maxzoom: 19,
      },
    },
    layers: [
      {
        id: "osm",
        type: "raster",
        source: "osm",
      },
    ],
  };

  return (
    <Map
      initialViewState={{
        latitude: 56.948719,
        longitude: 24.108638,
        zoom: 10,
      }}
      mapStyle={mapStyle}
      attributionControl={false}
    >
      {children}
      <NavigationControl showCompass={false} position={"bottom-right"} />
    </Map>
  );
});

export default GlMap;

Here is TerraDrawing
import terraDrawSetup from "./terraDrawSetup";
import { useEffect, useRef, useState } from "react";
import { useMap } from "react-map-gl/maplibre";
import { TerraDraw } from "terra-draw";
import bbox from "@turf/bbox";

import { Switch } from "~/ui/switch";

const TerraDrawing = ({ geoJson, onFinish }) => {
  const [isDrawing, setIsDrawing] = useState(false);

  const { current: map } = useMap();
  const drawRef = useRef<TerraDraw>(null);

  const m = map?.getMap();

  const AddFeatures = () => {
    if (drawRef.current && geoJson && geoJson.length > 0) {
      drawRef.current.addFeatures(geoJson);
    }
  };

  useEffect(() => {
    console.log("load");
    if (!drawRef.current) {
      if (!m) return;

      const draw = terraDrawSetup(m);

      if (!draw) return;

      // draw.setMode("select");
      draw.start();
      draw?.on("finish", (ids: string[]) => {
        console.log("finish", ids);
        const features = draw?.getSnapshot();
        console.log("features", features);
        onFinish(features);
      });

      draw.setMode("polygon");
      drawRef.current = draw;
    }
  });

  useEffect(() => {
    AddFeatures();
  }, []);

  return (

      Edit
      <Switch
        checked={isDrawing}
        onCheckedChange={() => setIsDrawing(!isDrawing)}
        className="text-white focus:outline-none"
      />
      {/* {JSON.stringify(geoJson)} */}
      Draw

  );
};

export default TerraDrawing;

Here is terraDrawSetup:

import {
    TerraDraw,
    TerraDrawMapLibreGLAdapter,
    TerraDrawSelectMode,
    TerraDrawPolygonMode,
} from "terra-draw";

import { MapLibreGL as lib } from "maplibre-gl";

const terraDrawSetup = (map) => {
    if (!map) {
        return
    }

    // Create Terra Draw
    const draw = new TerraDraw({
        // Using the MapLibre Adapter
        adapter: new TerraDrawMapLibreGLAdapter({ map, lib }),

        // Add the Rectangle Mode
        modes: [
            new TerraDrawPolygonMode(),
            new TerraDrawSelectMode({
                flags: {
                    polygon: {
                        feature: {
                            // The entire Feature can be moved
                            draggable: false,

                            // Individual coordinates that make up the Feature...
                            coordinates: {
                                // Can be added
                                midpoints: true,

                                // Can be moved
                                draggable: true,

                                // Can be deleted
                                deletable: true,
                            },
                        },
                    },
                },
            }),
        ],
    });

    return draw;
};

export default terraDrawSetup;

Im assuming that somewhere down the line the reference is lost because the map is re-rendered. Has anyone got such a problem before? How can I maybe fix it? Thanks

Hey @marisancans - I think your issue is to within your usage of React then with Terra Draw itself. Let me see if I can try and point you in the right direction.
It's hard to pin point exactly where the error you posted is arising from but if you want to see a working implementation with React, checkout the Terra Draw website code, specifically this file: https://github.com/JamesLMilner/terra-draw-website/blob/main/src/routes/home/index.tsx
I would probably suggest following that pattern of using useMemo rather than useRef here. The code you have with the useEffect will run every single render, which is unnecessary and is probably leading to the bug you're seeing.
This block is also suspicious, as it will only run once (empty dependency array) but there is no guarantee the map or Terra Draw instance is ready at that point in time:
  useEffect(() => {
    AddFeatures();
  }, []);

Instead, you probably want something closer to:
  const draw = useMemo(() => {
    if (map) {
      const terraDraw = setupDraw(map, L);
      terraDraw.start();
      return terraDraw;
    }
  }, [map]);

  useEffect(() => {
     if (draw && geoJson && geoJson.length > 0) {
      draw.addFeatures(geoJson);
    }

    // So that the original features are removed when the component is unmounted/the geojson changes
    return () => {
         draw.removeFeatures(geoJson.features.map((feature) => feature.id));
    }
  }, [terraDraw]);

Hope this helps!

Hey, I refactored a lot based on your examples, thanks. It was still not working for me so I dig deeper.
Looks like react strict mode is causing a double render even on useMemo
const draw = useMemo(() => {
  var terraDraw: TerraDraw | null = null;

  if (m) {
    console.log("SETUP DRAW");
    terraDraw = setupDraw(m);
    terraDraw.start();
    terraDraw.setMode("polygon");
    setDrawInitialized(true);
    return terraDraw;
  }

  return null;
}, [m]);

This memo is called twice, I don't want to disable strict mode because it just seems like a dirty fix and overall should not be disabled in development mode. Is there any ideas on how to handle it?

Thanks for the update - unfortunately it's hard to debug without a live environment like CodeSandbox etc. I am just looking through the code, a few thoughts:

Need to ensure the draw instance hasn't already been set
Need to check if the features haven't already been added (using featuresAdded to track this) otherwise will try and add the features multiple times
Need to check if Terra Draw is enabled before calling removeFeatures

This would be my changes, although I haven't run them:
import setupDraw from "./terraDrawSetup";
import { useEffect, useRef, useState, useMemo, useCallback } from "react";
import { useMap } from "react-map-gl/maplibre";
import { TerraDraw } from "terra-draw";
import { GeoJSONStoreFeatures } from "terra-draw/dist/store/store";
import bbox from "@turf/bbox";

import { Switch } from "~/ui/switch";

const TerraDrawing = ({ geoJson, onFinish }) => {
  const [isDrawing, setIsDrawing] = useState(false);
  const [mode, setMode] = useState<string>("static");

  const [selected, setSelected] = useState<GeoJSONStoreFeatures | undefined>();
  const [features, setFeatures] = useState<GeoJSONStoreFeatures[]>([]);

  const [drawInitialized, setDrawInitialized] = useState(false);

  const [featuresAdded, setFeaturesAdded] = useState(false);

  const { current: map } = useMap();

  const m = map?.getMap();

  const draw = useRef<TerraDraw | null>(null);

  useEffect(() => {
    if (m && !draw.current) {
      console.log("SETUP DRAW");
      const terraDraw = setupDraw(m);
      terraDraw.start();
      terraDraw.setMode("polygon");
      setDrawInitialized(true);
      draw.current = terraDraw;
    }

    return () => {
      if (draw.current) {
        draw.current?.stop();
      }
    };
  }, [m]);

  const changeMode = useCallback(
    (newMode: string) => {
      if (draw) {
        const mode = isDrawing ? "polygon" : "select";
        draw.current?.setMode(mode);
      }
    },
    [draw]
  );

  useEffect(() => {
    draw.current?.on("change", () => {
      const snapshot = draw.current?.getSnapshot();
      if (snapshot) {
        setFeatures(snapshot);
        setSelected(snapshot.find((f) => f.properties.selected));
      }
    });
  }, [draw]);

  useEffect(() => {
    if (!featuresAdded && draw.current && geoJson && geoJson.length > 0) {
      draw.current?.addFeatures(geoJson);
      setFeaturesAdded(true);
    }

    // So that the original features are removed when the component is unmounted/the geojson changes
    return () => {
      if (draw.current && draw.current.enabled) {
        draw.current?.removeFeatures(geoJson.map((feature) => feature.id));
      }
    };
  }, [draw, geoJson]);

  return (

      Edit
      <Switch
        checked={isDrawing}
        onCheckedChange={() => setIsDrawing(!isDrawing)}
        className="text-white focus:outline-none"
      />
      {/* {JSON.stringify(geoJson)} */}
      Draw

  );
};

export default TerraDrawing;

Hope this helps!

@JamesLMilner Is it ok if I prepare a repo that has devcontainer setup in it? I i'm always working in VScode devcontainer and it gives a great 1:1 sandboxed environment

@marisancans yes sure! That would work fine for me. I'll do my best to assist

This should work in devcontainer out of the box, if something is not working for you i will fix it.
https://github.com/marisancans/terra-draw-help
Here is how I usually do stuff:
ctrl+shift+p openns command pannel and choose "Devcontainers: Rebuild and Reopen in Container"

Create javascript terminal (so you can use breakpoints)

Run: $ npm i
Run: $ npm run dev
Launch web page

Some info on repo
This is a trimed down version of my original repo (so there is less clutter)
This is where fake api call is generated:

I hope you have some spare time to check where the problem could be and maybe upgrade guides for next batch of users?

Hey @marisancans - I really appreciate you effort, but unfortunately it was too complex to set up the repo you provide in the limited time I have available this weekend. I'm sorry about that. However, I do really want to help you, so I've set up a really simple stripped back repo which you should be able to follow along with. It covers adding features works as expected and shows how you can do it reactively.
Here it is:
https://github.com/JamesLMilner/terra-draw-react-help
You can see why pass in the geojson from the parent component:
https://github.com/JamesLMilner/terra-draw-react-help/blob/main/src/components/app.tsx
Then we have a useEffect which triggers a setTimeout after 5 seconds, it changes the features.
The child component is able to re-render them fine with no errors:
https://github.com/JamesLMilner/terra-draw-react-help/blob/main/src/routes/home/index.tsx
I think if you are able to match this pattern is should all work okay! Let me know how you get on?

I haven't heard back in a while so going to close this for now. Feel free to reopen with any new questions you might have.


Roundtrip strings

Turns out graphql doesn't support escaped strings. This makes it do so by re-using Aeson's code, on the assumption that GraphQL strings are identical to JSON strings.

LGTM, had a slight rewrite of string parser but doesn't matter this works fine (must resist fiddling!)

Will merge now, but curious as to the gist of this.


Request to declare static entry for those runtime-declare global variable

For the global "variable" defined during runtime, like zmq.REP or zmq.REQ, or some functions.
It would be nice to define a static "placeholder" in static for example zmq.REP = None, or some other number. It would be very convenient for static checking and IDE auto-complete.

I never invested time into this, but I can confirm that in PyCharm, whenever I inspect my code it complains about zmq.REQ and zmq.REP. If a placeholder as suggested above fixes it, without causing any issue for pyzmq developers, I'm +1 for that.
Thanks

Here are ways of suppression for 2 IDEs; These don't help auto-complication, though.
For PyCharm
# noinspection PyUnresolvedReferences
from zmq import REP

# noinspection PyUnresolvedReferences
print(zmq.REP)

For Eclipse+PyDev.
from zmq import REP  # @UnresolvedImport

print(zmq.REP)  # @UndefinedVariable

Universal but dirty way
from zmq import REP  # noqa

print(zmq.REP)  # noqa

P.S. VSCode doesn't seem to claim anything and I don't use Visual Studio.


Translations inside Bootstrap.php in multi-language websites

I have a multilanguage website I use https://github.com/codemix/yii2-localeurls to handle the languages. But I check that the subject of registration emails or recovery password emails are allways sent in the default language of the website.
I do some debugs and if I put something like this inside Bootstrap.php
\Yii::$app->session->setFlash('success', "bootstrap language: ".\Yii::$app->language);

I always get the default language instead of the current language selected by the user. Any quick fix for this?

I don't think that yii2-user is compatible with that extension at the moment. I'll try to do my best to fix this.

Fixed!


A,B,C -> X,Y,Z

As @tballmsft suggested, we could rename variables to X,Y,Z to avoid confusion with button names.

https://github.com/microsoft/microcode/pull/260


Doesn't seem to address repos NOT on an Asure DevOps server???

[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 22f31dd7-e676-aa47-cb11-8ad77412fb5a
Version Independent ID: 6cce7a4b-8f62-610d-f75f-fafc7b4c444a
Content: Connect to projects in Team Explorer - Visual Studio
Content Source: docs/ide/connect-team-project.md
Product: visual-studio-windows
Technology: vs-ide-general
GitHub Login: @TerryGLee
Microsoft Alias: tglee

@kehollin Thanks for contacting us. To answer your inquiry, we do support connecting to repos that are not hosted on Azure DevOps. The first paragraph on the page says "Team Explorer connects Visual Studio to Git and GitHub repositories, Team Foundation version control (TFVC) repositories, and projects hosted on Azure DevOps Services or an on-premises Azure DevOps Server (formerly known as TFS)." Notice that the words "Git and GitHub repositories" are the first type of repos that are listed.
Granted, the UI in Visual Studio does highlight Hosted Services Providers such as Azure DevOps at the top of the Team Explorer-Connect dialog, but right below that in the UI is a section that says "Local Git Repositories". To make this functionality more clear, I've added a link to the "See also" section of this Connect to projects in Team Explorer page to our "Open a project from a repo" tutorial, which includes an "Open a project from a GitHub repo" section.
We'll close this issue for now, with our thanks to you for helping us improve the documentation!
~ Terry
p.s. We are working on new Git functionality in the product, currently in Preview if you'd like to try it out. You can read more about it in the following blog post, Improved Git Experience in Visual Studio 2019. As an FYI: After this feature is out of Preview, we'll update all our Docs pages to reflect the new experience.


Publish to a local repo for samples

I couldn't figure out how to make includeBuild() work for metadata tasks.

Oh damn.
Let me try to land #297 really quickly. That will allow moving the samples into the same project as all of the others and only using includeBuild for the Gradle plugin (which is just a pure JVM project and works fine). I have it like 90% done on a branch I just didn't finish before Droidcon NYC.

That’d be perfect. Yes please.

It works! I just need a little time to polish, but thankfully it's the weekend.

Will solve this problem with https://github.com/cashapp/redwood/pull/375 instead


Examples in README don't work

(ns my.namespace
 (:require [io.github.humbleui.ui :as ui]))

(def ui
  (ui/default-theme
   {}
   (ui/center
    (ui/label "Hello world!"))))

fails with

class clojure.lang.Delay cannot be cast to class clojure.lang.IFn

It looks like ui/label is a delay, not a function.

I guess this is probably because I tried to add this project as a library to an existing one like
{:deps {io.github.HumbleUI/HumbleUI  {:sha "1262a11124845045feb88a70b3dad3c2b0b877cd"}}}

I didn't realize this was unsupported

Yep, sorry about that. I updated README


fixed the documentation of the RETURN VALUES section

for the following functions.
EC_GROUP_get_order
EC_GROUP_get_cofactor
EC_GROUP_get_curve_name
EC_GROUP_get_asn1_flag
EC_GROUP_get_point_conversion_form
EC_GROUP_get_degree

Checklist

[x] documentation is added or updated

Thanks @jayaram-intel, I am finally getting to review this.
I noticed only now that the previous PRs addressing this were opened by user @vilvarajintel (#9195 and previously #8847).
Are you working together on this?
I need to know because it would ease the review process if we managed to apply your latest changes on top of #9195 so that we can keep working on the previous feedback and keep working incrementally on the review until the PR is ready for a final review.
In case you are both working together on the issue I would suggest to close this PR and rebase your changes on top of #9195.
I can provide guidance on git workflow to achieve this, given that there were issues in #8847

Hi @romen ,
Previously @vilvarajintel Opened PRs (#9195 and previously #8847) and he suggested me to apply the required changes on top of #9195.
This PR #9664 will contain all required/suggested changes, Please suggest in case if I missed anything.
Note:
He faced some issues with #8847 that is why he raised another PR #9195.
Please Let me know if required I will close PRs #9195 and #8847
Thanks
Jayaram Matta

Ok, please then close the previous PRs and please address all the feedbackon top of this PR (#9664).
I will now go through the feedback in the previous PR and add here the relevant comments.

Hi @romen ,
Both previously created PRs(#9195 and #8847) are closed.

May I suggest a commit message change?  The first line is a bit broad:

fixed the documentation of the RETURN VALUES section

It would be nice to make it a little bit more specific:

fixed the RETURN VALUES section in the EC_GROUP documentation

Hi @romen and @levitte ,
Commit message changed, Please review now.

Hi @romen ,
Based on @levitte suggestions modified commit message.
Please review now.
Thanks
Jayaram Matta

Hi @mattcaswell ,
Based on your suggestion modified EC_GROUP_get_curve_name() return values section, Please review now.
Thanks
Jayaram Matta

Hi @romen ,
Made couple of changes, Please suggest incase if I missed anything to modify.
Thanks
Jayaram Matta

@mattcaswell @mspncp should we enforce the 80 char limit also on .pod files?
Are there other new formatting recommendations I should be checking for?

Not commenting on the 80char limit, although the source code exceeds that occasionally when legibility is more important:
; g ls-files | fgrep .c | xargs awk '{if (length>80) {print;}}'  | wc -l
1619

Make sure make doc-nits passes.  It should be part of everyone's dev build; it only takes a couple of seconds and avoids an extra, costly, CI round-trip

I don't think we have a formal rule about 80 char limit, although I do try and ensure that is the case in anything I produce, and I think its a good idea. Not sure how well our current pods conform to that though.

Hi @romen ,
Based on your suggestions and inputs made couple of changes, Please suggest in case if I missed anything to modify.
Thanks
Jayaram Matta

g ls-files | fgrep .c | xargs awk '{if (length>80) {print;}}'  | wc -l

@richsalz this command line is really remarkable. What I find even more astonishing than the fact that someone still uses awk (me too) is the fact that you seem to have an 'alias g=git' ;-)

As a side note, @jayaram-intel , of course you had to force-push to change the commit message and that's perfectly fine, but for follow-up changes it would be better to use git commit --fixup rather than amending and force pushing.
It makes reviews easier, and the committer can easily take care of squashing all the commits together in the end when the PR is ready to be merged using git rebase -i --autosquash.

Hi @romen ,
Based on your suggestions and inputs made couple of changes, Please suggest in case if I missed anything to modify.

I know I gave you a lot of extra tasks not strictly necessary to approve this PR, and we all really appreciate how much efforts you are putting into this @jayaram-intel , but would it be too much to ask you to add this function to the synopsis and go through this file once more to see if there are other entries missing in that section?

feel free to share your valuable comments and suggestions regarding this PR and please assign any other pending issues/documentation tasks, from my side I am always ready to work on it.
Thanks
Jayaram Matta

Hi @romen ,
Please review the changes.
Thanks
Jayaram Matta

Hi @romen ,
EC_GROUP_get_degree() is already present in SYNOPSIS section.
Please look at line number 51
int EC_GROUP_get_degree(const EC_GROUP *group);
Thanks
Jayaram Matta

EC_GROUP_get_degree() is already present in SYNOPSIS section.
Please look at line number 51

@jayaram-intel you are right, please discard my previous comment, I was evidently distracted!

Merging this now!

Merged:

df3d1e84b3802acffeec11d6224e8a0e33d0aa83 in master
24c23e1f3cd807dbf7e6a057dc01b435703d05b4 on 1.1.1

The latter required trivial changes, as the base in master included changes not backported to 1.1.1 that replaced the occurrences of builtin with built-in and caused a merge conflict.
Thanks once again @jayaram-intel for all the efforts you put into this and congrats on another successfully merged PR!


What is the black magic behind "Off-chip memory used for streaming uncached model parameter"?

What is the black magic behind "Off-chip memory used for streaming uncached model parameter"?
Edge TPU Compiler version 15.0.340273435

Model compiled successfully in 1379 ms.

Input model: model.tflite
Input size: 4.41MiB
Output model: model_edgetpu.tflite
Output size: 5.49MiB
On-chip memory used for caching model parameters: 1.92MiB
On-chip memory remaining for caching model parameters: 1.75KiB
Off-chip memory used for streaming uncached model parameters: 3.23MiB
Number of Edge TPU subgraphs: 1
Total number of operations: 136
Operation log: model_edgetpu.log

Model successfully compiled but not all operations are supported by the Edge TPU. A percentage of the model will instead run on the CPU, which is slower. If possible, consider updating your model to use only operations supported by the Edge TPU. For details, visit g.co/coral/model-reqs.
Number of operations that will run on Edge TPU: 135
Number of operations that will run on CPU: 1

Operator                       Count      Status

RESHAPE                        15         Mapped to Edge TPU
CONCATENATION                  3          Mapped to Edge TPU
MAX_POOL_2D                    3          Mapped to Edge TPU
ADD                            10         Mapped to Edge TPU
CUSTOM                         1          Operation is working on an unsupported data type
CONV_2D                        73         Mapped to Edge TPU
DEPTHWISE_CONV_2D              29         Mapped to Edge TPU
LOGISTIC                       2          Mapped to Edge TPU

Another curiosity. This model is made of two other tflite models in parallel (two inputs). However, if I compile the models for shared cache (using the original two tflite files), depending on the order it changes the amount of "Off-chip memory used for streaming uncached model parameters" assigned to each model.
P.S.: when I compile the models individually, this is the result for any of the models:
Off-chip memory used for streaming uncached model parameters: 0.00B

Originally posted by @ricardodeazambuja in https://github.com/google-coral/edgetpu/issues/324#issuecomment-882107646

Hi, please refer to this link : https://coral.ai/docs/edgetpu/compiler/#co-compiling-multiple-models

Hi @hjonnala,
Thank you for your reply, but I understand the compiler will off load stuff if there isn't enough memory. My problem is that I want to understand how to get the best of it. It seems the compiler has limits that go beyond simply "amount of memory", and the type / order / number of ops used will play a role as well. However, Google does NOT document these details making me think the EdgeTPU will follow other Google products and become vaporware sooner than later.
Could Google add a debug mode for the compiler that would give more details to allow the user to optimize / fix things????

Hi, Please check new compiler version. Changes have been made to help the users to know more about the errors.

@ricardodeazambuja Compiler version 16 has better error reporting. You can see the detailed changes at https://coral.ai/news/updates-07-2021.

@manoj7410, thank you for your reply. My problem is that I don't get an error, I just don't know how to improve / optimize the model. Is there a way to get more info about the "Off-chip memory" than what I get below?
Edge TPU Compiler version 16.0.384591198
Started a compilation timeout timer of 180 seconds.

Model compiled successfully in 1382 ms.

Input model: model.tflite
Input size: 4.41MiB
Output model: model_edgetpu.tflite
Output size: 5.47MiB
On-chip memory used for caching model parameters: 1.80MiB
On-chip memory remaining for caching model parameters: 512.00B
Off-chip memory used for streaming uncached model parameters: 3.39MiB
Number of Edge TPU subgraphs: 1
Total number of operations: 135
Operation log: alpr_full_edgetpu.log

Operator                       Count      Status

LOGISTIC                       2          Mapped to Edge TPU
CONV_2D                        73         Mapped to Edge TPU
DEPTHWISE_CONV_2D              29         Mapped to Edge TPU
CONCATENATION                  3          Mapped to Edge TPU
MAX_POOL_2D                    3          Mapped to Edge TPU
RESHAPE                        15         Mapped to Edge TPU
ADD                            10         Mapped to Edge TPU
Compilation child process completed within timeout period.
Compilation succeeded!


Query Building

Hi
Is there a simple way to query the database with complicated "finders" than the ones shows in the "Extra sugar" example ? For example, how does one find objects which satisfy criteria over different member variables ? On a related note... are you planning to add query building features like this in another android orm
http://greendao-orm.com/documentation/queries/
Any help you provide is much appreciated.
Thank You

does sugar ORM support query like this
elect PRODUCT from PRODUCT_TAGS where TAGS = 1 intersect Select PRODUCT from PRODUCT_TAGS where TAGS = 5;   how do i pass this using sugar orm . @satyan @whoshuu @homer123 @tobykurien @allieus please can some one help me .


Gallery throws exception on search requests that contain "toLower"

Microsoft.Data.OData.ODataException:
at Microsoft.Data.OData.Query.FunctionCallBinder.BindAsBuiltInFunction (Microsoft.Data.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.Data.OData.Query.FunctionCallBinder.BindFunctionCall (Microsoft.Data.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.Data.OData.Query.MetadataBinder.Bind (Microsoft.Data.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.Data.OData.Query.BinaryOperatorBinder.GetOperandFromToken (Microsoft.Data.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.Data.OData.Query.BinaryOperatorBinder.BindBinaryOperator (Microsoft.Data.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.Data.OData.Query.MetadataBinder.Bind (Microsoft.Data.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.Data.OData.Query.FilterBinder.BindFilter (Microsoft.Data.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.Data.OData.Query.ODataUriParser.ParseFilterImplementation (Microsoft.Data.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at System.Web.Http.OData.Query.FilterQueryOption.get_FilterClause (System.Web.Http.OData, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at NuGetGallery.OData.SearchHijacker.IsHijackable (NuGetGallery, Version=3.0.2123.0, Culture=neutral, PublicKeyToken=null)
at NuGetGallery.Controllers.ODataV2FeedController+d__5.MoveNext (NuGetGallery, Version=3.0.2123.0, Culture=neutral, PublicKeyToken=null)

I think this is actually user error. From what I can tell, the correct OData function to use in queries is tolower (notice the lowercase). People seem to be accidentally writing queries with toLower instead. I can see why--it's odd that the actual function is not camelcase so I can believe the confusion--but my understanding of OData is rather slim so I may be wrong.

I thought we added a few lines to fix this one?

The fix didn't work. Scott, the comparison in the hijacker is not key sensitive.

I can have a look tomorrow if you want, may need to check for a different condition.

So I checked what's going on, and Scott is right, it's an illegal OData query, and the customer is getting a 400 reply, which is good (bad request). The only issue I see with the current behavior, is that we get alerts and log exceptions because of this. Ideas?

Is there a way we could wrap exceptions from user OData queries and then fail gracefully while still returning 400?

So this is a valid Exception? If yes, we should catch it, return 400 and not log it to AI.

Fixed it, see related PR :-)


Add support for offline collection installs

This rebuilds our Containerfile to support offline collection installs.
Something we will need for pre-merge testing.
Depends-On: https://github.com/ansible/ansible-builder/pull/180
Signed-off-by: Paul Belanger<EMAIL_ADDRESS>

Pull-request updated, HEAD is now bc57d2f68ddf00061c61858bd0d382f8922e938f

Pull-request updated, HEAD is now bc57d2f68ddf00061c61858bd0d382f8922e938f

Pull-request updated, HEAD is now 7e9346b21ba8e0b01a55a3bdb9f80f8390bd47fa

Pull-request updated, HEAD is now 7e9346b21ba8e0b01a55a3bdb9f80f8390bd47fa

Pull-request updated, HEAD is now 21e0428d56a416c54ca9167c84d5c38ab7200418

Pull-request updated, HEAD is now 21e0428d56a416c54ca9167c84d5c38ab7200418

Pull-request updated, HEAD is now 4e72278d5675e63402d331dae276f544103e4ee5

Pull-request updated, HEAD is now 4e72278d5675e63402d331dae276f544103e4ee5

Pull-request updated, HEAD is now 638354d49fa097b20b454e679f3b6fcfb9a80e61

Pull-request updated, HEAD is now 638354d49fa097b20b454e679f3b6fcfb9a80e61

Pull-request updated, HEAD is now b45f14f23da691fb008c3382b338dfe42dbe619c

Pull-request updated, HEAD is now b45f14f23da691fb008c3382b338dfe42dbe619c

Pull-request updated, HEAD is now 10fed7c9de506d0ef905278a11dc7f7f2c8ca7ad

Pull-request updated, HEAD is now 10fed7c9de506d0ef905278a11dc7f7f2c8ca7ad

Pull-request updated, HEAD is now 6b60759b48a2f927535265f9bace0558d1df81de

Pull-request updated, HEAD is now 6b60759b48a2f927535265f9bace0558d1df81de

Pull-request updated, HEAD is now ec25cb99868cfa91fd48192c1cff9bc4d1b482c8

Pull-request updated, HEAD is now ec25cb99868cfa91fd48192c1cff9bc4d1b482c8

Pull-request updated, HEAD is now c59035212a478589011e828f510533744eaa6a6a

Pull-request updated, HEAD is now c59035212a478589011e828f510533744eaa6a6a

Pull-request updated, HEAD is now 74eb45181033542f091addd8f02a71414e4563e0

Pull-request updated, HEAD is now 74eb45181033542f091addd8f02a71414e4563e0

Pull-request updated, HEAD is now 6d09d12306223845e43fd752cfa939475af6bb51

Pull-request updated, HEAD is now 6d09d12306223845e43fd752cfa939475af6bb51

Pull-request updated, HEAD is now d4f3aaec75382a72d03fd0bb334d4ba0cd214fc6

Pull-request updated, HEAD is now d4f3aaec75382a72d03fd0bb334d4ba0cd214fc6

Pull-request updated, HEAD is now 872c672ae6d45cd56a21ca4768f92de3f917c42a

Pull-request updated, HEAD is now 872c672ae6d45cd56a21ca4768f92de3f917c42a

Pull-request updated, HEAD is now 2c6cce27a1d94341ff60c079d8eef7d13f26a27c

Pull-request updated, HEAD is now 2c6cce27a1d94341ff60c079d8eef7d13f26a27c

Pull-request updated, HEAD is now bdf3bfd33d528678db15a29e36c6e4d6c221648b

Pull-request updated, HEAD is now bdf3bfd33d528678db15a29e36c6e4d6c221648b

Pull-request updated, HEAD is now c377c40cd851c715dd687c93e985906b5ce27e59

Pull-request updated, HEAD is now c377c40cd851c715dd687c93e985906b5ce27e59

Pull-request updated, HEAD is now cbb9f95d0362e7aeb3d176c939c1f63133fb9f48

Pull-request updated, HEAD is now cbb9f95d0362e7aeb3d176c939c1f63133fb9f48

Pull-request updated, HEAD is now fced9f01a85858cca81bd78c2962d145efd963ee

Pull-request updated, HEAD is now fced9f01a85858cca81bd78c2962d145efd963ee


typescript module missing in definition files

Maybe I am blind, but I could not find a module declaration called "colyseus.js" anywhere in the package.
Wanted to use this library in my TS-project.
My workaround was to use a shorthand declaration. E.g.
declare module "colyseus.js";
But this will only import "any", even if it makes the project compile and works runtime.
I might have misunderstood how to import this library to my project, so please enlighten me in that case.

Hi @markokristian, can you provide more details about your environment and how are you building your project? I'd like to cover all possible scenarios.
AFAIK, if you're using "module": "commonjs" in your tsconfig.json, you should be able to import this module and use its type definitions out of the box:
import { Client, Room } from "colyseus.js";

Not going to support static type definitions, workaround here: https://github.com/gamestdio/colyseus.js/issues/18#issuecomment-353970650
Feel free to reopen this issue if you'd like to. Cheers!


Add renderSuggestion docs

Docs for https://github.com/appbaseio/reactivesearch/pull/530

The build is failing since at the last step travis attempts to deploy to gh-pages. This can be merged safely

This will be merged with v3.0.0 release of reativesearch.


Istio should consistently set transport socket match for headless services attached to ingress gateway

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
Hi folks,
We noticed the following behavior when an k8s headless service is attached to a istio gateway:

if all backends of the headless service have a sidecar, cds with transport socket match to do auto mtls is generated.
if atleast 1 backend of the headless service has no sidecar, cds with neither transport socket nor socket match is generated.

the drawback of doing so is that - istiod disables auto mtls for all backends of the service even if some of them do have a sidecar and can do mtls.
Considering that the cds cluster uses eds, istiod should just consistently generate cds cluster with transport socket match set. The transport socket match will take  care of doing mtls to endpoints with sidecar and plain text to services to not having sidecar.
We suspect this logic in istiod is causing this issue.
This logic is fine for mesh cases, however, for ingress seems less optimal.
Version
istio 1.19

Additional Information
No response

Perhaps you could declare two services, let the injection state of the instances under each service is consistent.
The connectivity behavior of the istio ingress gateway to upstream is configured using a cluster-level configuration, not endpoints.


AC term that corresponds to HTML img alt attribute?

Some colleagues and I are wondering if there are any conventions for what term in AC might correspond to an HTML alt attribute for an image. In a sense all of the Audubon Core fields are alt text, just way more detailed. But for automating accessibility of images (e.g. on the iDigBio or the GBIF website), is there a certain term that typically gets used that way. Maybe dcterms:description or ac:caption? Are you familiar with any examples in practice that use AC to generate HTML image attributes? I'm not sure whether answering this is in scope for the AC maintenance group or not, so feel free to tell me if it's not!

According to the documentation, ac:caption is displayed together with the resource, while dcterms:description is displayed instead of the resource. That would make that dcterms:description is used for alt attributes in img tags and ac:caption in figcaption elements. I think it would be good to add this to the documentation as an 'e.g.'.

This logic for dcterms:description makes sense to me, thanks, Niels!


Clean Up README.md

The current state of README.md is broken due to incorrect markdown table formatting. I have recreated this table in HTML for ease of use when rows are added down the line while preserving the language of the original version, among a few other syntactic changes. Let me know if this looks good! Thanks.

@microsoft-github-policy-service agree

Thank you so much for this fix!


Add ability to deploy EE sites

This reorganizes the Rails-specific recipes into their own rails subdirectory and adds a corresponding ee subdirectory to handle the ExpressionEngine-specific recipes.  This is mostly a migration from the copy/pasted Rake & Capistrano tasks from the vigetlabs/nea repository into a more reusable, modular approach.  Rather than carry forward the duplication, I opted to put the common components into a common Rakefile, and call Rake from Capistrano tasks.  Integration with an existing EE site is simple:
# Rakefile
load 'tasks/ee.rake'

Overall, this is great. Cool to have this in the gem. I like the namespacing, makes a lot of sense. Really dig abstracting the database operations into a separate class, super cool. Tighten up that code a bit and you have my :rabbit: :video_camera:

thanks bors


Remove extra word "the"

@andresnava : Thanks for your contribution! The author(s) have been notified to review your proposed change.


net/frr: (BGP) Configure ipv6 next-hop on route-map

according to the FRR documentation and the ui validations, match is optional (https://docs.frrouting.org/en/latest/routemap.html#term-Matching-Conditions). Likely fixes https://github.com/opnsense/plugins/issues/2955

This issue might be (partly) fixed as well by this PR.

Building configuration...


Fix minor issues in XML documentation comments

This fixes several minor issues in the code's documentation comments, such as spelling errors, missing punctuation and references to other code elements, and a few other small inconsistencies.
This commit deals only with fairly straight-forward stuff, but more could be done to clean up the XML documentation comments. See issue #1097 for more details.

Umm, I believe that build didn't fail because of any changes I made (which was only to code comments), but because of the unit test project (which appears to contain broken references to NUnit). I hope this is a known issue.

I'd be surprised if the CI build fails because of any of the changes in this pull request, since only code comments are affected. If there is something I need to do to resolve this build issue, please let me know.

I'll leave the more substantial changes to the new few days as they'll require more time and possibly some research how they document things on MSDN.

Looks good to me. Thanks for cleaning the comments up. A lot of embarrassing typos removed.

Beautiful


fix(css): fixed responisveness of examples page

Fixes #2857
Describe the changes you have made in this PR -
The CSS and component HTML was faulty I removed the circuit-card-footer class placed inside the components.scss and placed the example name and the tool tip inside the div with circuit-card-name class in the examples.html.erb file
Screenshots of the changes (If any) -
Changes upto resolution 1040 x 852
Note: Please check Allow edits from maintainers. if you would like us to assist in the PR.

Coverage remained the same at 81.774% when pulling 1df458d5ef2cd0297f1e63476fe43b28dc215a59 on Prakhargarg-2010196:example-page-responsive#2857 into 29f98c87dd976f9106968ec4277131127f5b9fe0 on CircuitVerse:master.


WorldMap: Add agility shortcut level requirements

Add the agility level requirement and obstacle type to all agility shortcut icons.
A huge thank you to @trimbe for their significant help on gathering the shortcut locations!

Closing because of rewritten history.


[Question] How can we access data from terraform module inside a terragrunt hcl file ?

Here is my hcl file:
terraform {
  source =<EMAIL_ADDRESS>}

locals = {
  config  = templatefile("./config.yml", { environment = {NEED HELP HERE } )]])
}

Inside the terraform module, I have a data that retrieve a value from our cloud provider. I would like to know if it is possible to use this data in order to file the variable required inside the templatefile ?
The only solution I have is to use an run_cmd in order to reproduce the behavior of the data block in the module.
Thanks for your help,
Have a great day.

This is not what I really want in fact. But I think it's not possible.
In fact, the hcl file I linked in the issue is used to manage dependency for the module between multiple others modules. This is why I was asking it the parent could use data from the terraform source but I don't think it's possible regarding your response.
I will use an run_cmd like I already did. It was just to find out if there was a better way to do it.

@axelczk -- I'm going to close this issue since it sounds like you got things working.


fixing lifetime of the ConnectionAutomaton

It is possible that ReactiveSocket class instance is destroyed by a user client call back. Eq. onComplete will tare down everything. In that case ReactiveSocket destructor was also taking down the ConnectionAutomaton instance which was executing the callback and had some more business to do. In order to stop this premature destruction of ConnectionAutomaton, it has to have independent lifetime from ReactiveSocket class. Also we need to make sure that all streams will be properly cleaned up when the ReactiveSocket instance is going away.

We need changes to automata as well, despite documentation saying so, there is no smart pointer to the Connection and automata currently assume that ConnectionAutomaton::endStream is idempotent... but it no longer is after your change.
@yschimke, @lehecka I have second thoughts. What is the use case? Destroying ReactiveSocket from, for example Channel's Subscriber::onComplete callback is equivalent(ish) to destroying ThriftServer from an RPC method, which guarantees a crash, last time I checked. This is more complicated change than in this PR, maybe we don't need it? I don't know :/

From the java and spec side there doesn't appear to be any limits on who or when you can shutdown a reactivesocket. e.g. shutdown method in https://github.com/ReactiveSocket/reactivesocket-java/blob/master/src/main/java/io/reactivesocket/ReactiveSocket.java

I absolutely agree that it would be ideal to make any code allowed by compiler not crash, but it's hard in C++, hence the question. :)
Point taken though, since you've written a code that triggers unsupported shutdown sequence, we have a use case for this...

@lehecka Do you mind if I experiment with plain old shared_ptr here?
I remember saying yesterday (in an offline conversation) that there is something wrong with using it, but I haven't taken into account that there is no flow control between stream automata and ConnectionAutomaton. That actually simplifies things a lot, as spontaneous communication is unidirectional.

Actually, the docs even say it's idempotent https://github.com/ReactiveSocket/reactivesocket-cpp/blob/master/reactivesocket-cpp/src/ConnectionAutomaton.h#L89. I will make sure this holds true in my experiment. I don't want to overcomplicate stream automata.


Add global carbon budget

Add Meadow, Garden and Grapher steps for Global Carbon Budget data.
The resulting dataset contains all variables from the old importers gcp_gcb dataset, plus the additional variables from this ETL step, plus some new variables given in the data (national land-use change emissions).
@edomt if you have a few minutes, could you please check the garden metadata file? (etl/steps/data/garden/gcp/2022-11-11/global_carbon_budget.meta.yml) There's no need to go line by line, which would take a long time, but simply check some entries at random to search for any possible inconsistencies (since filling up the metadata was a semi-manual process). Thanks.
TODO: Before merging this PR, the following steps need to be completed:

[ ] Merge https://github.com/owid/walden/pull/127 (until that one is merged, CI in this PR will fail)

Thanks @pabloarosado! I've checked 10 entries at random:

global_cumulative_emissions_from_gas has an empty description, as well as several other entries above and below it – I'm not sure if this is expected.
Same for consumption_emissions_as_share_of_global
The title of the global cumulative variables takes the form of Global annual cumulative CO2 emissions from <x>. Given that these are cumulative, we should drop the annual for clarity.
land_use_change_quality_flag has the wrong units (tonnes and t). It should probably have empty units.

Thanks a lot @edomt . "Global" variables are not used anywhere. I just added them because, in the garden dataset, it may be useful to have them as reference on how “share” variables were calculated. But they are actually a bit redundant. So I’ve left them without a description. Regarding the other suggestions, in the last commit I have:

Fixed wrong units (of GDP and land-use quality flag).
Changed “global annual cumulative” to “global cumulative”.
Changed CO2 to CO₂.
Removed “Global coal emissions include all country emissions” (and idem for other sources). We had this sentence in the variable descriptions of the previous release, but I don’t think it makes much sense. Global emissions from coal do not include all country emissions (they include only emissions from coal). Maybe it was meant to say “all countries emissions”. I found the sentence confusing, so I’ve removed it from all descriptions.

Thanks @bnjmacdonald for review and suggestions!


netrw split-view focus problem

I'm having trouble with split pane focus when already having a file open and opening netrw in a newly opened split pane.  The first split pane is given focus and won't let me switch to the other pane.  Orientation of the panes doesn't matter.
I've narrowed it down to it breaking in 7.4 snapshot 79 while snapshot 77 works just fine.  I am using the binaries, not compiling from source.
Steps to recreate

Open a file
Create a new split using ctrl-w, v, :vsp, :sp.  Whatever pleases you.  :smile:
use :Explore to open a netrw view in the new split pane
Focus should now be in the split pane containing the file you originally opened.  switching to the new pane will not accept focus.  Clicking in the pane, keyboard commands, nothing works.

I've been able to recreate this in a brand-spanking-new install of MacVim 7.4 (79).  No customizations, nothing in a .vimrc, etc.  Snapshot #77 uses netrw v153 while #79 is using netrw v154.
I found this stackoverflow post that sounds a little like the issue but they're able to open a file in the new Explore pane while I can't even switch focus.  The solution in there was to download a more recent version of netrw from Dr. Chip but that didn't solve it for me.  I tried Dr. Chip's v155f from November 23, 2015.
Thoughts?
(e)

Have you tried Vim in Terminal.app?
https://github.com/macvim-dev/macvim/wiki/Troubleshooting#test-the-original-vim

I'm having the same problem. Seems to be an issue with vim (not macvim specifically), and hasn't been fixed there as far as I can tell. See https://github.com/vim/vim/issues/484

ok, I close it because it is Vim issue.

Yeah, confirmed.  brew-installed vim v7.4 with patches 1-963 has the same issue.  So uninstalling that and sticking with MacVim 7.4 (77) is the solution for now I guess.
(e)


Increase time to try and get vault tunnel connection

What this PR does / why we need it:
I span up a hub cluster and got no vault tunnel was ready and exited with error. The vault instances came up fine, it just needed a bit more time to try before it was ready. This increases the vault tunnel tries from an optimistic 1 sec * 60 to every 5 sec * 60
NONE

/assign @simonswine

/approve
/lgtm


Fix ign server -s on Windows (take two)

Re-do of https://github.com/conda-forge/libignition-gazebo-feedstock/pull/49 after cherry-picking https://github.com/gazebosim/gz-sim/pull/1574 on the 6.12.0 release (branch for reference: https://github.com/traversaro/ign-gazebo/tree/backportwindowsfixgz6120).
Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

In https://github.com/conda-forge/libignition-gazebo-feedstock/pull/52/commits/7d53cfd34c7bca7d08a47109f7df5ed4ccd472be I enabled the upload of artifacts by the CI jobs, so that I can test locally if ign gazebo -s is working fine after this changes.

As there are a few doubts in https://github.com/gazebosim/gz-sim/pull/1764#issuecomment-1285038401 about some stranges CI failures on Ubuntu, let's apply the patch just on Windows.

I tried this locally, but for some reason it is failing with:
(libignition-gazebo6) C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\share\ignition\ignition-gazebo6\worlds>ign gazebo -s .\shapes.sdf
Library error: C:/Users/STraversaro/AppData/Local/mambaforge/envs/libignition-gazebo6/Library/lib/ignition-tools-backward.dll not found. Improved backtrace generation will be disabled
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-physics-system] : couldn't find shared library.
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-user-commands-system] : couldn't find shared library.
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-scene-broadcaster-system] : couldn't find shared library.

For some reason, the files installed by the https://github.com/gazebosim/gz-sim/blob/ign-gazebo6/src/systems/CMakeLists.txt#L85 are not copied correctly in the conda packaage.

I tried this locally, but for some reason it is failing with:
(libignition-gazebo6) C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\share\ignition\ignition-gazebo6\worlds>ign gazebo -s .\shapes.sdf
Library error: C:/Users/STraversaro/AppData/Local/mambaforge/envs/libignition-gazebo6/Library/lib/ignition-tools-backward.dll not found. Improved backtrace generation will be disabled
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-physics-system] : couldn't find shared library.
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-user-commands-system] : couldn't find shared library.
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-scene-broadcaster-system] : couldn't find shared library.

For some reason, the files installed by the https://github.com/gazebosim/gz-sim/blob/ign-gazebo6/src/systems/CMakeLists.txt#L85 are not copied correctly in the conda packaage.

Actually, this is not the problem. The problem is probably related to the fact that binary relocation does not work correctly on Windows. Anyhow, setting the path to find plugins manually, i.e.:
(libignition-gazebo6) C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\share\ignition\ignition-gazebo6\worlds>set IGN_GAZEBO_PHYSICS_ENGINE_PATH=C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\lib\ign-physics-5\engine-plugins
(libignition-gazebo6) C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\share\ignition\ignition-gazebo6\worlds>set IGN_GAZEBO_PHYSICS_ENGINE_PATH=C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\lib\ign-physics-5\engine-plugins

The test described in https://github.com/gazebosim/gz-sim/pull/1574 is working fine.

I tried this locally, but for some reason it is failing with:
(libignition-gazebo6) C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\share\ignition\ignition-gazebo6\worlds>ign gazebo -s .\shapes.sdf
Library error: C:/Users/STraversaro/AppData/Local/mambaforge/envs/libignition-gazebo6/Library/lib/ignition-tools-backward.dll not found. Improved backtrace generation will be disabled
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-physics-system] : couldn't find shared library.
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-user-commands-system] : couldn't find shared library.
[Err] [D:\bld\libignition-gazebo6_1666215155937\work\src\SystemLoader.cc:64] Failed to load system plugin [ignition-gazebo-scene-broadcaster-system] : couldn't find shared library.

For some reason, the files installed by the https://github.com/gazebosim/gz-sim/blob/ign-gazebo6/src/systems/CMakeLists.txt#L85 are not copied correctly in the conda packaage.

Actually, this is not the problem. The problem is probably related to the fact that binary relocation does not work correctly on Windows. Anyhow, setting the path to find plugins manually, i.e.:
(libignition-gazebo6) C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\share\ignition\ignition-gazebo6\worlds>set IGN_GAZEBO_PHYSICS_ENGINE_PATH=C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\lib\ign-physics-5\engine-plugins
(libignition-gazebo6) C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\share\ignition\ignition-gazebo6\worlds>set IGN_GAZEBO_PHYSICS_ENGINE_PATH=C:\Users\STraversaro\AppData\Local\mambaforge\envs\libignition-gazebo6\Library\lib\ign-physics-5\engine-plugins

The test described in gazebosim/gz-sim#1574 is working fine.

Probably the variables that we need to make sure to override with env variables are all the one contained in ignition\gazebo\config.hh, i.e. :
#define IGNITION_GAZEBO_GUI_CONFIG_PATH "D:/bld/libignition-gazebo6_1666215155937/_h_env/Library/share/ignition/ignition-gazebo6/gui"
#define IGNITION_GAZEBO_SYSTEM_CONFIG_PATH "D:/bld/libignition-gazebo6_1666215155937/_h_env/Library/share/ignition/ignition-gazebo6/systems"
#define IGNITION_GAZEBO_SERVER_CONFIG_PATH "D:/bld/libignition-gazebo6_1666215155937/_h_env/Library/share/ignition/ignition-gazebo6"
#define IGN_GAZEBO_PLUGIN_INSTALL_DIR "D:/bld/libignition-gazebo6_1666215155937/_h_env/Library/lib/ign-gazebo-6/plugins"
#define IGN_GAZEBO_GUI_PLUGIN_INSTALL_DIR "D:/bld/libignition-gazebo6_1666215155937/_h_env/Library/lib/ign-gazebo-6/plugins/gui"
#define IGN_GAZEBO_WORLD_INSTALL_DIR "D:/bld/libignition-gazebo6_1666215155937/_h_env/Library/share/ignition/ignition-gazebo6/worlds"

In this table I try to map each C preprocssor macro with the corresponding env variable:

Macro
Env Variable

IGNITION_GAZEBO_GUI_CONFIG_PATH

IGNITION_GAZEBO_SYSTEM_CONFIG_PATH

IGNITION_GAZEBO_SERVER_CONFIG_PATH

IGN_GAZEBO_PLUGIN_INSTALL_DIR
IGN_GAZEBO_SYSTEM_PLUGIN_PATH

IGN_GAZEBO_GUI_PLUGIN_INSTALL_DIR

IGN_GAZEBO_WORLD_INSTALL_DIR

Investigating Gazebo Sim docs I found two more env variables, i.e. IGN_GAZEBO_RENDER_ENGINE_PATH (related issue: https://github.com/gazebosim/gz-sim/issues/1765) and IGN_GAZEBO_PHYSICS_ENGINE_PATH, but there is no need to set them as ignition gazebo does not install any rendering or physics engine beside the one already installed by ign-physics and ign-rendering. Anyhow, we need to make sure that the env variable used by those libraries are properly set.

Investigating Gazebo Sim docs I found two more env variables, i.e. IGN_GAZEBO_RENDER_ENGINE_PATH (related issue: gazebosim/gz-sim#1765) and IGN_GAZEBO_PHYSICS_ENGINE_PATH, but there is no need to set them as ignition gazebo does not install any rendering or physics engine beside the one already installed by ign-physics and ign-rendering. Anyhow, we need to make sure that the env variable used by those libraries are properly set.

Actually it turns out that the rendering and physics library on their own do not provide any mechanism to override the default directory specified by the code, so we need to set this variables here, as the variables are consumed just by ign-gazebo.

Investigating Gazebo Sim docs I found two more env variables, i.e. IGN_GAZEBO_RENDER_ENGINE_PATH (related issue: gazebosim/gz-sim#1765) and IGN_GAZEBO_PHYSICS_ENGINE_PATH, but there is no need to set them as ignition gazebo does not install any rendering or physics engine beside the one already installed by ign-physics and ign-rendering. Anyhow, we need to make sure that the env variable used by those libraries are properly set.

Actually it turns out that the rendering and physics library on their own do not provide any mechanism to override the default directory specified by the code, so we need to set this variables here, as the variables are consumed just by ign-gazebo.

Actually, this is not completly true: for gz-rendering, there is the GZ_RENDERING_PLUGIN_PATH env variable, see https://github.com/gazebosim/gz-rendering/blob/90a13e0b295766bb3a3a33ef3da195d2fc52521b/src/RenderEngineManager.cc#L103 . Instead for gz-physics there is no env variable, and the directory used to search for physics engines are just manager by Ignition Gazebo/gz-sim .

In bafc5db and 3647c71 I added all the env variables I was able to add to solve the problem that is caused by ign-gazebo not being relocatable and of the binary relocation not properly working on Windows.

That was almost correct. The only wrong one was the IGNITION_GAZEBO_SERVER_CONFIG_PATH, that even if it has the same name of the preprocessor macro, it has a different meaning, so you can't just override it. So, for the time being we can't do anything, let's avoid to set it.


rasactl should use the latest rasa-x-helm by default

What problem are you trying to solve?
In rasactl 1.0.2, rasactl start -h shows:

at the time of writing, the latest rasa-x helm chart is 4.3.2.
rasactl should automatically use the latest rasa-x helm chart so that customers are able to use the latest features and not get stuck troubleshooting a bug that was already fixed in a subsequent release.
What's your suggested solution?
rasactl should always use the latest rasa-x helm release
Examples (if relevant)
No response
Is anything blocking this from being implemented? (if relevant)
No response
Definition of Done
rasactl  uses the latest rasa-x helm release by default

Enhancement request moved to JIRA: https://rasahq.atlassian.net/browse/INFRA-11


Augmentation policy

Need to enable different policies for augmentations

Good to implement RandAugment.

Selective Stream can also be considered as a form of augmentation policy.

Not relevant yet.


Update Poll.ts

Added the functionality to emit "listing" with the whole listing fetched from Snoowrap alongside with emiiting single items event.
In my code I want to have the ability to listen and process whole Listing, so I added 1 line to the code. I am fairly new to this, if there's anything I need to edit, please feel free to contribute.

Looks good, no reason not to include an extra event. Merging now, I'll tag a new release (along with extra tests) sometime in the next few days


Task Notification demo for FreeRTOS v10.4.6 with Tracealyzer ...

…ported to STM32F746xx Arm Cortex-M7. Removed the SEGGER Systemview trace middleware and decided to switch to Percepio Tracealyzer. Generated a preliminary trace for the task notification demo to confirm that the new middleware is correctly configured for the latest version of FreeRTOS and our STM32 NUCLEO-144 development board. Excluded stm32f7xx_hal_timebase_tim.c from the build, and removed TIM6 peripheral usage to derive the system ticks. Currently using Tracealyzer in Snapshot mode, but would like to configure USART2 to be used for Streaming mode. USART3 is used for ST-Link debugging to the eclipsed-based STM32CubeIDE. There is some commented out code that will be used for Streaming mode integration as well as Task Notification via hardware interrupts from our other CAN, USART and other serial devices on the pod network.

Great job!