always use latest logging image version

The images are always built and tagged with latest before running
logging install and CI, so just hard code the use of latest for
all of the logging images.

The worry with this approach is that if the images didn't get built etc they are just pulled and it's going to lead to super difficult debugging when you can't figure out which version you actually used. So a better approach is to tag them appropriately after the build. We use the commit SHA for Origin so we know the images don't exist anywhere else.


Make compatibility tests explicitly check out ibc-go

Description

closes: #XXXX
By explicitly checking out ibc-go, it means this workflow can be imported in other workflows, e.g.
    uses: cosmos/ibc-go/.github/workflows/e2e-compatibility-workflow-call.yaml@main
    with:
      test-file-directory: foo
      test-suite: bar

And it will use the e2e tests in this repo. As opposed to looking for them in the repo the calling workflow is in.
Commit Message / Changelog Entry
e2e: enabling compatibility tests to be usable from other repositories' CI.

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[x] Provide a commit message to be used for the changelog entry in the PR description for review.
[x] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

:crown:


FreeBSD support fixes to dep/openssl/CMakefile.txt  & small changes to README.md

Hi Petr,
If a later version of python was released in FreeBSD's package collection "pkg info python37" would not return anything, but "pkg info python" will report any version installed correctly.
Also making it clear that Retdec MUST be in "/usr/local" if not the command like "freebsd-update -r 12.1-RELEASE upgrade" will remove Retdec files. (as the Retdec installation files should not be in operating system directories)
The "dep/openssl/CMakefile.txt" needed FreeBSD code otherwise the entire build would fail.
I did not include the ".cirrus.yml" file as it fails to build on "cirrus-ci.com" and as yet I don't know why. It builds and runs perfectly locally, so I need to install another instance of FreeBSD from scratch to see what I am missing.
Thanks Greg

During the cirrus-ci build this error occurs BUT not on my local machine. Is there a way of accessing the error log?
....
[  4%] No install step for 'yara'
[  4%] Completed 'yara'
[  4%] Built target yara
Scanning dependencies of target yaramod-project
[  4%] Creating directories for 'yaramod-project'
[  4%] Performing download step (download, verify and extract) for 'yaramod-project'
[ 20%] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DFAPacketizerEmitter.cpp.o
-- yaramod-project download command succeeded.  See also /tmp/cirrus-ci-build/build/external/src/yaramod-project-stamp/yaramod-project-download-.log
[  4%] No update step for 'yaramod-project'
[  4%] No patch step for 'yaramod-project'
[  4%] Performing configure step for 'yaramod-project'
-- yaramod-project configure command succeeded.  See also /tmp/cirrus-ci-build/build/external/src/yaramod-project-stamp/yaramod-project-configure-.log
[  5%] Performing build step for 'yaramod-project'
CMake Error at /tmp/cirrus-ci-build/build/external/src/yaramod-project-stamp/yaramod-project-build-Release.cmake:49 (message):
Command failed: 2
'make'
See also
/tmp/cirrus-ci-build/build/external/src/yaramod-project-stamp/yaramod-project-build-*.log
--- external/src/yaramod-project-stamp/yaramod-project-build ---
*** [external/src/yaramod-project-stamp/yaramod-project-build] Error code 1
make[2]: stopped in /tmp/cirrus-ci-build/build
1 error
make[2]: stopped in /tmp/cirrus-ci-build/build
--- deps/yaramod/CMakeFiles/yaramod-project.dir/all ---
*** [deps/yaramod/CMakeFiles/yaramod-project.dir/all] Error code 2
make[1]: stopped in /tmp/cirrus-ci-build/build
A failure has been detected in another branch of the parallel make
make[5]: stopped in /tmp/cirrus-ci-build/build/external/src/llvm-project-build
--- utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/all ---
*** [utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/all] Error code 2
make[4]: stopped in /tmp/cirrus-ci-build/build/external/src/llvm-project-build
1 error
make[4]: stopped in /tmp/cirrus-ci-build/build/external/src/llvm-project-build
*** [all] Error code 2
make[3]: stopped in /tmp/cirrus-ci-build/build/external/src/llvm-project-build
1 error
make[3]: stopped in /tmp/cirrus-ci-build/build/external/src/llvm-project-build
--- external/src/llvm-project-stamp/llvm-project-build ---
*** [external/src/llvm-project-stamp/llvm-project-build] Error code 2
make[2]: stopped in /tmp/cirrus-ci-build/build
1 error
make[2]: stopped in /tmp/cirrus-ci-build/build
--- deps/llvm/CMakeFiles/llvm-project.dir/all ---
*** [deps/llvm/CMakeFiles/llvm-project.dir/all] Error code 2
make[1]: stopped in /tmp/cirrus-ci-build/build
2 errors
make[1]: stopped in /tmp/cirrus-ci-build/build
*** [all] Error code 2
make: stopped in /tmp/cirrus-ci-build/build
1 error
make: stopped in /tmp/cirrus-ci-build/build
Exit status: 2

During the cirrus-ci build this error occurs BUT not on my local machine. Is there a way of accessing the error log?

I am sorry but I have no experience with this CI service. As a workaround, maybe you can add
cat /tmp/cirrus-ci-build/build/external/src/yaramod-project-stamp/yaramod-project-build-*.log

into the build instructions so that the contents are shown in the output from the build on the web.

Recommended viewing https://www.youtube.com/watch?v=kx2xp7IQNSc - National (USA) Security Agency decompiler Ghidra... 20+ years in development.

I am closing this PR as (1) there was no activity in the last three months and (2) RetDec now uses OpenSSL from the system (i.e. the deps/openssl/CMakeLists.txt file no longer exists).

OK thanks.


Unregistered outgoing packet class

Reason: io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: Unregistered outgoing packet class: com.github.steveice10.mc.protocol.packet.ingame.client.player.ClientPlayerStatePacket

Are you making sure you're in the in-game protocol state before you send the packet?

Ohh no i'm not, thanks


Remove unnecessary reflection usage in android backend

This fixes #5785 because the new R8 obfuscator removes AndroidInput classes which were instantiated with reflection.

Just to confirm, you're testing this running on API 9?

The problem is that I don't got any old device with api level 9. I tried using the emulator, but it doesn't start. I also tried an api level 10 emulator, but it also doesn't start. So I'm not sure how I can test it. All emulators until api level 14 are deprecated

We can't accept this until it has been tested on API 9, or we increase the minimum sdk version. We can't just assume it is safe.

I just want to point out that libGDX doesn't work on API 9 anyway, so the best solution would be to change the minimum API level to 14 (as discussed).

I think we agree to move the API level to 14. Let's do that with this pull request also.

Is there any other location to increase the minSdk? I can't find more

Thanks! I think you got all the minSDK locations. I merged it for better or worse. :)
This also addresses https://github.com/libgdx/libgdx/issues/5755

I think me can also remove some proguard rules


acme-challenge validation broken in 2.0.9 version - question "Try in default browser?" is missing

I would like to create certificates using unattended batch file and deploy acme-challenge files manually to the server. But it is not possible with 2.0.9 version.
The question [--test] Try in default browser? does not show up.
I do not want to use any automatic validation methods via FTP, SelfHosting or give any FTP access to the software. I would like to write acme-challenge files to the local disk, upload them manually to the server, then continue the validation process (with asking of user) as it was in 1.9.9 version.
I've tried all possible combination with --validation parameters but no success in 2.0.9
It does not work!
What is worst 2.0.9 even deletes created acme-challenge files.
wacs.exe  --test  --verbose  --target manual  --host "www.mydomain.com"  --emailaddress<EMAIL_ADDRESS>--validation filesystem  --webroot "c:\win-acme-2.0.9"

It works excellent in 1.9.9 version as in picture below.
letsencrypt.exe  --test  --verbose  --plugin manual  --manualhost "www.mydomain.com"  --emailaddress<EMAIL_ADDRESS> --webroot "c:\win-acme-1.9.9"

Please add a possibility to upload acme-challenge files manually without using ftp, webdav in unattended mode.
How it should work.

I generate a real certificate.
win-acme plugin writes acme-challenge files to the specified folder on a local disk, it stops and waits for a confirmation like a "next" button.
I manually upload the files to the server.
Then I confirm "next" and win-acme do the rest of job.

Regards.

The Try in default browser? option will be back in the next release in --test mode (which you can also use on the production endpoint when you specify --baseuri https://acme-v02.api.letsencrypt.org/).
Regarding your other idea, I don't really see much need for it once the workaround with --test is back in place, but if it turns out there are more people interested I will consider it.

Thank you.


Option to use chat_id in telegram bot notifier

Expected behaviour:
my-task:
  notify:
    entries:
      message: Notification body.
      via:
        - telegram:
            bot_token: token
            parse_mode: markdown
            disable_previews: no
            recipients:
              - username: my-user-name
              - group: my-group-name
              - fullname:
                  first: my-first-name
                  sur: my-sur-name
              - chat_id:

It would be much more convenient if users can directly use chat_id to define telegram notification channel as shown above.
The problem with username and fullname is that you have to make sure there are recent messages in the chat, otherwise chat_id retrieval will fail. Using chat_id is simply more reliable.
Actual behaviour:
Now only username, fullname or group is allowed as config for the telegram notifier.
Steps to reproduce:
N/A
Config:
N/A
Log:
N/A
Additional information:

FlexGet version: 3.11.46
Python version: 3.11
Installation method: docker
Using daemon (yes/no): yes
OS and version: Synology 7.2
Link to crash log: N/A

Fixed in #4083, this can be closed now,
But one thing to note is that if the chat id you directly fill in has been migrated, it will cause an additional HTTP request each time the program runs. If your group has been migrated, you should fill in the new chat id.
If you are capable, you can also improve the relevant code (Store the old and new chat ids in the data table and make relevant judgments when the program runs.).

@vivodi thank you so much for taking time to fix it!


Js debugger stopped working after hibernation

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.71.2
OS Version: Windows

Steps to Reproduce:

Run VS Code
Open some project
Attach debugger to existing tab in chrome
Shutdown you system into hibernation mode for some time
Return from hibernation mode

After this steps, debugger will not work. You will not be able to stop it, or restart. Only solution is to restart vscode.

Duplicates https://github.com/microsoft/vscode/issues/147050


Login issue after log out

Just downloaded a fresh copy and when you log in then log out you will get a stuck log in screen with no errors other then the client saying error connecting to server.
Mac running latest version of java 8.66. Client is a non edited MITB client.

I know this issue but I don't believe its the best way to fix

I have fixed it though

@WizardJesse1 share the fix

@lare96 i would love to share all my fixes if i knew how to setup github rofl

pastebin it if you have to

@lare96 I have been going to @garyttierney and telling him the bugs so i will give him the fixes if he wants to push them for me lolol

@Lmctruck30 http://recordit.co/QU9JhihGXD this?

epic nice

This is still an issue, @Major- am able to replicate it.

Rats

cc @garyttierney is this fixed in your local copy?

@Major- was never able to reproduce

cc @ryleykimmel please look into this as I haven't managed to reproduce it either

I can reproduce this every time. Log in, log out, try to log back in. Using master w/ no edits

I am also able to reproduce this issue. Using master without any edits and running the 377 release.

Hi, this also happens for me. Unedited, 377. Jesse's fix seems to work, though.


Invalid connection string name makes portal non-responsive

I can only repro on Chrome and Edge, not IE. IE doesn't show the error popup at all, so it must be an IE compat issue.
I had an invalid connection string reference in my function.json, and the Functions portal became unresponsive. I didn't see any obvious issues in the F12 Console. See https://github.com/Azure/azure-webjobs-sdk-script/issues/841 for the specific problematic function

https://github.com/projectkudu/AzureFunctionsPortal/commit/cb05da69c4386aaa4fc36c17900a651b02d55c78


[Swift] Add interface ArrowArrayHolderBuilder

Describe the enhancement requested
Need to be able to build an ArrowArrayHolder without needing to know the generic type of the ArrowArrayBuilder.
This will be used for Nested types and arrow Codable implementation
Component(s)
Swift

Issue resolved by pull request 41946
https://github.com/apache/arrow/pull/41946


onTrashComment not firing

I've got an onTrashComment event inside my plugin but it doesn't seem to be firing when the status of a comment is set to Trash :(
Is there something I'm missing?
craft()->on('comments.onTrashComment', function($event) {
    $comment = $event->params['comment'];
    CommentsRatingPlugin::log('Trashed');
	craft()->commentsRating->trashRating($comment);
});

Just tested this locally, and is working fine for me? This won't be triggered through the CP's element status change, so that might be where things are tripping up?

Yeah possibly. I'm changing the status in the CP for Comments to 'Trashed' but it doesn't do it. How do comments get trashed other than in the CP?

Sure, there's a direct controller action for the front-end side of things, but makes sense to trigger this also from the CP. If you wouldn't mind giving the latest master a go, that should trigger properly now (when saving a comment via the CP, or when using the element actions).


Add support for adding keys for nsupdate

Hey,
I am in the middle of evaluating a foreman puppet setup, trying out all the foreman smart proxy features. I want to do everything through puppet and u guys have pretty good modules already for that. But i can't find how I would be able to add a key to bind for foremans nsupdates, shoulnd this be supported by this module or am I missing something ?
Best regards

That's a good question I didn't really consider. When I still used bind + dhcpd the services were on the same machine so limiting to localhost was sufficient for me. It looks like this is only doable with custom includes and not trivial out of the box.
Pull requests are highly appreciated but a description of what you'd expect is also very useful.

I will look into if i can make a pull request happen for that.
What i expect as a minimum for this is to do the exact steps that are pointed out in the Foreman Manual (<IP_ADDRESS> BIND):

Add a key to the named.conf.
Add update-policy for that key to specified zone.
Optional but would be a big plus: Create the key through this module.

Let me know if you want help. Also very early work in progress reviews are not a problem.


Notification COMMAND_SKIP_TO_PREVIOUS action need to click twice

Media3 Version
1.0.0-beta01
Devices that reproduce the issue
Pixel5 running Android 12
Samsung galaxy note 10 5G running Android 11
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
Yes
Reproduction steps

run demo-session
click "Album Folder", "Youtube Audio Library Rock", "Awakening"
wait 5s
click prev button in notification

Expected result
Skip to previous item.
Actual result
Just skip to begin of current item.
Media
Not applicable
Bug Report

[ ] You will email the zip file produced by adb bugreport to<EMAIL_ADDRESS>after filing this issue.

This is working as intended because the skip to previous action only seeks back to the beginning of the item once the playback position has passed Player.getMaxSeekToPreviousPosition(). See the documentation of Player.seekToPrevious for more details: https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/Player.html#seekToPrevious()


(Stupid) questions about coverage reports

Coverage reporting via https://codecov.io/gh/zephyrproject-rtos/zephyr was recently introduced, and coverage reports usually lead to a bunch of question. It's proposed to have this ticket to dump them.

A separate issue: Codecov seems to report 1 hit per line, even in lines which are obviously hit many times.

A separate issue: Codecov seems to report 1 hit per line, even in lines which are obviously hit many times.

Do you have a link for that? I believe I saw a hit count somewhere in its reports. So, do you say that this count shows 1, while it's logically provable (e.g. from context) that a particular line was hit more?

Do you have a link for that?
For example:
https://codecov.io/gh/zephyrproject-rtos/zephyr/src/master/arch/posix/core/posix_core.c
posix_swap() is called each time the kernel does a swap.. That will be quite a few times during the whole sanitycheck run.

A separate thing to be aware:
If you do changes to code which is not run by sanitycheck in any of the native_posix tests or samples, codecov will not tell that the diff coverage is 0%.
Instead it will tell you it is n/a and that those files are not tracked.

this is now resolved. thank you @aescolar-ot


[process-agent] Create process discovery check

What does this PR do?
This PR changes three things about the process agent:

Process aent now runs by default (specifically when process_config.enabled = false)
Adds a lightweight check that collects basic metadata on running processes, and sends them in a new ProcessDiscovery payload.

Motivation
This is part of a larger goal to allow for a feature that suggests to customers possible integrations that they can enable.
Additional Notes
Anything else we should know when reviewing?
Describe how to test your changes
Write here in detail how you have tested your changes
and instructions on how this should be tested in QA.
Describe or link instructions to set up environment
for testing, if the process requires more than just
running the agent on one of the supported platforms.
Checklist

[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] The need-change/operator and need-change/helm labels has been applied if applicable.
[ ] The appropriate team/.. label has been applied, if known.
[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] The config template has been updated if applicable.

Note: Adding GitHub labels is only possible for contributors with write access.

Actually I just realized that the discovery check does not have chunking logics like we have in process check and container check. This is in place to avoid sending a huge payload to the intake and cause intake to somehow OOM or crash.
https://github.com/DataDog/datadog-agent/blob/be59410d2c6d6321289287d8563e2c17493f369f/pkg/process/checks/process.go#L270-L286
.

Oh yes! This is quite a big deal! I will see if I can add batching logic to the process-discovery check


Windows shortcut is to "dbeaver.exe -nl en"

System information:

Windows 10
DBeaver version: Version <IP_ADDRESS>107041908

Describe the problem you're observing:
The windows installer creates a shortcut to dbeaver and hardcodes the locale to English dbeaver.exe -nl en (or possibly the language set during installation - but English will be used when a user can't find his own language in the installer).
The manual and info window in dbeaver suggests that change of the locale should be done in dbeaver.ini but no change in ini file will help if the user clicks on the shortcut afterwards, since it overwrites ini setting.
I suggest the shortcut should be without the locale parameter

One more argument for the change: dbeaver update overwrites the shortcut files again forcing en localization.
I would still consider it a bug (though a minor one)

duplicates #12771


Scripts to train/test/eval on custom data.

Hi, thanks for a great work.
Could you provide a script to train/test/eval on custom data? Readme only suggests to prepare data in MVSNet format, but didn't say how to run on it.

Thanks, it works like a charm.


Adding Errors

I don't understand why when I write this in my interaction :
errors.add(:no_way)

and I have the following error :
NoMethodError - undefined method `no_way'

I need to write this :
errors.add(:no_way, 'no_way')

in order to correctly add an error.
The add_sym method has the same behavior.

This behavior actually comes from ActiveModel. In general, you can't add errors to an attribute that doesn't exist on a model. So this code will raise an error:
class Example < ActiveInteraction::Base
  def execute
    errors.add :no_way
  end
end
Example.run!

While this code won't:
class Example < ActiveInteraction::Base
  boolean :no_way
  def execute
    errors.add :no_way
  end
end
Example.run!

Ok. Thank you for the answer.


[BUG]

Describe the bug

  Warning  FailedMount             2m36s                kubelet                  Unable to attach or mount volumes: unmounted volumes=[storage-cloned], unattached volumes=[kube-api-access-wz2r4 storage-cloned]: timed out waiting for the condition
  Warning  FailedMount             28s (x2 over 2m28s)  kubelet                  MountVolume.MountDevice failed for volume "pvc-e9b4c5e1-1c5d-4428-bd0e-a02167136cbf" : rpc error: code = DeadlineExceeded desc = context deadline exceeded
  Warning  FailedMount             20s                  kubelet                  Unable to attach or mount volumes: unmounted volumes=[storage-cloned], unattached volumes=[storage-cloned kube-api-access-wz2r4]: timed out waiting for the condition

To Reproduce

Expected behavior
volume should mount
Support bundle for troubleshooting

Environment

Longhorn version:
Impacted volume (PV):
Installation method (e.g. Rancher Catalog App/Helm/Kubectl):
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:

Number of control plane nodes in the cluster:
Number of worker nodes in the cluster:

Node config

OS type and version:
Kernel version:
CPU per node:
Memory per node:
Disk type (e.g. SSD/NVMe/HDD):
Network bandwidth between the nodes (Gbps):

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Number of Longhorn volumes in the cluster:

Additional context

Workaround and Mitigation

Duplicated: https://github.com/longhorn/longhorn/issues/9908


Use non-shared netty dependency for Spring Boot integration

Expected Behavior
Users should be able to use native compilation (with GraalVM) for applications using the Dapr Java Spring Boot integration.
Actual Behavior
The netty-shaded library doesn't work with native compilation.
Steps to Reproduce the Problem
Create a Spring Boot application, add the Spring Boot Dapr integration and try to compile a native image:
<dependency>
	<groupId>io.dapr.spring</groupId>
	<artifactId>dapr-spring-boot-starter</artifactId>
	<version>${dapr-java-sdk.alpha-version}</version>
</dependency>

Workaround
<dependency>
	<groupId>io.dapr.spring</groupId>
	<artifactId>dapr-spring-boot-starter</artifactId>
	<version>${dapr-java-sdk.alpha-version}</version>
	<exclusions>
	       <exclusion>
          	        <groupId>io.grpc</groupId>
			<artifactId>grpc-netty-shaded</artifactId>
		</exclusion>
	</exclusions>
</dependency>
<dependency>
	<groupId>io.grpc</groupId>
	<artifactId>grpc-netty</artifactId>
	<version>${grpc.version}</version>
</dependency>

You need to make sure that ${grpc.version} matches with the one included by the Java Dapr SDK.
@artursouza can you give me some background about why we need the shaded version? Do you have anything against using the non-shaded version when integrating with Spring Boot?
Release Note

RELEASE NOTE:

@salaboy here is a tiny PR: https://github.com/dapr/java-sdk/pull/1137 that should at least make things a little bit more consistent.

@artur-ciocanu do you think we can now add this exclusion to the Spring Boot integration?

@salaboy sorry for the delays, I am little bit busy, I will try to look into this by EOW.

@salaboy sorry for the delays, I am little bit busy, I will try to look into this by EOW.

No hurry.. async communications is all good.. don't feel the pressure to answer this on the same day I write a comment :)


Extract bits

An argument added to Extract Files/Scan For Embedded Files.
These Scanners/Extractors operate on the byte level currently.
Scan for embedded files fails to detect magic bytes if they are offset by even 1 bit.
Extract Files relies on the scanForFileTypes function.
In this PR I have modified the function to have a flag that enables it to scan on the bit level as well as on the byte level. Meaning that even if the Magic Bytes are offset they will still be detected and then hopefully extracted to a file.

Hey!  This pull request has gotten rather old and that's our fault.  This project stopped being actively maintained for a while and it looks like your pull request has started to gather dust.  Would you be able to update your branch to the latest version of CyberChef and we'll give it a review?

Hey, this PR has remained without updates for four weeks now.  I'll close it now, but feel free to re-open if you find time to contribute! 😄


Italian strings.js for 1.7

Hi,
I have some problems of memory for to change this PR from Master to release. Can you help me please?

@Denisov21 you'll need to open another PR AFAIK (that's what I had to do :joy_cat:) to change the target branch to release

Ok, I will do coming soon @petetnt!

I'm not sure but have you tried git rebase release?
Be aware that git rebase can be a "disruptive" command...

@ficristo it's an GitHub limitation, when you send a PR you are locked to branch

@petetnt oh, I didn't know...

I will try to change this PR!

See https://github.com/isaacs/github/issues/18 it's just not possible :ice_cream:

Tagging @nicolo-ribaudo for review.

@Denisov21 I've finished the review

Thank @nicolo-ribaudo.
I will check and update this PR until Sunday, 07.02

@nicolo-ribaudo
I'm ready for another check!! PR update!

LGTM Merging.
Thanks @Denisov21 @nicolo-ribaudo


[vite] The CJS build of Vite's Node API is deprecated

Steps to reproduce

Start
See the console

Current behavior

The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

Expected behavior
No warning.
Context
The warning goes away if I remove Pigment CSS from the vite config, but then, I'm not using Pigment CSS anymore 🙃
diff --git a/vite.config.js b/vite.config.js
index 78b5110..b39ba6c 100644
--- a/vite.config.js
+++ b/vite.config.js
@@ -1,6 +1,5 @@
 import { defineConfig } from 'vite';
 import react from '@vitejs/plugin-react';
-import { pigment, extendTheme } from '@pigment-css/vite-plugin';

 // To learn more about theming, visit https://github.com/mui/material-ui/blob/master/packages/zero-runtime/README.md#theming
 const theme = extendTheme({

Your environment

npx @mui/envinfo
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: -

+1 on this!

@oliviertassinari Did you find a resolution to this?

Is there a timeframe for this getting fixed?

Awesome, thank you for the update!


usm: format traced programs as json

What does this PR do?
Populates USM traced_programs value to the status command of the agent.

Motivation
A change that was missing from the original PR https://github.com/DataDog/datadog-agent/pull/26328

Additional Notes
Enable system-probe with TLS monitoring:
service_monitoring_config:
  enabled: true
  tls:
    go:
      enabled: true
    native:
      enabled: true
  enable_http_monitoring: true

Run the agent
Run agent status command
Expect to see
============
System Probe
============

  Status: Running
  Uptime: 23m15.000285038s
  Last Updated: 2024-06-26 19:29:54 IDT / 2024-06-26 16:29:54 UTC<PHONE_NUMBER>000)

  USM
  ===
    Status: running
    Last Check: 2024-06-26 19:06:29 IDT / 2024-06-26 16:06:29 UTC<PHONE_NUMBER>000)
    Traced Programs: [
      {
        "FilePath": "/usr/bin/external_proxy",
        "PIDs": [
          435877
        ],
        "ProgramType": "go-tls"
      }
    ]

  NPM
  ===
    Status: Running
    Last Check: 2024-06-26 19:06:25 IDT / 2024-06-26 16:06:25 UTC<PHONE_NUMBER>000)

  Event Monitor
  ================
    Status: Running

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


linsearch

Expected Behavior
I try to use easy-linsearch and linsearch but both have same issue : empty files
First, I have try easy-linsearch with the line :
"$ mmseqs easy-linsearch /work/cbelliardo/6-ensembl_clust/metag_G-rosea.fa /bighub/hub/DB/mmseq_swissprot/swissprot out tmp --search-type 2 -v 3 --threads 8"
but the output ( out file ) is empty without error message.
Then i have try whit linsearch cmd.
$ mmseqs createdb metag_G-rosea.fa queryDB
$ mmseqs linsearch queryDB /bighub/hub/DB/mmseq_swissprot/swissprot resultDB tmp
$ mmseqs convertalis queryDB /bighub/hub/DB/mmseq_swissprot/swissprot resultDB resultDB.m8
I have the same issue.
The  metag_G-rosea.fa file is a fasta file with 80 charactere by line. I have try with search and it's work really well. so, the file seems to be ok.
MMseqs Output (for bugs)
createdb metag_G-rosea.fa queryDB
MMseqs Version:              	10.6d92c
Max sequence length          	65535
Split seq. by length         	true
Database type                	0
Do not shuffle input database	true
Offset of numeric ids        	0
Compressed                   	0
Verbosity                    	3
Assuming DNA database, forcing parameter --dont-split-seq-by-len true
Converting sequences
[
Time for merging into queryDB_h by mergeResults: 0h 0m 0s 107ms
Time for merging into queryDB by mergeResults: 0h 0m 0s 116ms
Time for merging into queryDB.lookup by mergeResults: 0h 0m 0s 5ms
Time for processing: 0h 0m 0s 479ms
Tmp tmp folder does not exist or is not a directory.
extractorfs queryDB tmp/2730103712073724212/q_orfs_aa --min-length 30 --max-length 32734 --max-gaps<PHONE_NUMBER> --contig-start-mode 2 --contig-end-mode 2 --orf-start-mode 1 --forward-frames 1,2,3 --reverse-frames
1,2,3 --translation-table 1 --translate 1 --use-all-table-starts 0 --id-offset 0 --threads 64 --compressed 0 -v 3
[=================================================================] 101 0s 57ms
Time for merging into tmp/2730103712073724212/q_orfs_aa_h by mergeResults: 0h 0m 0s 174ms
Time for merging into tmp/2730103712073724212/q_orfs_aa by mergeResults: 0h 0m 0s 182ms
Time for processing: 0h 0m 0s 869ms
kmersearch tmp/2730103712073724212/q_orfs_aa /bighub/hub/DB/mmseq_swissprot/swissprot.linidx tmp/2730103712073724212/search/pref --seed-sub-mat nucl:nucleotide.out,aa:blosum62.out --kmer-per-seq 21 --mask 0 --ma
sk-lower-case 0 --cov-mode 0 -c 0 --max-seq-len 65535 --pick-n-sim-kmer 1 --split-memory-limit 0 --threads 64 --compressed 0 -v 3
kmersearch tmp/2730103712073724212/q_orfs_aa /bighub/hub/DB/mmseq_swissprot/swissprot.linidx tmp/2730103712073724212/search/pref --seed-sub-mat nucl:nucleotide.out,aa:blosum62.out --kmer-per-seq 21 --mask 0 --ma
sk-lower-case 0 --cov-mode 0 -c 0 --max-seq-len 65535 --pick-n-sim-kmer 1 --split-memory-limit 0 --threads 64 --compressed 0 -v 3
Estimated memory consumption 4 MB
Reduced amino acid alphabet: (A S T) (C) (D B N) (E Q Z) (F Y) (G) (H) (I V) (K R) (L J M) (P) (W) (X)
Process file into 1 parts
Generate k-mers list 0
[=================================================================] 14.93K 0s 32ms
Time for fill: 0h 0m 0s 35ms
Sort kmer ... Time for sort: 0h 0m 0s 39ms
Time to find k-mers: 0h 0m 0s 608ms
Time to sort: 0h 0m 0s 0ms
Time for merging into tmp/2730103712073724212/search/pref by mergeResults: 0h 0m 0s 5ms
Time for processing: 0h 0m 0s 729ms
rescorediagonal /bighub/hub/DB/mmseq_swissprot/swissprot.linidx tmp/2730103712073724212/q_orfs_aa tmp/2730103712073724212/search/pref tmp/2730103712073724212/search/reverse_ungapaln --sub-mat nucl:nucleotide.out
,aa:blosum62.out --rescore-mode 2 --filter-hits 0 -e 0.001 -c 0.9 -a 0 --cov-mode 1 --min-seq-id 0 --min-aln-len 0 --seq-id-mode 0 --add-self-matches 0 --sort-results 0 --db-load-mode 0 --threads 64 --compressed
0 -v 3
Index version: 15
Generated by:  10.6d92c
ScoreMatrix:  :
[=================================================================] 323 0s 253ms
Time for merging into tmp/2730103712073724212/search/reverse_ungapaln by mergeResults: 0h 0m 0s 177ms
Time for processing: 0h 0m 0s 855ms
filterdb tmp/2730103712073724212/search/pref tmp/2730103712073724212/search/pref_filter --filter-file tmp/2730103712073724212/search/reverse_ungapaln --positive-filter 0
Filtering with filter files.
[=================================================================] 323 0s 12ms
Time for merging into tmp/2730103712073724212/search/pref_filter by mergeResults: 0h 0m 0s 171ms
Time for processing: 0h 0m 0s 397ms
align /bighub/hub/DB/mmseq_swissprot/swissprot.linidx tmp/2730103712073724212/q_orfs_aa tmp/2730103712073724212/search/pref_filter tmp/2730103712073724212/search/reverse_aln --sub-mat nucl:nucleotide.out,aa:blos
um62.out -a 0 --alignment-mode 2 -e 100000 --min-seq-id 0 --min-aln-len 0 --seq-id-mode 0 --alt-ali 0 -c 0 --cov-mode 0 --max-seq-len 65535 --comp-bias-corr 1 --realign 0 --max-rejected<PHONE_NUMBER> --max-accept 2
147483647 --add-self-matches 0 --db-load-mode 0 --pca 1 --pcb 1.5 --score-bias 0 --gap-open 11 --gap-extend 1 --threads 64 --compressed 0 -v 3
Index version: 15
Generated by:  10.6d92c
ScoreMatrix:  :
Compute score and coverage
Query database size: 561568 type: Aminoacid
Target database size: 14926 type: Aminoacid
Calculation of alignments
[=================================================================] 323 0s 62ms
Time for merging into tmp/2730103712073724212/search/reverse_aln by mergeResults: 0h 0m 0s 109ms
335 alignments calculated.
323 sequence pairs passed the thresholds (0.964179 of overall calculated).
1.000000 hits per query sequence.
Time for processing: 0h 0m 0s 427ms
swapresults /bighub/hub/DB/mmseq_swissprot/swissprot.linidx tmp/2730103712073724212/q_orfs_aa tmp/2730103712073724212/search/reverse_aln tmp/2730103712073724212/aln --sub-mat nucl:nucleotide.out,aa:blosum62.out
-e 0.001 --split-memory-limit 0 --gap-open 11 --gap-extend 1 --threads 64 --compressed 0 --db-load-mode 0 -v 3
Index version: 15
Generated by:  10.6d92c
ScoreMatrix:  :
Computing offsets.
[=================================================================] 323 0s 3ms
Reading results.
[=================================================================] 323 0s 0ms
Output database: tmp/2730103712073724212/aln
[=================================================================] 14.93K 0s 154ms
Time for merging into tmp/2730103712073724212/aln by mergeResults: 0h 0m 0s 147ms
Time for processing: 0h 0m 0s 394ms
offsetalignment queryDB tmp/2730103712073724212/q_orfs_aa /bighub/hub/DB/mmseq_swissprot/swissprot.linidx /bighub/hub/DB/mmseq_swissprot/swissprot.linidx tmp/2730103712073724212/aln resultDB --chain-alignments 0
--merge-query 1 --search-type 0 --threads 64 --compressed 0 --db-load-mode 0 -v 3
Index version: 15
Generated by:  10.6d92c
ScoreMatrix:  :
Computing ORF lookup
Computing contig offsets
Computing contig lookup
Time for contig lookup: 0h 0m 0s 2ms
Writing results to: resultDB
==[===============================================================] 101 0s 3ms
Time for merging into resultDB by mergeResults: 0h 0m 0s 169ms
Time for processing: 0h 0m 1s 64ms
convertalis queryDB /bighub/hub/DB/mmseq_swissprot/swissprot resultDB resultDB.m8
MMseqs Version:        	10.6d92c
Substitution matrix    	nucl:nucleotide.out,aa:blosum62.out
Alignment format       	0
Format alignment output	query,target,pident,alnlen,mismatch,gapopen,qstart,qend,tstart,tend,evalue,bits
Translation table      	1
Gap open cost          	11
Gap extension cost     	1
Database output        	false
Preload mode           	0
Search type            	0
Threads                	64
Compressed             	0
Verbosity              	3
[=================================================================] 101 0s 8ms
Time for merging into resultDB.m8 by mergeResults: 0h 0m 0s 160ms
Time for processing: 0h 0m 1s 306ms
Context
There is no informations in the manual about this cmd, maybe i miss up some steps
Your Environment
I use the version  10.6d92c install with conda

Server specifications
512 GO RAM; 64 CPU

Operating system and version: linux last release

Thanks a lot for your help !

I'd recommend to use the normal search. Linsearch is still heavy in development and not ready for general use and has several important limitations that have to be documented and users have to be aware before using the new workflow.
However, If you can send me the input sequences I can try to reproduce the issue.

@milot-mirdita is there any update on this issue?
I'm on an Intel Mac (multithreading disabled) with MMseqs2 release 15.6f452 and still seeing very strange behavior from this pipeline.
Using two protein FASTA files (~225 normal-length proteins each), where there are many homologs spanning the full range of percent identities and the following command:
mmseqs easy-linsearch aa_1.fasta aa_2.fasta easy-linsearch-out.tsv mmseqs_tmp

I get an empty output file, despite a really nice set of outputs from the easy-search pipeline in just a few seconds.
Even stranger, when I try to make easy-linsearch only find high-identity HSPs, with the following:
mmseqs easy-linsearch aa_1.fasta aa_2.fasta easy-linsearch-out.tsv mmseqs_tmp --min-seq-id 0.8 -c 0.8

The memory utilization as profiled in the Apple Activity Monitor very quickly exceeds 250 GB (system only has 64 GB, so I think this means we are in disk swap territory), and I'm not sure how long it would take to finish - I killed the job after about a half hour of waiting.
Input files are attached, in case you have any interest in attempting to reproduce the issue.
aa_1.fasta.gz
aa_2.fasta.gz


As a user I can modify current fields

...so that I can keep my data up to date

EditCommand already implemented


.bazel.rc and .bazel support

resolve #1713

hi @JimiC, thanks for the review.
did you mean this:
+   extensions: ['.bazelrc', 'bazel.rc','bazel.bazelrc'],
-      filenamesGlob: [
-       'bazel',
-    ],
-   extensionsGlob: ['bazelrc'],

Yes. Since filename attribute is set to true all entries in extensions will be considered as filenames. In order to support a filename extension, you will have to add another bazel icon declaration without the filename attribute. We have plenty of other cases in there.

Can you ellaborate please

#3 of comment is misseing

It's a filename, isn't it?

I'm talking abiut #2 of your screeny.

I remove it, sorry, bad example. I think #2 is not a extension but a filename.  But I'm not sure.

And who knows, maybe they use also something like baze.*.bazelrc (where * can be one of: 'dev', 'prod', 'debug' etc).

And that's why I wanted the extension author to jump in and take care of this.

I've reviewed the docs and can't see a mention of a file extension. I've even searched through github repos and no clue about this as a file extension.  According to what I can see in the docs it still looks good to me.

#1714 comment is a pure conjecture and you cannot infer from the quote that the second one is a file extension. Provided that it's repeated also in the third line I think it's not very wild to guess that it's just a filename.
I prefer to publish this as it is, even at the risk of being restrictive (if later on we discover that this was, indeed, a file extension) than the other way around.

The only think I can see clearly is that we should have to learn Bazel to be 100% sure 😜

OK. I rest my case.


Fix params and logic for responsible tracking

Status
PRODUCTION / DEVELOPMENT
Description
A few sentences describing the overall goals of the pull request's commits.
Related PRs
List related PRs against other branches:

branch
PR

other_pr_production
link

other_pr_master
link

Todos

[ ] Tests
[ ] Documentation

Steps to Test or Reproduce
Outline the steps to test or reproduce the PR here.
roslaunch pkg_A executable_A

The car should move.

we cherry picked these changes into pacmod_apex branch.


Model does not show up in WebGl (localhost) when the marker is changed

I used the example scene (ARMarker Rotate and Scale) in Project ARWT. I added the model and an outer image after creating it with AR.js Marker Training (https://jeromeetienne.github.io/AR.js/three.js/examples/marker-training/examples/generator.html ). Follow the instructions on your site. But when built WebGL app (test in LocalHost), the AR model is not displayed, the camera screen blinks continuously.
Looking forward to the support.
Thank you very much!

I got the same issue and fixed it by using the latest versions of ar.js. In the index.html file of the WebAR template (Assets/WebGLTemplates/WebAR), replace the .js scripts references from local js/lib folder to the web urls. Here's my new index.html :
<!DOCTYPE html>

    <meta charset="utf-8">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>Unity WebGL Player | WebGL Test AR</title>

      --MARKERS--

I added that to my template, still not showing a model...I have to be missing something?
Using Mac OS 11.5.2, Unity 2021.1.22f1, on the phone side I am using an iPhone Xs Max running 14.6 and Safari to view the page. In player settings, I am using the supplied template from the ARWT-Master Project. Uploaded to my webserver with all the files, changes to the template are showing when I look at the source...just not image recognition and no model showing up.


fix: handle 0n as from/to blocks in getContractEvents

Fixes CNCT-1987

#4919  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @joaquim-verges and the rest of your teammates on  Graphite


[WIP] Add Client::getLocation() helper

See the individual commits for details why this is work-in-progress.
Any input is welcome!

I  think I've implemented that feature here : https://github.com/floriansimon1/php-soap-react/commit/913d3faf65f28a808126d85f400b7ec52a75b8d7
It's in the last lines of my ClientEncoder changes ;)

I've implemented that feature here : floriansimon1@913d3fa

This is true :) Despite some differences in the implementation, I'd rather keep these two features separate, hence this PR.
I've just updated the PR and resolved the outstanding issues. Would you care to review this? :)

I did not know that individual webservice function could have different locations.

I've just updated the PR and resolved the outstanding issues. Would you care to review this? :)
I just did. What I'd add is a way to get the WSDL location, because when you use a webservice with a single location for each function, you don't want to specify a function name, because it would add unintuitive boilerplate to your code. Moreover, having to specify a function name introduces an unnecessary source of error. What if you mistype the function name ? Or the function name does not exist anymore ?

Otherwise, I have to say I like your implementation more than my own. Thank you for your work !

What I'd add is a way to get the WSDL location, because when you use a webservice with a single location for each function, you don't want to specify a function name, because it would add unintuitive boilerplate to your code. Moreover, having to specify a function name introduces an unnecessary source of error. What if you mistype the function name ? Or the function name does not exist anymore ?

Thanks for bringing this up, I think this is a valid concern :+1:
I've just updated the implementation to also accept a function index.
As such, you can now always call it like this for your use case:
$location = $client->getLocation(0);


Withdrawals into queue in single function

Rework of @rolfyone's PR (#3032)
There were some minor bugs introduced in the last one. I think I cleaned it up but have not reworked tests.
I'd prefer to only do so once we have consensus on the general feature
Original comment:
Partially to initiate a discussion.
Basically use a single pipeline for withdrawal processing to simplify the flow and reduce the need for full validator scans during epoch processing.
This should make the feature much more testable amongst other benefits, and makes withdrawal of partial or full amounts an equal priority based on your position in the validator list.
The timing remains approximately equal to previous, except there may have previously been 4 exits per epoch to add that are now just done during sweeping, where previously they were done as a priority
Danny's comments:
Note, that this does have some shifts in "fairness" wrt when you become withdrawable and when you actually are withdrawn. It used to be immediate but not it could be quite a long time between when you become withdrawable and when withdrawn (on the order of a week at current vset size). Additioanlly, some people might become withdrawable sooner than others (thus exited sooner in some cases) but might then be later in the sweep.
I like the previous iteration a bit better for a few reasons:

The two mechanisms were isolated so were easier to test on the spec side. That said reworking tests shouldn't be too hard
The timing and fairness thing. In the prior mechanism, once you become withdrawable you get to get all of your ETH out immediately rather than waiting for what might be a very long partial withdrawals sweep. I understand the complexity of doing a full validator sweep to find the withdrawable folks but note that it's not like those that are withdrawable can change quickly, you can easily have the ones to check precomputed.

Re (2). If this is a major engineering complexity/hurdle, then I'm okay with the changes. But it does seem a bit weird to prioritize partial withdrawals (which usually all the set are ready for) over the much smaller (and more important) set of full withdrawals.

Like the simplicity of this.  the downside is that full withdrawals won't necessarily be processed immediately the validator is withdrawable, but I don't see that being a major issue.
I do want to go back to MAX_WITHDRAWALS_PER_EPOCH, however.  The current value of 256 will work through the entire current validator active set in around 7 days.  Looking at current rewards, an average validator would expect to earn around 0.025 ETH in that 7 day period, That seems like quite a small number as the "unit of value" to be going to the effort of transferring across chains.
The other related, but somewhat more nebulous, concern I have is that I can envisage smart contracts wanting to obtain proof on-chain that a withdrawal has come from a certain validator.  Providing and verifying a proof for a 0.025 ETH amount could end up eating a fair chunk of the value of the withdrawal.
If MAX_WITHDRAWALS_PER_EPOCH was reduced to 64 it would still get through the current active set in a month, and would be skimming values of around 0.1 ETH for active validators.  It would reduce the number of withdrawal operations on-chain, and would results in proofs taking up significantly less ETH as a percentage of the transfer.  Is there a reason outside of responsiveness (which I do understand) to keep this at 256?

Think the rate the rate they target my binace account is ridiculousl.  Binance are not cooperative
Sent from Outlook for iOShttps://aka.ms/o0ukef

From: Jim McDonald @.>
Sent: Monday, October 17, 2022 8:26:00 AM
To: ethereum/consensus-specs @.>
Cc: Subscribed @.***>
Subject: Re: [ethereum/consensus-specs] Withdrawals into queue in single function (PR #3042)
Like the simplicity of this. the downside is that full withdrawals won't necessarily be processed immediately the validator is withdrawable, but I don't see that being a major issue.
I do want to go back to MAX_WITHDRAWALS_PER_EPOCH, however. The current value of 256 will work through the entire current validator active set in around 7 days. Looking at current rewards, an average validator would expect to earn around 0.025 ETH in that 7 day period, That seems like quite a small number as the "unit of value" to be going to the effort of transferring across chains.
The other related, but somewhat more nebulous, concern I have is that I can envisage smart contracts wanting to obtain proof on-chain that a withdrawal has come from a certain validator. Providing and verifying a proof for a 0.025 ETH amount could end up eating a fair chunk of the value of the withdrawal.
If MAX_WITHDRAWALS_PER_EPOCH was reduced to 64 it would still get through the current active set in a month, and would be skimming values of around 0.1 ETH for active validators. It would reduce the number of withdrawal operations on-chain, and would results in proofs taking up significantly less ETH as a percentage of the transfer. Is there a reason outside of responsiveness (which I do understand) to keep this at 256?
—
Reply to this email directly, view it on GitHubhttps://github.com/ethereum/consensus-specs/pull/3042#issuecomment-1280060752, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AV4C5HWEAFUANIPWD6AQ4ALWDRXGRANCNFSM6AAAAAARGQGINA.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

I'll leave the same comment here as in Paul's PR, an option is to process full withrawals in the same loop as effective balance updates. That may be equivalent to the original approach without the extra loop

At least for Lodestar, the previous approach won't require a full sweep of the validator set. We do all sweeps in epoch processing in one go, essentially merging multiple spec functions into one.

At least for Lodestar, (on a preliminary look, not implemented yet) the previous approach won't require a full sweep of the validator set. We do all sweeps in epoch processing in one go, essentially merging multiple spec functions into one.

In order to do this you need to prove that doing it that way is equivalent to the specified version which explicitly adds a loop after balances changes. It needs to be checked that these processes are independent

At least for Lodestar, (on a preliminary look, not implemented yet) the previous approach won't require a full sweep of the validator set. We do all sweeps in epoch processing in one go, essentially merging multiple spec functions into one.

In order to do this you need to prove that doing it that way is equivalent to the specified version which explicitly adds a loop after balances changes. It needs to be checked that these processes are independent

Right. Then you can collect an initial list of fully withdraw-able validators at the beginning of epoch processing, and then re-check that balance > 0. If a validator gets slashed for all its balance such that it's 0, will it be considered withdrawn and not trigger a execution transaction?

To me, I don't see why full withdrawals should be prioritised, although there are definite periods where you may exit second and get processed before an earlier full exit.
Full withdrawals getting bumped to the top of the queue immediately does basically unfairly advantage them compared to active contributing members of the network, I'm not sure why the prioritisation call was made in the initial instance...
Processing them during updated balance calculation is probably ok, but the spec calling out that it's right at the end and the code being completely at odds does seem to be a little odd (if balance calculation also exits validators)...
The 'fairness' is not the reason I made the change though, it was purely reducing processing for the epoch transition.

I fixed the tests. Some notes:

Merged run_process_full_withdrawals and run_process_partial_withdrawals into run_process_withdrawals_into_queue
Since full and partial withdrawals are now in the same function, I removed randomize_state call from run_random_partial_withdrawals_test since random_state might also trigger the full withdrawal cases and lead to unexpected partial withdrawal num.

IMO opinion this PR does not add any tangible benefits in performance, while slowing full withdrawals for no reason. Partial withdrawals are processed "slowly" because we have to. Full withdrawals are processed "faster" because we can. It's purely technical, no fairness argument influences those facts.

I think we should benchmark this. How long does it realistically take to loop through the validator set? Isn't this premature optimization?

We know in teku that looping through the full set of validators is expensive and it makes any algorithm O(n) in the number of validators. So yes, we would definitely have to use an optimised version of this.
The argument for having a separate loop for full vs partial withdrawals was to make testing simpler, but that isn't the case once we need to add a cache for which validators have become withdrawn since tests would need to cover that caching. In other words, a separate loop actually expands the scope of testing required rather than reducing it since we now need to cover every way a validator may become withdrawable.
Besides which, we aim for simplicity in the way consensus works and having a single approach to withdrawal is simpler than having two different approaches depending on why the validator has balance that could be withdrawn.

I tried to make a summary table:

Solution
Pros
Cons

Separate partial func and full func
prioritize full withdrawal? (but most devs don't think it's benefit)
[@ajsutton] we're all saying we'll optimise it in clients, but then the tests for it will be written based on the simple implementation in the spec and won't provide coverage for the optimisations actual clients would need to do. Given Danny's argument for the separatation of withdrawals was to make it simpler to test, the fact it makes the tests less effective seems to be shooting ourselves in the foot.

#3042
simplest
[@dapplion] I don't find justifiable to add delays on withdrawals for the rationale of the PR. There are optimizations possible that achieve the same end without worsen the validator UX  [@etan-status] Downside is that it adds this arbitrary delay of 3-4 days on avg (but more in future) for trying to get out, during which no rewards are earned anymore. This means that exits need to be scheduled as late as possible into a withdrawal interval for a specific validator to not miss out on those rewards. This can be quite tricky because of the exit queue. Tracking the exited-but-not-yet-withdrawn validators separately is straight forward as an optimization. But please provide tests for edge case such as depositing into a validator that has already exited or fully withdrawn to re-enter the priority queue accordingly.

#3042 + loop in effective balance updates (@potuz's suggestion)
most efficient  probably closer to client's optimization?
[hww] more difficult to debug and test (but only in specs?)

My impression:

Clients will optimize the loop anyway, so the spec is less likely to be as same as the production implementation.
If (1) is true, the epoch processing tests (process_withdrawals_into_queue) may not be applied on the client side anyway.
Most devs like the simplicity of #3042 on the spec side.
#3042 may introduce some side effects, i.e., the delay. It needs to be testest properly if we go with #3042.

My read is that it’s slightly toward 👍…? 😬

There are good arguments on both sides here and I'll chime in with another view against this change :)
I think we should prioritize spec simplicity above all else, weighted against speed to ship the feature to mainnet.
There will always be things we need to do to optimize implementations in clients so I don't think this is a big ask for client teams. Caches etc have been a large source of bugs in the past and to mitigate the concern we develop/maintain a large corpus of consensus test cases. And the more the spec itself is optimized for the production/maintenance of these test cases, the better mitigation it provides against bugs due to implementation complexity.
And alongside this, I want to get to a place where we stop changing the capella spec as soon as possible so there is something stable for client teams to target by end of the year. And the best way to get stability is to stop changing the spec, i.e. do not make this change.

One big difference that this PR introduces is that the withdrawal queue is much smaller. This is the first time we have a queue in the specs and I am worried about memory fragmentation. I started implementing this in Go and all implementations we are evaluating either leak memory or suffer from continuous reallocations. Either way, if this PR passes I think it would be good to put WITHRAWAL_QUEUE_LIMIT = MAX_WITHRAWALS_PER_EPOCH or some aggressive limit like this, effectively capping the queue size to a constant bound since anyway we add to this queue on epoch transition and we cannot empty it during the coming epoch.
Having the queue of constant size allows us to optimize this further by keeping a rolling index and adding on place. This would be application specific, but I imagine all languages will benefit from having a constant size rather than potentially a big chunk of the validator set.

Coming to think about this: if we go with rolling sweeps as in this PR, there's no need for the queue at all: knowing what are the next withdrawal indices determines uniquely the next withdrawals that a block can include, so we can just check against that and there's not even the need to keep the queue in the state it seems.

@potuz One of the nice things about the queue is that it fixes the balance of the withdrawal at the point where it was processed in process_epoch. One thing that concerns me about the queueless approach (and https://github.com/ethereum/consensus-specs/pull/3068) is that we have to deal with the complexity of balances changing after every block, meaning that whatever cache we use for balances needs to be updated on every slot and needs to handle more frequent re-orgs, etc. It makes withdrawals feel a lot more like attestations, which we know are more complex to pack than e.g. voluntary exits which are epoch-based.

Balances can already change on each slot due to slashing.

@etan-status That doesn't effect the queued approach though, because the balance decrement for the withdrawal happens immediately on the epoch transition. If a validator that is getting partially withdrawn gets slashed before their withdrawal is processed then the slashing just applies to the remaining balance (which I think is fine).

closing due to #3068


fix getting default diffusion pipeline parameters from config

What does this PR do?
model_index.json may contain overrides of default pipeline parameters e.g.
https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/blob/main/model_index.json#L4
now these parameters are ignored at initialization stage of openvino pipeline.
Fixes # (issue)
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


User and fff_segmenter inputs

There is an inconsistency on how the input to fff_segmenter is processed versus the user input. The function call signature is API-like, requires MATLAB arrays to be defined beforehand and needs to be called from a MATLAB script or console, but it also requires user input.
I would suggest either:

removing the arguments from the function call and adding a prompt that asks for the path of the data, which is then loaded from inside the function.
Creating a second script meant to be edited by the user, where the data is loaded, and the function is called as-is.

@olivecha 👋
Thanks for the issue.
We've made significant changes to how users input the necessary data, signal names, and segmentation options. Upon execution, the fff_segmenter script now displays graphical interfaces for user input, available for both MATLAB and Octave.
Please check if these changes meet the requirements.
Best,
Thiago

This is nice, but would require a little more documentation, as it was really not clear what the fields are for a new user.

What format is expected in the "Select Data" file loader
That the sampling frequency is required. This is a bit uncommon, as most (if not all) audio formats store the sampling frequency in the metadata.
That the "Identification" fields are names of the associated variables in the .mat file. It would really help to have the variables names in the file in a drop-down menu.
Add a more detailed description of what the segmentation mode and unit choice do in the "How to use" section
If you run the App with the default "No" values, there is no output?

Adding annotations with arrows in the graphical interface figure could do the trick

Closing as this is acceptable


New rule: percent-placeholder-pattern. Some utility functions

Implements #26

I have a couple of review comments, but as it is late already, I'll return with those tomorrow.

I was away for the weekend, so unfortunately I did not have time to add my comments yet.

It would be good to have some tests for the utility functions too.

Nice test suite by the way. 👍

Thanks for the review, I added the code changes. As for utils tests - I simply copied them from stylelint repo until they expose them for plugins (and if they do so). So the tests for them are basically in stylelint repo :)


Added support for secondary stickies

Just FYI, you can always add more commits to your pull request to fix things if you didn't do them right in the first case. Git will actually allow you to edit your commits, but that's a little more advanced and easy to mess up.

I thought my pull requests were auto updating as I added commits.
On Mon, Jul 13, 2015, 10:33 PM Bryce Boe<EMAIL_ADDRESS>wrote:

Just FYI, you can always add more commits to your pull request to fix
things if you didn't do them right in the first case. Git will actually
allow you to edit your commits, but that's a little more advanced and easy
to mess up.
—
Reply to this email directly or view it on GitHub
https://github.com/praw-dev/praw/pull/466#issuecomment-121114987.

They are. Somehow there are two commits from your master branch. This one #466, which is closed, and #477 which is open. Perhaps I assumed incorrectly about how that occurred, and simply wanted to suggest a workflow to minimize extra PRs.
As a tip for the future, it's good practice to make a branch for each of your pull requests. That way your master branch can stay in sync with praw's master branch.

Thanks for the tip. I'm clearly still new to GitHub.


merge_cubes: order of dimension labels after merge

merge_cubes doesn't specify directly which order the dimension labels have been after the merge. It's implicitly clear that temporal and spatial likely have an order, but for band names for example it's not clear whether the bands are just concatenated or - for example - sorted. Behavior probably depends on the ref sys and if there's none than it concatenation, but it should be clarified.
Example 1:

temporal dimension labels cube1: 2018-..., 2020-...
temporal dimension labels cube2: 2019-...
I'd guess the result is 2018-..., 2019-..., 2020-...

Example 2:

band dimension labels cube1: B1, B4
band dimension labels cube2: B2, B5
I'd guess the result is B1, B4, B2, B5, but others could think it's B1, B2, B4, B5 as for spatial and temporal it's also having an implicit order

Opinions? How is it implemented?

I don't have a strong opinion which one feels best. For spatial and temporal it seems most logical to auto-sort. For band/other dimensions: is it that big of an issue to leave it as an implementation detail?
Side question: can labels in a  dimensions have mixed type (number and string)? If yes: how to define order for mix of number and strings? If no: what with merge_cube where first cube has number labels and second cube has string labels?

@soxofaan it's not an implementation detail because array_element allows to get an element by index, so it has to be clear for the user if it's B1, B2, B4, B5 or B1, B4, B2, B5.
In our case it is sorted in the temporal dimension, but not on the spectral one, but indeed the user cannot know that, so I'm in favour of specifying that in the process definition.
As to what specify, I don't have a strong opinion. In principle we have sort to sort a dimension, but it feels clunky to leave it to the user to having to use sort on every dimension, after having used merge_cubes...
I guess I would expect the 'continuous' dimensions to be sorted in ascending order (this includes spectral if you think of the wavelenght), and categorical ones to be in alphabetical order.

I have written the processes with the following expectations in mind:

spatial and temporal have a natural order that is always in place
bands (not necessarily spectral) are ordered as specified in metadata or processes, e.g. load_collection and filter_bands explicitly state that the order of the given array matters
all other dimension types are also ordered as specified in metadata or processes
For both bands and other dimension types, new labels are appended, e.g. see my merge_cubes example above

In theory dimension labels could be mixed types, yes.

because array_element allows to get an element by index,

yes indeed I thought about that too, and was thinking to recommend against using index based array_element after a merge_cubes. But specifying resulting order in process definition is probably better indeed.
giving it some more thought, I agree with what @m-mohr  proposes:

dimensions with natural/inherit label order (spatial and temporal): autosort
band/other dimensions (where there is no inherit order): don't autosort, just append new labels


[BUG] (Fabric 1.19.2) Infinite Reloading/Not Showing Items

Version of EMI : 0.5.0+1.19.2
Using a modified, Fabulously Optimized modpack
BUG : Version < 0.5.0+1.19.2 doesn't show items and EMI 0.5.0+1.19.2 show "EMI Reloading" since I've added new mods on my Minecraft.
Latest LOG file
Sorry for taking your time, to wait a reply I will redo my modpack and putting back one by one my mods and see if I find an issue.

Little update, in multiplayer I can use EMI but only after going in single-player. With the dev mode activated, I have those logs :

I see Create mentioned, do you recommend me to make an issue to them ?

That create issue is not causing this "infinite reload". There is some mod in your setup that is preventing the server from sending information to the client, and it's not clear from your large mod list which one it can be. You can verify this is not an EMI issue by checking if the recipe book has recipes available and if your client can see tags in F3.

Okay, thanks for enlightening me on that ^^

← After reading it, it's probably not a Farmer's Delight problem

You can try removing Farmer's Delight, which should solve the problem.

I also checked the source code of Create and there is no obvious problem.

I found out that Chipped (I'm dumb, or it's only for 1.18.2 rn ?) caused me EMI not charging at all.
That one problem solve lmao...

I found the bug! It's the Farmer's Delight Create-compat chocolate pie filling recipe - the fluid tag c:chocolates isn't used in Create, it's c:chocolate instead, so switching to the proper tag should stop it from getting index out-of-bounds issues!

srcCode Create chocolate
Nice one ! But does this one little thing that making all this mess ?

Yep! That goes through to this line, which throws if getMatchingFluidStacks returns an empty list.


missing --symlinks

I'm trying to debug some native c++ that is a part of my python project with Visual Studio. To get this working with a "pip generated" venv (after ~python 3.10) you need to add --symlinks when you create the the venv on a Windows machine. Do you think that it would be possible to add this option to uv as well? (So that the files gets created as symlinks instead as of copies..)

Do you know why this is necessary for your use-case?

I'm using it to be able to debugg a c++ extension that starts from python. (I'm running the debugging in visual studio)

For my current potential uv use case, I pass --symlinks or --copies to python -m venv explicitly to guard against the platform-specific defaults ever implicitly changing on me.
Given https://github.com/astral-sh/uv/issues/1795 though, I think I'll back off from trying to replace python -m venv for now, and stick with just replacing pip install, pip-compile, and pip-sync.

@charliermarsh I replied over there, but I'm pretty sure python -m venv is in the wrong in the way it is handling attempts to create virtual environments from within virtual environments (I had to change my current project to explicitly create layered venvs from the base Python runtime, since attempting to create them directly from the next layer down gave an unusable environment)


Nested Data is not parsed correctly

Describe the bug
Trying the example data nested objects get stringified to [object Object]

json_fields: {
      "Complete name": "name",
      City: "city",
      Telephone: "phone.mobile",
      "Telephone 2": {
        field: "phone.landline",
        callback: (value) => {
          return `Landline Phone - ${value}`;
        },
      },
    },
``` Have you tried this ?

Use callback https://vue-json-excel3.netlify.app/using-callbacks-examples.html

okay it works with field but I just want the data as is without a mapping

Object can't directly converted refer this example. https://vue-json-excel3.netlify.app/using-callbacks-examples.html

oh i get it, how should the parser know what to reduce it to.

Closing this issue


Update NPM and NuGet Task patch version.

Update NPM and NuGet Task patch version so we can hotfix

@b-barthel,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Regression with fast-glob and windows path

Hello team :)
There is a regression on windows regarding the cli push method combine with windows pathing.
This commit switch from glob to fast-glob here , unfortunately, fast-glob does not work with pattern that includes backward path separator docs
Please note that I am using forward slash in my tolgee config. Unfortunately, it is being overriden by resolve code

Hey, so switching back to regular glob would help you? Something like this?
https://github.com/tolgee/tolgee-cli/pull/121

FWIW I did the change to reduce a bit the bundle size, although tinyglobby would be even better since it only has 2 dependencies compared to fast-glob's 17 deps
Vite uses this small helper to normalise slashes to posix-style forward slashes: https://github.com/vitejs/vite/blob/dbb260499f894d495bcff3dcdf5635d015a2f563/packages/vite/src/shared/utils.ts#L26-L29

Hey, so switching back to regular glob would help you? Something like this? #121

Yes it actually would, but reverting back to previous cli version is fine in the meantime too. We are clearly not blocked.
IMO the bundle size does not matter much, as it is not meant to be bundled with web app. But as pointed by @cyyynthia, if the bundle size matters and you want to move forward keeping fast-glob and normalize the path, another option is to leverage this vite helper function docs code

Ok, it's reverted


Object Detection YOLOv3

Exception threw when run YOLOv3:
Incompatible shapes: [6,11,11,3,1] vs. [6,11,11,3,1,1]
         [[{{node define_loss/bigger_box_loss/mul_13}}]]
Tensorflow.TensorflowException: Incompatible shapes: [6,11,11,3,1] vs. [6,11,11,3,1,1]
         [[{{node define_loss/bigger_box_loss/mul_13}}]]
   at Tensorflow.BaseSession._call_tf_sessionrun(KeyValuePair`2[] feed_dict, TF_Output[] fetch_list, List`1 target_list) in
D:\SciSharp\TensorFlow.NET\src\TensorFlowNET.Core\Sessions\BaseSession.cs:line 246

I believe tf.broadcast_to can help you with that.

Upgrade to v0.12, another exception threw:
2019-11-04 06:14:26.003412: I tensorflow/core/platform/cpu_feature_guard.cc:142] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2
TensorFlow Binary v1.14.1
TensorFlow.NET v<IP_ADDRESS>
[0]: YOLOv3
11/4/2019 12:14:26 PM Starting YOLOv3
System.NotImplementedException: IsWhileContext
   at Tensorflow.Operations.ControlFlowContext.IsWhileContext()
   at Tensorflow.control_flow_util.GetContainingWhileContext(ControlFlowContext ctxt, ControlFlowContext stop_ctxt)
   at Tensorflow.control_flow_util.CheckInputFromValidContext(Operation op, Operation input_op)
   at Tensorflow.Operation._control_flow_post_processing()

System.InvalidCastException: Unable to cast object of type 'System.Single' to type 'Tensorflow.ITensorOrTensorArray'.
   at Tensorflow.control_flow_ops.<>c__19`1.<cond>b__19_3(T x) in D:\SciSharp\TensorFlow.NET\src\TensorFlowNET.Core\Operations\control_flow_ops.cs:line 504
   at System.Linq.Enumerable.SelectArrayIterator`2.ToArray()
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at Tensorflow.control_flow_ops.<>c__DisplayClass19_0`1.<cond>b__0(NameScope <p0>) in D:\SciSharp\TensorFlow.NET\src\TensorFlowNET.Core\Operations\control_flow_ops.cs:line 504
   at Tensorflow.Binding.tf_with[TIn,TOut](TIn py, Func`2 action) in D:\SciSharp\TensorFlow.NET\src\TensorFlowNET.Core\Binding.Util.cs:line 156

2019-11-05 23:01:34.084088: W tensorflow/core/framework/op_kernel.cc:1502] OP_REQUIRES failed at strided_slice_op.cc:107 : Invalid argument: Multiple ellipses in slice spec not allowed
2019-11-05 23:01:34.124432: W tensorflow/core/framework/op_kernel.cc:1502] OP_REQUIRES failed at strided_slice_op.cc:107 : Invalid argument: Multiple ellipses in slice spec not allowed
2019-11-05 23:01:34.167601: W tensorflow/core/framework/op_kernel.cc:1502] OP_REQUIRES failed at strided_slice_op.cc:107 : Invalid argument: Multiple ellipses in slice spec not allowed
2019-11-05 23:01:34.169512: W tensorflow/core/framework/op_kernel.cc:1502] OP_REQUIRES failed at strided_slice_op.cc:107 : Invalid argument: Multiple ellipses in slice spec not allowed
2019-11-05 23:01:34.174436: W tensorflow/core/framework/op_kernel.cc:1502] OP_REQUIRES failed at strided_slice_op.cc:107 : Invalid argument: Multiple ellipses in slice spec not allowed
2019-11-05 23:01:34.176334: W tensorflow/core/framework/op_kernel.cc:1502] OP_REQUIRES failed at strided_slice_op.cc:107 : Invalid argument: Multiple ellipses in slice spec not allowed
Multiple ellipses in slice spec not allowed
         [[{{node define_loss/smaller_box_loss/strided_slice_45}}]]

The node define_loss/bigger_box_loss/strided_slice_25 output shape should be shape(?, ?, ? 3)


Instagram DMS

My messages aren't showing up

same as #235 . Pls read the previous issues before creating new ones.

oh kay,, u plan on fixin it or nah ?

I am not the developer. I'm receiving all of these issues cause someone wants to use the app.  I am a subscriber of the mailing list and I am just trying to sleep


Add support for a separate color / image for padding area background

Summary of the new feature/enhancement
I'd like to be able to specify a separate background color, image, etc. for the area in the margin (padding) in the terminal window.
This uses a background image and padding value, but fails when resized to anything but the golden value of both.

In straight-up XAML, I'd do this by having a window-wide background color/image, and then specifying something different for the area inside the padding.

And yes, my use-case is ... unique :D

Well now that just screams Atari. Puts me in mind of the 800XL

Commodore 64 in my case, but does apply to a lot of 8-bit systems. 🕶

Triaging as "not a terrible idea." 😁

If you want to take a moment and make it closer to the XAML approach, you have margin and padding. The meaning of each depends on how you're looking at it. You could consider having both where the margin would be what you allow to have a different color, and the padding would be any additional space then inside the terminal client/text area.

I'm trying to recreate the gorilla tag terminal. I got everything, the font, the colors, except for this padding thing!


Improve gitter badge resolution in README (first-timers-only)

first-timers-only
This issue is tagged :octocat: first-timers-only. It is only for people who have never contributed to open source before, and are looking for an easy way take their first steps.
Consider this your chance to dip your toe into the world of open-source, and get some bragging rights for helping make drones fly, cars find charging stations, and people and goods get from place to place.
Find more first-timers-only issues here.
Thank you for your help :heart:
What is this project?
DAV (Decentralized Autonomous Vehicles) is a non-profit foundation working to build an open-source infrastructure for autonomous vehicles (cars, drones, trucks, robots, boats, and all the service providers around them) to communicate and transact with each other over blockchain.
As an organization that believes in building a large community of open-source contributors, we often create issues like this one to help people take their first few steps into the world of open source.
Captain n3m0
The DAV project you are looking at is Captain n3m0. It is a connector between the autonomous boat developed at California Maritime University and the DAV network. The goal of this boat is to help the autonomous boat find charging services, and thus allowing it to stay operational for longer times without human intervention, collecting scientific data for the university.

How you can help
In order to foster a community of developers that encourages helping each other, we started a gitter chat room just for contributors.
This chat room is linked from the top of the README file. Unfortunately the image used for the badge has quite a low resolution.
Replace the existing image on the top of the README file with a higher resolution one (https://img.shields.io/gitter/room/nwjs/nw.js.svg).
This is the markdown code required to display the link:
[![Gitter chat](https://img.shields.io/gitter/room/nwjs/nw.js.svg?style=flat-square)](https://gitter.im/DAVFoundation/DAV-Contributors)

This will look like this:

Contributing to Captain n3m0

[ ] Make sure this issue is labeled up-for-grabs and not labeled claimed, to verify no one else is working on it.
[ ] Comment in this issue that you would like to do it.
[ ] Open the Captain n3m0 GitHub page and click the ★ Star and then ⑂ Fork buttons.
[ ] Clone a copy to your local machine with $ git clone git@github.com:YOUR-GITHUB-USER-NAME/captain-n3m0.git
[ ] Add the file
[ ] Commit your changes and push your local changes back to github with $ git push -u origin master
[ ] Visit your fork on GitHub.com (https://github.com/YOUR-USER-NAME/captain-n3m0) and create a pull request for your changes.
[ ] Make sure your pull request describes exactly what you changed and references this issue (include the issue number in the title like this: #1)
[ ] Please do not fix more than one issue at a time. Your pull request should only fix what is described in this issue.

Asking for help
We appreciate your effort in taking the time to work on this issue and help out the open source community and the foundation. If you need any help, feel free to ask below or in our gitter channel. We are always happy to help 😄
We sometimes feature the work done by the community on our website. If you would like your GitHub user excluded from that, please email<EMAIL_ADDRESS>

Hi @TalAter ,
I have made the change and created a pull request.
I have tried following the well defined steps in your description.
Hope this is ok 😄

I want to try to resolve this issue

@pranav1698 This issue has already been taken. Please feel free to take on any other open issue we have.

@spoman007 Merged! Looks great. 🎆
Thank you so much ❤
I hope this is the first of many contributions to the open source :octocat: community from you.


componentWillReceiveProps is not recommended for use.

Bugs and Questions
This warning is raised by Victory Native
Checklist

[x] This is a victory-native specific issue. (Issues that also appear in victory should be opened here)

[x] I have read through the FAQ and Guides before asking a question

[x] I am using the latest version of victory-native

[x] I have checked to make sure that my versions of react-native and react-native-svg are compatible with this version of victory-native. Read about version requirements

[x] I've searched open issues to make sure I'm not opening a duplicate issue

The Problem
componentWillReceiveProps has been renamed, and is not recommended for use warning.

Fixed in latest Victory native version