Create a DEBUG environment variable to help with debugging errors.

Problem:
Currently if there is a JSON parse issue with one of our API responses we throw an error and have no idea of what the raw data is.
ZBD uses AWS and has middleware infra that can return HTML pages with various errors.
Proposed Solution:
It would be nice to have a DEBUG env flag that can be enabled to see the underlying problem in the logs.
Specifically for sendPayment, but would be nice to expand for all endpoints.

The error I get is Unexpected token < in JSON at position 0 So could it be related to JSON.stringify(cleanup(body)), here:
export async function postData({
  url,
  body,
  headers,
}: {
  url: string;
  body: any;
  headers?: any;
}) {
  const response = await fetch(url, {
    method: "POST",
    headers: {
      'Content-Type': 'application/json',
      ...headers,
    },
    body: JSON.stringify(cleanup(body)),
  });

  if (!response.ok) {
    const errorBody = await response.json();
    const error = {
      status: response.status,
      message: errorBody.message || 'API request failed',
    };

    throw error;
  }

  const result = await response.json();
  return result;
}


events not connected regularly in selenoid UI

HI @vania-pooh I am using selenoid ui and out of 10 events call one will be work/pass and 9 will be failed.
i am using ngnix proxy layer
can you please guide me :
server {
listen 80;
server_name selenoid.internaldomain.com;
return 301 https://$host$request_uri;
}
upstream tool-server-selenoid {
server #######:4444;
keepalive 20;
}
upstream tool-server-selenoid-ui {
server #####:8082;
keepalive 20;
}
server {
client_max_body_size 20M;
#location / {
#include /etc/nginx/auth/common.conf;
#proxy_set_header Connection "";
#proxy_buffering off;
#proxy_http_version 1.1;
#proxy_pass http://######:8082;
#proxy_set_header X-Forwarded-Proto $scheme;
#proxy_set_header X-Forwarded-Host $host;
#proxy_set_header X-Forwarded-Server $host;
#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#}
# selenoid-ui
location / {
proxy_pass http://tool-server-selenoid-ui;
include /etc/nginx/auth/common.conf;
}
# selenoid backend - hub
location /wd {
proxy_pass http://tool-server-selenoid;
}
# selenoid backend - wss
location /ws {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_pass http://tool-server-selenoid-ui;
proxy_http_version 1.1;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
#location /status {
#   proxy_pass http://tool-server-selenoid;
#}
location /video {
proxy_pass http://tool-server-selenoid;
}
location /logs {
proxy_pass http://tool-server-selenoid;
}
location /download {
proxy_pass http://tool-server-selenoid;
}
location /clipboard {
proxy_pass http://tool-server-selenoid;
}
location /devtools {
proxy_pass http://tool-server-selenoid;
}
location /vnc {
proxy_pass http://tool-server-selenoid;
}
location /ping {
proxy_pass http://tool-server-selenoid;
}
location /events {
proxy_pass http://tool-server-selenoid-ui;
}
}

@dutchview-harsha try to increase max request timeout as events are using long-running HTTP requests.

@vania-pooh I added below
Proxy_connect_timeout 60;
proxy_send_timeout 300;
proxy_read_timeout 300;
Doesn't help

@vania-pooh Even i am facing same issue any updates or workaround ??

@dutchview-harsha I would take a look at browser console errors then.

I dint see any console errors

@dutchview-harsha you should. Try to reload the page.

@vania-pooh tried several times didn't seen any errors. can you please send me sample nginx configuration

@dutchview-harsha try to add the same headers for /events like you did for /ws.


Use Ceibo descriptor get for visitable

~There is a single usage of Ceibo's value for only a visitable property.~ This is not true. the value is still used in the new Collection. But seems like it's for a reason.
The only difference between value and get is that value creates a writable descriptor while get doesn't. I think visitable should be changed to leverage Ceibo's get since I can see a reason to use writable descriptor for it.

@ro0gr

The only difference between value and get is that value creates a writable descriptor while get doesn't.

This is not exactly true, the difference is that with get, every time you access the property, a new function is created. On the other hand with value you always get the same value. Is not so much about writable/readonly although that difference is also true.
The initial idea in Ceibo about having value and get was the ability to intercept a call to a property (with get) or not to intercept the call and just return a fixed value (with value).
Hope this clarifies things a bit 😃

Yes, that makes things more clear. Thanks!
I don't see much difference in using of get or value. Actually there is but maybe Page Object doesn't need both get and value? It makes sense to me to use a single syntax(get) from the Ceibo for POs creation in the sake of simplicity. @san650 does it make sense to you or are the any reasons to use a value for the visitable?

@ro0gr for Page Object it makes total sense to only use get and we get the benefit of having access to the property name when evaluating the getter, which is useful for more descriptive errors.

Leaving more info about when value is used just in case someone finds it useful to know.
The value option is used automatically by Ceibo when you assign things that are not descriptors to a page object.
var page = create({
  foo: function() {
    return "FOO";
  }
})

In this case we generate the foo property in the page object object  using value. You can see this here https://github.com/san650/ceibo/blob/a4a9ad944249d0b14d40248f04bc162e5ac024e8/index.js#L40-L54

Coverage increased (+0.001%) to 98.764% when pulling 19a7b0fd94fd72c92313f84ddd43c18fb399c805 on only-get into aaec068aa9a8c4faba810af04d8644ea968c5669 on master.


Publish docker images

They are already published at https://github.com/microsoft/NubesGen/pkgs/container/NubesGen%2Fnubesgen


Cooperative box pushing giving unexpected observations

Hello,
according to the paper referenced in connection to the "Cooperative Box-Pushing" game, the agents are supposed to receive observations that correspond to what they currently see in a given time step:

After every time step each agent gets one out of 5 possible observations deterministically describing the situation of the environment in front of the agent: empty field,wall, other agent, small box, large box.

However, the game as implemented in OpenSpiel appears to return something else. In time_step.observations["info_state"], each agent receives a field of 704 binary values which seems to correspond to the global state (704 = 64 cells x 11 possible cell states).
Also, the GameType flag provides_information_state is set to true, while provides_observation is set to false which also goes contrary to what I would expect after reading the paper.
Is this an oversight or is there a purpose behind this?

Oops, this is my bad. I did not follow the paper closely, but not on purpose :)
We should provide both. The current one should be information state (evrn though it does not abide by perfect recall, though we will note this) and the one from the paper should be the observation.
I am on holiday at the moment so I can fix it next week. Or, also feel free to send us a PR with these changes instead!

Just touching base that I still plan to do this ;-)


Remove 'True' from --privileged flag in unit file

Starting the smokeping_exporter with --privileged=True instead of
just --privileged will prevent it from starting with the error
ERRO[0000] failed to create pinger: lookup True as the exporter
seems to interpret the True as a host.
Fixes #12

any update on this?

ping @paulfantom


Upgrade to swc_core 0.91.0

As requested in https://github.com/pmndrs/swc-jotai/issues/27 I try to address the required upgrade.

Upgrade to 0.91.0
Need to upgrade the rust-toolchain version to latest stable to handle proc_macro_span
Convert now missing PatOrExpr to AssignTarget (this is NAIVE, I am trusting tests here)
convert tests to test_inline as per other upgrades in swc

0.91 might be a hop too far in one go, as the broader ecosystem is currently on 0.90
I've tried this out but with 0.90 instead, and it seems to work with Next 14.2


changing camera mode from Photo to Video and start recording video

i change camera mode from photo to video in a single tap of button , the video mode is open but it did not start recording

Hey @sagar-sage thanks for the comments. I haven't been able to work on bugs due to a contract I'm involved with at the moment. If you or others submit a pull request, I can get a collaborator to get it merged in.


Ideia for a default background character

The current implementation: All shape functions use a space character (' ') to a background character, i think that an extra optional paramater to the background character is good.

I make a duplicate issue without knowing


fix(subscribers): respect TypeORM configuration option

:tada: This PR is included in version 1.17.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


feat: app specific directory storage

Fixes #544 Shift to App-Specific Directory for storing Badge and Clipart's

@adityastic please review.

@adityastic changed one.

@adityastic changed the Environment.getExternalStorageDirectory to app-specific directory code :)

@refactor-droidyy yes, you need to pass the object in the async task

@adityastic everything is working fine now.

@adityastic once again thank you very much I didn't know much about injecting dependency managing singletons and its vast use. But now with this PR and your guidance I really learned a lot. :)


add .npmignore file

Coverage remained the same at 71.266% when pulling a511dba3eae919e0ed67aef901dc48d727b9ac9f on fix/npmignore into 66bc58a895c76c3c5b9822fea5721d1b25a1d26f on master.


B2C custom policy  get external azure ad tenant_id in token

I implemented identification using custom policy to enable identification using azure AD (multi tenant).
My problem is that in the token I need to get the user's original tenant id (not the b2c tenant id) it is possible to do this
let's say that the b2c id is: 2b075fc8-7611-40d1-991b-64e5484ec1f6 and the external user tenant id is 0dbceff2-f2d3-45a7-910a-ffeb1deb0913 i want to get the 0dbceff2-f2d3-45a7-910a-ffeb1deb0913 in token.
Thanks

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

ID: f53d6e64-7bed-a987-c4bb-57fb1b116d48
Version Independent ID: fe33fd59-07ac-54d4-1926-f867aa6fc168
Content: Set up sign-in for multi-tenant Azure AD by custom policies - Azure AD B2C
Content Source: articles/active-directory-b2c/identity-provider-azure-ad-multi-tenant.md
Service: active-directory
Sub-service: b2c
GitHub Login: @msmimart
Microsoft Alias: mimart

@motim6026 Thanks for the question. We're investigating this and will get back to you shortly.

Hi,
The Azure AD tid claim contains the federated tenant ID (not the B2C one).
<OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid"/>

If you want to store the value in another claim. First define such a claim:

Open the extensions file of your policy. For example, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
Search for the BuildingBlocks element. If the element doesn't exist, add it.
Locate the ClaimsSchema element. If the element doesn't exist, add it.
Add the federatedTenantId claim to the ClaimsSchema element.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="federatedTenantId">
      <DisplayName>Federated tenant ID</DisplayName>
      <DataType>string</DataType>
    </ClaimType>
  <!--
  </ClaimsSchema>
</BuildingBlocks>-->

In the AADCommon-OpenIdConnect technical profile, replace the tid to use the federatedTenantId claim, as following:
<OutputClaim ClaimTypeReferenceId="federatedTenantId" PartnerClaimType="tid"/>

Then in the relaying party policy you can include the federatedTenantId in you token:
<OutputClaim ClaimTypeReferenceId="federatedTenantId"  DefaultValue=""/>

Yoel


fix adding dropdown fields to section

Description

Fixes validation with connection type dropdown items. Labels are not required and therefore empty labels should not cause the form to become invalid.
Fixes adding fields to sections.
How Has This Been Tested?

enable the connection type feature flag
create a new connection type
add a section
click the add field button for the section
select the field type as drop down
add a name and env var
add an item and supply value v1
add another item and supply value v2
Ensure the modal can be saved
save the modal
observe the item is correctly added to the section
try adding another field to the same or another section

Test Impact

added test case
Request review criteria:

Self checklist (all need to be checked):

[x] The developer has manually tested the changes and verified that the changes work
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has added tests or explained why testing cannot be added (unit or cypress tests for related changes)

If you have UI changes:

[x] Included any necessary screenshots or gifs if it was a UI change.
[x] Included tags to the UX team if it was a UI/UX change.

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

cc @simrandhaliw

looks good! I tested the empty labels on the dropdown and the adding of a field to a section
/lgtm


Wildcard certificates not being resolved correctly.

I am trying to generate a wildcard certificate using digitalocean. The zone lookup is splitting the entry incorrectly.
Describe the bug:
I have a certificate like so:
apiVersion: cert-manager.io/v1
kind: Certificate
spec:
  dnsNames:
  - '*.example.com'
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt
  secretName: wildcard-cert

Checking the logs, I can see that the call to the digitalocean domain is trying to lookup .com. domain, rather than example.com:
E0405 04:13:24.562351       1 controller.go:158] cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="GET https://api.digitalocean.com/v2/domains/com/records: 404 (request \"15075962-3845-4d2d-84a4-c463a5604d36\") Resource not found" "key"="platform/wildcard-cert-99rvk-1536210814-2979517128"
I0405 04:13:24.562844       1 wait.go:329] Returning cached zone record "com." for fqdn "_acme-challenge.example.com."

It looks like just a string split issue
Expected behaviour:
A certificate is issued
Steps to reproduce the bug:
Anything else we need to know?:
Environment details::

Kubernetes version: 1.20.0
Cloud-provider/provisioner: DigitalOcean
cert-manager version: v1.2.0
Install method: e.g. helm/static manifests Pulumi + Helm Chart

/kind bug

/priority important-soon

I am seeing the same issue. However, the end result is even more problematic than suggested above, because cert-manager keeps retrying the same API call every ~300 ms without stop (even after receiving a HTTP 429 response), up to the point where the API server starts blocking the source IP and forwards the requests to CloudFlare:
I1110 19:31:11.626023       1 setup.go:202] cert-manager/controller/clusterissuers "msg"="skipping re-verifying ACME account as cached registration details look sufficient" "related_resource_kind"="Secret" "related_resource_name"="letsencrypt-prod-private-key" "related_resource_namespace"="kube-system" "resource_kind"="ClusterIssuer" "resource_name"="letsencrypt-prod" "resource_namespace"="" "resource_version"="v1"
E1110 19:31:12.092289       1 controller.go:163] cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="GET https://api.digitalocean.com/v2/domains/com/records: 404 (request \"2e32a835-58f9-47e2-9d6f-5fadd5b09477\") Resource not found" "key"="mynamespace/company-wildcard-tls-prod-wqwsz-434997518-4173896995"
E1110 19:31:12.299203       1 controller.go:163] cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="GET https://api.digitalocean.com/v2/domains/com/records: 404 (request \"dfd79895-a9bb-4ae9-84a8-33234effeff1\") Resource not found" "key"="mynamespace/company-wildcard-tls-prod-wqwsz-434997518-4173896995"
E1110 19:31:12.579537       1 controller.go:163] cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="GET https://api.digitalocean.com/v2/domains/com/records: 404 (request \"6ea429a5-c373-4a45-94de-67ae4b44c8ed\") Resource not found" "key"="mynamespace/company-wildcard-tls-prod-wqwsz-434997518-4173896995"
E1110 19:31:12.774892       1 controller.go:163] cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="GET https://api.digitalocean.com/v2/domains/com/records: 404 (request \"6fd05b1d-29c1-4139-846a-507b7d11458d\") Resource not found" "key"="mynamespace/company-wildcard-tls-prod-wqwsz-434997518-4173896995"
E1110 19:31:12.932960       1 controller.go:163] cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="GET https://api.digitalocean.com/v2/domains/com/records: 404 (request \"5c0bbbf1-f9c4-4169-ac42-a10eff166886\") Resource not found" "key"="mynamespace/company-wildcard-tls-prod-wqwsz-434997518-4173896995"
E1110 19:31:13.060258       1 controller.go:163] cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="GET https://api.digitalocean.com/v2/domains/com/records: 404 (request \"35311189-97e6-4b72-a309-71b9dc1ec1ed\") Resource not found" "key"="mynamespace/company-wildcard-tls-prod-wqwsz-434997518-4173896995"
E1110 19:31:13.138893       1 controller.go:163] cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="GET https://api.digitalocean.com/v2/domains/com/records: 429 (request \"1eb0a2ac-bcc4-417e-8ca3-219f31d86602\") Too many requests" "key"="mynamespace/company-wildcard-tls-prod-wqwsz-434997518-4173896995"

/remove-lifecycle rotten


WIP: DOC: Fix code blocks in docstrings

Codecov Report

Merging #199 (d7cd562) into develop (6950b4b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           develop      #199   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           41        41
  Lines         1228      1228
=========================================
  Hits          1228      1228

Impacted Files
Coverage Δ

pfhedge/_utils/bisect.py
100.00% <ø> (ø)

pfhedge/_utils/hook.py
100.00% <ø> (ø)

pfhedge/_utils/lazy.py
100.00% <ø> (ø)

pfhedge/autogreek.py
100.00% <ø> (ø)

pfhedge/nn/functional.py
100.00% <ø> (ø)

pfhedge/nn/modules/bs/_base.py
100.00% <ø> (ø)

pfhedge/nn/modules/bs/american_binary.py
100.00% <ø> (ø)

pfhedge/nn/modules/bs/black_scholes.py
100.00% <ø> (ø)

pfhedge/nn/modules/bs/european.py
100.00% <ø> (ø)

pfhedge/nn/modules/bs/european_binary.py
100.00% <ø> (ø)

... and 8 more

Continue to review full report at Codecov.

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


Aditya Arpan Sahoo

Profile Screenshot

Hey Arpan, thanks for opening the issue:)
Please shrink the image (GitHub Profile) to a single page.


threw away the invented wheel and used clap for command line parsing

interestingly that adding clap increases the binary size from 690K to ~1.1 Mb.
// CC @waynr

Clap may not be the best if you're aiming for minimal binary size. https://github.com/clap-rs/clap/issues/1365 mentions https://docs.rs/argh/latest/argh/ as an alternative, which describes itself as:

Derive-based argument parsing optimized for code size and

Since it offers a similar derive-based parsing of arguments to what clap offers, you might be able to convert this PR pretty easily.


Azurite no longer runs correctly as a background task in GitHub Actions

Which service(blob, file, queue, table) does this issue concern?
Blob
Which version of the Azurite was used?
3.15.0
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
NPM
What's the Node.js version?
14.18.2
What problem was encountered?
I've noticed that, since today, Azurite fails to start correctly in my GitHub Actions pipeline and instead dumps some unknown text/binary content to the GitHub Action log.
Action run before the issue started:
https://github.com/CareTogether/CareTogetherCMS/runs/4710008033?check_suite_focus=true#step:6:6
Action runs showing the issue:
https://github.com/CareTogether/CareTogetherCMS/runs/4755534824?check_suite_focus=true#step:6:6 (first attempt)
https://github.com/CareTogether/CareTogetherCMS/runs/4755601564?check_suite_focus=true#step:6:6 (second attempt)
https://github.com/CareTogether/CareTogetherCMS/runs/4755632933?check_suite_focus=true#step:6:6 (third attempt, reverting my .NET SDK upgrade to try to make the Action environment as identical to the previous successful run as possible)
Steps to reproduce the issue?
See above. It seems like the following YAML is problematic now, but wasn't as of two days ago.
    - name: Set up Node.js
      uses: actions/setup-node@v1
      with:
        node-version: '14'
    - name: Install Azurite storage emulator
      run: npm install -g azurite
    - name: Start Azurite blob endpoint
      shell: bash
      run: azurite-blob &

Have you found a mitigation/solution?
No. I can't figure out what is going on that might be affecting this. (On a related note, it would be helpful if there was some guidance provided by the Azurite GitHub readme/wiki for how to use Azurite in a GitHub Action "properly", if the above is improper somehow. I got this to work based on guidance in an issue I found in the Azurite project some time back provided by @ethomson.)

Apologies if this turns out to not be an issue with Azurite. I've opened a GitHub Community topic as well in case it's an issue with Actions:
https://github.community/t/running-a-background-process-in-action-stopped-working/222180?u=larskemmann
Or maybe I'm crazy, in which case hopefully someone in one of the two places will be kind enough to point out what I've missed. 😊

@LarsKemmann
Have you do any change to Azurite (like upgrade Azurite to new version) when the issue repro? or any other changes?
From your words, it looks you have upgrade .net SDK version when the issue repro, could you confirm?
If you have not changed Azurite version, it looks more like not Azurite issue.
However, if Azurite not start from a new machine, would you like to remove the files in Azurite workspace (normally specify with -l when start Azurite.), and see if the issue repro?

This is happening in GitHub Actions (check out the links to the job logs I posted).

Okay, found the issue. You're being impacted by the "Zalgo" issue with one or both of these libraries:

https://github.com/Marak/colors.js/issues/285
https://github.com/Marak/faker.js

@LarsKemmann
Thanks for the reply!
If this is not Azurite code issue and can't resolve from Azurite side, do you mind we close this issue?

Well, the issue is resolved now in the sense that the problem has gone away (I haven't had time to figure out what resolved it), but I sure hope the Azurite team doesn't treat a supply chain attack - that causes your code to malfunction when run by end users - as someone else's problem. That would be very concerning.

The difficult part is the impacted package is not direct dependency of Azurite, sometimes, in-in-in-direct dependencies. Azurite cannot pin all direct or indirect dependencies versions. That's an issue for npm packages echo system and the issue brings up to everybody in case this supply chain attack.
Azurite other release channels like Docker Image, Visual Studio Code extension, Visual Studio built-in binary won't be impacted.

Close as the issue is resolved currently.


refactor: race_director: using bevy_ecs as a basis (WIP)

What
This adds a very WIP implementation of using bevy_ecs as the fundamental basis for race_director.
It’ll be a very slow burn over the next few weeks.
It will start by

[x] dropping support down to a single server, during refactor
[ ] add support for basic insim integration
[ ] add support for publishing insim packets as bevy Event’s
[ ] then we’ll work on basic “plugins” like track rotation, XP, etc.
[ ] scripting support
[ ] then we’ll work on persistence to a database
[ ] then we’ll work on web server integration for things like a livemap
[ ] then we’ll re-add multi-server support

Thought process
I have chosen not to use the bevy and/or bevy_app base crates because:

We dont need anything bar the ecs, and a few helper methods
A few features like Plugins we have slightly needs and can go more bespoke (direct config file integration, for example)
We want tighter control over how and when the schedules run
We probably want our own schedules, and the way the plugin trait currently works its “fork or suck it up” territory

Context
Over Christmas I had a bit of time to fiddle with writing a “scene” system for race_director.
The more time I worked on it the more and more it started looking like a hobbled ECS:

I wanted the ability to have removable “scenes”
I wanted the ability for each “scene” to have it’s own data, but still pull from a basic game state
I wanted the ability to turn “scenes” on and off based on the state of the game
I was starting to have data ownership issues and throwing Arc at everything just to get a minimally viable version up and working
I was looking at resurrecting the IndexMultiMap implementation from git history

Moved to theangryangel/race_directord.


Feature Request: add PyYAML as a dependency

SynthTool does this: https://github.com/googleapis/synthtool/blob/master/setup.py#L26
Let's do it too.

Nevermind, we already did!
https://github.com/googleapis/sample-tester/blob/master/setup.py#L46
No need to install it manually :)
/fyi @nnegrey


Adding support for new hardware platform (MCU)

Hi there,
I started to get my eyes on WAMR for an experimental project that aims to offer a uniform way of generating code uniformly across various hardware MCU platforms (STM, NXP, Silabs, Infenion, ...), for IoT specifically.
I see that in the shared lib inside the VMcore building block, the platform-defined code is done at the os level and that there is no hardware-specific code.
What does it mean for porting current WAMR implementation on, for example, an ARM Cortex-M33 chip? What would be the required step for that? I have seen this tutorial, about creating a new platform but, it is os-level not hardware level.
So to not get confused I prefer asking here first: before porting the WAMR onto new MCUs, is there any required modification on the code itself to support other hardware platforms not tested (stated above)? As long as I use the same OSs that are supported (Zephyr or FreeRTOS for example).

TLDR: Is any more work on the WAMR codebase needed, other than the one described here and here, for running WAMR hello-world with an example STM32 with Zephyr-OS or FreeRTOS?

We do have support for multiple MCU platforms with Zephyr-OS, you can refer to this directory. I think in most cases (including STM32 with Zephyr-OS you asked), you don't have to modify the codebase. You can simply use existing or add more board configs in the Zephyr board subdirectory. Feel free to play with some example configs in this directory.
However, there is no guarantee that all new platforms won't need modifications. There are always corner cases; there may be some hardware platform-specific modifications needed for a new platform, some instructions or relocation types that are unavailable on the toolchain, and different linking mechanisms may be required, etc. What we can do is fix it on a case-by-case basis when encountering it.
Here is an example of what platform-specific problem can be.


Add base-url config key instead of separate host and port

Before:
 trace {
   service-name = "zipkin-api-sample"
   zipkin {
     host = "localhost"
     port = 9411
     sample-rate = 0.1
   }
 }

After:
 trace {
   service-name = "zipkin-api-sample"
   zipkin {
     base-url = "http://localhost:9411"
     sample-rate = 0.1
   }
 }

This pull request covers #17.

@adriancole Thanks for very quick reaction :-)


Issues with Visual Studio 2017

After creating the Build folder with remake5, visual studio have problems to build the Projekt, caused by casting errors in in the header files. My Visual studio is running on default instruktions.

In addition to this, a have compiler warning:
"cl : warning D9002: unknown parameter -std=c++11"

I am also having issues setting up Box2D for my projects in VS2017.
Here are the steps I used to setup:

Create the build with premake5
Open up the Box2D.sln file and build the Box2D project.
Open up a new Visual Studio 2017 project
Set the Additional Include Directory to the Box2D header folder
Set the Additional Library Directories (under linker) to the folder that contains the lib file (Box2D.lib)
Set the Additional Dependencies to Box2D.lib
Add the HelloWorld.cpp to the project under Source files
Build

And when I try to build the project i receive the following errors.

HelloWorld.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall b2PolygonShape::ComputeMass(struct b2MassData *,float)const " (?ComputeMass@b2PolygonShape@@UBEXPAUb2MassData@@M@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall b2PolygonShape::ComputeAABB(struct b2AABB *,struct b2Transform const &,int)const " (?ComputeAABB@b2PolygonShape@@UBEXPAUb2AABB@@ABUb2Transform@@H@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall b2PolygonShape::RayCast(struct b2RayCastOutput *,struct b2RayCastInput const &,struct b2Transform const &,int)const " (?RayCast@b2PolygonShape@@UBE_NPAUb2RayCastOutput@@ABUb2RayCastInput@@ABUb2Transform@@H@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall b2PolygonShape::TestPoint(struct b2Transform const &,struct b2Vec2 const &)const " (?TestPoint@b2PolygonShape@@UBE_NABUb2Transform@@ABUb2Vec2@@@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: void __thiscall b2PolygonShape::SetAsBox(float,float)" (?SetAsBox@b2PolygonShape@@QAEXMM@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall b2PolygonShape::GetChildCount(void)const " (?GetChildCount@b2PolygonShape@@UBEHXZ)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: virtual class b2Shape * __thiscall b2PolygonShape::Clone(class b2BlockAllocator *)const " (?Clone@b2PolygonShape@@UBEPAVb2Shape@@PAVb2BlockAllocator@@@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: class b2Fixture * __thiscall b2Body::CreateFixture(struct b2FixtureDef const *)" (?CreateFixture@b2Body@@QAEPAVb2Fixture@@PBUb2FixtureDef@@@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: class b2Fixture * __thiscall b2Body::CreateFixture(class b2Shape const *,float)" (?CreateFixture@b2Body@@QAEPAVb2Fixture@@PBVb2Shape@@M@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: void __thiscall b2World::Step(float,int,int)" (?Step@b2World@@QAEXMHH@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: class b2Body * __thiscall b2World::CreateBody(struct b2BodyDef const *)" (?CreateBody@b2World@@QAEPAVb2Body@@PBUb2BodyDef@@@Z)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: __thiscall b2World::~b2World(void)" (??1b2World@@QAE@XZ)
HelloWorld.obj : error LNK2001: unresolved external symbol "public: __thiscall b2World::b2World(struct b2Vec2 const &)" (??0b2World@@QAE@ABUb2Vec2@@@Z)
MSVCRT.lib(exe_winmain.obj) : error LNK2001: unresolved external symbol _WinMain@16

I figured out why I was getting this error. Apparently Box2D was configured to build in x64 and I was building my project in x86.

Thanks, this should be fixed.


ExpressReceiver support for rawBody for signature verification

Description
The ExpressReceiver handles buffering the request body stream, and then verifying the signature (using the signing secret) in order to authenticate the sender as Slack.
However, when running in some serverless environments, such as Google Cloud Platform (GCP), the request body has already been buffered and even parsed before the Receiver gets a chance to interact with it. In GCP, the original buffer is not destroyed, but rather added as the req.rawBody property.
The ExpressReceiver should check the req.rawBody property for a buffered body for verification, instead of failing in this condition.
This feature request is analogous to https://github.com/slackapi/node-slack-events-api/issues/85, and the fix would be analogous to https://github.com/slackapi/node-slack-events-api/pull/90.
Requirements (place an x in each of the [ ])

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

cc @seratch - I think you'd like to follow this issue 😄

Did somebody already start working on this? If not, I'll make a pull request soon (possibly this weekend or early next week).

@seratch nobody has claimed this one yet that we're aware of. the timeline of next week sounds great! i'll assign this one to you just to keep track 🙇


[async] Include prediction id upload request

httpx version of #1667

We now allow downstream services to include the destination of the asset in a Location header, rather than assuming that it's the same as the final upload url (either the one passed via --upload-url or the result of a 307 redirect response.
We now include the X-Prediction-Id header in upload request, this allows the downstream client to potentially do configuration/routing based on the prediction ID. This ID should be considered unsafe and needs to be validated by the downstream service.

I opened #1788 in place of this one. Not because there was anything wrong with this code, I just found it useful to re-implement the PR to get my head around the async branch.


Remove "istio-virtual-service-ui" feature flag

rancher/rancher:v2.3-head
Now that there is UI support for Istio gateways, there is no need to hide Virtual Services & Destination Rules.
Currently, the feature flag seems to have no effect. It is set to false by default, and all Istio navigation tabs are shown.

@loganhz has something changed in release/v2.3 that would make it so that all the istio navigation shown?

All navigation being shown only started after Gateway UI was merged.

@deniseschannon Yes. In 2.3-master, they will show by default. Can I remove the feature flag or we should still use the feature flag and hide it by default?

@loganhz i don't believe we should remove teh feature flag but it should be turned on by default. is that what's happening now?

If we want to keep the feature flag and set it to true by default. Please merge https://github.com/rancher/ui/pull/3494 and https://github.com/rancher/rancher/pull/23625
If we want to remove the feature flag directly. Please merge https://github.com/rancher/rancher/pull/23624

@loganhz We've decided to move forward with setting the feature flag to true by default. Can you please make forwardport PRs for the UI and backend?

Available in 2.3-fixes

rancher/rancher:v2.3-head cd74c3592
UI: latest-2.3

istio-virtual-service-ui feature flag is enabled by default and UI features are shown
When flag is set to false the UI features are hidden


Compiler Error

Hey,
Thank you for building this much needed tool, I am trying to use the auto-compiler for a contract that I wrote but I am getting the error in the screen below.

I am running VS code windows, and below are the results of the env export on miniconda, don't know if you used conda before 😅 . Also I didn't do any configuration when installing vscode I just installed the extension from the market place. Any help or direction could help 🙏 .
name: brownie
channels:
  - defaults
dependencies:
  - astroid=2.4.2=py37_0
  - ca-certificates=2020.12.8=haa95532_0
  - certifi=2020.12.5=py37haa95532_0
  - colorama=0.4.4=py_0
  - isort=5.6.4=py_0
  - lazy-object-proxy=1.4.3=py37he774522_0
  - mccabe=0.6.1=py37_1
  - openssl=1.1.1i=h2bbff1b_0
  - pip=20.3.1=py37haa95532_0
  - pylint=2.6.0=py37_0
  - python=3.7.9=h60c2a47_0
  - setuptools=51.0.0=py37haa95532_2
  - six=1.15.0=py37haa95532_0
  - sqlite=3.33.0=h2a8f88b_0
  - typed-ast=1.4.1=py37he774522_0
  - vc=14.2=h21ff451_1
  - vs2015_runtime=14.27.29016=h5e58377_2
  - wheel=0.36.1=pyhd3eb1b0_0
  - wincertstore=0.2=py37_0
  - wrapt=1.11.2=py37he774522_0
  - zlib=1.2.11=h62dcd97_4
  - pip:
    - apipkg==1.5
    - appdirs==1.4.4
    - asttokens==2.0.3
    - base58==2.0.1
    - bitarray==1.2.2
    - black==19.10b0
    - blake2b-py==0.1.3
    - cached-property==1.5.2
    - click==7.1.2
    - cytoolz==0.11.0
    - eth-abi==2.1.1
    - eth-account==0.5.2
    - eth-bloom==1.0.3
    - eth-brownie==1.11.11
    - eth-event==1.2.0
    - eth-hash==0.2.0
    - eth-keyfile==0.5.1
    - eth-keys==0.3.3
    - eth-rlp==0.2.1
    - eth-typing==2.2.2
    - eth-utils==1.9.5
    - execnet==1.7.1
    - hexbytes==0.2.1
    - hypothesis==5.35.0
    - inflection==0.5.0
    - iniconfig==1.1.1
    - ipfshttpclient==0.7.0a1
    - ipython==7.19.0
    - ipython-genutils==0.2.0
    - jedi==0.17.2
    - lru-dict==1.1.6
    - more-itertools==8.6.0
    - multiaddr==0.0.9
    - mypy-extensions==0.4.3
    - mythx-models==1.9.1
    - netaddr==0.8.0
    - parsimonious==0.8.1
    - parso==0.7.1
    - pathspec==0.8.0
    - prompt-toolkit==3.0.7
    - protobuf==3.13.0
    - psutil==5.7.3
    - py==1.9.0
    - py-ecc==4.1.0
    - py-geth==2.4.0
    - py-solc-ast==1.2.5
    - py-solc-x==1.0.0
    - pycryptodome==3.9.8
    - pygments==2.6.1
    - pygments-lexer-solidity==0.5.1
    - pyjwt==1.7.1
    - pypiwin32==223
    - pytest==6.0.1
    - pytest-forked==1.3.0
    - pytest-xdist==1.34.0
    - pythx==1.6.1
    - pywin32==228
    - pyyaml==5.3.1
    - regex==2020.10.28
    - rlp==1.2.0
    - semantic-version==2.8.5
    - style==1.1.0
    - termcolor==1.1.0
    - toml==0.10.2
    - toolz==0.11.1
    - tqdm==4.48.2
    - trie==2.0.0a5
    - typing-extensions==<IP_ADDRESS>
    - update==0.0.1
    - varint==1.0.2
    - vvm==0.1.0
    - vyper==0.2.7
    - web3==5.11.1
    - websockets==8.1
    - zipp==3.4.0
prefix: C:\kaleb\miniconda\envs\brownie

I had the same issue today on my new PC. The cause and solution were in my case the following (I'm working on a Windows PC):
Cause:

I used a virtual environment for my contract delevopment, therefore Vyper was only installed in the venv (by using pip install vyper).

Therefore, the vyper extension in VS Code was trying to use the shell command vyper to compile.

But this command only exists in the venv.

Solution:

Go to your venv folder and look for the vyper.exe file (venv -> scripts -> vyper.exe)

Copy the path to the exe file

Go in VS Code -> Settings -> Extensions -> Vyper -> Change vyper Command to the path (e.g. C:\dev\your_project.venv\Scripts\vyper.exe)

restart VS Code

Worked for me. Hope for you too.

Can't thank you enough @mat774

If someone is using conda instead of venv use where your env file is saved C:\kaleb\miniconda\envs\brownie\Scripts


Student result view: students appearing twice (bug)

In the student result view of my exam, many students (like A. V.) appear twice.
The various links (to pdf, feedback view, ...) are identical, but not the score.
@barais: you can access the view here:
https://correctexam.github.io/corrigeExamFront/showresults/186

@nthiery
I fix it for your exam but i will let the bug open. Indeed, I add a notion of FinalResult in DB that keep the note for one student and one exam. (It is computed each time). I do not known why but several "Finalresult" have been created for the same exam and the same student. Not a big deal as it is a computed value, I can delete them but It should never happen. I will review the code to find the bug and add a constraint in the database.

done for the constraints


Fixed documentation to point to the right BSON namespace for ObjectID

After the merge, can you push this to the site @jmikola ?

See also https://github.com/mongodb/mongo-php-library/pull/157 for a lot more of this sort of fixes

Merged to v1.0 in https://github.com/mongodb/mongo-php-library/commit/6b2aa21acd8ab3e29f016ad5bfcab49b260ba75a.


Crawling rate and burst issue

Why can't I use --max-rate and --max-burst in 'all' mode? According to the document these two parameters only work in 'webui' mode?
This is how I ran my program, I have downloaded the pyspider source code.
    ./pyspider/run.py

Which is able to work.
But, if I try to run it with webui but failed.
    ./pyspider/run.py  webui
    [W 150923 22:36:17 index:107] connect to scheduler rpc error: error(111, 'Connection refused')

Of course my point is to control the rate.

you need a -c config.json file to specify arguments for webui while using all mode.

Didn't work.
{
  "webui": {
    "max_rate": 0.2,
    "max_burst": 2
  }
}

Still crawling very fast

You need to change the rate and burst via webui, this max_* restrict only works for UI part.

From where? I didn't see any button of rate control??


Import does not support french accents

The french accents é à ê etc are not well supported : it breaks the fields values and the passwords do not work.

Same with Swedish åäö, would be amazing if this could work. I guess it's essentially multi-byte string support we are looking for.

I think this depends on the further configuration of your Craft installation. Please read this paper and see if implementing this fixes your problems: http://static.zend.com/topics/multibyte-fgetcsv.pdf

Did the article help you guys with this?

Ah didn't see this I've just posted the same issue with the french language...  will have a look at the document

Not sure how I'm supposed to use that document posted.... any direction to test this would be appreciated.

Set the mb and locale settings on top of your index.php

Thanks Bob… will try that…

On 4 Nov 2015, at 07:35, Bob Olde Hampsink<EMAIL_ADDRESS>wrote:
Set the mb and locale settings on top of your index.php
—
Reply to this email directly or view it on GitHub https://github.com/boboldehampsink/import/issues/74#issuecomment-153619143.

Did this work for you?

It worked at #87, closing this


WIP: Device layer port to nRF52840

-- Test Travis script changes.

Codecov Report

:exclamation: No coverage uploaded for pull request base (feature/nrf52840-device-layer-local@8e460d2). Click here to learn what that means.
The diff coverage is n/a.

@@                          Coverage Diff                           @@
##             feature/nrf52840-device-layer-local       #4   +/-   ##
======================================================================
  Coverage                                       ?   53.59%
======================================================================
  Files                                          ?      326
  Lines                                          ?    55461
  Branches                                       ?        0
======================================================================
  Hits                                           ?    29726
  Misses                                         ?    25735
  Partials                                       ?        0

Continue to review full report at Codecov.

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


Release?

I understand the goal is to eventually get this into Julia's default, but wouldn't it help to release this as a package for now?

I'm not sure. I'm basically just overwriting a host of Base methods to do this. That feels like bad form?

Oh I'm not sure either! 🤷

Yeah, I'll leave it out for the time being. Thanks for raising the issue though!


Review and simplify Workspace properties and data stored in properties

MATCH (n:Workspace) where n.uuid = "02e14ca7-8754-4b3a-af71-64a5ed1dbd20" RETURN n LIMIT 25

Lots of data is replicated in the properties of a Workspace node
{
  "identity": 130914,
  "labels": [
    "Workspace"
  ],
  "properties": {
"createdAt": "2022-04-08T17:56:25.065000000Z",
"rfObject": "{"nodes":[{"id":"DiamondDAO","data":{"node":{"__typename":"Entity","name":"DiamondDAO","address":null,"avatar":"https://i.imgur.com/lZcAYTy.png","about":"Diamond DAO ◈ is an ecosystem of protocols designed to collect the most valuable assets in DeFi.","proposalsAggregate":{"__typename":"EntityProposalProposalsAggregationSelection","count":0}},"title":"DiamondDAO","about":"Diamond DAO ◈ is an ecosystem of protocols designed to collect the most valuable assets in DeFi.","avatar":"https://i.imgur.com/lZcAYTy.png","dim":false},"type":"entity","position":{"x":-291,"y":164},"positionAbsolute":{"x":-291,"y":164},"z":0,"handleBounds":{"source":[{"id":"b","position":"right","x":198,"y":36,"width":6,"height":6}],"target":[{"id":"a","position":"left","x":-4,"y":36,"width":6,"height":6}]},"width":200,"height":78,"selected":false,"dragging":false},{"id":"94c749ae-d3ff-4554-acb4-c0d68c6a8b52","data":{"node":{"__typename":"Note","text":"Diamond dao hosts genesis cohorts for testers of the program #testers\n","createdAt":"2022-04-08T17:55:43.881Z","uuid":"94c749ae-d3ff-4554-acb4-c0d68c6a8b52","wallet":{"__typename":"Wallet","address":"0x9aa11A6f9dD069003D7C406F2A853290F934b03B"},"tags":[{"__typename":"Tag","tag":"testers"}],"entities":[]},"dim":false,"label":"Diamond dao hosts genesis cohorts for testers of the program #testers\n"},"type":"block","position":{"x":193,"y":84},"positionAbsolute":{"x":193,"y":84},"z":0,"handleBounds":{"source":[{"id":"b","position":"right","x":197.99187835920858,"y":30.498498171155315,"width":6,"height":6}],"target":[{"id":"a","position":"left","x":-4.002331555968783,"y":30.498498171155315,"width":6,"height":6}]},"width":200,"height":67,"selected":false,"dragging":false},{"id":"f162aff5-7592-4cb4-a4e1-6bcadb580115","data":{"node":{"__typename":"Note","text":"@DiamondDAO prioritizes the creation of new knowledge that makes inferences, hypothesis, and narratives.\n","createdAt":"2022-04-08T17:50:26.225Z","uuid":"f162aff5-7592-4cb4-a4e1-6bcadb580115","wallet":{"__typename":"Wallet","address":"0x9aa11A6f9dD069003D7C406F2A853290F934b03B"},"tags":[],"entities":[{"__typename":"Entity","name":"DiamondDAO"}]},"dim":false,"label":"@DiamondDAO prioritizes the creation of new knowledge that makes inferences, hypothesis, and narratives.\n"},"type":"block","position":{"x":-2.999999999999993,"y":374},"positionAbsolute":{"x":-2.999999999999993,"y":374},"z":0,"handleBounds":{"source":[{"id":"b","position":"right","x":198,"y":37,"width":6,"height":6}],"target":[{"id":"a","position":"left","x":-4,"y":37,"width":6,"height":6}]},"width":200,"height":80,"selected":false,"dragging":false},{"id":"8b5a99b5-afe8-4936-9630-788ef8d50ce6","data":{"node":{"__typename":"Note","text":"Diamond DAO is considering exploring trading patterns in the Music NFT  as a proof of concept for a #DAO2DAO #partnership with @JournoDAO  focused on #data-storytelling.\n","createdAt":"2022-04-08T08:34:44.075Z","uuid":"8b5a99b5-afe8-4936-9630-788ef8d50ce6","wallet":{"__typename":"Wallet","address":"0xC75446A6AdaEF73269dBdEcE73536977B2b639e0"},"tags":[{"__typename":"Tag","tag":"DAO2DAO"},{"__typename":"Tag","tag":"partnership"},{"__typename":"Tag","tag":"data-storytelling"}],"entities":[{"__typename":"Entity","name":"JournoDAO"}]},"dim":false,"label":"Diamond DAO is considering exploring trading patterns in the Music NFT  as a proof of concept for a #DAO2DAO #partnership with @JournoDAO  focused on #data-storytelling.\n"},"type":"block","position":{"x":336,"y":230},"positionAbsolute":{"x":336,"y":230},"z":1000,"handleBounds":{"source":[{"id":"b","position":"right","x":198,"y":65.5,"width":6,"height":6}],"target":[{"id":"a","position":"left","x":-4,"y":65.5,"width":6,"height":6}]},"width":200,"height":137,"selected":true,"dragging":false}],"edges":[{"source":"DiamondDAO","sourceHandle":"b","target":"f162aff5-7592-4cb4-a4e1-6bcadb580115","targetHandle":"a","label":"Linked To","labelBgPadding":[2,2],"type":"smoothstep","labelStyle":{"fill":"#9C9C9C","fontFamily":"Rubik","fontWeight":500},"labelBgStyle":{"fill":"#E8F4FF","fontWeight":500},"markerEnd":{"type":"arrowclosed"},"id":"reactflow__edge-DiamondDAOb-f162aff5-7592-4cb4-a4e1-6bcadb580115a"},{"source":"f162aff5-7592-4cb4-a4e1-6bcadb580115","sourceHandle":"b","target":"8b5a99b5-afe8-4936-9630-788ef8d50ce6","targetHandle":"a","label":"Linked To","labelBgPadding":[2,2],"type":"smoothstep","labelStyle":{"fill":"#9C9C9C","fontFamily":"Rubik","fontWeight":500},"labelBgStyle":{"fill":"#E8F4FF","fontWeight":500},"markerEnd":{"type":"arrowclosed"},"id":"reactflow__edge-f162aff5-7592-4cb4-a4e1-6bcadb580115b-8b5a99b5-afe8-4936-9630-788ef8d50ce6a"}],"viewport":{"x":664.1258581235697,"y":127.31292906178487,"zoom":1.074370709382151}}",
"name": "Diamond Dao thesis
",
"uuid": "02e14ca7-8754-4b3a-af71-64a5ed1dbd20",
"updatedAt": "2022-04-08T17:56:25.065000000Z"
  }
}

Particularly the rfObject property. We should review why this is needed, and simplify if possible.

@liminal-dog how is rfObject created and what is it trying to store in here? Looks like a subgraph

My understanding is that while nodes are connected to saved workspaces through edges, @muabipapi designed the   rfObject to store the positions of nodes in the workspace, so users could preserve the layout of their visualization.

Got it, ok in that case it makes sense. Eventually might want to move that to just a json document so we don't run into Neo4j property character limits later when workspaces get big. For future backlog though


Test with Arduino 1.5

Request from Kelley:

Please test a bit with Arduino 1.5 version soon to see if it supports the lang features you're using..  One product wuses 1.5 and another uses 1.6/1.8 version.  If not, and hard to adapt, I vote continuing with 1.6/1/8 version, and we can get that working and ponder 1.5 later.

For this task, we need to download the Arduino 1.5 SDK/Application, load this library, and test that everything compiles and works.
If not, we need to find a good way to fix the problems.

Client has upgraded, closing this issue.


UMD package: export MaterialUI variable

Currently to use Material-UI with codepen.io, JSFiddle... you have to write (see https://stackoverflow.com/q/50705423):
const { Button, Input } = window['material-ui'];

This is because the output name inside rollup.config.js is 'material-ui':
https://github.com/mui-org/material-ui/blob/8013fdd36d40980ebb8f116f20e2843b781c0c39/packages/material-ui/scripts/rollup.config.js#L10
Instead it should be a name without -, something like 'MaterialUI':
const { Button, Input } = MaterialUI;

rollup.config.js example:
https://github.com/tkrotoff/react-form-with-constraints/blob/b64119bee6ab80c77417a9284a704b380b81bf5e/packages/react-form-with-constraints/rollup.config.js#L19-L27
Related issue: #7621

@tkrotoff This change sounds good to me. However, it's a breaking change. We gonna need to bump the version to v2. I'm adding it into the milestone 👍

This use case is OK: codepen.io => material-ui (with window['material-ui'])
This use case is KO: codepen.io => myLib => material-ui
I don't know how to configure myLib to use window['material-ui'] (no problem of course if material-ui exported a variable MaterialUI).
It's probably not possible, so having a MaterialUI export is not only a "nice to have".
Example code:

react-form-with-constraints-material-ui ("myLib") umd<EMAIL_ADDRESS>react-form-with-constraints-material-ui rollup.config.js: https://github.com/tkrotoff/react-form-with-constraints/blob/a742293a3ef16806aaae98f4254a521a6ce196a4/packages/react-form-with-constraints-material-ui/rollup.config.js#L24-L27
codepen.io experimentations: https://codepen.io/tkrotoff/pen/MBGOQo

I don't know how to configure myLib to use window['material-ui']

@tkrotoff We will definitely move forward and address this problem in v2!

@oliviertassinari wow did not expect a release so soon! Can I make a PR to change this: https://github.com/mui-org/material-ui/blob/v3.0.0/packages/material-ui/scripts/rollup.config.js#L10 ?

@tkrotoff What do you mean? This change is still planed for v4, in 3-4 months.

Je suis un peu perdu : few days ago you were talking about a v2. I saw v3 was just released (could have been a good time to change this) and now talking about a v4.
Anyway, can I make a PR on master? (I guess not, master is for v3 and there is no branch for v4 yet).

Yeah sorry for the confusion. v2 focus has just shifted to v4 for Q1 2019.

You can definitely open a pull request now on master. We will just wait before merging it :).


cron bad file mode

The cron job is failing and I find this in /var/log/cron
crond[3024]: (root) BAD FILE MODE (/etc/cron.d/certbot_renew)
not sure how to fix it

Can you try adjusting the permissions to 0644 instead of +x?

I did that and made sure that line endings were unix, and it worked.

Awesome! Closing this now.


Use GetCode/GetTaggedCode to easier synchronize GitHub and ROSWiki

Problem
Changing source files in this repository or in their respective ROSWiki entries requires that work to be duplicated into their counterparts, which is errorprone at best and could be forgotten at worst.
Solution
Link the ROSWiki entries to this repository by using the Makro GetCode/GetTaggedCode.
The remaining issue is that if the folder structure in this repository ever changes, this will require changes in ROSWiki aswell.
Additional context
This technique is also used in the official ROS Tutorials, e.g. CPP-Tutorial.
The tagged code for the above tutorial can be found here.

Thanks for your Input. Applied it here http://wiki.ros.org/pilz_robots/Tutorials/HowToSetupTheRobot.
Rest will follow.

We have one this in all tutorials now. Feel free to reopen if necessary


Support php's array callable format for macro's.

Hi Barry,
We've been defining our macro's as callables of a class instead of using closures, sadly this breaks ide-helper because it expects only closures as macros.
This patch allows you to define methods like this as well: Str::macro('name', [$this, 'method']);
(This patch was based on the latest stable tag [2.4.1] because dev-master was broken for me, i'm not sure what branch you want me to push this to, if you want it on another branch so it's easier to tag please let me know)

Hey @barryvdh,
Have you had time to look at this yet?
Greetings!


[BUG] Unstable LeaveEvent Message in "FabricWillBeRemoved" function

Reproduction steps
I want to implement the Leave Event before the Factory Reset is executed, but it does not work every time
As my understanding the FabricWillBeRemoved function in operational-credentials-server.cpp would send the Leave Event message when the Client(TH) subscribed.

Hence I created a function to directly call the DeleteAllFabrics() as below:

However, I discovered that the TH does not receive the Leave Event message no matter using the command to remove fabric or using the function I created every time.
Test Setup:
DUT Test  discriminator:  3840    & Passcode:            20202021
RaspberryPi TestHarness version: TE1 Spring 2024 (Sha: 5100c93)
Test Steps:

pairing DUT to Chip-tool
implement the "./chip-tool interactive start"
subscribe the leave event under basic-information (cmd: basicinformation subscribe-event leave 5 10 0x0001 0)
a. execute the remove-fabric command (cmd: operationalcredentials remove-fabric 1 0x0001 0)
b. Trigger MatterAPIRemoveFabric() function

Test Result:
Both 4.a and 4.b did not receive the LeaveEvent message every time
4.a result: LeaveEventTHLog.txt
4.b result: LeaveEventFactoryResetTHLog.txt
Receive Failure DUT Log:
DUTLogReceiveFail.txt
Receive Success DUT Log:
DUTLogReceiveSuccess.txt
According to my test result, the Leave Event is unstable.
Is that a bug when sending the Leave Event?? Or  my test method is incorrect?
Please let me know if require more information. Thank you
Bug prevalence
sometimes
GitHub hash of the SDK that was being used
esp-matter(2f692ac10a09ed27c223499ecdc458f7730d544d), connectedhomeip (2f692ac10a09ed27c223499ecdc458f7730d544d)
Platform
esp32
Platform Version(s)
v5.1.2 (482a8fb2d78e3b58eb21b26da8a5bedf90623213)
Anything else?
No response

All the LeaveEvent stuff is very best-effort.
That said, @emesamwong can you compile with detail logging enabled?  That will tell you things like whether LogEvent was called and whatnot, and what happened after that.
And please make sure you test with Matter tip, since there were bugs around this a while back that got fixed.

Thank you for your reply. I will try to read the "chip" level Log, but what is "Matter tip"?

Neither of those logs has detail logging enabled as far as I can tell.  And we are interested in the DUT log, since the DUT is not sending the data report.

and what is "Matter tip"?

Just the most current version of the Matter SDK (what you are calling "chip").

How to enable the detail log?
SDK version:
esp-matter: 2f692ac1
corresponding connectedhomeip: 8e3d98c0

I don't know offhand how to do it on esp32.  It'll be somewhere in their config menus....

@shripad621git Please check

@emesamwong please try to change the log level using idf.py menuconfig to Degbu, it is at Menu path: (Top) -> Component config -> Log output -> Default log verbosity


All dates are incorrectly removed from filenames when shown in the list

Only the date used for sort and the date field should be removed.

Fixed in #161.


Implement FoF Upload

It will be great to have FoF Upload implemented to set images.

@jaspervriends , is this for the Blog image, or for images in the post? I am on v0.2.1 but don't see any option to upload images to the blog image settings. The upload form is only available for the post content, let me know.. I might be confused lol.

@jaspervriends , is this for the Blog image, or for images in the post? I am on v0.2.1 but don't see any option to upload images to the blog image settings. The upload form is only available for the post content, let me know.. I might be confused lol.

It's for the blog featured image. I've worked on a media manager for the FoF Upload extension which we could use for this. After this PR has been merged I'll update the Blog extension to support custom uploads :)

Ok thanks :) so if the above has been merged already (for the featured image upload) how does this work, because I am not seeing the option on my end... onlhttps://github.com/v17development/flarum-blog/pull/29

Ok thanks :) so if the above has been merged already (for the featured image upload) how does this work, because I am not seeing the option on my end..  https://github.com/v17development/flarum-blog/pull/29

Hi! Sorry, forgot to add the link to the PR: The PR is still open: https://github.com/FriendsOfFlarum/upload/pull/262
So it isn't implemented yet. But after that it will be updated

Oh wow.. that looks.... amazing.
And the feature imaged will be able to hook into that? :)

Oh wow.. that looks.... amazing.
And the feature imaged will be able to hook into that? :)

Yup that is the idea :)

I know this is in the plans and will be done later, but I was wondering if it would be possible that the images when uploaded can be entered in a folder, currently I do it manually in my S3 storage, I do the following structure /blog/189/hey.png
The number 189 for example I take it from the post itself:

Would it be possible to automatically upload the images through the Blog extension with this folder structure? Or would this be a FOF Upload problem?

I think this feature is temporary solution: https://github.com/v17development/flarum-blog/issues/78


[Proofreading]: Junkland - Young Person

Please describe correction needed: Refine verbage. And translate Gald line.

Please paste or attach a screenshot of the issue.

Gald line has been translated. Not sure it the other really needs tweaked.

Junktown rewording #1023
Fixed for a better line
Buy 3 for 120 Gald?


twitter template

Adds twitter.html which formats a script as a sequence of tweets.

Thank you!
im really glad other people are using this tool :D


FLINK-3930 Added shared secret based authorization for Flink service …

This PR addresses FLINK-3930 requirements. It enables shared secret based secure cookie authorization for the following components

Akka layer
Blob Service
Web UI

Secure cookie authentication can be enabled by providing below configurations to Flink configuration file.

security.enabled: A boolean value (true|false) indicating security is enabled or not.
security.cookie : Secure cookie value to be used for authentication. For standalone deployment mode, the secure cookie value is mandatory when security is enabled but for the Yarn mode it is optional (auto-generated if not provided).

Alternatively, secure cookie value can be provided through Flink/Yarn CLI using "-k" or "--cookie" parameter option.
The web runtime module prompts for secure cookie using standard basic HTTP authentication mechanism, where the user id field is a noop and the password field will be used to capture the secure cookie.

@mxm - The patch is available for your review. Please take a look.

Thank you for opening a pull request for this. I'll check it out now.

It seems that some of the YARN tests are failing because the jobmanager / application master is logging:
2016-08-27 08:48:54,858 INFO  org.apache.flink.yarn.YarnJobManager                          - ApplicatonMaster will shut down YARN session when job f56f54e7288172fdc16966c04e343d91 has finished.
2016-08-27 08:48:55,370 ERROR org.apache.flink.runtime.blob.BlobServerConnection            - Error while executing BLOB connection.
java.io.EOFException: Read an incomplete length
	at org.apache.flink.runtime.blob.BlobUtils.readLength(BlobUtils.java:282)
	at org.apache.flink.runtime.blob.BlobServerConnection.readCookie(BlobServerConnection.java:487)
	at org.apache.flink.runtime.blob.BlobServerConnection.validateSecureCookie(BlobServerConnection.java:499)
	at org.apache.flink.runtime.blob.BlobServerConnection.run(BlobServerConnection.java:107)
2016-08-27 08:48:55,453 INFO  org.apache.flink.yarn.YarnJobManager                          - Submitting job f56f54e7288172fdc16966c04e343d91 (Flink Java Job at Sat Aug 27 08:48:46 UTC 2016).
2016-08-27 08:48:55,465 INFO  org.apache.flink.yarn.YarnJobManager                          - Using restart strategy NoRestartStrategy for f56f54e7288172fdc16966c04e343d91.
2016-08-27 08:48:55,524 INFO  org.apache.flink.yarn.YarnJobManager                          - Scheduling job f56f54e7288172fdc16966c04e343d91 (Flink Java Job at Sat Aug 27 08:48:46 UTC 2016).
2016-08-27 08:48:55,525 INFO  org.apache.flink.runtime.executiongraph.ExecutionGraph        - CHAIN DataSource (at getDefaultTextLineDataSet(WordCountData.java:70) (org.apache.flink.api.java.io.CollectionInputFormat)) -> FlatMap (FlatMap at main(WordCount.java:80)) -> Combine(SUM(1), at main(WordCount.java:83) (1/1) (f5b14d29193f2a64970a98423aa00be2) switched from CREATED to SCHEDULED
2016-08-27 08:48:55,535 INFO  org.apache.flink.yarn.YarnJobManager                          - Status of job f56f54e7288172fdc16966c04e343d91 (Flink Java Job at Sat Aug 27 08:48:46 UTC 2016) changed to RUNNING.
2016-08-27 08:48:55,547 INFO  org.apache.flink.runtime.executiongraph.ExecutionGraph        - CHAIN DataSource (at getDefaultTextLineDataSet(WordCountData.java:70) (org.apache.flink.api.java.io.CollectionInputFormat)) -> FlatMap (FlatMap at main(WordCount.java:80)) -> Combine(SUM(1), at main(WordCount.java:83) (1/1) (f5b14d29193f2a64970a98423aa00be2) switched from SCHEDULED to DEPLOYING
2016-08-27 08:48:55,547 INFO  org.apache.flink.runtime.executiongraph.ExecutionGraph        - Deploying CHAIN DataSource (at getDefaultTextLineDataSet(WordCountData.java:70) (org.apache.flink.api.java.io.CollectionInputFormat)) -> FlatMap (FlatMap at main(WordCount.java:80)) -> Combine(SUM(1), at main(WordCount.java:83) (1/1) (attempt #0) to testing-worker-linux-docker-8659bf87-3480-linux-9
2016-08-27 08:48:55,673 ERROR org.apache.flink.runtime.blob.BlobServerConnection            - Error while executing BLOB connection.
java.io.EOFException: Read an incomplete length
	at org.apache.flink.runtime.blob.BlobUtils.readLength(BlobUtils.java:282)
	at org.apache.flink.runtime.blob.BlobServerConnection.readCookie(BlobServerConnection.java:487)
	at org.apache.flink.runtime.blob.BlobServerConnection.validateSecureCookie(BlobServerConnection.java:499)
	at org.apache.flink.runtime.blob.BlobServerConnection.run(BlobServerConnection.java:107)

(see: https://s3.amazonaws.com/archive.travis-ci.org/jobs/155437254/log.txt)

I manually tested the code. Taskmanagers are properly rejected on missmatching cookies, it works when they match.
One thing I found was that the error reporting is not very good:
robert@robert-da ...k-1.2-SNAPSHOT-bin/flink-1.2-SNAPSHOT (git)-[FLINK-3930] % ./bin/flink run -k asdf ./examples/batch/WordCount.jar
Cluster configuration: Standalone cluster with JobManager at /<IP_ADDRESS>:6123
Using address <IP_ADDRESS>:6123 to connect to JobManager.
JobManager web interface address http://<IP_ADDRESS>:8081
Starting execution of program
Executing WordCount example with default input data set.
Use --input to specify file input.
Printing result to stdout. Use --output to specify output path.
Submitting job with JobID: 0816b6a3427cdcfc1160655edc2cef09. Waiting for job completion.

------------------------------------------------------------
 The program finished with the following exception:

org.apache.flink.client.program.ProgramInvocationException: The program execution failed: Couldn't retrieve the JobExecutionResult from the JobManager.
	at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:404)
	at org.apache.flink.client.program.StandaloneClusterClient.submitJob(StandaloneClusterClient.java:92)
	at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:380)
	at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:367)
	at org.apache.flink.client.program.ContextEnvironment.execute(ContextEnvironment.java:61)
	at org.apache.flink.api.java.ExecutionEnvironment.execute(ExecutionEnvironment.java:896)
	at org.apache.flink.api.java.DataSet.collect(DataSet.java:410)
	at org.apache.flink.api.java.DataSet.print(DataSet.java:1605)
	at org.apache.flink.examples.java.wordcount.WordCount.main(WordCount.java:92)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.flink.client.program.PackagedProgram.callMainMethod(PackagedProgram.java:509)
	at org.apache.flink.client.program.PackagedProgram.invokeInteractiveModeForExecution(PackagedProgram.java:403)
	at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:322)
	at org.apache.flink.client.CliFrontend.executeProgram(CliFrontend.java:775)
	at org.apache.flink.client.CliFrontend.run(CliFrontend.java:251)
	at org.apache.flink.client.CliFrontend.parseParameters(CliFrontend.java:1003)
	at org.apache.flink.client.CliFrontend.main(CliFrontend.java:1046)
Caused by: org.apache.flink.runtime.client.JobExecutionException: Couldn't retrieve the JobExecutionResult from the JobManager.
	at org.apache.flink.runtime.client.JobClient.awaitJobResult(JobClient.java:292)
	at org.apache.flink.runtime.client.JobClient.submitJobAndWait(JobClient.java:377)
	at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:400)
	... 19 more
Caused by: org.apache.flink.runtime.client.JobClientActorConnectionTimeoutException: Lost connection to the JobManager.
	at org.apache.flink.runtime.client.JobClientActor.handleMessage(JobClientActor.java:207)
	at org.apache.flink.runtime.akka.FlinkUntypedActor.handleLeaderSessionID(FlinkUntypedActor.java:90)
	at org.apache.flink.runtime.akka.FlinkUntypedActor.onReceive(FlinkUntypedActor.java:70)
	at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:167)
	at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
	at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)
	at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
	at akka.actor.ActorCell.invoke(ActorCell.scala:487)
	at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:254)
	at akka.dispatch.Mailbox.run(Mailbox.scala:221)
	at akka.dispatch.Mailbox.exec(Mailbox.scala:231)
	at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
	at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.pollAndExecAll(ForkJoinPool.java:1253)
	at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1346)
	at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
	at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

But I think that this is akka's fault, not ours.

I'm done with my initial review.
If you have a minute @mxm, it would be good if you could check the CliFrontend changes, to see if they fit the architecture well.

According to the design document, netty authentication is also part of this JIRA. Why was it not addressed?

According to the design document, netty authentication is also part of this JIRA. Why was it not addressed?
The netty layer is addressed as part of web layer authentication (T2-3 & T2-5 combined). Do you see a need to address this to some other part of the code as well?

T2-3 is not about the web interface netty, its about the data transfer netty
In Flink, we are using netty for (at least) three things:

Akka is using Netty. This is addressed in the pull request
The web interface is using Netty. Addressed as well
The user data (datastreams, etc.) is transferred using Netty between the TaskManagers as well.

T2-3 is not about the web interface netty, its about the data transfer netty
In Flink, we are using netty for (at least) three things:
- Akka is using Netty. This is addressed in the pull request
- The web interface is using Netty. Addressed as well
- The user data (datastreams, etc.) is transferred using Netty between the TaskManagers as well.
Thanks Robert for the clarification. It was a good catch and I have clearly missed the Netty part used between TMs. I will create another JIRA and address the issue as part of it.
I have incorporated your feedback comments and rebased the commits to latest master. Please retest and see if the patch is okay?

Thank you for addressing my comments.
I've looked into the design document [1] again and some details are missing there. In particular its not clearly specified how and where the shared secrets are created and transferred in the cluster.
How is the secret transferred to the TaskManagers on YARN?
Is the using the  JobManagerMessages.getRequestBlobManagerSecureCookie() message always secure?
I think its important for security-related changes to first have a clear, documented security concept, and then an implementation that matches the documentation.
Maybe it also makes sense to start adding a page into the internals documentation section, explaining how the secure cookie is implemented.
@StephanEwen can you maybe add your thoughts here?
[1] https://docs.google.com/document/d/1-GQB6uVOyoaXGwtqwqLV8BHDxWiMO2WnVzBoJ8oPaAs/edit

How is the secret transferred to the TaskManagers on YARN?
Cookie is transferred to TM container through container environment variable and further gets populated to in-memory Flink configuration instance. The secure cookie is vulnerable (so as the Keytab file) to the users who has access to the container local resource storage area and that's the limitation we may have to deal with.

Is using the JobManagerMessages.getRequestBlobManagerSecureCookie() message always secure?

I believe it is safe since Akka endpoints are secured using the shared token (cookie) and for someone to access the cookie using the "JobManagerMessages.getRequestBlobManagerSecureCookie()", they should have been authenticated first.

Maybe it also makes sense to start adding a page into the internals documentation section, explaining how the secure cookie is implemented.
I am planning to add a separate page to internals documentation explaining how the shared secret stuff is implemented for various deployment options - Standalone, Yarn, Mesos (tbd)

@rmetzger I have added internals documentation section and provided details on how secure cookie is implemented. I will address the missing Netty data transfer secure cookie part in FLINK-4635. Please take a look.

@rmetzger @StephanEwen are you guys waiting for any inputs from my side?

I think we are waiting for @rmetzger to follow up. He is out of office for a few days...

Thanks @StephanEwen

Addressed [FLINK-4635] Netty data transfer authentication (missing piece of FLINK-3930)

@rmetzger can you please take a look at the updated patch

I'll take a look.

Resolved merge conflicts and squashed commits to rebase with master

Thank you for your work so far @vijikarthi. I'll take a final look before we merge this.

Thanks @mxm for the review. I will incorporate your feedback and attach the patch.

When security is enabled, encryption should also be turned on by default. Otherwise we will transmit plain-text passwords over the wire.
Yes it makes sense. I will make a conditional check and throw an error if encryption is not enabled when security is enabled?

Should there be too modes for network transmission, 1) with cookie, one without? Do we need 32 bits for the cookie length? We should be precise about the maximum length. I saw it is set to 1024 in other places.
Yes, max cookie length validation is 1024. I will change the code where the buffer length was allocated to a high value, instead it will use the byte array length read from the message.

Should we really always send the cookie for every message? The security document mentions in T2-3 that we only want to authorize upon the first connection.
Yes, we took the approach to pass secure cookie for every message to keep minimal changes to the current design

Why do we transmit the cookie to the client? This seems like a major security concern. The client should always provide the cookie.
edit: I see this has been specified in the document in T2-4. Still, I wonder if it would make sense to simply add this now because the workaround to fetch the cookie from the JobManager doesn't look appealing.
Good catch. I forgot to revert the code after the merge and it is not required. Will fix it.

You added a Yarn specific cookie option which should be part of the general options instead.
It is added since secure cookie can be supplied when using both Yarn session CLI as well as Flink CLI. I have provided detailed explanation in one of the comments.

You've introduce a new config file to persist the app state. We already have the Yarn properties file for that.
I have provided explanation on why we need new config file in one of the comments. Please take a look.

@mxm - Please take a look when you get a chance?

@vijikarthi I haven't forgotten about your PR. Thanks for the feedback. I'll get back to you today.

CC @uce to check out the network layer changes. This is a very sensitive and performance critical part of Flink. We should be very sure nothing breaks it with the changes.
@vijikarthi Please have a look at the null checks in the network code. I would replace them with checkNotNull and never pass any null values in there. It would be desirable that turned off security doesn't have any overhead with the security support built in.

Addressed multiple application support/Yarn configuration file changes as part of FLINK-4950 patch.

@mxm - Sorry that I have missed to address some of your comments. Attached patch that includes Netty code null precondition validation and fixes the Blob service cookie length issue. Please take a look and see if they are okay? Thanks for your patience.

Thank you for the changes. I wonder, could we remove the cookie header completely for Netty or the BlobServer in case the authorization is turned off? The Netty protocol has a MAGIC_NUMBER which is checked when decoding the message. We could use a different "magic number" to check whether we use the normal or the cookie-based Netty protocol. This would eliminate all the overhead of the cookie transmission. Furthermore, we should strip the cookie from the message once we have verified it is correct.

The Netty logic needs some improvements:

The cookie is added to every single message/buffer that is transferred. That is too much - securing the integrity of the stream is responsibility of the encryption layer. The cookie should be added to requests messages that establish connections only.

Charset lookups and cookie to bytes encoding happens for every buffer, rather than once in an initialization step.

The String to byte conversion is not consistent. Sometimes it uses the default platform encoding, sometimes "UTF-8".

The cookie is added to every single message/buffer that is transferred. That is too much - securing the integrity of the stream is responsibility of the encryption layer. The cookie should be added to requests messages that establish connections only.
I will change the code to address cookie handling right after the SSL handshake using a new handler and drop the cookie passing for every messages. The handler will be added to the pipeline of both NettyClient and NettyServer. Client will send the cookie when the channel becomes active and the server will validate and keep track of the clients that are authorized.
Here is the pseudo-code for Client and Server handlers. Please take a look and let me know if you are okay with this approach and I will modify the code.

public static class ClientCookieHandler extends ChannelInboundHandlerAdapter {

	private final String secureCookie;

	final Charset DEFAULT_CHARSET = Charset.forName("utf-8");

	public ClientCookieHandler(String secureCookie) {
		this.secureCookie = secureCookie;
	}

	@Override
	public void channelActive(ChannelHandlerContext ctx) throws Exception {
		super.channelActive(ctx);

		if(this.secureCookie != null && this.secureCookie.length() != 0) {
			final ByteBuf buffer = Unpooled.buffer(4 + this.secureCookie.getBytes(DEFAULT_CHARSET).length);
			buffer.writeInt(secureCookie.getBytes(DEFAULT_CHARSET).length);
			buffer.writeBytes(secureCookie.getBytes(DEFAULT_CHARSET));
			ctx.writeAndFlush(buffer);
		}
	}
}

public static class ServerCookieDecoder extends MessageToMessageDecoder<ByteBuf> {

	private final String secureCookie;

	private final List<Channel> channelList = new ArrayList<>();

	private final Charset DEFAULT_CHARSET = Charset.forName("utf-8");

       public ServerCookieDecoder(String secureCookie) {
		this.secureCookie = secureCookie;
	}

	@Override
	protected void decode(ChannelHandlerContext ctx, ByteBuf msg, List<Object> out) throws Exception {

		if(secureCookie == null || secureCookie.length() == 0) {
			return;
		}

		if(channelList.contains(ctx.channel())) {
			return;
		}

		//read cookie based on the cookie length passed
		int cookieLength = msg.readInt();
		if(cookieLength != secureCookie.getBytes(DEFAULT_CHARSET).length) {
			String message = "Cookie length does not match with source cookie. Invalid secure cookie passed.";
			throw new IllegalStateException(message);
		}

		//read only if cookie length is greater than zero
		if(cookieLength > 0) {

			final byte[] buffer = new byte[secureCookie.getBytes(DEFAULT_CHARSET).length];
			msg.readBytes(buffer, 0, cookieLength);

			if(!Arrays.equals(secureCookie.getBytes(DEFAULT_CHARSET), buffer)) {
				LOG.error("Secure cookie from the client is not matching with the server's identity");
				throw new IllegalStateException("Invalid secure cookie passed.");
			}

			LOG.info("Secure cookie validation passed");

			channelList.add(ctx.channel());
		}

	}
}

@StephanEwen @mxm - Could you please review the proposed change and let me know if you are okay with it.

@StephanEwen, @mxm  I have updated the documentation changes as suggested, moved common code from BlobUtils to SecurityContext, added new ConfigOptions class for security configurations lookup.

The cookie is added to every single message/buffer that is transferred. That is too much - securing the integrity of the stream is responsibility of the encryption layer. The cookie should be added to requests messages that establish connections only.
I have added a new handler code to front load the secure cookie validation. These handlers are added to both NettyServer and NettyClient pipeline right after the SSL handler is added. I still kept the original code that passes cookie for every message (will remove the logic if you are okay with the handler implementation)
Please review and let me know your feedback.

@vijikarthi ,when you will push this issue to the master? I can help you, if you need any help. Thanks!

Sorry for chiming in a bit late here with this more fundamental question.
I would like to understand from a security architecture, what additional security this shared secret gives us:

If there is no encryption, then this shared secret is not very secure, as it can be sniffed from the network
When there is encryption, isn't the current assumption that all parties have access to the server-side certificate? Would that already be a form of shared secret, meaning that certificate-based authentication as part of the SSL handshake already covers the mechanism of a shared secret?

@StephanEwen The shared secret serves can be considered as an additional security extension on top of TLS integration, thus it designates only an authorized identity to execute actions on a running cluster.

@StephanEwen keep in mind that Flink's current SSL support in Flink doesn't achieve mutual authentication - there's no client certificate there.    With SSL enabled, an untrusted client can launch jobs in your Flink cluster and thus gain access to the Kerberos credential associated with the cluster.
SSL mutual authentication is a good alternative to a shared secret, but at the time we were limited to built-in Akka functionality (which doesn't include mutual auth).   Given the "flakka" fork that's now in place, a pure SSL solution might now be possible (I haven't thought it through completely).
The fact remains that, today, all the secrets known to a Flink job are exposed to everyone who can connect to the cluster's endpoint.
It would be nice to construct a holistic plan that worked out how the Web UI would support authentication and also incorporated FLIP-6.      Both YARN and Mesos interpose a web proxy for the UI with its own limitations, notably no support for SSL mutual auth.

Thanks Eron, that makes a lot of sense.
My first thought would be: Let's add SSL mutual authentication. That seems desirable anyways and we would not need another mechanism (shared secret). Do you know if newer versions of Akka support this mutual auth? We may be able to upgrade if we drop Java 7, or we could see if there is a lightweight way to patch this into flakka.

@vijikarthi I hope you are okay with exploring that option - this is not saying that this pull request is not a good solution, but whenever we have to maintain less code it makes things easier.

@StephanEwen It's absolutely fine with me and I will cancel this PR.

Note to future self: to generate a self-signed certificate, use CertAndKeyGen and see OPENDJ-2247.


Handle single and double quote in csv files identically

As discussed in #105 the serde library does not support multiple signs for escaped sequences.
To be uniform with RDF string handling, single quotes and quotes should both be handled as valid escape sequences.
Example
a, "b,c", 'd,e'

is currently parsed into 4 fields: [ "a", "b,c", "'d", "e'" ], while it should be 3 fields: [ "a", "b,c", "d,e"]
One possible solution is to inject another reader to sanitize the csv input line by line before letting serde csv parse the csv content.

We do not plan to support both " and ' at the same time.


kubelet should rectify corrupt pod status

Forked from #8335
Currently, kubelet sends pod status update whenever it discovers that the newly-generated status differs from the copy in its internal cache. However, it does not check the pod status received from the apiserver at all. What this implies is that if a user or another component changes the pod status via apiserver, kubelet will not correct the status until there is an actual update. We should make kubelet detect corrupt pod status and rectify it.
There are a couple of things need to be ironed out for this:

Kubelet, as of now, filters out pod status update by default, i.e., it will trigger an update only if the pod spec is changed. Kubelet will not be able to view the status it updates in a short-period of time.
When kubelet generates the pod status, it sets StartTimestamp for the pod before storing it into status manager (the internal cache). The timestamp needs to be at the second-level precision to match with the status received from the apiserver (after json marshalling).

What about the case where the pod is in Succeeded or Failed?

Architecturally, is there a ever a future where a field could be defined on Pod.Status whose source of truth is not the Kubelet?

@derekwaynecarr Yes.

We're planning to make the node controller have joint (backup) responsibility for the Ready condition: https://github.com/GoogleCloudPlatform/kubernetes/issues/8335#issuecomment-109051619
We could create a subresource that would enable another controller to set a specific part of the status and/or an annotation. For instance, /binding currently sets spec.nodeName and annotations, but I'd like to be able to update status also, as mentioned in https://github.com/GoogleCloudPlatform/kubernetes/pull/9032#discussion_r31473139

What about the case where the pod is in Succeeded or Failed?

Kubelet ignores pods in the terminated states, so it will not update their status. This behavior can be changed, but I don't see any reason to do that (terminated pods cannot be revived)>

but I'd like to be able to update status also, as mentioned in #9032 (comment)

For this specific case, the pod is not scheduled anywhere, so it is safe for the scheduler to update the pod status.

I think the resource version of a pod that is terminated should be stable as it used to do screwy things to our client watches when the Kubelet updated their status.
Sent from my iPhone

On Jun 5, 2015, at 12:58 PM, Yu-Ju Hong<EMAIL_ADDRESS>wrote:
What about the case where the pod is in Succeeded or Failed?
Kubelet ignores pods in the terminated states, so it will not update their status. This behavior can be changed, but I don't see any reason to do that (terminated pods cannot be revived)>
but I'd like to be able to update status also, as mentioned in #9032 (comment)
For this specific case, the pod is not scheduled anywhere, so it is safe for the scheduler to update the pod status.
—
Reply to this email directly or view it on GitHub.

Repurposing the old issue for a new use case. @freehan is working on transitioning the pod status to not ready if kubelet hasn't updated the node status after 40 seconds. This fits the "a user or another component changes the pod status via apiserver" condition in the original post. If kubelet restarts, it'd by default updating statuses for all the pods. However, if kubelet was disconnected from the apisever due to, e.g., a network partition, once it recovers from that, it wouldn't update the status since its internal cache is always up-to-date.
Off the top of my head, we have two options.

Rectifying the pod status as the original title suggests. This relies on the fact that status is a subresource of pod, and through watching the pods, kubelet can receive the latest status. If this ever changes, kubelet may need to explicitly watch pod status as well.
Instruct kubelet to detect whether apiserver is reachable (e.g., failed to update node status for the past minute, etc). Once kubelet notices that, it'd lock the internal status cache, and reset the version in the cache to forcibly trigger updates (cc @timstclair). The problem with this is that it's less universal and it may race with the node controller to change pod status. This could be mitigated by setting a more conservative threshold, but I am not sure the race could be completely avoided.

/cc @kubernetes/goog-node

Update: I discussed with @timstclair and the conclusion is that we'll go with option (1), and clear the apiStatusVersion if the status from the apiserver differs from what kubelet cached internally.

Add a new pod operation, and sends an update if only status differs so that kubelet [can receive the new update] (https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kubelet.go#L2295).
Upon receiving the new update, kubelet will send the status to StatusManager to compare against the current status in the cache. If the statuses differ, the apiStatusVersion entry is cleared to trigger an update.

It should be noted that this approach

may cause some extra status updates due to watch delay when there are multiple in flight updates
would slightly the kubelet's workload (e.g., checking the statuses). The lock contention in status manager will be higher too.

We may want to test kubelet's performance and resource usage during batch creation of pods.

Close this issue because #18410 has been merged. Feel free to reopen it if any related error happens again.

Close this issue because #18410 has been merged. Feel free to reopen it if any related error happens again.


Load the weights file for multi-gpu training

Hi! I liked your approach and wanted to try it for SISR task, however, I am facing issues while loading the weights file when I want to train it on multiple GPUs. I guess the torch.load() directly is causing the problem here https://github.com/gfxdisp/mdf/blob/85c9ad36734f50e30d162e327194e8dbfa52f0cf/mdfloss.py#L10
Can you please pass it as a model instance where we can load it as model.load_state_dict(torch.load("...")) ?? That might be helpful if anyone wants to train using multiple GPUs. Also can you please share the opt argparse arguments mentioned in the SinGAN/models.py file??
https://github.com/gfxdisp/mdf/blob/85c9ad36734f50e30d162e327194e8dbfa52f0cf/SinGAN/models.py#L19
Please let me know if you have a workaround for this (loading the weights file on multiple GPUs) and it would also be helpful if you could release the training code.
Thanks!

I think we should set the arguments of opt argparse  according to the algorithm that we select in option application= in the main configuration

Hi.
In the implementation we have provided a choice of the number of discriminators (scales) you need in your loss function. For this purpose the discriminators are loaded in the form of a list. nn.DataParallel(Ds) will not work on the list of models. However, you can implement data parallelisation of each model inside the file 'mdfloss.py'. This should be pretty straightforward, as follows:

After you load each scale discriminator as D= Ds[scale]
We can do D = nn.DataParallel(D, device_ids=[0, 1, 2]), depending on the number of devices you have.

Hope that helps


Variable font build target

Updates fontmake submodule, adds build target for variable fonts, and does away with the makefile which was too limiting for passing in build options.

LGTM


AndroidManifest.xml update - Package name fix

react-native link was failing to update the android project with the proper import class path.
This resolves the issue.

thx


Container console command result is displayed as a ladder

After the last update, in any of the docker containers, after entering the commands, the result is displayed as a ladder. At first I thought that there were problems with the environment for entering commands, but in the standard MAC console too.
Docker on MAC OS:

System Version: macOS 10.12.4 (16E195)
Kernel Version: Darwin 16.5.0
Boot Volume: Macintosh HD
Boot Mode: Normal

Docker version:

Version 17.06.0-rc1-ce-mac13 (18169)
Channel: edge
2425473dc2

Diagnostic ID
95CDB1D9-9973-44FE-848F-CD27C7404ACE

I have the same issue

I have the same issue

I have the same issue.
Version 17.06.0-rc1-ce-mac13 (18169)

Fixed in Version 17.06.0-rc2-ce-mac14 (18280)

In the console of the docker container everything works as it should. But, when command executing from the root of the project, the ladder arises again ...

I have the same issue

:(
+1

Fixed in Version 17.06.0-ce-rc5-mac16 (18400)


FirebaseESP8266.h takes high memory, I need lighter version

Hi, I have used FirebaseESP8266.h in my ESP-12F and I figured out it has a high memory usage.
Would you mind can we have a lighter library?

I can't shrink the size of flash mem because we think of available free memory (ram) first then every constant string will store as flash string to save ram usage.
I recommend to use others ESP8266 chips or modules which the overall size is also small e.g. Wemos D1 mini pro.

Yes, its true that ESP-12F is suitable for using the Firebase, But you may need to use other libraries in your code that don't have enough memory left and your esp module is keep going to restart.
I have try my firmware with wemos D1 mini pro.

You should debug rather blame on memory. You may make memory leak with your code or use unhandle memory/variable and leads to error.
The watchdog reset may happen when you 're running the blocking code.
Your request is not quite clear what you're talking between flash or ram. If you're new to esp, you need to learn how to debug and decode the stack trace.

Ok I just known the potential cause of low memory issue.
The issue is from the reserved Bearssl rx buffer is too large (16k), now I fixed it already.
You can update the library to v2.6.6 from Git version.

Thanks for your considering
well for clear the issue I take a some screenshot of Sketch uses & Global variables use after verifying my arduino code.

my Arduino code without including "FirebaseESP8266.h"
==>>
Sketch uses 403788 bytes (38%) of program storage space. Maximum is 1044464 bytes.
Global variables use 33088 bytes (40%) of dynamic memory, leaving 48832 bytes for local variables. Maximum is 81920 bytes.

my Arduino code after just including "FirebaseESP8266.h"
==>>
Sketch uses 423244 bytes (40%) of program storage space. Maximum is 1044464 bytes.
Global variables use 58984 bytes (72%) of dynamic memory, leaving 22936 bytes for local variables. Maximum is 81920 bytes.

after updating FirebaseESP8266 to version 2.6.6
==>>
Sketch uses 423244 bytes (40%) of program storage space. Maximum is 1044464 bytes.
Global variables use 58984 bytes (72%) of dynamic memory, leaving 22936 bytes for local variables. Maximum is 81920 bytes.

That is estimation.
You should check your free heap when running.

As I see the latest library cannot help you to gain more free memory.
This because you're using the old esp8266 core sdk version 2.4.x that use old WiFi client (axTLS) instead of BearSSL.
Please update your board (esp8266 core sdk) to the latest 2.5.2 to gain more memory.


Add resizePvc command into alert manager

Q
A

Bug fix?
no

New feature?
yes

API breaks?
no

Deprecations?
no

License
Apache 2.0

What's in this PR?
This implements the resizePvc command from alertmanager. This will add the additional space set in the alert to the existing pvc for the specific broker it alerts for.
Why?
I have a setup where we want to retain data by time and not size, we tried the addPvc but that is slow and more disruptive than just resizing the pvc. I have tested this with GKE and EKS and it works as expected.
Checklist

[x] Implementation tested
[x] Error handling code meets the guideline
[x] Logging code meets the guideline

I changed UpdateCR to be public and used it instead of the other method.
I also added a 3rd commit that makes the StorageConfig unique since we are appending the ConfigGroups to the end. I can make this a different PR if we think it exceeds the scope of this. I noticed they where not unique in testing my resizePvc command in dev

Thanks, I don't think the dedup is the right thing to do here. I think we need to merge these two configs like we do in case of other config values. That way we can set precedence. broker -> configgroups.

This is post the config merge
it currently does:
       err := mergo.Merge(bConfig, clusterSpec.BrokerConfigGroups[broker.BrokerConfigGroup], mergo.WithAppendSlice)
	if err != nil {
		return nil, errors.WrapIf(err, "could not merge brokerConfig with ConfigGroup")
	}

which appends the storage configs from the BrokerConfigGroup to the end of the ones from the broker specific config. It currently inflate bConfig via:
	bConfig := &v1beta1.BrokerConfig{}
	if broker.BrokerConfigGroup == "" {
		return broker.BrokerConfig, nil
	} else if broker.BrokerConfig != nil {
		bConfig = broker.BrokerConfig.DeepCopy()
	}

so before we use mergo.Merge we already have the []StorageConfig initialize with with the broker specific []StorageConfig
The "dedup" logic makes broker specific configs take precedence over the ConfigGroup.
Unless I misunderstanding something; this seems to be the desired behavior. Without the reconciliation loop fails trying to reduce the PVC size (which no platform I know of outside of NFS allows for lowering the pvc size) because the []StorageConfig has both the StorageConfig from the brokerConfig and from the brokerConfigGroup I can get rid of the deduping but we would need to solve the reconciliation failure.

Sorry for the delayed response. I tried and you are right there will be duplicate values in the []StorageConfig slice. The main reason this happens is because of how mergo handles slice merges. By default mergo merge policy regarding to slice is to overwrite it with the value which is coming from the second parameter which our case is clusterSpec.BrokerConfigGroups[broker.BrokerConfigGroup]. However we added a merge option which tells mergo to append slices instead of overwriting it. This causes the duplication problem.
I think we have an ultimate option here is to change the []StorageConfig value from slice to map[string]*corev1.PersistentVolumeClaimSpec because that way mergo will take care of the merging properly.
But in the meantime maybe this dedubing can work as well. Thanks for pointing this out:)

I would find a way to check the underlying StorageClass since not all SCs support volume expansion by default e.g. amazon's gp2 support for expansion is disabled by default

Note the unit test build is failing due to https://github.com/banzaicloud/kafka-operator/pull/428

@nikore can you rebase your PR such as it picks up https://github.com/banzaicloud/kafka-operator/commit/bae79b91ecba085fe4426e66d3b06c04eef13ec6. It should address the license check issue.

LGTM, thanks @nikore

LGTM, thanks @nikore