Getuser throws EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

when trying to get user info Xcode 10 just throws an EXC_BAD_ACCESS (code=EXC_I386_GPFLT) error even when using the get user from tests

Could you share your steps ?

[-] Describe steps
[-] Function name
[-] Attach your code
[-] Attach screenshot

once I log user in I try to get info about the signed in user using handler.getuser()

As it appears from your console, the username value could not be read.
Please check the username you entered.
If you need more help, send me your Skype to check it remotley.


Can't install plugin

I can't seem to get this working on a Raspberry Pi 4 running Home Assistant in a dockerized form.
HA Version: 2023.12.3
I installed via HACS... when I attempt to install the integration on the "Devices and Integrations" page I just get this:

I also don't see anything pop up in my error log.

I recently updated the plugin to support HA 2024.6, this was the second breaking change in HA in the last year, so I assume this could be the issue. Can you check with commit 11eecaf9e584d3a7549933cd4e37ea73c38025fc?
Another issue could be the Bluetooth in HA Docker, have you got any other Bluetooth Device / Integration working?
Related to this: There is also issue #1, limiting the usable dialogs to add a device.


Update core modules for JPMS compatibility

The core NoSQLBench engine and API modules need to build cleanly with JPMS to enable sane resource bundling and management for drivers and driver developers.

The current core modules should allow for modular artifacts to be included as dependencies. Additional modularization is being deferred until it becomes a blocking issue.
This is separate from requirements that all drivers or dependencies be compatible with modular artifacts and avoid shading, which is documented elsewhere.


[MacOS] Support offline font caching on mac

Acceptance Criteria:

MacOS stores and re-uses a ttf after downloading once
use https://pub.dev/packages/path_provider_macos#-readme-tab-

This is solved for macOS in the regular path_provider package.
https://pub.dev/packages/path_provider_macos is now part of  path_provider.
I think it is safe to close this issue 😎

Indeed!


[style]: Enhance Footer UI

I want to work on this ...Could you please assign this issue to me as a GSSoc23 contributor?
Add screenshots
Before:

After Demo:

Code of Conduct

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

i am ready to help

Assigned @crocmons

i am ready to help

Good to know @krspriya, if you both wanna collaborate then do tell me then I will assign this to both of you.
Just ask @crocmons  first 👌

yeah, sure @krspriya can work on this..

@crocmons , @SurajPratap10 actually I've already been assigned this and I'm working on it

@crocmons , @SurajPratap10 actually I've already been assigned this and I'm working on it under issue #265

You work on it, whose footer will be better that I will merge? As there are so many folks that want to work on same issues and I can't deny to everyone

@SurajPratap10 Sure, Thanks
Could you send the link of Imagine-AI personal discord, so that I could join it


docker image cypress 11.1.0 error on Opensuse Tumbleweed

Hi to all,
I got this error when tried to run docker image:
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null) [194:1118/194859.882832:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported
Im running Linux Opensuse Tumbleweed on AMD64. I install all dependencies to be able to use this docker image.  Any help?

@GastonMelo
This is an old issue and the errors you mention are considered "garbage errors" which don't generally affect the outcome of Cypress tests.
If you are still seeing this error in current versions of Cypress please respond. Some of the error messages have been suppressed and some have disappeared due to updates of the version of Electron embedded in Cypress.

Closing as this is a stale problem.


KAFKA-18272: Deprecated protocol api usage should be logged at info level (3.9)

This makes it possible to enable request logs for deprecated protocol api versions without enabling it for the rest. Combined with the ability to enable/disable dynamically, it makes it a bit easier to collect the information about deprecated clients that is not available via metrics.
I manually verified that:

If the request logger is configured at INFO level, only deprecated protocol api versions are logged and they are logged at INFO level.
If the request logger is configured at DEBUG level, all requests are logged but the log level is INFO for deprecated protocol api versions and DEBUG for the rest.
If the request logger is configured at WARN level (the default), no requests are logged.

The cherry-pick from trunk had one conflict: RequestConvertToJson was rewritten from Scala to Java in trunk. In addition, I added an upgrade note for 3.9.1.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@chia7712 Since you reviewed the original PR, perhaps you can review this cherry-pick. I'll also backport it to older branches in case we end up releasing new patch releases for those. I would usually not do that, but since this helps plan future upgrades, it makes sense to backport more aggressively.

Test failures are unrelated.


Configmap with Helm

Description

Resolves https://github.com/feathr-ai/helm-charts/issues/1
How was this PR tested?

Added configmap for environment variables of Feathr
Does this PR introduce any user-facing changes?

[x] No. You can skip the rest of this section.
[ ] Yes. Make sure to clarify your proposed changes.

@blrchen
This is the command I suggested. Let me know if you need any modifications.
https://github.com/feathr-ai/helm-charts/blob/8955f83fa6f6fca9d1f9d612ef910c76e558397c/charts/README.md

@blrchen
This is the updated test document.
https://github.com/feathr-ai/helm-charts/blob/8e2829c7031e81727fc6c293bb57c5b199c490ce/charts/README.md


Fluid ArrayList performance problem

Describe the Bug
I'm just writing quests but I've noticed MSPT growing up over time for no reason.
I only have two mechanical pumps doing nothing, but after I broke them it looks like the situation went back to normal.
I don't know how I'd troubleshoot this.
Technician commented:
"yeah you need to report that to Create so they can fix it
it is also partially an issue with the code I wrote for Fabric, but Create is misusing it"

Reproduction Steps
Two mechanical pumps idling.
It seems to increase over time, because when I log in fresh into it, MSPT looks fine.
Expected Result
MSPT being regular.
Screenshots and Videos
I have a spark profile here:
https://spark.lucko.me/6Ia7bsNfsj
Crash Report or Log
No response
Operating System
Windows 10
Mod Version
0.5.0i
Minecraft Version
1.19.2
Other Mods
No response
Additional Context
No response

You should really not be instantiating a BlockApiCache just to throw it away immediately, however this is also a problem with Fabric. I'll look at possible fixes. :)

Hmmm, there is not much that I can do about this on the Fabric side. This hook is very strange: https://github.com/Fabricators-of-Create/Porting-Lib/blob/580154ecc58f025678b6dcaa49e8c4fd08cff53e/transfer/src/main/java/io/github/fabricators_of_create/porting_lib/transfer/mixin/common/ServerLevelMixin.java#L19
If you are querying a storage once you should use the API Lookup directly, there is no point in creating the cache then immediately discarding it. (As the cache needs to be kept in memory until GC'ed to correctly receive BE change notifications, which has some overhead).

Definitely not supposed to be created multiple times


Ensure subvolume snapshots is mounted to list snapshots

This is fixes an issue about how we were updating the state.yaml file after upgrades. For the corner case of running upgrades from the recovery system the<EMAIL_ADDRESS>is unmounted before upgrading the state.yaml and this mount is required to properly list available snapshots and reflect that in state.yaml.

Yes, in fact there used to be only a snapshotsUmount one, but no snapshotsMount. It was this way because there was the assumption it was only mounted once and at the very same stage for all cases. This turns not to be accurate enough when upgrading the snapshot from the recovery system (likely to be a squashfs image on a different partition).


fix: don't render VaultControls when hidden

should save us up to 400 re-rendering on load
this commit is back ported from #366 in case it doesn't get merged

@patcito can't we accomplish the same by just using active &&?

Moving render logic to a method doesn't mean the render logic doesn't get executed. The main change I see here is that you only render vault controls if a vault is active, which is a reasonable change IMO.

@patcito can't we accomplish the same by just using active &&?

Moving render logic to a method doesn't mean the render logic doesn't get executed. The main change I see here is that you only render vault controls if a vault is active, which is a reasonable change IMO.

yes you're right, I thought active was used for navigation only when loading /vaults/:address but it's also set when clicking on a vault. Just pushed a change.


NS1 - Geo Region - invalid answer metadata: "" is not a valid "country"

Version: octoDNS 0.9.4
Using the example provided in records.md, when trying to load a yaml file to ns1 for a domain the following error is thrown;
********************************************************************************
* tobyjackson.net.
********************************************************************************
* nsone (Ns1Provider)
*   Create <ARecord A 300, test.tobyjackson.net., ['<IP_ADDRESS>'], {'EU': 'Geo EU None None ['<IP_ADDRESS>']', 'NA-US-NY': 'Geo NA US NY ['<IP_ADDRESS>']', 'OC-AU': 'Geo OC AU None ['<IP_ADDRESS>']', 'NA-US-CA': 'Geo NA US CA ['<IP_ADDRESS>']'}> (config)
*   Summary: Creates=1, Updates=0, Deletes=0, Existing Records=2
********************************************************************************

2019-04-02T17:03:26  [140238595214184] INFO  Ns1Provider[nsone] apply: making changes
Traceback (most recent call last):
  File "/usr/local/bin/octodns-sync", line 10, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/site-packages/octodns/cmds/sync.py", line 39, in main
    dry_run=not args.doit, force=args.force)
  File "/usr/local/lib/python2.7/site-packages/octodns/manager.py", line 330, in sync
    total_changes += target.apply(plan)
  File "/usr/local/lib/python2.7/site-packages/octodns/provider/base.py", line 93, in apply
    self._apply(plan)
  File "/usr/local/lib/python2.7/site-packages/octodns/provider/ns1.py", line 367, in _apply
    change)
  File "/usr/local/lib/python2.7/site-packages/octodns/provider/ns1.py", line 311, in _apply_Create
    meth(name, **params)
  File "/usr/local/lib/python2.7/site-packages/ns1/zones.py", line 140, in add_X
    return record.create(callback=callback, errback=errback, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/ns1/records.py", line 130, in create
    callback=success, errback=errback, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/ns1/rest/records.py", line 113, in create
    **kwargs)
  File "/usr/local/lib/python2.7/site-packages/ns1/rest/records.py", line 124, in create_raw
    errback=errback)
  File "/usr/local/lib/python2.7/site-packages/ns1/rest/resource.py", line 73, in _make_request
    return self._transport.send(type, self._make_url(path), **kwargs)
  File "/usr/local/lib/python2.7/site-packages/ns1/rest/transport/requests.py", line 60, in send
    resp.text)
ns1.rest.errors.ResourceException: server error: invalid answer metadata: "" is not a valid "country"

yamls
# tobyjackson.net.yaml
---
? ''
: type: ALIAS
  value: example.com

test:
  geo:
    NA-US-NY:
    - <IP_ADDRESS>
    NA-US-CA:
    - <IP_ADDRESS>
    OC-AU:
    - <IP_ADDRESS>
    EU:
    - <IP_ADDRESS>
  ttl: 300
  type: A
  value: <IP_ADDRESS>

production.yaml
providers:
  config:
    class: octodns.provider.yaml.YamlProvider
    directory: ./octozones
    enforce_order: false
  nsone:
    class: octodns.provider.ns1.Ns1Provider
    api_key: env/NSONE_KEY
zones:
  tobyjackson.net.:
    sources:
      - config
    targets:
      - nsone

running a simply octodns-sync

Hrm, I haven't had a chance to dig into the geo support in the NS1 provider. I believe they did most of it on the server side. I'm not seeing anything wrong with your example and I don't know offhand what would cause that. I'm pretty booked up at the moment so I'm not sure when I'll have a chance to look. At some point in the future I'd like to look at implementing the new dynamic record type for NS1, but tbh I have no clue when I'll get a stretch of time to do it. If no one beats me to it, that's probably when i'd be able to look into this.


Codecov

Hi, Tom from Codecov here.
I noticed this repository, and I thought it would be useful to have code coverage metrics in front of any developers and contributors. Codecov is a hosted code coverage provider with awesome features. You can check out your first reports here.
I would love all the feedback you have, and please don't hesitate to reach out.
Cheers,
Tom

Hi @thomasrockhu,
Codecov looks interesting, but I don't think we should strive for some particular code coverage in this project.
Sorry for not responding earlier.

@thomasrockhu I believe that for most open source projects contributors (including myself) are not motivated enough to force them to follow some minimal code coverage. And that is fine - they already do the job none else is willing to do. No need to discourage them more :)

thanks for the honest feedback @vmihailenco, we'll continue to aspire to make our product more helpful for contributors and maintainers alike


Fix #3644: Fixed scrollbar overflow issue.

Fixes #3644.

Automated message from Dropbox CLA bot
@souravbadami, thanks for the pull request! It looks like you haven't yet signed the Dropbox CLA. Please sign it here.

Automated message from Dropbox CLA bot
@souravbadami, thanks for signing the CLA!

Awesome, thanks for fixing this @souravbadami!  I merged this as
c511f576fbbbd773f7cd492108000d25102974b3, after cleaning up the commit message.
Check out the Zulip commit message guidelines for more details: https://zulip.readthedocs.io/en/latest/version-control.html#commit-messages
Thanks @souravbadami!


OpenVPN 3 Autload is being deprecated

Hi,
I'm the upstream maintainer of the OpenVPN 3 Linux project and I just stumbled across this project.  I just wanted to give a heads up that the openvpn3-autoload approach is being deprecated and will at some point be removed in a later release.
The approach to use now is:

Import the configuration profile using
$ openvpn3 config-import --persistent --config ${CONFIG_FILE} --name ${CONFIG_NAME}

Start the VPN session using either:
# systemctl enable --now openvpn3-session@${CONFIG_NAME}

or
# openvpn3 session-start --config ${CONFIG_NAME}

The former will automatically start the connecting on each boot, the latter needs to be run each time you want to start the VPN connection.

The ${CONFIG_FILE} itself may now also contain <auth-user-pass>...</auth-user-pass> tags if username/password auth is required; this will be further hardened with support for keyring services and such.
If there are additional settings which was configured via the .autoload file, they can now be set properly via openvpn3 config-manage --config ${CONFIG_NAME}.  See the openvpn3-config-manage(1) man page for details

@dsommers cool, thanks a lot for pointing out that. I'll work on updating this gh action to follow the new approach.

If it makes it easier for you, OpenVPN 3 Linux is based on D-Bus so you can manage it directly this way.  It also ships with an openvpn3 Python 3 module, where you can do all the things you do with the openvpn3 command line tool.
A few examples:

https://github.com/OpenVPN/openvpn3-linux/blob/master/src/tests/python/configimport.py
https://github.com/OpenVPN/openvpn3-linux/blob/master/src/tests/python/start-tunnel2.py

@dsommers thanks for the docs. Actually, for this project I want to keep it simple using bash and exposing a way to run any command so people can use that for simple and complex things.


<EMAIL_ADDRESS>not work very well for Azure-China

Describe the bug
Can't jump to web-browser when executing
az aks browse --resource-group <resource-group-name> --name <k8s-name>,
The following is console log:
No registered resource provider found for location 'chinaeast2' and API version '2020-03-01' for type 'managedClusters'. The supported api-versions are '2017-08-31, 2018-03-31, 2019-02-01, 2019-04-01, 2019-06-01, 2019-08-01, 2019-10-01, 2019-11-01, 2020-01-01, 2020-02-01'. The supported locations are 'chinaeast2, chinanorth2'.
To Reproduce
brew upgrade azure-cli
az cloud set --name AzureChinaCloud
az account set --subscription <subscription name>
kubectl config use-context <k8s context>
az aks browse --resource-group <resource-group-name> --name <k8s-name>

Expected behavior
open a browser tab to show the k8s' status
Environment summary
OS:    MacOS Catalina  10.15.3
AZure CLI  Version:  2.3.1
Additional context
When switching to k8s in Central US, one browser tab will be opened and show the k8s' status

aks

This is due to 2020-03-01 not being available in AzChina yet.
cc @andyzhangx @feiskyer if they know any ETAs

cc @karataliu @fseldow

try to use an older version by running azure-cli container:
https://github.com/Azure/azure-cli#docker
e.g.
docker run -v ${HOME}:/root -v /usr/local/bin/:/kube -it mcr.microsoft.com/azure-cli:2.2.0

The api 2020-03-01 was published, should work now


Extraction of license text from files.

Untested code for license text extraction.
fixes #33

we have a basic implementation here: https://github.com/CycloneDX/cyclonedx-webpack-plugin/blob/72700f06d00eac79fa3b91fe838bd78c583346a2/src/extractor.ts#L135
I was thinking of pulling this one into the CDX library,. so it is available for every dowenstream user - like here...
Could you review that other implementation and see if it suites your case here?

Taking a file name + a data blob and converting it to an instance of CDX.Models.License would make sense in the CDX library. Assuming specific loggers or that packages contents would be kept in ordinary files should not be part of the library.
Since you explicitly referred to the other implementation in ticket #33, the implementation here matches it. One would not want different behavior for different libraries under the CycloneDX umbrella.
Before this PR has an chance of moving forward, this repo needs to be fixed. The current ESLint setup does not work with the present TypeScript version. You can do a yarn up<EMAIL_ADDRESS>to change to a compatible version by the way.
Also, the tests in the repo depend on yarn install for the test projects as shown by tests/integration/setup.js. This was not necessary in the original code and should not be necessary, now. The plugin needs to retrieve the packages to be able to read their manifests (package.json) and now the license texts. But it must not execute an yarn install ... or similar in order to produce an SBOM as the dependency resolution is retained in the yarn.lock file and installations are risky security-wise.

here is the (WIP) draft to bring the functionality to the library: https://github.com/CycloneDX/cyclonedx-javascript-library/pull/1158

Before this PR has an chance of moving forward, this repo needs to be fixed. The current ESLint setup does not work with the present TypeScript version. You can do a yarn up<EMAIL_ADDRESS>to change to a compatible version by the way.
Also, the tests in the repo depend on yarn install for the test projects as shown by tests/integration/setup.js. This was not necessary in the original code and should not be necessary, now. The plugin needs to retrieve the packages to be able to read their manifests (package.json) and now the license texts. But it must not execute an yarn install ... or similar in order to produce an SBOM as the dependency resolution is retained in the yarn.lock file and installations are risky security-wise.

Please discuss these things in individual extra tickets. Thank you in advance.

https://github.com/CycloneDX/cyclonedx-javascript-library/pull/1158 was postponed and will not ship any soon.
Please continue your work crafting a yarn=specific implementation.
This will help understand opportunities to generalize in the upstream-library later.

i had to fix one of the github workflows.
Please rebase/merge the latest main branch.

Note that despite the build passing in the PR validations, the existing tests fail for me. This is with the yarn.lock from the latest release at https://github.com/CycloneDX/cyclonedx-node-yarn/releases/tag/v1.0.2
Example with similar changes in many test cases:
[test:node    ]       + expected - actual
[test:node    ]
[test:node    ]            </properties>
[test:node    ]          </metadata>
[test:node    ]          <components>
[test:node    ]            <component type="library" bom-ref="in-array@npm:0.1.2">
[test:node    ]       -      <author>Jon Schlinkert (https://github.com/jonschlinkert)</author>
[test:node    ]       +      <author>Jon Schlinkert</author>
[test:node    ]              <name>in-array</name>
[test:node    ]              <version>0.1.2</version>
[test:node    ]              <description>Return true if a value exists in an array. Faster than using indexOf and won't blow up on null values.</description>
[test:node    ]              <licenses>
[test:node    ] --
[test:node    ]                  <url>https://github.com/jonschlinkert/in-array/issues</url>
[test:node    ]                  <comment>as detected from PackageJson property "bugs.url"</comment>
[test:node    ]                </reference>
[test:node    ]                <reference type="vcs">
[test:node    ]       -          <url>jonschlinkert/in-array</url>
[test:node    ]       -          <comment>as detected from PackageJson property "repository"</comment>
[test:node    ]       +          <url>git+https://github.com/jonschlinkert/in-array.git</url>
[test:node    ]       +          <comment>as detected from PackageJson property "repository.url"</comment>
[test:node    ]                </reference>
[test:node    ]                <reference type="website">
[test:node    ]                  <url>https://github.com/jonschlinkert/in-array</url>
[test:node    ]                  <comment>as detected from PackageJson property "homepage"</comment>
[test:node    ] --
[test:node    ]                  <url>https://github.com/dcousens/is-sorted/issues</url>
[test:node    ]                  <comment>as detected from PackageJson property "bugs.url"</comment>
[test:node    ]                </reference>
[test:node    ]                <reference type="vcs">
[test:node    ]       -          <url>https://github.com/dcousens/is-sorted.git</url>
[test:node    ]       +          <url>git+https://github.com/dcousens/is-sorted.git</url>
[test:node    ]                  <comment>as detected from PackageJson property "repository.url"</comment>
[test:node    ]                </reference>
[test:node    ]                <reference type="website">
[test:node    ]                  <url>https://github.com/dcousens/is-sorted</url>
[test:node    ]
[test:node    ]       at runTest (tests/integration/index.test.js:156:12)

a lot of dependencies and other things were bumped lately.
I will postpone all dependency bumps until this very feature is merged :+1:
please continue, all your efforts are appreciated very much.
Better rebase/merge master, delete your local .pnp.*/.yarn/..., and run yarn install again.

regarding your failing tests  - https://github.com/CycloneDX/cyclonedx-node-yarn/pull/193#issuecomment-2460652894
the underlying test beds ship own lock files, they are not affected by your project lock file.
anyway, the lock file from v1.0.2 is an outdated static one that is not carries over by maintenance. Of course, it makes no sense to pull it in the project when developing new features.
Anyway, do you maybe have old build artifacts, that need to be removed before testing?

./yarn-plugin-cyclonedx.cjs
dist/yarn-plugin-cyclonedx.cjs

a lot of dependencies and other things were bumped lately. I will postpone all dependency bumps until this very feature is merged 👍 please continue, all your efforts are appreciated very much.

Just for your info the part of the install where node-gyp is used to build libxmljs2 is failing in case you run with Node 22 (current LTS). It's header files are incompatible with the referenced libxml. Updating libxmljs2 to 0.35.0 in CycloneDX/cyclonedx-javascript-library should solve this.
Building on Node 20 is not showing the incompatibility and should work with libxmljs2 version 0.33.0 as well as 0.35.0.

Anyway, do you maybe have old build artifacts, that need to be removed before testing?
* `./yarn-plugin-cyclonedx.cjs`

* `dist/yarn-plugin-cyclonedx.cjs`

Thanks for the hints. It turned out that test errors were the result of a bug in my changed code. It's fixed with correcting the invocation of the normalize-package-data library in my last commit.
Please try out the changes and check if the license evidence is included as you would expect in the resulting SBOMs.

Just for your info the part of the install where node-gyp is used to build libxmljs2 is failing in case you run with Node 22 (current LTS). It's header files are incompatible with the referenced libxml. Updating libxmljs2 to 0.35.0 in CycloneDX/cyclonedx-javascript-library should solve this.
Building on Node 20 is not showing the incompatibility and should work with libxmljs2 version 0.33.0 as well as 0.35.0

this libxmljs2 is a transitive optional dependency. I would love to omit it.
Do you see a way to do so, @AugustusKling ?

this libxmljs2 is a transitive optional dependency. I would love to omit it. Do you see a way to do so, @AugustusKling ?

I do not think this is doable from cyclonedx-node-yarn.
Yarn and probably other package managers, too, would download all optional dependencies in the dependency tree, transitively. Then they should compare the current system environment with the compatibility info from the packages' manifests; that is the fields os, cpu, libc. If these are compatible or absent, the package manager needs to invoke the packages build script. If the build succeeds, the package will be used, otherwise it will be excluded from the installation.
In the specific case here the build of libxmljs2 fails and Yarns warns about it. This failure with the libxmljs2 packages does however not abort the installation of cyclonedx-node-yarn. Instead, Yarn excludes libxmljs2 automatically since it's only part of the dependency tree as an optional dependency. You'll lose whatever optional feature or optimization libxmljs2 should have contributed to @cyclonedx/cyclonedx-library.
If you really wanted to exclude libxmljs2, you'd need to remove it from @cyclonedx/cyclonedx-library but I guess it is there for a reason. Instead, update libxmljs2 to 0.35.0 to allow for a successful build with more Node versions.
The following is Yarn's way to notify about the build failure or an optional dependency. It would be nicer if the wording was more explicit and it said something along the lines of "excluding libxmljs2 which is an optional dependency".
➤ YN0000: · Yarn 4.5.1
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Post-resolution validation
➤ YN0086: │ Some peer dependencies are incorrectly met by dependencies; run yarn explain peer-requirements for details.
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed in 0s 307ms
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0007: │ libxmljs2@npm:0.33.0 must be built because it never has been before or the last one failed
➤ YN0009: │ libxmljs2@npm:0.33.0 couldn't be built successfully (exit code 1, logs can be found here: /tmp/xfs-8914cf2a/build.log)
➤ YN0000: └ Completed in 18s 797ms
➤ YN0000: · Done with warnings in 19s 425ms

re https://github.com/CycloneDX/cyclonedx-node-yarn/pull/193#issuecomment-2474161240
I expected that, since - according to the docs I've read - yarn's concept of optional is a very well-thought one. But since I am not a heavy user of yarn, I thought I should ask, before assuming something.
Thank you for the detailed explanation. :+1:
The features provided by this optional dependency are not used in the code at the moment, so they are not bundled in the final product, and no related code is generated in the build artifact.
From developer experience, the warning on setup/install looks ugly, true. But it's fine, it is not a blocker. If it was, please open an issue for that.

From developer experience, the warning on setup/install looks ugly, true. But it's fine, it is not a blocker. If it was, please open an issue for that.

The warning is easily misunderstood for a problem but can be safely ignored.

followups and concerns that need to be taken into account:  https://github.com/AugustusKling/cyclonedx-node-yarn/pull/1#issuecomment-2518025384

@AugustusKling ,
how do you see the current state of this PR? Would you be okay with merging it and have it published and tested downstream?
I mean, this software is not meant to be final, it is intended to be improved step-by-step over time, right?

Firstly, sorry for leaving this for many days. I would like to spend more time to improve this tool but time is sadly limited.
We can merge this in my opinion as it is. When I compare with my PR to your repo https://github.com/CycloneDX/cyclonedx-node-yarn/pull/193/files then I think these things should be addressed soon (before or after merge):
* Add `--gather-license-texts` to /README.md file, maybe with a warning that it's not reliable yet

* Take over changes from /tests/README.md file

These improvement could be addressed in follow-up PRs:
* Improve file name pattern for license files

* Make sure to abort with a non-zero status code on errors, that is address things like mentioned in https://github.com/AugustusKling/cyclonedx-node-yarn/pull/1/files#r1840859282

* Improve efficiency if it turns out opening the cached packages multiple times is notable

Just make sure to call the license extraction experimental until we can trust it does not silently skip over errors.

tracking of tasks that need to ke tackled immediately:

[ ]  Add --gather-license-texts to /README.md file, maybe with a warning that it's not reliable yet
[ ] Take over changes from /tests/README.md file

@AugustusKling,
I've suggested the docs regarding  the "experimental" nature of the new feature.
please review and apply the suggestions, if they appeal.

https://github.com/CycloneDX/cyclonedx-node-yarn/pull/193#discussion_r1874408640
https://github.com/CycloneDX/cyclonedx-node-yarn/pull/193#discussion_r1874409027

@jkowalleck, thanks for the suggestions. I've merged them and also the main branch into this. The build/tests pass locally.
Can you please check why the workflows for the PR validations do not start to run?

Can you please check why the workflows for the PR validations do not start to run?

the CI does not start automatically for PRs, it needs to be triggered by a maintainer - after reviewing the changes. (This s a security-feature by github, taken for workflows that were not migrated to github's modern permission system.
I might have time to modernize workflows during the course of next year, but for now this is our solution)
Anyway, I had the CI running, and it passed - as expected :partying_face:
I'd consider this PR as ready for merging.
@AugustusKling, do you agree?  If so, I would merge this PR, and you could create all the follow-up tickets needed.

Hi @jkowalleck , I created the tickets #228 and #229 for the improvements after merge of this pull request.
I agree that this is ready to be merged since the README file already mentions license text extraction is experimental.

@AugustusKling ,
i will merge this PR today,
and might come back to you for discussions of https://github.com/CycloneDX/cyclonedx-node-yarn/issues/228 and https://github.com/CycloneDX/cyclonedx-node-yarn/issues/229


create (beta 0.5.1) fabric 1.20.1 doesn't work with siduim latest version

Describe the Bug
1.instal create 0.5.1 1.20.1 fabric
2.drag and drop on mods folder
3.open minecraft
4.minecraft crash error
5.Replace mod 'Create' (create) 0.5.1-d-build.1161+mc1.20.1 with any version that is compatible with: sodium 0.5.8+mc1.20.1
6.help
Reproduction Steps
1.instal create 0.5.1 1.20.1 fabric
2.drag and drop on mods folder
3.open minecraft
4.minecraft crash error
5.Replace mod 'Create' (create) 0.5.1-d-build.1161+mc1.20.1 with any version that is compatible with: sodium 0.5.8+mc1.20.1
6.help
Expected Result
1.instal create 0.5.1 1.20.1 fabric
2.drag and drop on mods folder
3.open minecraft
4.minecraft crash error
5.Replace mod 'Create' (create) 0.5.1-d-build.1161+mc1.20.1 with any version that is compatible with: sodium 0.5.8+mc1.20.1
6.help
Screenshots and Videos
No response
Crash Report or Log
No response
Operating System
windows 11
Mod Version
0.5.1d
Minecraft Version
1.20.1
Other Mods
No response
Additional Context
No response

this is already fixed in the next version

thank you .
When will create fabric no longer be in beta?


Replace HashRing method with Rendezvous

This is the same implementation of https://github.com/AsynkronIT/protoactor-go/pull/176 but in dotnet version.

Very nice!


Alternative output formats not available on taxonomy term pages.

The [outputs] section in the site config allows us to define alternative output formats for given page kinds. For page, home, section and taxonomy this works, but for taxonomyTerm this seems to be broken. The following code:
  {{- range .AlternativeOutputFormats }}
  {{ printf `<link rel="%s" type="%s" href="%s" title="%s">` .Rel .MediaType.Type .Permalink $.Site.Title | safeHTML }}
  {{- end }}

successfully includes the application/json link on all page kinds but the taxonomy terms (e.g. /tags/ fails).
Hugo Static Site Generator v0.49.2/extended windows/amd64 BuildDate: unknown

Sorry, just found the duplicate: #4528


No pack for name [null]!

It looks like the same issue as posted by another user. Not sure how they resolved it.

I will add that I got it to work when I turned the forge game manager off. Not sure why that happened.

hmm there might be some weird interaction going on there. Sorry, I don't use the Forge, is the game manager a module in-game too, or just the tool from the website?

@Wakarusa67 have you been able to work around this ? I saw the user from the other issue where you initially reported this mentioned it got fixed by updating the module. If you have the latest version of the module, there's also a console command you can use to restore compendiums to defaults, if somehow they end up in an inconsistent state:
 game.modules.get('hero-creation-tool').api.resetSources();

@Wakarusa67 I sadly will need to close this without any further info. If you are still having this problem, feel free to leave a message here so I can reopen the ticket and we can maybe see this together on Discord!


Issue creating new container

I use below poweshell comamnd to pull the latest image
docker pull mcr.microsoft.com/businesscentral/sandbox:us-ltsc2019
Whe i try to use below command to create new container, i got below error
New-NavContainer -containerName sbmem -accept_eula -auth NavUserPassword -imageName mcr.microsoft.com/businesscentral/sandbox:us-ltsc2019  -licenseFile "C:\Work\D365BC-V15.flf" -updatehosts -includeAL

WIndows OS information:
Edition: Windows 10 Enterprise
Version: 1903
please help!!

Reset your docker installation to factory defaults and try again would be my suggestion.

Hi fredy - iam still getting the same error.
I did factory reset and also uninstalled everything and reinstalled it again. I am still getting te same error.
It says - required feature is not installed but it doesnt say whats the feature that it is missing.
if you can point me in right direction, that should be great.

Did it use to work on this machine?
Can you start other containers?
Could you paste the full output of the container generation here?
Is HyperV installed?

this one is caused by HyperV not being enabled on the machine (99% of the time)


[WIP] feat: use zerocopy types for defining underlying docs fs types

First round of using zerocopy in the sync db.
Open tasks

this is missing a migration currently
in a next round, after redb@v2 is merged, it should be possible to reduce some of the current allocations further (hopefully)

Will be included in future work


[broker][admin]Add api for update topic properties

Motivation

Maybe this modification should be part of  https://github.com/apache/pulsar/issues/12629 .  As described in the PIP document "These metadata could be set during topic creation and also updated.",  we have implemented the creation method, but have not implement  the updated method.

This PR will implement the topic meta update

Modifications

Add a admin api updateProperties

Verifying this change

[x] Make sure that the change passes the CI checks.
Add UT org.apache.pulsar.broker.admin.AdminApi2Test#testUpdatePartitionedTopicProperties
Add UT org.apache.pulsar.broker.admin.AdminApi2Test#testUpdateNonPartitionedTopicProperties

Documentation
Check the box below or label this PR directly.
Need to update docs?

[ ] doc-required
(Your PR needs to update docs and you will update later)

[x] doc-not-needed
(Please explain why)

[ ] doc
(Your PR contains doc changes)

[ ] doc-complete
(Docs have been already added)

Can you help open a new PR to branch-2.10? There are a lot conflict when cherry-pick directly. @AnonHxy

@Jason918 we cannot add new APIs on released branches

@Jason918 we cannot add new APIs on released branches

Sure, I will remove the label.


Reactify declaration incomes page

Short Description

More React! :)

Changes

Add React component
Wire it up

Feedback

Do you think we need a test that the list is displayed?
Is there another way of accessing an image than loading it in the /assets folder?

What do you have in mind? Or rather: what doesn't work for you about loading it from the /assets folder?

Just because I'm duplicating the icon - that's the only reason I asked I think.

Just because I'm duplicating the icon - that's the only reason I asked I think.

Right. When we're done, we can delete all assets from public/ except what's used by the Lay-out templates and non-react pages. I'll make a "post-reactification cleanup" ticket where we can collect tasks like this and also removing CSS classes from components.

Feel free to add anything I missed: https://steuerlotse.atlassian.net/browse/STL-1575


Annotations and Labels

Thanks, just merged, and yeah sure, if there is any improvement to apply, let's have another PR for this.


Watchdog (v2)

Designed to work on all platforms.
See https://github.com/keybase/go-updater/pull/78 for more details.
It will be ctl watchdog2 until we flip it on.
This PR also tweaks the install package:

GetMountDir can return an error (if unsupported)
KBFSBinPath is now public method
Unified defaultLinkPath method (was dupe code)
BinPath is now public method
Added UpdaterBinPath for path to updater executable
kbfsBinName moved to separate file

Ignore CI failures since this doesn't have packages vendored. I will create separate PR for that since it will make it harder to evaluate.

:mag_right: No visual changes found as a result of these commits.

:mag_right: No visual changes found as a result of these commits.

:mag_right: No visual changes found as a result of these commits.

@zanderz

cc @keybase/updater-hackers

LGTM with some comments :thumbsup:

:mag_right: No visual changes found as a result of these commits.

:mag_right: No visual changes found as a result of these commits.


fix(cli): correct module name resolution for clipboard and globalShortcut plugins

closes #9905

Thanks for contribution


[BUG] no reset invoice working

I confirm that I've previously read bug reports, but I haven't found the solution or the report by other users.
Operating System: 10 Winda
Application version:  0.0.1
author is retarded no reset on invoice in woking

I totally regret you having problems with School Accounting Studio and I'm going to solve this issue as soon as I can.
There is indeed a problem with private void reset() function of InvoicePanel class which doesn't account the existence of SELLER_VAT_NUMBER, CUSTOMER_VAT_NUMBER, and INVOICE_PACKAGING_COST fields. They should be added in the array of items to reset in order to function properly.
I thank you for your curiosity for my work and the time you spent on using my project.
As a result of coming refactoring and reformatting pull requests, I'll handle this problem.

As commit 712eef6 on branch updating/reformatting-refactoring made on 08.02.2024 the issue is fixed.


Fix event tests

This PR fixes #556 and updates the event tests.
Notable changes:

I've deleted the echo statement echo "SLUGGING ABORTED!\n"; in tests/Listeners/AbortSlugging.php since I don't think it's used anywhere.
I've removed the testSluggedEvent method in tests/EventTests.php  since it seems to be a duplicate of testEventsAreFired.

Thank you!


Could you share you training weights file?

I would like to use the features provided by your model as a comparison, is it possible to provide the file after your training, thanks!

I don't have the pre-trained models anymore, you can use the deepdrugdomain package for much faster training.


Review of requirements for next release (potentially Sep 18)

Omid, please review the list below:
Product backlog

[ ] 288 – update batch job - We need the query to pull companies implemented in code

In Progress
TESTING:

[ ] 318 - fix date issue - bug

Ready for Release
DONE:

[ ] 307 – investigate – fix difference in effective date - HOME TEAM CODE FIX

Closed

[ ] #244 - Liquidation check in colin
Add a check to the colin-api that can be used to show a business is in an ACTIVE state, but is also in the process of liquidation
[ ]#245 - Admin Freeze check in colin
Add a check to the colin-api that can be used to show a business is in an ACTIVE state, but is blocked due to an admin-freeze.
[ ] 314 - confirm AR reminder batch job – turn off AR prompt
[ ] 319 - Confirm dat will be deleted from AR_prompt in cprd l
[ ] 321 - Ar reminder workflow
[ ] 292 – update review page for mobile
[ ] 304 – Language switching issue
[ ] 324 - fix: Improper formatting of date in downloadable pdf receipt
[ ] 312 – test nano IDs

We ran production job yesterday, i am closing this ticket, and now we tackle tickets sprint by sprint


Portable markdown links

See Portable markdown links

I don't see any harm in making this change. It adds functionality while maintaining the existing workflow. I only note that you have omitted the rel="noreferrer noopener" part of the link and I believe this is still required? It was added in https://github.com/jpanther/congo/pull/446 but potentially this is no longer necessary?

Anchor target=_blank implies rel=noopener by default (as of 2021, for most browsers). But not noreferrer. So yes, I need to fix this bit

Thanks for amending it, I'll merge this one in now.


Don't copy before pasting in copyOnSelect mode

Don't try to copy if we're in copyOnSelect mode, and have already copied this selection.
#14464 demonstrates a scenario where the buffer contents might have changed since the selection was made, and copying here would cause weirdness.
Also adds a couple tests for copyOnSelect.
Closes #14464

Lemme make sure I get this straight - when you modify the selection with mark mode (with copyOnSelect:true), the clipboard contents don't get immediately updated? They only get updated on the right-click (which we turn around and use to immediately paste)?

Sorry, I'm not very experienced in feature implementation workflow. Could someone explain to me which stage this issue is on?
I waited for the new release and fix but unfortunately, it's still not implemented :(

Lemme make sure I get this straight - when you modify the selection with mark mode (with copyOnSelect:true), the clipboard contents don't get immediately updated? They only get updated on the right-click (which we turn around and use to immediately paste)?

Correct! Because if the clipboard contents got updated whenever you move the cursor, you'd copy so many " " to your clipboard! 😆

I waited for a long time this issue will be fixed and no. New version 1.20 doesn't contain fix for it. I wander why so small number of users confirmed this bug. This feature works ideal on putty, why it can't be fixed on MS Terminal? I believe it's pretty easy to fix.
I'm sorry, I'm not experienced developer, otherwhise I'd also contribute. If there is any volonteer to explain how I can do that, please guide me. I believe I can read this code to fix it.

I've been working on another project for the last 6 months and have solidly cached this out. I'll probably loop around on all these open PRs after that gets out the door, but I honestly don't remember exactly the interaction that was weird about this fix. I know that it was related to https://github.com/microsoft/terminal/pull/14635#pullrequestreview-1243131362 but I don't recall how the code flowed to cause that anymore.

I've been working on another project for the last 6 months and have solidly cached this out. I'll probably loop around on all these open PRs after that gets out the door, but I honestly don't remember exactly the interaction that was weird about this fix. I know that it was related to #14635 (review) but I don't recall how the code flowed to cause that anymore.

In the nutshell the problem is that when copyOnSelect is active it does it twise: onSelect and onPaste (right click). It shouldn't do copy during onPaste operation. In putty, when you select anything, putty shows selection. When you select anything somewhre else, puttyclear it's own selection and after that buffer contains new selection. Which is used for paste on right click.
I've read release notes and that's a huge of work. Just hope new version also include fix for this bug. )


Update Cake.Sonar NuGet package icon to the new Cake-Contrib logo for Cake addins

We've recently released new icons for Cake extensions, to help more easily differentiate Cake Addins, Modules, Recipes, etc.

More information: https://github.com/cake-contrib/graphics

Fixed by #109


Added tutorial notebooks for Focal and Contrastive losses

Related to #1612 .
@shun-lin - Please review.

@shun-lin , On loading the vecs.tsv in the UMAP of the projector, it is showing parsing failed. Please can you help me?

Focal loss image

Contrastive loss image

@shun-lin, I am not getting why the tests are failing after merging with master. Please take a look at it. I have added images for embeddings.

@ashutosh1919 sorry I didn't see your comment earlier as I was working, but would you be able to download the embedding and upload it to tensorboard public server (similar to Triplet Loss's tutorial)? Also the embedding images look nice! would you able to color code it? (without color coding it's harder to see whether or not it works haha).
I am also aware that there are also another PR that is working on tutorial of focal loss, it that also your PR?

@shun-lin, I am not getting why the tests are failing after merging with master. Please take a look at it. I have added images for embeddings.

Hmm I am not sure, I will tag @seanpmorgan :)

I am also aware that there are also another PR that is working on tutorial of focal loss, it that also your PR?
No, I haven't made any separate PR for focal_loss. Please, mention that PR if possible.

@googlebot I consent.

@ashutosh1919 would you able to create embedding with colors for different classes?

@ashutosh1919 would you able to create embedding with colors for different classes?

@shun-lin , Not really, I am not even able to load the vectors in the projector. Everytime, it is showing parsing failed.

@ashutosh1919 would you able to create embedding with colors for different classes?

@shun-lin , Not really, I am not even able to load the vectors in the projector. Everytime, it is showing parsing failed.

interesting, bugs at TensorBoard's side?

@shun-lin , I am not quite sure about that. Can you please try once if you have sometime.

Contrastive Loss

Focal Loss

@shun-lin , @seanpmorgan , @bhack , @gabrieldemarmiesse - I have added embedding image where all labels have different color. Please review.

Now we have also a contrastive keras/Addons tutorial at https://keras.io/examples/vision/supervised-contrastive-learning/
We could think to expand that one?

IMO, we should have different tutorial for contrastive learning. This PR contains information about contrastive loss and other code (Model building, compiling and running) is easy to understand. If we expand this tutorial to have Supervised contrastive learning, then it may be difficult for beginners to understand.
@bhack , I would appreciate your opinion on this.

We are collecting more tutorial in the Keras.io repo so I suggest you to port this PR to https://github.com/keras-team/keras-io


Updated issue with Flutter

Renamed inheritFromWidgetOfExactType to dependOnInheritedWidgetOfExactType
I don't know if you've had this issue, but it helped me to continue to use this package, so thought I'd share it. Thanks for an awesome package BTW!

Anybody who needs it before then can add to dependency_overrides in their pubspec.yaml
dependency_overrides:
  calendarro: #https://github.com/zenled/calendar_views/pull/28 The method 'inheritFromWidgetOfExactType' isn't defined for the class 'BuildContext'
    git: https://github.com/m8iog/calendar_views.git


[19.03 backport] Use ocischema package instead of custom handler

backport of https://github.com/moby/moby/pull/40070
Fixes https://github.com/moby/moby/issues/39727
Relates to https://github.com/docker/distribution/issues/3024
Previously we were re-using schema2.DeserializedManifest to handle oci
manifests. The issue lies in the fact that distribution started
validating the media type string during json deserialization. This
change broke our usage of that type.
Instead distribution now provides direct support for oci schemas, so use
that instead of our custom handlers.
On 19.03:
$ docker run -it --rm cpuguy83/mobyissue39727:latest cat /foo
Unable to find image 'cpuguy83/mobyissue39727:latest' locally
docker: Error response from daemon: mediaType in manifest should be 'application/vnd.docker.distribution.manifest.v2+json' not 'application/vnd.oci.image.manifest.v1+json'.
See 'docker run --help'.

With this change:
# docker run -it --rm cpuguy83/mobyissue39727:latest cat /foo
Unable to find image 'cpuguy83/mobyissue39727:latest' locally
latest: Pulling from cpuguy83/mobyissue39727
9d48c3bd43c5: Pull complete
ada774eec8cc: Pull complete
Digest: sha256:1afcf1bc336b1dbb346fef91b8e2b648f90c801a446cec214c46f544eb3608c8
Status: Downloaded newer image for cpuguy83/mobyissue39727:latest
hello

- Description for the changelog

@cpuguy83

Some weird failure in docker-py; https://ci.docker.com/public/blue/rest/organizations/jenkins/pipelines/engine/branches/PR-405/runs/2/nodes/203/log/?start=0
[2019-10-17T15:17:38.261Z] docker/api/client.py:261: in _raise_for_status
[2019-10-17T15:17:38.261Z]     response.raise_for_status()
[2019-10-17T15:17:38.261Z] /usr/local/lib/python3.7/site-packages/requests/models.py:940: in raise_for_status
[2019-10-17T15:17:38.261Z]     raise HTTPError(http_error_msg, response=self)
[2019-10-17T15:17:38.261Z] E   requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.35/images/hello-world:latest/get

Restarting CI


[refs #0003] Move styles to much higher up in the DOM

As per #3, this PR will improve performance by allowing CSSOM (and thus rendering) to happen much sooner, and will avoid the FOUC caused by the browser rendering HTML before it knows about the CSS.

Thanks!
Pro tip: If you write "Closes #3" into the PR description or the commit message Github auto closes that issue when the PR is merged! 👌


Check the balance of ttko,ttkeoe that I deposited in explorer.

Describe the feature request
Deposit in explorer is required to run Propose.If the Propose is successful, the balance will be reduced.So I thought it would be useful to have a place where I could check how much more I have left in my balance.I found it inconvenient that I could not check my balance.
Describe alternatives you've considered
Description of the alternatives you've considered here.
Additional context
Additional context here.

You can add the token to your metamask and view your TTKO balance there.
Click on the "Add Sepolia Tokens" button to easily add TTKO token to your metamask:
https://taiko.xyz/docs/guides/build-on-taiko/setup-your-wallet

Not metamasku, I'm talking about currency deposited directly in Explorer.
2023年8月7日(月) 11:26 Kenk @.***>:

Closed #14389 https://github.com/taikoxyz/taiko-mono/issues/14389 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/taikoxyz/taiko-mono/issues/14389#event-10018719726,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AW6GGGNNEXM5HPTPKBTVJILXUBG4ZANCNFSM6AAAAAA3FXNAOU
.
You are receiving this because you authored the thread.Message ID:
@.***>

Ah so you would want a dashboard to see TTKO / TTKOe in your wallet as well as TTKO / TTKOe deposited in the TaikoL1 contract

you can check the balance on the TaikoL1 contract. i will close the issue for now.


Ability to set Transport token

Add the ability to set the access token on a Transport. This is useful to create a Transport from a token already known (for example stored in a database) to avoid an unnecessary HTTP request to get a new one.
Also fix the build by changing to new jwt time types.

@bradleyfalzon / @wlynch Let me know what you think :)

I've just noticed the Token() method only returns a string, so there is currently no way to get the expires date out to "save" an access token. Not sure the best way to solve this in a backwards compatible way

Thanks for the PR! I'm a little hesitant to expose the AccessToken type, since the github.InstallationOptions and github.Repository fields aren't meant to be set by the user.
The intent for this change seems very similar to oauth2.ReuseTokenSource (and oauth2.Token contains expiration information). I wonder if we should start exposing Token/TokenSource compatible types 🤔  - @bradleyfalzon what do you think?


README is not great for newbies (also there is no README)

For those new to Karaf, it might be mystical what exactly an exporter is.. It seems like dependency injection wiring.. I've actually found little details in karaf's docs saying precisely what they are.  Like KafkaSenderService, OkHttpSenderService. Exporter is not really a common term in karaf or OSGi in general. What the code does is to allow to configure the senders via OSGi config admin and export them as OSGi services so other OSGi components can pick them up. I can help creating readme files for documentation.

ah sounds sensible and thanks for the offer
On Mon, Feb 18, 2019, 2:11 PM Christian Schneider<EMAIL_ADDRESS>wrote:

Maybe we should rename them to service. Like KafkaSenderService,
OkHttpSenderService. Exporter is not really a common term in karaf or OSGi
in general. What the code does is to allow to configure the senders via
OSGi config admin and export them as OSGi services so other OSGi components
can pick them up. I can help creating readme files for documentation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-zipkin-brave-karaf/issues/34#issuecomment-464598847,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD617waQ6e6fe8ngMLZYpXkKlLjXrXdks5vOkP0gaJpZM4a_6O2
.


Is Vitis AI Compiler open-sourced?

I cannot find the source code of Vitis AI Compiler (e.g., vai_c_tensorflow executable) in this repo. Is it open-sourced somewhere?

Hi @ZJUGuoShuai
Vitis AI Compiler is not open source.


BLT don't working(again)

I'm Install new version of BLT(2.1), but mods dont working. Somebody say, what im doing wrong

Be specific with your problem, beyond simply saying "mods aren't working." Is it that BLT mods don't appear?

I think what they're trying to say is that their BLT mods aren't showing up in Payday 2
But I think that it could be the Aldstone's Heritage update breaking BLT, which I heard of it doing (Unless that got fixed in 2.1).


App Icon issue

Describe the bug
App icon from the user's homescreen has a white border.

Screenshots
If applicable, add screenshots to help explain your problem.
Android
Oppo Realme 5

@JGDoh I believe this is only present on the specific device? (Oppo Realme 5)
Looks like @RaulUrtecho has confirmed the correct icon (Raúl, curious, was this done in a simulator?)

@JGDoh You can confirm if this was fixed on your cell phone?


Date not set correctly

Small fix that corrects the order in which the selected date is set. This fixes a problem in which the selected date is a full month ahead of the intended one for certain dates. For example selecting February 14th 2015 shows March 14th, 2015.

Thanks for your work @cfperea ! Good catch.


PPO agent produces non-deterministic results when evaluating the same episode

Habitat-Lab and Habitat-Sim versions
Habitat-Lab: master (commit ce397)
Habitat-Sim: master (commit 5cb10)
Docs and Tutorials
Did you read the docs? Yes
Did you check out the tutorials? Yes
❓ Questions and Help
Problem
Hello, I am trying to evaluate the V2 RGBD agent in one of the Habitat test point-navigation episodes in a similar fashion as ppo_agents.py, but I noticed that the agent produces inconsistent actions when evaluating the same episode, depending on whether

the episode was evaluated alone, or
evaluated after episodes before it from the same dataset.

I have fixed random seed when initializing the agent, so based on what I understand from this post, the agent should be deterministic. So may I ask why it would produce different actions depending on the order at which I evaluated the episode?
Context
I created my evaluation script based upon ppo_agents.py, and made some changes so it can either evaluate all episodes from a dataset, or select a particular episode to start the evaluation from.
In pseudocode my evaluation process is
# iterate until we find the first episode to evaluate
if not evaluate_all:
 while env.episode_id != ep_id or env.scene_id != sc_id:
   env.reset()

while count_episodes < num_episodes:
 agent.reset()
 observations = env.reset()
 while not env.episode_over:
   action = agent.act(observations)
   observations = env.step(action)

I have called agent.reset() so the agent's decision would not be affected by previous episodes. Also fixed RANDOM_SEED to 7 as in ppo_agents.py.
The episode of interest is from the test scenes data, has episode-id=49 and scene-id=data/datasets/van-gogh-room.glb. I have also confirmed that the envionrment initally always produced deterministic readings, but the agent's action after a couple of steps into the episode became non-deterministic.

This is because the state of the PRNGs for action noise and sensor noise is different.  Those get seeded at simulator/environment creation but not on reset so their state will be a function of the pervious episodes.  If you want to fix the random seed based on the episode, doing something like env.seed(hash(env.current_episode.scene_id) + hash(env.current_episode.episode_id)) should work.

Hi Erik, thanks for the quick response! That makes sense.

Sorry for asking help on this again - I have fixed the environment's random seed to 0, but still I'm having the discrepency.
I suspect this being the agent's problem rather than the environment's, because I have compared sensor readings and noticed that as long as the agent was producing the same action, the readings I got from env.step() were always identical. The divergence happened from the 6th step where given the same readings, the RGBD agent produced different actions.

Yeah, likely an agent issue.  Worth reading through PyTorch's docs on determinism: https://pytorch.org/docs/stable/notes/randomness.html

Hi Erik, again thanks for looking into this issue. I will look into the doc and see if I can find the source of non-determinism.


I want to know if fixed window size

how to set

Not supported by Chrome at the moment. Of course, once this feature is implemented in Chrome and becomes available through the DevTools protocol - I'd be happy to add support for this.


Escape output file with quotes

ImageMagick will not properly handle filenames with spaces if not escaped by quotes.

Great. Thanks!


Support for gguf models

hey team, incredible work being done here.
Wondering if you only support .bin models, or would it also manage to work with gguf quantized models as well.
If not, then that's a real feature request. Mostly everyone uses gguf models to work nowadays, as they are easier to run on consumer-grade hardware.
thanks.

Hi . Thanks for you question.
GGUF is not yet supported. AFAIK, gguf models are just originally bin models converted to gguf, so.
It also depends on the exact "bin" model architecture, I think there is no strict agreement how bin models should be implemnted, all projects has its own format.


Updated flash driver and littlefs helper to use NAND memory module (MT29F1G Series)

Pull Request is based on issue #118. From Saksham's branch, a separate branch was made to work on separately. Flash driver functions are working properly as well as using them with LittleFS.

This is awesome! I'm so excited this is ready!
My testing started off sad when I kept getting the -84 error. Then I remembered that was just because I hadn't formatted it yet.
Just going to dump my testing notes here for reference:
Tests which pass:

Write a text file with about 15 regarlar characters. Read it. Success.
After writing the file, unmount. Reset with reset button. Mount. Read the file. Success.
CTS1+fs_benchmark_write_read(100,5)!
Calling CTS1+fs_benchmark_write_read(100,1)!, where it writes to the same file every time, works for 20+ calls.

Tests which fail:

CTS1+fs_benchmark_write_read(100,100)! -> Stall.
Run the following command roughly once every 3 seconds, about 10+ times: CTS1+fs_benchmark_write_read(100,1), with my modified code which creates a new file every time. It works several times, with an ever-increasing "Write open" time (about 5ms per call), which is somewhat expected. Then, reliably fails after about 17 calls, it starts reporting a corrupted filesystem (error code -84). This updated code is added to this branch in commit 82e8034.

The code looks solid! Haven't read it line-by-line yet, but your stuff has been good! Let's look at getting some of these fixes working better.
If I had to hazard a guess, I think it may have something to do with behaviour as the file table (which stores the names and addresses of each file) reaches the size of a whole page, data may not be getting fully written, and thus appears corrupt.


Change handler for unverified request

cc/ @juanignaciosl

Could you review this please, @juanignaciosl ?

LGTM, I can't help too much here. Just test it :+1:

I've tested al POST endpoints we have and their neighbourhoods, tomorrow morning we deploy this cc/ @xavijam

:racehorse:


Added C interface to datagram API

As said in https://github.com/cloudflare/quiche/issues/430 I built a small C interop interface on top of the quic datagram's API (no h3).
This PR mostly to discuss it.
Of note: quiche_conn_dgram_free is meant to be called to free the buffer returned by quiche_conn_dgram_recv which  was allocated "Rust side". Its _conn parameter is totally useless, but I kept it there for API uniformity.

Thanks for the PR!
I think there'll be some debate about both the Rust and C APIs, so lets keep this PR open.

I think there'll be some debate about both the Rust and C APIs, so lets keep this PR open.

Any way I can contribute more to get that discussion going ? I'm happy to help, if possible.

Our main focus right now is in the core protocol, and DATAGRAM is a bit best effort. The good news is that the changes it requires are not too intensive and the API surface seems small.
As always, having some data to aid decision making is real helpful. Perhaps it is possible to profile the copy vs. non-copy case and understand the tradeoffs a bit more?

I haven't ack'ed this before, but I'm slowly working towards it.

Dumping the benchmarks and thoughts here.
I set up a benchmark which could run in several modes on localhost, that is raw udp (it just floods the client with packets, with no care whether they are received or not), "nocopy" which is the dgram interface which doesn't require an extra data copy (i.e. yours: dgram_recv(&mut self) -> Result<Vec<u8>>) or "copy" which is dgram_recv(&mut self, out: &mut [u8]).
I did the benchmark in C, given the results (spoiler) I'm not too keen in performing them again in pure Rust, unless there are concerns over this.
The code for the benchmark is very quick and dirty and is at : https://github.com/xanathar/quiche/tree/datagram_iface_perf_comp/performance_comparison . I'm sorry for the dirty-ness of the code but that required a lot of back-and-forth and is written as a throw-away.
To reach a decent amount of bandwidth in a controlled way, I removed flow-control (which actually should be refactored decently and picked, because, if I'm not mistaken the current draft says that datagrams should not be constrained by flow control) and disabled congestion control by passing a dummy congestion control algorithm. On the congestion control topic, I think there are some checks to be done to see if datagrams contribute correctly to congestion control or not (something I plan to check in the future).
I measured the process cpu time (as returned by clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)) and the bandwidth sustained after a ramp-up. For the 64K datagrams I aimed for a 128MB ramp-up and 4GB target, for the 1KB datagrams test I aimed for a 256MB target after a 8MB ramp-up. Both server and client process were restarted each iteration, to avoid iterations influencing each other and to work around what seems to be a memory leak in the server code, which is something which must be debugged but off topic for this specific context of deciding the API.
The results (showing p50 over 5 tests for each mode):

Test
UDP
no-copy
copy

1K dgrams, CPU sec
2.02
5.02
5.07

1K dgrams, MiB/s
492
194
194

64K dgrams, CPU sec
0.52
3.85
4.01

64K dgrams, MiB/s
7325
762
763

The tests gave all fairly stable numbers. For the "copy/64KB" scenario I took several more numbers and gathering them gave the result:

Copy/64K
Average
Std Dev

CPU time
3.991
0.03858

Bandwidth MB/s
768.3
9.338

Given this, I'd say that the gains for the "no-copy" scenario are negligible and probably not worth pursuing versus a cleaner interface; there is maybe a small CPU time gain in having no copy, but really, it's not going to be noticed unless I got the numbers completely wrong.
On the other hand, the performance difference versus a pure UDP scenario is quite big, but probably would disappear once on a "real" network rather than insanely pumping on the loopback.
Given this, I'd recommend going with dgram_recv(&mut self, out: &mut [u8]).

Thank you very much for doing this!
I'll need to digest this a bit more, so I'll followup with a more comprehensive response. But again, this is well appreciated.

I found I misunderstood one part of the code around the send function when max_packet_size was taken into consideration and I thus fixed it and rerun the tests. The conclusion doesn't change much. Posting this mostly in case anybody wants to repeat the results. Numbers taken on a c5n.4xlarge EC2 instance.

MEDIAN
UDP
Copy
No-copy

1K dgrams, CPU sec
0.506169
1.3319005
1.3098825

1K dgrams, MiB/s
494.058696
185.786007
187.3379035

16K dgrams, CPU sec
0.962107
6.3041795
6.106201

16K dgrams, MiB/s
4250.329674
525.773377
525.9469895

STDDEV
UDP
Copy
No-copy

1K dgrams, CPU sec
0.003309591
0.00648492
0.010422114

1K dgrams, MiB/s
3.087541535
1.071140286
1.66477244

16K dgrams, CPU sec
0.010671619
0.025372608
0.029966428

16K dgrams, MiB/s
49.00906114
2.376173833
3.353950162

A bit snowed under here but expect a response over the weekend :) thanks again

Don't worry about it, take your time.
My plan regarding this currently is to go on a series of tasks (below the list) and then stop working on it until most of the material has been reviewed by you when time allows. I don't want to pressure :) but I don't want to block on my side at this time while I have the ball rolling; after all it's a work where 99% of the thing is getting knowledge and 1% is writing the code that does the job.
The tasks I was planning to face are:

[x] Perform the test in order to unlock a discussion over the interface
[x] Get some measures around the datagrams
[x] Suggest an interface (see Issue on the main project)
[x] Verify the interface is feasible
[x] Check some specs corner cases
[ ] Understand the role of congestion control when sending data made up mostly by datagrams

So far only the last one is remaining, after which I plan to stop and resume when you have more time to dedicate to this side activity.
Thanks btw, great library! :)

So taking a fresh look back at my datagram code and comparing it to other read operations in quiche, I kinda dislike the inconsistency of returning a Vec. I think I had my reasons at the time but from an API purist view I'm no longer sold.
So I think a refactor of the internal APIs would probably be a good thing, and then the C API proposal becomes a better fit and I think we can avoid the need of a _free function..

Thinking about the near future.
Other than some work around retransmission, I hope to get code to a PR-ready state (using proposal 2 as it seems the one which sparked the interest, but I can switch to 1 or do a more vanilla PR and then submit another one for the send queue customizations).
Unsurprisingly, it's a rather big PR, with multiple commits.
Would you prefer...

A large PR or several small incremental PRs ?
The PR to be sent to the cloudflare/quiche repo or yours ?
Changes to be rebased on top of the latest cloudflare/quiche/master or not and use a merge ?
Any other requirement ?

I'd like to concentrate work into this fork in order to minimise noise on the main quiche repo. So a rough plan would be to
step 1) sync up my datagram-frame branch in this branch to quiche master and refactor out the webtransport stuff to a separate branch.
step 2) internal refactor to move away from the current Vec code.
That should leave things in a place to add the C API in one PR, and then the additional changes in one or more PRs against this repo.
This lets us review and selectively land iterative changes for datagram here, and then at some checkpoint surface up that aggregate changes to the main quiche repo.
I was planning on doing steps 1 and 2 at the end of this week.
WDYT?

I think it makes perfect sense, as it would also give me the chance to re-submit the commits I have (many) in small, affordable batches :)
For step 2, if by that you mean the change of signature of dgram_recv and not a deeper change, I did it on my branch (https://github.com/xanathar/quiche/commit/0a5911e410955f7d51fca85e0c1da499ebf49bb5#diff-b4aea3e418ccdb71239b96952d9cddb6R2854) so you can copy/paste or I can submit a PR.

@xanathar for fear of getting lost in rebases and force pushes, I've created an alternative branch that rewrites history by taking out webtransport and squashing everything down into a single commit. I've then added a commit to refactor the API and internals, which makes dgram::DatagramQueue simpler and less duplicative. PTAL
https://github.com/LPardue/quiche/tree/datagram-frame-alt

Took a look and it definitely makes sense to me. Starting tomorrow I'll start sending PRs.
Just one thing. On the issue in the main project I suggested 2 proposals to be able to control the queue of outgoing datagrams: one exposing a function to selectively purge unwanted datagrams from the queue using a closure, and the other exposing a customizable queue. The closure one has an easier C interface and a syntax which is more Rust-idiomatic, the other allows for more customization. Any preference for the PRs or shall I just skip that part for now ?

On the issue in the main project I suggested 2 proposals to be able to control the queue of outgoing datagrams: one exposing a function to selectively purge unwanted datagrams from the queue using a closure, and the other exposing a customizable queue. The closure one has an easier C interface and a syntax which is more Rust-idiomatic, the other allows for more customization. Any preference for the PRs or shall I just skip that part for now ?

Good point, thanks for reminding me. My 2c: I am attracted to the customizable queue but now realise that this might cause some difficulty around the C API. The more conservative side of me leans to enhancing the existing model (your approach 1) and making progressive improvement steps that mature the underlying DATAGRAM code in quiche. That will empower people to build more advanced applications and provide more input to future design decisions. If customizable queue emerges as a need, then we can decide later whether it warrants a refactor to bring it in. WDYT?

I'm also more for approach 1 - it gives application developers plenty to do with datagrams and has already enough control built in. If the need arise between user, a more complex solution can be designed (likely, due to users' feedback, in an entirely different way which we can't even imagine right now), in the meantime this will do I think.
Btw, I started sending PRs; apart a couple of ones, most of them are WIPs because I'm waiting for the last one to perform a deeper complete end-to-end test to check for regressions in the rebase/rewrite process.
I'm also sending them... let's say "without flow control" 😅 Feel free to check them when you have time, with no hurry.

All PRs have been sent, except a minor one regarding qlog support which requires me to check with the qlog people (datagrams are not in the format, even if qvis displays them happily) and that one will take a little more time but it's, like, 10 lines.
I've integrated all the changes in a single branch on my side (https://github.com/xanathar/quiche/tree/lpdgalt-pr-integration-test) and everything seems to be working (both MacOS and Windows with different application code).
As such I marked all PRs as ready.
Btw - sorry again for the boringssl bit and the chaos that ensued to refactor that out of the PRs but this whole thing is.. big as you can see and it's becoming hard to manage.

Btw - sorry again for the boringssl bit and the chaos that ensued to refactor that out of the PRs but this whole thing is.. big as you can see and it's becoming hard to manage.

No problem, these things easily happen and it had no substantial effect on me.
Thanks for making these small PRs, it will keep discussion points focused and hopefully we can land the less contentious points.

Moved this to draft as it's mainly a centralized discussion now :)

I also moved all other pending PRs as Draft, and will unlock as Ready as soon as I address the feedback there (there's a lot of things on the plate for both of us to keep track of)

All (except the examples one) other PR's are unlocked now.
Just as an overall help, this is the DAG of the open PRs as it's becoming hard to follow. Tell me if you prefer a single big one.
              +----+
    +---------|  7 |----------+
    |         +----+          |
    |            |            |
    V            V            V
  +----+      +----+        +----+
  | 10 |      | 11 |        | 13 |
  +----+      +----+        +----+
    |            |            |
    |            |            |
    |         +----+          |
    |         | 12 |          |
    |         +----+          |
    |            |            |
    |            V            |
    |         +----+          |
    +-------->| 14 |<---------+
              +----+

Thanks! I'll try to review these soon and knock them down 1-by-1


Update the link to the KotlinSlack Arrow Channel

https://arrow-kt.io/slack/ returns 404.
https://slack-chats.kotlinlang.org/c/arrow is referenced in other places.

Many thanks!


feat(js/plugins/vertexai): add initial Mistral MaaS integration

This PR will resolve https://github.com/firebase/genkit/issues/1386

(samples included in testapps, documentation to follow)

TODO:

[x] switch out the custom HTTPServer and hooks etc for the standard SDK client approach (now that they're fixing it)
[x] handle streaming responses
[ ] comprehensive docs

Checklist (if applicable):

[x] PR title is following https://www.conventionalcommits.org/en/v1.0.0/
[x] Tested (manually, unit tested, etc.)
[ ] Docs updated (updated docs or a docs bug required)

Probably want to wait for https://github.com/mistralai/client-ts/issues/52 to be resolved (in their next release) so we can support 2411?


#1102 Add a method in gen to get a Random for a given optional seed

Seems good to me.
Thanks @ashishkujoy !


chore(apps/prod/tekton/setup): bump tekton operator to v0.65.1

Signed-off-by: wuhuizuo<EMAIL_ADDRESS>

/approve


steem.auth.verify does not appear to be working

<script src="https://cdn.steemjs.com/lib/latest/steem.min.js"></script>
<script type="text/javascript">
    console.log(steem.auth.verify("barbara2", "my_super_secret_password", ["posting"]))
</script>

This will always return 'false', despite username/password being correct.

The last params is wrong, you should pass an object with the public posting wif, see here: https://github.com/adcpm/steemauth/blob/master/test.js#L10

You're right.
function keyFromPassword(username, password, role) {
    const wif = steem.auth.toWif(username, password, role);
    // const pubWif = steem.auth.wifToPublic(wif);

    return new Promise((resolve, reject) => {
        validateKey(username, wif, role, (err, isKeyValid) => {
            if (err != null) {
                reject(err)
            }

            if (isKeyValid) {
                resolve(wif)
            } else {
                reject(Error("Invalid Key"))
            }

        })
    })
}

keyFromPassword("barbara2", 'supersecret', 'posting').then(console.log);

I'm starting to get a hang of this JS thing...


New CBMC header for TCB structs

Description
This PR adds a new CBMC header that declares some TCB structs which are currently defined in tasks.c. It also changes the last include path on MakefileCommon.json to be absolute, since otherwise the headers will not be found when proofs are grouped into a subfolder.
Checklist:

[x] Changes have been tested.
[x] Updates README.md with a line for tcb.h

@karkhaz @markrtuttle

Closing in favour of an approach that moves task.c declarations into a private header file, which is #included by task.c and the CBMC proofs. PR for that soon come.


Can't autoplay when setting multiple autoplay for true

The steps to reproduce.
Modify https://github.com/MoePlayer/APlayer/blob/master/demo/demo.js#L42
autoplay: false,

to
autoplay: true,

Error information
Demo.html:1 Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause(). https://goo.gl/LdLk22
Demo.html:1 Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause(). https://goo.gl/LdLk22

Screenshot

最近也是被这个问题苦恼，特别是换歌，而歌曲没有载入的时候，直接所有的歌都播放不了了，找到this.isMobile&&this.audio?(this.audio.src=this.music.url,this.play())，把 this.isMobile&&删掉，看看能不能解决，不过这样一来流量会变大。

We see this as well. You can read about the source of this issue at the shortlink in the console or simply click here.

Done. e2e8884a45229b23233932f554f399bd2ea9d191 cf5972879a27459445aaf730f7777c9400667881 fb4211a0b050a065f1ecc3e5eb37b97f0bd96ffc


calicoctl KDD manifest didn't just work with hosted install

I applied these two manifests on a CRC, kubeadm cluster (doing v3.0 alpha testing):
https://docs.projectcalico.org/master/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
https://docs.projectcalico.org/master/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml
This got calico working without any config tweaks.  Then I tried the calicoctl manifest:
https://docs.projectcalico.org/master/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calicoctl.yaml
I had hoped that it'd pick up the RBAC just like calico/node did but it seems not:
$ kubectl exec -n kube-system calicoctl calicoctl get wep
Failed to get resources: connection is unauthorized
command terminated with exit code 1

The version command partially works, giving my some hope that I'm actually running calicoctl:
$ kubectl exec -n kube-system calicoctl calicoctl version
Client Version:    v2.0.0-alpha1-rc2-13-g2434301a
Build date:        2017-10-27T04:01:42+0000
Git commit:        2434301a
Unable to retrieve Cluster Version or Type:  connection is unauthorized
command terminated with exit code 1

calico repo master is currently a742aa6d063bd3951b35e80926d96369bfc6fdc6
Expected Behavior

It'd be nice if we could make the calicoctl pod just work.
Current Behavior

Permission error with default config.
Possible Solution

Add RBAC service account for calicoctl?
Maybe we should pull it into the main set-up guide for hosted so it gets more attention.

Steps to Reproduce (for bugs)

Context

Your Environment

Calico version: 3.0 alpha1 rc2
Orchestrator version (e.g. kubernetes, mesos, rkt):

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:38:10Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Operating System and version: Linux smc--kubeadm-master 4.10.0-37-generic #41~16.04.1-Ubuntu SMP Fri Oct 6 22:42:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Link to your project (optional):

We probably want to port this back to v2.x as well - should just be a matter of shipping RBAC with the calicoctl manifest.

Yea it looks like it just needs the service account added to the manifest, PR incoming shortly.


fix 47

switch classloader when run ark test case or not.

Pull Request Test Coverage Report for Build 218

1 of 26 (3.85%) changed or added relevant lines in 3 files are covered.
59 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-1.9%) to 31.464%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sofa-ark-parent/support/ark-support-starter/src/main/java/com/alipay/sofa/ark/support/runner/ArkJUnit4Runner.java
0
3
0.0%

sofa-ark-parent/support/ark-support-starter/src/main/java/com/alipay/sofa/ark/support/runner/JUnitExecutionListener.java
0
22
0.0%

Files with Coverage Reduction
New Missed Lines
%

sofa-ark-parent/support/ark-support-starter/src/main/java/com/alipay/sofa/ark/support/runner/ArkJUnit4Runner.java
6
0.0%

sofa-ark-parent/support/ark-support-starter/src/main/java/com/alipay/sofa/ark/support/startup/SofaArkBootstrap.java
9
0.0%

sofa-ark-parent/support/ark-support-starter/src/main/java/com/alipay/sofa/ark/support/thread/LaunchRunner.java
19
0.0%

sofa-ark-parent/support/ark-support-starter/src/main/java/com/alipay/sofa/ark/support/common/DelegateArkContainer.java
25
0.0%

Totals

Change from base Build 216:
-1.9%

Covered Lines:
1105

Relevant Lines:
3512

💛  - Coveralls

fix #47

@straybirdzls  please squash these commit log when merge this pr..  😜


Historicals should return results from local cache ahead of the query queue

It doesn't make sense to wait for all the queries ahead in the queue to return the result from the local cache (Caffeine) immediately.
Related: #8356

Related: #8552


Compiler API (gulp support)

Move the exec from compiler.ts to a different file.
And improve the existing compiler interface.

Partially added #148 compile from Compiler.ts can now be imported. The option passing has to be improved tho. But for that we need to rewrite the cli parser.


Streamline dwindle groups

Definition
I had a look into the implementation of dwindle groups. For a clean design and rigorous implementation, I would propose the following definition:

For each tiling window, we have a terminal node (i.e. no further children) , to which the window is assigned to. A group is a non-terminal node in the dwindle tree, that exposes the window of one of its descendant terminal nodes (selectable),  solely, on the entire viewport of the group . Normal non-terminal nodes, in short nodes, don't do that and just distribute the remaining rendering space to its children.

Implementation guidelines
Implementation wise this can be achieved when sticking to the following principles:

Always keep the binary tree intact. Even with a group being present, they behave transparent with regard to the tree: Nodes/child nodes are handled (moved, resized, inserted, etc.) completely normal (like in case of a plain node)
A grouping action is just a matter of visualization and does not affect the tree structure: If a node turns into a group, it short-cuts the window rendering at this tree position and presents a window of it descendant child nodes.

Development state
In this PR, I implemented the outlined behavior to provide a proof of concept. It was easiest to discard the most recent changes w.r.t groups in the main branch (in particular c319a2aba9cf993d26af7af66a8632aad6a83d1b) and give it a fresh start.
Apart from a cleaner implementation, we gain the following:

Grouped nodes remember their original split-ratio when being ungrouped again
Groups of groups are possible now. Following the definition from above, an outer group still presents all reachable child windows. But if the outer group gets dissolved, the inner group becomes visible again.

Demo:
The following video:
https://user-images.githubusercontent.com/14107889/187093674-78678dcd-f4bd-48f5-9ac8-b2f2be38fb7f.mp4
demonstrates the new features. It is driven by the playbook below:
#!/bin/zsh

alias D="hyprctl dispatch"
alias S="sleep"

for i in `seq 3`; do
	S 0.5; D exec ~/.config/hypr/kitty-with-banner;
done

S 1; D resizeactive 120 120
S 2; D togglegroup 1
S 1; D focuswindow "title:.*001$"
S 1; D togglegroup 1
S 2; D togglegroup 0
S 1; D movewindow l
S 1; D focuswindow "title:.*003$"
S 1; D resizeactive -120 0
S 2; D togglegroup 0
S 1; D resizeactive 0 -120
S 1; D movewindow l

Unresolved issues:
Atm, a few things still need to be done:

[ ] Fullscreen requests are not handled probably. However, with the concept from above, maximized fullscreen windows can be represented with the top node turned into a group and the view being rotated to the desired window.
[ ] I did not care about decorations (Don't now how they work). Once this gets fixed, I would suggest to

[ ] use dedicated decoration colors for fullscreen windows, making them easier to identify

I submit this PR to trigger a discussion and get some feedback although the implementation is not finished and thoroughly tested.
I also do not now how much time I can invest into this within the next week, so help with the remaining issues would be appreciated. But imho, it would be worth it!

After some testing - this PR introduces a lot of issues the new rewrite was supposed to get rid of

closing the "master" node (the one from which the group was created) will remove the group
dragging any window from the group out does not work, dragging the "master" will break the group and cancel the drag
of course the issues you mentioned above
I dislike groups of groups - they are not intuitive, and like, why? Example: I have 3 windows, two on the right and one on the left. The left one is a group. While focused on the group, i use togglegroup. Should it make a new group, with the 3 windows, or dissolve the focused group? In your PR, it will dissolve, but the first time it's done that it was a bit of a "oh, thought it would make a group, no?"
I do agree there can be a problem where this would block the creation of a new group, but that can be solved differently, either by "eating" the subgroup or, after I do #541, a tint-like indicator.

Is all of this really worth it just to enable "remembering the layout"? I think we're missing the point of what most people want when they see groups. They want a group, not a façade.
That was my original thought regarding my group rewrite (c319a2aba9cf993d26af7af66a8632aad6a83d1b)
Feel free to prove me wrong, but I feel this is an overkill, and will lead to more issues than it solves. The only requests I've heard from people is #598, being groups of single windows. Never anything else.
Of course this PR also introduces some temporary issues, like the code styling not following the Hyprland code styling, but again, that's just a temporary easy-to-fix thing.
Feel free to elaborate on this PR.

Is all of this really worth it just to enable "remembering the layout"?

Worth? IDK. It is a wishlist item though.

Ok, thank's again for looking into this and your honest feedback. My reply gonna be a rather longish read (again) and will discuss things on a more general level. Sorry for this, I we want to discuss things further we might use a different place for it, since this not focused on the initial PR any more:
Let me first explain an example situation, in which I would like to use some kind of grouping feature:
I am scientist and when doing analysis a typical workspace looks like this:

One large editor window
At least one console window in which I execute the the scripts I am working on
(Multiple) result windows product by the scripts

In such a context I would like to group windows mostly for two reasons:

Give them all the same size, so that plots and alike can be compared. For this, you can also use floats
Temporarily magnify windows: As the grouped windows are displayed sequentially they can take up the entire group area on the screen. If I undo this, I do want my workspace to return to its former layout.

So, yes, I would say "remembering the layout" is important here. In particular a dynamic tiling algorithm should honor the (limited) adjustments that have been made by the user and try to preserve them. For the reset, it should deliver predictable results that follow a logic to which the user can adapt to -- and in my particular use case this is where the current implementation fails (cf the videos):
I made to videos, in which I compare the behavior of the main branch with this branch:
https://user-images.githubusercontent.com/14107889/188014795-4757a63e-6eb1-4bef-8191-4c25ba86373f.mp4
https://user-images.githubusercontent.com/14107889/188014807-99ad9bf9-71b3-4956-97c1-104e88ab054c.mp4
In case of this branch (not possible in the main branch atm) I also regroup a node being already a group. The group eating aspect (as you called it) can become quite handy to enlarge an already existent group. The fact that groups can be nested is not important and could be abandoned. With the decorations being fixed its also clear on which node the togglegroup operation has to be performed: The node not (yet) being a group.

With this in mind I tried to see how far I could get with the facade implementation. It was mostly a poc and atm I do not expect from it to deliver perfect results. But from my point of view this implementation looks cleaner (less if (grouped) {...} else segments scattered over the code, it looks like we could get rid of the dummy nodes being labeled with "massive hack"). So I would expect that the issues you presented could finally be resolved. And let me ask the other way around:
What are the things that would really break with this implementation approach?
However, I do admit that we are not there yet and I cannot guarantee that I can resolve all the issues in the near future (probably not, due to time constraints). I could still try to keep slowly/gradually working on this (so exactly the opposite to the current hyprland dev spirit) but only if has the realistic possibility of being finally merged in.
So, before discussing the details we should reach conclusion on:

I think we're missing the point of what most people want when they see groups. They want a group, not a façade.

Btw, do WM like bspwm or awesome offer a grouping feature for their dwindle layout. How do they handle them?
I would lean toward the facade, but this is the implementation perspective. From the user perspective, I want to have groups that do not deteriorate a window arrangement once they get dissolved again. How this is done behind the scenes is merely an academic discussion, that I have to admit.

This is how Hyprland should have been designed in the first place. The current implementation displays an abhorable lack of forethought; when writing software it is best to work around the premise of a prototype. You build something twice, expecting to throw it away the first time. This pull request is fundamentally correct; it deserves attention.

That's mostly how it used to work before, and was so difficult to manage it was dropped. It served no purpose whatsoever. Haven't seen a single person outside you two that complained about the way groups work.
The only requests atm regarding groups is #516 (well and #520 but that is cosmetic)

Believe me, I am still bothered by this almost every day...

From the user perspective, I want to have groups that do not deteriorate a window arrangement once they get dissolved again. How this is done behind the scenes is merely an academic discussion, that I have to admit.

Key aspect of this PR was to promote the facade aspect and to demonstrate that you can reach a concise design that delivers all the functionality that we expect + even more.
Also, none of the issued brought up @vaxerski  seem to fundamentally contradict with my approach, though it still needs some development work.
Once it is is finished, I beg to differ here:

and was so difficult to manage

I am quite busy at the moment, but I have not forgotten about this PR and whenever I find the time, I would like to work on it/ bring it forward again

This is how Hyprland should have been designed in the first place.

I think this is quite debatable!
Sometimes it's just what you discover on the way, that turns out to be the right solution.
I think if you try to guess beforehand what the best thing is going to be, you might wasting time thinking, when in reality you can't even know at that time.

You build something twice, expecting to throw it away the first time.

It's a luxury be allowed to rewrite and change stuff on the way, when you discover how things actually should work.
A luxury that a big team, possible with a deadline, doesn't always have.
But i think if you can work that way, it often leads to better more original software.

A luxury that a big team, possible with a deadline, doesn't always have.
But i think if you can work that way, it often leads to better more original software.

I just wanted to point out, that it's quite easy to state things like:

The current implementation displays an abhorable lack of forethought

at a point where you have already gained information by trying things.

@Dickby Apologies. Perhaps this was a bit harsh. I say this because I made my own prototype in OpenGL and came up with the exact solution provided by this PR.


Tag version

@JuliaRegistrator register
Release notes:
This is a preliminary release of a statistical toolbox that does inference for diffusion processes based on path imputation with guided proposals. For more details see the README.md. The first (non-preliminary) release of the package will be announced at a later time.

Registration pull request created: JuliaRegistries/General/3595
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.1 -m "<description of version>" 8803e2c658288f4bb1d4de5d31966722078d9050
git push origin v0.1.1


Tapping on category should open category filter

Description of issue
When user taps on category box, nothing happens
Expected behaviour
When user taps on either Showing [All event types]
or [name of category filter]
They should be taken to the category filter

When user scrolls on the category filter this should scroll horizontally and not take the user to the category filter

Adding that users should be able to click on the categories on the event pages in order to be taken to the category filtered events listing (after seeing lots of people try to click on them)

Should this be closed @declanslevin ?

Yeh this is working now.


docs: Improve API docs in common/lib packages

Improve API docs in common packages
The intention behind this PR is to improve API documentation on the consumer-facing APIs of the @fluidframework/protocol-definitions, @fluidframework/common-definitions, and @fluidframework/common-utils packages.
These docs are not (currently) published to our public site, but they are published to our eng-hub wiki

common-definitions
common-utils
protocol-definitions

Some of these types and functions also bubble up through more public-facing packages, so having clear and nicely formatted documentation for these packages' APIs is important.
The TODOs and comments I left are in search of suggestions from area experts.  If you are reviewing this and know of someone who would have expertise and/or opinions on the docs, please feel free to tag them 🙂
ADO #969
This PR also adds a missing API report for common-utils

Committing some of the changes separately in #11093

@gary is added to the review. #Closed