Azure ARM Template Subscription Deployments do not respect SecureStrings

Azure ARM Template deployments. Subscription level deployments do not respect SecureString. SecureStrings are visible in azure deployment logs.
Resource group level arm deployments work as expected and SecureStrings are hidden.
Will this be fixed or please send me instruction documentation on how to achieve this.
Alternately explicitly highlight in the documentation that subscription level deployments are for unsecure use only?

@dirkslab I am unable to repo, can you provide the logs. Please hide your secrets before sharing the log and sent them to<EMAIL_ADDRESS>

@dirkslab  any update?

@anuragc617 Apologies, did not see notification in my mail on your response.
What does it mean when you say you could not repo? Are you saying a securestring parameter in subscription level deployment are not visible in azure deployment logs from your testing?
I will create an example with the logs I have and send to you as requested.

subscriptiondeployment-vaults.zip
ExportedTemplate-demo01-dev-vault-core-we.zip
@anuragc617 I have attached an example subscription deployment template with basic vault and 1 secret. Also included exported template from azure portal deployment logs.
When deploying at subscription level (New-AzSubscriptionDeployment) the secret is visible in the azure deployment logs. If you take the same example and convert to plain resourcegroupdeployment(New-AzResourceGroupDeployment
), it will be hidden in the azure deployment logs.
Please let me know if sufficient detail. Would be great to resolve this as this is causing a problem with my automation flow.

@dirkslab I think you are trying to deploy from azure powershell and not arm pipelinetask. Could you reach out https://github.com/Azure/azure-powershell for this.

both powershell and azure arm pipeline same result.

@ddivanshu powershell and arm template pipeline same result. easily testable by using supplied templates above.

@dirkslab tested the above template with AzureResourceManagerTemplateDeployment task could not reproduce it.
steps:

task: AzureResourceManagerTemplateDeployment@3
displayName: 'ARM Template deployment: Subscription scope'
inputs:
deploymentScope: Subscription
azureResourceManagerConnection: 'xxxxxxx'
subscriptionId: 'xxxxxx'
location: 'Central US'
csmFile: 'subscriptiondeployment-vaults.json'
csmParametersFile: 'subscriptioneployment-vaults.parameters.json'

Could you share your pipeline as well.

Please can you clarify when you say you cannot reproduce the issue? Are you saying that if you go to the deployment output in the portal the secrets are not visible? I want to make sure we are aligned at what we are looking at. Please be as specific as possible.
my pipeline:
steps:

task: AzureResourceManagerTemplateDeployment@3
displayName: vault1
inputs:
deploymentScope: Subscription
azureResourceManagerConnection: xxxxxxx
subscriptionId: 'xxxxxxx'
location: 'West Europe'
csmFile: '$(System.DefaultWorkingDirectory)/build/ARMTemplates/mySubscription_vaults.json'
csmParametersFile: '$(System.DefaultWorkingDirectory)/build/ARMTemplates/mySubscription_vaults.parameters.json'

I will also double check my deployment and give more detailed feedback

https://github.com/ddivanshu
please find attach. Screenshot of pipeline task.
json output from portal. Secret values all visible. This does not happen with resource group deployment, only subscription deployment.
ExportedTemplate-demo01-dev-vault-core-we (1).zip

When deploying as Resource Group Images, expected behavior. Doing a good job at masking secrets.

@ddivanshu please advice on your results.

@ddivanshu please advice on your results.

Hey @dirkslab , thank you for the details. Looking into it.

@dirkslab this is an ARM deployment behavior and not pipeline task issue. You are using nested templates. When doing nested template deployment, ARM does not treat parent secure strings as secure in child templates. That's the reason it appears in plain text.

I could not find a good doc, but this doc talk about that. Essentially, you will need to define parameters explicitly in child template and set the expression scope.

I made changes in your template and now it works fine
{
  "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
  "contentVersion": "<IP_ADDRESS>",
  "resources": [
    {
      "condition": "[parameters('vaults_demo01-dev-vault-core-we_condition')]",
      "name": "kptestvault",
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2020-06-01",
      "resourceGroup": "bishal-test-secret",
      "properties": {
        "expressionEvaluationOptions": {
          "scope": "inner"
        },
        "parameters": {
            "vaults_demo01-dev-vault-core-we_condition": {
                "value": true
            },
            "mytestsecret": {
                "value": "[parameters('mytestsecret')]"
            }
        },
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
          "contentVersion": "<IP_ADDRESS>",
          "parameters": {
            "vaults_demo01-dev-vault-core-we_condition": {
              "type": "bool"
            },
            "mytestsecret": {
              "type": "SecureString"
            }
          },
          "resources": [
            {
              "name": "bishal-kv",
              "type": "Microsoft.KeyVault/vaults",
              "apiVersion": "2019-09-01",
              "location": "westeurope",
              "properties": {
                "tenantId": "[subscription().tenantId]",
                "sku": {
                  "family": "A",
                  "name": "standard"
                },
                "accessPolicies": [],
                "enableSoftDelete": false,
                "networkAcls": {
                  "defaultAction": "Allow",
                  "ipRules": []
                }
              },
              "condition": true,
              "resources": [
                {
                  "name": "mytestsecret",
                  "type": "secrets",
                  "apiVersion": "2019-09-01",
                  "tags": {
                    "projectKey": "demo01",
                    "environment": "dev",
                    "alias": "demo"
                  },
                  "properties": {
                    "value": "[parameters('mytestsecret')]",
                    "contentType": "SecureString",
                    "attributes": {
                      "enabled": true
                    }
                  },
                  "condition": true,
                  "resources": [],
                  "dependsOn": [
                    "bishal-kv"
                  ]
                }
              ]
            }
          ]
        },
        "mode": "Incremental",
        "debugSetting": {
          "detailLevel": "none"
        }
      }
    }
  ],
  "parameters": {
    "vaults_demo01-dev-vault-core-we_condition": {
      "allowedValues": [],
      "metadata": {
        "description": "add a description"
      },
      "defaultValue": false,
      "type": "bool"
    },
    "mytestsecret": {
      "allowedValues": [],
      "metadata": {
        "description": "add a description"
      },
      "defaultValue": "test value 9",
      "type": "SecureString"
    }
  }
}

Thanks @bishal-pdMSFT I will have a look at the feedback.

@bishal-pdMSFT cannot thank you enough. I have updated my template builder to action as per your suggestion and it now works as expected. Really thought this was a bug, happy to confirm it's working as expected.
This makes me wonder about my other big issue. I had 2 issues stopping me from reaching Subscription level template Nirvana and this resolves one of them.
The existing issue:
If there is a reference in the resource template, it gets evaluated and fails (if the resource does not yet exist) even though dependsOn is set at "Microsoft.Resources/deployments" level and the resource exist in the the template.
Could this be related, any suggestions where to start on this. I am hoping this is also a config issues and not by design or bug.
Again, thank you very much!

hi team, the same issue affecting resource group deployments as well.
As the result everyone with just Reader access on resource group level can see SQL admin password (for example) in deployment logs.
See ticket<PHONE_NUMBER>00082 for detailed steps to reproduce the issue and screenshots.
A proper fix of the issue would be much appreciated.

@rshariy this issue is already hotfixed.


VideoRehabService

Implementation of first VideoRehabService.

[ ] Re-send invitation when participant is reconnected
[ ] Manage session acceptance / denial from openteraplus (automatic for web app for now)
[ ] Simple UI for username / password login instead of tokens
[ ] Cleanup teraplus.js
- [ ] Prototype rtcconnection +  UI
[ ] Remove timeout when starting nodejs. Handle startup with URL fetch.
[ ] Same site cookies (undefined)
[ ] Manage participant disconnection / endpoint
[ ] Websocket ping, auto close when unused
[ ] NGINX dynamic port / URL management / avoid multiple copies of the same rules with different ports OR Python generator


Component YAML Schema change not reflected

This example shows the old schema for the component definition.

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

ID: 73a70fdb-96e1-a30f-bd42-450eba903109
Version Independent ID: f9b84ffe-95d0-f2e8-184c-70361de4aa66
Content: What is a component (preview) - Azure Machine Learning
Content Source: articles/machine-learning/concept-component.md
Service: machine-learning
Sub-service: core
GitHub Login: @likebupt
Microsoft Alias: keli19

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

@ezwiefel   Thank you for your feedback. To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.  As part of that transition, we are closing  older issues that we believe have been resolved by subsequent document updates.
If you feel that this issue still persists, please respond and let us know.
#please-close


Just publish release branches

Fixes #59

I meant to add, “apart from the nits, looks good overall :+1:” :innocent:

@qmonnet thank you very much to taking a look! I've tested as much as possible locally so 🤞


feat: add select (custom) component

Purpose
Add Select component.
Approach
Implements Select  (custom) component.
This closes issue #3.
Testing
On Storybook preview.
Risks
N/A

You weren't kidding when you said there was a lot of JS 😅
I still wonder if there's a way to get most of what we need from vanilla elements so we don't need so much custom code, but that is probably a better concern for a second iteration of the component.

Closing in favour of https://github.com/onfido/castor/pull/965.


BUG#1171-Resource and menu action buttons on the same row

Reconfigure resource action and menu buttons to use component tools
Actively working this, where we are headed 👇

@AllenBW is this WIP?

Why did miq bot remove wip?

Closing cuz I wanta go a different direction with this.


When using nested components in theme, dark values are active when in light mode

Description
When using nested components in theme, dark values are active when in light mode
CodeSandbox/Snack link
https://snack.expo.dev/@milesingrams/gluestack-issue-with-dark-styles
Steps to reproduce
Only in ("@gluestack-style/react": "1.0.32") and after. Still happens in latest release ("@gluestack-style/react": "1.0.45")
https://snack.expo.dev/@milesingrams/gluestack-issue-with-dark-styles
Toggle the colorMode and notice the Icon always has the _dark theme set (red color)
gluestack-ui Version
"@gluestack-style/react": "1.0.32" and later
Platform

[X] Expo
[ ] React Native CLI
[ ] Next
[ ] Web
[ ] Android
[ ] iOS

Other Platform
No response
Additional Information
No response

hi @milesingrams please follow the method given in the docs for customizing theme rather than following the above approach. Sharing the link below
https://gluestack.io/ui/docs/theme-configuration/customizing-theme

We already use a custom theme in our app and it still happens. Also happens when using .dark or _dark. Looks like theres a bug in the resolution of nested colorMode themes during the sx processing step.
Likely files to look at are:
https://github.com/gluestack/gluestack-ui/blob/main/packages/styled/react/src/convertSxToSxVerbosed.ts
https://github.com/gluestack/gluestack-ui/blob/main/packages/styled/react/src/resolver/checkAndPush.ts

In this method:
https://github.com/gluestack/gluestack-ui/blob/c15698c5740015127c28e0908f322e81dfed8728/packages/styled/react/src/resolver/checkAndPush.ts#L18C70-L19C1
Youll see that which colorMode is stored in path as 'theme' now after the change of theme handling, this method looks for 'colorMode' in the path to handle the logic for setNestedObjectValue.

You have passed the color property in the props, you dont need to pass it inside the props key, you can directly pass it and it will work.
Check this expo snack, I changed the code to work accordingly. I only removed the props key and the rest is the same.
If you have any other issue or if it is breaking somewhere else or need more clarification then please open this issue again.
I am closing it for now.


bug: Destroying component doesn't remove references to DOM elements and keeps them as detached nodes in the memory.

Bug Report
REF:  MORE INFO CAN BE FOUND IN THE FIRSTLY CREATED ISSUE BELOW ( SINCE THE ISSUE FIRST WAS EXPERIENCED IN IONIC V3 VERSION, BUT THEN IT TURNED OUT THAT ALSO HAPPENS IN IONIC 4 TOO )
https://github.com/ionic-team/ionic-v3/issues/1040
Ionic version:

[x] 4.x
Current behavior:

DOM Nodes are stacking up in the memory.
Expected behavior:

DOM Nodes are being destroyed from the memory when the component is destroyed.
Steps to reproduce:

NOTE: Tested the ionic 4 app with both @ionic/angular: 4.1.0 and 4.6.0 (latest version)
1.ionic start testApp --type=angular with sidebar
2.then changed the structure in app.component.html to
<ion-header>
  <ion-toolbar>
    <ion-title>Menu</ion-title>
  </ion-toolbar>
</ion-header>
<ion-content>
  <ion-list>
    <ion-menu-toggle auto-hide="false" *ngFor="let p of appPages">
      <ion-item [routerDirection]="'root'" [routerLink]="[p.url]">
        <ion-icon slot="start" [name]="p.icon"></ion-icon>
        <ion-label>
          {{p.title}}
        </ion-label>
      </ion-item>
    </ion-menu-toggle>
  </ion-list>
</ion-content>

Just open the side menu , enter Home or List page , redo that 10 , 20 times while profiling , then dont do anything... the nodes are stacking up in the memory

NOTE: This also happened with ionic v3 starter app created
The result:

Anyway, I've tested pure Angular 5 or 6 (don't remember the latest update) app that we've developed into the past, which is super massive , when ran profiling, a decrease of nodes was noticed.

Closing this issue since in the referenced issue from v3 repo there were a solution.
If your ionic v4 project runs @angular/browser-platform < 6.1.10 , in 6.1.10 version there is patched fix for that nodes leak, it turned out that hammerjs weren't destroying components but only the listeners.


esdoc includes return values inferred from the AST in documentation even though the doc comment includes a @return(s) tag

Say, having
class foo
{
     /**
      * @returns {boolean} - the bar
      */
     get bar()
     {
          return true;
     }

     /**
      * @returns {Object} - the car
      */
     get car()
     {
         return {};
     }
}

will generate documentation that includes the information inferred from the AST, e.g.
get bar : boolean : boolean
get car : Object : *

Can this be changed so that esdoc will only include the inferred type when no @return(s) tag is present?
For a "live" example, please have a look at
http://esbases.es.coldrye.eu/projects/esbases/doc/dev/class/src/error.es~EsError.html
here: get cause : Error : *

ESDoc requires @type for getter, not @returns.
export default class Foo {
  /**
   * this is foo.
   * @type {boolean}
   */
  get foo(){
    return true;
  }
}

https://esdoc.org/tags.html#for-member-and-variable

@h13i32maru Thanks for the hint. Sigh will have to fix a lot of API docs :grinning:


Sending POST to https server panic if CONFIG_MBEDTLS_SSL_PROTO_TLS1_3=y (IDFGH-6895)

Environment

Module or chip used: ESP32-WROOM-32E
IDF version: v5.0-dev-1829-ge29e96101d
Build System: idf.py
Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2021r2-patch3) 8.4.0
Operating System: Linux
Power Supply: USB

Problem Description
I test sending POST to https://hookbin.com, then it always hits below panic if CONFIG_MBEDTLS_SSL_PROTO_TLS1_3=y
Note, if CONFIG_MBEDTLS_SSL_PROTO_TLS1_3=n it works.
Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.
Core  1 register dump:
PC      : 0x4008e520  PS      : 0x00060b33  A0      : 0x8008ece5  A1      : 0x3ffdf2c0
0x4008e520: remove_free_block at /home/axel/esp/esp-idf/components/heap/heap_tlsf.c:213
(inlined by) block_locate_free at /home/axel/esp/esp-idf/components/heap/heap_tlsf.c:448
(inlined by) tlsf_malloc at /home/axel/esp/esp-idf/components/heap/heap_tlsf.c:757
A2      : 0x3ffb93ac  A3      : 0x3ffdffa4  A4      : 0x00000010  A5      : 0x3ffdf410
A6      : 0x871682ac  A7      : 0x00000001  A8      : 0x00000003  A9      : 0x00000000
A10     : 0x3ffb93b8  A11     : 0x0000000c  A12     : 0x91b3e144  A13     : 0x53496bda
A14     : 0x2086b79b  A15     : 0x53496bd8  SAR     : 0x0000001d  EXCCAUSE: 0x0000001d
EXCVADDR: 0x91b3e150  LBEG    : 0x4000c46c  LEND    : 0x4000c477  LCOUNT  : 0x00000000
Backtrace:0x4008e51d:0x3ffdf2c00x4008ece2:0x3ffdf2e0 0x40081f3f:0x3ffdf300 0x40081f51:0x3ffdf330 0x4008215d:0x3ffdf350 0x400856a0:0x3ffdf370 0x40144e2d:0x3ffdf390 0x4013cfd7:0x3ffdf3b0 0x4013d141:0x3ffdf3d0 0x40142831:0x3ffdf3f0 0x4013f94f:0x3ffdf410 0x4013fb39:0x3ffdf430 0x40139dbe:0x3ffdf450 0x401390de:0x3ffdf510 0x40139117:0x3ffdf530 0x401329d5:0x3ffdf550 0x401326bd:0x3ffdf570 0x40132797:0x3ffdf5a0 0x401338c3:0x3ffdf5d0 0x40192f07:0x3ffdf5f0 0x40134af8:0x3ffdf610 0x40134d8d:0x3ffdf630 0x400dac71:0x3ffdf650 0x400db219:0x3ffdf6c0 0x401951c3:0x3ffdf6e0 0x400db245:0x3ffdf730
0x4008e51d: remove_free_block at /home/axel/esp/esp-idf/components/heap/heap_tlsf.c:212
(inlined by) block_locate_free at /home/axel/esp/esp-idf/components/heap/heap_tlsf.c:448
(inlined by) tlsf_malloc at /home/axel/esp/esp-idf/components/heap/heap_tlsf.c:757
0x4008ece2: multi_heap_malloc_impl at /home/axel/esp/esp-idf/components/heap/multi_heap.c:189
0x40081f3f: heap_caps_malloc_base at /home/axel/esp/esp-idf/components/heap/heap_caps.c:139
0x40081f51: heap_caps_malloc at /home/axel/esp/esp-idf/components/heap/heap_caps.c:159
0x4008215d: heap_caps_calloc at /home/axel/esp/esp-idf/components/heap/heap_caps.c:433
0x400856a0: esp_mbedtls_mem_calloc at /home/axel/esp/esp-idf/components/mbedtls/port/esp_mem.c:17
0x40144e2d: mbedtls_calloc at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/platform.c:61
0x4013cfd7: mbedtls_mpi_grow at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/bignum.c:129
(inlined by) mbedtls_mpi_grow at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/bignum.c:119
0x4013d141: mbedtls_mpi_lset at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/bignum.c:283
0x40142831: ecp_use_curve25519 at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ecp_curves.c:4646
(inlined by) mbedtls_ecp_group_load at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ecp_curves.c:4809
0x4013f94f: ecdh_setup_internal at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ecdh.c:201
(inlined by) mbedtls_ecdh_setup at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ecdh.c:234
0x4013fb39: mbedtls_ecdh_setup_no_everest at ??:?
0x40139dbe: ssl_tls13_generate_and_write_ecdh_key_exchange at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:295
(inlined by) ssl_tls13_write_key_share_ext at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:424
(inlined by) ssl_tls13_write_client_hello_body at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:796
(inlined by) ssl_tls13_write_client_hello at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:896
(inlined by) mbedtls_ssl_tls13_handshake_client_step at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:1733
0x401390de: mbedtls_ssl_handshake_step at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:5250
(inlined by) mbedtls_ssl_handshake_step at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:5225
0x40139117: mbedtls_ssl_handshake at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:5317
(inlined by) mbedtls_ssl_handshake at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:5293
0x401329d5: esp_mbedtls_handshake at /home/axel/esp/esp-idf/components/esp-tls/esp_tls_mbedtls.c:180
0x401326bd: esp_tls_handshake at /home/axel/esp/esp-idf/components/esp-tls/esp_tls.c:79 (discriminator 15)
(inlined by) esp_tls_low_level_conn at /home/axel/esp/esp-idf/components/esp-tls/esp_tls.c:421 (discriminator 15)
0x40132797: esp_tls_conn_new_sync at /home/axel/esp/esp-idf/components/esp-tls/esp_tls.c:483
0x401338c3: ssl_connect at /home/axel/esp/esp-idf/components/tcp_transport/transport_ssl.c:111
0x40192f07: esp_transport_connect at /home/axel/esp/esp-idf/components/tcp_transport/transport.c:173
0x40134af8: esp_http_client_connect at /home/axel/esp/esp-idf/components/esp_http_client/esp_http_client.c:1247
(inlined by) esp_http_client_connect at /home/axel/esp/esp-idf/components/esp_http_client/esp_http_client.c:1219
0x40134d8d: esp_http_client_open at /home/axel/esp/esp-idf/components/esp_http_client/esp_http_client.c:1402

assert failed: block_trim_free heap_tlsf.c:377 (block_is_free(block) && "block must be free")
Backtrace:0x40081de2:0x3ffdf2200x400896ed:0x3ffdf240 0x40090469:0x3ffdf260 0x4008e4c1:0x3ffdf380 0x4008ece2:0x3ffdf3a0 0x40081f3f:0x3ffdf3c0 0x40081f51:0x3ffdf3f0 0x4008215d:0x3ffdf410 0x400856a0:0x3ffdf430 0x40144e2d:0x3ffdf450 0x4013cfd7:0x3ffdf470 0x4013d141:0x3ffdf490 0x4014283f:0x3ffdf4b0 0x4013f94f:0x3ffdf4d0 0x4013fb39:0x3ffdf4f0 0x40139dbe:0x3ffdf510 0x401390de:0x3ffdf5d0 0x40139117:0x3ffdf5f0 0x401329d5:0x3ffdf610 0x401326bd:0x3ffdf630 0x40132797:0x3ffdf660 0x401338c3:0x3ffdf690 0x40192f07:0x3ffdf6b0 0x40134af8:0x3ffdf6d0 0x40134d8d:0x3ffdf6f0 0x400dac71:0x3ffdf710 0x400db219:0x3ffdf780 0x401951c3:0x3ffdf7a0 0x400db245:0x3ffdf7f0
0x40081de2: panic_abort at /home/axel/esp/esp-idf/components/esp_system/panic.c:403
0x400896ed: esp_system_abort at /home/axel/esp/esp-idf/components/esp_system/esp_system.c:130
0x40090469: __assert_func at /home/axel/esp/esp-idf/components/newlib/assert.c:85
0x4008e4c1: block_locate_free at /home/axel/esp/esp-idf/components/heap/heap_tlsf.c:447
(inlined by) tlsf_malloc at /home/axel/esp/esp-idf/components/heap/heap_tlsf.c:757
0x4008ece2: multi_heap_malloc_impl at /home/axel/esp/esp-idf/components/heap/multi_heap.c:189
0x40081f3f: heap_caps_malloc_base at /home/axel/esp/esp-idf/components/heap/heap_caps.c:139
0x40081f51: heap_caps_malloc at /home/axel/esp/esp-idf/components/heap/heap_caps.c:159
0x4008215d: heap_caps_calloc at /home/axel/esp/esp-idf/components/heap/heap_caps.c:433
0x400856a0: esp_mbedtls_mem_calloc at /home/axel/esp/esp-idf/components/mbedtls/port/esp_mem.c:17
0x40144e2d: mbedtls_calloc at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/platform.c:61
0x4013cfd7: mbedtls_mpi_grow at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/bignum.c:129
(inlined by) mbedtls_mpi_grow at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/bignum.c:119
0x4013d141: mbedtls_mpi_lset at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/bignum.c:283
0x4014283f: ecp_use_curve25519 at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ecp_curves.c:4649
(inlined by) mbedtls_ecp_group_load at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ecp_curves.c:4809
0x4013f94f: ecdh_setup_internal at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ecdh.c:201
(inlined by) mbedtls_ecdh_setup at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ecdh.c:234
0x4013fb39: mbedtls_ecdh_setup_no_everest at ??:?
0x40139dbe: ssl_tls13_generate_and_write_ecdh_key_exchange at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:295
(inlined by) ssl_tls13_write_key_share_ext at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:424
(inlined by) ssl_tls13_write_client_hello_body at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:796
(inlined by) ssl_tls13_write_client_hello at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:896
(inlined by) mbedtls_ssl_tls13_handshake_client_step at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls13_client.c:1733
0x401390de: mbedtls_ssl_handshake_step at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:5250
(inlined by) mbedtls_ssl_handshake_step at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:5225
0x40139117: mbedtls_ssl_handshake at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:5317
(inlined by) mbedtls_ssl_handshake at /home/axel/esp/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:5293
0x401329d5: esp_mbedtls_handshake at /home/axel/esp/esp-idf/components/esp-tls/esp_tls_mbedtls.c:180
0x401326bd: esp_tls_handshake at /home/axel/esp/esp-idf/components/esp-tls/esp_tls.c:79 (discriminator 15)
(inlined by) esp_tls_low_level_conn at /home/axel/esp/esp-idf/components/esp-tls/esp_tls.c:421 (discriminator 15)
0x40132797: esp_tls_conn_new_sync at /home/axel/esp/esp-idf/components/esp-tls/esp_tls.c:483
0x401338c3: ssl_connect at /home/axel/esp/esp-idf/components/tcp_transport/transport_ssl.c:111
0x40192f07: esp_transport_connect at /home/axel/esp/esp-idf/components/tcp_transport/transport.c:173
0x40134af8: esp_http_client_connect at /home/axel/esp/esp-idf/components/esp_http_client/esp_http_client.c:1247
(inlined by) esp_http_client_connect at /home/axel/esp/esp-idf/components/esp_http_client/esp_http_client.c:1219
0x40134d8d: esp_http_client_open at /home/axel/esp/esp-idf/components/esp_http_client/esp_http_client.c:1402

Hello, @AxelLin!
Thank you for sending the report. I was investigating this issue but unfortunately could not reproduce it with the esp_http_client example. Rather than a system abort, I got the following logs (with hookbin.com and api.github.com) indicating a TLS extension mismatch. (The mbedtls support for TLS 1.3 is still developing - see here).
I (12022) http_client: Connected to AP, begin http example
E (16982) esp-tls-mbedtls: mbedtls_ssl_handshake returned -0x7500
I (16992) esp-tls-mbedtls: (FFFF8B00): SSL - Client received an extended server hello containing an unsupported extension
I (16992) esp-tls-mbedtls: Certificate verified.
E (17002) esp-tls: Failed to open new connection
E (17002) TRANSPORT_BASE: Failed to open a new connection
E (17012) HTTP_CLIENT: Connection failed, sock < 0
E (17022) http_client: HTTP POST request failed: ESP_ERR_HTTP_CONNECT
I (17032) http_client: HTTP_EVENT_DISCONNECTED
I (17032) http_client: Last esp error code: 0x801a
I (17042) http_client: Last mbedtls failure: 0x7500
I (17042) http_client: Finish http example

Could you please attach -

Minimal code snippet that reproduces the bug
The sdkconfig file
Debug logs (with CONFIG_LOG_DEFAULT_LEVEL_DEBUG=y)

Hi @laukik-hase
You can use esp_http_client example code to reproduce the issue (without any code modification), just need to set below settings:
(I think the key point is to set CONFIG_MBEDTLS_DYNAMIC_BUFFER=y)
#
# mbedTLS
#
CONFIG_MBEDTLS_INTERNAL_MEM_ALLOC=y
# CONFIG_MBEDTLS_DEFAULT_MEM_ALLOC is not set
# CONFIG_MBEDTLS_CUSTOM_MEM_ALLOC is not set
CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN=y
CONFIG_MBEDTLS_SSL_IN_CONTENT_LEN=16384
CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN=4096
CONFIG_MBEDTLS_DYNAMIC_BUFFER=y
# CONFIG_MBEDTLS_DYNAMIC_FREE_CONFIG_DATA is not set
# CONFIG_MBEDTLS_DEBUG is not set

#
# mbedTLS v3.x related
#
CONFIG_MBEDTLS_SSL_PROTO_TLS1_3=y
CONFIG_MBEDTLS_SSL_TLS1_3_COMPATIBILITY_MODE=y
# CONFIG_MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH is not set
# CONFIG_MBEDTLS_X509_TRUSTED_CERT_CALLBACK is not set
# CONFIG_MBEDTLS_SSL_CONTEXT_SERIALIZATION is not set
CONFIG_MBEDTLS_SSL_KEEP_PEER_CERTIFICATE=y
# end of mbedTLS v3.x related

#
# Certificate Bundle
#
CONFIG_MBEDTLS_CERTIFICATE_BUNDLE=y
CONFIG_MBEDTLS_CERTIFICATE_BUNDLE_DEFAULT_FULL=y
# CONFIG_MBEDTLS_CERTIFICATE_BUNDLE_DEFAULT_CMN is not set
# CONFIG_MBEDTLS_CERTIFICATE_BUNDLE_DEFAULT_NONE is not set
# CONFIG_MBEDTLS_CUSTOM_CERTIFICATE_BUNDLE is not set
# end of Certificate Bundle

# CONFIG_MBEDTLS_ECP_RESTARTABLE is not set
# CONFIG_MBEDTLS_CMAC_C is not set
CONFIG_MBEDTLS_HARDWARE_AES=y
CONFIG_MBEDTLS_HARDWARE_MPI=y
CONFIG_MBEDTLS_HARDWARE_SHA=y
CONFIG_MBEDTLS_ROM_MD5=y
# CONFIG_MBEDTLS_ATCA_HW_ECDSA_SIGN is not set
# CONFIG_MBEDTLS_ATCA_HW_ECDSA_VERIFY is not set
CONFIG_MBEDTLS_HAVE_TIME=y
# CONFIG_MBEDTLS_HAVE_TIME_DATE is not set
CONFIG_MBEDTLS_ECDSA_DETERMINISTIC=y
CONFIG_MBEDTLS_SHA512_C=y
# CONFIG_MBEDTLS_TLS_SERVER_AND_CLIENT is not set
# CONFIG_MBEDTLS_TLS_SERVER_ONLY is not set
CONFIG_MBEDTLS_TLS_CLIENT_ONLY=y
# CONFIG_MBEDTLS_TLS_DISABLED is not set
CONFIG_MBEDTLS_TLS_CLIENT=y
CONFIG_MBEDTLS_TLS_ENABLED=y

#
# TLS Key Exchange Methods
#
# CONFIG_MBEDTLS_PSK_MODES is not set
CONFIG_MBEDTLS_KEY_EXCHANGE_RSA=y
CONFIG_MBEDTLS_KEY_EXCHANGE_ELLIPTIC_CURVE=y
CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_RSA=y
CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA=y
CONFIG_MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA=y
CONFIG_MBEDTLS_KEY_EXCHANGE_ECDH_RSA=y
# end of TLS Key Exchange Methods

CONFIG_MBEDTLS_SSL_RENEGOTIATION=y
CONFIG_MBEDTLS_SSL_PROTO_TLS1_2=y
# CONFIG_MBEDTLS_SSL_PROTO_GMTSSL1_1 is not set
# CONFIG_MBEDTLS_SSL_PROTO_DTLS is not set
CONFIG_MBEDTLS_SSL_ALPN=y
CONFIG_MBEDTLS_CLIENT_SSL_SESSION_TICKETS=y
CONFIG_MBEDTLS_SERVER_SSL_SESSION_TICKETS=y

BTW,  I always got compile error with bellow config:
CONFIG_MBEDTLS_DYNAMIC_BUFFER=y
# CONFIG_MBEDTLS_HARDWARE_SHA is not set

Must set CONFIG_MBEDTLS_HARDWARE_SHA=y.

Hello, @AxelLin!
(The mbedtls support for TLS 1.3 is still developing - see here).

@laukik-hase
I understand the TLS 1.3 is in developing state.
It's difficult to know which part is already supported (should be working), and cannot differentiate the non-working part is becasue of bug or just not yet supported.
Do you have test cases to verify the working part of TLS1.3?

Hello, @AxelLin
The commit https://github.com/espressif/esp-idf/commit/87d3296c37a35caad790cb172d4441fcfb689d22 disables the usage of MBEDTLS_DYNAMIC_BUFFER when TLS 1.3 is enabled. Support for this is in progress and will be merged to ESP-IDF soon.

It's difficult to know which part is already supported (should be working), and cannot differentiate the non-working part is becasue of bug or just not yet supported.
Do you have test cases to verify the working part of TLS1.3?

We too are exploring more on TLS 1.3 support, and it has been difficult due to very few test endpoints being able to connect to mbedtls TLS 1.3 clients. The only endpoint we found was google.com (gives the HTTP/1.1 301 Moved Permanently response) but it is a functional example and can be used to test some of the features.
Sorry for the inconvenience.

@laukik-hase
I try to compile a third party libary but got build error as below in master tree.
(It was fine to compile with esp-idf stable branches)
/home/axel/esp/esp-idf/components/mbedtls/mbedtls/include/mbedtls/private_access.h:27:33: error: 'mbedtls_x509_crt' {aka 'const struct mbedtls_x509_crt'} has no member named 'private_version'; did you mean 'private_sig'?
#define MBEDTLS_PRIVATE(member) private_##member
^~~~~~~~
I check the code in esp-idf/components/mbedtls, only some file defines MBEDTLS_ALLOW_PRIVATE_ACCESS.
So now all the source file that includes private_access.h must define MBEDTLS_ALLOW_PRIVATE_ACCESS explictly?

Hello, @AxelLin!

So now all the source file that includes private_access.h must define MBEDTLS_ALLOW_PRIVATE_ACCESS explicitly?

Yes, you will have to define MBEDTLS_ALLOW_PRIVATE_ACCESS at the top of every file explicitly.

Hello, @AxelLin
The commit 87d3296 disables the usage of MBEDTLS_DYNAMIC_BUFFER when TLS 1.3 is enabled. Support for this is in progress and will be merged to ESP-IDF soon.

@laukik-hase
What will be merged soon? It has been 5 months since you replied but I still don't find the fix.

Hello, @AxelLin!
Sorry for the late reply and the inconvenience.

Mbed TLS has now been upgraded to v3.2.1. We have tried the https_request example with CONFIG_MBEDTLS_SSL_PROTO_TLS1_3 enabled with several test endpoints (example list), but none of them was able to connect to Mbed TLS-based TLS 1.3 clients. Could you suggest any endpoints with which you have established a connection with TLS 1.3? If not, you can raise an issue upstream about this.
As Mbed TLS is being upgraded, the dynamic buffers feature is now subject to some refactoring. Mbed TLS is splitting up TLS 1.2 and 1.3 implementations and adding their own variable length buffers feature. Even the update from v3.1.0 to v3.2.1 broke the feature (as fixed in https://github.com/espressif/esp-idf/commit/9b290e3668a562ed279445131f4e523a370e05e5).

Thus, this request has been now pushed to the backlog queue. Sadly, we will have to wait until Mbed TLS's TLS 1.3 implementation gets stable.

Hello, @AxelLin!
Sorry for the late reply and the inconvenience.

Mbed TLS has now been upgraded to v3.2.1. We have tried the https_request example with CONFIG_MBEDTLS_SSL_PROTO_TLS1_3 enabled with several test endpoints (example list), but none of them was able to connect to Mbed TLS-based TLS 1.3 clients. Could you suggest any endpoints with which you have established a connection with TLS 1.3? If not, you can raise an issue upstream about this.
As Mbed TLS is being upgraded, the dynamic buffers feature is now subject to some refactoring. Mbed TLS is splitting up TLS 1.2 and 1.3 implementations and adding their own variable length buffers feature. Even the update from v3.1.0 to v3.2.1 broke the feature (as fixed in 9b290e3).

Thus, this request has been now pushed to the backlog queue. Sadly, we will have to wait until Mbed TLS's TLS 1.3 implementation gets stable.

@laukik-hase
The latest mbedTLS release is v3.4.0 now.
Do you have further update regarding TLS 1.3 support?
BTW, wolfssl also supports TLS 1.3, you can take a look how they test TLS 1.3.

Hello @AxelLin,
As mentioned in the mbedtls documentation and it's workflow TLS1.3 uses PSA crypto APIs. Adding support for mbedtls' PSA crypto in ESP-IDF would be a major task and we are looking into it. Once the support is completely added, I think we could also support TLS1.3.

@AxelLin
We have now enabled and verified the TLS 1.3 with https_request and simple_ota_example. Relevant CI tests also have been added. Please find details in following commits:
cba923788ec2d4721ad7996db5c956a8e3305d23
200cf10373f3ab8cf1429a34d96cd98a249fc458
Please note that we are not planning to support dynamic buffer feature with TLS 1.3, as the upstream API is not yet stable. Easiest way to verify the use-case could be, host the OTA update file on github.com, enable TLS 1.3 and then verify OTA update example. This feature will be supported in IDF 5.2 release, as we are still evaluating memory profile and few other pending items.
Please do let us know if you run into any issues, otherwise we can close this ticket.

@AxelLin
We have now enabled and verified the TLS 1.3 with https_request and simple_ota_example. Relevant CI tests also have been added. Please find details in following commits:
cba9237 200cf10
Please note that we are not planning to support dynamic buffer feature with TLS 1.3, as the upstream API is not yet stable.

Hi @mahavirj
The Mbed TLS 3.6.0 LTS is released.
I'm wondering if you can check again for the dynamic buffer feature with TLS 1.3.
Since it's a LTS version, I think the API is stable for LTS branch.
And maybe you can also check if https://github.com/espressif/esp-idf/issues/8325 can be addressed by @LJYSP 's patch (https://github.com/espressif/esp-idf/issues/8325#issuecomment-1118134508).


Fix: Add static error state

IntegSoft requested a static error state. I used dotcom styling to add a duplicate Password field showing an error state.
Note that this static error field is only for IntegSoft reference as to how an error state should look.
Asana ticket (see comments for context): https://app.asana.com/0/0/1200981513142981/f

There is no reference in the SSO Annotation slides for this.

Love these changes! Implemented now, along with text changes to mirror the screenshot above

.

Makes sense! SVG and associated style removed 👍


Stack level too deep with ActiveSupport logger after ~ 475 requests

When I run my project in development mode with the rails-footnootes gem. I'm getting a SystemStackError: stack level too deep error after ~475 requests to localhost.
This happens with rails 4.2+, 5.0+ and ruby 2.2+. Only workaround is to remove the gem or overwrite ActiveSupport::Logger to not call super on add and close (see http://stackoverflow.com/questions/39596073/stack-level-too-deep-with-activesupport-logger-after-475-requests#comment66514021_39596073).
Relevant files:

Stacktrace
Gemfile.lock (incl. rails-footnotes)
Monkey patched ActiveSupport::Logger

Happy to reopen and investigate if you can provide reproduction steps, but closing for now since I am not able to reproduce this.


[Bug]: text-to-SQL example fails with the new LlamaCPP fallback

Bug Description
The example of a text-to-SQL query that is provided here:
https://gpt-index.readthedocs.io/en/latest/examples/index_structs/struct_indices/duckdb_sql_query.html
fails with the latest 0.8.2.x
when it tries to use the new default llm, which is
Using default LlamaCPP=llama2-13b-chat.
as per the message that shows up when I instantiate a
NLSQLTableQueryEngine
I suspect the expected format of the first response, in which he the SQL query is generated, may be wrong.
The error message, no matter the query I try to make, is always in the following form:
ProgrammingError: (duckdb.ParserException) Parser Error: syntax error at or near "Sure"
LINE 1: Sure, I'd be happy to help! Here's the ...
        ^
[SQL: Sure, I'd be happy to help! Here's the query to list all cities in reverse alphabetical order based on the 'city_name' column:
SQLQuery: SELECT city_name FROM city_stats ORDER BY city_name DESC;

This will return a list of all cities in the 'city_stats' table, sorted in reverse alphabetical order based on the 'city_name' column.

Now, let me run the query and provide the results:]

Version
0.8.2.post1
Steps to Reproduce
simply through the first example in: https://gpt-index.readthedocs.io/en/latest/examples/index_structs/struct_indices/duckdb_sql_query.html
Relevant Logs/Tracbacks
No response

Thanks for the tip. Unfortunately, using a restrictive text_to_sql_prompt does not seem to have any effect.
It still returns the same error i.e.
ProgrammingError: (duckdb.ParserException) Parser Error: syntax error at or near "Sure"
LINE 1: Sure, I'd be happy to help! Here's the ...
        ^
[SQL: Sure, I'd be happy to help! Here's the SQL query to find the city with the highest population:
SQLQuery: SELECT city_name, population FROM city_stats WHERE population = (SELECT MAX(population) FROM city_stats);
This query uses a subquery to find the maximum population in the city_stats table and then selects only the rows where the population matches that value.
Now, let me run this query and provide the results:]

Should merge a PR (linked above) that will help. Confirmed it worked with llama2-chat-13B and our SQL notebook demo

Sounds great! Looking forward to  trying it out once released.


Added a new chapter to do a full cluster upgrade

I've added a new chapter that will show how to take this cluster from 1.17 to 1.18 with eksctl. I also added a note to the cluster provisioning step indicating why it is one version behind kind of as a reminder for people to not try to make that current so that we can have this upgrade chapter going forward.

I was initially blocked by https://github.com/weaveworks/eksctl/issues/3201 but on closer examination, this appears to be an internal-only problem. I'm going to merge, but knowing that internal accounts may still run into this problem.
An easy work-around is to use:
aws eks update-nodegroup-version --cluster-name eksworkshop-eksctl --nodegroup-name nodegroup


threads: add hammer tests

where are these cases coming from? written by you?

Yeah these were written by me manually considering code coverage of the new instructions.
As in the comment I wasn't able to come up with deterministic test cases for certain instructions though.


Added pytest-extra-durations to monitor the speed of the tests.

Closes #1316
Current output:
========================== slowest modules durations ===========================
49.85s tensorflow_addons/seq2seq/tests/attention_wrapper_test.py
24.94s tensorflow_addons/layers/tests/normalizations_test.py
17.38s tensorflow_addons/image/tests/filters_test.py
14.21s tensorflow_addons/optimizers/tests/lookahead_test.py
14.14s tensorflow_addons/optimizers/tests/rectified_adam_test.py
======================= slowest test functions durations =======================
11.66s tensorflow_addons/layers/tests/optical_flow_test.py::test_gradients
10.53s tensorflow_addons/optimizers/tests/cyclical_learning_rate_test.py::test_exponential_cyclical_learning_rate
7.97s tensorflow_addons/optimizers/tests/lookahead_test.py::test_fit_simple_linear_model
7.69s tensorflow_addons/optimizers/tests/novograd_test.py::test_fit_simple_linear_model
6.88s tensorflow_addons/optimizers/tests/stochastic_weight_averaging_test.py::test_fit_simple_linear_model
6.00s tensorflow_addons/layers/tests/normalizations_test.py::test_groupnorm_2d_different_groups
5.97s tensorflow_addons/optimizers/tests/moving_average_test.py::test_fit_simple_linear_model
5.58s tensorflow_addons/seq2seq/tests/attention_wrapper_test.py::AttentionMechanismTest::test_save_load_layer_bahdanau_monotonic
5.28s tensorflow_addons/seq2seq/tests/attention_wrapper_test.py::AttentionMechanismTest::test_save_load_layer_bahdanau
5.18s tensorflow_addons/seq2seq/tests/attention_wrapper_test.py::AttentionMechanismTest::test_save_load_layer_luong
5.04s tensorflow_addons/seq2seq/tests/attention_wrapper_test.py::AttentionMechanismTest::test_save_load_layer_luong_monotonic
3.81s tensorflow_addons/optimizers/tests/lookahead_test.py::test_sparse_exact_ratio
3.64s tensorflow_addons/layers/tests/normalizations_test.py::test_picture_input
3.43s tensorflow_addons/layers/tests/wrappers_test.py::test_model_build
3.31s tensorflow_addons/layers/tests/netvlad_test.py::test_simple
2.97s tensorflow_addons/seq2seq/tests/attention_wrapper_test.py::AttentionWrapperTest::testLuongScaled
2.94s tensorflow_addons/image/tests/dense_image_warp_test.py::test_interpolation
2.76s tensorflow_addons/callbacks/tests/time_stopping_test.py::test_time_stopping_verbose
2.69s tensorflow_addons/losses/tests/npairs_test.py::test_unweighted
2.67s tensorflow_addons/seq2seq/tests/attention_wrapper_test.py::AttentionMechanismTest::test_memory_re_setup_bahdanau_monotonic
========================== sum of all tests durations ==========================
271.92s

LGTM! Do you want to make any other changes or should I merge this one now? @gabrieldemarmiesse

That's all folks!

Thanks


AssertionError: Torch not compiled with CUDA enabled

While running demo.py, I am able to initialize the various models but get terminated with the AssertionError.

How was your torch installed?

Makes me think now.
I feel that I created a conda env without specifying the python version and when I ran pip install -r requirements.txt, there was a dependency conflict as No matching distribution found for torch==1.13.1+cu117
So I think I manually went ahead with 2.0.1
PS: which python version shall I use to create my env?

Fresh install with python=3.9 solved the error. Hence closing.


Add error messaging for the --detach-keys flag

Reported by @jpetazzo
If I pass an invalid sequence it just accepts it without showing an error (and silently reverts to ^P^Q) also, I don't think that [a-Z] is a valid glob entry

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

Note: the warning is actually shown in the daemon log.

@mlaventure That's good to know. Does your response mean you think a CLI message is unnecessary?

I think it would be good to have it on the CLI side. I don't think many people would have the reflex to look at the daemon log, and they will just wonder why is their detach combination is not work.
I just wanted to point that we actually were reporting it somewhere :)

Ah, cool. I was hoping you'd say that.  IDK if we have anything where we state our policy for adding these things like --- need a cli error and a log; I think having both are the ideal.

:+1:
Client should report an error instead of swallow it, I want to pick up this if no one is working on this.
#dibs


Road to ember-bootstrap 1.0

This is a Work in Progress PR to design, discuss and track the changes that are planned for a stable 1.0 release of ember-bootstrap. All users are encouraged to participate with comments and suggestions!
Scope of a 1.0 release
The basic idea of a first stable 1.0 release is not to add any new components or other features. Instead its focus will be to improve and stabilize its public API, make it coherent across components and follow modern ember best practices ("idiomatic ember").
In particular it should address these current issues:

Apply the DDAU pattern everywhere: some older components violate this by changing public properties through two-way bindings instead of just triggering an action
Remove the need for private APIs: components that follow a parent/child relationsship make use of private APIs (see the child and parent mixins).
Make child components (e.g. a NavItem component can only be used within a Navparent component) kind of private

The latter two issues can be solved by using the contextual components feature of Ember 2.3+
Breaking change
ember-bootstrap 1.0 will be a backwards incompatible change, because of the proposed API changes. But this will clear the way to have a stable API with strict semver compliance starting at 1.0.
To Do
Fix DDAU (replaces #129):

[x] Button: active state
[x] ButtonGroup: value should be one way, call action
[x] Alert: visible should be one way
[ ] FormElement: use one way controls (replaces #104)
[x] Modal: open property is modified when autoClose is set
[ ] Accordion: selected property is modified
[ ] Tabs: activeId property is modified

Apply contextual components (replaces #86):

[x] ButtonGroup -> Button
[x] Modal -> ModalHeader/ModalBody/ModalFooter
[x] Nav -> NavItem
[x] Navbar -> NavbarNav/NavbarToggle/NavbarContent
[x] Dropdown -> DropdownToggle/DropdownButton/DropdownMenu
[ ] Tab -> TabPane
[ ] Accordion -> AccordionItem

Other:

[ ] Unify action names: on<Event>. Remove use of default action (action) in favor of speaking name.
[ ] Drop bs-select

@simonihmig I can restore the contextual components for navbar in the next few days.  Any other areas in particular you'd like me to take on?

Hey @srvance, that would be really nice!
As stated in my check list, I also started to rename action names to on<Event>  for more consistent naming. And I changed action invokation from sendAction calls to directly calling close action. See this commit: https://github.com/kaliber5/ember-bootstrap/pull/158/commits/05a9606a7b36295befea7c28781c737f35102c4f
When you are ready, just submit a PR to the "release-1.0" branch, not master!

Will do! Watch for it by the end of the upcoming US holiday weekend, if not sooner.

@simonihmig I'm thinking of nesting the navbar components. what do you think?
Also, I'm updating to<EMAIL_ADDRESS>and ember-2.9.0.  I'd like to eliminate the deprecation warnings on npm install.

Yes, I forgot to mention that by myself: nesting! :) If you look at the release-1.0 branch, the bs-modal components has been refactored already, and all the sub components (here header/body/footer) are nested under bs-modal. Basically every contextual component that is yielded should be regarded as kind of private (in the sense that a user should not create it directly) and be nested under its public parent.

@simonihmig So it inherits the template, after all!

Just a word of encouragement for you.
Big task ! The "one way controls" will be a great feature.

@Moxide thanks! Most of it is done though, more or less just the one way controls are missing... :)

Just wanted to stop in and leave a huge THANK YOU comment to everyones hard work.  1.0 feels so close!

This is directly related to the refactorings I was making for ember-bootstrap 1.0. For anyone reading this, please give some feedback! :)
https://gist.github.com/simonihmig/f4cada751b89b192f608bcb83ed1c22a
https://twitter.com/simonihmig/status/811648173932445696

Just released v1.0.0-alpha, fyi!


Python reserved word as an attribute

Hello people, I have class that must have a from attribute. Using attrs, I would first try the code below:
@attr.s()
class Message:
    from = attr.ib()
    # ...

But since from is a reserved word, I got a SyntaxError. Can I customize the name of the field? Something like this:
@attr.s()
class Message:
    _from = attr.ib('from')
    # ...

I couldn't find anything on the docs and this example comes from Django model fields.
Thank you!

Imho This makes no sense, as it wouldn't be usable sanely

The Django example IIRC maps the DB column from to the field _from so that you never access it using the reserved keyword from in your code. You cannot have an attribute from in Python, with or without attrs. The question is what you're really trying to achieve.

@RonnyPfannschmidt why?
@hynek I was thinking about using attrs/cattrs as an object serialization (classes from json), at first it seems to be the way.

Yeah that sounds like a serialization issue, not attrs. You should look at cattrs and if such renaming isn't supported, open an issue there.

Thank you @hynek.

@rougeth , There is renaming support in related which is built on top of attrs. It supports nested classes and does key renaming.
Library:
https://github.com/genomoncology/related
Example Unit test for doing renaming:
https://github.com/genomoncology/related/blob/master/tests/ex05_field_names/test_renamed.py

Thank you @imaurer! I'm testing schematics, it seems to have everything I need right now.

@rougeth Link? Should we add schematics to https://github.com/python-attrs/attrs/wiki/Extensions-to-attrs ?

I think what he’s saying is that he abandoned attrs. 🙃

Kind of, schematics isn't an extensions for attrs. But, I'm still using it, attrs helped me a lot. Thank you @hynek and all the contributes for the awesome lib. 😄


Closes #8775 Scripts started via CLI should also be able to write into the process table

Hi!
Reference
With this PR, I'm providing a feature that allows the script launched via CLI to be saved in Process table.
Fixes #8775
Instructions for Reviewers
This feature is disabled by default. To activate it you need to go to dspace.cfg and set process.save-enable = true, and most important, you need to set the EPerson ID to associate the owner process in process.eperson.
Description

I modified the steps of CommandLineDSpaceRunnableHandler to manage the creation of process on database (like RestDspaceRunnableHandler).
I created a new constructor for CommandLineDSpaceRunnableHandler to save script name and the parameters list

PS: this is my first PR, feel free to suggest me how to improve my PR or its commit :)

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
[x] My PR passes Checkstyle validation based on the Code Style Guide.
[x] My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
[x] My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
[ ] If my PR includes new libraries/dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[ ] If my PR modifies REST API endpoints, I've opened a separate REST Contract PR related to this change.
[x] If my PR includes new configurations, I've provided basic technical documentation in the PR itself.
[x] If my PR fixes an issue ticket, I've linked them together.

@Bezkup : Apologies for the delay in getting back... I hadn't had time to revisit this PR.
I think you bring up a good point about the ./dspace database test script (which is what Ant executes in a "fresh_install").  If I run that script manually, I also see it adds an entry to the Processes table in the Admin UI:

This is a bit of a problem because the ./dspace database script CANNOT be run from the Admin UI.  It's not compatible with the Admin UI at this time. (Some are NOT meant to be run from the Admin UI.  This "database" script is too powerful & can run database migrations which is something you don't want to allow from the Admin UI... as it can potentially bring down the site.)
Yet, if I click on that entry in the processes list, I see this:

There are two issues here:

I cannot create a similar process (button doesn't work as this cannot be run from the Admin UI)
It is refreshing over and over again as the Admin UI thinks this process is not complete.  It never stops refreshing.  If you look closely at that first screenshot you'll see it has an empty start/finish time & empty status.

Overall, I think your simple question about this ./dspace database test script is showing us that there's a flaw in the design here.  I think we need to find a way to limit which scripts appear in the Processes page in the Admin UI.
More specifically, I'd suggest we may want to consider if there's a way to ONLY enable this feature for scripts which are visible/runnable in the Admin UI.  This likely means that you MUST remove the changes to ScriptLauncher in this PR, as scripts defined in [dspace]/config/launcher.xml are NOT runnable in the Admin UI.  Only scripts defined in [dspace]/config/spring/api/scripts.xml can be used both in the Admin UI and on CLI.   (In case it isn't clear, this would solve the "ant fresh_install" problem too as the ./dspace database script is only in launcher.xml)

@tdonohue: Don't worry, we are all busy in this period :D
Ok, I've tried to differentiate scripts within scripts.xml from the others within launcher.xml; I've used the class ScriptService to see if there are any ScriptConfiguration (as I understand, only scripts within scripts.xml have a ScriptConfiguration bean). Here is the function, tell me if you have a suggestion and how to improve it :)

@Bezkup : To clarify, I don't think you even need to add a function to determine which scripts are in scripts.xml.   While I could be wrong, I think the only change that might be necessary is to remove all your modifications to ScriptLauncher.java in this PR
The reason is that we have two types of "scripts" currently in DSpace.

Scripts defined in launcher.xml which are always run via ScriptLauncher.java
Scripts defined in scripts.xml which are always run via CommandLineDSpaceRunnableHandler.java and the equivalent RunnableHandler in the REST API.

So, I think all we need to do is ensure this PR doesn't touch ScriptLauncher.java... that, in itself should ensure that scripts that appear in launcher.xml are never saved to the process table.  In other words, your new method shouldn't be necessary once your changes to ScriptLauncher are removed.

@tdonohue Mmm I don't know.. My idea with that function came up when I saw this. So ScriptHandler handles both scripts in scripts.xml and launcher.xml. Maybe I've not understand this step

@Bezkup : Sorry, I misspoke/mistyped slightly.   You are correct, that both types of scripts "flow through" ScriptLauncher.  But, the ScriptLauncher.executeScript() your referenced calls the CommandLineDSpaceRunnableHandler to run anything in the scripts.xml here: https://github.com/DSpace/DSpace/blob/main/dspace-api/src/main/java/org/dspace/app/launcher/ScriptLauncher.java#L149
What I'm trying to point out, is that, because the ScriptLauncher calls to  CommandLineDSpaceRunnableHandler for everything in scripts.xml, I don't think you need to actually touch the ScriptLauncher.  All you need to do is ensure that everything run via CommandLineDSpaceRunnableHandler is added to the processes table... that will already exclude all the processes in launcher.xml because they are run by the ScriptLauncher.runOneCommand() method.

@tdonohue Somehow I need to modify ScriptLauncher because if I don't pass the script name and arguments to CommandLineDSpaceRunnableHandler I cannot insert them in Process table. Can I retrieve them elsewhere?

UPDATE: I should add, it's possible I'm overlooking something too. But I just find it odd that we need to check if something is in scripts.xml in two places. Once in ScriptLauncher (to decide whether to call CommandLineDSpaceRunnableHandler) and then a second time now in your new method. It seems like we should have already filtered out what is in scripts.xml with the first check that you referenced.

Yes, you're right. I was considering creating a DspaceRunnable and retrieve its configuration and pass it as a boolean (script != null) to the constructor of CommandLineDSpaceRunnableHandler. This would allow us to avoid to create the new function, and passing the DspaceRunnable (that might be null) to ScriptLauncher.handleScript() to determine which function to call (executeScript() or runOneCommand()). However, I believe it's not a good idea due to its complexity and the fact that this function is heavily used in many test classes.
Sorry if it sounds tricky but it's a bit complicated to manage :/

@tdonohue What if we move the logic of Process creation from CommandLineDSpaceRunnableHandler constructor to CommandLineDSpaceRunnableHandler.start() method? So we are 100% sure that Process will create only if the script is inside scripts.xml and avoid to call another function to verify this.
But I still have to pass the script name and parameters to constructor so I can create the Process when start() method is called

@Bezkup : I fear I may have misled you...or gotten things confused.  I won't have immediate time this week to dig deep on this.  But, my main concern is simply that, prior to this PR, I believe that only scripts in scripts.xml ran via CommandLineDSpaceRunnableHandler.   This is the primary way that we "filtered out" scripts from launcher.xml appearing in the Admin UI.
So, assuming that is true, I believe that we already have a way to ensure that scripts in launcher.xml do NOT appear in the Admin UI.  All that you therefore need to do in this PR is ensure that scripts from scripts.xml run from CLI also now appear in the Admin UI.   You are correct that this still may require some modifications to ScriptLauncher.  However, you need to find a way to ensure modifications to ScriptLauncher do NOT get run by scripts in launcher.xml...as you only need to deal with the scripts in scripts.xml. (E.g. you are modifying ScriptLauncher.main() which both types of scripts use... while I understand the reasons why, it's odd that scripts in launcher.xml are also running this code.  Shouldn't some/all of that code move into the "executeScript()" method which will ONLY be run by scripts in scripts.xml?)
I hope that makes some sense.  I'm swamped this week, so I don't know that I can provide more exact advice.  I'm just worried that some of the code in this PR is unnecessarily changing the behavior of scripts in launcher.xml, when all it needs to do is change the behavior of scripts in scripts.xml.   If you find a cleaner solution that you feel works well, I'm OK with it.

I believe this commit is the cleanest way to achieve this. I attempted to overload the ScriptLauncher.handleScript to accept only args e commandArgs and create a CommandLineDspaceHandler solely when the script is in scripts.xml. But the older function were only used in test classes, which makes it useless
Let me know if you have a suggestion, because I've run out of ideas :/

@abollini  Hi! Alright then, I'll make another PR with only nullable. I'm happy to wait for any information you have about this PR :)

@Bezkup i re-ran the integration test pipeline and it has now passed :)

Closing this PR, I will reopen it when the time come :)


Merge dsl2 template

DSL2 conversion (closes https://github.com/qbic-pipelines/metapep/issues/68).
PR checklist

[x] This comment contains a description of changes (with reason)
[x] CHANGELOG.md is updated
[ ] If you've fixed a bug or added code that should be tested, add tests!
[x] Documentation in docs is updated
[x] If necessary, also make a PR on the nf-core/metapep branch on the nf-core/test-datasets repo

Just saw it now, well done @AntoniaSchuster :)


NEAR Wallet is deprecated

Describe the bug
"NEAR Wallet is deprecated" when select connect with Near Wallet since v4.1.0. Not sure if this is a bug or intention, but I can use this in v3.1.0
To Reproduce
In react example, click Log in button then select Near Wallet.
Expected behavior
Redirect to Near Wallet page as usual.

Hi @phucloc8697,
This change was intentional as NEAR are moving away from NEAR Wallet to My NEAR Wallet. dApp users that have previously selected NEAR Wallet will be unaffected but this change was made to prevent new selections of wallets that are considered deprecated

@lewis-sqa  Got it. But is there any official/unofficial announcement about this intention from NEAR team? Or is there a reasonable explain for why those wallets are being moved away?

@phucloc8697 There's been some internal discussions with NEAR about this move though it was mentioned in this PR: https://github.com/near/wallet-selector/pull/288.
Maybe @MaximusHaximus can help provide more detail?

Hi @phucloc8697, as Lewis mentioned, the NEAR Wallet at wallet.near.org is moving to a new domain as My Near Wallet (mynearwallet.com). There'll be an awareness campaign and an official announcement soon: https://twitter.com/MyNearWallet/status/1537077521329561600?s=20&t=xP-eVEFNwEp4Y1l9xzLp7A


Flutter 3.3. - No way to use PrimaryScrollController on Desktop/Web platforms

Issue: No way to use PrimaryScrollController on Desktop/Web platforms due to it no longer automatically attaching to vertical ScrollViews on desktop platforms with Flutter 3.3+
Use Case: This is necessary so an application can detect the position and retrieve additional data (infinite scroll).
Possible Solution: Either expose a way to set the ListView.Builder.primary parameter OR allow passing in a ScrollController.
Flutter 3.3 behavior change documentation
https://docs.flutter.dev/release/breaking-changes/primary-scroll-controller-desktop

Thanks for the issue. I will take a look at it next week 👍🏼

I just released version 1.3.0 of this package with the possibility to access the underlying ListView options. This should resolve this issue.
For more information and changes, see: https://github.com/hauketoenjes/responsive_grid_list/releases/tag/v1.3.0


[BugFix] Fix alter routine load npe

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes #7803
Problem Summary(Required) ：

Do not merge load properties if load properties is null

[FE PR Coverage check]
:heart_eyes: pass : 1 / 1 (100.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/load/routineload/RoutineLoadJob.java
1
1
100.00%

https://github.com/Mergifyio backport branch-2.1

https://github.com/Mergifyio backport branch-2.2


chore: specify types for parachain v0.10.0

Signed-off-by: Gregory Hill<EMAIL_ADDRESS>

@sander2 why is querying the oracle's storage a problem?


boards/stm32f0l0g0: rework boards to not use legacy pinmap

Summary

boards/stm32f0l0g0: rework boards to not use CONFIG_STM32F0L0G0_USE_LEGACY_PINMAP=y
arch/stm32f0l0g0: fix compilation for L0 pinmap

Impact
Continuation to PR #8992
Testing
CI

@raiden00pl - Thank you for fixing the pinmap and doing the translation!


feat(Namespace): generic const parameter for namespace id size

Allow for namespace id's of different length through the const generic.
This depends on #6, feel free to check last commit for a separated diff

Thanks, will address those tomorrow

Looks great, thanks for the PR @zvolin!


chore(ci): add condition for "auto-releasing"

This PR changed our "Create GUI PR" workflow:

Naming. I changed the name to release.yaml / Build and release to kumahq/kuma because we are releasing the GUI to the binary/kuma. "Create GUI PR" sounds like I am creating a PR on kumahq/kuma-gui
Added a repository-data job that fetches all "topics" from the repository
Uses the repository-data output to look for a auto-release "topic" which when present (as it is currently) performs a "release" as before.

I plan on merging this with the auto-release "topic" applied to prove it works (validate the PR is made). I will then remove the auto-release topic temporarily.
Notes:

I "think" I can't access the secrets in a run because I'm PRing from a forked PR, hence will currently fail until this is on master. I would level a better way to test this out (and GH Actions as a whole really) edit: I confirmed offline that my guess here is right.
In this PR we have two calls to get the GH token. One during the actual "release" and one to have permissions to access the repo topics. I plan on reusing the one in the repository-data job across the entire workflow once this PR is merged and we know it works as expected 🤞

@lahabana showed me a button in the GH UI that does exactly what this PR does 😆 , so a lot of this PR is no longer needed.

There are some bits here that I'd like to keep, mostly the renaming of "Create GUI PR" to "Release". We'd also like to improve the "release" PRs to include more changelog information.
For the moment I'm going to put this back into draft. While I re-jiggle this about a bit.


Bump Go to 1.10

Signed-off-by: Denys Smirnov<EMAIL_ADDRESS>

If there are no objections, I would suggest to close this in favor of #164 that has ✅'ed the CI.

closing as #164 is merged now


"Must initialize Fabric before using singleton"

On RN 0.26 everything works fine. After upgrading to RN 0.34 we encountered on android the exception mentioned in the title. On iOS everything works fine, only android is broken for us.
android/app/build.gradle:
dependencies {
    compile project(':react-native-vector-icons')
    compile project(':react-native-uuid-generator')
    compile project(':react-native-sound')
    compile project(':react-native-i18n')
    compile project(':react-native-google-analytics-bridge')
    compile project(':react-native-fs')
    compile project(':react-native-fetch-blob')
    compile project(':react-native-fabric')
    compile project(':react-native-extra-dimensions-android')
    compile project(':react-native-device-info')
    compile project(':react-native-code-push')
    compile project(':react-native-billing')
    compile project(':react-native-sqlite-storage')

    compile('com.crashlytics.sdk.android:crashlytics:2.5.5@aar') {
         transitive = true;
       }

    compile fileTree(dir: "libs", include: ["*.jar"])
    compile "com.android.support:appcompat-v7:23.0.1"
    compile "com.facebook.react:react-native:+"  // From node_modules
}

settings.gradle:
include ':react-native-fabric'
project(':react-native-fabric').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-fabric/android')

MainApplication.java:

    @Override
    protected List<ReactPackage> getPackages() {
      return Arrays.<ReactPackage>asList(
          new MainReactPackage(),
            new VectorIconsPackage(),
            new RNUUIDGeneratorPackage(),
            new RNSoundPackage(),
            new ReactNativeI18n(),
            new GoogleAnalyticsBridgePackage(),
            new RNFSPackage(),
            new RNFetchBlobPackage(),
            new SQLitePluginPackage(),
            new FabricPackage(),
            new ExtraDimensionsPackage(),
            new RNDeviceInfo()
    }
  };

Have i something forgotten?

Are you calling Fabric.with(this, new Crashlytics()); in your onCreate?

Thanks for reaching out so quickly! I've added onCreate() now as described in README.
It continues now with:

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

Failed to apply plugin [id 'io.fabric']
Crashlytics was applied to a project without an Android plugin. Please make sure the Crashlytics plugin is applied after the appropriate Android plugin for your project.

This is the build.gradle where i applied instructions from README.
// Top-level build file where you can add configuration options common to all sub-projects/modules.
// Top-level build file where you can add configuration options common to all sub-projects/modules.
apply plugin: "com.android.application"

buildscript {
    repositories {
        jcenter()
        maven { url 'https://maven.fabric.io/public' }
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.3.1'

        // The Fabric Gradle plugin uses an open ended version to react
        // quickly to Android tooling updates
        classpath 'io.fabric.tools:gradle:1.+'
        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {

  apply plugin: 'io.fabric'

  repositories {
        mavenLocal()
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url "$rootDir/../node_modules/react-native/android"
        }
        maven { url 'https://maven.fabric.io/public' }
    }

}

Have i missed something else?
Oh, and above the "Failed to apply plugin [id 'io.fabric']"  is another error shown:

Failed to notify ProjectEvaluationListener.afterEvaluate(), but primary configuration failure takes precedence.
java.lang.IllegalStateException: buildToolsVersion is not specified.
at com.google.common.base.Preconditions.checkState(Preconditions.java:176)
at com.android.build.gradle.BasePlugin.createAndroidTasks(BasePlugin.groovy:444)
at com.android.build.gradle.BasePlugin$_createTasks_closure13_closure17.doCall(BasePlugin.groovy:415)
at com.android.build.gradle.BasePlugin$_createTasks_closure13_closure17.doCall(BasePlugin.groovy)
at sun.reflect.GeneratedMethodAccessor884.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:324)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:292)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1015)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)

Missing onCreate() fixes this. Thanks a lot! Incredible fast support! :)

public class MainApplication extends Application implements ReactApplication {

  @Override
  public void onCreate() {
      super.onCreate();
      Fabric.with(this, new Crashlytics());
}

  private final ReactNativeHost mReactNativeHost = new ReactNativeHost(this) {

    @Override
    protected String getJSBundleFile() {
      return CodePush.getJSBundleFile();
    }

Hey guys
I just ejected my app with expoKit, but I dont understand there is no any onCreate method.
where should I put  Fabric.with(this, new Crashlytics());

@ozanhonamlioglu Did you ever resolve this? I have the same problem. No onCreate method and when I add one to initialize Fabric, my app immediately crashes.

Like @bethshook, I have same issue here.
With Fabric.with(this, new Crashlytics()) my app crashes.

I have done this and it seems to have fixed the problem:
import com.crashlytics.android.Crashlytics;
import io.fabric.sdk.android.Fabric;
public class MainActivity extends ActionBarActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  Fabric.with(this, new Crashlytics());
 // setContentView(R.layout.activity_main);
}

}


Release v1.5.0

Pull request for release v1.5.0.  Bug fixes and documentation only at this point.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls


[BUG] UnknownHostException when downloading Tesseract trained data using proxy

Version
<IP_ADDRESS>
What platform are you using?
Android
OS Version
GrapheneOS Android 13
What happened?
When trying to download the trained data for Tesseract from within the app, an "UnknownHostException" is thrown.
This happens when a global proxy is set via "settings put global http_proxy proxy.example.com:8080"
The address in the error message is my configured proxy hostname.
Relevant log output
03-17 14:51:44.732  1630  2686 D CoreBackPreview: Window{1bf2af0 u0 com.akylas.documentscanner/com.akylas.documentscanner.MainActivity}: Setting back callback null
03-17 14:51:44.737  1630  2686 W InputManager-JNI: Input channel object '1bf2af0 com.akylas.documentscanner/com.akylas.documentscanner.MainActivity (client)' was disposed without first being removed with the input manager!
03-17 14:51:44.753  1630  1773 V WindowManager: Unknown focus tokens, dropping reportFocusChanged
03-17 14:51:44.796 31016 31057 W Parcel  : Expecting binder but got null!
03-17 14:51:44.803  1630  3360 D CoreBackPreview: Window{deca04e u0 com.akylas.documentscanner/com.akylas.documentscanner.MainActivity}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@4c98a68, mPriority=0}
03-17 14:51:44.842  1630  3360 D CoreBackPreview: Window{deca04e u0 com.akylas.documentscanner/com.akylas.documentscanner.MainActivity}: Setting back callback null
03-17 14:51:44.844  1630  3360 W InputManager-JNI: Input channel object 'deca04e com.akylas.documentscanner/com.akylas.documentscanner.MainActivity (client)' was disposed without first being removed with the input manager!
03-17 14:51:44.876 31016 31057 W Parcel  : Expecting binder but got null!
03-17 14:51:44.880  1630  2686 D CoreBackPreview: Window{501f457 u0 com.akylas.documentscanner/com.akylas.documentscanner.MainActivity}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@ad35629, mPriority=0}

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@eht16 not sure what I can do about this. could this be an issue with your proxy being unable to contact github?
I dont do anything special with http request so I guess they should work with proxy.
can you access github using your global proxy from your browser?

The proxy server can contact Github just fine, it works via browser and any other app and it can be resolved via DNS.

Argh, I denied the network permission when installing it.
After allowing the app network access, it works perfectly.
Sorry for wasting your time :(.


Remember PVA recognizer

When coming from PVA and opening a topic in composer, initially we set the recognizer to PVA NLU.
When creating another dialog/trigger as part of the same bot/dialog, can we pre-set the recogizer to the PVA NLU again?

@mareekuh as designed, it will say "Default Recognizer" by default, not "PVA NLU". What was demo'd yesterday wasn't quite where we are ending up. Reach out to me if you have further questions

Ah i see - @cwhitten where do you expect we'll be ending up instead?


docs: update CONTRIBUTING.md to include how to run the make commands

Update CONTRIBUTING.md on how to build test and lint repo

Current dependencies on/for this PR:

10-18-feat_Add_cli_action_config

PR #41

PR #42

PR #44   👈
PR #43
PR #39

This comment was auto-generated by Graphite.


Support for Bookmarklets

By request (https://github.com/pfrazee/beaker/pull/92#issuecomment-246541404). This will need three updates:

Ability to add new bookmarks manually
A bookmarks bar under the url
Ability to add/remove bookmarks to the bar

Would these bookmarklets have access to the full web APIs?
Would it still depend on the location, http:// or dat:// ?

They'd execute within the current page's context, which means it would depend on the location. I'm a little torn about adding bookmarklets. We have plans for better forms of contextual actions.

I see. Even if you add a

better forms of contextual actions
bookmarklets are still out there. I have one to generate passwords, for instance. I think there could still be a use for them.

BTW, you've thanked me many times already for my issue comments, while I don't think I thanked you once yet for Beaker. Consider it done! :-)

Thanks :)

bookmarklets are still out there. I have one to generate passwords, for instance. I think there could still be a use for them.

The key problem with bookmarklets is, they're run as injections into the current page. Once we tighten up the Content-Security Policies in dat:// sites, that kind of injection will be blocked. HTTP/S sites may also block them with their own CSPs. So, I think we have to alter the model.
The key question is, do bookmarklets need direct access to the page to do useful work? If the answer can be "no," then we'll have a much easier time moving forward.

I'm really not up-to-date with CSPs, but I trust your judgement.
I'm going a bit off-topic, I hope you'll indulge me.
Another bookmarklet I sometimes use is the following (the details aren't important, only that it modifies the page):
(function() {
  var r, news = document.querySelectorAll(
      '.blended-wrapper.esc-wrapper'),
    langs = {
      en: 'ago',
      fr: 'il y a',
      'fr-CA': 'il y a',
      es: 'hace'
    };
  if ('undefined' === typeof ___jsl ||
    'undefined' === typeof ___jsl.cfg ||
    'undefined' === typeof ___jsl.cfg
    .lang || 'undefined' === typeof langs[
      ___jsl.cfg.lang]) {
    console.log("Langage inconnu.");
    return;
  }
  for (r = 0; r < news.length; r) {
    if (-1 === news[r].querySelector(
        '.al-attribution-timestamp').innerHTML
      .indexOf(langs[___jsl.cfg.lang])
    ) {
      news[r].style.display = 'none';
    }
  }
}());

I use it on Google News to filter out items older than a day. You're saying Google could update its CSP for that site which would prevent my bookmarklet from running, is that it? Of course, they could change anything in their source that could bust the bookmarklet, but that's a whole other matter.
It happens quite often I'll write a bookmarklet to modify a page - but this habit of mine could be taken away from me, in general?

I'm going a bit off-topic, I hope you'll indulge me.

Not at all, this is helpful

I use it on Google News to filter out items older than a day. You're saying Google could update its CSP for that site which would prevent my bookmarklet from running, is that it?

Correct -- and it's usually a positive that they do, because it protects against attacks by injection.

It happens quite often I'll write a bookmarklet to modify a page - but this habit of mine could be taken away from me, in general?

That's a possibility, yes.
People have raised the same concerns you have with FF and Chrome. It may be possible that CSPs can be circumvented to support bookmarklets. I dislike taking control away from users, so unless there's a strong security case against that, I'd be in favor of keeping bookmarklets.

Looking back at the big picture:
When it comes to page modification, the concept we're aiming for is "Fork to modify."
We're also going to implement 1) a subset of the WebExtensions API and 2) a revived form of WebIntents.
We're hoping these can cover enough use-cases that injection won't be necessary anymore.

Great, thanks for all the feedback and references.

The key problem with bookmarklets is, they're run as injections into the current page. Once we tighten up the Content-Security Policies in dat:// sites, that kind of injection will be blocked. HTTP/S sites may also block them with their own CSPs. So, I think we have to alter the model.

Please note that not all bookmarklets need to inject third party resources into the page, most do because that provides simple update mechanism, that is they publish update to the script that bookmarklet injects on their servers.
You could have bookmarklet that has all the logic inline & have more evolved  update mechanism that would talk to corresponding server and if update found prompt user in some way to suggest update.
So I'd still encourage to add support for bookmarklets.

I see this has been "added" to 1.0.0-prerelease.8
Does that mean bookmarklets will be enabled in that version (if nothing changes)?  (I don't see any PRs or related code, so I'm not sure what it means by "added" back on prerelease.6)

Is this still on the roadmap? Would be cool to be able to use http://hypothes.is in Beaker (even if just with HTTP/S websites)


Release 2.6.0 for Windows & MacOs

Add radios:

Times Radio
LBC Radio.

https://github.com/kkamara/kelvinkamara/releases


138 revise pageservice based on latest changes for siteservice and hostservice

[x] Update PageService
[x] Test PagesService

closes #138

@ParsaGachkar I just had a small code cleanup.
I merged with sprint-4 and it has exception.
I recommend rewriting PageService.

@pournasserian it's been rewritten. Please check the interface and let me know if I'm missing anything.
I think having a IsSiteAdmin property in our ApplicationContext would simplify our code


ImmutableDictionary regression in 2.7

Hello,
In 2.7, AutoBogus throws an exception when using AutoFaker.Generate<T>() with classes that expose an ImmutableDictionary<T,U> as a public property.  In 2.6, such classes used to be able to generate without having to skip these properties - they would just be null.
This also seems to happen with ReadOnlyDictionary<T,U>, which is a regression - in 2.6, a ReadOnlyDictionary would work and be faked correctly.
The regression can be worked-around by calling WithSkip in AutoFaker.Configure.
The below console app demonstrates the issue.  If you install the 2.6.0 AutoBogus package, it runs and produces the below output (the immutable dictionary is left as null).  If you update to 2.7.0 or beyond, it crashes with one of the exceptions below.  Skipping both the ReadOnlyDictionary and ImmutableDictionary works around the problem.
SomeStringProperty = JSON
SomeReadOnlyDictionary = System.Collections.ObjectModel.ReadOnlyDictionary`2[System.String,System.String]
SomeReadOnlyDictionary Count = 3
SomeImmutableDictionary =
SomeImmutableDictionary Count =

In 2.7.0 and after, it crashes with an exception.  Even if you skip the immutable dictionary property, it still crashes when trying to call Add.
Example of exception for converting to ReadOnlyDictionary<T,U>:
System.ArgumentException
  HResult=0x80070057
  Message=Object of type 'System.Collections.Generic.Dictionary`2[System.String,System.String]' cannot be converted to type 'System.Collections.ObjectModel.ReadOnlyDictionary`2[System.String,System.String]'.
  Source=System.Private.CoreLib
  StackTrace:
   at System.RuntimeType.TryChangeType(Object value, Binder binder, CultureInfo culture, Boolean needsSpecialCast)
   at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr)
   at System.Reflection.MethodBase.CheckArguments(Object[] parameters, Binder binder, BindingFlags invokeAttr, CultureInfo culture, Signature sig)
   at System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
   at AutoBogus.AutoMember.<>c__DisplayClass0_0.<.ctor>b__1(Object obj, Object value)
   at AutoBogus.AutoBinder.PopulateInstance[TType](Object instance, AutoGenerateContext context, IEnumerable`1 members)
   at AutoBogus.Generators.TypeGenerator`1.AutoBogus.IAutoGenerator.Generate(AutoGenerateContext context)
   at AutoBogus.AutoGenerateContextExtensions.Generate[TType](AutoGenerateContext context)
   at AutoBogus.AutoFaker.AutoBogus.IAutoFaker.Generate[TType](Action`1 configure)
   at AutoBogus.AutoFaker.Generate[TType](Action`1 configure)
   at AutoBogusImmutableIssue.Program.Main(String[] args) in C:\Users\SteveOgnibene\source\repos\AutoBogusImmutableIssue\AutoBogusImmutableIssue\Program.cs:line 21

Example of exception for converting to ImmutableDictionary<T,U>:
System.ArgumentException
  HResult=0x80070057
  Message=Object of type 'System.Collections.Generic.Dictionary`2[System.String,System.String]' cannot be converted to type 'System.Collections.Immutable.ImmutableDictionary`2[System.String,System.String]'.
  Source=System.Private.CoreLib
  StackTrace:
   at System.RuntimeType.TryChangeType(Object value, Binder binder, CultureInfo culture, Boolean needsSpecialCast)
   at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr)
   at System.Reflection.MethodBase.CheckArguments(Object[] parameters, Binder binder, BindingFlags invokeAttr, CultureInfo culture, Signature sig)
   at System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
   at AutoBogus.AutoMember.<>c__DisplayClass0_0.<.ctor>b__1(Object obj, Object value)
   at AutoBogus.AutoBinder.PopulateInstance[TType](Object instance, AutoGenerateContext context, IEnumerable`1 members)
   at AutoBogus.Generators.TypeGenerator`1.AutoBogus.IAutoGenerator.Generate(AutoGenerateContext context)
   at AutoBogus.AutoGenerateContextExtensions.Generate[TType](AutoGenerateContext context)
   at AutoBogus.AutoFaker.AutoBogus.IAutoFaker.Generate[TType](Action`1 configure)
   at AutoBogus.AutoFaker.Generate[TType](Action`1 configure)
   at AutoBogusImmutableIssue.Program.Main(String[] args) in C:\Users\SteveOgnibene\source\repos\AutoBogusImmutableIssue\AutoBogusImmutableIssue\Program.cs:line 11

Demo program:
using AutoBogus;
using System;
using System.Collections.Immutable;
using System.Collections.ObjectModel;

namespace AutoBogusImmutableIssue
{
    class Program
    {
        static void Main(string[] args)
        {
            //AutoFaker.Configure(builder =>
            //{
              //  builder
              //  .WithSkip<MyClass>(mc => mc.SomeImmutableDictionary)
              //  .WithSkip<MyClass>(mc => mc.SomeReadOnlyDictionary)
             //   ;
            //});

            var myInstance = AutoFaker.Generate<MyClass>();
            Console.WriteLine($"{nameof(MyClass.SomeStringProperty)} = {myInstance.SomeStringProperty}");
            Console.WriteLine($"{nameof(MyClass.SomeReadOnlyDictionary)} = {myInstance.SomeReadOnlyDictionary}");
            Console.WriteLine($"{nameof(MyClass.SomeReadOnlyDictionary)} Count = {myInstance.SomeReadOnlyDictionary?.Count}");
            Console.WriteLine($"{nameof(MyClass.SomeImmutableDictionary)} = {myInstance.SomeImmutableDictionary}");
            Console.WriteLine($"{nameof(MyClass.SomeImmutableDictionary)} Count = {myInstance.SomeImmutableDictionary?.Count}");

        }
    }

    public class MyClass
    {
        public string SomeStringProperty { get; set; }
        public ReadOnlyDictionary<string, string> SomeReadOnlyDictionary { get; set; }
        public ImmutableDictionary<string, string> SomeImmutableDictionary { get; set; }
    }
}

I'm willing to give it a shot to fix this if you can come up with a good idea.  I can try bisecting if you think that would be valuable.  Thanks for this great library.

Hi @nycdotnet
Thanks for the details above. I am surprised you are seeing an issue with ReadOnlyDictionary. That type should be handled, so I will need to investigate further.
With the ImmutableDictionary that could possibly be a special case that doesn't follow the supported collection interfaces. Again, I will need to investigate to see why.
Watch this space :smile:
Nick.

Hi @nickdodd79 - this is still an issue for us.  Did you like the behavior of how ReadOnlyDictionary was faked in 2.6?  If so, I can take a crack at restoring that and making it work with ImmutableDictionary and friends.

Hey @nycdotnet
Apologies for not getting a fix in place. There have been several events, commitments and deadlines I have had that have stolen my time. I have some spare time over the next few weeks, so I am hoping to resolve this for you.
Thanks for your patience.
Nick.

No worries at all.  I totally understand.  We have reverted back to 2.6 on all our projects for now, and it’s meeting our needs very well.  Thanks again for this great library.  Happy Holidays.

Just wanted to point out that this same regression exists with IReadOnlyDictionary<T,U> members as well. Hopefully, the fix is the same, if not very similar.

Hey @kevin-david
I have now got IReadOnlyDictionary<T,U> working again. Turns out some of my tests weren't executing which would have highlighted the issue. A new version will be available shortly.
Hey @nycdotnet
I can't get ImmutableDictionary to work as expected because the AutoBogus code runs on .NET Standard, but ImmutableDictionary seems to only be available in .NET Core.
https://docs.microsoft.com/en-us/dotnet/api/system.collections.immutable.immutabledictionary-2?view=netcore-2.0
I do have plans for a big refactor of AutoBogus (v3) to cater for this, which I am currently working on.
However, I did wonder how you managed to get it working in v2.6, so I checked out that version of the code to run some tests. Do your properties populate as expected, because when I run my test code, the ImmutableDictionary property is always null. As far as I can tell ImmutableDictionary instances need to be created using static factory methods on the class (which AutoBogus doesn't know about to create an instance).
Nick.

@nickdodd79 it works in 2.6 precisely because this version does not attempt to populate them.  We slap another abstraction on top of AutoBogus where we generate a bogus object and then add the immutable properties ourselves after.
You're correct about the immutable factories, but one of the refinements in recent versions is the extension methods in System.Collections.Immutable on the cousin mutable collections - so you can call .ToImmutableDictionary() on a Dictionary<T,U> and get the same effect as using the static builder at a minor performance cost but way simpler code, or .ToImmutableList(), .ToImmutableHashSet(), etc.
Thanks again for this great library and effort, and happy new year.

Just to say out loud, I was thinking about this problem the other day - and I was expecting this to actually be a problem.  To add to the issue, there are even multiple versions of the immutable libraries and they're continuing to refine them.  I was actually wondering if there might be some sort of way to use reflection to call this stuff without requiring a reference.  Given that immutable collections are CPU intensive already for steady-state ops, and that AutoBogus is probably mostly a library used for testing (though not specifically limited to that) I wonder if this might be a possible solution.

OK. In that case I think I have a quick fix for 2.7 where we can wrap the binding operations in the try..catch. That will prevent the error from occurring, but will mean the ImmutableDictionary property has a value of null.

@nickdodd79 that would be fine and would make the fixed 2.7 have the same behavior as 2.6 does for immutables.


0.1.4

Updates:

Prediction array type option (default=float32)
Feature propagation
Clustered subsumable partitioning
No memmaps passed to estimators (only ndarray views)
Threading as default global backend (changeable through mlens.config.BACKEND)
Global configuration (mlens.config)
Scoring exception handling

Coverage decreased (-1.09%) to 90.062% when pulling a493c6a50721c8c9886384553a7458cdd24a1c9a on 0.1.X into 00189fbff5d1b97465079cfdfb08cd5f26f29b3a on master.

Coverage increased (+0.3%) to 91.495% when pulling caae0781afc750e24542dd6123d087315e9c6f32 on 0.1.X into 00189fbff5d1b97465079cfdfb08cd5f26f29b3a on master.

Coverage increased (+0.3%) to 91.495% when pulling bd8d1ae949cd90a580325d33710cdfd87374e308 on 0.1.X into 00189fbff5d1b97465079cfdfb08cd5f26f29b3a on master.


IGV renames "chromosome_1" to "omosome_1"

It seems that IGV always removes "chr" from scaffolds titles. It makes sense when they are called, for example, "chr1". However, if a scaffold is called "chromosome_1", IGV will display its title as "omosome_1". Please, add an option to disable this automatic renaming.

Actually it doesn't do that, could you provide more information?  Where do you see "omosome_1"?
Also always state the version of IGV you are using when posting an issue.

I use the latest version, 2.13.5, downloaded from https://igv.org/app-archive/
I attached two screenshots. In the drop-down list and in the text box scaffolds are named properly.

I see, so the whole genome view.   That is not intentional, we will fix it for the next release.
I'm going to transfer this issue to igv.js as that is where the problem lies.


x/net/idna: backward compatibility issues with change 2

What version of Go are you using (go version)?
go version go1.7.3 darwin/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/weppos/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.7.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.7.3/libexec/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rk/llwxtd9s6jn91p2ky13tr30c0000gn/T/go-build024013537=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?
This issue is a follow up to #18567. The changes just committed in https://github.com/golang/net/commit/78ebe5c8b6a27ec13109c73c22193d618270e1e1 introduces again a compatibility error. I first discovered it thanks to the test failures in this PR: https://github.com/weppos/publicsuffix-go/pull/64
The issue is that a leading dot is stripped in the input. Here's a code to reproduce it:
package main

import (
	"fmt"
	"golang.org/x/net/idna"
)

func main() {
	var input, output string
	var err error
	input = ".example.com"
	output, err = idna.ToASCII(input)
	fmt.Println("in:\t", input)
	fmt.Println("out:\t", output)
	fmt.Println("err:\t", err)
	input = "..example.com"
	output, err = idna.ToASCII(input)
	fmt.Println("in:\t", input)
	fmt.Println("out:\t", output)
	fmt.Println("err:\t", err)
}

WIth previous version:
➜  gco f2499483f923065a842d38eb4c7f1927e6fc6e6d
➜  gotest go run idna.go
in:	 .example.com
out:	 .example.com
err:	 <nil>
in:	 ..example.com
out:	 ..example.com
err:	 <nil>

With latest version:
➜  gco HEAD
➜  gotest go run idna.go
in:	 .example.com
out:	 example.com
err:	 <nil>
in:	 ..example.com
out:	 example.com
err:	 <nil>

In order to restore the previous functionality, I had to apply a terrible workaround: https://github.com/weppos/publicsuffix-go/pull/66
I'd appreciate suggestions on how to handle this case in a better way, if this bugfix is not going to land in net/idna.
What did you expect to see?
I'd expect the following string conversion:
idna.ToASCII(".example.com") == ".example.com"
idna.ToASCII("..example.com") == "..example.com"

What did you see instead?
idna.ToASCII(".example.com") == "example.com"
idna.ToASCII("..example.com") == "example.com"

/cc @mpvl @nigeltao

This behavior was added to pass the test set for IDNA 2008 provided by the Unicode consortium. The same behavior is displayed here: http://www.unicode.org/cldr/utility/idna.jsp?a=..example.com.
It is also consistent with the behavior of Chrome.
However, one could argue that dots should not be removed and/or that having leading dots is an error. Safari has this behavior.
I suggest making an option for this which is enabled in the Lookup profile, but disabled everywhere else. This would make the Punycode profile (used by idna.ToASCII) compatibly with the old behavior.


Refactoring of checking Nullreferences, checking Disposed classes and correct Disposing of Resources

Throw an ArgumentNullException if parameter is null. This helps to stop execution early and not in native dependency.
Correct Disposing of Resources like Filestream
move checking of disposed class to helper method

Thanks!