SPFx 1.18 failed to serve - error:0308010C:digital envelope routines::unsupported

npm run serve command with node 18.17.1  for SPFx 1.18 throws below errors where as it works perfectly fine with Node v16
`ERROR in ./src/webparts/listView/components/ListView.module.scss (./node_modules/spfx-css-modules-typescript-loader!./node_modules/spfx-fast-serve-helpers/node_modules/css-loader/dist/cjs.js??ref--8-2!./node_modules/spfx-fast-serve-helpers/node_modules/postcss-loader/dist/cjs.js??ref--8-3!./node_modules/clean-css-loader/lib??ref--8-4!./node_modules/sass-loader/dist/cjs.js??ref--8-5!./src/webparts/listView/components/ListView.module.scss)
Module build failed (from ./node_modules/spfx-fast-serve-helpers/node_modules/css-loader/dist/cjs.js):
Error: error:0308010C:digital envelope routines::unsupported
at D:\Learning\listView\src\webparts\listView\components\ListView.module.scss:1:1
at new Hash (node:internal/crypto/hash:69:19)
at Object.createHash (node:crypto:133:10)
at getHashDigest (D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\loader-utils\lib\getHashDigest.js:46:34)
at D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\loader-utils\lib\interpolateName.js:113:11
at String.replace ()
at interpolateName (D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\loader-utils\lib\interpolateName.js:110:8)
at defaultGetLocalIdent (D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\css-loader\dist\utils.js:208:43)
at generateScopedName (D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\css-loader\dist\utils.js:432:24)
at exportScopedName (D:\Learning\listView\node_modules\postcss-modules-scope\src\index.js:95:28)
at localizeNode (D:\Learning\listView\node_modules\postcss-modules-scope\src\index.js:124:22)
at Array.map ()
at Selector.map (D:\Learning\listView\node_modules\postcss-selector-parser\dist\selectors\container.js:269:23)
at localizeNode (D:\Learning\listView\node_modules\postcss-modules-scope\src\index.js:120:31)
at traverseNode (D:\Learning\listView\node_modules\postcss-modules-scope\src\index.js:152:32)
at Selector.each (D:\Learning\listView\node_modules\postcss-selector-parser\dist\selectors\container.js:159:16)
at traverseNode (D:\Learning\listView\node_modules\postcss-modules-scope\src\index.js:175:18)
ERROR in ./src/webparts/listView/assets/welcome-light.png
Module build failed (from ./node_modules/spfx-fast-serve-helpers/node_modules/file-loader/dist/cjs.js):
de_modules\loader-utils\lib\interpolateName.js:110:8)
at Object.loader (D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\file-loader\dist\index.js:29:48)
ERROR in ./src/webparts/listView/assets/welcome-dark.png
Module build failed (from ./node_modules/spfx-fast-serve-helpers/node_modules/file-loader/dist/cjs.js):
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:69:19)
at Object.createHash (node:crypto:133:10)
at getHashDigest (D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\loader-utils\lib\getHashDigest.js:46:34)
at D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\loader-utils\lib\interpolateName.js:113:11
at String.replace ()
at interpolateName (D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\loader-utils\lib\interpolateName.js:110:8)
at Object.loader (D:\Learning\listView\node_modules\spfx-fast-serve-helpers\node_modules\file-loader\dist\index.js:29:48)
ERROR in chunk list-view-web-part [entry]
list-view-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported`

I have the same problem. In a HelloWorld example I left only an empty div (without scss) and sill I got an error:
[10:52:23] [fast-serve] To load your scripts, use this query string: ?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/manifests.js
i ｢wds｣: Project is running at https://localhost:4321/
i ｢wds｣: webpack output is served from https://localhost:4321/dist/
i ｢wds｣: Content not from webpack is served from C:\Users\sbak\Desktop\tmp\test2
i ｢wds｣: 404s will fallback to /index.html
× ｢wdm｣: Time: 588ms
Entrypoint hello-world-web-part =
ERROR in chunk hello-world-web-part [entry]
hello-world-web-part.js
C:\Users\sbak\Desktop\tmp\test2\node_modules\ansi-html\index.js
error:0308010C:digital envelope routines::unsupported
i ｢wdm｣: Failed to compile.
Dependecies:
node: v18.17.1
C:\Program Files\nodejs -> .
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>gulpfile.js
build.addSuppression(Warning - [sass] The local CSS class 'ms-Grid' is not camelCase and will not be type-safe.);
var getTasks = build.rig.getTasks;
build.rig.getTasks = function () {
var result = getTasks.call(build.rig);
result.set('serve', result.get('serve-deprecated'));
return result;
};
/* fast-serve /
const { addFastServe } = require("spfx-fast-serve-helpers");
addFastServe(build);
/ end of fast-serve */
build.initialize(require('gulp'));
fast-server/config.json:
{
"$schema": "https://raw.githubusercontent.com/s-KaiNet/spfx-fast-serve/master/schema/config.latest.schema.json",
"cli": {
"isLibraryComponent": false
}
}
fast-server/webpack.extend.js
const path = require('path');
const webpackConfig = {};
const transformConfig = function (initialWebpackConfig) {
initialWebpackConfig.resolve.modules.push(path.resolve(__dirname, './../src'));
return initialWebpackConfig;
};
module.exports = {
webpackConfig,
transformConfig
};
package.json -> from template + "spfx-fast-server-helpers": "^1.18.0"
Thanks in advance for investigating!

Thank you for reporting. I have some ideas how to fix it, most likely will publish a fix tomorrow.

Just wanted to chime in and say I have the same issue. Upgraded to SPFx 1.18.0 and Node 18.17.1 Gulp serve works fine but npm run serve does not. Here's my terminal log after running the command
PS C:\RespositoriesGit\CP\clientportalsharepoint> npm run serve

><EMAIL_ADDRESS>serve
> gulp clean && gulp bundle --custom-serve --max_old_space_size=8192 && fast-serve

Build target: DEBUG
[13:06:13] Using gulpfile C:\RespositoriesGit\CP\clientportalsharepoint\gulpfile.js
[13:06:13] Starting 'clean'...
[13:06:13] Starting gulp
[13:06:13] Starting subtask 'clean'...
[13:06:14] Finished subtask 'clean' after 530 ms
[13:06:14] Finished 'clean' after 534 ms
[13:06:14] ==================[ Finished ]==================
[13:06:15] Project client-portal version:1.0.0
[13:06:15] Build tools version:3.18.0
[13:06:15] Node version:v18.17.1
[13:06:15] Total duration:3.61 s
[13:06:15] Node flags detected: --max_old_space_size=8192
[13:06:15] Respawned to PID: 108972
Build target: DEBUG
[13:06:18] Using gulpfile C:\RespositoriesGit\CP\clientportalsharepoint\gulpfile.js
[13:06:18] Starting 'bundle'...
[13:06:18] Starting gulp
[13:06:18] Starting subtask 'pre-copy'...
[13:06:18] Finished subtask 'pre-copy' after 66 ms
[13:06:18] Starting subtask 'copy-static-assets'...
[13:06:18] Starting subtask 'sass'...
[13:06:18] Finished subtask 'sass' after 102 ms
[13:06:18] Starting subtask 'lint'...
[13:06:18] [lint] eslint version: 8.49.0
[13:06:18] Starting subtask 'tsc'...
[13:06:18] [tsc] typescript version: 4.5.5
[13:06:19] Finished subtask 'copy-static-assets' after 402 ms
[13:06:33] Finished subtask 'lint' after 14 s
[13:06:37] Finished subtask 'tsc' after 18 s
[13:06:37] Starting subtask 'save-webpack-config'...
[13:06:37] Finished subtask 'save-webpack-config' after 708 μs
[13:06:37] Starting subtask 'post-copy'...
[13:06:37] Finished subtask 'post-copy' after 239 μs
[13:06:37] Starting subtask 'configure-webpack'...
[13:06:37] Finished subtask 'configure-webpack' after 576 ms
[13:06:37] Starting subtask 'webpack'...
[13:06:58] Finished subtask 'webpack' after 21 s
[13:06:58] Finished 'bundle' after 40 s
[13:06:59] ==================[ Finished ]==================
[13:06:59] Project client-portal version:1.0.0
[13:06:59] Build tools version:3.18.0
[13:06:59] Node version:v18.17.1
[13:06:59] Total duration:43 s
[13:07:01] [fast-serve] To load your scripts, use this query string: ?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/manifests.js
i ｢wds｣: Project is running at https://localhost:4321/
i ｢wds｣: webpack output is served from https://localhost:4321/dist/
i ｢wds｣: Content not from webpack is served from C:\RespositoriesGit\CP\clientportalsharepoint
i ｢wds｣: 404s will fallback to /index.html
× ｢wdm｣: Time: 14544ms
Entrypoint admin-manage-permissions-web-part =
Entrypoint common-document-library-web-part =
Entrypoint common-iframe-web-part =
Entrypoint home-about-web-part =
Entrypoint home-banner-web-part =
Entrypoint home-documents-web-part =
Entrypoint home-links-web-part =
Entrypoint home-marketing-web-part =
Entrypoint home-videos-web-part =
Entrypoint home-page-web-part =
Entrypoint pt-dashboard-web-part =
Entrypoint pt-reports-web-part =
Entrypoint pt-search-web-part =
Entrypoint site-create-web-part =
Entrypoint site-request-site-web-part =
Entrypoint site-select-web-part =
Entrypoint ttc-carry-forward-web-part =
Entrypoint ttc-compliance-summary-web-part =
Entrypoint ttc-dashboard-web-part =
Entrypoint ttc-documents-web-part =
Entrypoint ttc-filing-calendar-web-part =
Entrypoint ttc-notices-web-part =
Entrypoint ttc-on-demand-reports-web-part =
Entrypoint ttc-prepayment-web-part =
Entrypoint ttc-rate-validation-web-part =
Entrypoint ttc-tax-returns-web-part =

ERROR in chunk 0
chunk.0.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk 1
chunk.1.js
C:\RespositoriesGit\CP\clientportalsharepoint\node_modules\jspdf\node_modules\dompurify\dist\purify.js
error:0308010C:digital envelope routines::unsupported

ERROR in chunk admin-manage-permissions-web-part [entry]
admin-manage-permissions-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk common-document-library-web-part [entry]
common-document-library-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk common-iframe-web-part [entry]
common-iframe-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk fileSaver
chunk.fileSaver.js
C:\RespositoriesGit\CP\clientportalsharepoint\node_modules\file-saver\dist\FileSaver.min.js
error:0308010C:digital envelope routines::unsupported

ERROR in chunk home-about-web-part [entry]
home-about-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk home-banner-web-part [entry]
home-banner-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk home-documents-web-part [entry]
home-documents-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk home-links-web-part [entry]
home-links-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk home-marketing-web-part [entry]
home-marketing-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk home-page-web-part [entry]
home-page-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk home-videos-web-part [entry]
home-videos-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk pt-dashboard-web-part [entry]
pt-dashboard-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk pt-reports-web-part [entry]
pt-reports-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk pt-search-web-part [entry]
pt-search-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk site-create-web-part [entry]
site-create-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk site-request-site-web-part [entry]
site-request-site-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk site-select-web-part [entry]
site-select-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-carry-forward-web-part [entry]
ttc-carry-forward-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-compliance-summary-web-part [entry]
ttc-compliance-summary-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-dashboard-web-part [entry]
ttc-dashboard-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-documents-web-part [entry]
ttc-documents-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-filing-calendar-web-part [entry]
ttc-filing-calendar-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-notices-web-part [entry]
ttc-notices-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-on-demand-reports-web-part [entry]
ttc-on-demand-reports-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-prepayment-web-part [entry]
ttc-prepayment-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-rate-validation-web-part [entry]
ttc-rate-validation-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk ttc-tax-returns-web-part [entry]
ttc-tax-returns-web-part.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported

ERROR in chunk vendors~exceljs
chunk.vendors~exceljs.js
C:\RespositoriesGit\CP\clientportalsharepoint\node_modules\exceljs\dist\exceljs.min.js
error:0308010C:digital envelope routines::unsupported

ERROR in chunk vendors~html2canvas
chunk.vendors~html2canvas.js
C:\RespositoriesGit\CP\clientportalsharepoint\node_modules\html2canvas\dist\html2canvas.js
error:0308010C:digital envelope routines::unsupported

ERROR in chunk vendors~jspdf
chunk.vendors~jspdf.js
<EMAIL_ADDRESS>error:0308010C:digital envelope routines::unsupported
i ｢wdm｣: Failed to compile.
Issues checking in progress...
No issues found.

<EMAIL_ADDRESS>with the fix was published.
Please run npm update spfx-fast-serve-helpers or just install explicitly npm i<EMAIL_ADDRESS>then make sure that the right version is installed by running npm list spfx-fast-serve-helpers and checking that the version is 1.18.1. After that run and see if the issue is still reproducible.

@s-KaiNet Thanks for fixing the issue. It is working fine for me now after the update.

Thanks, will close the issue for now, if anybody still see this error, please feel free to reopen.

@s-KaiNet I can open a new issue is needed , but I am getting the same error, but only in node v18, fast-serve works fine in node 16. I upgraded my project from 1.17.4 to 1.18.2, then I updated fast serve helpers to 1.18.4, and when I run fast serve on node 16, all is well, but if I run on node 18, I get the error mentioned above. More details below:
node versions: 16.13.2 (works), 18.17.1 (does not work) 18.19.0 (does not work)
Error:

The error is referencing places where I am using require() to load an asset, such as an image that resides in the assets folder within the web part.
from node_modules in my project

I've also tried 1.18.7 of spfx-fast-serve-helpers and get the same error when on node 18. If there are any other details or screenshots I can provide, let me know.

@c-eiser13 do you still experience this issue?

@s-KaiNet, thanks for the follow up,  I've found a solution that is working for now. I had to add this to the serve command, without this line, I still get the error when trying to serve on node 18.

This post led me to this solution.

That's strange, because that exactly what I'm doing inside fast-serve in order to unlock node 18. I have a feeling that something wrong with your dependencies and you somehow install the old version of fast-serve. Have you tried deleting node_modules and package.json and reinstalling dependencies?

@s-KaiNet yes, I deleted node_modules and pnpm-lock.yaml many times, trying different versions of spfx-fast-serve-helpers. Could be something related to environment variables, I also tried this inside the glupfile, which did not work:

The only way it would work is if I manually ran that set command before running serve, or once I figured I could use that set command in the serve command within package.json. If you have any suggestions I could check further to see if it is something on my end, I'd be happy to. I'm currently running 1.18.4 of the -helpers.

Could you tell me what is your OS?

@s-KaiNet sorry, I'm on Windows 11 Pro

@c-eiser13 I'm also on W11 Pro, just out of curiosity, if you have time, could you clone this repository and try to run advanced sample. You just need to npm install and npm run serve. Will the error appear?
Could you also tell me the command line tool you use for running npm run serve command?

@s-KaiNet I am running Cmder and using NVM for node. I cloned the repo, installed deps and the project runs successfully. I even added a line in scss to load an image file from an assets folder using url() and it still runs correctly.
I went back and re-traced my steps and when I upgraded my project to 1.18.2, I did so on a fork, but thought I was on node 16. I still had the fork so went and was able to run serve command on node 18 without the set NODE_OPTIONS line. It is something on my end on my main project, if you have any other suggestions of where I can look, I will do so, otherwise using set in the serve command in package.json has me unblocked on node 18 for now. Appreciate your assistance!

@c-eiser13 maybe somehow the old version of spfx-fast-serve-helpers is used in your project, you can check the version installed by running npm list spfx-fast-serve-helpers. If it shows at least 1.18.4, then it should be ok. Otherwise I'm running out of ideas.

@s-KaiNet seems to be an issue with pnpm, if I install dependencies with npm, it runs fine. When I run npm list spfx-fast-serve-helpers, I get some errors regarding @pnp/spfx-controls-react and @pnp/spfx-property-controls requesting version 1.18.3 of spfx-fast-serve-helpers, but I also see these errors in my working fork, so not sure that is the root cause. I'm going to continue using the set command in my serve cmd in package.json until I have some more time to troubleshoot further. Appreciate all the feedback.


#1235 library, data, ... pop up external window

Implement override via 'pager' option

Yeah I know, yet another method on callback interface... We should get together and discuss perhaps calling by name or something. Doesn't want to get into reflection though.


Update pubspec.yaml

Update http version to the latest more than 1.0.0

updated to latest in https://github.com/lamsz/lamsz_quran_api/pull/21


Limit Rostam Jenkins jobs to marvin partition temporarily

Hoping to get some insight into why some slurm jobs never start...

Well, the results already show that the partition doesn't make a difference. There are two failed jobs on marvin now, and I've seen it happen on medusa before. Closing without merging.


💡 [REQUEST] -

[x] I am from GSSoC23.
[x] I would like to be assigned this task.

fill [x] to check the boxes.

Section
Description

Concise Description
Adding more resorces under devops

Code of Conduct
By submitting this issue, you agree to follow our Code of Conduct.

[x] I follow the Contributing Guidelines of this project.
[x] I have checked the current issues for duplicate problems.
[x] I have read the readme of this repository.

@Shreya111111 assigned


chore: fix typo

fixes #5

@nemorize Would you change https://github.com/abiriadev/seia/blob/main/packages/seia/README.md too?

Or you can allow me to push additional commits: GitHub doc

Oh, okay... wait for a minute 😊

Perfect! :+1:


Feat/update treesitter

I've been using this PR for a while, no crashes.

tree-sitter generate (with CLI 0.22.5) will bump a lot of this for you ;)

Still a failing npm install on windows. Any ideas @clason ? I'm out of ideas..

I'd try out https://github.com/tree-sitter/workflows, to be honest.
But first thoughts:

bump node to v20
let tree-sitter generate the bindings for you and test those.

(I don't use Windows myself so can't be of much help there specifically.)

Fixed #25 for me


Updated azure-cosmos logging to INFO level

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

Hi @moderakh - Thanks for your review! In the public repo, PRs need to be signed off by the author or another member of the content team, or by a PM for the service. Thanks.
@anfeldma-ms - Could you review the proposed changes to your article? Thanks.

#sign-off

#sign-off

Hi @anfeldma-ms - Thanks for your review and sign-off. @kirankumarkolli added a comment. Could you indicate whether we should merge the PR? Thanks.

#sign-off

@kirankumarkolli: I'm sorry - only the author of this article, @anfeldma-ms, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


请问支持P-tuning吗

Reminder

[X] I have read the README and searched the existing issues.

Reproduction
请问支持P-tuning吗
Expected behavior
请问支持P-tuning吗
System Info
No response
Others
No response

p-tuning后的模型泛化能力更好些，lora容易带偏了


Fix when PIPENV_SHELL is empty

After this commit the exception KeyError is no longer raised in case the env variable SHELL is missing.
This patch fixes the issue without making any changes in the current flow.
One might want to make this check earlier when PIPENV_SHELL is set at environments.py#L90 and then remove all validations of PIPENV_SHELL afterwards.

Thanks for your first contribution to pipenv @alercunha!  This looks good but I'm going to let @kennethreitz or @nateprewitt merge 👍

Thanks @erinxocon. My pleasure. Nice little project of yours, very useful. I'm here to help.

This seems fine to me since we've already been importing PIPENV_SHELL. Thanks for your contribution, @alercunha!


add hash to tarballs so additional samples can be produced for an exi…

…sting production tag

This would work as long as the sample_types are different from the sample_types of all the previous productions, right?

Yes, same sample types worked already before. I thought about this PR a bit more and I will implement it properly with multiple tarballs, split per era and sampletype to get a much cleaner implementation

@nshadskiy If you could have a look again, now KingMaker keeps track of which builds are already done, and provides one tarball per sample / era. If new / other samples are requested, now only builds that are not there yet will be rebuild. I tested it for various setups and did not encounter any problems

I think this looks fine.

feel free to approve and merge then :)


Can't set default tiling mode

I can't seem to set the default tiling mode with the -t flag regardless of where I launch the program (cmd.exe or a mintty bash shell or a startup service). I can change the tiling mode with mod + space but the default doesn't seem to work. Here's an example of my usage:
hashtwm.exe -t 2 -a mintty
Thanks for any help.

Hey Chad, I think this was broken in a previous commit, could you try the updated source/binary and see if that fixes it? Seems to work for me now.

Yep, that fixes it for me. Thanks for the quick response! I found another simple problem concerning toggling tiling modes but I'll make a new issue for it when I get a chance.


Auto-import IntelliSense of React components missing

Initial checklist

[X] I read the support docs
[X] I read the contributing guide
[X] I agree to follow the code of conduct
[X] I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions
MDX VS Code Extension v1.8.9
Link to runnable example
No response
Steps to reproduce
As noted in https://github.com/mdx-js/mdx-analyzer/issues/451#issuecomment-2196432076, the IntelliSense entries for auto-import of React components in .tsx files (auto-import in an .mdx file) are missing.

Clone the reproduction at https://github.com/karlhorky/repro-mdx-analyzer-missing-auto-import-intellisense
Install the 2 recommended extensions<EMAIL_ADDRESS>and<EMAIL_ADDRESS>(both enabled)
In app/message.mdx, move the cursor to the end ZoomImage and trigger IntelliSense with ctrl-space
Observe one entry in IntelliSense
Select this entry
Observe the import is added at the end of the file
Disable<EMAIL_ADDRESS>Move the cursor to the end ZoomImage and trigger IntelliSense with ctrl-space
Observe zero entries in IntelliSense

Version: 1.91.0-insider
Commit: aea213b7fcc7de5c24ad797ac1af209b159d451f
Date: 2024-06-28T06:02:58.030Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 23.5.0

Repo: https://github.com/karlhorky/repro-mdx-analyzer-missing-auto-import-intellisense
https://github.com/mdx-js/mdx-analyzer/assets/1935696/9dc9fded-14a3-490f-a94e-416c16fa2d0a
Expected behavior

One entry in the IntelliSense for ZoomImage when only<EMAIL_ADDRESS>installed
Selecting the entry should add the new import to the top of the code (also when<EMAIL_ADDRESS>enabled)

Saving the file with an import not in the import block at the top should move the import to the top of the file

Actual behavior

Zero entries in the IntelliSense for ZoomImage when only<EMAIL_ADDRESS>installed
(when<EMAIL_ADDRESS>enabled) selecting the entry adds the new import to the bottom of the code

Saving the file has no effect

Runtime
Node v20
Package manager
No response
OS
macOS
Build and bundle tools
Next.js
Potentially Related

https://github.com/mdx-js/mdx-analyzer/issues/413
https://github.com/mdx-js/mdx-analyzer/issues/56
https://github.com/mdx-js/mdx-analyzer/issues/165
https://github.com/mdx-js/mdx-analyzer/pull/226

I am getting a similar issue with the VSCode Intellicode extension turning off all hints from this extension


Contact Form: add validator for email field

That's old stuff.
You cannot reproduce the error? Fine. I close this issue.


Fix D_GGX code which can cause divide-by-zero

This revision Fix #56373.
When given roughness is lower than 0.01, d value in the original code will
be zero because of floating-point precision.
This can make the last return value NAN because of divide-by-zero.
Modified code is referenced on D_GGX function of google/filament
(https://github.com/google/filament/blob/main/shaders/src/brdf.fs#L54-L79)
Before

After

Thanks! And congrats for your first merged Godot contribution :tada:


LSP catching up

When parsing takes a few seconds and you type 5 characters, you get LSP feedback for each version, one at a time.
Instead I'd propose: Once a parsing job completes, fast forward all "file update" messages received in the interim (coalescing multiple single-character updates in one file, for example), and only start a new parsing job with the final versions?

This is fixed now (though I'm not certain the latest changes were released).

Published lsp v0.3.6 today.


[Property Request] Codeunit 63 Sales-Explode BOM - HideDialog

We need to explode BOM item in Sales Orders via Web Request and we can't perform a Manually Selection.
We found a CodeUnit 63 can help us to explode BOM but it need us to do manually selection on a poped-up Dialog .
We found the logic in the CodeUnit is just what we need when 'HideDialog ' is FALSE.
But unfortunately we can't set value to it.

Does it possible to add a function like 'SetHideDialog()' to let us set value for 'HideDialog '?
Thanks
Billy

You simply need to subscribe to event OnBeforeConfirmExplosion@2(VAR SalesLine@1000 : Record 37;VAR Selection@1001 : Integer;VAR HideDialog@1002 : Boolean) to set HideDialog.


Added how to offboard an employee in Hot Storage

couldn't get the Youtube link to work

here's the link to the video: https://www.youtube.com/watch?v=d_2N2CHyjPI


[sqlitecpp] update to 3.3.0

Fixes https://github.com/microsoft/vcpkg/issues/31670
Usage tested pass on x64-windows.
Tested all features on the following triplets:

x64-windows
x86-windows

[x] Changes comply with the maintainer guide
[x] SHA512s are updated for each updated download
[ ] The "supports" clause reflects platforms that may be fixed by this new version
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

IMO the port's two patches should be merged. It is all about using the unofficial sqlite config.


v0.2.3 Reorgaization

Comprehensive Analysis of Core Library Updates
Changes in ln_func_call.py
1. Function Implementations
lcall:

Now uses CoreLib.lcall instead of custom implementation.
Removed flatten and dropna parameters.
Added new parameters: retries, initial_delay, backoff_factor, default, timeout, timing, verbose, error_msg, error_map, max_concurrent, throttle_period.

mcall:

Switched to CoreLib.mcall.
Added explode parameter.
Removed custom logic for handling different input scenarios.

bcall, pcall, tcall, rcall:

All now use corresponding CoreLib methods.
Significant parameter changes to align with core implementations.

2. Class Changes
CallDecorator:

All methods now use CoreLib.CallDecorator implementations.
Removed custom Throttle class.
Deprecated timeout and default decorators.

3. Type Hinting and Imports

Updated to use more precise type hints, e.g., Callable[..., T].
Removed AsyncUtil and SysUtil imports, now relying on CoreLib.
Introduced LN_UNDEFINED from lion_core.

4. Deprecated and Removed Features

Removed alcall function.
Deprecated max_concurrency in favor of max_concurrent.

Changes in sys_util.py
1. Method Updates

time, copy, get_id, import_module, check_import, uninstall_package: Now use CoreUtil methods.
Removed get_bins method, replaced with TokenizeUtil.get_bins.

2. Deprecation Warnings

Updated all deprecation warnings from version 0.2.2 to 0.2.3.
Consistently mentioned removal in v1.0.0 for deprecated methods.

3. Documentation Updates

Updated docstrings to reflect new implementations and deprecations.
Changed error raising notations from ValueError to `ValueError` for consistency.

Implications and Considerations

API Changes:

Users will need to update function calls to match new parameter lists.
Some features (like flatten and dropna in lcall) are no longer directly supported.

Performance:

The shift to core library implementations may affect performance. Benchmarking is crucial.

Type Safety:

Improved type hinting may reveal type-related issues in existing code.

Dependency Management:

Stronger coupling with lion_core library. Version compatibility becomes more critical.

Migration Effort:

Significant changes may require substantial effort to update existing codebases.

Testing Requirements:

Comprehensive testing needed, especially for edge cases and performance-critical paths.
Backward compatibility tests are essential where possible.

Recommendations

Version Bumping: Consider a minor version increase (e.g., to 0.3.0) due to potential breaking changes.
Migration Guide: Develop a detailed migration guide highlighting changes in function signatures and behaviors.
Deprecation Timeline: Clearly communicate the timeline for removing deprecated features (v1.0.0).
Performance Analysis: Conduct thorough performance testing, especially for frequently used functions like lcall and mcall.
Documentation Update: Revise all relevant documentation to reflect new API structures and best practices.
Gradual Rollout: Consider a phased approach, potentially with a beta release, to gather user feedback and identify issues.

Open Questions

How will these changes affect existing CI/CD pipelines and automated tests?
Are there plans to provide compatibility layers or shims for easier migration?
What is the strategy for handling potential performance regressions?
How will these changes be communicated to the broader user community?

This PR represents a significant step towards a more unified and maintainable codebase, but careful consideration of its wide-ranging impacts is crucial for a smooth transition.

This pull request implements significant changes across multiple files, aligning the codebase with the new lion_core implementation. The changes focus on improving code structure, enhancing type safety, and leveraging the new core library functionality.
1. lionagi/libs/ln_filepath.py

Simplified clear_path method signature:

Combined parameters into a single line
Removed empty line between decorator and method definition

Removed an empty line in copy_file method
Added a newline at the end of the file

2. lionagi/libs/ln_import.py

Reformatted error message in install_import:

Split long line into multiple lines for better readability

Adjusted formatting in list_installed_packages:

Split list comprehension into multiple lines

Simplified _run_pip_command:

Combined arguments into a single line

Updated file path comment at the end of the file

3. lionagi/libs/ln_knowledge_graph.py

File completely removed

4. lionagi/libs/ln_nested.py

Major overhaul of the file:

Removed copyright header and replaced with a simpler import statement
Significantly reduced the number of functions
Replaced custom implementations with CoreLib functions from lion_core
Updated type hints to improve type safety and readability
Removed deprecated functions and updated documentation

Key changes:

nset, nget, nmerge, flatten, unflatten, nfilter, ninsert, and get_flattened_keys now use CoreLib implementations
Removed several helper functions that are now handled by CoreLib
Updated function signatures to align with CoreLib implementations

5. lionagi/libs/ln_parse.py

Extensive changes to the file:

Removed copyright header
Updated imports to use lion_core components
Replaced custom implementations with CoreLib functions
Added new type hints and updated existing ones
Deprecated several methods and added warnings

Key changes:

fuzzy_parse_json, fix_json_string, extract_json_block, extract_code_blocks, md_to_json now use CoreLib implementations
Deprecated StringMatch class and its methods
Added new function_to_schema method
Updated force_validate_keys and choose_most_similar to use CoreLib implementations

6. lionagi/libs/ln_queue.py

File completely removed

7. lionagi/libs/ln_validate.py

Removed extensive copyright and docstring comments at the beginning
Updated imports:

Removed specific imports from local modules
Added from lion_core import CoreLib

Modified function implementations to use CoreLib equivalents:

check_dict_field, check_action_field, check_enum_field
_fix_action_field, _fix_number_field, _fix_bool_field, _fix_str_field, _fix_enum_field

Replaced custom utility functions with CoreLib versions:

to_str, is_same_dtype, to_list, to_dict, to_num, strip_lower

Removed validation function dictionary at the end of the file

8. lionagi/os/operations/direct/init.py

Empty file removed

Impact and Considerations

API Changes: Many function signatures have changed, which may require updates in calling code.
Deprecations: Several methods and classes have been deprecated, with warnings added for future removal.
Dependency Shift: The codebase now heavily relies on lion_core, which may affect the overall package structure and dependencies.
Type Safety: Improved type hinting throughout the codebase, which may reveal type-related issues in existing code.
File Removals: The removal of ln_knowledge_graph.py and ln_queue.py may impact existing functionalities that depend on these modules.

Recommendations

Version Bump: Consider a minor version increase (e.g., to 0.3.0) due to the significant changes and potential breaking modifications.
Documentation Update: Comprehensive documentation updates are necessary to reflect the new API structure and usage patterns.
Migration Guide: Develop a detailed migration guide highlighting changes in function signatures, deprecated features, and new CoreLib usage.
Testing: Implement thorough testing, especially for the modified functions and their interactions with CoreLib.
Performance Analysis: Conduct performance testing to ensure that the shift to CoreLib implementations doesn't introduce unexpected performance regressions.

Next Steps

Review and update all import statements in the codebase to reflect the new structure.
Update unit tests to cover the new implementations and ensure backward compatibility where possible.
Create a changelog detailing the changes, especially noting the deprecated features and their planned removal timeline.
Consider a beta release to gather user feedback on the new structure and API changes.

This PR represents a significant step towards a more unified and maintainable codebase, leveraging the lion_core library for core functionalities. However, it introduces substantial changes that require careful review and testing to ensure a smooth transition for existing users.


NextJS Compression & Azure Web Sites

I'm unsure if this is the appropriate page for this, but given NextJS runs on Node.JS...
Azure Web Sites perform gzip compression. NextJS also performs gzip compression on compilation. This causes a double gzip compression which may throw net::ERR_HTTP2_PROTOCOL_ERROR 206 messages in the console when attempting to load the NextJS resources. This can lead to excessive (>75 second) page load times and/or page rendering failures.
I'd suggest adding this piece of NextJS documentation which outlines disabling NextJS gzip compression which solves this issue.
https://nextjs.org/docs/api-reference/next.config.js/compression
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 896b5d4c-ac3b-f0a2-5102-9e59bbe2ed48
Version Independent ID: 32fd9660-0d08-205c-c7f3-57b00f35e667
Content: Configure Node.js apps - Azure App Service
Content Source: articles/app-service/configure-language-nodejs.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@tseward
Thanks for your feedback! We will investigate and update as appropriate.

tseward, apologies for the delay.  Just to highlight, by default, compression is not enabled on Azure App Service Linux.
Since on App Services we don’t expose configuration to any platform components, this would need to be done through application.Users can enable this, as per their requirement. We have this article- Compression on App Service Linux
.

@AjayKumar-MSFT in this case, we were running App Service on Windows.

tseward, thanks for the additional info.  Thanks for bringing this to our attention. Your feedback has been shared with the content owner (@Cephalin) for further review, and update the document as appropriate.

#reassign:msangapu-msft

#reassign:msangapu-msft

Thank you for your feedback. I've added this into our backlog to update this article.
#please-close


remove label in ci

This will remove the label to run the CI after one run. This will safe cost in the long run.

ah, I somehow missed that you already tested it, that’s why I added and removed the label.


lightbox: Toggle wakelock while video is playing

Fixes: #763

Thanks for the review @chrisbobbe, pushed a new revision that includes tests using a helper function via ZulipBinding.

Also just pushed an added docs commit:
3c782cfdb binding [nfc]: Expand toggleWakelock doc to clarify what it does
with information I found from digging into the implementation of that package:wakelock_plus plugin.


feat: update server

Codecov Report
Base: 77.95% // Head: 80.61% // Increases project coverage by +2.66% :tada:

Coverage data is based on head (2d77dca) compared to base (b6fa647).
Patch coverage: 66.66% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #13      +/-   ##
==========================================
+ Coverage   77.95%   80.61%   +2.66%
==========================================
  Files          11       11
  Lines         694      748      +54
  Branches       77       86       +9
==========================================
+ Hits          541      603      +62
+ Misses        153      145       -8

Impacted Files
Coverage Δ

packages/dite/src/node/cli/commands.ts
63.63% <44.44%> (+8.75%)
:arrow_up:

packages/dite/src/node/server/index.ts
78.00% <67.34%> (ø)

packages/dite/src/shared/lib/tree-kill.ts
78.48% <100.00%> (+1.14%)
:arrow_up:

packages/dite/src/shared/lib/print-memory-usage.ts

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Current Missing/Erroneous Control Measure Symbols (And METOC)

Control Measure Symbols have been retested by @Dbarnes1 with current mil2525d.stylx as of 7/7/15 and these are the remaining symbols that aren't displaying or that have significant/major issues:

Fixed
Item
Feature Type
Symbol Name
Symbol Set
Entity
Draws Correctly
Issue(s)

- [x]
1
Point
Maneuver Points : Observation Post/Outpost (Specified) : Sensor Outpost/Listening Post
25
160204
N
This shape doesnt match with the diamond in 2525D

- [x]
2
Point
Maritime Points : Data Link Reference Point
25
213900
N
No circle in middle ins 2525D

- [x]
3
Point
Maritime Points : Enemy Point
25
214300
N
This is symbol for 214400- not 214300

- [x]
4
Point
Maritime Points : Position and Intended Movement (PIM) Route
25
217300
N
M instead of P in 2525D

- [x]
5
Point
Maritime Points : Point R Route
25
217500
N
P instead of R in 2525D

- [x]
6
Point
Protection Points : Antipersonnel Mine : With Directional Effects
25
280201
N
Multiple differences in arrow and line placement

- [x]
7
Point
Protection Points : Chemical Event
25
281300
N
Completely different symbols

- [x]
8
Point
Protection Points : Biological Event
25
281400
N
Completely different symbols

- [x]
9
Point
Protection Points : Nuclear Event
25
281500
N
Completely different symbol

- [x]
10
Point
Protection Points : Nuclear Fallout Producing Event
25
281600
N
Completely different symbol

- [x]
11
Line
Maneuver Lines : Forward Line of Troops : Friendly Planned or on Order
25
140102
N
Simply drawing straight line- should be more like 140101 but dashed

- [x]
12
Line
Maneuver Lines : Forward Line of Troops : Enemy Known
25
140103
N
Simply drawing straight line- should be curved like 140101

- [x]
13
Line
Maneuver Lines : Forward Line of Troops : Enemy Suspected or Templated
25
140104
N
Simply drawing straight line- should be more like 140100

- [x]
14
Line
Maneuver Lines : Forward Edge of the Battle Area : Proposed or On Order
25
140401
N
Simply drawing a straight line- doesnt match with 2525D

- [x]
15
Line
Maneuver Lines : Direction of Attack : Friendly Planned or On Order
25
140604
N
Simply straight line- should be more like 40603

- [x]
16
Line
Maneuver Lines : Direction of Attack : Enemy Confirmed
25
140606
N
Simply straight line- should have an arrow at the end

- [x]
17
Line
Maneuver Lines : Direction of Attack : Enemy Templated or Suspected
25
140607
N
Simply straight line- should be an arrow and a dotted line

- [x]
18
Line
Maneuver Areas : Axis of Advance : Supporting Attack Planned or On Order
25
151405
N
Simply straight line- should look more like 151404

- [x]
19
Line
Maneuver Areas : Axis of Advance : Enemy Confirmed
25
151407
N
Simply straight line

- [x]
20
Line
Maneuver Areas : Axis of Advance : Enemy Templated or Suspected
25
151408
N
Simply straight line

- [x]
21
Line
Air Corridors : Safe Lane
25
170400
N
Simply straight line- should be more like 170300

- [x]
22
Line
Air Corridors : Transit Corridor
25
170600
N
Simply straight line- should be more like 170500

- [x]
23
Line
Maritime Lines : Bearing Line : Electronic Warfare (EW)
25
220102
N
Simply straight line

- [x]
24
Line
Maritime Lines : Bearing Line : Acoustic (Ambiguous)
25
220104
N
Simply straight line

- [x]
25
Line
Maritime Lines : Bearing Line : Jammer
25
220107
N
Simply straight line

- [x]
26
Line
Maritime Lines : Bearing Line : Radio Direction Finder (RDF)
25
220108
N
Simply straight line

- [x]
27
Line
Deception : Decoy/Dummy/Feint
25
230200
N
Simply straight line

- [x]
28
Line
Fire Lines : Restrictive Fire Line
25
260500
N
Simply straight line

- [x]
29
Line
Protection Lines : Wire Obstacles : Single Concertina
25
290307
N
Simply straight line

- [x]
30
Line
Protection Lines : Mine Cluster
25
290400
N
Simply straight line

- [x]
31
Line
Intelligence Lines : Intelligence Coordination Line
25
300100
N
Simply straight line

- [x]
32
Line
Sustainment Lines : Main Supply Route : One Way Traffic
25
330301
N
Simply straight line

- [x]
33
Line
Sustainment Lines : Main Supply Route : Two Way Traffic
25
330302
N
Simply straight line

- [x]
34
Line
Sustainment Lines : Main Supply Route : Alternating Traffic
25
330303
N
Simply straight line

- [x]
35
Line
Sustainment Lines : Alternate Supply Route : One Way Traffic
25
330401
N
Simply straight red line

- [x]
36
Line
Sustainment Lines : Alternate Supply Route : Two Way Traffic
25
330402
N
Simply straight line

- [x]
37
Line
Sustainment Lines : Alternate Supply Route : Alternating Traffic
25
330403
N
Simply straight line

- [x]
38
Line
Maneuver Lines : Forward Edge of the Battle Area
25
140400
N
Wrong Symbol

- [x]
39
Line
Maneuver Lines : Forward Edge of the Battle Area : Proposed or On Order
25
140401
N
Simply drawing a straight line- doesnt match with 2525D

- [x]
40
Area
Maneuver Areas : Area : Friendly
25
150101
N
Simply gray square

- [x]
41
Area
Maneuver Areas : Area : Friendly Planned or On Order
25
150102
N
Simply gray square

- [x]
42
Area
Maneuver Areas : Area : Enemy Known or Confirmed
25
150103
N
Simply gray square

- [x]
43
Area
Maneuver Areas : Area : Enemy Suspected
25
150104
N
Simply gray square

- [x]
44
Area
Maneuver Areas : Occupied Assembly Area
25
150300
N
Simply gray square

- [x]
45
Area
Maneuver Areas : Proposed or On Order Assembly Area
25
150400
N
Simply gray square

- [x]
46
Area
Maneuver Areas : Action Area : Joint Tactical Action Area (JTAA)
25
150501
N
Simply gray square

- [x]
47
Area
Maneuver Areas : Limited Access Area
25
151100
N
Completely different symbols

- [x]
48
Area
Maneuver Areas : Encirclement : Enemy
25
151802
N
Simply gray square

- [x]
49
Area
Air Corridors : Unmanned Aircraft Restricted Operating Zone
25
171200
N
Simply gray square

- [x]
50
Area
Air Corridors : Fighter Engagement Zone
25
171400
N
Simply gray square

- [x]
51
Area
Air Corridors : Short Range Air Defense Engagement Zone
25
171900
N
Simply empty square

- [x]
52
Area
Maritime Areas : Defended Area : Rectangle
25
200202
N
Simply gray square

- [x]
53
Area
Maritime Areas : Ship Area of Interest
25
200400
N
Simply gray square

- [x]
54
Area
Maritime Areas : Ship Area of Interest : Ellipse/Circle
25
200401
N
Simply gray square

- [x]
55
Area
Maritime Areas : Ship Area of Interest : Rectangle
25
200402
N
Simply gray square

- [x]
56
Area
Maritime Areas : Active Maneuver Area
25
200500
N
Simply gray square

- [x]
57
Area
Maritime Areas : Cued Acquisition Doctrine
25
200600
N
Simply gray square

- [x]
58
Area
Maritime Areas : Radar Search Doctrine
25
200700
N
Simply gray square

- [x]
59
Area
Fires Areas : Airspace Coordination Area : Irregular
25
240101
N
Simply black square

- [x]
60
Area
Fires Areas : Airspace Coordination Area : Rectangular
25
240102
N
Simply black square

- [x]
61
Area
Fires Areas : Airspace Coordination Area : Circular
25
240103
N
Simply black square

- [x]
62
Area
Fires Areas : Restricted Fire Area : Irregular
25
240401
N
Missing RFA

- [x]
63
Area
Fires Areas : Restricted Fire Area : Rectangular
25
240402
N
Missing RFA

- [x]
64
Area
Fires Areas : Restricted Fire Area : Circular
25
240403
N
Missing RFA

- [x]
65
Area
Fires Areas : Area Targets : Rectangular Target - Single Target
25
240804
N
Simply gray square

- [x]
66
Area
Fires Areas : Fire Support Area : Irregular
25
241001
N
Simply black square

- [x]
67
Area
Fires Areas : Fire Support Area : Rectangular
25
241002
N
Simply black square

- [x]
68
Area
Fires Areas : Artillery Target Intelligence Zone : Irregular
25
241101
N
Simply black square

- [x]
69
Area
Fires Areas : Artillery Target Intelligence Zone : Rectangular
25
241102
N
Simply black square

- [x]
70
Area
Fires Areas : Artillery Target Intelligence Zone : Circular
25
241103
N
Simply gray square

- [x]
71
Area
Fires Areas : Call for Fire Area : Irregular
25
241201
N
Simply black square

- [x]
72
Area
Fires Areas : Call for Fire Area : Circular
25
241203
N
Simply gray square

- [x]
73
Area
Fires Areas : Critical Friendly Zone : Irregular
25
241401
N
Simply black square

- [x]
74
Area
Fires Areas : Critical Friendly Zone : Circular
25
241403
N
Simply gray square

- [x]
75
Area
Fires Areas : Target Build-up Area : Irregular
25
241701
N
Simply black square

- [x]
76
Area
Fires Areas : Target Build-up Area : Rectangular
25
241702
N
Simply black square

- [x]
77
Area
Fires Areas : Target Build-up Area : Circular
25
241703
N
Simply black square

- [x]
78
Area
Fires Areas : Target Value Area : Irregular
25
241801
N
Simply black square

- [x]
79
Area
Fires Areas : Target Value Area : Rectangular
25
241802
N
Simply black square

- [x]
80
Area
Fires Areas : Target Value Area : Circular
25
241803
N
Simply black square

- [x]
81
Area
Fires Areas : Zone of Responsibility : Irregular
25
241901
N
Simply black square

- [x]
82
Area
Fires Areas : Zone of Responsibility : Rectangular
25
241902
N
Simply black square

- [x]
83
Area
Fires Areas : Zone of Responsibility : Circular
25
241903
N
Simply black square

- [x]
84
Area
Fires Areas : Weapon/Sensor Range fan-Circular
25
242100
N
Simply gray square

- [x]
85
Area
Fires Areas : Weapon/Sensor Range fan-Sector
25
242200
N
Simply gray square

- [x]
86
Area
Fires Areas : Kill Box : Irregular-Blue
25
242301
N
Simply gray lines

- [x]
87
Area
Fires Areas : Kill Box : Rectangular-Blue
25
242302
N
Simply gray lines

- [x]
88
Area
Fires Areas : Kill Box : Circular-Blue
25
242303
N
Simply gray lines

- [x]
89
Area
Fires Areas : Kill Box : Irregular-Purple
25
242304
N
SImply gray lines

- [x]
90
Area
Fires Areas : Kill Box : Rectangular-Purple
25
242305
N
Simply gray lines

- [x]
91
Area
Fires Areas : Kill Box : Circular-Purple
25
242306
N
Simply gray lines

- [x]
92
Area
Protection Areas : Minefield : Completed
25
270701
N
Simply gray square

- [x]
93
Area
Protection Areas : Minefield : Planned
25
270702
N
Simply gray square

- [x]
94
Area
Protection Areas : Minefield : Known Enemy
25
270703
N
Simply gray square

- [x]
95
Area
Protection Areas : Minefield : Suspected or Templated Enemy
25
270704
N
Simply gray square

- [x]
96
Area
Protection Areas : Minefield : Dummy
25
270705
N
Simply gray square

- [x]
97
Area
Protection Areas : Minefield : Dynamic Depiction
25
270707
N
Simply green square

- [x]
98
Area
Protection Areas : Assault Crossing
25
271300
N
Simply gray square

- [x]
99
Area
Protection Areas : Biological Contaminated Area
25
271700
N
Completely different symbol

- [x]
100
Area
Protection Areas : Chemical Contaminated Area
25
271800
N
Completely different symbol

- [x]
101
Area
Protection Areas : Chemical Contaminated Area : Toxic Industrial Material
25
271801
N
Simply gray square

- [x]
102
Area
Protection Areas : Nuclear Contaminated Area
25
271900
N
Completely different symbol

- [x]
103
Area
Protection Areas : Radiological Contaminated Area
25
272000
N
Simply gray square

- [x]
104
Area
Protection Areas : Radiological Contaminated Area : Toxic Industrial Material
25
272001
N
Simply gray square

- [x]
105
Area
Protection Areas : Minimum Safe Distance Zone
25
272100
N
Simply gray square

- [x]
106
Area
Protection Areas : Radiation Dose Rate Contour Lines
25
272200
N
Completely different symbol

Pro Project should look similar to the following:

@Dbarnes1 - Great work! Thanks for bringing the solution forward.

List above updated from efforts I made right before UC and the runtime compatibility issue came to light. Once we get the issue fixed #104 there only remain a small number to fix.

After creating a test dataset for METOC points, lines, and areas, I came up with this list of 12 symbols that need to be fixed.

Fixed
SIDC
Name
Feature Type

- [ ]
45110202
Pressure Systems-High Pressure Center-Tropopause High
Atmospheric Point

- [ ]
45110505
Pressure Systems-Pressure Tendency-Steady
Atmospheric Point

- [ ]
46110304
Ice Systems-Dynamic Processes-Ice Drift (Direction)
Oceanographic Point

- [ ]
46120310
Hydrography-Ports and Harbors- Fish Wiers (Point)
Oceanographic Point

- [ ]
46120506
Hydrography-Dangers/Hazards-Kelp/Seaweed (Point)
Oceanographic Point

- [ ]
45110401
Pressure Systems-Lines-Through Axis
Atmospheric Line

- [ ]
45110408
Pressure Systems-Lines-Convergance Line
Atmospheric Line

- [ ]
45180700
Isopleths-Operator Defined-Freeform
Atmospheric Line

- [ ]
46120512
Hydrography-Dangers/Hazards-Reef
Oceanographic Line

- [ ]
45162004
Weather Symbols-Tropical Storm Systems-Tropical Storm Wind Areas and Date/Time Labels
Atmospheric Area

- [ ]
45171000
Bounded Areas of Weather-Operator Defined-Freeform
Atmospheric Area

- [ ]
46120507
Hydrography-Dangers/Hazards-Kelp/Seaweed (Area)
Oceanographic Area

List updated to reflect end of spring 9/2/15 with all Control Measure symbols rendering correctly. However, this issue should not yet be closed as the few incorrectly rendering METOC symbols should be addressed at some point.

Verified - METOC ones noted in the comments moved to #146


Migrate plannings page to material

 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.2 out of 3 committers have signed the CLA.:white_check_mark: sanioooook:white_check_mark: renemadsen:x: dependabot[bot]You have signed the CLA already but the status is still pending? Let us recheck it.


update install for new name/format of the release tgz

0.1.1 has iostio.tar.gz vs 0.1.0 istioctl.tar.gz
cc @sebastienvas

https://github.com/istio/istio.github.io/pull/180

I think the tar should have the directory name
also we should prune all the unnecessary dot and mac files (probably because @rshriram did the latest on manually on a mac ?)
-rw-r--r--  0 shriram staff      120 May 11 09:41 istio/install/._.DS_Store
-rw-r--r--  0 shriram staff     6148 May 11 09:41 istio/install/.DS_Store
-rwxr-x---  0 shriram staff      222 May 10 21:49 istio/install/._kubernetes
...

@rshriram created that tar. What do you mean by "the tar should have the directory name"?

Sorry my comment was not clear, updated
As we chatted with @andraxylia and @sebastienvas :

we'll put just the yaml and no mac specific or other extra files
we'll put istioctl binary in a bin/ subdirectory
the top level directory will be istio-X.Y.Z (aka have the version)
the archive names will be istio-osx.tar.gz istio-linux.tar.gz and istio_win.zip (with the version being in the parent directory of the url - ie : https://github.com/istio/istio/releases/download/${ISTIO_VERSION}/istio-${OSEXT}.tar.gz (PR #266 )

note: it may be good to repeat the version in the filename of the archive too if we ever have the releases in a single directory like usually done

to set the owner/group in the tar (can be any string) :
tar --owner=releng --group=releng -c -v -z -f  /tmp/blah.tar.gz ....


is there any way to run tmate using the standard MSYS2 environment set by msys2/setup-msys2@v2?

I running into a difficult situation where my action runs on windows using msys2/setup-msys2@v2, but tmate runs it's own mingw enviroment.
I'm using msys2/setup-msys2@v2 pip to install pywin32, but it's failing during the build. In tmate, when I run pip install pywin32, it finds it and installs correctly.
Is there any way to run tmate using msys2/setup-msys2@v2 environment instead?

Is there any way to run tmate using msys2/setup-msys2@v2 environment instead?

Not currently.
You could of course introduce support for a new input, say, msys2-root-directory, which would then be handled at the beginning of the run() function, for example like this:
if (process.platform === "win32") {
  process.env.MSYS2_ROOT = core.getInput("msys2-root-directory") || "C:\\msys64"
}

Then, in the call to the MSYS2 Bash, you would use that environment variable, something like this:
      spawn(`${process.env.MSYS2_ROOT}\\usr\\bin\\bash.exe", ["-lc", cmd], [...]

@hradec do you feel up to the task?

What about the WSL? :)


Misalignment in Multiple Choice Task

Multiple choice task radio buttons are not properly aligned. They appear to be centered between the header and the continue button, but they should be top aligned.

Obsolete issue.


Re-size/orientation change with background images

Hi,
When I use b-lazy to lazy load a background image set as data-src this works well. But my site is responsive so I am specifying data-src (default e.g. 320px or should that be the largest?), medium (770px) and large (> 771). When I re-size or re-orientate the device, the new image is not being used - only the one used first time is applied.
Also the data-src attributes are destroyed when b-lazy has finished applying.
My div:
<div class="b-lazy" src="placeholder.jpg"
     data-src-medium="/images/600/Specifications.jpg')"
     data-src-large="images/template/landingpage/features/980/Specifications.jpg">
</div>

My java script:
<script type="text/javascript">
        jQuery(document).ready(function($j) {
            var bLazy = new Blazy({
                breakpoints: [
                {
                    width: 770, // max-width
                    src: 'data-src-medium',
                    mode: 'viewport'
                },
                {
                    width: 99999, // max-width
                    src: 'data-src-large',
                    mode: 'viewport'
                }],
                selector: 'img,.b-lazy', // all images
                offset: 200 // Loads images 200px before they're visible
            });
        });
    </script>

I tried the following, but as of yet have been unable to get it to work:
var isIOS = /safari/g.test(navigator.userAgent.toLowerCase());
            var ev = isIOS ? 'orientationchange' : 'resize';
            var diff = (window.innerWidth-window.innerHeight);
            $j(window).bind(ev,function(){
                setTimeout(function(){
                    if(diff*((window.innerWidth-window.innerHeight)) < 0)
                        orientationChanged();
                }, 500);
            });

            function orientationChanged() {
                console.log("orientation changed");
                $j('div.b-lazy').removeClass('b-loaded');
                bLazy.revalidate();
            }

Hey Craig.
The breakpoints are defined by the device width not the browser width. It means that it’ll look at your screen width which won’t change when you resize your browser window. You can emulate device widths in chrome: https://developers.google.com/chrome-developer-tools/docs/mobile-emulation#enable-emulation-panel.
The reason why I’m looking at the device width and not the width is that I don’t want to load multiple image sources for the same image when you resize (multiple server request per image). And if you have a big screen but the start width of your browser window is something small I don’t want to upscale a low res image if you resize it up.
Hope it make sense :)
Bjørn

@dinbror Hi, that makes perfect sense. The only issue in our application is when a customer re-sizes their browser it would mean missing images. Would it be possible to make this a configurable option so we can do it either way?

This won't work well in case of changing of orientation on tablets. Script should try to reload images in case of width changes, otherwise you might switch from portrait to landscape view and find yourself in quite sad situation.


Short solution needed: "Write JSON to log" (nginx-lua)

Please help us write most modern and shortest code solution for this issue:
Write JSON to log (technology: nginx-lua)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

How to write JSON to log


vcpkg fails to build on latest nightly: "readme file with name '../README.md' was not found"

vcpkg, one of the packages built by naersk specifies a README located outside its crate directory, in its wider cargo workspace root. It appears that naersk didn't catch that.
error: failed to get `clap` as a dependency of package `cign v0.1.0 (/build/dummy-src)`

Caused by:
  failed to load source for dependency `clap`

Caused by:
  Unable to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to update replaced source registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to parse manifest at `/nix/store/ybindkbcy3d74hyjcc3kpygkdmdf8cwm-crates-io/vcpkg-0.2.9/Cargo.toml`

Caused by:
  readme file with name '../README.md' was not found
[naersk] cargo returned with exit code 101, exiting
builder for '/nix/store/b1j64hn8p0mgxjnb7nsbcrfqx2x7pjqj-cign-deps-0.1.0.drv' failed with exit code 101
cannot build derivation '/nix/store/grrd3cb3y8pdx60w9nhzrwmj14jm1nkq-cign-0.1.0.drv': 1 dependencies couldn't be built
error: build of '/nix/store/grrd3cb3y8pdx60w9nhzrwmj14jm1nkq-cign-0.1.0.drv' failed

After prodding this some more cargo-tree tells me that I don't depend on vcpkg and it fails all the same no matter which dependency I remove from my Cargo.toml. Pinning an older nightly worked as a workaround.

Hi, could you give more details? I've managed to build the package with this setup:
 $  niv add NixOS/nixpkgs -b release-20.03
 $  niv add mcgoo/vcpkg-rs
 $  niv add nmattia/naersk

# default.nix
let
  sources = import ./nix/sources.nix;
  pkgs = import sources.nixpkgs {};
  naersk = pkgs.callPackage sources.naersk {};
in
  naersk.buildPackage sources.vcpkg-rs

building '/nix/store/g7ws0pszjllciz5n1wh9k7q05b0lslhr-rust-workspace-deps-unknown.drv'...
unpacking sources
unpacking source archive /nix/store/30w3x1f3c8gjybfh0sywr6dcvkqcqv1q-dummy-src
source root is dummy-src
patching sources
configuring
[naersk] cargo_version (read): 1.41.0
[naersk] cargo_message_format (set): json-diagnostic-rendered-ansi
[naersk] cargo_release: --release
[naersk] cargo_options: -Z unstable-options
[naersk] cargo_build_options: $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
[naersk] cargo_test_options: $cargo_release -j "$NIX_BUILD_CORES"
[naersk] RUST_TEST_THREADS: 8
[naersk] cargo_bins_jq_filter: .
[naersk] cargo_build_output_json (created): /build/tmp.RqKjupThO8
[naersk] crate_sources: /nix/store/cgas0klk8czpj2qzbr1af3vz0skwhflw-crates-io
[naersk] RUSTFLAGS:
[naersk] CARGO_BUILD_RUSTFLAGS:
[naersk] CARGO_BUILD_RUSTFLAGS (updated): --remap-path-prefix /nix/store/cgas0klk8czpj2qzbr1af3vz0skwhflw-crates-io=/sources
building
cargo -Z unstable-options build $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
   Compiling proc-macro2 v1.0.15
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.23
   Compiling version_check v0.9.2
   Compiling libc v0.2.71
   Compiling serde v1.0.110
   Compiling unicode-width v0.1.5
   Compiling ryu v1.0.4
   Compiling vcpkg v0.2.10 (/build/dummy-src/vcpkg)
   Compiling vec_map v0.8.1
   Compiling ansi_term v0.11.0
   Compiling unicode-segmentation v1.6.0
   Compiling strsim v0.8.0
   Compiling bitflags v1.0.3
   Compiling itoa v0.4.5
   Compiling semver-parser v0.7.0
   Compiling anyhow v1.0.31
   Compiling vcpkg_cli v0.2.4 (/build/dummy-src/vcpkg_cli)
   Compiling cargo-vcpkg v0.1.5 (/build/dummy-src/cargo-vcpkg)
   Compiling termcolor v1.1.0
   Compiling textwrap v0.11.0
   Compiling heck v0.3.1
   Compiling quote v1.0.6
   Compiling atty v0.2.14
   Compiling proc-macro-error-attr v0.4.12
   Compiling proc-macro-error v0.4.12
   Compiling clap v2.33.1
   Compiling syn-mid v0.5.0
   Compiling serde_derive v1.0.110
   Compiling structopt-derive v0.4.0
   Compiling structopt v0.3.7
   Compiling semver v0.9.0
   Compiling serde_json v1.0.53
   Compiling cargo_metadata v0.10.0
    Finished release [optimized] target(s) in 1m 50s
installing
/*stdin*\            : 31.29%   (83937280 => 26267801 bytes, /nix/store/gpcfaxkykzd3jzmp10xvb0ch01vz52g4-rust-workspace-deps-unknown/target.tar.zst)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/gpcfaxkykzd3jzmp10xvb0ch01vz52g4-rust-workspace-deps-unknown
strip is /nix/store/hrkc2sf2883l16d5yq3zg0y339kfw4xv-binutils-2.31.1/bin/strip
patching script interpreter paths in /nix/store/gpcfaxkykzd3jzmp10xvb0ch01vz52g4-rust-workspace-deps-unknown
checking for references to /build/ in /nix/store/gpcfaxkykzd3jzmp10xvb0ch01vz52g4-rust-workspace-deps-unknown...
building '/nix/store/gy88ky3h50r2h4p48j9ifqlia4wms6j0-rust-workspace-unknown.drv'...
unpacking sources
unpacking source archive /nix/store/j94n74091gw05rq1ifb0px2jb35mcd0h-vcpkg-rs-src
source root is vcpkg-rs-src
patching sources
configuring
[naersk] cargo_version (read): 1.41.0
[naersk] cargo_message_format (set): json-diagnostic-rendered-ansi
[naersk] cargo_release: --release
[naersk] cargo_options: -Z unstable-options
[naersk] cargo_build_options: $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
[naersk] cargo_test_options: $cargo_release -j "$NIX_BUILD_CORES"
[naersk] RUST_TEST_THREADS: 8
[naersk] cargo_bins_jq_filter: select(.reason == "compiler-artifact" and .executable != null and .profile.test == false)
[naersk] cargo_build_output_json (created): /build/tmp.VvXGBhkwqY
[naersk] crate_sources: /nix/store/cgas0klk8czpj2qzbr1af3vz0skwhflw-crates-io
[naersk] RUSTFLAGS:
[naersk] CARGO_BUILD_RUSTFLAGS:
[naersk] CARGO_BUILD_RUSTFLAGS (updated): --remap-path-prefix /nix/store/cgas0klk8czpj2qzbr1af3vz0skwhflw-crates-io=/sources
[naersk] pre-installing dep /nix/store/gpcfaxkykzd3jzmp10xvb0ch01vz52g4-rust-workspace-deps-unknown
building
cargo -Z unstable-options build $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
   Compiling vcpkg v0.2.10 (/build/vcpkg-rs-src/vcpkg)
   Compiling cargo-vcpkg v0.1.5 (/build/vcpkg-rs-src/cargo-vcpkg)
   Compiling vcpkg_cli v0.2.4 (/build/vcpkg-rs-src/vcpkg_cli)
    Finished release [optimized] target(s) in 9.82s
installing
[naersk] Using file /build/tmp.VvXGBhkwqY to retrieve build (executable) products
[naersk] found executable vcpkg_cli -> /nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown/bin/vcpkg_cli
[naersk] found executable cargo-vcpkg -> /nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown/bin/cargo-vcpkg
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown
shrinking /nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown/bin/cargo-vcpkg
shrinking /nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown/bin/vcpkg_cli
strip is /nix/store/hrkc2sf2883l16d5yq3zg0y339kfw4xv-binutils-2.31.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown/bin
patching script interpreter paths in /nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown
checking for references to /build/ in /nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown...
/nix/store/d47rg1vgm8qqs42b9mjmajsywvsri0cf-rust-workspace-unknown

I am getting this issue on a private repository with some private submodules.
The path, however, is absolute and does appear in the nix store.
error: failed to read `/nix/store/q3z3s15xr0rvbbhjhkj51ggkyjrfjz80-source/Cargo.toml`
error: failed to read `/nix/store/q3z3s15xr0rvbbhjhkj51ggkyjrfjz80-source/Cargo.toml`

Caused by:
Caused by:
  No such file or directory (os error 2)
  No such file or directory (os error 2)
[naersk] cargo returned with exit code 101, exiting
[naersk] cargo returned with exit code 101, exiting

Wondering if there's an easy way to get a minimal reproducible example...

I believe I also encountered this error. For me it's with a submodule:
builder for '/nix/store/m2c7hpwrcpaky8wj13srd87xj212bk62-harmony_rust_sdk-0.2.1.drv' failed with exit code 101; last 10 log lines:
     Compiling tonic-build v0.3.1
     Compiling harmony_rust_sdk v0.2.1 (/build/source)
  error: failed to run custom build command for `harmony_rust_sdk v0.2.1 (/build/source)`

  Caused by:
    process didn't exit successfully: `/build/source/target/debug/build/harmony_rust_sdk-e1bf2448e7cea35d/build-script-build` (exit code: 101)
    --- stderr
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "protoc failed: protocol: warning: directory does not exist.\nCould not make proto path relative: harmonytypes/v1/types.proto: No such file or directory\n" }', build.rs:30:10
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  [naersk] cargo returned with exit code 101, exiting

where protocol is a submodule in my root (src is the same).
You can see the issue by cloning https://github.com/harmony-development/harmony_rust_sdk, switching to the ci/nix branch and building with nix build .#harmony_rust_sdk-tests -L (or nix-build nix/default.nix). Dev shell setups cachix cache so it will be faster if you do it within the shell.

I believe I also encountered this error. For me it's with a submodule:
builder for '/nix/store/m2c7hpwrcpaky8wj13srd87xj212bk62-harmony_rust_sdk-0.2.1.drv' failed with exit code 101; last 10 log lines:
     Compiling tonic-build v0.3.1
     Compiling harmony_rust_sdk v0.2.1 (/build/source)
  error: failed to run custom build command for `harmony_rust_sdk v0.2.1 (/build/source)`

  Caused by:
    process didn't exit successfully: `/build/source/target/debug/build/harmony_rust_sdk-e1bf2448e7cea35d/build-script-build` (exit code: 101)
    --- stderr
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "protoc failed: protocol: warning: directory does not exist.\nCould not make proto path relative: harmonytypes/v1/types.proto: No such file or directory\n" }', build.rs:30:10
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  [naersk] cargo returned with exit code 101, exiting

where protocol is a submodule in my root (src is the same).
You can see the issue by cloning https://github.com/harmony-development/harmony_rust_sdk, switching to the ci/nix branch and building with nix build .#harmony_rust_sdk-tests -L (or nix-build nix/default.nix). Dev shell setups cachix cache so it will be faster if you do it within the shell.

Hi, sorry for the delay. Is there any chance you can provide a minimal reproducible example? harmony_rust_sdk is fairly big

Hi, sorry for the delay. Is there any chance you can provide a minimal reproducible example? harmony_rust_sdk is fairly big

Sure, I will make a repo with an MRE.

I have made a minimal example https://github.com/yusdacra/naersk_bug here. Just clone it and switch to the submodule branch. My Nix version is 2.4pre20210326_dd77f71 and the nixpkgs I used is on commit 6fc2b7ecc2a167ce6a6902d5417daf1fa5cac777.
mre_naersk> unpacking sources
mre_naersk> unpacking source archive /nix/store/ljam2qj5af3cyhc00mf4yspaipz1cc5l-source
mre_naersk> source root is source
mre_naersk> patching sources
mre_naersk> configuring
mre_naersk> [naersk] cargo_version (read): 1.50.0
mre_naersk> [naersk] cargo_message_format (set): json-diagnostic-rendered-ansi
mre_naersk> [naersk] cargo_release: --release
mre_naersk> [naersk] cargo_options: -Z unstable-options
mre_naersk> [naersk] cargo_build_options: $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
mre_naersk> [naersk] cargo_test_options: $cargo_release -j "$NIX_BUILD_CORES"
mre_naersk> [naersk] RUST_TEST_THREADS: 4
mre_naersk> [naersk] cargo_bins_jq_filter: select(.reason == "compiler-artifact" and .executable != null and .profile.test == false)
mre_naersk> [naersk] cargo_build_output_json (created): /build/tmp.P3yhtVvSPD
mre_naersk> [naersk] crate_sources: /nix/store/ipgwnyr55zyrm71fkjj27b51gh8qynhy-crates-io
mre_naersk> [naersk] RUSTFLAGS:
mre_naersk> [naersk] CARGO_BUILD_RUSTFLAGS:
mre_naersk> [naersk] CARGO_BUILD_RUSTFLAGS (updated): --remap-path-prefix /nix/store/ipgwnyr55zyrm71fkjj27b51gh8qynhy-crates-io=/sources
mre_naersk> [naersk] pre-installing dep /nix/store/kzq6cab2rzwb6hyy9681slv2vwxnyzc4-mre_naersk-deps-0.1.0
mre_naersk> building
mre_naersk> cargo -Z unstable-options build $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
mre_naersk>    Compiling mre_naersk v0.1.0 (/build/source)
mre_naersk> error: failed to run custom build command for `mre_naersk v0.1.0 (/build/source)`
mre_naersk> Caused by:
mre_naersk>   process didn't exit successfully: `/build/source/target/release/build/mre_naersk-265e47b6b59688af/build-script-build` (exit code: 101)
mre_naersk>   --- stderr
mre_naersk>   thread 'main' panicked at 'can't compile protos: Custom { kind: Other, error: "protoc failed: Could not make proto path relative: protocol/harmonytypes/v1/types.proto: No such file or directory\n" }', build.rs:2:92
mre_naersk>   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
mre_naersk> [naersk] cargo returned with exit code 101, exiting
error: builder for '/nix/store/jkc43r04k3871lrs1fym54bgim2mlyr9-mre_naersk-0.1.0.drv' failed with exit code 101;
       last 10 log lines:
       > cargo -Z unstable-options build $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
       >    Compiling mre_naersk v0.1.0 (/build/source)
       > error: failed to run custom build command for `mre_naersk v0.1.0 (/build/source)`
       >
       > Caused by:
       >   process didn't exit successfully: `/build/source/target/release/build/mre_naersk-265e47b6b59688af/build-script-build` (exit code: 101)
       >   --- stderr
       >   thread 'main' panicked at 'can't compile protos: Custom { kind: Other, error: "protoc failed: Could not make proto path relative: protocol/harmonytypes/v1/types.proto: No such file or directory\n" }', build.rs:2:92
       >   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
       > [naersk] cargo returned with exit code 101, exiting
       For full logs, run 'nix log /nix/store/jkc43r04k3871lrs1fym54bgim2mlyr9-mre_naersk-0.1.0.drv'.

I have made a minimal example yusdacra/naersk_bug here. Just clone it and switch to the submodule branch. My Nix version is 2.4pre20210326_dd77f71 and the nixpkgs I used is on commit 6fc2b7ecc2a167ce6a6902d5417daf1fa5cac777.
mre_naersk> unpacking sources
mre_naersk> unpacking source archive /nix/store/ljam2qj5af3cyhc00mf4yspaipz1cc5l-source
mre_naersk> source root is source
mre_naersk> patching sources
mre_naersk> configuring
mre_naersk> [naersk] cargo_version (read): 1.50.0
mre_naersk> [naersk] cargo_message_format (set): json-diagnostic-rendered-ansi
mre_naersk> [naersk] cargo_release: --release
mre_naersk> [naersk] cargo_options: -Z unstable-options
mre_naersk> [naersk] cargo_build_options: $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
mre_naersk> [naersk] cargo_test_options: $cargo_release -j "$NIX_BUILD_CORES"
mre_naersk> [naersk] RUST_TEST_THREADS: 4
mre_naersk> [naersk] cargo_bins_jq_filter: select(.reason == "compiler-artifact" and .executable != null and .profile.test == false)
mre_naersk> [naersk] cargo_build_output_json (created): /build/tmp.P3yhtVvSPD
mre_naersk> [naersk] crate_sources: /nix/store/ipgwnyr55zyrm71fkjj27b51gh8qynhy-crates-io
mre_naersk> [naersk] RUSTFLAGS:
mre_naersk> [naersk] CARGO_BUILD_RUSTFLAGS:
mre_naersk> [naersk] CARGO_BUILD_RUSTFLAGS (updated): --remap-path-prefix /nix/store/ipgwnyr55zyrm71fkjj27b51gh8qynhy-crates-io=/sources
mre_naersk> [naersk] pre-installing dep /nix/store/kzq6cab2rzwb6hyy9681slv2vwxnyzc4-mre_naersk-deps-0.1.0
mre_naersk> building
mre_naersk> cargo -Z unstable-options build $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
mre_naersk>    Compiling mre_naersk v0.1.0 (/build/source)
mre_naersk> error: failed to run custom build command for `mre_naersk v0.1.0 (/build/source)`
mre_naersk> Caused by:
mre_naersk>   process didn't exit successfully: `/build/source/target/release/build/mre_naersk-265e47b6b59688af/build-script-build` (exit code: 101)
mre_naersk>   --- stderr
mre_naersk>   thread 'main' panicked at 'can't compile protos: Custom { kind: Other, error: "protoc failed: Could not make proto path relative: protocol/harmonytypes/v1/types.proto: No such file or directory\n" }', build.rs:2:92
mre_naersk>   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
mre_naersk> [naersk] cargo returned with exit code 101, exiting
error: builder for '/nix/store/jkc43r04k3871lrs1fym54bgim2mlyr9-mre_naersk-0.1.0.drv' failed with exit code 101;
       last 10 log lines:
       > cargo -Z unstable-options build $cargo_release -j "$NIX_BUILD_CORES" --out-dir out --message-format=$cargo_message_format
       >    Compiling mre_naersk v0.1.0 (/build/source)
       > error: failed to run custom build command for `mre_naersk v0.1.0 (/build/source)`
       >
       > Caused by:
       >   process didn't exit successfully: `/build/source/target/release/build/mre_naersk-265e47b6b59688af/build-script-build` (exit code: 101)
       >   --- stderr
       >   thread 'main' panicked at 'can't compile protos: Custom { kind: Other, error: "protoc failed: Could not make proto path relative: protocol/harmonytypes/v1/types.proto: No such file or directory\n" }', build.rs:2:92
       >   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
       > [naersk] cargo returned with exit code 101, exiting
       For full logs, run 'nix log /nix/store/jkc43r04k3871lrs1fym54bgim2mlyr9-mre_naersk-0.1.0.drv'.

Apparently the cause of this was that git submodules were not being put in source because of flakes. The workaround is to use builtins.fetchGit to fetch source from your repository (and keeping an input for it in your inputs). Like so:
{
	inputs.selfDup = {
		url = "<url>";
		flake = false;
	};

	outputs = inputs: {
		#...
		# then in source fetching
		src = builtins.fetchGit {
			url = "<url>";
			rev = inputs.selfDup.rev;
			allRefs = true; # make sure all branches will work
			submodules = true;
		};
		#...
	};
}


Jetbrains chat text keyboard shortcuts not working

Before submitting your bug report

[x] I believe this is a bug. I'll try to join the Continue Discord for questions
[x] I'm not able to find an open issue that reports the same bug
[x] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
broke in 0.0.77

Description
@fRonin on discord
Windows 11, PyCharm 2024.2.4 newest.
I have updated to the latest stable version of the JetBrains plugin (currently 0.0.77).
Previously, the Ctrl+Shift+Left/Right arrow keys (for selecting whole words) worked fine in the session message box.
In version 0.0.77, this functionality no longer works. However, "Select All," "Home/End," and other shortcuts still function correctly.
*Actualy, non of the ctrl+arrow shortcuts work
To reproduce
No response
Log output
No response

Copy / Paste / Cut is also broken on the chat interface

Some extra info on replicating this issue:
I'm having the same issue. I'm using Ubuntu with custom key bindings. I suspect that some of the hotkeys are being remapped or hijacked once the continue plugin window becomes active (in particular, the ctrl key). If I hide the window or stop the plugin, the keys start working again. I can tell it's not all the command keys because holding alt toggles the @codebase / Active file shortcut.

Having this issue also on both my Windows devices on multiple jetbrains apps (ws/ps/pc) latest releases for all (0.77-0.80 for plug-in)
Interestingly I can use ctrl-c on any code block, but not on general text.
Also ctrl-backspace is acting like ctrl-shift-backspace. Like it's holding shift down as well?

Hi all, we're recommending folks downgrade to 0.0.75 at the moment. Please see this main issue for details: https://github.com/continuedev/continue/issues/2956


Cannot pickle dask array objects

What happened:
Attempting to pickle a dask array gives:
AttributeError: Can't pickle local object 'broadcast_trick.<locals>.inner'

Dask arrays are no longer pickleable since v2.23.0.
What you expected to happen:
The dask array can be pickled.
Minimal Complete Verifiable Example:
import dask.array
import pickle
a = dask.array.ones((10, 10))
pickle.dumps(a)

This fails on versions larger than v2.22.
Anything else we need to know?:
I am happy to fix this. It seems like a simple fix to move the inner function to the module level.
Environment:

Dask version: 2.25.0
Python version: 3.7.7
Operating System: Mac OS X
Install method (conda, pip, source): pip

It seems like a simple fix to move the inner function to the module level.

That should make things serializable with pickle. Though there may be some restrictions on the signature of the function that broadcast_trick returns
Alternatively, does using cloudpickle work for your use case?

cloudpickle does work, so I could probably use it. However if the simple fix works, it would be nice to fix normal pickle.

Ah, sorry I don't think I was very clear in my previous comment. A fix to make things serializable with pickle is very welcome. I meant to propose using cloudpickle as a workaround.


Created a new branch off main to add prettier auto-format and eslint test pre-commit

The old pull request was #27.
The related issue is #15.
In this pull request, I added more rules to nextjs as the rules provided were not enough. The rules I added were eslint recommended, react recommended, typescript, typescript type checking, prettier, and tailwind.
The other thing that was added was adding husky + lint-staged to run prettier auto-format and eslint test pre-commit (when you run "git commit" locally, prettier and eslint will run). If the eslint tests fails, git commit will be aborted.

A new branch was made as there were too many merge conflicts in #27 since we last migrated to NextJS, so a new branch was created.


Avoid saving charts to filesystem

Why not? I think, to save chart localy is not bad idea. Maybe add it as optional parameter?

Why not? I think, to save chart localy is not bad idea. Maybe add it as optional parameter?

potential issues:

permissions management (java-process may be run under user who don't have permissions to write to filesystem or to the folder where the process is running from)
performance: IO operations loading data from FS and flushing data to FS (this point could be considered as insignificant for this utility, but if there is a chance to avoid peformance drawbacks, why not to do it)
differences in FS management for different OS and environments (e.g., containerised infrastructure) - however that's not yet an issue for the library
non-transparent logic: it's hard to follow the library logic when file is created in one part of the project and then referenced by its name in another part - however it's a project specific issue and it could be resolved in another way


In rerun mode start time should be reset

Otherwise, we have this:

if it will be reproduced, could be reopened


Missing processing wheel in changing passcode/biometrics flow

Bug Description
While changing passcode/biometrics and after having entered the new passcode twice, the app gets unresponsive for a long time (up to 20 seconds for wallet with many accounts on iPhone 11) without any waiting indication for the user. It’s very unclear what is going on during that period. We should have a waiting wheel. Preferably the “use full password instead” button should be deactivated, as it is sometimes possible to enter that menu while waiting and that flow will then be interrupted when the password change gets into effect.
Steps to Reproduce

enter the "change passcode"flow
enter new password
enter new password
if possible click on "use full password instead"

Expected Result
Waiting wheel indicates processing time. Button "use full password instead" cannot be pressed.
Actual Result
App is unresponsive. It might be possible to enter the "use full password instead" flow.
Versions

1.0.22
iOS 14.7
iPhone 11

This seems to work on iOS 15, but probably good to check on iOS 14 as well. @concordium-cl

Checked on iOS 14.7.1.
Fixed in 1.0.23


Nav-component content is not projected

Ionic version:  (check one with "x")
[ ] 1.x
[x ] 2.x
I'm submitting a ...  (check one with "x")
[ ] bug report
[x ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://forum.ionicframework.com/ or http://ionicworldwide.herokuapp.com/
Current behavior:
In order to have a "global" element across different pages that slides out with the currently selected page when animating the menu in, I want to add a new element/component in the nav-component like this:
<ion-nav [root]="rootPage" #content swipeBackEnabled="false">

Media player

</ion-nav>

This code disappears in the compiled HTML output.
Expected behavior:
Code added here should be projected to be able to add elements/components on the DOM level of the displayed page.
Related code:
Adding an ng-content directive to the nav-component template would solve this.
Other information:
I will create a pull request for this issue.

I created the following pull request:
https://github.com/driftyco/ionic/pull/10705

Thanks for the issue and the PR! We will look into this.


add ActiveRecord::Calculations module to ActiveRecord::Base

I wanted to use ActiveRecord::Calculations methods like User.count as class methods of the model, so added code to extend ActiveRecord::Calculations module in ActiveRecord::Base.

Thank you for your contribution.
Unfortunately, this is not correct. ActiveRecord::Base does not extend ActiveRecord::Calculations directly.
The reason why ActiveRecord::Base provides the .count method is ActiveRecord::Querying.
It delegates tons of methods to the .all method.
You can see the .count method in the list:
https://github.com/rails/rails/blob/v8.0.0/activerecord/lib/active_record/querying.rb#L19
Therefore, extending the Calculation module in this class is not good.
Instead, in activerecord.rbs, we list such methods up to ActiveRecord::Base::ClassMethods and _ActiveRecord_Relation_ClassMethods.
https://github.com/ruby/gem_rbs_collection/blob/443b2934235be3a76b9022b21764d06429ac6d7e/gems/activerecord/6.0/activerecord.rbs#L422
https://github.com/ruby/gem_rbs_collection/blob/443b2934235be3a76b9022b21764d06429ac6d7e/gems/activerecord/6.0/activerecord.rbs#L590

@tk0miya
Thanks for the review! I understand!
I will close this PR once I have implemented the type definitions based on the information you gave me, and I will remake the PR again once I have implemented the type definitions.


[New azd-template] servicebus-dotnet-functionapp

New azd-template Submission
Fill in the sections below to populate a new gallery card for your template. All fields are mandatory unless explicitly identified as optional
1. Description
This template includes everything needed to build, deploy, and monitor an Azure solution that both adds messages to and reacts to messages on an Azure Service Bus queue using Azure Function Apps and the native bindings for Service Bus.
2. Author Information
Gordon Byers
Link: https://github.com/Gordonby
3. Template Repo
The GitHub repo containing the template being contributed-- must be a valid, complete template
https://github.com/Gordonby/servicebus-dotnet-functionapp
4. Link to PR where you made your repo azd compatible
n/a - was written in azd format from the first commit
5. Tags
Standard: One or more tags representing the template. Look at the currently available tags on the Gallery page. Provide at least 1 tag for programming language used and at least 1 tag for Azure services integrated. Also tag the IaC provider (Bicep or Terraform)
.NET/C#
Bicep
Azure Service Bus
Azure Functions
6. Architecture Diagram or Application Screenshot

7. Related Issues (optional)
Is this a template that was requested in a separate issue? If so, please tag the related issue here.
Next Steps
Once submitted, the issue will be reviewed - we plan to do reviews on a rolling basis at regular intervals. The process will include verifying all information required for the template gallery is provided and the template works (i.e., successfully deploys to Azure with azd up).

If we have questions or enhancements, we will add comments in issue thread (issue stays open)
If the contribution is approved, we'll update the gallery directly (issue will then be closed)

@v-xuto can you validate, test the template and update?

@rajeshkamal5050 We've run this template without any issues.

I prefer it to use /infra/core, but looks fine


Shouldn’t validate content type if there is no content

Content-Type should not be validated when there is no content for every status code, not only 204.
For example: according to RFC it is valid to provide no content for responses with 200 status code. In this case content type validation should not be performed.
Also, this fix aligns the implementation with AFNetworking, which uses the same rule for skipping Content-Type validation.

Looks like CI is failing

The test case that is failing is not even reaching the changes introduced in the pull request. Also all of the tests are successful when Im executing them locally.
Could it be a CI test server configuration issue?

Pull request looks good, will merge once 0.27.1 is out

@stnslw could you please update from development and make sure tests are green?
CI is back to business :)

@valeriomazzeo Nice 👍 Its passing now


Change background

Currently, the background is static, implement some dynamic background which will change itself according to the current weather conditions.

Please assign this issue to me under IWOC

Hello @1010varun I would like to work on this issue. Can you assign it to me ?


a question about config

Excuse me, I don't find the config files in the path?is ia any question ?

Traceback (most recent call last):
File "./bin/run_bert_glyce_tagger.py", line 404, in
main()
File "./bin/run_bert_glyce_tagger.py", line 394, in main
config = merge_config(args_config)
File "./bin/run_bert_glyce_tagger.py", line 385, in merge_config
model_config = Config.from_json_file(model_config_path)
File "/content/drive/My Drive/NER/glyce/glyce/dataset_readers/bert_config.py", line 44, in from_json_file
with open(json_file, "r") as f:
FileNotFoundError: [Errno 2] No such file or directory: '/home/lixiaoya/dataset/'

Please change the python path.
Many thanks!

@stepperL  Pls ?
Traceback (most recent call last):
  File "/home/zy/CODE/bishe/test/test.py", line 18, in <module>
    glyce_embedding = CharGlyceEmbedding(glyce_config)
  File "/home/zy/CODE/bishe/glyce/glyce/layers/char_glyph_embedding.py", line 65, in __init__
    self.char_embedding = nn.Embedding(len(self.config.idx2char), self.config.char_embsize) # (4452, 13, 13)
TypeError: object of type 'NoneType' has no len()

What this problem?


Weird type-widening issue when using methods instead of function properties.

Hi there.
I'm using the tsc compiler, version 1.8.0-dev.20151231, and I'm running into a weird issue where widening of structural types works when I'm defining a class with a function property, and fails when I'm replacing that function property by a "proper" method.
But see for yourself: This is the version that compiles, and this is the version that doesn't.
What is the difference here? Is this a bug in the type inference engine?

This doesn't have to do with widening.
The problem is that you typed run as (T) => X which is actually (T: any) => X. Parameter names are required in function type literals. You can catch this more easily by using --noImplicitAny.
You'll see the version that errors the same way here.

This doesn't have to do with widening.
The problem is that you typed run as (T) => X which is actually (T: any) => X. Parameter names are required in function type literals. You can catch this more easily by using --noImplicitAny.
You'll see the version that errors the same way here.

Thanks, I enabled --noImplicitAny for building my project now.
Out of interest, is there a way I can make this program typecheck without any? Why is TypeScript not able to widen {foo: number} contra-variantly to {foo: number, bar: number} to make it assignable?

Thanks, I enabled --noImplicitAny for building my project now.
Out of interest, is there a way I can make this program typecheck without any? Why is TypeScript not able to widen {foo: number} contra-variantly to {foo: number, bar: number} to make it assignable?

Part of it is the way we select inference points, and the flow of direction between types. Supporting many different inference sites can be complex.
One way to get what you want is to make fooIsEq and barIsEq generic. That way you can say ahead of time what type you're working with.
function fooIsEq<T extends { foo: number }>(x: number) {
  return new Predicate<T, boolean>(v => v.foo === x);
}

function barIsEq<T extends { bar: number }>(x: number) {
  return new Predicate<T, boolean>(v => v.bar === x);
}

function fooAndBarEq(x: number) {
  return fooIsEq<{foo: number; bar: number }>(42)
  			.chain(() => barIsEq(42));
}

Another approach is to say that chain can build types up with an intersection type:
class Predicate<T, X> {
  constructor(private _run: (x: T) => X) {}

  public run: (x: T) => X = (v: T) => {
    return this._run(v);
  }

  public chain<U, Y>(f: (x: X) => Predicate<U, Y>) {
    return new Predicate((v: U & T) => f(this.run(v)).run(v));
  }
}

function fooIsEq(x: number) {
  return new Predicate<{foo: number}, boolean>(v => v.foo === x);
}

function barIsEq(x: number) {
  return new Predicate<{bar: number}, boolean>(v => v.bar === x);
}

function fooAndBarEq(x: number) {
  return fooIsEq(42).chain(() => barIsEq(42));
}

This will allow you to compose predicate functions easily, but you're more prone to accidentally passing in an incorrectly typed function.
By the way, does Predicate really need two type parameters? Usually they just return booleans.

Part of it is the way we select inference points, and the flow of direction between types. Supporting many different inference sites can be complex.
One way to get what you want is to make fooIsEq and barIsEq generic. That way you can say ahead of time what type you're working with.
function fooIsEq<T extends { foo: number }>(x: number) {
  return new Predicate<T, boolean>(v => v.foo === x);
}

function barIsEq<T extends { bar: number }>(x: number) {
  return new Predicate<T, boolean>(v => v.bar === x);
}

function fooAndBarEq(x: number) {
  return fooIsEq<{foo: number; bar: number }>(42)
  			.chain(() => barIsEq(42));
}

Another approach is to say that chain can build types up with an intersection type:
class Predicate<T, X> {
  constructor(private _run: (x: T) => X) {}

  public run: (x: T) => X = (v: T) => {
    return this._run(v);
  }

  public chain<U, Y>(f: (x: X) => Predicate<U, Y>) {
    return new Predicate((v: U & T) => f(this.run(v)).run(v));
  }
}

function fooIsEq(x: number) {
  return new Predicate<{foo: number}, boolean>(v => v.foo === x);
}

function barIsEq(x: number) {
  return new Predicate<{bar: number}, boolean>(v => v.bar === x);
}

function fooAndBarEq(x: number) {
  return fooIsEq(42).chain(() => barIsEq(42));
}

This will allow you to compose predicate functions easily, but you're more prone to accidentally passing in an incorrectly typed function.
By the way, does Predicate really need two type parameters? Usually they just return booleans.

Thanks a lot. The & intersection type is pretty cool. Tbh, I had looked for a dual to | previously, but wasn't able to find anything. Is there documentation for in the current TypeScript spec for it? I'd be especially interest in how co & contravariance are solved for it how it plays together with the bivariance of function arguments. Is that why you were saying "[I was] more prone to accidentally passing in an incorrectly typed function." with this approach?

We're in the process of documenting things a little more, and the spec will have it soon as well.
What I meant is that you can chain with basically any single-argument function. I guess in practice it won't be a problem, since you'll get an error when you actually try to run with some value that isn't compatible.


FDG-6044 Remove AFG blub from hero section on the Debt, Deficit and Spending explainer pages

Code Coverage: 89.69
Removed Blurbs from debt, deficit, spending page.
Modify test to remove test
removed unused styling.

Code looks good and all ACs met.
All test ran successfully locally.
build-dev ran successfully  locally.


Ducted Heating with Add on Cooling

Hi Everyone,
I have a MagiqTouch with ducted heating which works great, thanks heaps for making the add on. But I also have add-on cooling that that is also controlled by the MagiqTouch which doesn't seem to report into home assistant. (https://www.seeleyinternational.com/products/combined/ducted-gas-heating-and-add-on-cooling/)
Would anyone know if support has been added into this add-on? If not, are there logs I can attach that would assist in getting the add-on cooling added?
thanks

I don't know of anyone using add-on cooling with this module, I personally only have evap cooling - no heating.
Logs of raw settings data can be captured by turning on debug in https://github.com/andrewleech/ha_magiqtouch/issues/16#issuecomment-1558259349
Then the home assistant system logs will have lines of json data in them for the settings whenever anything is changed.
I can't commit to having any time to spend on this myself though, don't have much time outside work lately.

I have ducted heating with the add on cooling, would be interested to hear if anybody gets this working.

I have both heating and cooling working with this HA plugin. My setup is Braemar ducted heating unit, with a Braemar evap unit daisy-chained through the ducted heater. The MagiQtouch panel is connected to the heater, and can control both units.
This plugin (until last week) was happily controlling both as a single climate entity in HA. I could set my MagiQtouch climate entity to heat, cool, recirc fan (uses ducted heater fan), or fresh fan (uses evap fan).
As I said, this was all fine until about a week ago. Now the plugin isn't able to change settings for either appliance through HA. BUT, it does reflect changes to settings made at the panel or in the MagiQtouch app. Issue #19 has been opened for that problem.