Threadsafe RPC Manager for Threaded Network Polling

This PR makes the RPC Manager threadsafe and allows polling network events inside a thread, to prevent as ex. loose connection when main thread is busy.
We can also integrate a thread inside the engine, but i blv that people can handle it by them self.
Example of an Networking Thread in Mono:

cc @Faless

I don't think  this is enough to make the class thread safe, in fact, this just converts rpc to rpc.call_deferrred() when inside a thread (which should also be doable in GDScript).
To properly make it thread safe we should review the other functions, including _process_rpc, _process_get_node, etc, possibly including the higher level MultiplayerAPI.
I don't have a clear plan sadly, but top of my head I would imagine using some sort of buffered queue where the thread only handles the lower level "socket" connection, at least until we can make tree operation thread safe (4.1+) and we can then start thinking of doing part of the processing in the thread too.

_process_rpc

Thats right, actually it handles only the polling.  "Threadsafe RPC Manager for Threaded Network Polling".
So for sure we have to extend also the other functions. Currently its just to prevent a disconnect of clients in the case that the main thread are hangs.

Thanks for contributing to Godot's networking! The new replication side of things hasn't stabilized yet, for example, there are likely large changes incoming with this:
https://github.com/godotengine/godot/pull/55950
As long as thats the case, its somewhat hard for us to test and take contributions, as this code is moving fast and changing. I'd suggest to wait a bit for this area to stabilize, maybe for Godot 4 beta (or late alpha) for working on this.
Thanks still!


fix override item

This fixes the mod_origin of reregistered items being "??"
It's problematic when using the unified inventory mod.
Look a the forum topic for more detail.
https://forum.minetest.net/viewtopic.php?f=6&t=29806

I will close this, since it doesn't look like this repository accepts PRs. Of course, you are free to open it again.

I will close this, since it doesn't look like this repository accepts PRs. Of course, you are free to open it again.


Remove duplicate TMOUT #70

Signed-off-by: James Beckett<EMAIL_ADDRESS>Overall Review of Changes:
Avoid shell warning about readonly TMOUT at start
Issue Fixes:
#70
How has this been tested?:
N/A

This was added to PR https://github.com/ansible-lockdown/UBUNTU20-CIS/pull/74 that addressed a lot of fixes.  This has been merged to main.  Thanks @hackery for the find.


rustc 1.10.0-nightly (2174bd97c 2016-04-14)

Coverage decreased (-0.7%) to 98.789% when pulling 4c03582c1ef666d67da14c49b8f6b3ba1e92021f on update-to-nightly into 4155b941bb6ee4a61a792143decee8f3ac7c16b9 on master.


[Task]: refactor approach of button detect form widget

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks

need to fix abstraction leak refer here

Quoting @riodeuno

With that said, if it is possible for us to revert to using the onAddChild mechanism in the future as described in https://github.com/appsmithorg/appsmith/issues/10659, I'm ok with moving ahead with this for now. Let's make sure to refer to https://github.com/appsmithorg/appsmith/issues/10659 in the comments above this implementation, and move forward.


How to implement initial data fetch

If I correctly understand the intention of this library, it is supposed to move decision making as close to reducers as possible. Classic example of React+redux flow is to fetch data needed to render a React component from componentDidMount lifecycle hook in the component itself:
class DataViewer extends React.Component {
  componentDidMount() {
    this.props.dispatch(fetchDataIfNeeded());
  }

  render() {
    return (
      <div>
        { this.props.data ?
          <DataList data={ this.props.data }/> :
          <Preloader />
        }
      </div>
    );
  }
}

If we try to move this logic inside reducer, we can add fetchDataIfNeeded to Effect returned after an action leading to displaying this component occurred, like in this example.
Additionally, we have to handle the initial state leading to display DataViewer without any action made yet. Example situation:

The initial state is restored from URL.
The initial state is passed to createStore.
We don't want to handle data fetching manually, but instead, we assume reducer to check if we have enough data to show DataViewer and return a loop with fetchDataIfNeeded if it is the case.

The question is how to handle this init step in reducer. Using @@INIT action is considered an anti-pattern. @@ReduxLoop/INIT happens later if we already returned initial effect.
So, what is the suggested way to decide the need of initial effects?

i think the code you have (using componentdidmount) makes sense. the component needs the data, so it should be the one that asks for it.

@bdwain, as we are trying to implement more Elm architecture principles around Redux (and redux-loop makes a great job), the view is supposed to be as dumb as possible. If we use some dumber alternative to React without such lifecycle hooks, wich would be the place for such data fetching logic right after store init?

If you want to do it right after store init you could just dispatch the action manually right after you create the store.
const store = createStore(...) store.dispatch(createFetchInitialDataAction())
On May 17, 2016, 4:15 AM -0500, Roman<EMAIL_ADDRESS>wrote:

@bdwain(https://github.com/bdwain), as we are trying to implement more Elm architecture principles around Redux (and redux-loop makes a great job), the view is supposed to be as dumb as possible. If we use some dumber alternative to React without such lifecycle hooks, wich would be the place for such data fetching logic right after store init?
—
You are receiving this because you were mentioned.
Reply to this email directly orview it on GitHub(https://github.com/raisemarketplace/redux-loop/issues/55#issuecomment-219662849)

If you want to do it right after store init you could just dispatch the action manually right after you create the store.
const store = createStore(...)
store.dispatch(createFetchInitialDataAction())

@bdwain's suggestion is typically how we handle it at Raise. This let's make use of dispatch being modified to return a promise as well, in case you want to wait for your initial data fetch to complete before rendering or doing aything else.

I'd like to push this off as a task for version 4.0 or 3.1 or whatever it ends up being


https://developer.mozilla.org/zh-CN/docs/Learn/JavaScript/First_steps/zh-CN/docs/Learn/JavaScript/First_steps/Variables

Request type

[] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x ] Correction or update

Details

关于 let 和 var 之间的区别 原文链接失效。

Sorry, what is the problem here?

@chrisdavidmills The link pointed at by the arrow is invalid

@SamoZ Can you confirm what page this bad link is found on? I couldn't find it.

@chrisdavidmills
https://developer.mozilla.org/zh-CN/docs/Learn/JavaScript/First_steps/A_first_splash#添加变量以保存数据

@chrisdavidmills
https://developer.mozilla.org/zh-CN/docs/Learn/JavaScript/First_steps/A_first_splash#添加变量以保存数据

Great, thank you.
I have found the broken link and fixed it.


Explicit positive definite

The code is much faster if positive definiteness is guaranteed for matrix A. It would be helpful if the settings accept a command line option for PD as to perform numerical optimization.

This should actually just regard symmetric matrices.


open/close tooltip controller

This PR is very useful to help with form validation.
It allows having a condition of not opening it if the value of data-tip is false. Please see this example I created to demonstrate its use.
https://svelte.dev/repl/79a08e408d9e464aad574b46fa9e1feb?version=3.55.0

Thank you for the PR.
I think having the false value for a data attribute is not a good idea (actually having the word false as a string in the HTML). So what do you think about conditionally rendering the data-tip (Svelte syntax: data-tip={error || null}) and then having this CSS to hide .tooltips that have not data-tip:
.tooltip:not([data-tip]):hover:before,
.tooltip:not([data-tip]):hover:after {
  visibility: hidden;
  opacity: 0;
}

https://svelte.dev/repl/9f8ceaff8bf041068027373441972e1c?version=3.55.0

Thank you for the PR. I think having the false value for a data attribute is not a good idea (actually having the word false as a string in the HTML). So what do you think about conditionally rendering the data-tip (Svelte syntax: data-tip={error || null}) and then having this CSS to hide .tooltips that have not data-tip:
.tooltip:not([data-tip]):hover:before,
.tooltip:not([data-tip]):hover:after {
  visibility: hidden;
  opacity: 0;
}

https://svelte.dev/repl/9f8ceaff8bf041068027373441972e1c?version=3.55.0

Great, that solves it too 😁
It's just that in my complete code in typescript, the error control variable has the type string | boolean.
I'll make a new commit with your suggestion, thanks 👍

Thank you for the PR. I think having the false value for a data attribute is not a good idea (actually having the word false as a string in the HTML). So what do you think about conditionally rendering the data-tip (Svelte syntax: data-tip={error || null}) and then having this CSS to hide .tooltips that have not data-tip:
.tooltip:not([data-tip]):hover:before,
.tooltip:not([data-tip]):hover:after {
  visibility: hidden;
  opacity: 0;
}

https://svelte.dev/repl/9f8ceaff8bf041068027373441972e1c?version=3.55.0

Hey @saadeghi,
Only now did I realize that my original example was wrong. For some reason, when copying from my original code, the error occurred.
The correct one would be this one, which simplifies the use of the tooltip using somment like:
(Svelte syntax: data-tip={error})  stead of (Svelte syntax: data-tip={error || null})
This should be the correct code in my PR:
[data-tip=false]:hover:before,
[data-tip=false]:hover:after {
  visibility: hidden;
  opacity: 0;
}

Stead of:
[data-tip="false"]:hover:before,
[data-tip="false"]:hover:after {
  visibility: hidden;
  opacity: 0;
}

If you agree, I'll clean up the mess I made in the first commit 😅

Thank you for the PR. I think having the false value for a data attribute is not a good idea (actually having the word false as a string in the HTML). So what do you think about conditionally rendering the data-tip (Svelte syntax: data-tip={error || null}) and then having this CSS to hide .tooltips that have not data-tip:
.tooltip:not([data-tip]):hover:before,
.tooltip:not([data-tip]):hover:after {
  visibility: hidden;
  opacity: 0;
}

https://svelte.dev/repl/9f8ceaff8bf041068027373441972e1c?version=3.55.0

Hey @saadeghi
I better understood what caused the false value to become "false" in my PR. It was the prettier I have in vscode, with an autosave option.
What I understood was the following:
"false" in the context of CSS is a quoted boolean.
"'false'" in the CSS context is a string.
At first glance we seem to think it's a string/word, but CSS treats it as a quoted boolean.
The Prettier adds quotes around the values. So I decided to check that he was right and that it complies with the CSS specification and how the value is handled. I created some variations around boolean values. If you can take a look please:
https://svelte.dev/repl/8823dbfd36ed44e4a91aecb92ad9a178?version=3.55.0
With my original proposal we can use the Svelte syntax like this:
(Svelte syntax: data-tip={error})
Rather than:
(Svelte syntax: data-tip={error || null})
What do you think?

Thank you for the PR. I think having the false value for a data attribute is not a good idea (actually having the word false as a string in the HTML). So what do you think about conditionally rendering the data-tip (Svelte syntax: data-tip={error || null}) and then having this CSS to hide .tooltips that have not data-tip:
.tooltip:not([data-tip]):hover:before,
.tooltip:not([data-tip]):hover:after {
  visibility: hidden;
  opacity: 0;
}

https://svelte.dev/repl/9f8ceaff8bf041068027373441972e1c?version=3.55.0

Hey @saadeghi,
I was in doubt about which style was the best, but I realized some problems with my original proposal.

Thank you


Add a wiki: Dustloop Wiki

An anonymous user has submitted a new wiki via our submission form.
Link to origin wiki: https://guiltygear.fandom.com/wiki/Guilty_Gear_Wiki
Link to destination (independent) wiki: https://www.dustloop.com/w/Main_Page

This has been added and will be released in v1.3.0


⚠ ETF has degraded performance

In ca4b2f5, ETF (https://markets.hankyung.com/equity-product/etf) experienced degraded performance:

HTTP code: 200
Response time: 8910 ms

Resolved: 한경주요지수-코스피 performance has improved in f6708e7.


Mismatch between CPU and NPU in simple Conv2D

Hi,
We have been working with the VX delegate to execute TFLite models on the NPU of the i.MX 8M Plus which is a VeriSilicon's VIPNano-SI+. Doing so, we have found that there are mismatches between the execution of the model in CPU and in NPU, even with a model with a single Conv2D with a 3x3 kernel and padding 'same'. This plot shows the distribution of this mismatch.

Even more, this mismatch errors propagate along different layers across the  model. This file (conv-sequence.zip) contains the descomposition of a model with 20 Conv2D layers into 20 models, each of them adding one layer to the previous one, allowing the measurement of the mismatch after each of the layers. The following plot shows this propagation across the model.

Is there a way to avoid this mismatch? Is this a known issue with this NPU?
We are using TFLite Runtime <IP_ADDRESS> and the forked iMX delegate under version lf-5.15.71_2.2.0.

@deneriz-veridas @jetxeberria ,
Thanks for your feedback. Very nice data analysis. Our NPU integer math is not bit-accurate compare to tflite CPU implementation - for single layer 1-bit distance.
In our practise, the difference doesn't impact the top-1 accuracy in mobilenet-v1.   we usually check the result from application POV such as label/box, not compare the absolute error between cpu and npu.

Hi @sunshinemyson,
Thanks for having a look to this issue. I understand this errors can have minimal impact in classification applications. However, we working with a model that generates embeddings, which we use to compute the distance between them. In this application, the errors are much more important.
Could you extend more on the bit-accuracy of the NPU integer math?  Do you have characterized when this happens? We are looking for a way to avoid or mitigate this. Thanks in advance!


Use default variant for submit buttons

This PR makes the confirmation/submit type of action buttons stand out, by changing them into a "default" variant, instead of "outline".

Perhaps also the "Add user" button in /admin/users and the "Save changes" button in /settings?section=profile should be changed


Sticky data-hover on MenuTrigger component when its children changes

Provide a general summary of the issue here
When user clicks on the button to open the menu in the following code, the <Button /> will have a sticky data-hover that won't go away even even when the user closes the menu, click elsewhere, or pretty much anything. The only thing that will remove data-hover is for the user to hover the button again and un-hover it.
function DropdownMenu() {
  const [isOpen, setIsOpen] = useState(false);
  const Icon = isOpen ? Close : Open;

  return (
    <MenuTrigger isOpen={isOpen} onOpenChange={setIsOpen}>
      <Button>
        <Icon />
      </Button>
      <Popover>
        <Menu>
          <MenuItem id="a">A</MenuItem>
          <MenuItem id="b">B</MenuItem>
        </Menu>
      </Popover>
    </MenuTrigger>
  );
}

I tried the same code without a dynamic <Icon />, it works as expected without any problems.
🤔 Expected Behavior?
There should be no data-hover on <Button /> unless the user closes the menu and hovers the button again.
😯 Current Behavior
When user clicks on the button to open the menu, the <Button /> will have a sticky data-hover that won't go away even even when the user closes the menu, click elsewhere, or pretty much anything. The only thing that will remove data-hover is for the user to hover the button again and un-hover it.
💁 Possible Solution
I'm not sure what's causing this internally but without changing children, it works as expected.
🔦 Context
No response
🖥 Steps to Reproduce
Run this code, click the button with mouse to open menu and see data-hover being sticky in element inspector.
function DropdownMenu() {
  const [isOpen, setIsOpen] = useState(false);
  const Icon = isOpen ? Close : Open;

  return (
    <MenuTrigger isOpen={isOpen} onOpenChange={setIsOpen}>
      <Button>
        <Icon />
      </Button>
      <Popover>
        <Menu>
          <MenuItem id="a">A</MenuItem>
          <MenuItem id="b">B</MenuItem>
        </Menu>
      </Popover>
    </MenuTrigger>
  );
}

Version
react-aria-components v1.1.1
What browsers are you seeing the problem on?
Chrome
If other, please specify.
I didn't test on other browsers but I suspect it will have the same issue
What operating system are you using?
macOS Sonoma
🧢 Your Company/Team
No response
🕷 Tracking Issue
No response

Seems unrelated to the changing children. I tried changing the children to text which would change and didn't see the issue. I also tried keeping it as one image that didn't change. Again, didn't see the issue.
I then tried setting pointerEvents: 'none' on the image, that also fixed the issue. So I think you can just do that to your icons.


No more tracking since June 21.

Dear all,
sinice June 21. there is no more tracking for my Account (TRO#05189)
Could you assist me? :-)
Thanks for your great work!
Regards,

Have you updated to v 1.7.9?
Try reinstall, manual reset button in the app, set date format in the app settings

Date Format was missing, thanks a lot!


Implementation of the 10^23 fluence experiment for the Ogorodnikova TDS case

referenced this implementation
solves #21 .
Oddly enough, this implementation appears to have half the fluence present in the original paper. Please have a look.

Can't inspect this as the docs don't compile

We need to get others input on this since in theory you wouldn't have two completely different models for this. The architecture of this complete validation case should be:
def run_festim_model(fluence):
    ...

for fluence in [1e22. 1e23]:
    result = run_festim_model(fluence)
    plot_tds(result, label=fluence)

Completely agree, I'll try something out but I'll have this as low priority until they respond.


Invalid Error: 'Unable to set hardware breakpoint, all available breakpoint units are in use'

Describe the bug
When setting and clearing breakpoints, a few changes will eventually result in Unable to set hardware breakpoint, all available breakpoint units are in use error, even though fewer than the max (8 in my case) are being set.
** Discussion **
I traced this down to the fact that the Core::state::breakpoints is not cleared by clear_all_hw_breakpoints()
Before I fix it, I'd like to understand why&if Core::state::breakpoints vector is necessary. Is there something that that can't be done without it, or can we replace it with hardware queries, in favour of simplicity and reliability?
** Additional Question**
I noticed that  clear_all_hw_breakpoints() and other methods call self.inner.clear_breakpoint(), while there is also  a local clear_hw_breakpoint() - this has a direct impact on the lack of maintenance of the Core::state::breakpoints. Is this a redundancy that I can cleanup, or is this there for a purpose?

The breakpoints in Core::state::breakpoints are only tracked to reduce the amount of queries we have to do.
I think it's a good idea to remove the list breakpoints to increase reliability. If we discover later that the performance suffers too much, we can add some caching again. For now reliability is more important.
I don't think the redundancy is there on purpose.

@Tiwalun ... I have an additional question. CoreState only has an id and breakpoints, so it would seem to make sense to remove CoreState as well ... BUT ... that would alter Core API in a breaking way. Any recommendations?

I think the id is still useful to have, so I wouldn't remove the CoreState.

@Tiwalun : Additional question. set_breakpoint() will set a hw breakpoint, irrespective of whether one already is set at a different index. Should incur the register read overhead to look for existing hw breakpoints at the same address before we set the new one?

@Tiwalun and @Yatekii  ... I am not sure who to ask, but I've fixed this for the m4.rs. It requires a trait CoreInterface::get_hw_breakpoints to be implemented for the other architectures. I can 'guess' my way around, but have no way of testing these. Is there someone who can help me with those?

We can test it for M0 for sure, M33 is trickier as it is not well tested anyways. The linked branch does not seem to contain any commits for this tho?

@Yatekii  ... the commit is there now. The new trait has an implementation for m4.rs, and a default todo!() implementation for the other architectures.

@noppej Can you please make a PR? Can just be as a draft, but that would make it easier to discuss, then we can also add comments to the changes directly.


Fix USB enumeration problem on macOS.

The pico-ice board does not appear as an USB device on macOS with default firmware versions 1.3 and 1.4.  The logs indicate that USB enumeration fails:
kernel: (AppleUSBXHCI) AppleUSBXHCIDevice: AppleUSBXHCIDevice::transferEvent: no endpoint 1 for event 0x0000010000003700 1b000000 01018001
kernel: (IOAccessoryManager) IOPortTransportState::setNominalSignalingFrequencies(): [Port-USB-C@1: USB2] Setting nominal signaling frequencies... (nominalSignalingFrequenciesHz: YES, nominalSignalingFrequenciesHz.count: 1)
kernel: (AppleUSBXHCI) AppleUSBXHCIRequest: AppleUSBXHCIRequest::finish: transfer completed with status 0xe00002ed
kernel: (IOUSBHostFamily) IOUSBHostDevice@00100000: IOUSBHostDevice::start_block_invoke: device descriptor fragment is invalid
kernel: (IOUSBHostFamily) IOUSBHostFamily::validateEndpointMaxPacketSize: USB 2.0 5.[5-8].3: endpoint 0x00 invalid wMaxPacketSize 0x0000
kernel: (IOUSBHostFamily) usb-drd0-port-hs@00100000: AppleUSBHostPort::enumerateDeviceComplete_block_invoke: enumeration failed
kernel: (IOUSBHostFamily) usb-drd0-port-hs@00100000: AppleUSBHostPort::terminateDevice: destroying 0x0000/0000/0000 (IOUSBHostDevice): enumeration failure
kernel: (IOUSBHostFamily) IOUSBHostDevice@00100000: IOUSBHostDevice::start_block_invoke: device will not be registered for matching

The tests were done on an M2 MacBook with macOS 14.1.

This was introduced with commit 5f37b79.  The problem is that the delay in the main loop causes the RP2040 to send a lot of NAK responses and the Mac host gives up on the enumeration.  I reproduced the same situation with the dev_hid_composite example by adding a sleep_ms(100) in the main loop.  A solution is to ensure that USB enumeration has completed before going into the main loop:
while (!tud_ready())
  tud_task();

while (true) {
  // main loop
}

Such an extensive review! I think this is what we are expected to do for TinyUSB. I will merge it here first, but will consider propagating it further to ice_usb_init().
Thank you for the fix!

This got incorporated into the new release, along with other fixes. Thank you for this patch!
https://github.com/tinyvision-ai-inc/pico-ice/releases/tag/pico-ice-default-v1.5


NET::ERR_CERT_AUTHORITY_INVALID

Google Chrome also prompts NET::ERR_CERT_AUTHORITY_INVALID。

楼上和我得情况一下，也是这个错误。我也按照文档将CA导入到windows的证书管理中，但还谷歌浏览器还是提示不信任！！！

@mycloudedu Hello. In the Windows operating system, select Trusted Root Certification Authorities for the certificate storage type.（您好，如果是Windows系统环境下，安装时证书存储类型，请选择“受信任的根证书颁发机构”。）

@peijs Hello. In the Windows operating system, select Trusted Root Certification Authorities for the certificate storage type.（您好，如果是Windows系统环境下，安装时证书存储类型，请选择“受信任的根证书颁发机构”。）

@hexabyte23 Hello. In the Windows operating system, select Trusted Root Certification Authorities for the certificate storage type.（您好，如果是Windows系统环境下，安装时证书存储类型，请选择“受信任的根证书颁发机构”。）

Hello. In the Windows operating system, select Trusted Root Certification Authorities for the certificate storage type. Because the certificate store is automatically selected by default based on the certificate type, it is not stored and categorized to the root certificate authority. From the visa document to the trust mechanism.（您好，如果是Windows系统环境下，安装时证书存储类型，请选择“受信任的根证书颁发机构”。因为默认根据证书类型自动选择证书存储并不会存储和归类到根证书颁发机构。自签证书自信任机制。）

你好，我选择就是受信任的根证书颁发机构
---- Replied Message ----
| From | Jack @.> |
| Date | 08/17/2023 23:46 |
| To | ljq/gen-tlsv3-san-ca @.> |
| Cc | peijs @.>,
Mention @.> |
| Subject | Re: [ljq/gen-tlsv3-san-ca] NET::ERR_CERT_AUTHORITY_INVALID (#1) |
Hello. In the Windows operating system, select Trusted Root Certification Authorities for the certificate storage type. Because the certificate store is automatically selected by default based on the certificate type, it is not stored and categorized to the root certificate authority. From the visa document to the trust mechanism.（您好，如果是Windows系统环境下，安装时证书存储类型，请选择“受信任的根证书颁发机构”。因为默认根据证书类型自动选择证书存储并不会存储和归类到根证书颁发机构。自签证书自信任机制。）
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

测试后效果还是一样
---- Replied Message ----
| From | Jack @.> |
| Date | 08/17/2023 23:46 |
| To | ljq/gen-tlsv3-san-ca @.> |
| Cc | peijs @.>,
Mention @.> |
| Subject | Re: [ljq/gen-tlsv3-san-ca] NET::ERR_CERT_AUTHORITY_INVALID (#1) |
Hello. In the Windows operating system, select Trusted Root Certification Authorities for the certificate storage type. Because the certificate store is automatically selected by default based on the certificate type, it is not stored and categorized to the root certificate authority. From the visa document to the trust mechanism.（您好，如果是Windows系统环境下，安装时证书存储类型，请选择“受信任的根证书颁发机构”。因为默认根据证书类型自动选择证书存储并不会存储和归类到根证书颁发机构。自签证书自信任机制。）
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

@hexabyte23 @peijs @mycloudedu By the way，due to the security policy design of Firefox, you need to import the visa from the browser certificate management to the certificate authority to be trusted by the browser. （另外补充一下，因火狐浏览器的安全策略机制设计，需要从浏览器证书管理导入自签证书到证书颁发机构才能被浏览器信任，操作方式）：https://github.com/ljq/gen-tlsv3-san-ca/blob/main/images/firefox-tls.png

If you have any other questions, please contact author.
WeChat: labsec
Email<EMAIL_ADDRESS>


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


close reason should be optional and options.shouldRetry -> bool as a replacement for isFatalConnectionProblem

This PR fixes 2 problems

Server can close connection without providing any reason. With current implementation this will throw an error because  reason: socket.closeReason! is expected to exists.
Since the javascript library implementation is the main reference, they introduce shouldRetry: boolean option and deprecated isFatalConnectionProblem

Based on their documentation: https://github.com/enisdenjo/graphql-ws/blob/master/src/client.ts , shouldRetry can override fatal close code which is the default implementation.
   * The library classifies the following close events as fatal:
   * - _All internal WebSocket fatal close codes (check `isFatalInternalCloseCode` in `src/client.ts` for exact list)_
   * - `4500: Internal server error`
   * - `4005: Internal client error`
   * - `4400: Bad request`
   * - `4004: Bad response`
   * - `4401: Unauthorized` _tried subscribing before connect ack_
   * - `4406: Subprotocol not acceptable`
   * - `4409: Subscriber for <id> already exists` _distinction is very important_
   * - `4429: Too many initialisation requests`
   *
   * In addition to the aforementioned close events, any _non-CloseEvent_ connection problem
   * is considered fatal by default. However, this specific behaviour can be altered by using
   * the `shouldRetry` option.

Sometimes we make updates to our server and we need to reset the program. On closing server sends close code 1002 and no reason.
This way we can override if we choose to to reconnect once the server is rebooted. This will also make the library in line with the javascript equivalent .
PS. I know this might be confusing, but this PR is for the new websocket protocol: graphql-transport-ws from the library graphql-ws

@juancastillo0 what do you think?

Hi! Looks great! The implementation is a little different form the reference, but the differences make sense. There are no additional tests, however the changes are kind of incremental.
Not sure if we should treat it as a breaking change, since the close reason was non-nullable. We could also make it non-null and pass an empty String (or the close code as a String) when the server does not return a reason, but I personally don't like it. And I suppose it would still be a breaking change since the TransportWsClientOptions has a new field and it could be implemented, but I believe it would be less common.
If we make a breaking change maybe we could accommodate other changes like this one https://github.com/gql-dart/gql/issues/411#issuecomment-1666551422 and I am not sure what is the status of this PR https://github.com/gql-dart/gql/pull/412.
In general I think it could be merge, not sure what you think about the test and the breaking change.

@catapop84 please pull the latest changes from master to CI succeeds

@knaeckeKami done

@knaeckeKami can you try one more time. Should be valid this time.


Apple iOS and iPadOS 18 "dark icon" support

with the changes that Apple announced for icons in iOS and iPadOS 18 the other day, I'm just wondering if there are any plans to update this asset generator to cater for this?
I suspect that, much like myself, many people are building hybrid mobile apps because we don't have access to a Mac for development... so while I've been able to use Android Studio to maintain my Android app icons, I cannot use Xcode to maintain iOS icons.
just for easy reference, the updated design specs for these icons can be seen here: https://developer.apple.com/design/human-interface-guidelines/app-icons/#Platform-considerations

+1

The iOS update just went live that supports dark mode icons. We would love an update on this to support dark mode.

ok, so... on a positive note, using iOS Simulator to test my current apps in iOS 18, I can safely say that no "special" modifications are necessary for iOS 18 to be able to tint app icons. it simply takes a greyscale version of the default icon, and applies the custom tint colour to anything "white" in the image.
unfortunately though, I cannot work out how to get the @capacitor/assets tool to handle the output of this additional app icon asset. I've been looking through the code for a few hours and now I'm more confused than when I started.

with that said, I have discovered a few things...
looking at the sample icons from this Figma file:

the default "light" icon has no transparency, with a solid coloured background.
the "dark" icon has transparency, with no background behind the icon.
the "tinted" icon has no transparency, with a black background behind the white icon.

I tested these inside my test Xcode project and running in iOS Simulator I do see the correct icons when I switch between the "light", "dark" and "tinted" styles.
now the ios/App/App/Assets.xcassets/AppIcon.appiconset/Contents.json file that this tool generates only contains a single "universal icon" entry, specifically as follows:
{
  "images": [
    {
      "filename"<EMAIL_ADDRESS>      "idiom": "universal",
      "platform": "ios",
      "size": "1024x1024"
    }
  ],
  "info": {
    "author": "xcode",
    "version": 1
  }
}

whereas the same file in a project created by Xcode defaults to three entries, as follows:
{
  "images" : [
    {
      "filename" : "Icon-Light-1024x1024.png",
      "idiom" : "universal",
      "platform" : "ios",
      "size" : "1024x1024"
    },
    {
      "appearances" : [
        {
          "appearance" : "luminosity",
          "value" : "dark"
        }
      ],
      "filename" : "Icon-Dark-1024x1024.png",
      "idiom" : "universal",
      "platform" : "ios",
      "size" : "1024x1024"
    },
    {
      "appearances" : [
        {
          "appearance" : "luminosity",
          "value" : "tinted"
        }
      ],
      "filename" : "Icon-Tinted-1024x1024.png",
      "idiom" : "universal",
      "platform" : "ios",
      "size" : "1024x1024"
    }
  ],
  "info" : {
    "author" : "xcode",
    "version" : 1
  }
}

as far as I can tell no other configuration changes are required to make tinted icons work in iOS 18. so for the moment at least, it seems that people without access to Xcode might need to configure these icon assets manually..
I'll keep digging, but I can't make any promises.

@markemer I know you've probably got a lot on your plate, but is dark mode icon support something Ionic will take a look at?
With iOS 18 rolling out now, where icons may be dark, it would be neat to support it.


fix: don't apply toString() to json

Currently, each column value is turned to String via .toString(), but when this gets applied to a Map/json the corresponding string isn't a valid string presentation of the map. So decoding it again with json.decode() fails. I removed the .toString() call, because it's either a Map or a String. If it's a bool, it gets recognized as such either way later on in toBoolean called in convertCell()
I see it got already discussed in #30

Thanks. Should I fix the relative imports too? I think the dynamic linter fails are hard to fix.

Yeah I know, but I can add this if you want to.

Any updates?


mount command should use its own path to find sub-commands

See https://github.com/chromium/axiom/blob/master/lib/wash/exe/mount.js#L88
  var fsMountCmd = new Path('jsfs:/exe/mount.' + fsType);

The code currently a hard-coded path. It should use cx.path as the basis for creating the name of the sub-mount commands.

Makes sense. I'll fix this.


updated symlink endpoint

This fixes the bug #429

Sorry, accidentally pushed to this branch on my fork. Will reopen with correct fix.


cell-type specific apoptotic process

"cell-type specific apoptotic process" is a 'meta-term' - impossible to define logically: all apoptosis occurs in some specific cell type.  I'd favour getting rid of it.
More immediately, this is a problem for classification of classes of the form 'X cell apoptotic process'. Many terms that should do not sit under this node:

These generally have logical definitions in which the genus is 'apoptotic process'

Others use the more specific term as the genus:

As a result, we have quite a number of ETINES for these terms and their regulation equivalents:
e.g. GO:2000352	negative regulation of endothelial cell apoptotic process	GO:1904036	negative regulation of epithelial cell apoptotic process
Whether or not 'cell-type specific apoptotic process' is obsoleted, the same genus needs to be used in all cases for these.

I guess the question is, do all cell types use the same proteins for apoptosis, or at least to 'regulate' apoptosis? My gut reaction is no, specifically for the T and B cells apoptosis is triggered to remove any cells which are auto-antigenic. With more diseases being recognised as auto-immune related I would request some caution before deleting all of these terms.

Hi @RLovering ,
I’m afraid there may have been some confusion. David is not suggesting to get rid of all cell-type specific apoptosis terms (e.g. T cell apoptotic process). Rather, he’s concerned about the generic parent, the structure of the node and the logical definitions. I’ll get to that shortly.

Hi @dosumis ,
Thanks for spotting these. They need fixing, and I’ll get to that next, but first let me dig into the term archeology. Back in 2012 I suggested to create ‘cell-type specific apoptotic process’ because, without it, all of the 36 terms shown in your first screenshot would sit directly under ‘apoptotic process’. The node was very cluttered because of that.  I do realise that this may seem less of an issue in the logical world of OWL :-) but most GO curators refer to browsers that display nodes as ‘flat’ lists and if there are too many terms, it is less straightforward to spot the ones they may really need (think about all the work we did to describe sub-processes of signalling, execution etc.). So I suggested to clean up the node by creating a generic parent term ‘cell-type specific apoptotic process’ to act as un umbrella, with appropriate caveats:
Def: Any apoptotic process in a specific cell type.
Comment: This term was created as a generic parent to group terms indicating occurrences of apoptotic process in specific cell types. The process of apoptosis may not vary, but the cell type does. Note that this term is in the subset of terms that should not be used for direct gene product annotation.  Direct annotations to this term may be amended during annotation QC. Alternatively, you may annotate to the parent term GO:0006915 apoptotic process.
At the time, this was well received. I think the rationale behind having this term still holds, and I favour keeping it. (As I said, the node still needs cleaning, I’ll do that.)
Before I dig into why 2 different logical definitions cropped up in time (sneak preview: it’s got to do with how we designed the TG template), please let me know if keeping ‘cell-type specific apoptotic process’ would be acceptable to you.
Thanks!

Let me know if keeping ‘cell-type specific apoptotic process’ would be acceptable to you.

I think it comes down to whether you think keeping it is sustainable.  There are a few scenarios where an editor or curator might perfectly reasonably use the pattern "'apoptotic process' that occurs in some { cell type }" and expect the results to classify correctly:

Anyone using a term genie template with a generic BP occurs_in CL pattern
A curator extending apoptotic process or one of its subclasses with 'occurs in{cell type}
An editor extending some existing apoptotic process subclass with the restriction: 'occurs in' some { cell type }

Classification/folding in all of these cases will fail if we keep "cell-type specific apoptotic process".  If we allow the general principal of adding meta-logical classes like this for the purposes of tidiness, the sustainability problem can increase non-linearly through compounding.  I see the tidiness/browse-ability issue as more of an interface problem.

Thanks, I see your point (and I forgot to add, there's still the problem of making specific cell type terms available for MODs that don't use AEs, but that's not the main subject of discussion here; mentioning just for completeness). My main concern is with
"I see the tidiness/browse-ability issue as more of an interface problem."
I'm afraid that is there to stay for many curators. I know that @ValWood  is often concerned about ease of visualisation for community curators - the cell apoptosis terms wouldn't apply to Pombe of course, but maybe she could comment on the tidiness/browse-ability issue please?

My concern is usually when there are lots of terms which would be out of scope for our current guidelines (like protein family specific binding terms, and  gene product specific terms). The confusion is less about browsing per se, and more about which terms are appropriate. The  community curators can see these terms, and then think that it is appropriate to request new terms like this, because they are trying to annotate specifically, and they can see other terms of this type. For this reason, I think it would be nice to accelerate the merging of the terms which we would consider out of scope for future, because it saves time for us, and our users (and helps users more generally to understand what GO terms represent).
This issue seems slightly different. If there are completely different signalling pathways involved in the regulation of apoptosis  in different cells types then there is a case for making the the terms. However, presumably a number of cell types would share the same alternative pathways, so making terms for each cell type could result in redundancy when describing the same pathway in different cells.
I guess it really depends how much is known about the pathways. Maybe they could be
x signalling involved in regulation of apoptosis (occurs in cell type).
Before making a decision is there an easy way to see how many gene products are annotated to these cell-type specific apoptotic processes which are not "general apoptotic genes", and how many 'cell types' they are annotated in? That might help to come to the best solution.
(btw who still can't use extensions?)

Hi Val
my understanding is that if an extension is used a lot for the same cell type then the editors will consider creating a new GO term (but maybe that is no longer true).
In addition, there are currently no functional analysis tools that use extension data, so currently putting everything in the extension field when it maybe of use if the information is captured within a GO term does not make sense.
But I agree it would be interesting to see how many gene products are annotated to these cell-type specific apoptotic processes which are not "general apoptotic genes", and how many 'cell types' they are annotated in. Unfortunately, this might not be as clear cut to interpret, there maybe some cells that are used more often to study apoptosis but that doesn't mean the proteins involved are specific to that cell type. Plus proteins annotated to 'general' processes are not necessary present in 'all' cell types.

Right. There’s nothing like apoptosis to stir a good conversation…
Summing up:

The issue of tidiness/browse-ability is sort of postponed pending decision on keeping cell-type specific terms. (Just to mention this somewhere: GO:0006915 apoptotic process currently has 20 direct descendants among is_a, part_of and regulates. That is without the cell-type specific terms.)

Do different cell types follow different pathways to apoptose? Presumably some of them do, others don’t. The real problem is that I think that typically, papers showing cell death in a given cell type or tissue don’t go deep into the details of the (signaling) processes. This info is more easily found in studies on cell lines or in vitro. @RLovering  may confirm this. In absence of this certainty, it’s hard to decide if cell-type specific apoptosis terms belong in GO or not.  Then ‘neuron apoptosis’ has a reason to exist beyond simply wanting to capture a frequently-used cell type. Should we disallow any cell-type specific apoptosis terms unless details of the pathway are provided? Fine with me, but that’s not going to be a quick fix.

Looking at cell-type specific apoptotic genes and cell types - interesting but afraid not easily or quickly done.

Which MODs are still not using annotation extensions - I used to have a list, I’ll ask @mcourtot  or Tony to respond please.

AFAIK, it still holds that if the same annotation extension is used often associated with a process, then we’d create the specific term.

Having term enrichment tools that look at extensions too: I think @cmungall  had a plan. I’d expect that, in many cases, only ‘apoptotic process’ would be enriched, but the cell type specific terms could potentially aid a lot in discovery. So, ideally, we’d want the cell type captured, one way or another. If an appropriate tool can be in place within a reasonable time frame, then we don’t care how the cell type is captured. If not, our users would benefit from cell-type specific terms being precomposed.

Just to throw something else into the discussion. There are Total: 1640 human proteins annotated to apoptotic process, which seems super-high to me...really?????

But I think that is closing over regulates. So it's not as bad as you think.

Rather a lot going on now in this ticket. All good, but can we focus on the initial request - as we need a fix for ETINE issues ASAP?
All terms of the form 'X cell apoptotic process' need a logical def with the same genus.  Your call whether you keep 'cell-type specific apoptotic process'  and use this as the genus or obsolete it and use 'apoptotic process'.

There are Total: 1640 human proteins annotated to apoptotic process, which seems super-high to me...really?????

I have a strong suspicion that most of the cell-type specific annotations are for developmental regulation of apoptosis.  These could be useful if annotated to the reg term - but even then, many coming from IMPs are likely to be indirect (change almost anything in development and the level of apoptosis of some cell type will change).

But I think that is closing over regulates.

Ahhh - never thought this was a good idea.

You can filter it out in AmiGO2. Then there are 361 genes left.

apoptotic process
programmed cell death (has_part some apoptotic signaling pathway) and (ends_with some execution phase of apoptosis)
cell-type specific apoptotic process
apoptotic process (occurs_in some cell)
I know it's a bit weird because apoptosis always occurs in a cell, but I think this might work. Whether the cell-type term is useful........

Yes of course @dosumis , going back to the initial issue, i.e. whether to use ‘apoptotic process’ or ‘cell-type specific apoptotic process’ as the genus in the logical def.
As far as I understand, the rule of thumb should be to use the most generic genus and the most specific differentia, so the genus should be ‘apoptotic process’. And that’s how we set up the TermGenie template to start with. But then, curators noted that newly created terms were not children of ‘cell-type specific apoptotic process’ (see https://sourceforge.net/p/geneontology/ontology-requests/10669/). And I asked Heiko to change the template. I see now that the best route should have been to leave the template as was and add the ‘cell-type specific apoptotic process’ parentage by hand… which wouldn’t be maintainable.
I’d keep ‘cell-type specific apoptotic process’ as the genus for the time being, if it weren’t for 1) most terms have the other genus at present and 2) if we end up obsoleting it, it’ll be even more work.
Vote? Or go for David H's solution?

know it's a bit weird because apoptosis always occurs in a cell

That's the fundamental point - and I don't think we can or should try to hack around it.  'cell-type specific apoptotic process' is not a class that makes any sense logically.  If we choose to keep it for the sake of tidiness then we need to commit to manually maintain classification under it.

What about cases in cell lines where the experiments are done simply for the purpose of studying the apoptotic mechanism, and the cell type would not necessarily be captured or important?
If we go with the solution I propose, cell is from the cell ontology not GO, I think this will all work out and users can navigate through the cell-type specific term when it is something they care about.

"As far as I understand, the rule of thumb should be to use the most generic genus and the most specific differentia, so the genus should be ‘apoptotic process’."  The rule of thumb should be to use logical definition patterns that work.  Choosing the more general class doesn't work if you have a class with no logical def in between.  David's pattern would cause equivalence if any parent class of apoptotic process ever gets the axiom (or inference) 'occurs in' some cell.

I'll bet my bottom dollar these are not 'regulating apoptosis'
TAF9B
RPS3A
SOX9
FMN2
RPS27A
COL4A3
LIG4
etc.....
re:

But I think that is closing over regulates.

Ahhh - never thought this was a good idea.

It depends if you use 'regulates' strictly to mean 'a biological mechanism regulating a process' and not just 'affects the rate of a process'.

But wouldn't those parents use the GO cell and not the cell type cell?

But wouldn't those parents use the GO cell and not the cell type cell?

In that case I think you want http://purl.obolibrary.org/obo/CL_0000003 'native cell': A cell that is found in a natural setting, which includes multicellular organism cells 'in vivo' (i.e. part of an organism), and unicellular organisms 'in environment' (i.e. part of a natural environment).
It's still a hack though.

If what we care about is the type of cell, then I don't think it is a hack. It is a meaningful differentia. CL:0000003 works.

I'll let you guys decide. Would be nice to hear what @cmungall thinks too. I can propose obsoletion of 'cell-type specific apoptotic process' if it doesn't make sense to keep it and if we'd have to manually maintain classification.
@ValWood , please feel free to relay doubtful apoptosis annotations to the pertinent MODs :-)

Too many....

I don't think it does. Generic apoptosis always happens to a CL:0000003,
so the fake class would be equivalent to the parent.
I think it's clear - obsolete the fake class. It doesn't work
computationally/logically, and I don't see a major biological use case.
I can see it's sort of nice to be able to have some guidance when
drilling down the hierarchy, but this applies all over the ontology. For
example, when drilling down in metabolism, to see subclasses by process
type (catab/biosynth) vs chemical type. But making metaclasses classes
is not a workable solution, we should file an amigo ticket for this.
On 11 Mar 2016, at 6:45, ukemi wrote:

If what we care about is the type of cell, then I don't think it is a
hack. It is a meaningful differentia. CL:0000003 works.

Reply to this email directly or view it on GitHub:
https://github.com/geneontology/go-ontology/issues/12338#issuecomment-195395780

OK. So (my) action items are:

Current children of 'cell-type specific apoptotic process’: move parentage to is_a ‘apoptotic process’

Obsolete 'cell-type specific apoptotic process'

(These combined should take care of all relevant ETINEs I think)

Ask Heiko to change TG template back to is_a ‘apoptotic process’ (by opening a ticket on the TG GH tracker)

Anything else? I think we should keep the cell type-specific terms themselves (neuron apoptosis, etc), so I suggest we leave that discussion aside.
Thanks,
Paola

Fixed parentage and intersections of cell-type specific terms.

Asked Heiko to fix the TG template.

Sent obsoletion email.

I'll label this ticket as 'pending', and will close it when 'cell-type specific apoptotic process’ is obsoleted.

TG template modified as requested.

Obsoleted GO:0097285 cell-type specific apoptotic process.


Adding event handler

I know this plugin is used as part of local notifications (for example).  Another instance where the app wakes up on iOS is if I am using location services and monitoring for an iBeacon.  When that iBeacon comes in range, if the app has been killed, it is relaunched.  Can you suggest a way to have the system make the launch options available to the cordova app on startup (maybe through an event, maybe through polling some API) so that apps restarted by the OS can react accordingly?

@halindrome Such event will be available with the new release of the local-notification plugin if the app is launched by clicking on a notification.

Is there a timeline for this?


add modeq implementation

Resolves #96.
I couldn't figure out how to add a 0..1000 range test for modeq.

Thanks!! We're glad to have you here 🎉


The plugin hide my project bar

Since the latest update when i open multiple Idea projects i don't see the project structure (in left side) please guys if you can take care about this kind of details.
Solution for those have the same bug use the previous version edit the configuration file inside the plugin and update the minimum idea version
/gitflow4idea-0.7.1.zip/gitflow4idea/lib/gitflow4idea-0.7.1.jar/META-INF/plugin.xml
 <idea-version since-build="182.0" until-build="193.*"/> change to  <idea-version since-build="182.0" until-build="200.*"/>

duplicate of #301
A fix is in the works


Missing oracle jars

Hi folks,
I have already installed oracle jars locally in my maven repo using this command:

..\mvnw install:install-file -Dfile=ojdbc8.jar  -DgroupId=com.oracle -DartifactId=ojdbc8 -Dversion=<IP_ADDRESS> -Dpackaging=jar

Why dont querydsl plugin complains about missing jars?

ERROR:

org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find com.oracle:ojdbc8:jar:<IP_ADDRESS> in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates

Its not allowed to provide any "oracle jars".
There is no maven artifact at all, the oracle jdbc driver needs to be installed by yourself.
For an example of how to install the driver in your local repository see here:

I already did the installation -> thats the point
..\mvnw install:install-file -Dfile=ojdbc8.jar -DgroupId=com.oracle -DartifactId=ojdbc8 -Dversion=<IP_ADDRESS> -Dpackaging=jar

Put the dependency in the plugins dependency section

Already tried that too

Thats not a Querydsl problem.
It has something to do with your local maven setup. Check if the driver is already in the local repository (e.g. .m2/repositorycom/oracle/...).
Also for generating Q-Classes from JPA entites you don't need any JDBC driver or a real connection.


Is SoftEther's VPN Protocol (Ethernet over SSL) support PFS(perfect forward secrecy)?

Is SoftEther's VPN Protocol (Ethernet over SSL)  support perfect forward secrecy just like OpenVPN's tls-auth?
PFS is on SSL/TLS, which is used by OpenVPN and SoftEther's VPN Protocol.
OpenVPN with double certificate authentication in TLS mode (as implemented in Air) provides forward security. New encryption key is negotiated every hour by default ("re-keying").

For future reference, they technically did publicly announce PFS support for SSL about 8 days before the above comment.
https://www.softether.org/5-download/history


[DropdownMenu] Not opening after being clicked on tests

Bug report
Current Behavior
When testing a component using the DropdownMenu and userEvent.click the dropdown does not open. It does open on the browser, it just fails on the tests.
Expected behavior
The dropdown opens and the items can be selected.
Reproducible example
Github repo using CRA
Additional context
We were trying to update a project from 0.0.22 to the latest version. After downgrading I discovered it started failing since 0.0.23.
Your environment

Software
Name(s)
Version

Radix Package(s)
@radix-ui/react-dropdown-menu
0.0.23 to latest

React
n/a
^17.0.2

Browser
Chrome

Assistive tech

Node
n/a
v16.13.0

npm/yarn
yarn
1.22.17

Operating System
Kubuntu

This is an issue with how JSDom emulates pointerEvent, it doesn't currently provide the correct event object properties. You'll need to supply these manually or use an alternative testing tool such as Cypress.
See this comment for a working solution https://github.com/radix-ui/primitives/issues/856#issuecomment-928704064
// test/helpers.ts
export class PointerEvent extends Event {
  button: number;
  ctrlKey: boolean;

  constructor(type, props) {
    super(type, props);
    if (props.button != null) {
      this.button = props.button;
    }
    if (props.ctrlKey != null) {
      this.ctrlKey = props.ctrlKey;
    }
  }
}

// dropdownMenu.test.tsx
fireEvent.pointerDown(
  button,
  new PointerEvent('pointerdown', {
    ctrlKey: false,
    button: 0,
  })
);

0.0.23 and upwards starting using pointerEvent which is why you're seeing this now.
I'm going to close this issue now but if you're still having problems or have any other questions then feel free to re-open and we'll do our best to help.


Missing Static Web App DNS Zone configuration

In the table that lists private DNS zone information, please add DNS zone information for Azure Static Web Apps.

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

ID: a88af182-32aa-a8f3-359d-b92ae1cfb8c7
Version Independent ID: 01ce07fc-4bc2-def5-9ecd-a80330ad9488
Content: Azure Private Endpoint DNS configuration
Content Source: articles/private-link/private-endpoint-dns.md
Service: private-link
GitHub Login: @asudbring
Microsoft Alias: allensu

@RamanaSwaroop , thank you for your feedback. We'll review this and get back to you shortly!

@RamanaSwaroop , We have assigned this to the content owner/author for updating the doc accordingly.
@asudbring , could you please update the DNS zone table for Static Web App?
I could find the below information from Portal:
Private link resource type / Subresource : Azure Static Web Apps (Microsoft.Web/Staticsites) / staticSites
Private DNS zone name : privatelink.1.azurestaticapps.net
Need to confirm the Public DNS zone forwarders with the PG (it will mostly be azurestaticapps.net).

@GitaraniSharma-MSFT do we have any update for this issue?

@GitaraniSharma-MSFT
I have discussed it with Allen, it seems there is discrepancy here.
The static app I created on 2021-02-02 is using Azure DNS Zone privatelink.azurestaticapps.net,
but for newly created static app, it's using Azure DNS Zone privatelink.1.azurestaticapps.net.

@rachelxj-ms , I discussed this with the Product group team and below is the update:
Every Static webapp will have a default hostname that ends with some DNS suffix. For some apps that will be ‘azurestaticapps.net’, for others it could be a sub domain (i.e. ‘1.azurestaticapps.net’, ‘2.azurestaticapps.net’). This is by design and allows the platform to be more resilient to DNS outages.
For private endpoints to work, you need to have an intermediate CNAME of .privatelink.. As a result, if you have a default hostname for your SWA that ends with ‘1.azurestaticapps.net’ then the private endpoint dns zone should be ‘privatelink.1.azurestaticapps.net’. This ‘1’ is not specific to private endpoints but just a result of the default hostname having it.
The default hostname and subdomain of your Static Web App are decided at create time and will remain constant until the app is deleted.
The PG team is working to acknowledge all the possible subdomains in the table for static web apps.

What will the DNS Zone be for Preview / Staging environments? This works for production environment, but not for staging environments.


Added -o to Quail CLI to change the default output directory

We're not going to merge this into master (definitely not dev, that's a defunct branch now). You already fixed the month bug in 307065ceb6ce71f9e2e50f6360b15162fa4a00dd. So, what I recommend is creating a branch from 2.2.15 tag (just make sure the name of the branch isn't simply 2.2.16. Name it something like 2.2.16-output-config). We won't do a pull request for this. We'll just cut a tag from the branch. For review, we can compare your work to the SHA 590733055f2f79cf94d958407ce9f14daa2e7e3a

Oh, and I should mention, it looks great. Just a few stray debuggers and opportunities to exit the process in a catch.

I'm a little confused about your comments for the branches? From what I can gather dev is what 2.2.x is developed from, and the work you're doing on master will (I assume) become part of 2.3.0 (or maybe 3.0.0?) once ready. Shouldn't we then keep using dev for patches on 2.2? Lets discuss in the call Monday. Not sure where you want the try/catch statements - as this is mostly just a copy of what you've made in master. Can you specify?

Redid the PR as https://github.com/quailjs/quail/pull/316


Dark theme for list view

We don't want to wait until all activities have been refactored to use the new theme. Instead we could start with a partial dark theme, just for the list view (and all other activities which have been refactored).

done


add i18n support

add i18n support,according to browser language

Thanks for getting this started!

This pull request is done by our UI team, sorry for the wire account name :)
Please refer to the attached screen shot, including English and Chinese UI

there are some linting problems here https://travis-ci.org/openzipkin/zipkin/builds/303415206?utm_source=github_status&utm_medium=notification
you can change to the zipkin-ui directory and run npm run lint to see them locally

Thanks for the help!

@gianarb noticed this crashes when browser language is italian. There's probably an easy fix for that but.. wonder if we shouldn't crowd-source some more languages?
@shakuzen japanese?
@gianarb italian?
@marcingrzejszczak polish?
@dsyer english? (hehe)


The container Exec function cannot end correctly and there is a mistake in the api doc

When I use the Exec function to execute a command inside a container, it cannot end correctly and print endless something like "2015/11/05 09:07:03 websocket: close 1000 ".
And the example in the doc says "c := make(chan string)", but it cannot work. After I read the code, I think it should be "c := make(chan tutum.Exec)". I try it and it works. I think it should be discussed.

Hey!
Thank you for the feedback we're going to check this right now and fix the mistake in the doc

Ok so I think your issue is related with #33 it will soon be merged. I'll make sure to update the doc ASAP


PBREffect

Basic Theory of Physically-Based Rendering
SIGGRAPH 2016 Course
Pharr, Jakob, and Humphreys, Physically Based Rendering: From Theory to Implementation, Morgan Kaufmann, website code
The Comprehensive PBR Guide, Allegorithmic website

For now, there's a SimplePBR12 sample.


Poor Haddock interaction

G'day,
So I was trying to solve this really annoying Haddock issue I have:
'''
Warning: LibBladeRF.LibBladeRF: could not find link destinations for:
Bindings.LibBladeRF.Types.C'bladerf
'''
I think this essentially comes down to something similar to this issue:
https://github.com/haskell/c2hs/issues/62
Hope that makes sense? Let me know if you need any more details.
Many thanks for your library!
Edward.

I'm not quite sure what the request is.  You want Haddock comments to be supported in .hsc files?

Hi,
Haddock coverage:
0% (  0 /203) in 'Bindings.LibBladeRF.Types'
0% (  0 / 17) in 'Bindings.LibBladeRF.Gpio'
0% (  0 /  9) in 'Bindings.LibBladeRF.Lms'
0% (  0 /  5) in 'Bindings.LibBladeRF.Si5338'
0% (  0 /  7) in 'Bindings.LibBladeRF.Flash'
0% (  0 / 19) in 'Bindings.LibBladeRF.Utils'
0% (  0 / 87) in 'Bindings.LibBladeRF.LibBladeRF'
100% (  1 /  1) in 'Bindings.LibBladeRF'
100% (  4 /  4) in 'LibBladeRF.LibBladeRF'
100% (  3 /  3) in 'LibBladeRF.Flash'
100% (  6 /  6) in 'LibBladeRF.Utils'
100% (  2 /  2) in 'LibBladeRF.Misc'
Warning: LibBladeRF.LibBladeRF: could not find link destinations for:
Bindings.LibBladeRF.Types.C'bladerf
Documentation created: dist/doc/html/hlibBladeRF/index.html
Notice how Haddock is trying to give coverage to the Binding and there seems no way to ignore it.
Also the warning comes about because I have
newtype BladeRF a = BladeRF { unBladeRF :: ExceptT BladeRFError (StateT (Ptr C'bladerf) IO) a }
in  'LibBladeRF.LibBladeRF' but naturally Bindings.LibBladeRF.Types.C'bladerf is generated by #opaque_t blader
There seems to be no way to fix the warning and coverage issues?
Kind Regards,
Edward.


Implement rimraf

Replaces rm from build script with rimraf.

Was this the issue building between windows and unix? @frankjlin16

From the npm package it seems sound and would fix the issue. @frankjlin16 I am not the project lead, but this does seem sound to me. I will be handing this off to @KevinThePepper :)


Use std::filesystem

Go from using out own implementation to using std::filesystem. It should simplify things a bit and make code more portable.

Wait until filesystem is no longer experimental?


send_file's Content-Disposition filename* is ignored in Chrome and Safari, when download_name is unicode with a brace

My test code looks like this:
@app.get('/file')
def return_file():
    return send_file(BytesIO(b"test"), download_name="(тест.txt")

Notice the ( in download_name. Currently response headers look like this:
Content-Disposition: attachment; filename="("; filename*="UTF-8''(%D1%82%D0%B5%D1%81%D1%82"

Firefox uses filename* and downloads file with intended name ((тест.txt). Both Chrome (106.0.5249.103) and macOS Safari (16.0 (176<IP_ADDRESS>.10, 17614)) download files with name (.
Both opening and closing braces in download_name cause this behaviour.
Environment:

Python version: 3.9
Flask version: 2.2.2

This appears to be owing to the way Werkzeug's header construction code quotes options in headers.
This is the behavior now with the filename above ("(тест.txt")::
Content-Disposition: attachment; filename="(.txt"; filename*="UTF-8''(%D1%82%D0%B5%D1%81%D1%82.txt"

But without the quotes, as below, the downloads work in Firefox and Chrome:
Content-Disposition: attachment; filename="(.txt"; filename*=UTF-8''(%D1%82%D0%B5%D1%81%D1%82.txt

It looks like Firefox allows the double quotes around the encoded filename option in the Content-Disposition header. But other browsers handle this differently.
Reading over RFC 5987, there's no mention of quoting these values. Maybe this has been interpreted by some to mean the value for filename attributes ought to not be quoted?
Firefox and Chrome both work fine without the quotes.
Currently, Werkzeug adds double quotes in quote_header_value in http.py without making any distinctions regarding which header is being constructed.

Report this bug to Chromium. Header option values can be enclosed in quotes.

I don't know that it's that straightforward. The RFC doesn't show quotes in ext-parameter in the definition (and the succeeding document doesn't seem to override it). But maybe I'm misreading it (though it would explain why implementations vary across browsers).
I think it could theoretically be handled reasonably well based on the Content-Disposition header name. Annoying, but possibly more conformant (depending on the reading of the RFC).

You'd presumably look at the earlier RFC that defines options in general and shows that quotes are accepted.

The grammar extends the parameter element to allow ext-value as well as value. The latter permits token or quoted-string. But ext-value does not include quoted-string:
ext-value = charset  "'" [ language ] "'" value-chars

There's no mention of quotes. This is to be set against the plain value defnition:
value = token / quoted-string

It seems plausible to me that this might be interpreted to indicate extended parameters such as those we're interested here are not to be quoted.
It would require a lot of testing to make sure a change to extended parameter handling improves things rather than creates problems. But, for what it's worth, my initial tests showed that non-quoted extended parameters work with more browsers, not fewer.
I guess I could look at the browser parser implementations to confirm. But if it's something folks don't think worth delving into at the moment, I'll step back.

Thanks for looking into the RFCs, it's not easy :sweat_smile: Happy to review a PR.

Fixed by https://github.com/pallets/werkzeug/commit/97547cc6825e7bfdc9c08b9a99b21d979b891602


Missing sanity tests for these algorithms on Kunpeng930

Missing sanity test cases for these algo. in Kunpeng930: AES/SM4 CFB and OFB mode, SM4-CTR.
Please update test/sanity_test.sh.
Refer to commit id: aaf1e63ba2b83887e316ee556290407a34ef9b7d
cipher: add new algs for Kunpeng 930
Add new algs for Kunpeng 930, include AES/SM4 CFB and OFB mode, SM4-CTR.

Signed-off-by: Kai Ye<EMAIL_ADDRESS>

Plus, SM4_ecb is for Kunpeng930 only, and need a sanity test case.


Timeout on recv = dropped messages

Scenario:

I use the example from the documentation with both async consumer and async producer.
I also run an async UI, and to let it execute in "parallel", I add timeout= to asyncio.wait.
If I set timeout to reasonable 0.1 s, a small percent of packets from the server doesn't find its way to the consumer task. The lower timeout I set, the higher odds that the message will be dropped.

The issue gets more apparent if I quickly spam multiple packets.
What can I do?
It kind of sounds like https://github.com/python/asyncio/issues/343 (I'm using Python 3.6 though)

In the below examples, while I cannot reproduce the issue with a timeout such as 0.1, 0.001 is enough to trigger this behavior.
server.py
#!/usr/bin/env python
import asyncio
import websockets

connected = set()

async def hello(websocket, path):
    global connected
    connected.add(websocket)
    try:
        while True:
            counter = await websocket.recv()
            print(counter)
            for client in connected:
                await client.send(counter)
    finally:
        connected.remove(websocket)
        for ws in connected:
            await ws.close()

start_server = websockets.serve(hello, 'localhost', 8765)
asyncio.get_event_loop().run_until_complete(start_server)
asyncio.get_event_loop().run_forever()

client.py
#!/usr/bin/env python
import asyncio
import websockets
import sys

POLL_TIME = 0.001
messages_received = 0
messages_sent = 0

spam = '--spam' in sys.argv

async def producer() -> int:
    if not spam:
        # don't send anything (timeout > POLL_TIME)
        await asyncio.sleep(99999)
        assert False
    # always be on time (timeout < POLL_TIME)
    await asyncio.sleep(POLL_TIME / 2)
    global messages_sent
    messages_sent += 1
    return 'packet #%d' % messages_sent

async def consumer(message):
    global messages_received
    messages_received += 1
    print(message)

async def hello():
    async with websockets.connect('ws://localhost:8765') as websocket:
        while messages_received < 1000:
            listener_task = asyncio.ensure_future(websocket.recv())
            producer_task = asyncio.ensure_future(producer())
            done, pending = await asyncio.wait(
                [listener_task, producer_task],
                timeout=POLL_TIME,
                return_when=asyncio.FIRST_COMPLETED)

            if listener_task in done:
                r = listener_task.result()
                await consumer(r)
            else:
                listener_task.cancel()

            if producer_task in done:
                await websocket.send(producer_task.result())
            else:
                producer_task.cancel()

try:
    asyncio.get_event_loop().run_until_complete(hello())
finally:
    print('msgs sent: ', messages_sent)
    print('msgs received: ', messages_received)

I run the scripts like this:

./server
./client (it'll pick up the messages)
./client --spam (it'll send the messages)

./client --spam shows:
msgs sent:  1000
msgs received:  1000

whereas ./client receives fewer messages:
msgs sent:  0
msgs received:  970

I believe this is a race condition, when a message is received between asyncio.wait and listener_task.cancel. This means it's a bug in the example, not in the library.
The example was simplified significantly, which has the side effect of eliminating this race condition, and means we can consider the bug in the example fixed.
Please reopen if you encounter the race condition within websockets itself.


I can't create a new project with nitrogen

I am running Erlang/OTP 22 [erts-10.5]
make rel_inets, yaws, etc. does not work.

Hi @joshzinny , I'm sorry I never responded.

Did you ever get it going?

If not, are you interested in still trying?

And if yes to (2) and you still get the error, what error do you get?

I'm going to close this for now. If you come back, feel free to reopen it :)


GitHub+Travis: avoid Docker Hub pull limit by logging into docker account

There is a new image pull limit enforced by Docker Hub for anonymous
users. Since we seem to be sharing that pull limit with other jobs
running from the same IP, we want to log in to get our own, exclusive
pull limit of currently 200 pulls per 6 hours.
@Roasbeef: Need new secrets in Travis:

DOCKER_USERNAME: same value as on GitHub
DOCKER_PASSWORD same value as DOCKER_API_KEY on GitHub

Hmm... The action seems to fail. @Roasbeef are the GH secrets limited to certain workflows? If yes, we might need to add the main CI workflow to the allow list.

Are the GH secrets limited to certain workflows?

I think they don't work on PRs, because PRs don't have access to secrets (for security purposes, if anyone modifies the workflow, secrets can be exposed).

It seems like this is no longer needed. Didn't happen again AFAIK.


[Group Chats] Fixes for Thread Avatars and Leave Group Chat Navigation

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/40474
$ https://github.com/Expensify/App/issues/40470
PROPOSAL: https://github.com/Expensify/App/issues/40474#issuecomment-2064411071 & https://github.com/Expensify/App/issues/40470#issuecomment-2064352113
Tests
Test 1:

Go to FAB > Start chat.
Create a group chat.
Tap on the chat header.
Tap Leave.
Tap on the back button twice.
Verify user goes back to a valid page

Test 2:

Go to FAB > Start chat.
Create a group chat.
Send a message in the group chat.
Right click on the message > Reply in thread.
Verify Thread header avatar does not allow user to upload custom avatar

[x] Verify that no errors appear in the JS console

Offline tests
Same as Tests Step
QA Steps
Same as Tests Step
PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/64629613/05f3d8bc-91d5-40ab-bddb-a95bb7514424
https://github.com/Expensify/App/assets/64629613/078769b4-12e7-4599-b277-e5271e0b062a

Android: mWeb Chrome
https://github.com/Expensify/App/assets/64629613/e341ca2c-0518-40db-8964-72f5c71b15a5
https://github.com/Expensify/App/assets/64629613/86f4ccb1-03c3-4744-9692-9c85714637f2

iOS: Native
https://github.com/Expensify/App/assets/64629613/d5a16362-ec24-468f-841b-f47d5a85c59b
https://github.com/Expensify/App/assets/64629613/2bc5b63c-f5e7-43ba-bc6b-2071947d6d55

iOS: mWeb Safari
https://github.com/Expensify/App/assets/64629613/3e349117-bea3-40df-a58c-a960b9c2784a
https://github.com/Expensify/App/assets/64629613/78d06d48-71c4-4541-849c-e3e9bb726d73

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/64629613/e948cd41-3740-4956-bd77-21be222e9367
https://github.com/Expensify/App/assets/64629613/79675ff7-5c23-41f0-80aa-3e7de5fdd618

MacOS: Desktop
https://github.com/Expensify/App/assets/64629613/6892fabe-1b54-4bf3-8c40-5c7b7b51d413
https://github.com/Expensify/App/assets/64629613/100061bd-a0f9-4d38-9d44-26af6e806e32

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/mountiny in version: 1.4.63-21 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Can't get refresh to trigger

Hi There
First off, I just want to say a huge thanks for this utility. It's exactly what I'm looking for. Unfortunately, I just can't seem to make it work quite right. I'm sure I'm close and missing something obvious.
Context

My app allows a user to log in and is granted a short-lived access token and refresh token
I'm using the axios.create method to instantiate the baseURL of the api
I have two custom interceptors applied to the axios instance that automatically sign the request with the access token

Observed Behavior

Once the short-lived access token expires, any additional requests that require authentication (except one, more below) following the expiration will correctly return a 401 error response.
While inspecting the network tab, the refresh doesn't seem to be triggering.

Debug Steps

Removed my custom interceptors from the equation
Removed the axios instantiation with axios.create and just used Axios's default export.
added .then, .catch and .finally to the api action to try force promises to go through.

I'm out of ideas of things to try at this point. My other interceptors are working great. I'm sure there's something minor I'm doing wrong with promises or something like that. Any tip that could be provided to point me in the right direction would be greatly appreciated!
Chad
Code:
api.json

import axios from "axios";
import store from "../store";
import { userActions } from "../_actions/user.actions";
import createAuthRefreshInterceptor from "axios-auth-refresh";
import { showLoading, hideLoading } from "react-redux-loading-bar";

const { dispatch } = store;

const api = axios.create({
    baseURL: process.env.REACT_APP_API_ROOT,
    timeout: 150000,
    headers: {
        Accept: "application/json"
    }
});

// Function that will be called to refresh authorization
const refreshAuthLogic = (failedRequest) => {
    console.log('failed request interceptor');

    // unable to refresh because the token is not available
    if (userActions.getRefreshToken() === false) {
        return Promise.reject(failedRequest)
    }

    api
        .post("/oauth/token", {
            grant_type: "refresh_token",
            refresh_token: userActions.getRefreshToken(),
            client_id: process.env.REACT_APP_CLIENT_ID,
            client_secret: process.env.REACT_APP_CLIENT_SECRET
        })
        .then(tokenRefreshResponse => {
            // save the new access and refresh tokens
            localStorage.setItem(
                "auth-token",
                JSON.stringify(tokenRefreshResponse.data)
            );
            failedRequest.response.config.headers["Authentication"] = "Bearer " + userActions.getAuthenticatedToken();
            return Promise.resolve();
        })
}

// Instantiate the interceptor (you can chain it as it returns the axios instance)
createAuthRefreshInterceptor(api, refreshAuthLogic, {statusCodes: [ 401, 400 ]});

// show loader
api.interceptors.request.use(function(config) {
    dispatch(showLoading());

    return config;
});

// hide loader
api.interceptors.response.use(
    response => {
        dispatch(hideLoading());
        return response;
    },
    error => {
        dispatch(hideLoading());
        return Promise.reject(error);
    }
);

// append auth header
api.interceptors.request.use(function(config) {
    let token = userActions.getAuthenticatedToken();

    if (token !== false) {
        config.headers.Authorization = `Bearer ${token}`;
    }

    return config;
});

export default api;

Actions.js
/**
 * Retrieve collection of lead sheets
 * @param page
 * @param orderColumn
 * @param orderDirection
 * @returns {Function}
 */
export function getLeadSheets(page, orderColumn, orderDirection) {
    return dispatch => {
        dispatch(request());

        leadsApi.getLeadSheets(page, orderColumn, orderDirection).then(
            response => {
                dispatch(success(response));
            },
            error => {
                dispatch(failure(error));
            }
        )
    };

    function request() {
        return {
            type: leadsConstants.LEAD_SHEET_INDEX_REQUEST
        };
    }

    function success(response) {
        return {
            type: leadsConstants.LEAD_SHEET_INDEX_SUCCESS,
            payload: response.data
        };
    }

    function failure(error) {
        return {
            type: leadsConstants.LEAD_SHEET_INDEX_FAILURE,
            payload: error
        };
    }
}

Hi Chad,
I'm sorry but I have completely missed your issue.
I didn't even read the whole thing, so correct me if I'm wrong, but it seems like you're missing the return statement in refreshAuthLogic function.
Try returning the axios call, so the interceptor can bind to it.
const refreshAuthLogic = (failedRequest) => {
    console.log('failed request interceptor');

    // unable to refresh because the token is not available
    if (userActions.getRefreshToken() === false) {
        return Promise.reject(failedRequest)
    }

    return api
        .post("/oauth/token", {
            grant_type: "refresh_token",
            refresh_token: userActions.getRefreshToken(),
            client_id: process.env.REACT_APP_CLIENT_ID,
            client_secret: process.env.REACT_APP_CLIENT_SECRET
        })
        .then(tokenRefreshResponse => {
            // save the new access and refresh tokens
            localStorage.setItem(
                "auth-token",
                JSON.stringify(tokenRefreshResponse.data)
            );
            failedRequest.response.config.headers["Authentication"] = "Bearer " + userActions.getAuthenticatedToken();
            return Promise.resolve();
        })
}

Hi Flyrell
Thanks for getting back to me. I did figure this out just the other day. You are right, I was missing the return.
The other big problem I was having was this: I had a Laravel backend with CORS configured on certain routes. But the auth route did not have CORS configured correctly. This meant whenever the XHR request failed it failed as a network / browser error not as a catchable error inside the Refresh function.
This helped me work it out:
https://github.com/axios/axios/issues/569#issuecomment-364817273
Thanks for taking the time to respond and spot the error. This is working for me now and I'm really happy I got it working. It feels like a very clean implementation.


Make only Flutter.framework files read-only

Making the directories read-only causes problems with deletion, which
breaks the Mac chrome buildbot and DeviceLab.
Followup patch to cb2b89c38.

Fixes breakage noted on #8748


WIP: Major refactor to use RObject type.

There is still a bit more I would like to do, but I would appreciate some comments. This is a fairly major change, and will break some things, but I think it's a nicer interface.
R objects are now represented in 2 ways:

behind-the-scenes as Ptr{S<:SEXPREC}
user-facing RObject{S<:SEXPREC}, which provide GC-protected pointers

The advantage of this is that it is now clear whether or not an R object is protected from garbage collection.
In order to convert a Julia object to an R object:
RObject(x) # GC-protected
sexp(x)    # not protected

as a result, sexp is no longer exported. To do the reverse, use rcopy, with optional type:
rcopy(x) # default conversion
rcopy(T,x) # specific conversion

Other changes:

SEXPRECs are now immutable
whenever possible, the correct SEXPREC type is returned from functions, to improve type information
nice wrappers to R functions (CAR, CDR, allocArray, setAttrib!, etc.)
correctly call Rf_xlength for vectors.
Use of Base.vec has been replaced by unsafe_vec (not exported)
Use of Base.names has been replaced by getNames (exported)
protect and unprotect are used to ensure Ptr{S<:SEXPREC} are not GC-ed.

Very promising :+1: .

Just a naming issue. As far as I understand correctly, SEXPs are pointers to the SEXPREC but not subtypes of SEXPREC. It may make some sense to rename them as follows
@doc "R logical vector"->
type LglSxp_Struct <: SEXPREC     # type tag 10
    info::Cint
    attrib::Ptr{Void}
    p::Ptr{Void}
    pv::Ptr{Int32}
    length::Cint
    truelength::Cint
end

alias LglSxp Ptr{LglSxp_Struct}

How does it sound?

Good point. It does add more typs though, and the RObjects would then appear as RObject{LglSxp_struct}.

Their nomenclature is really confusing.
What about LglSx, or some variant? So we would have
abstract SExpr

immutable LglSx <: SExpr
...
end

typealias LglSxp Ptr{LglSx}
typealias Sxp Ptr{S<:SExpr}

If I understand correctly, SEXP or SXP stands for S expression. LglSx or SExpr may not be able to reflect the structure very precisely.
How about
abstract SEXPREC

immutable LglSxpREC <: SEXPREC
...
end

typealias LglSxp Ptr{LglSxpREC}
typealias Sexp Ptr{S<:SEXPREC}

But I don't know what "REC" means...

But I don't know what "REC" means...I searched over the source files but couldn't find any hints.

I would assume "Record"?

I found a presentation at userR 2004 http://www.r-project.org/conferences/useR-2004/Keynotes/Dalgaard.pdf
it says Symbolic EXPression RECord.
It makes sense to me to use LglSxpRec or LglSxpREC. And for the generic structure, SEXPREC or SxpRec

@randy3k I've renamed some things: let me know what you think.

As sexp returns SEXP rather than SEXPREC, should we define
sexp(::Type{LglSxp},v) instead of sexp(::Type{LglSxpREC},v)?
With that sense, I think we only have to export Sxp types but not the SxpRec types.

I see your point, but I'm reluctant for the following reasons:

Users shouldn't have to care about the distinction between Sxp and SxpRec: this is only important for people using the lower level interface (basically, package developers who want to interact with R).
The problem is that the Sxp types are just aliases, so the user will see Ptr{FooSxpRec}, which makes matters more confusing.
From an aesthetic point of view RObject{FooSxpRec} is nicer than RObject{Ptr{FooSxpRec}}.
Having an SEXP be a pointer is probably more due to limitations of C, rather than a semantic choice.
We don't mirror the C interface in other ways: i.e. we use different structs for each type, SEXP is a (concrete) Ptr{Void}, whereas Sxp is an abstract type.

Having given this more thought, I was actually thinking it might be better to go back to using the original names, with the Sxp types being immutables, something like:
abstract Sxp # subtypes correspond to SEXPREC structs
typealias SxpPtr{S<:SxpRec} Ptr{S} # subtypes match SEXP arguments/

immutable LglSxp <: Sxp
...
end
typealias LglSxpPtr Ptr{LglSxp}

That way, users will see RObject{LglSxp}, which should be a bit nicer.
I realise this doesn't mirror the C interface, but I think as long as we document it, it shouldn't be a problem.

Agree. LglSxpPtr/LglSxp are more readable than ``LglSxp/LglSxpRec`.

@dmbates You mention in your notes that symbols are not garbage collected. Do you think this is likely to be the case for the foreseeable future? If so, we can special-case the RObject{SymSxp} to omit the preserve call.

@simonbyrne Yes, I expect that we will be able to count on symbols not being garbage collected for the foreseeable future.

Okay, now we have testing on all platforms. I was thinking of merging this in, cleaning up the docs and then tagging a new release. Any objections @randy3k @dmbates?