value out of bounds for floating point Infinity

Using browserify 13.0.0 which ships with buffer 4.3.1, I'm getting a RangeError when attempting to write a valid float value of -Infinity to a buffer:
$ echo "new Buffer(4096).writeFloatBE(-Infinity,0)" | browserify - | browser-run -b chrome
Uncaught RangeError: value is out of bounds

This seems to be an issue too with doubles:
$ echo "new Buffer(4096).writeDoubleBE(-Infinity,0)" | browserify - | browser-run -b chrome
Uncaught RangeError: value is out of bounds

Positive infinity yields the same error:
$ echo "new Buffer(4096).writeFloatBE(Infinity,0)" | browserify - | browser-run -b chrome
Uncaught RangeError: value is out of bounds

This works fine in node:
$ node -pe "new Buffer(4096).writeFloatBE(-Infinity,0)"
4

Released as 4.4.0.


App slow in Firefox when server is offline due to keycloak.json

In Firefox, when the app is loaded while the server is offline, it takes really long to load.
The reason is that the browser tries to retrieve the file keycloak.json from the server, which fails after a long time (in my case, 7.9s). This file should probably be cached.
This does not happen in other browsers (tested in Chrome and Microsoft Edge)

keycloak.json has been added to cache.manifest by @ascheman in 7e612e77e78bb13cb97cd7acaad9c7836a32a5df
I suggest closing this issue.

Submitted pull request to initialize keycloak only when online. Please check if this handles your offline cases successfully. If yes, please merge and maybe also close this ticket.
I wonder if the login button should be hidden when we are not online?

@annam002 - der PR ist gemerged. Kann das Ticket geschlossen werden?

Yep, problem gone.


Test Rosenbrock derivative and Hessian by comparing to finitediff

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e9bebb2) 90.12% compared to head (d26489f) 90.37%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #420      +/-   ##
==========================================
+ Coverage   90.12%   90.37%   +0.24%
==========================================
  Files         162      162
  Lines       19549    19606      +57
==========================================
+ Hits        17618    17718     +100
+ Misses       1931     1888      -43

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix issue #229

@realdadfish Rebase this and can we pass e as parameter instead?

@jaredsburrows PR is rebased. Initially I just passed e, but the problem is that we have some very verbose variant-resolving exception messages that span 10+ lines which then still spam the log quite a lot. I found no other way of getting a "condensed" / "shortened" exception message other than manually shrinking the exception message string itself.

Thanks!


How do i add judgement counter?

Describe your problem here.
so i wanted to add judgement counter in psych engine with a lua script putted in mods/scripts so idk how to code so help
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No response

go to a psych discussion
im sure one of them has a judgement counter
(note: if your going to mayo's discussions its only open for 1 more week and your not allowed to create a discussion there)

go to a psych discussion im sure one of them has a judgement counter (note: if your going to mayo's discussions its only open for 1 more week and your not allowed to create a discussion there)

the discussion is deleted


mgmt: smp: Fix shell sending smp response to wrong UART

The commit fixes problem where the SMP over shell response was sent
via UART attached to the console rather than the UART attached to
the shell.
Fixes #26939
Signed-off-by: Dominik Ermel<EMAIL_ADDRESS>

Can you please add more information in the commit message? Why did k_str_out() send the message to the wrong device?


Suggestion: Crop replace

Option to enable crop auto replanting on right click with hoe :) with durability use option

This can be easily accomplished by a plugin, just listen to BlockBreakEvent while holding a hoe, and if it's any of the crop blocks, just set it back as that.

still i think its a thing that should be added to purpur


External links are not active although they are in Chrome pdf viewer and Accrobat Reader

Attach (recommended) or Link to PDF file here:
link_problems.pdf

When opened in Chrome, the external link on the last page (see picture) is clickable although in pdf.js it is not (neither directly in Firefox). Anythink I should enable in pdf.js.
Note, the link is of type myapp://link2document and not an http:// on.
Thank you for your help.

Those annotations contain URIs with a non-standard amos:// protocol (which none of the browsers I've tried are able to open directly anyway), and PDF.js will purposely for security reasons only display link annotations with white-listed standard protocols; please refer to https://github.com/mozilla/pdf.js/blob/b4c3b9459216c57aeb50f237d4f5857d92a08dcb/src/shared/util.js#L335-L370
Hence I believe that this issue is thus INVALID, or WONTFIX, since the default PDF.js library won't be adding non-standard protocols to the white-list.

In a custom implementation of PDF.js you can use the unsafeUrl property, to access the original URI, on the annotation objects that's returned by the getAnnotations method; see https://github.com/mozilla/pdf.js/blob/b4c3b9459216c57aeb50f237d4f5857d92a08dcb/src/display/api.js#L948-L953

Thanks for the super fast and very helpfull answer :) 👍


Add d2l-dialog-abort event to dialog-mixin

You'll want to rebase from main as we've removed Browserstack tests. Also there might be a good place to add a unit test for this now that we're more confident in the approach.

So, I was doing some local testing for this and I'm noticing that in some cases, _close gets called before _handleClose and in some cases its the opposite.
It looks like this is due to the native dialog triggering its own cancel event when the esc key is not caught by our own key handlers.
Would it make sense to add a listener to the dialog cancel event using our own _close instead of the default behaviour there?
Ex:
_handleCancel(e) {
	// Override the default logic for closing the native dialog with our own
	e.preventDefault();
	this._close(abortAction);
}

<dialog
	...
	@cancel="${this._handleCancel}"
></dialog>

This way, I think _close will consistently be called before _handleClose.

Would it make sense to add a listener to the dialog cancel event using our own _close instead of the default behaviour there?

I think that makes sense, and is a nice behaviour anyway to ensure that all the internal state and other logic in our own close is applied consistently in the same order in the native vs. not case.

Hmm, in what scenarios does the close event trigger when the cancel event doesn't?

Based on the docs, it sounds like the cancel event will only run when pressing Esc, or a button with type="reset".  Everything else would be relying on close event.
I am a bit concerned that the dismissible stack can could get out of step when the abort/dismiss is cancelled.  We may need further changes to address that.

I think bullets 2 & 3 can be summarized as Esc.  We prevent the default behaviour of native dialogs, and we normalize the behaviour by handling Esc through the dismissible helper regardless of native vs custom impl.
There are also the cases where the consumer removes the opened attribute or sets the opened property to false, or the user clicks on a dialog button which has the data-dialog-action attribute.  I'm not sure what happens if a consumer uses <button type="reset"> as the docs mention that results in a cancel event like Esc.  The docs sort of imply that button in a native dialog will close the dialog, but I don't think we've ever explored that.

This is looking pretty stale. @bearfriend @jorge-ramirez-arredondo is this still something that's needed, or can we close this off?

Closing for now due to age -- feel free to re-open later if necessary.

Sorry for leaving this hanging for so long. I should've mentioned that I ended up implementing a workaround instead of this due to time constraints.
I'd still like to get back to this at some point, since I think something like this makes sense to have (for the sake of making the open state fully controllable), but without an actual use-case to test it with, it's hard to justify working on it now. I'll re-open this if I run into another scenario where this makes sense to have.


Prepare 2.1.1 release

Signed-off-by: James Taylor<EMAIL_ADDRESS>

Build status not being reported. Closing


ethers-v6: Please consider implementing Result methods like toArray() and toObject()

https://github.com/ethers-io/ethers.js/blob/main/src.ts/abi/coders/abstract-coder.ts#L138
https://github.com/ethers-io/ethers.js/blob/main/src.ts/abi/coders/abstract-coder.ts#L153
Both methods are invaluable to most common use-cases. Thank you.

Have made a PR for this: #818

Is there any update here?

I'm not really sure, it's been so long, @krzkaczor please let me know anything you need on this before it can be merged? Thank you.

Is there any update here? I got a lot of type errors because of this.

Same issue here.

Seems this project is deprecated, maintainer is not responsive and so I have moved onto viem as mentioned in the README.md, I will not spend any more time on this. Feel free to fork and open up another PR (Good luck on getting it merged). Cheers.


"invalid reference format" for version tag

Summary

I'm working on a project and start to learn/use protobuf as protocol. After imported docker-protobuf layer, I saw this error. To simplify the situation, I recreated a new workspace and only a minimum context is involved.
Steps to Reproduce

Use a simple Dockerfile as below:
$ cat Dockerfile
FROM thethingsindustries/protoc:latest as protobuf
ARG CENTOS_VERSION=7.7.1908
FROM centos:$CENTOS_VERSION as osbase

Build it
$ docker build .
Sending build context to Docker daemon  16.38kB
Step 1/3 : FROM thethingsindustries/protoc:latest as protobuf
---> 61425e1df8e3
Step 2/3 : ARG CENTOS_VERSION=7.7.1908
---> Using cache
---> dc1d45376788
Step 3/3 : FROM centos:$CENTOS_VERSION as osbase
invalid reference format

Error shows at the last line above

What do you see now?

See the example I posted in the Reproduce section.
What do you want to see instead?

If I removed the first line, then I see the $CENTOS_VERSION is being parsed correctly.
$ docker build .
Sending build context to Docker daemon  16.38kB
Step 1/2 : ARG CENTOS_VERSION=7.7.1908
Step 2/2 : FROM centos:$CENTOS_VERSION as osbase
---> 08d05d1d5859
Successfully built 08d05d1d5859
Another, the doker-protobuf layer accepts ARG as tag itself. Here is another run:
$ docker build .
Sending build context to Docker daemon  16.38kB
Step 1/4 : ARG TTI_VERSION=3.1.22
Step 2/4 : FROM thethingsindustries/protoc:$TTI_VERSION as protobuf
---> 43f36b10febe
Step 3/4 : ARG CENTOS_VERSION=7.7.1908
---> Using cache
---> b51117ba064d
Step 4/4 : FROM centos:$CENTOS_VERSION as osbase
invalid reference format
Environment

The docker version on my MacOS. (however, I see the same thing on a Centos VM.)
$ docker version
Client: Docker Engine - Community
Version:           19.03.8
API version:       1.40
Go version:        go1.12.17
Git commit:        afacb8b
Built:             Wed Mar 11 01:21:11 2020
OS/Arch:           darwin/amd64
Experimental:      false
Server: Docker Engine - Community
Engine:
Version:          19.03.8
API version:      1.40 (minimum version 1.12)
Go version:       go1.12.17
Git commit:       afacb8b
Built:            Wed Mar 11 01:29:16 2020
OS/Arch:          linux/amd64
Experimental:     false
containerd:
Version:          v1.2.13
GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version:          1.0.0-rc10
GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version:          0.18.0
GitCommit:        fec3683
How do you propose to implement this?

I've been using Docker for a while but very new to docker-protobuf. Not sure if this is an issue but it looks odd to me.
Can you do this yourself and submit a Pull Request?

...

After flip the first 2 lines it works.
Seems it doesn't agree with the docker document. (doesn't need the ARG VERSION line).
https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact
Anyway, it's not an issue, especially not for TTI.

Great that you managed to fix the issue.
FYI, this is exactly why we have these lines at the top in the Dockerfile as well https://github.com/TheThingsIndustries/docker-protobuf/blob/34b1efa4988855ba73065180b54a7b8a23382f91/Dockerfile#L1-L5


Save2DImage didn't work

          Hi,

Save2DImage function didnt work. The error is related enums I think. ExportFormat has no attribute. Please help about that...
Originally posted by @highvoltage9306 in https://github.com/Ophir-Spiricon/BP-Automation/issues/6#issuecomment-2269821403

Hello,
Do you have an error you can share?

My code:
self.beamgage.Export.Save2DImage(filename, ext_num, self.beamgage.FrameBuffer.Current, self.beamgage.ExportFormat.PNG)
Error:
AttributeError: 'AutomatedBeamGage' object has no attribute 'ExportFormat'


Use environment variable for github token file

Use the environment variable 'GITHUB_TOKEN_FILE'
If env variable GITHUB_TOKEN_FILE is not set:

Only check if github cli is authenticated
This is usefull if used localy where the gh cli is authenticated anyway

See how it works: https://jenkins.ivyteam.io/job/github-repo-manager_raise-deps/job/use-env-for-github-token-for-raise-scripts/2/

LGTM. I've lost the overview over all changes.
You may fix README.md

The README.md does not cover the raise use cases, but true I should enhance it!
Because not it is also easy possible to run the raise scripts locally if needed.


Prevent opening Console / Output window on every log

Please add ability to cancel opening console / Terminal on every  Project or Solution creating, also cancel it on making references between projects:

My setting:
 "vssolution.outputChannelMode": "none"
does not helps. Please add one more setting, something like:
 "vssolution.openConcoleForInfo": "never"

may be it is a good idea to add 'onError' option too:
"vssolution.openConcoleForInfo": "onError"

There is a problem with the terminal. I can sendText but I cannot get the output :(

@fernandoescolar
I'm using Live Sass Compiler with this setting:
"liveSassCompile.settings.showOutputWindowOn": "Error"
and console is revealing only on errors. So technically it is possible.

That extension only uses the OutputChannel. In the output panel you can create your custom channel and write what you want. vscode-solution-explorer also uses the terminal to run "dotnet" commands. In the terminal you can only write commands... The method is sendText(..): void :(


Omega482 mods

https://spacedock.info/profile/Omega482
Half of them have the CKAN badge, but I didn't find them on the ckan

Yeah, that part of SpaceDock isn't working, see KSP-SpaceDock/SpaceDock#188.
Feel free to make your own pull requests if you notice ones that are missing. Otherwise I do catch-up PRs every couple of weeks.

KSP-CKAN/NetKAN#6686
KSP-CKAN/NetKAN#6705
KSP-CKAN/NetKAN#6788
KSP-CKAN/NetKAN#6827


'Gigasecond' exercise works in Visual Studio but when submitted via CLI shows as Failed

The message on website when checking Tests status is:
AN ERROR OCCURRED
"We received the following error when we ran your code:
make: *** No targets specified and no makefile found.  Stop."

Thanks! There's investigation ongoing in https://github.com/exercism/exercism/issues/5729

Closing this, for updates follow the above linked issue.


Classic version and MajorMinorPatchMetadata

VariableProvider resets the CommitsSinceTag:
                // For continuous deployment the commits since tag gets promoted to the pre-release number
                semanticVersion.PreReleaseTag.Number = semanticVersion.BuildMetaData.CommitsSinceTag;
                semanticVersion.BuildMetaData.CommitsSinceTag = null;

So the AssemblySemVer will never have the right last number?

Why is it reset to null? Am I not understand the VersioningMode correctly?
A possible fix would be this change in AssemblyVersionsGenerator:

return string.Format("{0}.{1}.{2}.{3}", sv.Major, sv.Minor, sv.Patch, sv.BuildMetaData.CommitsSinceTag ?? sv.PreReleaseTag.Number ?? 0);

This is only in continuous delivery mode which overwrites patch with number commits, doesn't make sense to change 1.2.3-beta.4 to 1.2.4-beta.4, just make it 1.2.4-beta.
Sent from my Windows Phone

From: Geert van<EMAIL_ADDRESS>Sent: ý14/ý03/ý2015 15:33
To<EMAIL_ADDRESS>Subject: [GitVersion] Classic version and MajorMinorPatchMetadata (#391)
VariableProvider resets the CommitsSinceTag:
            // For continuous deployment the commits since tag gets promoted to the pre-release number
            semanticVersion.PreReleaseTag.Number = semanticVersion.BuildMetaData.CommitsSinceTag;
            semanticVersion.BuildMetaData.CommitsSinceTag = null;

So the AssemblySemVer will never have the right last number?

Why is it reset to null? Am I not understand the VersioningMode correctly?
A possible fix would be this change in AssemblyVersionsGenerator:

return string.Format("{0}.{1}.{2}.{3}", sv.Major, sv.Minor, sv.Patch, sv.PreReleaseTag.Number);
—
Reply to this email directly or view it on GitHubhttps://github.com/ParticularLabs/GitVersion/issues/391.

But you set it to null for continuous deployment (so is this a bug?). I think there is a difference between 1.2.3-beta3 and 1.2.3-beta4.

It is inside if (mode == VersioningMode.ContinuousDeployment && !currentCommitIsTagged)
I actually meant continuous deployment in my example above.
The logic and reasoning is explained in the readme at https://github.com/ParticularLabs/GitVersion#octopus-deployci-build-nuget-packages

Still not sure I understand, but let's close this issue.

In short, there are two modes. Continuous delivery and continuous deployment.
Continuous delivery will bump the BuildMetaData.CommitsSinceTag each commit which doesn't change the SemVer.
Continuous deployment mode promotes the changing CommitsSinceTag to be the Pre-release number. And I didn't see any point having the same number duplicated as you get
1.2.3-beta.1+1
1.2.3-beta.2+2
etc
I just drop the +1 by nulling it out. Make sense?

If I can improve the docs to explain better or something then I am interested in doing that, just not sure of the exact issue you are reporting so my answers might be missing

So you are saying, in Continuous deployment, I should be able to get <IP_ADDRESS> when I specific MajorMinorPatchMetadata?

Hrrmm, ok I think the problem is the MajorMinorPatchMetadata itself.. we never take into account the build number.. So 1.2.3-beta.4+5 will either be <IP_ADDRESS> or <IP_ADDRESS>, which is wrong as you say. I am following you now..
I think we should drop MajorMinorPatchMetadata, it doesn't make sense.. What do you think?

I think falling back through different things is not great.
Out of interest what are you using it for?

or we change it to be MajorMinorPatchTag so 1.2.3-beta.4+5 will be <IP_ADDRESS> or in continuous delivery mode it will be <IP_ADDRESS>.
Then the issue is with stable, when it is stable we start bumping the patch on every commit meaning it will always be .0 at the end.
At any rate, I think this is a bad idea as we are trying to make a tool for SemVer?

What I did in the past was using ClassicVersion, but that is dropped now in v3. I was looking for the alternative, so found AssemblySemVer (or something like that). However, I found it strange that 2.1.0-unstable.13 wouldn't result in version <IP_ADDRESS>.
Then I created this issue. Then I decided: hmmm, 2.1.0 isn't a bad idea. I will keep 2.1.0 as file version, but use the FullSemVer as InformationalVersion, so decided to put back MajorMinorPatch.
So that's a bit of history. However, I think if a user wants to stamp it as <IP_ADDRESS>, it should be allowed using MajorMinorPatchMetadata. If the user wants <IP_ADDRESS>, he/she should use MajorMinorPatch (which is the default).

Makes sense. Sorry, missed the point of the original issue. Will have a think and add some tests around it to see what makes sense

Just running into this issue today when trying to release my 2nd beta version (2 commits). The NuGet version being generated is 2.2.0-beta0001 for both, so no update needed :-(

What we can do:

if you want to keep the beta1+1 (not sure why, but ok), we can use this numbering: beta10001, then beta2+1 becomes beta20001. Each next one becomes beta20002, etc.
if you don't want to keep the beta1+1, we can just count the 0001, 0002, etc

Let me know what you prefer and I will do a PR. Need to fix this today anyway to allow users to update to beta 2.

"The NuGet version being generated is 2.2.0-beta0001" that sounds a lot like the issue I had (meta count not equal to commit count).  https://github.com/ParticularLabs/GitVersion/pull/442

Just checked how something could become beta 2 (when applying an actual tag). Not sure if that's really required (anyone uses that?). To make sure I don't break anything, I will go for option 1.

Based on a discussion, I think the continuous deployment mode fixes this issue @GeertvanHorrik?

Exactly. I have moved all my projects to continuous deployment and it works now, thanks.

If you can figure a better way to explain in readme a pr would be good
Sent from my Windows Phone

From: Geert van<EMAIL_ADDRESS>Sent: 28/05/2015 07:56
To<EMAIL_ADDRESS>Cc: Jake<EMAIL_ADDRESS>Subject: Re: [GitVersion] Classic version and MajorMinorPatchMetadata (#391)
Closed #391https://github.com/ParticularLabs/GitVersion/issues/391.
—
Reply to this email directly or view it on GitHubhttps://github.com/ParticularLabs/GitVersion/issues/391#event-315690302.

I think we should focus on #446 , that will make life much easier and more self explanatory.


No /dist/server.js File

I have just noticed that there is a development server file in the dist folder: dev-server.js. However, there is no production version of the server. Is this intentional?
If so, I am unsure how to get it to deploy. I am attempting to deploy on Heroku.

The server as it stands is production ready and will just serve the files in dist when you are outside of development mode; there is no need to compile it, so if there is a server file in dist something is wrong. Check out https://github.com/davezuko/react-redux-starter-kit/wiki/FAQ:-Frequently-Asked-Questions#heroku-deployment for details on deploying to heroku. Hope that helps.


Remove opencv2_catkin: Not needed anymore -> use opencv3_catkin

@ethz-asl/multiagent-mapping-developers Does anyone have a problem with this?

@dymczykm not necessarily, as long as nothing is depending on ocv2 it is never built and your workspace is fine, but if ocv2 is built once your workspace is corrupted and you have to start over. That's why I want this gone.

Yes, I understand that, let's merge it


sceneLocationView drastically slows down after a while (after about 30 sec)

I have an application which adds about 10 pins/location nodes in the scene location view.
When the application first starts, the responsiveness is good, at about 60 FPS.
When the user started moving and after about 30 sec, the FPS steadily drops to about 5 fps and won't restore.

Could you give any details on what those location nodes are? How many lights are being added to the scene? If you were to modify the updatePositionAndScaleOfLocationNodes to only be called every 2 seconds, for example, does that improve performance?

These pins are added as confirmed location nodes (they are created with confirmed lat/lon).
I used the default lighting (.constant) for each pin.
I have tried to change the update timer interval to 2sec, but no luck, it still slows down after about 30 sec.
I am using iphone 6s

This is fixed on an unrelated location

Hi @gp-wang,
could you explain a little better because I'm facing with the same problem? thanks

Same issue here, on a 6S. Only a few pins (images, just like the demo) and it slows down seemingly on its own.

I'm facing the same problem. What I'm doing is just calling "addLocationNodeWithConfirmedLocation()" with several locations and images.
Any suggestions would be great appreciated.


Admin Notifications

Brooke should now be receiving notifications for all of the following events:

Users create new accounts
Users create and complete their profiles
Users submit new workshop proposals
Users complete the Speaker Response Form
Users upload handouts

Currently, these notifications do not include a ton of info so we need to get feedback from Brooke on the content of these notifications and if we need to include more information.

Brooke would like to see some content improvements for when speakers update their profiles or create proposals — namely, this information included in the email notifications.

I improved these notifications for when a speaker submits a new session proposal.


Illegal repo

I have reported this to the GitHub admins.  You should be ashamed of yourself for releasing this.

If I understand this correctly, this isn’t the original source code. They decompiled the rom file, cleaned up and annotated it, and posted it here. So, not illegal, I’m guessing.

Your name makes sense.

is this supersmeg64 or whoever he was called

Maybe you should study some laws and then come here making accusations because this repo doesn't violate any law that i know of unless some lawyer pulls off a nasty trick

Didn't you already spam reddit comment sections about this repo with this reactionary tripe? calm down and take a chill pill man, I'd like to see the exact rule violation you speak of, if any

Obvious troll, name should give it away. Account also created 2 hours ago and this is their first issue.

im just curious why...
why would someone do this.
also not even a good troll, cmon man.

You've gotta have dangerous levels of salt to pull something like this


Change get_test_context() to have a default GenerationClient

Description
As a developer, I want to have a default generation client on get_test_context, so that I can write unit tests without having to much the generation client if the test doesn't require it.
Discussion
This is how the method currently looks like:
    async fn get_test_context(
        gen_client: GenerationClient,
        chunker_client: Option<ChunkerClient>,
        detector_client: Option<DetectorClient>,
    ) -> Context {
        let chunker_client = chunker_client.unwrap_or_default();
        let detector_client = detector_client.unwrap_or_default();

        Context {
            generation_client: gen_client,
            chunker_client,
            detector_client,
            config: OrchestratorConfig::default(),
        }
    }

I'm just not quite sure what would be a good default, since adding derive(Default) to GenerationClient doesn't work.
Acceptance Criteria

[ ] Unit tests that don't interface with a generation client, such as test_handle_detection_task could be rewritten to work without mocking the GenerationClient.

Once we decide on the default value, I'd like to work on this.


Serialized Error: { code: 'ERR_REQUIRE_ESM' }

Serialized Error: { code: 'ERR_REQUIRE_ESM' }

Reproduction
node_modules/package/dist/index.d.ts
export { default as Accordion, AccordionItem } from './Accordion';
vite config
test: {
    globals: true,
    pool: 'forks',
    globalSetup: "./src/test-globals.ts",
    environment: "jsdom",
    threads: true,
    setupFiles: "./src/setupTests.ts",
    coverage: {
      reporter: ["cobertura", "text"],
      exclude: ["node_modules/", "src/setupTests.ts"],
    },

  },

System Info
System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz
    Memory: 5.50 GB / 15.75 GB
  Binaries:
    Node: 20.11.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.21 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.5.0 - ~\TSI\TSI-Web-Customer-Portal\node_modules\.bin\npm.CMD
    pnpm: 8.9.2 - ~\AppData\Roaming\npm\pnpm.CMD
  Browsers:
    Edge: Chromium (123.0.2420.65)
    Internet Explorer: 11.0.19041.3636
  npmPackages:
    @vitejs/plugin-react-swc: ^3.5.0 => 3.6.0
    @vitest/coverage-v8: ^1.3.1 => 1.4.0
    vite: ^5.0.8 => 5.2.6
    vitest: ^1.3.1 => 1.4.0

Used Package Manager
yarn
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I think you could try server.deps.inline: ["@your/package"] in config, something like https://github.com/vitest-dev/vitest/issues/5283#issuecomment-1962781471

I have one private  component libray.

This is the package.json of the library

{
    "name": "@components/react",
    "version": "1.1.0",
    "description": "components React library",
    "main": "./dist/components-react.js",
    "types": "./dist/index.d.ts",
    "sideEffects": [
      "**/*.scss"
    ],
    "scripts": {
      "build": "webpack --config webpack.dev.js",

<EMAIL_ADDRESS>
export { useToggle } from './_hooks';
export { default as Accordion, AccordionItem } from './Accordion';
export { default as ActionButton } from './ActionButton';
export { default as ActionButtonValidation } from './ActionButtonValidation';
export { default as ActionList, ActionListItem } from './ActionList';
export { default as Breadcrumb } from './Breadcrumb';
export { default as Breadcrumbs } from './Breadcrumbs';
export { default as Card } from './Card';

I was geting below error when I run the vitest

To solve that I updated the vite config as below

alias: {
    '@components/react': fileURLToPath(
        new URL("src/components.ts", import.meta.url)
      ),
  },

And my components.ts is
export * as default from '@components/react';
Now test cases are running succesfully, all the components path is correct. But the hook useToggle is not working.
It gives me below error
TypeError: useToggle is not a function or its return value is not iterable

How can we resolve this?


Plan to support http/https protocol?

If you want to connect to an AWS ES cluster, they don't support the transport protocol.

Since the driver is entirely build on top of the transport client my guess is that it is not a trivial thing to do. Hence i do not plan to add this feature, but others are welcome to implement it ofcource :)


Specify a node version in netlify.toml

This PR attempts to address the Node version error we see when trying to build a preview for #20874.
I'm taking this approach based on this conversation in Netlify docs, with formatting from npm docs.
This is my first time adding an engines: block, so who knows if I'm doing it right. 🤷
UPDATE: Netlify ignored the version set in package.json, so I specified a NODE_VERSION in netlify.toml instead, which works fine, but does highlight a whole bunch of build-related errors that show we don't really know where our environments are specified.

/lgtm (for what it's worth)

/lgtm
/approve


qpter not finding PyQt5 under python3 (No longer easily available under pip install)

(worth noting: pter works with pipx install. This is only for qpter)
Recently upgraded my machine, to BunsenLabs Boron / Debian Bookworm.
Wanted to reinstall pter and qpter after upgrading, finding pip install no longer easily available. (There is an 'externally managed environment' warning and it doesn't install. It either suggests creating a virtual environment, or using pipx, which streamlines that process.)
I used pipx install pter and PyQt5, both with success. (I had to delete the older .local files, but otherwise it worked.)
But trying to run qpter gets an error:
PyQt5 is not installed or could otherwise not be imported: No module named 'PyQt5'
I'm guessing the virtual environment pipx is creating for pter and qpter doesn't 'see' the virtual install of PyQt5.
Notably, I do have python3-PyQt5 installed already. I'm not sure what could be tweaked to let qpter 'see' the things it needs over there?
Some more architecture info:
Kernel: 5.10.0-28-amd64 arch: x86_64 bits: 64 compiler: gcc v: 10.2.1
Distro: BunsenLabs GNU/Linux 12 (Boron) base: Debian GNU/Linux 12

Hm, good point. I should really make qpter work nicely with pipx. I'll try to fix this within the next few days!

Alright, it's fixed! Also added a section to the documentation about the installation via pipx -- note that it's not sufficient to run pipx install pter to get it running with qpter; you will have to write pipx install pter[qt] to also add QT to that pipx virtual environment.
The updated version is 3.16.2, so it should "just work" now. Let me know if there are still problems!

Ummm... the pipx install command worked, but I'm getting this now when attempting to run qpter:

Traceback (most recent call last):
File "/home/jason/.local/pipx/venvs/pter/lib/python3.11/site-packages/pter/qtui.py", line 1257, in update_search
self.searcher.parse()
File "/home/jason/.local/pipx/venvs/pter/lib/python3.11/site-packages/pter/searcher.py", line 322, in parse
self.casesensitive.can_lowercase(''.join(self.contexts | self.not_contexts)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'can_lowercase'
Aborted

Not sure if that's something wrong with my machine or qpter.
(Also not sure if I should open a new issue!)


Instrumentation "enabled" configuration inconsistent with OpenTelemetry

The "@opentelemetry/instrumentation" defines a generic InstrumentationConfig interface:
export interface InstrumentationConfig {
  /**
   * Whether to enable the plugin.
   * @default true
   */
  enabled?: boolean;
}

This interface defines an optional configuration for all instrumentations, named "enabled", with the default value "true". The default value is enforced In InstrumentationAbstract:
    this._config = {
      enabled: true,
      ...config,
    };

Which introduces the following issues:
Inconsistent With OpenTelemetry Specification
The OpenTelemetry specification for environment variables says:

All Boolean environment variables SHOULD be named and defined such that false is the expected safe default behavior

The concept is applied in the specification with the OTEL_SDK_DISABLED env variable.
Although this configuration is not an environment variable in the exact context, having the default value as true creates inconsistencies in the OpenTelemetry JS implementation which can be a source of confusions for end users and code maintainers, and increases cognitive load for consumers which should be aware of default values per use-case.
For node-sdk implementation, the property is used with compliance to spec:
export class NodeSDK {
  ...
  private _disabled?: boolean;
  ...
}

Harder to Maintain
When a user chooses not to set the enabled flag (which is very common) leaving it as undefined, the implementation code needs to be aware of the default and make sure to use nullish-coalescing or some other fallback mechnisim everywhere it is accessed.
This practice requires awareness which is not straightforward to comply with, as the enabled flag is a public API property and can be consumed in OpenTelemetry package but also by any user of the @opentelemetry/instrumentation package.
Buggy
The current implementation of InstrumentationAbstract assumes that the config object is sanitized in the constructor:
  constructor(
    public readonly instrumentationName: string,
    public readonly instrumentationVersion: string,
    config: ConfigType = {}
  ) {
    this._config = {
      enabled: true,
      ...config,
    };

And then read the value freely without checking for undefined and defaulting the true. For example, the value is read as-is here.
Since the logic to change enabled undefined to true is not applied in the InstrumentationAbstract class with setConfig function:
  /**
   * Sets InstrumentationConfig to this plugin
   * @param InstrumentationConfig
   */
  public setConfig(config: InstrumentationConfig = {}): void {
    this._config = Object.assign({}, config);
  }

any call to setConfig will invalidate the assumption which is a bug. Even if we fix it for the base class, It is still extremely easy for instrumentation authors that override setConfig to miss this nuance and introduce bugs to the implementation.
Fix
I can think of 2 ways to fix this issue:

align with opentelemetry specification and change the enabled property to disabled, and change the default value to false. This will be a potential breaking change for the package which we can introduce at the moment but not after the package is stable.
Keep the current property as enabled but fix the places where it is used, as well as add documentation for consumers on how to use it safely.

I personally think that since the package is still experimental and breaking changes are allowed, it is a good opportunity to introduce changes that will promote consistent and robust use of the package.
Would love to hear more opinions and to work on changing this property if there isn't any push-back.

By the way, the handling of enabled flag is not done consistent as of now, see https://github.com/open-telemetry/opentelemetry-js/issues/2257
I think a single enable / disable flag is not enough in generla. I would expect 2 flags:

enable (or disable) - only evaluated at construction time to decide patch yes/no
capture - runtime changeable, evaluated whenever some monitored/pached API is called

By the way, the handling of enabled flag is not done consistent as of now, see #2257
I think a single enable / disable flag is not enough in general. I would expect 2 flags:

enable (or disable) - only evaluated at construction time to decide patch yes/no
capture - runtime changeable, evaluated whenever some monitored/pached API is called

So the patch will be decided at construction time and then capture will decide if an invoked patch should record telemetry or not?
In this case, when will instrumentation unpatch is expected to be called?

I can think of 2 ways to fix this issue:

align with opentelemetry specification and change the enabled property to disabled, and change the default value to false. This will be a potential breaking change for the package which we can introduce at the moment but not after the package is stable.
Keep the current property as enabled but fix the places where it is used, as well as add documentation for consumers on how to use it safely.

🤔  If we change this to disabled, that would potentially be very disruptive to people using enabled: false - the first thing that comes to mind is the fs-instrumentation that produces many events and is not always needed for folks, so they add the auto-instrumentations-node metapackage, and explicitly set fs instrumentation to false. With this change, if they don't update their code but they upgrade their instrumentation package, they will need to change enabled: false to disabled: true to avoid getting an unexpected influx of events. I am concerned about how big that impact may be for folks who miss the changelog update, and it may be too much without declaring a major version. Experimental technically means we could do this... but I am still hesitant based on the potential impact to end users.
Because of the potentially large impact on end users, I'd be more in favor of Option 2 to keep things as consistent as possible. As we look to stabilize, we may consider reversing the enabled/disabled flag and evangelizing it (similar to how we will need to do it with the http attributes).

Is there a possible third option of implementing number 1, with a deprecated codepath that checks for enabled:false and sets disabled:true if that is found?


Update sbt-scalafmt to 2.3.3

Updates org.scalameta:sbt-scalafmt from 2.3.2 to 2.3.3.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "sbt-scalafmt" } ]

labels: sbt-plugin-update, semver-patch

Codecov Report

Merging #8 into master will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #8   +/-   ##
=======================================
  Coverage   96.64%   96.64%
=======================================
  Files          15       15
  Lines         298      298
  Branches       17       16    -1
=======================================
  Hits          288      288
  Misses         10       10

Continue to review full report at Codecov.

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


[BUG] No tests generated for function calling function from another module

Description
Generation for function that calls function from another target produces no tests saying that it leads to klee internal error
To Reproduce
Steps to reproduce the behavior:

Open the c-example project
Choose libsrc.a target and set use stubs to true
Generate tests for function other_module_call at least two times. One of attempts will fail

Expected behavior
Tests are supposed to be generated and linked with stubs
Actual behavior
No tests are generated.
Visual proofs (screenshots, logs)
Generated test file:
/*
 * This file is automatically generated by UnitTestBot. For further information see https://www.utbot.org
 */

#include "calc_dot_c_test.h"

#include "gtest/gtest.h"
namespace UTBot {
// Some tests for function 'other_module_call' were skipped, as execution of function leads KLEE to the internal error. See console log for more details.

// Tests for other_module_call were not generated. Maybe the function is too complex.

}

Logs: logs.txt
Environment
latest main or latest release 2022.10.4

Tests are generated but there could be identical ones - #547


WIP aspnetcore2swaggercommand

Why did you close the PR?

@RSuter - Here's the correct PR - https://github.com/RSuter/NSwag/pull/1046. This was an early prototype of the change and I'm not entirely sure why I sent it as a PR

Ok, no problem. Is there also a way to generate the spec for existing dlls, or does this only work with a .csproj?


Rendering issue when using localization

Hi,
I am working on multi-culture angular web app and to get culture in URL I am using

https://github.com/Greentube/localize-router

But found that the current selected culture appear in the breadcrumb component like this:
Home / En / Campaigns
Is there any way to remove the culture from the breadcrumb ?
thanks

Reading every line of the docs saved my day :)
the following line did the job this.breadcrumbService.hideRouteRegex('^/([A-Za-z]{2})$');


Docs for Sequel.extension

Please add some docs/examples for use-case without Sequel::Model.
I have pretty minimal experimental ruby app built with Sequel and pgvector plugin, but struggle to enable it:
/Users/u/.rvm/rubies/ruby-3.3.2/lib/ruby/3.3.0/bundled_gems.rb:74:in `require': cannot load such file -- sequel/extensions/pgvector (LoadError)
	from /Users/u/.rvm/rubies/ruby-3.3.2/lib/ruby/3.3.0/bundled_gems.rb:74:in `block (2 levels) in replace_require'
	from /Users/u/.rvm/gems/ruby-3.3.2@pgvector_app/gems/sequel-5.82.0/lib/sequel/core.rb:158:in `block in extension'
	from /Users/u/.rvm/gems/ruby-3.3.2@pgvector_app/gems/sequel-5.82.0/lib/sequel/core.rb:158:in `each'
	from /Users/u/.rvm/gems/ruby-3.3.2@pgvector_app/gems/sequel-5.82.0/lib/sequel/core.rb:158:in `extension'
	from /Users/u/.rvm/gems/ruby-3.3.2@pgvector_app/gems/sequel-5.82.0/lib/sequel/dataset/query.rb:207:in `extension'
	from (irb):2:in `block in <top (required)>'
	from /Users/u/dev/hobby/ollama-index/lib/postgres.rb:39:in `query'
	from (irb):2:in `<main>'
	from <internal:kernel>:187:in `loop'
	from bin/console.rb:9:in `<main>'

require 'logger'
require 'sequel'
require 'pgvector'

EXTENSIONS = [:pgvector]
CONNECTIONS_SETTINGS = {:adapter=>"postgres", :host=>"localhost", :database=>"pgvector_app"}

def connect
  Sequel.connect(CONNECTIONS_SETTINGS).tap do |cnt|
    cnt.loggers << Logger.new(STDOUT)
    EXTENSIONS.each { cnt.extension(_1) }
  end
end

connect

Hi @m0n9oose, here's an example without Sequel::Model.
require "sequel"

DB = Sequel.connect("postgres://localhost/pgvector_example")

DB.run("CREATE EXTENSION IF NOT EXISTS vector")
DB.run("CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3))")

DB[:items].insert(embedding: "[1,2,3]")

p DB[:items].order(Sequel.lit("embedding <-> ?", "[1,2,3]")).limit(5).to_a

You can optionally use the gem to convert between Ruby and the pgvector text format.
require "pgvector"

p Pgvector.encode([1, 2, 3]) # "[1.0,2.0,3.0]"
p Pgvector.decode("[1,2,3]") # [1.0, 2.0, 3.0]

Thanks for looking into this @ankane ❤
I was able to make it work as an extension but my code is very raw so I hesitate to make a PR :)
In case if you interested in adding extension support:
diff --git c/lib/sequel/extensions/pgvector.rb i/lib/sequel/extensions/pgvector.rb
new file mode 100644
index 0000000..23557e7
--- /dev/null
+++ i/lib/sequel/extensions/pgvector.rb
@@ -0,0 +1,9 @@
+require 'pgvector'
+require 'sequel/plugins/pgvector'
+
+module Sequel
+  module Pgvector
+  end
+
+  Dataset.register_extension(:pgvector, Sequel::Plugins::Pgvector::DatasetMethods)
+end

Thanks @m0n9oose, added in the commit above.


Ensure clients can create multiple instances of HMSMeeting

Clients should be able to create an instance of 100ms SDK > Join Room > Leave & they destroy the instance.
Then create a new instance of 100ms SDK > Join > Leave > Destroy
Ensure we don't have a singleton or store HMSMeeting instances within the SDK

@Arunshaik2001 Can we test this scenario?

@Arunshaik2001 Can we test this scenario?

ok, I will check


raft: set m.Context in addRequest()

m.Context needs to be set in addRequest() because advance()
will use it to delete it from pendingReadIndex map.
FIXES #7571

We need a test for this. Also have you confirmed this will fix the issue?

@xiang90 I manually run the the following script
func TestMemLeak(t *testing.T) {
	const key = "/foo"

	// this size was pulled from one of our larger test values: we often see bigger values in production
	val := make([]byte, 22973)
	if _, err := rand.Read(val); err != nil {
		t.Fatal(err)
	}

	if err := initializeKey(key, string(val)); err != nil {
		t.Fatal(err)
	}

	if err := demonstrateLeak(key); err != nil {
		t.Fatal(err)
	}
}

// demonstrateLeak repeatedly performs a gets to demonstrate a memory leak in
// etcd server v3.1.2. It explicitly creates and closes the client periodically
// to demonstrate that the memory is not reclaimed upon closing the gRPC
// connection.
func demonstrateLeak(key string) error {
	for outer := 0; ; outer++ {
		fmt.Printf("Starting outer iteration %d\n", outer)

		etcdc, err := etcdClient()
		if err != nil {
			return err
		}

		for inner := 0; inner < 1000000; inner++ {
			if inner%10000 == 0 {
				fmt.Printf("Starting inner iteration %d\n", inner)
			}
			if _, err := etcdc.Get(context.Background(), key); err != nil {
				return err
			}
		}

		if err := etcdc.Close(); err != nil {
			return err
		}
	}
}

func initializeKey(key, val string) error {
	etcdc, err := etcdClient()
	if err != nil {
		return err
	}
	defer etcdc.Close()

	_, err = etcdc.Put(context.Background(), key, val)
	return err
}

func etcdClient() (*clientv3.Client, error) {
	return clientv3.New(clientv3.Config{
		Endpoints: []string{"http://localhost:2379"},
	})

}

and observe there is no mem leak from top.

@xiang90 I'll try to come up with a test.

is this safe with respect to the raft dissertation 6.4, step 3?

Probably instead change advance so there's no need to modify the message data:
for _, rs := range rss {
    delete(ro.pendingReadIndex, string(rs.req.Entries[0].Data))
}

@heyitsanthony yeah, that probably has lesser potential side affect.

Added test. PTAL

lgtm, defer to @xiang90

LGTM

unrelated CI failure. Merging.


refactor(sdk,app): unify jwt signing.

Signed-off-by: Volodymyr Kubiv<EMAIL_ADDRESS>

Codecov Report
Base: 92.09% // Head: 90.69% // Decreases project coverage by -1.41% :warning:

Coverage data is based on head (4887232) compared to base (adbb615).
Patch coverage: 61.76% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #242      +/-   ##
==========================================
- Coverage   92.09%   90.69%   -1.41%
==========================================
  Files          49       49
  Lines        1873     1859      -14
==========================================
- Hits         1725     1686      -39
- Misses        104      124      +20
- Partials       44       49       +5

Impacted Files
Coverage Δ

pkg/common/jwt_signer.go
85.10% <0.00%> (-14.90%)
:arrow_down:

pkg/openid4ci/clientconfig.go
63.63% <ø> (-36.37%)
:arrow_down:

pkg/openid4ci/openid4ci.go
84.43% <66.66%> (-5.18%)
:arrow_down:

cmd/wallet-sdk-gomobile/openid4ci/interaction.go
83.33% <100.00%> (-1.60%)
:arrow_down:

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.


Default Memo should be empty.

Because of hashing or something post processing when you don't apply a MEMO to a transaction, you get:
Memo: i!z0y!B5J|UH,% nz
We should default an empty memo or even 'empty memo' as a default to make this a little prettier/nicer.

I can do this one easily.

@jkrauska where are the memos made visible?

@psteckler not sure where Joel is seeing them, but they're visible in a base58check-encoded form (we should probably change that too but idk if it's related to this issue) in the logs and in one of the graphql queries.
@garethtdavies decodes those encoded strings in https://codaexplorer.garethtdavies.com, which is where I've seen the i!z0y�!B5J|�UH,��% �nz-like string in the past.

@Schmavery OK, I believe I know where they're generated. I do need a way to verify that a fix is indeed a fix.

If you're able to print out the base58check-encoded representation of an empty memo, then you should be able to look for that in the logs when sending a transaction


Bundling of dependency pg fails for workers preset because it bundle the optional dependency pg-native. Is there a way to ignore this ?

Environment
Node.JS : 16.15.0
NItro : 0.3.8
Reproduction
Here is a simple reproduction link : Stackblitz
Just run NITRO_PRESET=cloudflare npm run blitz
Notice the message 'pg-native' is imported by pg-native?commonjs-external, but could not be resolved – treating it as an external dependence
The .output/server/index.mjs build has now an import e as * from 'pg-native' : it is not compatible with cloudflare or any worker.
Describe the bug
To generate the build, nitro bundle pg with it's optional peer dependency pg-native. However, pg-native is not compatible with workers since it relies on libpq.
However this dependency is optional and it would work perfectly fine without it.
-> Is there a way to ignore this dependency, or to mock it because we never use it ?
Additional context
No response
Logs
No response

any movement on this issue?

Hi pi0, definitly better support with and cloudflare for sure.
I was able to set these values in my nuxt project, for anyone that finds and is seeking a resolution
nitro: {
esbuild: {
options: {
target: "ESNEXT",
},
},
rollupConfig: {
external: ["cloudflare:sockets"],
},
preset: "cloudflare-pages",
},

TIL about cloudflare:sockets. Is there any link to docs for it? (we might add it to externals by default)

Nothing concrete, no. Seen it across various issues though. Most relevant would be this one: https://github.com/unjs/nitro/issues/1967


Custom quotes and get quotes by author

Is your feature request related to a problem? Please describe.
Most of the time, I'm frustrated with the categorial quotes I'm getting with the extension.
Describe the solution you'd like
A solution would be to set your own custom quotes and/or search quotes by favourite author(s). While selecting favourite category quotes.
Describe alternatives you've considered
nil
Additional context
nil

I added this in the upcoming release of the extension, which is being released today.


automatically updates on new diagnostics doesn't work

Problem:

Default configuration
Open file with LSP errors and Trouble set.
Try to fix.
Zero reaction.
Trying to set auto_close and auto_open.
Repeat actions.

Plug 'folke/trouble.nvim'
lua << EOF
  require("trouble").setup {
    -- your configuration comes here
    -- or leave it empty to use the default settings
    -- refer to the configuration section below
  }
EOF

lsb_release -a:
Description:	Debian GNU/Linux 11 (bullseye)

Neovim version:
NVIM v0.6.0-dev+631-g72d62aa6a
Build type: Release
LuaJIT 2.1.0-beta3

:checkhealth
lspconfig: require("lspconfig.health").check()
========================================================================
  - INFO: cssls: configuration checked.
  - INFO: clangd: configuration checked.
  - INFO: jsonls: configuration checked.
  - INFO: cmake: configuration checked.
  - INFO: tailwindcss: configuration checked.
  - INFO: tsserver: configuration checked.
  - INFO: html: configuration checked.

nvim: health#nvim#check
========================================================================
## Configuration
  - OK: no issues found

## Performance
  - OK: Build type: Release

## Remote Plugins
  - OK: Up to date

## terminal
  - INFO: key_backspace (kbs) terminfo entry: key_backspace=\177
  - INFO: key_dc (kdch1) terminfo entry: key_dc=\E[3~
  - INFO: $VTE_VERSION='6203'
  - INFO: $COLORTERM='truecolor'

nvim-treesitter: require("nvim-treesitter.health").check()
========================================================================
## Installation
  - WARNING: `tree-sitter` executable not found (parser generator, only needed for :TSInstallFromGrammar, not required for :TSInstall)
  - OK: `node` found v16.13.0 (only needed for :TSInstallFromGrammar)
  - OK: `git` executable found.
  - OK: `cc` executable found. Selected from { vim.NIL, "cc", "gcc", "clang", "cl", "zig" }
    Version: cc (Debian 10.2.1-6) 10.2.1 20210110
  - OK: Neovim was compiled with tree-sitter runtime ABI version 13 (required >=13). Parsers must be compatible with runtime ABI.

  Legend: H[ighlight], L[ocals], F[olds], I[ndents], In[j]ections
         +) multiple parsers found, only one will be used
         x) errors found in the query, try to run :TSUpdate {lang}

provider: health#provider#check
========================================================================
## Clipboard (optional)
  - OK: Clipboard tool found: xclip

## Python 2 provider (optional)
  - WARNING: No Python executable found that can `import neovim`. Using the first available executable for diagnostics.
  - ERROR: Python provider error:
    - ADVICE:
      - provider/pythonx: Could not load Python 2:
          python2 not found in search path or not executable.
          python2.7 not found in search path or not executable.
          python2.6 not found in search path or not executable.
          python not found in search path or not executable.
  - INFO: Executable: Not found

## Python 3 provider (optional)
  - INFO: `g:python3_host_prog` is not set.  Searching for python3 in the environment.
  - INFO: Multiple python3 executables found.  Set `g:python3_host_prog` to avoid surprises.
  - INFO: Executable: /usr/bin/python3
  - INFO: Other python executable: /bin/python3
  - INFO: Python version: 3.9.2
  - INFO: pynvim version: 0.4.3
  - OK: Latest pynvim is installed.

## Python virtualenv
  - OK: no $VIRTUAL_ENV

## Ruby provider (optional)
  - WARNING: `ruby` and `gem` must be in $PATH.
    - ADVICE:
      - Install Ruby and verify that `ruby` and `gem` commands work.

## Node.js provider (optional)
  - INFO: Node.js: v16.13.0
  - INFO: Nvim node.js host: /home/user/.npm-packages/lib/node_modules/neovim/bin/cli.js
  - OK: Latest "neovim" npm/yarn package is installed: 4.10.0

## Perl provider (optional)
  - ERROR: perl provider error:
    - ADVICE:
      - "Neovim::Ext" cpan module is not installed

telescope: require("telescope.health").check()
========================================================================
## Checking for required plugins
  - OK: plenary installed.
  - OK: nvim-treesitter installed.

## Checking external dependencies
  - OK: rg: found ripgrep 13.0.0 (rev 7ec2fd51ba)
  - OK: fd: found fd 8.2.1

## ===== Installed extensions =====

## Telescope Extension: `fzf`
  - INFO: No healthcheck provided

vim.lsp: require("vim.lsp.health").check()
========================================================================
  - INFO: LSP log level : WARN
  - INFO: Log path: /home/user/.cache/nvim/lsp.log
  - INFO: Log size: 6144 KB

vim.treesitter: require("vim.treesitter.health").check()
========================================================================
  - INFO: Runtime ABI version : 13
  - OK: Loaded parser for bash: ABI version 13
  - OK: Loaded parser for beancount: ABI version 13
  - OK: Loaded parser for bibtex: ABI version 13
  - OK: Loaded parser for c: ABI version 13
  - OK: Loaded parser for c_sharp: ABI version 13
  - OK: Loaded parser for clojure: ABI version 13
  - OK: Loaded parser for cmake: ABI version 13
  - OK: Loaded parser for comment: ABI version 13
  - OK: Loaded parser for commonlisp: ABI version 13
  - OK: Loaded parser for cpp: ABI version 13
  - OK: Loaded parser for css: ABI version 13
  - OK: Loaded parser for cuda: ABI version 13
  - OK: Loaded parser for dart: ABI version 13
  - OK: Loaded parser for dockerfile: ABI version 13
  - OK: Loaded parser for dot: ABI version 13
  - OK: Loaded parser for elixir: ABI version 13
  - OK: Loaded parser for erlang: ABI version 13
  - OK: Loaded parser for fennel: ABI version 13
  - OK: Loaded parser for fish: ABI version 13
  - OK: Loaded parser for glimmer: ABI version 13
  - OK: Loaded parser for glsl: ABI version 13
  - OK: Loaded parser for go: ABI version 13
  - OK: Loaded parser for gomod: ABI version 13
  - OK: Loaded parser for graphql: ABI version 13
  - OK: Loaded parser for hcl: ABI version 13
  - OK: Loaded parser for heex: ABI version 13
  - OK: Loaded parser for hjson: ABI version 13
  - OK: Loaded parser for html: ABI version 13
  - OK: Loaded parser for http: ABI version 13
  - OK: Loaded parser for java: ABI version 13
  - OK: Loaded parser for javascript: ABI version 13
  - OK: Loaded parser for jsdoc: ABI version 13
  - OK: Loaded parser for json: ABI version 13
  - OK: Loaded parser for json5: ABI version 13
  - OK: Loaded parser for jsonc: ABI version 13
  - OK: Loaded parser for julia: ABI version 13
  - OK: Loaded parser for kotlin: ABI version 13
  - OK: Loaded parser for latex: ABI version 13
  - OK: Loaded parser for ledger: ABI version 13
  - OK: Loaded parser for llvm: ABI version 13
  - OK: Loaded parser for lua: ABI version 13
  - OK: Loaded parser for nix: ABI version 13
  - OK: Loaded parser for ocaml: ABI version 13
  - OK: Loaded parser for ocaml_interface: ABI version 13
  - OK: Loaded parser for perl: ABI version 13
  - OK: Loaded parser for php: ABI version 13
  - OK: Loaded parser for pioasm: ABI version 13
  - OK: Loaded parser for prisma: ABI version 13
  - OK: Loaded parser for python: ABI version 13
  - OK: Loaded parser for ql: ABI version 13
  - OK: Loaded parser for query: ABI version 13
  - OK: Loaded parser for r: ABI version 13
  - OK: Loaded parser for regex: ABI version 13
  - OK: Loaded parser for rst: ABI version 13
  - OK: Loaded parser for ruby: ABI version 13
  - OK: Loaded parser for rust: ABI version 13
  - OK: Loaded parser for scala: ABI version 13
  - OK: Loaded parser for scss: ABI version 13
  - OK: Loaded parser for sparql: ABI version 13
  - OK: Loaded parser for supercollider: ABI version 13
  - OK: Loaded parser for surface: ABI version 13
  - OK: Loaded parser for svelte: ABI version 13
  - OK: Loaded parser for tlaplus: ABI version 13
  - OK: Loaded parser for toml: ABI version 13
  - OK: Loaded parser for tsx: ABI version 13
  - OK: Loaded parser for turtle: ABI version 13
  - OK: Loaded parser for typescript: ABI version 13
  - OK: Loaded parser for vim: ABI version 13
  - OK: Loaded parser for vue: ABI version 13
  - OK: Loaded parser for yaml: ABI version 13
  - OK: Loaded parser for yang: ABI version 13
  - OK: Loaded parser for zig: ABI version 13
  - OK: Loaded parser for c: ABI version 13

https://user-images.githubusercontent.com/85330672/143771109-b7802cad-ed29-47d3-a373-16b145bf6146.mp4

Most likely related to https://github.com/neovim/neovim/issues/14090#issuecomment-979424077.

Actually changing the code in plugin/trouble.vim
au User LspDiagnosticsChanged lua require'trouble'.refresh({auto = true, provider = "diagnostics"})

to the following (based on the described change in neovim/neovim#14090)
au DiagnosticChanged * lua require'trouble'.refresh({auto = true, provider = "diagnostics"})

looks like fixes the issue, making diagnostics autoupdate working as before. But I'm not too sure about a PR since I don't know much about lua and vimscript, and whether other files needs checking too.

It's not as easy as just changing the aucommand, it will break for 0.5.x users. Checking for 0.6.0 version needs to be added.

Took a crack at fixing it in PR #127


RPC Zod Validation, Type Checking

What version of Hono are you using?
4.6.7
What runtime/platform is your app running on?
node
What steps can reproduce the bug?
package.json snippet
 "@hono/node-server": "^1.13.2",
 "@hono/zod-validator": "^0.4.1",
 "hono": "^4.6.7",

This code works fine, meaning when I am using the honor client I can properly see the input types
const route = app.post(
  '/posts',
  zValidator(
    'json',
    z.object({
      body: z.string(),
      title:z.string()
    })
  ),
  (c) => {
    const validated = c.req.valid('form')
    // ... use your validated data
  }
)

But I am using typescript so when I add the type for the context, I do not get the types for the input arguments when using RPC and honor client in my application
const route = app.post(
  '/posts',
  zValidator(
    'json',
    z.object({
      body: z.string(),
      title:z.string()
    })
  ),
  (c:Context) => {  // <== this change causes the issue
    const validated = c.req.valid('form')
    // ... use your validated data
  }
)

What is the expected behavior?
to see input variable types
What do you see instead?
the input variables are not defined
Additional information
No response

Could you please tell me why it has to be the latter code?
Since the latter code cannot inherit type information in generics, it seems inevitable that it cannot be inferred.

I am not a generics expert, so it is not obvious to me. I guess it would not be obvious not to include a type when writing with Typescript. @EdamAme-x

I am not sure what you mean.
Either way, it is best practice not to explicitly specify the type of the former argument.
TypeScript will automatically infer the argument types.

@aaronksaunders
Don't say "not helpful" to the person who wants to help you.

@aaronksaunders I think you haven't quite understood something about TypeScript. It has nothing to do with Hono. When you declare a type in TypeScript like c: Context, you are asking the compiler to assign the type Context to the argument c. At this point, the TypeScript compiler just checks if the type you assign is compatible, and if it is, it will just accept it and use it from then on. If you don't explicitly assign the type, TypeScript will try to infer the type instead. If you want to assign it explicitly, you would have to define the T generic (in your case the request body shape) in Context<T> yourself. However, Hono is already doing that for you under the hood. The only thing you need to do is to let the type inference do it's magic. :-)

@aaronksaunders It could be a good idea to ask this in Discord.

No harm meant, I just did not know another way to say that the comment left
provided no additional information to help me understand why it wasn’t
working for me.
So yes I appreciate the response but it didn’t bring me any closer to
understanding the magic that was happening.
The explanation provided by @marcomuser explains it clearly and answered my
question. Context is hard to convey in text and unfortunately everyone is
on edge when reading issues and assuming the worse when the read something.
There was no malicious intent.
--
Aaron K. Saunders
CEO Clearly Innovative Inc
@.***
www.clearlyinnovative.com
This email message and any attachment(s) are for the sole use of the
intended recipient(s) and may contain proprietary and/or confidential
information which may be privileged or otherwise protected from disclosure.
Any unauthorized review, use, disclosure or distribution is prohibited. If
you are not the intended recipient(s), please contact the sender by reply
email and destroy the original message and any copies of the message as
well as any attachment(s) to the original message.
On Tue, Oct 29, 2024 at 1:20 AM Yusuke Wada @.***>
wrote:

@aaronksaunders https://github.com/aaronksaunders
Don't say "not helpful" to the person who wants to help you.
—
Reply to this email directly, view it on GitHub
https://github.com/honojs/hono/issues/3579#issuecomment-2443238372, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEAFGI5NB5JKCMWQ5OUURLZ54LLBAVCNFSM6AAAAABQX7QPHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBTGIZTQMZXGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

@aaronksaunders Thank you for the comment!
I'll close this issue. If you have a problem that is suspected of if it's a bug, please feel free to open an issue!


Revert "rebase: bump github.com/go-jose/go-jose/v3 from 3.0.1 to 3.0.3"

Reverts red-hat-storage/ceph-csi#270
This pr needs to be reverted for proper sync between DS devel and release-4.16 branch.
/cc @Madhu-1 @nixpanic

/lgtm

/hold
I don't think reverting is nice. Better rebase a manual sync PR on top of latest release-4.16?

/hold
I don't think reverting is nice. Better rebase a manual sync PR on top of latest release-4.16?

I think its better to have proper sequence of commits that doesn't deviate much.
and resolving manual conflicts may complicate things further.

I think its better to have proper sequence of commits that doesn't deviate much.

This is normal with backports. Automation, or in this case we are expected to be able to handle this without issues.

Addressed with #281.


Add storage information of /roms2

Add storage information of /roms2 and fix network information issues.

Fixed in commit 9280c3f on branch rg503


Enhance AppVeyor Configuration for Pull Request Management

User description

Closes #
📑 Description

✅ Checks

[ ] My pull request adheres to the code style of this project
[ ] My code requires changes to the documentation
[ ] I have updated the documentation as required
[ ] All the tests have passed

☢ Does this introduce a breaking change?

[ ] Yes
[ ] No

ℹ Additional Information

Description

Improved the appveyor.yml configuration to manage queued builds for pull requests.
Added a check to fail early if there are newer builds queued for the same PR.

Changes walkthrough 📝
Relevant filesConfiguration changes

appveyor.ymlEnhance AppVeyor Configuration for PR Builds

appveyor.yml
Added installation step to handle queued builds for pull requests.  Included a PowerShell script to check for newer queued builds.

+11/-0

💡 Penify usage:
Comment /help on the PR to get a list of all available Penify tools and their descriptions

Summary by CodeRabbit

New Features

Introduced a mechanism to prevent redundant builds for pull requests, enhancing build process efficiency.

Chores

Updated configuration to streamline build checks and remove unnecessary environment variable settings.

:white_check_mark: Build Sankhya-SDK-dotnet 3.0.836 completed (commit https://github.com/guibranco/Sankhya-SDK-dotnet/commit/82f93ebaa7 by @guibranco)


(chaos-center): Added litmus core component version API

Signed-off-by: Amit Kumar Das<EMAIL_ADDRESS>
Proposed changes
This PR adds:

envs for Litmus Core Component version
API for the Litmus Core version (required in workflow creation)

Route: /litmus_core_version
Response :

{
coreVersion: "2.7.0"
}

Types of changes
What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

[ ] New feature (non-breaking change which adds functionality)
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices applies)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] I have read the CONTRIBUTING doc
[ ] I have signed the commit for DCO to be passed.
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[ ] I have added necessary documentation (if appropriate)

Dependency

Please add the links to the dependent PR need to be merged before this (if any).

Special notes for your reviewer:

Can we have /version only?

Just split the image by : and use the last element of the array

Can we have /version only?
and we don't need LITMUS_CORE_VERSION. we can parse it from the CHAOS_OPERATOR/CHAOS_EXPORTER image.

Probably not a good idea, in case we don't have to do a simultaneous release of these images for eg. when no changes are made to the operator then this will not work. Best to have its own version.

CORE_VERSION and OPERATOR/EXPORTER version will always be same. So, need required to maintain a separate ENV.

@amityt is this version anything different from this https://github.com/litmuschaos/litmus/blob/395a4cf2f673fb384017e82e908a41ffb62509b6/litmus-portal/cluster-k8s-manifest.yml#L418
We already need this for the upgrade agent and it's also being accessed in the server already here https://github.com/litmuschaos/litmus/blob/395a4cf2f673fb384017e82e908a41ffb62509b6/litmus-portal/graphql-server/server.go#L43
I think we can just reuse that, no need for a new version.

Hi @rajdas98 @gdsoumya This API is specific to only the workflow related components like runner, k8s etc. As per the user requirement, he/she can update the env and the version will reflect in the workflow manifests.

@Jonsy13  We can close this PR. The changes are already added in this PR https://github.com/litmuschaos/litmus/pull/3595

Closing this PR as this change is already merged as part of https://github.com/litmuschaos/litmus/pull/3595.


Weird networking on Windows 10

Hi.
I've had a lot of problems getting testcontainers to work with networking and Windows 10.
I've basically implemented the code from the "Creating custom networks" section from the homepage https://www.testcontainers.org/features/networking/ (except I've changed "foo" to "my-server" and "bar" to "my-client")
This does not work, with the following output from the client side:
Connecting to my-server:8080 (<IP_ADDRESS>:8080)
wget: can't connect to remote host (<IP_ADDRESS>): Connection refused

Which I interpret as the client being able to find the other container, but the connection is being cut by some intermediate means.
The weird thing is that I have created the same example in WSL (not WSL2, neither on the client or docker backend) using shell scripts, and it works!
Here's a docker network inpect output of the one network created by me (docker-test-network) and the testcontainers one.
[     {         "Name": "docker-test-network",         "Id": "fa5c30c915cf245f3552dfe44ebc66604bb1cf7c698884526b88f274c47c1324",         "Created": "2021-03-18T13:49:13.5312317Z",         "Scope": "local",         "Driver": "bridge",         "EnableIPv6": false,         "IPAM": {             "Driver": "default",             "Options": {},             "Config": [                 {                     "Subnet": "<IP_ADDRESS>/16",                     "Gateway": "<IP_ADDRESS>"                 }             ]         },         "Internal": false,         "Attachable": false,         "Ingress": false,         "ConfigFrom": {             "Network": ""         },         "ConfigOnly": false,         "Containers": {},         "Options": {},         "Labels": {}     },     {         "Name": "7d511be3-6b13-4689-8414-3c5f21a38763",         "Id": "a839ba7f7d9c03e3e90784ca1efac6e07a838012adbd7918f6133d6187ede883",         "Created": "2021-03-18T14:30:03.9193692Z",         "Scope": "local",         "Driver": "bridge",         "EnableIPv6": false,         "IPAM": {             "Driver": "default",             "Options": null,             "Config": [                 {                     "Subnet": "<IP_ADDRESS>/20",                     "Gateway": "<IP_ADDRESS>"                 }             ]         },         "Internal": false,         "Attachable": false,         "Ingress": false,         "ConfigFrom": {             "Network": ""         },         "ConfigOnly": false,         "Containers": {             "24fd5d988e941945ac9f1933547455b81b69f94a07c63c52533a56ea0833f1ae": {                 "Name": "loving_dubinsky",                 "EndpointID": "d31747b09c7220289b9eb19ffc01b28476a8c3e86e1c86d5bfba9ad93f4d097a",                 "MacAddress": "02:42:c0:a8:00:02",                 "IPv4Address": "<IP_ADDRESS>/20",                 "IPv6Address": ""             },             "47be6ee2cb615636f542ae0b083fe4fa107611d59de1c4ed48ce87878547e0a0": {                 "Name": "admiring_austin",                 "EndpointID": "a1a2abaf5d51591f6819b4361ea61368b320a965f1b8eea444aa9e6fbeb235d0",                 "MacAddress": "02:42:c0:a8:00:03",                 "IPv4Address": "<IP_ADDRESS>/20",                 "IPv6Address": ""             }         },         "Options": {},         "Labels": {             "org.testcontainers": "true",             "org.testcontainers.sessionId": "a554d7ae-ca99-4009-8baf-becdfe64c890"         }     } ]
Am I doing something wrong in setting up the network, creating the containers, or something else?
Really hope someone can help :-)

Hi @kyrrek,
This is really a question to Docker and not Testcontainers. Especially given that it works fine with WSL, but not with WSL2. Since the WSL2 backend is new, it might as well be a bug. Consider reporting to them.

Thanks for the reply. Just one more details, the scripts are runnning under WSL, and the Java code is running on Windows (through Intellij). But you're probably right. I'll try to raise an issue with Docker.


Added init subcommand to generate base config

headscale init sqlite generates a working headscale environment (i.e., config.json, derp.yaml and wireguard private.key)
This helps my life a lot when developing in a reusable Vagrant environment.

You know you can quite easily have Vagrant pre-configure the machine for you? ;) Not negating this feature, but if you want I could help you with the Vagrant config.

You know you can quite easily have Vagrant pre-configure the machine for you? ;) Not negating this feature, but if you want I could help you with the Vagrant config.

I know! :) But for convenience I'd like to merge it. It would be a common solution for both Vagrant or classic environments. Also, removes the dependency on wireguard-tools packages, as you can generate the private.key with headscale CLI

@cure @ohdearaugustin
You are very right. I do agree that the idea of this PR makes sense, and its quite convenient (in particular removing the need for wireguard-tools to be installed to generate the wg key). However, how the configuration is defined in a string + removing the check on a valid config at Headscale start is suboptimal / crap 😅
I do agree with @ohdearaugustin on dropping the need for a config.json file altogether. Running only on ENV vars is perfectly feasible, and pretty easy with viper.
I am closing this PR, and will think on a better way to implement this.

Not that there's much secrets in configuration besides the database
password, but oftentimes files are easier to keep secret than environment
of a process, so if possible I'd rather keep the ability to feed it a
config file.
On Sun, 25 Jul 2021, 18:24 Juan Font, @.***> wrote:

@cure https://github.com/cure @ohdearaugustin
https://github.com/ohdearaugustin
You are very right. I do agree that the idea of this PR makes sense, and
its quite convenient (in particular removing the need for wireguard-tools
to be installed to generate the wg key). However, how the configuration is
defined in a string + removing the check on a valid config at Headscale
start is suboptimal / crap 😅
I do agree with @ohdearaugustin https://github.com/ohdearaugustin on
dropping the need for a config.json file altogether. Running only on ENV
vars is perfectly feasible, and pretty easy with viper.
I am closing this PR, and will think on a better way to implement this.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/juanfont/headscale/pull/57#issuecomment-886225510,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAE4DZK766UFVLUTFGE5YYLTZQ3EHANCNFSM5AUFFTRQ
.

@viq I didn't meant to replace the ability to use a config file. This should still be kept. I rather see it as addition to make headscale only configurable from the environment. As a lot of containerization take use of it and it is easier to configure. File permission are in my opinion rather harder to get right with containerization. For security reason you can use for example systemd and lock it down really a lot, so the environment is also secured.
Therefore move the default setting into the program itself. I was thinking about using viper with default values to make the executable runable without any additional configuration file needed.


[Containerapp] az containerapp env create: Remove not used argument --docker-bridge-cidr

Related command

Description

Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Containerapp

please rerun relative tests to verify this PR won't bring any unexpected change.

please rerun relative tests to verify this PR won't bring any unexpected change.

Hi @yanzhudd
Rerun relative tests and add one test for the deprecated argument.


[hacs.repository.integration.danobot.entity-controller] Missing manifest file.

Hi All,
get this error:
[hacs.repository.integration.danobot.entity-controller] Missing manifest file.
Running hassio 0.99.2 on a RPi 3B+ Docker config

me too, 0.93.3 on hassio + nuc
2019-10-06 18:29:45 ERROR (MainThread) [hacs.repository.integration.danobot.entity-controller] Missing manifest file.
2019-10-06 18:29:45 ERROR (MainThread) [hacs] Validation for danobot/entity-controller failed.

Everyone get that, you can ignore it

ok, thanks

Thanks. Add to ignore list in my brain (programming done) 😊

HA 0.99.3
The same error...

2019-10-08 22:20:18 ERROR (MainThread) [hacs.repository.integration.danobot.entity-controller] Missing manifest file.
2019-10-08 22:20:18 ERROR (MainThread) [hacs] Validation for danobot/entity-controller failed.

Hi, I have this error too, but I also have this other one that I want to know if its related with?
2019-10-09 09:28:28 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 226, in async_setup_platform
    self.hass, self.config, self.domain, platform_type
  File "/usr/src/homeassistant/homeassistant/setup.py", line 227, in async_prepare_setup_platform
    integration = await loader.async_get_integration(hass, platform_name)
  File "/usr/src/homeassistant/homeassistant/loader.py", line 278, in async_get_integration
    Integration.resolve_from_root, hass, components, domain
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/loader.py", line 154, in resolve_from_root
    manifest_path = pathlib.Path(base) / domain / "manifest.json"
  File "/usr/local/lib/python3.7/pathlib.py", line 908, in __truediv__
    return self._make_child((key,))
  File "/usr/local/lib/python3.7/pathlib.py", line 695, in _make_child
    drv, root, parts = self._parse_args(args)
  File "/usr/local/lib/python3.7/pathlib.py", line 649, in _parse_args
    a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType

It is not related

Closed by https://github.com/danobot/entity-controller/pull/83


The configurations cwd is not working

OS: Ubuntu20.04
VSCode version:  1.73.1
CodeLLDB version: v1.8.1
Compiler: clang
Debuggee: d8 (v8)
I set  cwd as ${workspaceFolder}/out/debug in launch.json configurations.
However, when I enter platform shell pwd in debug console, the output is always ${workspaceFolder}/ instead of ${workspaceFolder}/out. This make lldb not locating the source code.
Obviously the configurations.cwd is not working

cwd sets the debuggee's working directory, not debugger's.
relativePathBase is what's used by the debugger for relative path resolution.

@vadimcn Thanks for the explanation, but relativePathBase seems also not work for me.
My directory structure is like this:
Project
....src
....out
........bin

I configure like this:
    {
      "name": "lldb launch",
      "type": "lldb",
      "request": "launch",
      "program": "${workspaceFolder}/out/bin/d8",
      "args": ["/home/xxx/test/test.js"],
      "stopOnEntry": false,
      "relativePathBase":"${workspaceFolder}/out/bin",
    },

The breakpoints can never be hitten at all. However, if I cd to ${workspaceFolder}/out/bin and use lldb in shell, it works well.

What do you use to build.your.binary?

What do you use to build.your.binary?

GN and ninja
https://v8.dev/docs/build-gn#manual

I haven't ever build V8 myself (nor used GN), but according to documentation it seems to re-write source file paths?   In which case, information here regarding Bazel applies to GN as well.

I didn't say it is exactly like Bazel, just that GN seems to rewrite paths, similarly to Bazel.  You'll need to find out what exactly gets encoded into the debug info as explained on that wiki page.

Thanks for your patience.
The debug info is like this for example:
../../src/d8/d8.cc
gen/src/regexp/special-case.cc

Obviously, it regard ${workspaceFolder}/out/bin as the relative base, I am not sure why "relativePathBase":"${workspaceFolder}/out/bin" dosen't work.

Ah. hm...   I guess relativePathBase would fix paths in the debugger->vscode direction, but it does not transform in the opposite direction.    So LLDB cannot match the absolute file path to what it finds in the debug info (a relative path).  I think your only recourse here is to try the set up path mapping from ../../src to ${workspaceRoot}/src.   Not sure it this is going to work - IIRC, there were bugs in LLDB related to re-mapping relative paths.


Fix bug when gitea request fails

Trying to print out the http status codes
results in a deferencing null when they are not
set. Thus crashing the cmd in case of an error.
As we don't know the error, it's best to just
print the error here.
Tradeoff
There may be cases in which the body is helpful to have, however that would need to be checked.
I think further down other cases handle HTTP codes so I don't think information is lost

Thanks for the pullrequest, the go-scm library used in this project is a generic one that support different git provider but not all of them return error message via http request so it makes sense to ignore the request body in this case


Empty CSV files?

Hello!
All the generated CSVs are always empty, except for the "_timestamp__Classic_Platform_Status.csv" that lists this:
us-east-1, Disabled
us-west-1, Disabled
us-west-2, Disabled
eu-west-1, Disabled
ap-southeast-1, Disabled
ap-southeast-2, Disabled
ap-northeast-1, Disabled
sa-east-1, Disabled
Also, the error text file is empty.
I tried with

python3 py-Classic-Resource-Finder.py -p default
python3 py-Classic-Resource-Finder.py -p "default"
python3 py-Classic-Resource-Finder.py -p 'default'
python3 py-Classic-Resource-Finder.py

But the result is always the same (empty files except for "_Classic_Platform_Status.csv"). But this is strange as in the AWS account, there are at least four "classic load balancers" in eu-west-1.
Any ideas? Thanks!
(The files are generated in a folder with the AWS account id as name. And on the CLI, I can still do "aws ec2 describe-volume-status", "aws s3 ls", "aws ec2 describe-vpc-classic-link", ... . So there's nothing fishy with my cli.)

Hello Jörg,
Thank you for posting.  As part of the EC2 Classic retirement, we are only retiring Classic Load Balancers not running in a VPC (thus running in EC2-Classic). Classic Load Balancers which are running in a VPC are not currently being retired as part of this.
You can confirm that these Classic Load Balancers are running in a VPC by running aws elb describe-load-balancers in the AWS CLI.
If you see an output like this your Classic Load Balancer is running in a VPC and the script ran correctly (Note VPCId value):
[cloudshell-user@ip-10-0-127-234 ~]$ aws elb describe-load-balancers
{
    "LoadBalancerDescriptions": [
        {

                "LoadBalancerName": "VPC-CLB",
                "DNSName": "VPC-CLB-484*******.us-west-2.elb.amazonaws.com",
                "CanonicalHostedZoneName": "VPC-CLB-48*******.us-west-2.elb.amazonaws.com",
                "CanonicalHostedZoneNameID": "Z1H*******",
                "ListenerDescriptions": [
                    {
                        "Listener": {
                            "Protocol": "HTTP",
                            "LoadBalancerPort": 80,
                            "InstanceProtocol": "HTTP",
                            "InstancePort": 80
                        },
                        "PolicyNames": []
                    }
                ],
                "Policies": {
                    "AppCookieStickinessPolicies": [],
                    "LBCookieStickinessPolicies": [],
                    "OtherPolicies": []
                },
                "BackendServerDescriptions": [],
                "AvailabilityZones": [
                    "us-west-2b",
                    "us-west-2a"
                ],
                "Subnets": [
                    "subnet-f6******",
                    "subnet-fe******"
                ],
                "VPCId": "vpc-d9******",
                "Instances": [],
                "HealthCheck": {
                    "Target": "HTTP:80/index.html",
                    "Interval": 30,
                    "Timeout": 5,
                    "UnhealthyThreshold": 2,
                    "HealthyThreshold": 10
                },
                "SourceSecurityGroup": {
                    "OwnerAlias": "13************",
                    "GroupName": "Closed"
                },
                "SecurityGroups": [
                    "sg-07**************"
                ],
                "CreatedTime": "2021-03-12T19:45:29.910000+00:00",
                "Scheme": "internet-facing"

        }
    ]
}

If, however, you see this, where there is no VPCId key value pair, then something went wrong and the Classic Load Balancers are running in EC2-Classic. If that is the case for some reason, please reopen this, so we can investigate further.
[cloudshell-user@ip-10-0-127-234 ~]$ aws elb describe-load-balancers
{
    "LoadBalancerDescriptions": [
        {

            "LoadBalancerName": "Classic-CLB",
            "DNSName": "Classic-CLB-12******.us-west-2.elb.amazonaws.com",
            "CanonicalHostedZoneName": "Classic-CLB-12******.us-west-2.elb.amazonaws.com",
            "CanonicalHostedZoneNameID": "Z1H******",
            "ListenerDescriptions": [
                {
                    "Listener": {
                        "Protocol": "HTTP",
                        "LoadBalancerPort": 80,
                        "InstanceProtocol": "HTTP",
                        "InstancePort": 80
                    },
                    "PolicyNames": []
                }
            ],
            "Policies": {
                "AppCookieStickinessPolicies": [],
                "LBCookieStickinessPolicies": [],
                "OtherPolicies": []
            },
            "BackendServerDescriptions": [],
            "AvailabilityZones": [
                "us-west-2a"
            ],
            "Subnets": [],
            "Instances": [],
            "HealthCheck": {
                "Target": "HTTP:80/index.html",
                "Interval": 30,
                "Timeout": 5,
                "UnhealthyThreshold": 2,
                "HealthyThreshold": 10
            },
            "SourceSecurityGroup": {
                "OwnerAlias": "amazon-elb",
                "GroupName": "amazon-elb-sg"
            },
            "SecurityGroups": [],
            "CreatedTime": "2021-03-12T19:44:18.430000+00:00",
            "Scheme": "internet-facing"

        }
    ]
}

You're correct - I've got a non-empty VPCId for all the load-balancers. Thanks a lot!


How to remove/hide "search box"?

I would like to remove/hide Search Box.
And then create my own custom.
Please help me.

Now it work fine
new Tabular.Table({
  name: "Books",
 searching: false


Determine packages to install prior to installing

Old logic (pseudocode)
for krate in to_install {
    pkg = determine_pkg(krate);
    install_pkg(pkg);
}

New logic
let pkgs = to_install.into_iter(|krate| determine_pkg(krate));
pkgs.into_iter(|pkg| install_pkg(pkg));

This has the short term benefit of dumping most error messages out earlier in the process (eg a typo in the second package name).
Longer term, it might help with #9741 - as only the second loop would be parallelized. First loop shouldn't be parallelized because it would lead to redundant registry/git updates.

r? @ehuss
(rust-highfive has picked a reviewer for you, use r? to override)

Looks good to me, thanks!

@bors: r+
Thanks again!

:pushpin: Commit f9c2d04592b1c4f48e9b4c30cba23f2136101cfc has been approved by alexcrichton

:hourglass: Testing commit f9c2d04592b1c4f48e9b4c30cba23f2136101cfc with merge b64c96bfa0c9401624185aafd5c76f11b7eb24bd...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing b64c96bfa0c9401624185aafd5c76f11b7eb24bd to master...


Create flatpickr.l10n.ua.js

Add Ukrainian locale.

I saw Ukrainian locale with uk shortcut. No need in my commit anymore.


Docs: Roadmap

Summary
What changed?
Adding an MVP roadmap page to our Gestalt docs
Why?
We're trying to both create more visibility of what Gestalt plans to work on across the year as well as build the habit to refer to the Gestalt site for any/all info to Gestalt.

@ponori Oh and don't forget to fix the merge conflict


Load Shedding for Keycloak

Adjust the thread pool size of Keycloak. Create a list of max number of queued elements. Drive the discussion.
Have a meeting to create a shared understanding what strategies are available and why load shedding is a good thing.

We are going to be restricting the number of worker thread in Keycloak pod to minimize impact from jgroups thread pool congestion until ISPN-14780 is fixed, then we can scale  the worker threads a bit more as the total thread pool default will be 200 instead of the 100 which is now.
Keycloak PR: https://github.com/keycloak/keycloak-benchmark/pull/452
Keycloak Benchmark PR: https://github.com/keycloak/keycloak/commit/a1e1fd8d5da08068f39ea4a100ffc1a12763b1b0


Uncommitted files warning on branch checkout?

If there are files that haven't been committed yet and the user tries to checkout a new branch, does a warning pop up? Or does Elegit just checkout without a problem?

There is a notification, but it's confusing: "You can't switch to that branch because there would be a merge conflict. Stash your changes or resolve conflicts first."


Update swift-system dependency to 0.0.2

Swift System 0.0.1 is really old and doesn't build on Android.
Information

Package version: main
Platform version: Android 11
Swift version: 5.4

Checklist

[x] If possible, I've reproduced the issue using the main branch of this package.
[x] I've searched for existing GitHub issues.

Oh, just noticed that you updated this dependency for swift-collections last month, so I added that repo to my daily CI for Android, which cross-compiles it with Swift 5.4 and runs its tests in the Android emulator.

Closed by #14.


feat[cartesian]: Absolute k indexation

Syntax: field[K_at(...)] Backends:  numpyanddace:cpu`
Can index with literals, parameters, externals and fields.
ToDo:

change syntax to field.at(K=...)
more protection & test for unwanted syntax (I, J in particular)

Bad remote, sorry


Property initialisation

Not implemented for Tuples, Lambdas, type alias,
Rework for other types along lines of arraylist initialisation

lamdda done - still need to check equality checking between empty lambdas

We've decided you can't print a function. Should you be able to check functions for equality ?
https://github.com/elan-language/IDE/blob/a346a28f039e88b701b35c5c4620152419a0c4d5/elan/src/test/compiler/T49_EqualityTesting.test.ts#L216
I'd prefer the answer to be no

I'd be OK with no. ;-)


Advantage over Matlab HDF5 support?

Hello
Since this is working only with Matlab and not Octave, what is the advantage of this library over using the readily available HDF5 functions in Matlab?
https://www.mathworks.com/help/matlab/hdf5-files.html
I'm sorry if this is a silly question, I haven't looked at your code or examples at all...
I was just wondering about the use of this code in jsnirf, and questioning the necessity of many additional dependencies to Brainstorm if we want to reuse some of you code. Related with this PR: https://github.com/brainstorm-tools/brainstorm3/pull/283
Thanks!

@ftadel, I was about to start a conversation with your team on file formats, glad you you mentioned this.

what is the advantage of this library over using the readily available HDF5 functions in Matlab?

the main appeal of easyh5 is its simplicity and usability. it is super compact and extremely easy to use.
the corresponding functions to loadh5/saveh5 in matlab's high-level H5 interface are h5read/h5write, but the latter have a lot of limitations.
For starters, they can't directly save a struct, a struct array, or a cell array. It only accepts numerical or string arrays as input. They are also unable to directly handle other advanced data structures, such as tables, graph, containers.Map etc, unless you use the low-level interfaces and serialize those manually.
In comparison, easyh5 accepts literally all matlab data structures, serializing those and storing in a single hdf5 file. It also reads any hdf5 file and obtain a convenient struct/containers.Map object to store the complex hierarchical data.
Secondly, even one calls low-level interface, without special settings, matlab's functions do not save data fields in their creation order. This can be quite annoying as some data records requires an appearance order. This was fixed in easyh5 https://github.com/fangq/easyh5/issues/1
Last but not the least, hdf5 is a general data storage format, like JSON and MessagePack, and it does not have internal data-structure vocabularies to serialize complex data structures. People will have to serialize those by themselves, and use non-standardized fields. For example, hdf5 does not have built-in complex numbers, people have been storing those in composite fields as r/i, Re/Im or Real/Imag etc. This makes it difficult to share and parse.
My solution to the above issue is to adopt the JData specification I defined for JSON-based data storage, aiming for standardizing the vocabularies of serializing complex data structures.
you can see my other related thoughts related to hdf5 in this BIDS thread:
https://github.com/bids-standard/bids-specification/issues/197#issuecomment-541107503

This is all very clear, thanks!
Which types of data does the SNIRF data format need to store in HDF5 that the Matlab functions can't store easily?
Only cell-arrays, or more than this?

The SNIRF data is basically a struct if mapped to a matlab data structure.
Unfortunately, matlab's h5read/h5write can only deal with numerical arrays. To support a hierarchical data, you will have to loop over subfields and call the low-level functions, which in the end is exactly what easyh5's [loadh5](https://github.com/fangq/easyh5/blob/master/loadh5.m)/[saveh5](https://github.com/fangq/easyh5/blob/master/saveh5.m) do.

in other words, yes, you can write a manual code use matlab's low level H5 APIs, but it will end up with same thing as the loadh5/saveh5 code structure but less generalizable.

take a look at the loadh5/saveh5 code and you can see they are super compact (yet very general).


Unify fusion

~Please merge #1550 fiest.~

jenkins, test this please.

Jenkins CI test (for commit 860a0c19157b7bb31b2f88a5378f18ab410adcf4, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)


Stop depending on asu.edu's images

Mainly because they are not compressed.
//www.asu.edu/asuthemes/4.0-rsp.1/images/asu_arrow_closed.gif
//www.asu.edu/asuthemes/4.0-rsp.1/images/ipad_close.gif
//www.asu.edu/asuthemes/4.0-rsp.1/images/asu_search_btn.png

Related to #48

This task will be superseded by https://github.com/gios-asu/ASU-Web-Standards-Wordpress-Theme/issues/79