Broken deployment of Azure Serverless function to Azure

Our github deployment workflow file stopped working today. Upon drilling down into the issue, it appears that this was updated to v1.5.1  ~ 35 minutes ago.
Downgrading to 1.5.0 appears to allow us to work without issue.
DOTNET_VERSION: '6.0.x'

.NET action
      - name: Setup DotNet ${{ env.DOTNET_VERSION }} Environment
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }}

Azure/functions-action workflow section
- name: 'Run Azure Functions Action'
        uses: Azure/functions-action@v1
        id: fa
        with:
          app-name: 'xxx-staging'
          slot-name: 'Production'
          package: '${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}/output'
          publish-profile: ${{ secrets.xxxx }}

Error from build log
Run Azure/functions-action@v1
  with:
    app-name: xxx-staging
    slot-name: Production
    package: ./output
    publish-profile: ***
    respect-pom-xml: false
    respect-funcignore: false
    scm-do-build-during-deployment: false
    enable-oryx-build: false
  env:
    AZURE_FUNCTIONAPP_PACKAGE_PATH: .
    DOTNET_VERSION: 6.0.x
    BRANCH_NAME: master
    DOTNET_ROOT: /home/runner/.dotnet
node:internal/modules/cjs/loader:1031
  throw err;
  ^

Error: Cannot find module './debug'
Require stack:
- /home/runner/work/_actions/Azure/functions-action/v1/node_modules/debug/src/node.js
- /home/runner/work/_actions/Azure/functions-action/v1/node_modules/debug/src/index.js
- /home/runner/work/_actions/Azure/functions-action/v1/node_modules/https-proxy-agent/dist/agent.js
- /home/runner/work/_actions/Azure/functions-action/v1/node_modules/https-proxy-agent/dist/index.js
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>- /home/runner/work/_actions/Azure/functions-action/v1/lib/publishers/websiteRunFromPackageDeploy.js
- /home/runner/work/_actions/Azure/functions-action/v1/lib/publishers/index.js
- /home/runner/work/_actions/Azure/functions-action/v1/lib/handlers/contentPublisher.js
- /home/runner/work/_actions/Azure/functions-action/v1/lib/main.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:10[2](https://github.com/OrderEaseInc/ClientIntegrationService/actions/runs/5894075314/job/15986941733#step:6:2)8:15)
    at Function.Module._load (node:internal/modules/cjs/loader:87[3](https://github.com/OrderEaseInc/ClientIntegrationService/actions/runs/5894075314/job/15986941733#step:6:3):27)
    at Module.require (node:internal/modules/cjs/loader:1100:19)
    at require (node:internal/modules/cjs/helpers:108:18)
    at Object.<anonymous> (/home/runner/work/_actions/Azure/functions-action/v1/node_modules/debug/src/node.js:1[4](https://github.com/OrderEaseInc/ClientIntegrationService/actions/runs/5894075314/job/15986941733#step:6:4):28)
    at Module._compile (node:internal/modules/cjs/loader:1198:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:12[5](https://github.com/OrderEaseInc/ClientIntegrationService/actions/runs/5894075314/job/15986941733#step:6:5)2:10)
    at Module.load (node:internal/modules/cjs/loader:107[6](https://github.com/OrderEaseInc/ClientIntegrationService/actions/runs/5894075314/job/15986941733#step:6:6):32)
    at Function.Module._load (node:internal/modules/cjs/loader:[9](https://github.com/OrderEaseInc/ClientIntegrationService/actions/runs/5894075314/job/15986941733#step:6:9)11:12)
    at Module.require (node:internal/modules/cjs/loader:1[10](https://github.com/OrderEaseInc/ClientIntegrationService/actions/runs/5894075314/job/15986941733#step:6:10)0:[19](https://github.com/OrderEaseInc/ClientIntegrationService/actions/runs/5894075314/job/15986941733#step:6:20)) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/home/runner/work/_actions/Azure/functions-action/v1/node_modules/debug/src/node.js',
    '/home/runner/work/_actions/Azure/functions-action/v1/node_modules/debug/src/index.js',
    '/home/runner/work/_actions/Azure/functions-action/v1/node_modules/https-proxy-agent/dist/agent.js',
    '/home/runner/work/_actions/Azure/functions-action/v1/node_modules/https-proxy-agent/dist/index.js',
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>    '/home/runner/work/_actions/Azure/functions-action/v1/lib/publishers/websiteRunFromPackageDeploy.js',
    '/home/runner/work/_actions/Azure/functions-action/v1/lib/publishers/index.js',
    '/home/runner/work/_actions/Azure/functions-action/v1/lib/handlers/contentPublisher.js',
    '/home/runner/work/_actions/Azure/functions-action/v1/lib/main.js'
  ]
}

Downgrading using
uses<EMAIL_ADDRESS>
appears to resolve the issue

Seeing similar issue:
Run Azure/functions-action@v1
  with:
    app-name: ****
    slot-name: ****
    package: *****
    publish-profile: ***
    respect-pom-xml: false
    respect-funcignore: false
    scm-do-build-during-deployment: false
    enable-oryx-build: false
  env:
    AZURE_FUNCTIONAPP_PACKAGE_PATH: ****
    DOTNET_VERSION: 7.0.x
    DOTNET_ROOT: C:\Users\runneradmin\AppData\Local\Microsoft\dotnet
node:internal/modules/cjs/loader:1031
  throw err;
  ^

Error: Cannot find module './debug'
Require stack:
- D:\a\_actions\Azure\functions-action\v1\node_modules\debug\src\node.js
- D:\a\_actions\Azure\functions-action\v1\node_modules\debug\src\index.js
- D:\a\_actions\Azure\functions-action\v1\node_modules\https-proxy-agent\dist\agent.js
- D:\a\_actions\Azure\functions-action\v1\node_modules\https-proxy-agent\dist\index.js
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>- D:\a\_actions\Azure\functions-action\v1\lib\publishers\websiteRunFromPackageDeploy.js
- D:\a\_actions\Azure\functions-action\v1\lib\publishers\index.js
- D:\a\_actions\Azure\functions-action\v1\lib\handlers\contentPublisher.js
- D:\a\_actions\Azure\functions-action\v1\lib\main.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1028:15)
    at Function.Module._load (node:internal/modules/cjs/loader:873:27)
    at Module.require (node:internal/modules/cjs/loader:1100:19)
    at require (node:internal/modules/cjs/helpers:108:[18](****))
    at Object.<anonymous> (D:\a\_actions\Azure\functions-action\v1\node_modules\debug\src\node.js:14:28)
    at Module._compile (node:internal/modules/cjs/loader:1[19](*****)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1[25](****)2:10)
    at Module.load (node:internal/modules/cjs/loader:1076:[32](****))
    at Function.Module._load (node:internal/modules/cjs/loader:911:12)
    at Module.require (node:internal/modules/cjs/loader:1100:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    'D:\\a\\_actions\\Azure\\functions-action\\v1\\node_modules\\debug\\src\\node.js',
    'D:\\a\\_actions\\Azure\\functions-action\\v1\\node_modules\\debug\\src\\index.js',
    'D:\\a\\_actions\\Azure\\functions-action\\v1\\node_modules\\https-proxy-agent\\dist\\agent.js',
    'D:\\a\\_actions\\Azure\\functions-action\\v1\\node_modules\\https-proxy-agent\\dist\\index.js',
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>    'D:\\a\\_actions\\Azure\\functions-action\\v1\\lib\\publishers\\websiteRunFromPackageDeploy.js',
    'D:\\a\\_actions\\Azure\\functions-action\\v1\\lib\\publishers\\index.js',
    'D:\\a\\_actions\\Azure\\functions-action\\v1\\lib\\handlers\\contentPublisher.js',
    'D:\\a\\_actions\\Azure\\functions-action\\v1\\lib\\main.js'
  ]
}

Same issue, this error has broken our deployment pipeline.
node:internal/modules/cjs/loader:1031
  throw err;
  ^

Error: Cannot find module './debug'
Require stack:
- /home/runner/work/_actions/azure/functions-action/v1/node_modules/debug/src/node.js
- /home/runner/work/_actions/azure/functions-action/v1/node_modules/debug/src/index.js
- /home/runner/work/_actions/azure/functions-action/v1/node_modules/https-proxy-agent/dist/agent.js
- /home/runner/work/_actions/azure/functions-action/v1/node_modules/https-proxy-agent/dist/index.js
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>- /home/runner/work/_actions/azure/functions-action/v1/lib/publishers/websiteRunFromPackageDeploy.js
- /home/runner/work/_actions/azure/functions-action/v1/lib/publishers/index.js
- /home/runner/work/_actions/azure/functions-action/v1/lib/handlers/contentPublisher.js
- /home/runner/work/_actions/azure/functions-action/v1/lib/main.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1028:15)
    at Function.Module._load (node:internal/modules/cjs/loader:873:[27](https://github.com/microsoft/provenance-bulk-signer/actions/runs/5894097705/job/15987147873#step:11:28))
    at Module.require (node:internal/modules/cjs/loader:1100:19)
    at require (node:internal/modules/cjs/helpers:108:18)
    at Object.<anonymous> (/home/runner/work/_actions/azure/functions-action/v1/node_modules/debug/src/node.js:14:[28](https://github.com/microsoft/provenance-bulk-signer/actions/runs/5894097705/job/15987147873#step:11:29))
    at Module._compile (node:internal/modules/cjs/loader:1198:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1252:10)
    at Module.load (node:internal/modules/cjs/loader:1076:[32](https://github.com/microsoft/provenance-bulk-signer/actions/runs/5894097705/job/15987147873#step:11:33))
    at Function.Module._load (node:internal/modules/cjs/loader:911:12)
    at Module.require (node:internal/modules/cjs/loader:1100:19) ***
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/home/runner/work/_actions/azure/functions-action/v1/node_modules/debug/src/node.js',
    '/home/runner/work/_actions/azure/functions-action/v1/node_modules/debug/src/index.js',
    '/home/runner/work/_actions/azure/functions-action/v1/node_modules/https-proxy-agent/dist/agent.js',
    '/home/runner/work/_actions/azure/functions-action/v1/node_modules/https-proxy-agent/dist/index.js',
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>    '/home/runner/work/_actions/azure/functions-action/v1/lib/publishers/websiteRunFromPackageDeploy.js',
    '/home/runner/work/_actions/azure/functions-action/v1/lib/publishers/index.js',
    '/home/runner/work/_actions/azure/functions-action/v1/lib/handlers/contentPublisher.js',
    '/home/runner/work/_actions/azure/functions-action/v1/lib/main.js'
  ]

Same (#196). I'll close as duplicate as more are here.

Sorry for inconvenience and thank you for reporting. I have reverted the v1 tag to 1.5.0 and actively investigating the issue with 1.5.1.

This issue is resolved. Thus, v1 tag is back to v1.5.1 latest release. I ran some extra tests but please confirm if it is fixed on you end as well. Thanks!

New error reverting to @v1
Successfully parsed SCM credential from publish-profile format.
Using SCM credential for authentication, GitHub Action will not perform resource validation.
(node:5896) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Error: Execution Exception (state: ValidateAzureResource) (step: Invocation)
Error:   Cannot read properties of undefined (reading 'AzureWebJobsStorage')
Error:     TypeError: Cannot read properties of undefined (reading 'AzureWebJobsStorage')
    at ResourceValidator.<anonymous> (D:\a\_actions\Azure\functions-action\v1\lib\handlers\resourceValidator.js:[17](https://github.com/OrderEaseInc/orderease.api/actions/runs/5895204885/job/15990449866#step:5:18)8:40)
    at Generator.next (<anonymous>)
    at fulfilled (D:\a\_actions\Azure\functions-action\v1\lib\handlers\resourceValidator.js:5:58)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
Error: Deployment Failed!

I have reverted the v1 tag to 1.5.0 and actively investigating the issue with 1.5.1.

Now we have the issue reported in #197. So this particular issue may be resolved, but deployment is still stopped (for us). Staying on v1.5.0 until #197 is resolved.

Bug fix released for v1.5.1. I'll wait for feedback on v1.5.1 before updating v1. Thanks.

I've switched our workflow file to use<EMAIL_ADDRESS>specifically, and it successfully runs without error now.


Console legacy functions have not been migrated to standard extension format

What is the future library direction for the SBI console functions (getchar/putchar)?  Will they remain as legacy functions?  Will a new extension be created for them?  Will they be deprecated?

Sounds like they're not coming back: https://lore.kernel.org/patchwork/cover/1119999/

The idea is to deprecate them in future because you can use earlycon devices in Linux.

SBI of course doesn't just cater to Linux but you'd have the same issue on basically any other operating system too: Sharing a UART or console device between the OS and the SBI provider could result in them interfering with each other. UEFI has a clear hand-off point to coordinate who in charge of managing I/O devices (the ExitBootServices function), but since SBI doesn't have anything equivalent it makes more sense to remove these functions entirely. Effectively, the hand-off takes place as soon as the OS starts

Actually, for the hypervisor I am porting, my plan was to continue to use the SBI as the interface to the system console, even after boot.  Similarly, guest operating systems could access the console, at least for logging, via the SBI, providing for a – very simple – multiplexing of the console.
Clearly, the SBI console itself does not actually have to be tied to a physical UART/RS-232 interface, but could be implemented via the debug interface (JTAG/trace – I haven’t looked at the RISC-V debug specification yet) or through some sort of Serial-over-LAN out-of-band management protocol.  The extreme simplicity of the console API makes this easy to do.
Obviously better APIs, such as VirtIO(?) can be envisioned for virtualized consoles.
From: Jonathan Behrens<EMAIL_ADDRESS>Sent: Wednesday, March 4, 2020 22:02
To: riscv/riscv-sbi-doc<EMAIL_ADDRESS>Cc: Schwarz, Konrad (CT RDA IOT SES-DE<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [riscv/riscv-sbi-doc] Console legacy functions have not been migrated to standard extension format (#34)
SBI of course doesn't just cater to Linux but you'd have the same issue on basically any other operating system too: Sharing a UART or console device between the OS and the SBI provider could result in them interfering with each other. UEFI has a clear hand-off point to coordinate who in charge of managing I/O devices (the ExitBootServices function), but since SBI doesn't have anything equivalent it makes more sense to remove these functions entirely. Effectively, the hand-off takes place as soon as the OS starts
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/riscv/riscv-sbi-doc/issues/34?email_source=notifications&email_token=AAGVI64DBSUJRSGDWAWQTUDRF26UVA5CNFSM4LBHUW4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN2IIVI#issuecomment-594838613, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAGVI65D63QGDC5TCNPZXG3RF26UVANCNFSM4LBHUW4A.

For Hypervisor, you can emulate UART8250 or SiFive UART for Guest or VM. We are already doing this for KVM RISC-V and Xvisor RISC-V.
From hypervisors perspective, we really don't need any SBI console calls.
Regards,
Anup

The SBI specification should be extended to note that the console functions are expected to be deprecated.

The SBI specification should be extended to note that the console functions are expected to be deprecated.

I agree. We need a short paragraph at the end of "Legacy SBI Extension, Extension IDs 0x00 through 0x0F". We should clearly state that we have SBI Extensions to replace almost all Legacy SBI functions except SBI console calls. The rationale for not supporting console functions as SBI Extension is to avoid duplicating early debugging features (such as earlycon of Linux) of modern OSes.
Can you send a PR to riscv-sbi-doc ?
Regards,
Anup

The issue is already addressed in the specification as per the latest suggestion. Closing this.

IMHO having at least console putchar functionality is a very nice to have feature in SBI. Is not useful only for bare-metal apps, but also it will help microkernels to stay micro. Otherwise they need to parse the FDT, find what is the /chosen/std-out node, parse that node, then check if it's compatible with the supported drivers.

IMHO having at least console putchar functionality is a very nice to have feature in SBI. Is not useful only for bare-metal apps, but also it will help microkernels to stay micro. Otherwise they need to parse the FDT, find what is the /chosen/std-out node, parse that node, then check if it's compatible with the supported drivers.


The request url "/api/cv" is outside of vite dev server root

Describe the bug
Calling endpoints within a svelte-kit project that has no file extension seems to fail.
This worked before upgrading to 2.3.0.
I am not 100% sure if this problem might be a svelte specific problem.
Reproduction
https://github.com/BetaConnector/vite_error/
The Problem seems to be calling an endpoint with file extension / without file extension:
https://github.com/BetaConnector/vite_error/blob/master/src/routes/index.svelte
System Info
Output of npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers:
  System:
    OS: Linux 5.11 Ubuntu 21.04 (Hirsute Hippo)
    CPU: (16) x64 Intel(R) Core(TM) i9-9900KS CPU @ 4.00GHz
    Memory: 286.56 MB / 15.54 GB
    Container: Yes
    Shell: 5.1.4 - /bin/bash
  Binaries:
    Node: 16.1.0 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.12.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 90.0.4430.212
    Chromium: 90.0.4430.212
    Firefox: 88.0.1

Used package manager: npm
Logs

21:35:32 [vite] Internal server error: The request url "/api/cv" is outside of vite dev server root "/home/alex/my-app".
      For security concerns, accessing files outside of workspace root is restricted since Vite v2.3.x.
      Refer to docs https://vitejs.dev/config/#server-fsserveroot for configurations and more details.
      at ensureServingAccess (/home/alex/my-app/node_modules/.pnpm/vite@2.3.0/node_modules/vite/dist/node/chunks/dep-c9ea388d.js:57841:15)
      at transformRequest (/home/alex/my-app/node_modules/.pnpm/vite@2.3.0/node_modules/vite/dist/node/chunks/dep-c9ea388d.js:57883:17)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
      at async viteTransformMiddleware (/home/alex/my-app/node_modules/.pnpm/vite@2.3.0/node_modules/vite/dist/node/chunks/dep-c9ea388d.js:58069:32)

Before submitting the issue, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the docs.
[x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[x] Provide a description in this issue that describes the bug.
[ ] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[x] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

fsServe.root would help
for example
server: {
    fsServe: {
      root:  '../../',
    },
  }

fsServe.root would help
for example
server: {
    fsServe: {
      root:  '../../',
    },
  }

I am pretty sure that I tried that without success. I will evaluete that again.

In vite 2.3.1 that check is disabled by default: https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md#231-2021-05-12

I got this point, but all files are within the projects src folder. And one file works and the other file is not. Seems little bit strange.


Bulk Script - body passed as string encoding

AMQP is returning a byte array, and the bulk script is converting that to a string. The issue is that the default string encoding ruin's binary data - ie compressed streams.
The script interface should just deal with byte arrays (both as the return type and body parameter), as that is what AMQP is returning, this will let the script do what it wants with the raw data, rather then converting it posibally incorrectly before calling the script.

This project is not maintained anymore.


Some warnings when building greptimedb

What type of bug is this?
Other
What subsystems are affected?
Other
What happened?
There are some warnings when building greptimedb:
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /Users/dennis/programming/rust/greptimedb/src/common/mem-prof/Cargo.toml
workspace: /Users/dennis/programming/rust/greptimedb/Cargo.toml
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /Users/dennis/programming/rust/greptimedb/src/common/mem-prof/Cargo.toml
workspace: /Users/dennis/programming/rust/greptimedb/Cargo.toml
...
...
warning: the following packages contain code that will be rejected by a future version of Rust: lalrpop v0.19.8
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`

Looks like most of them are dependencies issues. Create this issue to track it.
What operating system did you use?
Mac OSX1 M1
Relevant log output and stack trace
No response
How can we reproduce the bug?
cargo build or cargo test

warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /Users/dennis/programming/rust/greptimedb/src/common/mem-prof/Cargo.toml
workspace: /Users/dennis/programming/rust/greptimedb/Cargo.toml

@v0y4g3r Caused by #1124


Update README.md

Description
Updated Readme to be up to date with S1 2023 working team
Related to #1
Changes include

[x] Bugfix (non-breaking change that solves an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)

Checklist

[x] I have assigned this PR to myself
[x] I have added at least 1 reviewer
[x] I have added the needed labels
[x] I have linked this PR to an issue
[x] I have linked this PR to a milestone
[x] I have linked this PR to a project
[x] I have updated the README and other relevant documents (guides...)

Just make sure to use conventional commits next time @YlanGarnier :wink:


Investigate better support for long multiday interims using meetecho

Alan and I would like to request a multi-day in-person meeting for MoQ, to be held at Meta's Seattle office from 9:00 to 6:00 on January 31st and February 1st.  Alan first attempted this and ran into a tool snag that the tool limited a single meeting to 5 hours (and threw an error if you chose exactly 5).  I then tried breaking each day into two session (see attached); this throws an error claiming that the days requested must be consecutive.  They are, but apparently it disallows two sessions on a single day.
Can we ask that the secretariat manually schedule the meeting as soon as possible, so that folks can schedule their travel?
Can we ask that the tools team look at the error and allow in-person meetings to go beyond 5 hours and/or have multiple sessions per day?
thanks,
Ted and Alan

cc @alexamirante @avezza @hardie

I just checked and the API the Datatracker uses to create Meetecho sessions doesn't pose any limit on the duration of a meeting. I think the limitation is in the Datatracker interim creation form.

I just checked and the API the Datatracker uses to create Meetecho sessions doesn't pose any limit on the duration of a meeting. I think the limitation is in the Datatracker interim creation form.

Thanks - will verify and adjust.


Add this to libphonenumber package

A PR to add this directly inside the libphonenumber package would be nice

This actually nice a idea. I'll see what I can do...

@natintosh, I'm writing a dart version of lib phone number. It's not a one to one mapping as currently it deals with only mobile numbers but you might be interested in it. I might make it work with all numbers eventually if needed.
I'll keep you updated


NC_CLASSIC_MODEL and nc_enddef

When using flag NC_CLASSIC_MODEL to create an HDF5-based file,
is calling nc_enddef() required before the first put/get var call?
In the NetCDF-C document, nc_enddef has the following statement, which implies it is not required.
It's not necessary to call nc_enddef() for netCDF-4 files.

Yes it is necessary when NC_CLASSIC_MODEL is used.
It is not necessary for netCDF-4 files which were created without NC_CLASSIC_MODEL.

I am interested in learning the reason of why it is required. Could you please explain?
Also, look like the nc_enddef document can use a clarification.


Write once variables

Description
As far as I understand, regular global variables cannot be set from functions, because this would
allow for some kind of race conditions and ordering problems. But frequently Users do only set a value once inside a document. A state with update and display logic seem fairly heavy for this use case. So I thought about allowing to set those variables exactly once, as long as they are none. A second attempt would throw an error.
What do you think of that?
Use Case
You have to set some globally available state at document begin (maybe inside the template), but don't want to use the display-function everytime you use it.

You could just check for none - but in the use case of global settings they should be set at start and used later, so "safe by design" ;-)

That still requires evaluation to proceed in a certain order. I think most things currently done with state should switch to set rules once custom elements are available. Retrieving values from a set rule still requires context and is thus not completely freely scriptable, but it's much cleaner than states.

I have done a few experiments in a local checkout. As the captured variables are copied to the local scope, it's not trivial to implement it. Also the main problem for me was, that using a state and updating that state does create pagebreak (weak) where it shouldn't. So if #1346 will be solved, I could easily switch to states.
As for now, states seem cleaner to me; but if you like, please give an example, how you would use the custom elements as replacement for states.

Oh yes, and see #1928


Feat/text native props

Description
Having encountered some problems in production I was motivated to add textStyle only textProps so that we could add documented props for the native Text component, e.g. disabling text scaling and other described properties.
Feature : added textProps for apply some property to native component
What type of PR is this? (check all applicable)

[x] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 🔥 Breaking change
[ ] 💣 Package Update
[ ] 📝 Documentation Update
[x] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[x] ✅ Test
[x] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert
[ ] 🏰 Code style update (formatting, local variables)

How Has This Been Tested?

Screenshots/Recordings (if appropriate):
Related Tickets & Documents

Additional note for QA team:

Added tests?

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

Checklist:

[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] My changes don't decrease Code Coverage percentage

@HMDarkFir3 Hi, cannot assing you to pr , but can ping you.

@BLOCKMATERIAL thanks for the contribution, I approved your PR


Redacting "responseTime" leads to invalid JSON

In the configuration options below, responseTime is a redacted path:
          "redact": {
            "paths": [
                "pid",
                "hostname",
                "app",
                "responseTime",
                "req.id",
                "req.method",
                "req.headers",
                "req.remoteAddress",
                "req.remotePort",
                "res"
            ],
            "remove": true
          }

This results in a log that contains invalid JSON (see undefined):
{"level":30,"time":1576099135935,"req":{"url":"http://localhost:8080/todos?completed=true"},"req":{"url":"http://localhost:8080/todos?completed=true"},"responseTime":undefined,"msg":"request completed","v":1}

I recognize that this is probably a pino issue, but it's only occurring for me when redacting responseTime, a value calculated in hapi-pino.
I believe the issue has to do with the stringifier in pino here.

There might be some bugs! Would you like to upload an example that reproduce the problem? Also, sending a PR would be handy.
I think this might be a bug in https://www.npmjs.com/package/fast-redact.
cc @davidmarkclements

I wouldn't expect any software to be completely free of bugs 😁
Here's a repo here that reproduces the problem: https://github.com/tuckbick/test-hapi-pino
This could also be a problem in pino-pretty, as this only occurs while piping stdout through pino-pretty instead of using the prettyPrint option.

I’m failing to understand how using prettyPrint internally can avoid this. Anyway, it seems you have identified where there is a bug.. would you like to send a PR to pino to fix?

Yep, sure thing. I'll try to get PR together this week!

Haven't gotten to a PR yet -- not quite sure where to put a fix yet. However, I've done some investigation:

When pinoPretty: true, pino does some programmatic redaction here, stringifying the object, thus removing undefined properties.
Otherwise, when pinoPretty: false, the object is logged to stdout containing the undefined properties.

You need to add another if in https://github.com/pinojs/pino/blob/master/lib/tools.js#L107 to handle the case that value could be undefined and in that case not include the key as well.

Thanks for the direction! Please see the submitted PR.

Merged in https://github.com/pinojs/pino/pull/756


loading included nms onnx model on Triton

while loading model on triton error is coming
UNAVAILABLE: Internal: onnx runtime error 1: Load model from /models/yolov8_onnx/1/model.onnx failed:Fatal error: TRT:EfficientNMS_TRT(-1) is not a registered function/op |
how to use EfficientNMS_TRT  plugin while loading model in TRITON

This is a tensorrt base repo.
So the plugin named 'EfficientNMS_TRT' is only for tensorrt and not for onnxruntime.

how can we use plugin while loading model on Triton


Create a ML model to split the text in sentences.

User story:

As a developer, I want to have an easy to use method to parse a large/long string into an array of sentences (if possible)

Acceptance criteria:

Method should take an input string and return an array of sentences
Method should work on both questions, exclamation and regular sentences
Method should be easy to use

Initial Time Estimates:

Planning (issue writeup, initial rough time estimations): 30 min
Research (NLTK, Python syntax and OOP, import/download requirements): 1 hour
Implementation and Testing: 2 hours
Documentation (writeup code explanation and how-to for unfamiliar user): 1 hour
Deployment (PR Write-up): 1 hour
Extra features (split words, identify questions, etc): 5 - 10 hours


Update nodejs-nuxtjs stack

What does this PR do?:
Updates nodejs-nuxtjs stack:

Add new version: 1.2.1
Set schemaVersion: 2.2.2
Set https protocol for the endpoint
Set 1.2.1 version as a default one

Which issue(s) this PR fixes:
https://github.com/eclipse/che/issues/22869
PR acceptance criteria:

[ ] Contributing guide
Have you read the devfile registry contributing guide and followed its instructions?
[ ] Test automation
Does this repository's tests pass with your changes?
[ ] Documentation
Does any documentation need to be updated with your changes?
[ ] Check Tools Provider
Have you tested the changes with existing tools, i.e. Odo, Che, Console? (See devfile registry contributing guide on how to test changes)

How to test changes / Special notes to the reviewer:
You can use the following link to start a workspace for testing:
https://workspaces.openshift.com/#https://raw.githubusercontent.com/RomanNikitenko/registry/update-nuxtjs/stacks/nodejs-nuxtjs/1.2.1/devfile.yaml
Signed-off-by: Roman Nikitenko<EMAIL_ADDRESS>rh-pre-commit.version: 2.2.0
rh-pre-commit.check-secrets: ENABLED

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error:  error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0
So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.
See: https://github.com/devfile/registry/blob/72a45de9a3a01834ecbfa4e920926a041622ade6/tests/validate_devfile_schemas/go.mod#L6
https://github.com/devfile/registry/blob/72a45de9a3a01834ecbfa4e920926a041622ade6/tests/odov3/go.mod#L7
https://github.com/devfile/library/commit/44ca18d63cf41ff4d5f8a64c87453f905d2598e5
cc @michael-valdron @thepetk

I believe this open issue would cover the changes required to unblock these ci checks? @michael-valdron
https://github.com/devfile/api/issues/1479

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error:  error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0
So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.
See:
https://github.com/devfile/registry/blob/72a45de9a3a01834ecbfa4e920926a041622ade6/tests/validate_devfile_schemas/go.mod#L6
https://github.com/devfile/registry/blob/72a45de9a3a01834ecbfa4e920926a041622ade6/tests/odov3/go.mod#L7
devfile/library@44ca18d
cc @michael-valdron @thepetk

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

We can do this to unblock this PR and update to v2.2.2 release itself once @Jdubrick has completed devfile/api#1477 to resolve https://github.com/devfile/api/issues/1479.

/retest

@Jdubrick we'll need to rebase to your changes
FYI @RomanNikitenko

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error:  error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0
So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.
See:
https://github.com/devfile/registry/blob/72a45de9a3a01834ecbfa4e920926a041622ade6/tests/validate_devfile_schemas/go.mod#L6
https://github.com/devfile/registry/blob/72a45de9a3a01834ecbfa4e920926a041622ade6/tests/odov3/go.mod#L7
devfile/library@44ca18d
cc @michael-valdron @thepetk

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

Digged a little bit further for this issue and opened https://github.com/devfile/api/issues/1494. We should also update the version of library used by odo in order to be able to support v2.2.1 and v2.2.2 in our PR checks

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error:  error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0
So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.
See:
https://github.com/devfile/registry/blob/72a45de9a3a01834ecbfa4e920926a041622ade6/tests/validate_devfile_schemas/go.mod#L6
https://github.com/devfile/registry/blob/72a45de9a3a01834ecbfa4e920926a041622ade6/tests/odov3/go.mod#L7
devfile/library@44ca18d
cc @michael-valdron @thepetk

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

Digged a little bit further for this issue and opened devfile/api#1494. We should also update the version of library used by odo in order to be able to support v2.2.1 and v2.2.2 in our PR checks
Another question is if we would like to remove the 1.2.0 version completely (dir and stack.yaml record) like we did for #342
cc @michael-valdron @Jdubrick

I've merged the temporary fix and now the check should be passing

Might need a rebase @RomanNikitenko :(

Another question is if we would like to remove the 1.2.0 version completely (dir and stack.yaml record) like we did for https://github.com/devfile/registry/pull/342

https://github.com/devfile/registry/pull/347#issuecomment-2035372734

/retest

Please let me know if any changes are required on my part to merge


members as markdown files - initial member; noon

see: https://github.com/FixPlanet/FixPlanet.github.io/issues/15
i'm going to put markdown files here, and read them from the website.

I added myself with a new commit, feel free to edit the content


Update Dave Briccetti’s “Stupid Nonsense Spoken Sentences”

Sorry for the trouble, but I’ve updated the YouTube video, which requires a change to the link. Thanks!

No problems!


x86/sse: Fix type convert error for LSX.

When compile webkitgtk-2.45.92, failed with following error:
webkitgtk-2.45.92/Source/WTF/wtf/simde/arm/neon.h:92893:38: 错误：cannot convert ‘_m128’ to ‘v2i64’ in assignment
92893 |         r.lsx_i64 = _lsx_vfrintrm_s(a.lsx_f32);
|                      ~~~~~~^~
|                                      |
|                                      __m128

Thank you for the report and the fix, @yinshiyou
What is your compiler and its version?

I use  gcc14 on loongson platform.
The previous code was developed base on the internal old version gcc of loongson which has defined inappropriate return types for some LSX builtin API.
GCC14  has merged LoongArch support, and it's return types of some LSX builtin API  is correct .

I use upstream gcc14 on loongson platform. The previous code was developed base on the internal old version gcc of loongson which has defined inappropriate return types for some LSX builtin API. The new version has fiexed it. Upstream gcc14 has merged LoongArch support, and it's return types of those LSX builtin API are correct .

Thanks, can you give me the output of --version for your gcc14?
Can you suggest updates to https://github.com/simd-everywhere/simde/blob/9aeb89ebea0d3a2b0bc6cec9d38114702766ba52/.github/workflows/ci.yml#L866 so we can use this newer compiler to confirm your fixes?

@yinshiyou Thanks!
I'm testing some CI updates over at https://github.com/simd-everywhere/simde/pull/1217

@yinshiyou Thanks!
I'm testing some CI updates over at #1217

OK, Let's do it in #1217

Thank you for updating the CI for loongson.


Issue removing finalizers when namespace containing operator and CR is deleted

Bug Report
What did you do?
I have created a repo with a simple operator that reproduces the bug:
https://github.com/philbrookes/finalizer-operator
The gist of the bug is:

Create an operator and a custom resource in a namespace
Have the operator add a finalizer to the custom resource
Delete the namespace
Operator is deleted before it can remove the finalizer from the custom resource

What did you expect to see?
The operator given the opportunity to remove it's finalizers and clean up, before being deleted.
What did you see instead? Under which circumstances?
The operator was deleted before removing it's finalizers
Environment

operator-sdk version: 0.0.6

Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:53:20Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.0+b81c8f8", GitCommit:"b81c8f8", GitTreeState:"clean", BuildDate:"2018-11-15T14:18:49Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes cluster kind:
go

@philbrookes Yeah that's a common problem with all operators/controllers. If your operator isn't around, it can't be expected to cleanup and remove finalizers.
Can you explain the use case where you would want to delete the namespace before deleting the CRs. I know it's an easy way to cleanup everything.
@chancez I might be wrong but I seem to recall you brought up this issue once before. Any idea if we can prevent the operator from being deleted by the namespace?
One possibility might be to have a pre stop hook to remove all finalizers.

You could add a finalizer to the operator pod itself potentially. Generally speaking though, an operator could depend on resources in the cluster to clear finalizers, so it may still get stuck itself. Generally I've learned that operators are special and probably need to live in a location separate from the resources they manage (eg operator runs in one namespace, but watches a different namespace, or all namespaces). Otherwise it just gets really complicated to prevent you, and anything you depend on (which you may not own) from being deleted as an operator.

Also, a pre stop hook would be delivered when the container receives any termination event, including in scaling.

I'm not sure that moving the operator into it's own namespace solves the overall problem (though it does solve my specific example); if the operator namespace is deleted before the resources namespace, the resources namespace would still be unable to cleanly terminate.
So I wonder if the solution for now, is to put a finalizer on the deployment for the operator and move the operator into it's own namespace, then when the pre-stop hook is called, check if the deployment has a deletion timestamp, and if so, remove the finalizer from the deployment as well as from any other resource the operator has ever added the finalizer to?
If so, then if the operator was redeployed after this, it would need to re-add the finalizer to any object it interacts with, that is missing the finalizer it should have?

That sounds about right.


Improve split check

In a TPCC benchmark we observed that split check becomes the bottleneck.

Any details? Did it cause too much resources? Or was it too slow? Or was it inaccurate?


Feature Request: cache.all method

I think it would be nice to fetch the whole cache object.
const fcache = require('flat-cache')

const birthdays = fcache.load('birthdays')

birthdays.set('Alice', '01/01/98')
birthdays.set('Bob', '02/02/97')

birthdays.all() // returns { 'Alice': '01/01/98', 'Bob': '02/02/97' }

Hi @OzairP,
I don't think of a reason to no add this one, I will try to find some time to add a method to return the cache object, but if you're interested into adding it, PRs are welcome!
Kind regards

Awesome, can you push the newest changes to NPM whenever possible? Thanks!

Thanks @OzairP. Published v1.3.0


Gulp.src doesn't seem to work on windows shares

On windows I have a gulpfile like this:
var gulp = require('gulp');
var size = require('gulp-size');
var fs = require('fs');

var loc = '//some/shared/file.txt';

console.log(fs.existsSync(loc));

gulp.task('default', function(){
  gulp.src(loc)
    .pipe(size({showFiles: true}))
});

If I run this, I get size is 0, while the file does exist. The console.log outputs true, so node detects the file correctly, but gulp doesn't. If I change the path to something on the c drive, everything works as expected.

Shortcut to node-glob PR -> https://github.com/isaacs/node-glob/pull/146

Followed some references and found a possible workaround at https://github.com/sindresorhus/del/issues/35#issuecomment-184736366
It doesn't look like node-glob cares about this issue at all, so hopefully anyone running into this is able to use that workaround.  We pass all extra options to node-glob, I believe.


New Feature: checking for event.defaultPrevented for custom events

As discussed in #165  we added the ability to stop execution for most components when using event.preventDefault() for the custom events.
Main focus:

first the feature is added to V3, if all goes well, the exact same will be added to V4 as well
I don't see the point of using event.preventDefault() on events like shown.bs.modal or slid.bs.carousel, the functionality could break in some cases, while in other cases like affixed-top.bs.affix event makes no sense
we're looking into ways to improve code
additional suggestions/PR should come with strong arguments

Please test latest master, lemme know what you think.

@edufransoni how we doin?

@edufranzoni how we doin?

Hello @thednp , looks nice.
i will try to test today.
i appreciate it

Right from my demo:
var myModal = document.getElementById('myModal');
myModal.addEventListener('show.bs.modal', function(e) {
        e.preventDefault(); // this works for me just right, the modal is not shown
	e.target && console.log('show.bs.modal triggered for #'+e.target.id);
	e.relatedTarget && console.log('event.relatedTarget is '+e.relatedTarget.tagName+'.'+e.relatedTarget.className.replace(/\s/g,'.'));
}, false);

@thednp It worked now, thank you very much.
Can this also be implemented in bootstrap-native-v4 please?
Thank you very much

It will come as soon as we have more confirmations on good functionality for the current build.

@edufranzoni please check latest master, I've added the changes to V4.
Would love to have a full review as soon as you please.

@edufranzoni please check latest master, found some time and I've added the changes to V4.
Would love to have a full review as soon as you please.

@thednp Working perfectly, I didn't detect problems with other components either.
Thank you so much for your attention and agility in helping the community.

No problem man, some things just make a lot of sense. I mean why have events that won't allow you to control.


NIfTI C library is outdated with broken byte swapping within newer GCC

The NIfTI-1 C library source code included with the IRTK is outdated. I ran in particular into an issue that the byte swapping was not working when the library is compiled with optimization using GCC >=4.7. It turns out these problems have been fixed in the most recent 2.0 release version (this particular problem was possibly fixed in v1.1 from 2008 already).
https://gcc.gnu.org/ml/gcc-help/2015-04/msg00005.html

Hi @schuhschuh , do you know if this issue is fixed in IRTK 2.0?
When trying out the new IRTK 2.0 through Python, I got:
img = irtk.imread("brain.nii")
irtkFileNIFTIToImage: Data type 1 not supported, trying signed short data type

and this messed up image header:
{   'dim': array([256, 256, 192,   1], dtype=int32),
    'orientation': array([[ inf,  nan,  nan],
                          [ -1.,   0.,   0.],
                          [  0.,  -1.,   0.]]),
    'origin': array([ 0., -1.,  1.,  1.]),
    'pixelSize': array([ 0.,  1.,  1.,  1.])  }

CMake says my system is little endian (Mac OSX if that's related), if I force the big endian flag, I get:
Modules/Image/src/irtkFileNIFTIToImage.cc:197:29: error: use of undeclared
      identifier 'MSB_FIRST'
  if (hdr.nim->byteorder == MSB_FIRST) {
                            ^
1 error generated.

Bu if I remove the lines https://github.com/BioMedIA/IRTK/blob/master/Modules/Image/src/irtkFileNIFTIToImage.cc#L192 :
#ifndef WORDS_BIGENDIAN
  if (hdr.nim->byteorder == 1) { //LSB_FIRST) {
    this->_Swapped = !this->_Swapped;
  }
#else
  if (hdr.nim->byteorder == MSB_FIRST) {
    this->_Swapped = !this->_Swapped;
  }
#endif

Then I get the correct header.
{   'dim': array([256, 256, 192,   1], dtype=int32),
    'orientation': array([[-1.,  0.,  0.],
                          [ 0., -1.,  0.],
                          [ 0.,  0.,  1.]]),
    'origin': array([-127.5, -127.5,   95.5,    0. ]),
    'pixelSize': array([ 1.,  1.,  1.,  1.])  }

Now that IRTK 2.0 uses NiftiClib instead of shipping its own version of nifti reading code, I do not know if it still corresponds to the bug you reported but I'm curious to hear from your experience.

Hi @kevin-keraudren, regarding the issue I reported here, it will not affect you with the new IRTK when on your system is a recent enough NiftiCLib installed (at least v1.1, better 2.0).
Regarding the byte swapping issue within the IRTK code itself, I have had no issue so far with my private IRTK copy (no particular CMake refactoring). I suggest you report this issue and your findings in the issue tracker of the new IRTK so @ghisvail can have a closer look.
Given that in the code you remove to "fix" the issue the _Swapped flag is simply inverted (which must be the case, otherwise removing the code wouldn't do anything), it might as well be that this flag is now incorrectly initialised in irtkCifstream.cc.
The other issue you report seems that MSB_FIRST is not defined. A look at nifti1_io.h reveals that this header defines this macro for internal use only by the corresponding nifti1_io.cc. It may well be that we have to define it ourselves in irtkNIFTI.h, e.g., as IRTK_MSB_FIRST and IRTK_LSB_FIRST. You can also note that in the #ifndef branch, LSB_FIRST is not used, but instead expanded already. Probably for the same reason.

P.S.: I think the IRTK so far actually never defined WORDS_BIGENDIAN... so the added endianness check might be the reason for your issue.

I am having trouble reading NIFTII files with this IRTK and I get an error like this:
irtkFileNIFTIToImage: Data type<PHONE_NUMBER> not supported, trying signed short data type
It seemed to me that it might related to this issue. The header is not read correctly resulting in not finding the correct data type for the image.
I included the NifTI 2.0 library but that did not fix.  I am running on MacOS Sierra with GCC version 4.2.1. Any pointers on how this issue could be fixed?

IRTK is deprecated in favour of MIRTK, which should include a more robust handling of NifTI I/O.

The only problem is that I have a lot of legacy code written that depends on IRTK.

Do you known on which platform your NifTI files have been generated from? Also can you successfully load them on papaya?
This would tell us whether they are well formed, and which endianness they are potentially in.

These were mostly generated under Windows 7. They successfully work when loaded on papaya.
It is happening to pretty much every NifTI file I am trying to load with IRTK.

These were mostly generated under Windows 7.

So, big endian.

They successfully work when loaded on papaya.

Confirming the files are well-formed.

It is happening to pretty much every NifTI file I am trying to load with IRTK.

Could you try running IRTK's info executable on this file and paste the results or the error raised.
FYI, I am looking for something obvious to fix. If the problem lies deeper in the code, then I will most likely not investigate further as IRTK is no longer actively maintained. Most of our software has been ported to MIRTK, which we actively maintain and support.

@drkarim If you send a list of IRTK binaries that you are using, I can compile a brief overview of corresponding MIRTK commands or we'll see if one you need is missing. In case you mostly need nreg, you'd save lots of time waiting for results switching to MIRTK. From a comparison I've done based on OASIS / Neuromorphometrics labels, nreg runs on average in 403 min whereas MIRTK run on average in only 3.6 min with 8 cores, achieving the same if not higher Dice overlap.
As I see you're at King's, @ericspod has recently updated Eidolon to use MIRTK.

@ghisvail The info command manages to read the header, but it is not quite correct (black window). The correct header is shown by running info from my working IRTK installation (purple window). It seems that the bytes are not read properly?

I suspect @drkarim is using IRTK as a library. Could you confirm @drkarim ? If that's the case, then porting the code to MIRTK might be a bit more involved. If you are just using the IRTK executables, please consider @schuhschuh's suggestion to port your process calls over to MIRTK
Regardless, if this were a global endianness issue, the output of info would affect all fields which are larger than a byte in memory, i.e. pretty much all of them. Here only the voxel type is incorrect, and then wrongly assigned to short as a result of the failure.

Never mind, I saw Andreas kick-started the portage.


WaitForEdge generated unexpected results

Describe the bug
WaitForEdge generated unexpected results，Problems arise when using edge detection for ultrasonic ranging，When the sensor is stationary, the calculated values deviate significantly
To Reproduce
Steps to reproduce the behavior:

Run program

package main

import (
	"fmt"
	"log"
	"periph.io/x/conn/v3/gpio"
	"periph.io/x/conn/v3/gpio/gpioreg"
	"periph.io/x/host/v3"
	"time"
)

var (
	trig gpio.PinIO
	echo gpio.PinIO
)

func Test() {
	if _, err := host.Init(); err != nil {
		log.Fatal(err)
	}

	trig = gpioreg.ByName("23")
	echo = gpioreg.ByName("24")
	trig.Out(gpio.Low)
	echo.In(gpio.PullDown, gpio.BothEdges)

	for {
		test(trig, echo)
		time.Sleep(time.Millisecond* 10)
	}
}

func test(trig gpio.PinIO, echo gpio.PinIO) {
	trig.Out(gpio.Low)
	time.Sleep(time.Microsecond * 2)
	trig.Out(gpio.High)
	time.Sleep(time.Microsecond * 10)
	trig.Out(gpio.Low)

	// Low -> High
	echo.WaitForEdge(time.Second)

	ts := time.Now()
	// High -> Low
	echo.WaitForEdge(time.Second)
	cost := time.Since(ts)
	dis := float32(cost.Nanoseconds()) * 0.000000343 / 2.0 * 100
	fmt.Printf("distance: %vcm\n", dis)
}

Run it.
See error

Expected behavior
The expected result is 180+-cm, but the actual value will be 180+-cm at one time and 8+-cm at another time, and the two will alternate repeatedly. （180+- is the current true value）
Platform (please complete the following information):

OS: Raspbian bookworm
Board Raspberry Pi 4

Additional context
I have used polling to verify and can get the expected results

The problem with WaitForEdge() is that the implementation in https://github.com/periph/host/blob/main/sysfs/gpio.go is dependent on sysfs which is sensitive to timing issues from linux.

So for my problem, I can only use polling instead of WaitForEdge, right? Or is there any way to avoid this timing-sensitive problem?

The problem with WaitForEdge() is that the implementation in https://github.com/periph/host/blob/main/sysfs/gpio.go is dependent on sysfs which is sensitive to timing issues from linux.

The problem with WaitForEdge() is that the implementation in https://github.com/periph/host/blob/main/sysfs/gpio.go is dependent on sysfs which is sensitive to timing issues from linux.

So for my problem, I can only use polling instead of WaitForEdge, right? Or is there any way to avoid this timing-sensitive problem?

@zombie-k A new implementation of GPIO has been created that uses ioctl() interface, and not sysfs. You might try re-testing your code with the HEAD of periph.io/x/host.
You can clone the repo, and in your go.mod file put:
replace periph.io/x/host/v3 v3.8.2 => path to cloned repo
and rebuild it. Note that you'll need to remove any references to sysfs from your code.

Simpler, you can do the following:
go get periph.io/x/host/v3@7540d26b4dc114207d0e5f7603b0f176bf5805dd

No need for a replace statement or checking out locally.


Importing JSON files Offline Do Not Get the Default Values of The Properties

In the existent version of SLSC EDS, we use JKI JSON parser, which work very well for a lot of applications but it can't obtain the "Default" values for the properties. So, all the channels created by the too will have "0" in it and you would need to go and change those values. You can avoid that by reading the JSON while the chassis is ON and then, export that configuration. This will make the parameters to persist (although this is another type of file).
However, SLSC NI R&D also created this tool: https://github.com/ni/slsc-capability-explorer that is able to read the JSON file offline and obtain the default values in the tree. This was not incorporated into the SLSC EDS because it required you to update the source-code to work in LV 2017. Since now we do not need to support previous versions, then maybe we incorporate such tool. @Karl-G1 @csjall

See https://github.com/ni/niveristand-slsc-eds-custom-device/issues/38#issuecomment-582959663 about the potentially concerning licensing implications of this.

@rtzoeller , @Karl-G1 , you are correct that this library is setup with GPL (copy left) within NI. However, I believe that this was setup with that by mistake since that is part of NI and its dependency is https://www.vipm.io/package/jdp_science_jsontext/ and this is BSD. It is very possible that this could be changed in the original code and we could notify this change. Please talk to 3rd party review commit if you want further help. The reason I am bringing this up is because this fix is one of the most annoying problems in working with offline SLSC capabilities and this could could help... Also, this code was create by our (marketing) request back then and it was unfortunate that they used GPL here... anyway...  :)

@Alexbarp it looks like you authored the original commit in that repo which added the license file. Given the inactivity on the repo, you are likely the de facto owner - I recommend you work with the licensing team at NI to get the licensing issue sorted out as part of any request for this issue #42 to be fixed (which would need to be prioritized through @bdexni. At this time we don't have any priority associated with this improvement.


crl-cron.sh ca-crl.pem full path

crl-cron.sh need to include full path for the ca-crl.pem or it will throw errors in cron logs

I'm also seeing this issue. The crl doesn't get regenerated by the cron job and this results in clients not able to connect because of a certificate verify error:
Mon Sep  2 10:22:18 2019 <IP_ADDRESS>:57611 VERIFY ERROR: depth=0, error=certificate revoked: CN=OpenVPN-Client-localhost-username
Mon Sep  2 10:22:18 2019 <IP_ADDRESS>:57611 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Mon Sep  2 10:22:18 2019 <IP_ADDRESS>:57611 TLS_ERROR: BIO read tls_read_plaintext error
Mon Sep  2 10:22:18 2019 <IP_ADDRESS>:57611 TLS Error: TLS object -> incoming plaintext read error
Mon Sep  2 10:22:18 2019 <IP_ADDRESS>:57611 TLS Error: TLS handshake failed
Mon Sep  2 10:22:18 2019 <IP_ADDRESS>:57611 SIGUSR1[soft,tls-error] received, client-instance restarting```


fix: modules and runs api

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Additional documentation e.g., design docs, usage docs, etc.:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

20 of 43 (46.51%)  changed or added relevant lines in 5 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.02%) to 47.681%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/infra/persistence/module_model.go
0
2
0.0%

pkg/infra/persistence/resource.go
5
7
71.43%

pkg/server/manager/resource/util.go
14
19
73.68%

pkg/server/manager/module/module_manager.go
0
14
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/engine/operation/watch.go
1
82.76%

Totals

Change from base Build<PHONE_NUMBER>2:
0.02%

Covered Lines:
10858

Relevant Lines:
22772

💛  - Coveralls


Add reason to AgentVersionNotSupported condition

What this PR does / why we need it:
Add reason to AgentVersionNotSupported condition.
Which issue(s) this PR fixes:
Fixes #7433
Release note:
User now gets information about the type of commands which the guest agent does not support.

/assign @vladikr

Also, deleted some forgotten Println in vm_test.go.

/lgtm
/retest

/retest

/cherry-pick release-0.53
/cherry-pick release-0.49

/cherry-pick release-0.49


Hi,  Can you share the prompt for generating pretrain data?

thanks

my email<EMAIL_ADDRESS>

Nice job! May I also request the prompts for generating the pretrain data? My email address is<EMAIL_ADDRESS>


update PaymentAccountResponse to correct api response structure

Update the Action field of PaymentAccountResponse to Actions, a slice of Action. This is what is correctly returned in the Midtrans API when creating a pay account
see: https://api-docs.midtrans.com/#create-pay-account

Look good, passed on the unit test. Will merge and make a release. Thanks @hardyrarso


How to apply normalization factors

Hi,
I am reading in a hic2cool issue that hic2cool version 0.5 will use divisive correction factors. At the same time it seems that cooler itself still uses multiplicative weights. (See hic2cool) and my old issue.
In the hic2cool issue it is stated that divisive correction factors are applied as follows: corr_i,j = orig_i,j / corrfactor_i / corrfactor_j but in the ICE publication it is  corr_i,j = orig_i,j / corrfactor_i * corrfactor_j:

After the vector of biases is computed, the corrected map of relative contact probabilities is obtained by Tij = Oij/(BiBj)

https://www.nature.com/articles/nmeth.2148
I am a bit confused now what is the old and what is the new way and if cool files produced by hic2cool really use divisive correction factors if all other cool files use multiplicative ones.
I hope you can clarify this a bit.
Thanks a lot,
Joachim

Given the latest answer from hic2cool: https://github.com/4dn-dcic/hic2cool/issues/24 we have now really the situation I feared: Some cool files have stored multiplicative some have divisive correction factors. Any idea how to solve this?

All weights generated by cooler balance are multiplicative. It is the reciprocal of the biases as defined in the ICE paper. We decided on switching to this convention long ago.
Because of some miscommunication between us, hic2cool and HiGlass devs, the 4DN DCIC started converting hic files by extracting their divisive weights unmodified. Because of this behavior, these specific weights (named KR, VC, VC_SQRT) ended up being special-cased by HiGlass and treated as divisive. DCIC decided that it would be better to leave the behavior as such and make hic2cool do the same.
The solution will be to special-case those same 3 names in the cooler.matrix selector.  If you apply weights yourself, you'll have to account for those 3 special cases.
I'll aim to have that implemented in the next release as well as an option to force weight application to be divisive or multiplicative as desired. How does that sound?

Hi,
sorry for the delayed answer, I do apply the correction factors on my own and so far I am using the metadata information which tool and which version created the file to decide if it is divisive or multiplicative. It would be really helpful (as you suggested somewhere else if I remember correctly?) to add a field to the metadata if the correction factors are divisive or multiplicative.
Best,
Joachim


Fix async race condition bug in storage operations

Description
Race condition on write and read.

[ ] Closes #716

Solution
Using of await is necessary when switching from expression body returning feature (=>) to async block body ({}).

Thank you for your contribution!


Notify TAG-Runtime related projects of the switch from  k8s.gcr.io to registry.k8s.io.

Relevant github issue: https://github.com/kubernetes/k8s.io/issues/4780
Need to notify projects of the registry endpoint changes.

Do we have a list of projects that we need to reach out to?

@helayoty, here's a list that we can start with (Graduated, Incubating):

Containerd
CRI-O
KubeEdge
Harbor
KEDA
Knative
Volcano

Thanks!

@helayoty can we close this? Thx.

Closing this, given the thumbs up.


Spelling, formatting and grammar

Just fixing a few things in the README to make it nicer to read.
Awesome library, really helped me understand event sourcing and CQRS. Thanks!

@mishudark Is there any way we could get the failing wercker build going?
I'd soon like to create a PR myself and I am sure @ides15 would also like to see this merged.
😉

Hello, thanks for th PR, I'm moving this repo out of werker, to put everything into github actions
sorry for the long delay, I'm back, to continue working on the v2.0


Inline border aren't visible

Hi,
It seems that inline border are not visible in the "Description" view despite they are well visible in the "Advanced description" view.
However, outline borders are visible on both tabs. Changing size, color, etc doesn't help.
thanks,

Can you attach an example using the code viewer?
adding border-inline and border-inline-style to elements works as expected.
If you are referring to tables, cells and rows only inherit color from adding a table border in table properties context menu.
Rows and cells are bordered using single or multi-select then choosing border styles from their context menu.

Ok, I didn't see the "context menu" when selecting cells !
It works for row but I don't have the option "column properties"

There's no parent element in html for column cells, just row.  Multi-select cells vertically and use the context menu to style a group of column cells all at once.


Vue error when using vue-tsc - Type '{}' is not assignable to type 'ComponentProps'

Describe the bug
I have configured vue-tsc in a vue project and after running the validation I got an error.
How to reproduce the issue

<script setup lang="ts"> section

import UnpluginCloseChip from "~icons/unplugin/close-chip.svg";

<template> section

 <UnpluginCloseChip />

File tsconfig.json

{
...
  "compilerOptions": {
    "skipLibCheck": true,
    "types": ["vite/client", "unplugin-icons/types/vue"],
  },
...
}

File package.json

...
  "scripts": {
     "check-types": "vue-tsc --noEmit",
  },
 "devDependencies": {
    "unplugin-vue-components": "^0.26.0",
    "vue": "~3.2.45",
  },
...

After running the following command yarn check-types I am getting the following error.

Type '{}' is not assignable to type 'ComponentProps<string>'.
  Type '{}' is not assignable to type 'string'.

44       <UnpluginCloseChip />
          ~~~~~~~~~~~~~~~~~

Reproduction
Vue error when using vue-tsc
System Info
System:
    OS: macOS 14.3
    CPU: (10) arm64 Apple M1 Max
    Memory: 111.53 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.14.0 - ~/.nodenv/versions/18.14.0/bin/node
    Yarn: 1.22.19 - ~/.nodenv/versions/18.14.0/bin/yarn
    npm: 9.3.1 - ~/.nodenv/versions/18.14.0/bin/npm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Safari: 17.3

Used Package Manager
yarn
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

can you remove the .svg extension in the import?

Now I get this error:
error TS2307: Cannot find module '~icons/unplugin/close-chip' or its corresponding type declarations.

5 import UnpluginCloseChip from "~icons/unplugin/close-chip";
                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Yes I have typescript: "typescript": "~4.9.4",.
I will create the reproduction env.

did you install unplugin icons dev dependency?

Yes, I did. I run this: yarn add -D unplugin-icons

@userquin  The problem was that I was using a very old version of the library "vue-tsc": "~1.0.24"
I am using "vue-tsc": "~1.8.27" and now is working fine.


Update QueueAdapterOptions typing

Thanks for your awesome work!
Here is a typing PR to add the ability to modify one attribute only and not the whole option object.

Hi, @AlexisAnzieu thank you for wanting to contribute, but all QueueAdapters are defined with Partial<> as needed.
https://github.com/felixmosh/bull-board/blob/37a618f8cc9c58b0591f288a298293650ec2b133/packages/api/src/queueAdapters/bullMQ.ts#L13
What is the TS error that you get?

Hi @felixmosh. (I work with Alexis.)
The error is:
error TS2739: Type '{ readOnlyMode: true; }' is missing the following properties from type 'QueueAdapterOptions': allowRetries, prefix, description

55       options: {
         ~~~~~~~

  node_modules/@bull-board/nestjs/dist/bull-board.types.d.ts:18:5
    18     options?: QueueAdapterOptions;
           ~~~~~~~
    The expected type comes from property 'options' which is declared here on type 'BullBoardQueueOptions'

Our code that triggers this error:
@Module({
  // ...
  imports: [
    // ...
    BullBoardModule.forFeature({
      name: QueueName.OPENAI,
      adapter: BullAdapter,
      options: {
        readOnlyMode: true,
      },
    }),
  ],
})

Hi, thanx for the clarification, can you change the PR, so that the usage of this type will use Partial<> (inside nest module)

Released in v5.9.2
Thank you for your PR

Thank you for your reactivity 🚀


plz add Lora block weight in PowerPrompt

Many thx for this useful extension for comfyui, plz add Lora block weight in PowerPrompt
https://github.com/ltdrdata/ComfyUI-Inspire-Pack
https://github.com/hako-mikan/sd-webui-lora-block-weight

by the way,
1 add autocomplete for lora in TextEncode
https://github.com/pythongosssss/ComfyUI-Custom-Scripts
2 add tag to in TextEncode when add lora by autocomplete
https://github.com/Extraltodeus/LoadLoraWithTags


Made code PEP8 compilant

Fix for Issue #1

@NavneetNandan review this.
I guess it looks pretty good.


add ILI9341 320x240 LCD driver

The ILI9341 driver should be the same as ST7735 except for the init sequence and screen size. An example init sequence is here
https://github.com/adafruit/Adafruit_ILI9341/blob/master/Adafruit_ILI9341.cpp#L151-L178
A new class needs to be added similar to this https://github.com/microsoft/devicescript/blob/9cd49aef06114a147cbd5127fc12f1fc58112769/packages/drivers/src/st7735.ts#L247-L264
The main thing is to test it with hardware
** Datasheet, firmware, etc... **
https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf

This works as a basic implementation:
export interface ILI934xOptions extends STLikeDisplayOptions { }

export class ILI934xDriver extends STLikeDisplayDriver {
    constructor(image: Image, options: ILI934xOptions) {
        super(
            image,
            options,
            hex`
01 80 80 // software reset
ED 04 64 03 12 81 //power on sequence control
3A 01 55 // pixel format
B1 02 00 18 // FRMCTR1
B6 03 08 A2 27 // display function control
11 80 78
29 80 78
`
        )
    }
}

Tested on an adafruit 320x240 ILI9340C
it'll probably be worth adding more options but i'm currently unsure what exactly would be useful (ie what varies between products)

https://github.com/microsoft/devicescript/pull/663

Added!


List exports might not include all accounts in the list

I used listmanager.py to export the list of accounts followed by<EMAIL_ADDRESS>(meidasTouch@mstdn.social.csv). When I used the same script to import that list into my US politics list, API errors were returned for 12 of the 50 accounts.
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')
WARNING: Unable to add<EMAIL_ADDRESS>to US politics: ('Mastodon API returned error', 422, 'Unprocessable Entity', 'Validation failed: Account has already been taken')

Further investigation revealed that these accounts appeared in the list web  UI after a previous run, but for some reason are not listed in the list_accounts API call, so the script thinks those accounts need to be added to the list. This results in the API errors, because the accounts ate already in the list.
I will open an issue on the Mastodon project, and use this issue for reference.

It turns out that information from this API call is eventually accurate, it's just stale. This seems to be a caching problem somewhere. Investigating further with the infosec.exchange instance administrator.

The issue occurs immediately after adding an account to a list, even if the list accounts API call hasn't been made recently, so it's not an issue of the API results being cached, but of a long delay in the accuracy of the data provided by the API call.

Mastodon bug reported here https://github.com/mastodon/mastodon/issues/22828

Disregard. I forgot to paginate


quagga discontinued - modify scripts for bgp commands via vtysh

As quagga is discontinued, in order to transition to FRR, review all scripts that manipulate bgp by directly editing the /etc/quagga/bgp.conf file an dreplace it by vtysh commands to achieve same result.
As vtysh is also used to configure FRR, it should help transition to FRR in a second phase.

some vtysh commands:
to remove bgp neighbor:

vtysh -c "show bgp summary"
vtysh -c "configure terminal" -c "router bgp  65800" -c "no neighbor <IP_ADDRESS> remote-as 65936"
vtysh -c "write memory"


docs: add proposal for grafana dashboard parent folder management

Aim of the merge request:
This MR aims to create a document to propose an evolution on the folder management related to the parent folder.
The suggested new features are:

Use a folderRef field to target a folder deployed thanks to the GrafanaFolder CR.
Use a folderUID field to target an existing folder in Grafana.
Enable or disable folder creation from GrafanaDashboard by adding a field createFolder (default: true for retrocompatibility). This field cannot be false if folderUID and folderRef are not set in the GrafanaDashboard manifest.

Breaking change
There is no breaking change because it is just a proposal document. Nothing is implemented yet.
This should be discussed during a maintainer meeting.

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

Outcome from discussing this in our weekly:
we want to only add folderUid and folderRef fields. The createFolder fields is implicitly defined through the presence of the new fields. This means:

If folder is set and none of the other fields is set (backwards compat. case): Create the folder
If folderUID or folderRef is set, don't create the folder
If folderUID or folderRef AND folder is set, the new fields take priority -> don't create the folder

Will clean up the proposal and we can further discuss this async

Outcome from discussing this in our weekly:
we want to only add folderUid and folderRef fields. The createFolder fields is implicitly defined through the presence of the new fields. This means:

If folder is set and none of the other fields is set (backwards compat. case): Create the folder
If folderUID or folderRef is set, don't create the folder
If folderUID or folderRef AND folder is set, the new fields take priority -> don't create the folder

Will clean up the proposal and we can further discuss this async

@theSuess Normally, this should be fine now. I let you review a last time the document. :)


InternalServerError - Making a credential

I suspect there is at least one environment variables that needs to be set before running this proof-of-concept.
I noticed the makeCredential route is looking for an ORIGIN variable, eg.
guard let origin = Environment.get("ORIGIN") else {             throw Abort(.internalServerError)         }
Any idea what I should set this to?

No worries, I'm really looking forward to incorporating PassKeys into my app!


Fix  in  to use default font size 14px and not 16px as it appears larger than regular text

Overview
There is a discrepancy in the styling of inline code snippets with backticks `` and  when added to <Admonition>, the latter has larger font size than regular body text.
Slack convo: https://prisma-company.slack.com/archives/C5Z9TH6N9/p1667910235702469
MDX code overview

Code snippet with backticks in body text has font size 14px:

Code snippet with <inlinecode>in <Admonition> has font size 16px:

This has already been fixed with some other latest changes.


[Bug] Doesn't work on Windows anymore

Describe the bug
The v3 of this plugin doesn't work on Windows anymore.

It fails because it can't find "collect-stories.js" with a wrong path
It fails with stories containing sources with \n

Steps to reproduce the behavior

Create a storybook with this addon
Compile it under windows

Screenshots and/or logs
ModuleNotFoundError:
Module not found:
Error: Can't resolve
<EMAIL_ADDRESS>
NB: "projode_modules" should be "proj\node_module" but \n has been removed
Environment

OS: Windows
Node.js version: v16
NPM version: 8.11

Additional context
It caused by this commit : https://github.com/storybookjs/addon-svelte-csf/commit/0f5bf9878bf80a09efd84276d8157a729ec7bad3
"Fixed" by this one : https://github.com/storybookjs/addon-svelte-csf/commit/fa5505bda90c1c1d06a6a6b3d508b82d6813ef14#diff-c5f119d3c0fad64afb4a542f1fb2bdf0e475cc6191a63712dbfba50bb5af6c3c
However, it's better to replace backslash with juste slash for windows.
After fixing this issue, the stories containing sources with multilines doesn't compile either. The generated stories contains invalid json.
For example:
   const { default: parser } = require('C:/Users/MyApp/proj/node_modules/@storybook/addon-svelte-csf/dist/parser/collect-stories.js');
   const __storiesMetaData = parser(Spacer_stories, {"meta":{"title":"Component/Core/Spacer"},"stories":{"spacer":{"storyId":"component-core-spacer--spacer","name":"Spacer","template":false,"source":"<Surface row>\r
\t<Button>A</Button>\r
\t<Spacer/>\r
\t<Button>B</Button>\r
</Surface>","hasArgs":false}},"allocatedIds":["default","Meta","Story","Surface","Button","Spacer"]});
   export default __storiesMetaData.meta;
   export const spacer = __storiesMetaData.stories["spacer"];

After analysing a little more this issue, it`s caused by "dedent".
const myObject = { name: "my\nname" };
console.log(dedent`--> ${JSON.stringify(myObject)}`);

print :
--> {"name":"my
name"}

In fact, it's caused by this commit https://github.com/storybookjs/addon-svelte-csf/commit/02ce02a7b2e3be5b0b29ef844dc05d38004dbfc4 by @hobbes7878


Expo Prebuild

Incident Identifier: BAD0009B-86D5-4761-898E-42942AA1EF8D
CrashReporter Key: 91FE9550-7974-8D4E-BC06-971601F52573
Hardware Model: MacBookPro16,2
Coalition: com.apple.CoreSimulator.SimDevice.B8C8F3B3-9BAA-4799-9EDD-A2FD5439F7AC [24256]
Responsible Process: SimulatorTrampoline [51232]
Date/Time: 2024-08-25 14:46:31.2490 +0500
Launch Time: 2024-08-25 14:46:31.1987 +0500
OS Version: macOS 14.6.1 (23G93)
Release Type: User
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: DYLD 1 Library missing
Library not loaded: @rpath/MapboxCommon.framework/MapboxCommon
Referenced from: <6645BACD-586B-3B2C-A884-09B701040564> /Users/USER/Library/Developer/CoreSimulator/Devices/B8C8F3B3-9BAA-4799-9EDD-A2FD5439F7AC/data/Containers/Bundle/Application/8AFF4689-0E88-4190-85AE-614DC219379F/YurDrivers.app/YurDrivers
Reason: tried: '/Library/Developer/CoreSimulator/Volumes/iOS_21F79/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/MapboxCommon.framework/MapboxCommon' (no such file), '/usr/lib/swift/MapboxCommon.framework/MapboxCommon' (no such file, not in dyld cache), '/Users/mac/Library/Developer/CoreSimulator/Devices/B8C8F3B3-9BAA-4799-9EDD-A2FD5439F7AC/data/Containers/Bundle/Application/8AFF4689-0E88-4190-85AE-614DC219379F/YurDrivers.app/Frameworks/MapboxCommon.framework/MapboxCommon' (no such file), '/Users/mac/Library/Developer/CoreSimulator/Devices/B8C8F3B3-9BAA-4799-9EDD-A2FD5439F7AC/data/Containers/Bundle/Application/8AFF4689-0E88-4190-85AE-614
(terminated at launch; ignore backtrace)

@syedmumersajjad check this out https://github.com/pawan-pk/react-native-mapbox-navigation/issues/12#issuecomment-2309303069


IconCancel is missing

As the title says, the icon "cancel" seems to be missing.

Nevermind, wrong version was installed.


[SMALLFIX] Converted field to local variable in HdfsFileInputStreamIntegrationTest

Converted a field to a local variable in the HdfsFileInputStreamIntegrationTest class.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/10177/
Test PASSed.

LGTM


Confirm AKV permission required

Looks the app requires unwrap key permission.
https://github.com/aspnet/AspNetCore.Docs/issues/11941#issuecomment-482182673
This makes sense because that's exactly what it has to do ... unwrap the key!
I'll repro it here and then adjust the text as necessary.
cc: @brobichaud

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

ID: b63ab082-ad30-b00d-ecd1-ca88eee1659e
Version Independent ID: 69818122-e47a-3fed-ea37-8009f66e2a5c
Content: Configure ASP.NET Core Data Protection
Content Source: aspnetcore/security/data-protection/configuration/overview.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Looks like it requires both Wrap Key and Unwrap Key + the content doesn't instruct the user to create the key. I'll revise the content.

Looks like it requires both Wrap Key and Unwrap Key + the content doesn't instruct the user to create the key. I'll revise the content.


Move CSS to a .css file

This part:
https://github.com/WEEE-Open/crauto/blob/eb33d55dc62376dfabb0cf009d88d9c8c60bd4e8/templates/base.php#L9-L39

Closed in https://github.com/WEEE-Open/crauto/commit/327a0aab63cfad19d72f9a66315b5cb02a7cfa33 but referenced the wrong issue in the commit message


⚠ Bofrost.lu has degraded performance

In a04fd1c, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 857 ms

Resolved: Bofrost.lu performance has improved in 22af7e3 after 306 days, 0 hours, 58 minutes.


Unable to Make All

Hi,
I have cloned the repo and tried building the whole package without any luck.
I attach a picture of the error message. I tried troubleshooting some of these but nothing changed.
I am using GNU Make 3.81, Docker version 20.10.22, build 3a2c30b, Docker Compose version v2.15.1 On a Mac, macOS 12.5.1 Intel.
Let me know if you need anything else from me, I'll be happy to keep the conversation open.
`Reading package lists...
W: GPG error: https://deb.nodesource.com trusty InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1655A0AB68576280
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
libpython-stdlib libpython2.7-minimal libpython2.7-stdlib python
python-minimal python2.7 python2.7-minimal
Suggested packages:
python-doc python-tk python2.7-doc binutils binfmt-support
The following NEW packages will be installed:
libpython-stdlib libpython2.7-minimal libpython2.7-stdlib nodejs python
python-minimal python2.7 python2.7-minimal
0 upgraded, 8 newly installed, 0 to remove and 1 not upgraded.
Need to get 17.8 MB of archives.
After this operation, 86.5 MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
nodejs
E: There are problems and -y was used without --force-yes
/bin/sh: 1: npm: not found
/bin/sh: 1: npm: not found
1 error occurred:
* Status: The command '/bin/sh -c apt-get update;     apt-get install -y curl;     curl -sL https://deb.nodesource.com/setup_8.x | bash -;     apt-get install -y nodejs;     npm update -g npm;     npm install -g yarn;' returned a non-zero code: 127, Code: 127`

Hi, thanks for the report!
This repository is getting old, that doesn't surprise me that things are broken :sweat_smile:
I'd simply recommend using more recent versions of everything, in Dockerfiles and docker-compose YAML files, checking out how to install these more recent versions on their official docs.
A PR updating everything would be quite welcome!

Yeah, makes sense. If I figure out a workaround, I'll definitely share a PR.
Thanks, will close


Unable to use worker.send on version 0.1.3

After the new update, I am now unable to send messages to my workers from my master since this library would throw an error.
// from cluster-node-cache.js
    process.on("message", function(msg) {
      if(resolve_dict[msg.sig]) {
        resolve_dict[msg.sig](msg.body);
        delete resolve_dict[msg.sig];
      } else {
        throw new Error("Could not find key: " + msg.sig);
      }
    });

This code will handle all messages, so if I try to do a worker.send without a sig, it will go to the throw.

Fixed in commit 6171609 - Really sorry about that, that was stupid!


Project Automation

Description
Project automation. When issues are added or removed from milestones, it will update a public roadmap.
Quick checks:

[x] I have followed the Code Guidelines.
[x] There is no other pull request for the same update/change.
[x] I have written unit tests.
[x] I have made sure that the PR is of reasonable size and can be easily reviewed.

@hariso ok. I think we're at the final review. I missed a hard coded value in one of the graphql queries. I also removed the extra env variables.

@hariso I refactored. This is way better. I didn't know you could recast node into a different object on graphql queries. That made this whole thing more deterministic.


Use sample component names as retrieved from CDQ

Fixes
Fixes HAC-3024
Description
When creating sample components, use the suggested name returned by CDQ rather than prepending the application name and adding the -sample suffix.
Type of change

[x] Bugfix

/retest


Hi , How to close all default animations ? Because I don't want to use animaitons.

you can modify library dimens params to fit the needs. set active and inactive to same numbers in order to achieve this


In the beta, some of the given passwords I got were > 16. 17, even 18 chars!

I calculate it ALWAYS generating 17 character passwords:

No padding
2-digit number at the end (2 characters)
1 separator character between 4 entities (3 words and 1 number -- 3 characters)
3 words of 4 characters each alternating case (12 characters)

2 + 3 + 12 == 17
As bad as sites are that max out at 16 character passwords, this preset will fail every time.
I guess we need to reduce the number of digits to 1.

Good catch. I've reduced the 2 digit number to 1


Support for window level presets

Almost all dicom viewers offer a feature that allows predefined window levels to be set. For example for CT scans CT Abdomen,CT Angio,CT Bone,CT Brain,CT Chest,CT Lungs presets are available. This feature would be very useful in diagnosis. Perhaps some guidance on implementation can be had from here >>> https://www.radiantviewer.com/dicom-viewer-manual/change_brightness_contrast.htm

Yes we had that in the Meteor version but they haven't been added in the React UI yet. See https://viewer-legacy.ohif.org/

Yes we had that in the Meteor version but they haven't been added in the React UI yet. See https://viewer-legacy.ohif.org/

I cant seem to find the feature in the Meteor version at the link you provided. Am I missing something?

It's in User Preferences

It's in User Preferences

how do we apply them to a window?

ok got it...via the numeric keys

Mentioned here: https://github.com/OHIF/Viewers/issues/1287
But this is a better tracking issue.

Please review the latest code in the master branch. This issue might have been resolved. If it persists, kindly reopen the issue with updated details.
Try viewer-dev.ohif.org instead of viewer.ohif.org
Our viewer.ohif.org is deployed from release branch while viewer-dev.ohif.org is our master  branch
Read more about branch explanations here https://docs.ohif.org/development/getting-started#developing


Huge update

It will take huge amounts of time so please be patient!!

can't wait for the China summer school closure!!!

So, what will this update contain?

gugugu

oh no, you gugu-ed

huge update but it's almost a month

it's a huge update without screenshots.
it's almost a month

agree


SVG layer position bug

Steps to reproduce:

Add method to create a OSM Layer and invoke it first
Add method to create SVG layer in way that it will be created after few seconds
While 2 is in timeout, move OSM layer via mouse
SVG layer location will be wrong now whenever it will be created

I attempted to recreate this in a couple of ways:

Via a new test in https://github.com/OpenGeoscience/geojs/tree/svg-alignment using selenium to invoke a drag
In a jsbin example at http://jsbin.com/johimi/1/edit?js,output

Neither shows the behavior indicated.

Thanks @jbeezley. I will have a look. Also, I will see if I can modify the test to reproduce the behavior.

The linked jsbin initialized the d3 layers incorrectly.  I fixed it in an updated version, but misalignment still doesn't occur.

@jbeezley I zoom in and pan and then click the button and then zoom in again, I see this offset (attached).

Seems like its happening for G.

Looks like a race condition of some sort, I can't reproduce it here.  My guess is there is something causing the base GL layer from applying a pan when under load.  That is why I added both the GL and SVG point features, to see if they are both off by the same amount.

I can only see the misalignment if I cause the same problem I see with misaligned GL layers (and then all features are misaligned).
See this jsbin: http://jsbin.com/jikojivoho/1/edit?js,output
Note that I call bounds() where the center is different than the original center.  The feature layers are now offset.

Looks like this is a gl only bug.  See here.  The d3 renderer was specified incorrectly defaulting back to gl.  Looking at the source, I think it could be related to one of the camera bugs.

Adding to this comment, the alignment bug no longer occurs once you interact with the map.  So the camera is in an incorrect state from when you recenter after adding the layer, but before you pan with the mouse where the explicit centering relies on camera.setPosition.

May be then its the same bug which I observed. I will look into it.

Not the same, but related.

Fixed by #426.


Remember The Window State & Last File Opened

To Remember The Last Opened State Of The Window
The app right now does not remember it's last window sizing state, and always opens in default size. On a UHD window, where the UI is already tiny, this just adds another obstacle to working within the app quickly.
If Lorien is closed full screen, it should open full screen.
Use case: Quality of life and happiness using the app. Quick access to working in the app without interruption.
Related: To Remember The Last Opened File and Auto Load It
Use case: Be able to continue working in the last file opened, as Whiteboards will always be constantly opened and new content added, perhaps many times during the day. If the app closes (or crashes), the file is forgotten and the user must open the file again.

I just implemented saving/restoring of the window size in: https://github.com/mbrlabs/Lorien/commit/b3194c23fb339040bb56052156101eea0d0f6d7f. Restoring open files has already been implemented in: https://github.com/mbrlabs/Lorien/pull/78

In this regard, I would like a startup option with a specified screen size. Full screen would also be nice.


Change license to GPLv3

Description of change
There is a big perception issue within the community regarding the virality of AGPLv3. The authors of this project initially chose that license to ensure that all modifications are released back to the community. However, we are seeing that several organizations have blanket banned the use of AGPLv3 because of the misunderstanding of what modifications could mean.
Until GNU comes up with a "Lesser" AGPLv3 that hopefully fulfills the aspirations of Aperture authors, we have decided to downgrade the license to GPLv3 for now.
Checklist

[X] Documentation is changed or added

This change is

Don't forget to update the FAQs in docs as well.


publishNotReadyAddresses not working

according to https://github.com/kubernetes/kubernetes/issues/58662 the publishNotReadyAddresses: true is not working. Instead they suggest this annotation as workaround: service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"

[ ] Chart version not bumped (the versions are all bumped and released at the same time)
[ ] README.md updated with any new values or changes
[ ] Updated template tests in ${CHART}/tests/*.py
[ ] Updated integration tests in ${CHART}/examples/*/test/goss.yaml

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

Which version of Kubernetes are you running? When we deprecated this option I checked to make sure that it was supported by 1.8 https://github.com/elastic/helm-charts/pull/123#discussion_r281612632 and it was. However that issue you linked to makes it sound like this option was never properly implemented even though the changelog made it sound like it was. I'm curious to know which version you are running since I would hope that this fix was backported to the latest 1.8 release too.
jenkins test this please

I confirmed that this is indeed broken on the latest 1.8 cluster running in minikube. 1.8 isn't part of the automated testing suite anymore since GKE no longer has the version available.
I'll make sure to manually test anything that could affect backwards compatibility for 1.8 from no on (instead of blindly trusting the changelogs).
Thank you for finding and fixing this!

I'm running v1.10.11


Beginning of acceptance test framework

This is the start of an acceptance test using mountaincar and softmaxAC. So far I have done:

Added tests/acceptance/softmaxAC_mc.py with a test that writes to a database using DefinitionPart and reads from it using ExperimentDefinition.
Added a unit test tests/test_generate_configurations.py, which tests the function in DefinitionPart.py.

The tests are failing because Scheduler imports typing.Self, which was implemented in Python 3.11. The import is not from my code, it is from main. Should we just stop testing python 3.10?

split styling changes and tests
maybe remove python 3.10 from testing?
make sure local run actually runs everything

@andnp we need your advice here. The Github workflow tests for this PR are failing because of two issues

Scheduler imports typing.Self, which is only introduced with python 3.11. The workflow tests include python 3.10.
The user's experiment.py cannot import ml_experiment since it is not installed during the github workflow, and ml_experiment is not in sys.path. See for more details: #20

Yup, I think editing the workflow spec to solve both of these is a great strategy! I'm quite comfortable dropping 3.10 support

Below tests are those on the main branch, the PR has an updated test.yaml and those pass when run locally through https://github.com/nektos/act