QoS behavior bis

Environment

VerneMQ Version: 1.12.3 (docker)
OS: Fedora
VerneMQ configuration (vernemq.conf) or the changes from the default: Set only ACCEPT_EULA / ALLOW_ANONYMOUS / UPGRADE_OUTGOING_QOS
Cluster size/standalone: standalone

Expected behaviour
I test locally the behaviour of VerneMQ using mosquitto clients when subscriber and publisher are using different QoS level.
What I'm expecting is resumed in "3.8.4 Response" in "Non normative examples" and "Non normative comment" of http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html:
Subscribing to a Topic Filter at QoS 2 is equivalent to saying "I would like to receive Messages matching this filter at the QoS with which they were published". This means a publisher is responsible for determining the maximum QoS a Message can be delivered at, but a subscriber is able to require that the Server downgrades the QoS to one more suitable for its usage.

Actual behaviour
I get a message with QoS 2:

Client null received PUBLISH (d0, q2, r0, m1, 'topic1', ... (4 bytes))
Client null sending PUBREC (m1, rc0)
Client null received PUBREL (Mid: 1)
Client null sending PUBCOMP (m1)
ciao

The same if I send a message with QoS 1 (always received a QoS 2 message).
I tested this scenario with a Mosquitto Server and it follows the specification.
I think this issue is related to #741, it seems that the variable UPGRADE_OUTGOING_QOS is always on regardless of the value that I assign to it.
Thanks
Domenico

@dometec thanks, ups did we break the spec again? :)
Seriously, though, I think we implemented it looking at it from the other side, instead of downgrading the consumer, we "upgrade" to what the publisher says. Which should be the same, but maybe we missed a thing. (for instance not downgrade when Consumer QoS > Publisher QoS).
Specifically, what behaviour do you see when upgrade_outgoing_qos is on?

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

Thanks, @ioolkos, I don't notice any changes.
However, I see others have interpreted the specs in this way, for example (see the Note): https://subscription.packtpub.com/book/application_development/9781787287815/1/ch01lvl1sec19/learning-about-the-different-quality-of-service-levels

@dometec the spec non-normatively but nevertheless clearly seems to state this, yes.
Never seen any problems with the way Verne implements this. Still will have to look into this and decide whether to adapt behaviour.
Thanks!

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

Additional context: I think we originally had a wrong understanding for this, and it got never corrected.
In short, we implemented a configurable upgrade of the Subscriber QoS to the Publisher QoS. If off, the Subscriber QoS would always stay at the configured QoS level.
The spec says to use the Publisher QoS as a default for the Subscriber QoS (within the configured Subscriber QoS as "highest" QoS to be accepted). The configurable "upgrade" then should upgrade to the Subscriber QoS, not the Publisher QoS.

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@ioolkos I'm not sure that you've got exactly the point. It's not a matter of downgrading or upgrading neither the Subscriber QoS nor the Publisher QoS. It's about selection of QoS that the Server has to use to deliver a message to a subscribed Client. And mandatory statement [MQTT-3.8.4-6] in section 3.8.4 of MQTT v3.1.1 specification is really clear about this:
The Server might grant a lower maximum QoS than the subscriber requested. The QoS of Payload Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published message and the maximum QoS granted by the Server.
Therefore, Server default behaviour MUST be the specified one, using the minimum.
If you would like a non-standard option that forces the Server to always use the Subscriber QoS (or, better, the maximum QoS the Server has granted to the Subscriber), I would not call it upgrade_outgoing_qos as it is misleading due to the fact that in some cases it is not upgrading but downgrading message QoS.
Looking at next piece of code in vmq_server/src/vmq_mqtt_fsm.erl, comment seems OK, but about Erlang implementation I do not know enough:

%% The MQTT specification requires that the QoS of a message delivered to a
%% subscriber is never upgraded to match the QoS of the subscription. If
%% upgrade_outgoing_qos is set true, messages sent to a subscriber will always
%% match the QoS of its subscription. This is a non-standard option not provided
%% for by the spec.
-spec maybe_upgrade_qos(qos(), qos(),state()) -> qos().
maybe_upgrade_qos(SubQoS, PubQoS, ) when SubQoS =< PubQoS ->
%% already ref counted in vmq_reg
SubQoS;
maybe_upgrade_qos(SubQoS, PubQoS, #state{upgrade_qos=true}) when SubQoS > PubQoS ->
%% already ref counted in vmq_reg
SubQoS;
maybe_upgrade_qos(, PubQoS, _) ->
%% matches when PubQoS is smaller than SubQoS and upgrade_qos=false
%% SubQoS = 0, PubQoS cannot be smaller than 0, --> matched in first case
%% SubQoS = 1|2, PubQoS = 0 ---> this case
PubQoS.


bonus popup should have icon at the top

same icon as receive

Look as expected.
The bonus income have the same icon, as a daily income.


Same column for IE & Edge?

I was wondering why IE & Edge aren't under one “IE/Edge” column.
I don't know how most people feel about this, but I view Edge as the successor of IE, with a different name and a different engine. The version numbers are also lined up to suggest that.
Putting both names in the same column could save a bit of screen real estate too.
Mind you, I haven't used IE in a long time, so maybe I'm missing something.

Edge as the successor of IE, with a different name and a different engine.

This and that the engine is way less bad than IE justifies the treatment as separate browser, and not just another newer version of IE. (Also, Edge has a more regular update cycle, wherefore devs can assume Edge is being used as 'latest', whereas each version of IE needs its own treatment.)

I see. Like I said, never tried Edge and didn't use IE for years. Guess I'm missing out.

When Edge was released, both were indeed put in the same column for the reasons you described. However it was requested to split the two up, which I think helps save on confusion. So no plans no revert back to the previous behavior.


Add placeauctionbid dftx + tx builder

What kind of PR is this?:

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

Fixes part of #532
Additional comments?:

@canonbrother why remove vault going to active state after a successful auction end of the first batch? I think we can still include itthinking

that one was actually same as this should placeAuctionBid on all batches
so regarding the vault recovery by bidding one index only test, i simulated it previously its very difficult, no matter how, that's still have nano range to get vault recover.

@canonbrother why remove vault going to active state after a successful auction end of the first batch? I think we can still include itthinking

that one was actually same as this should placeAuctionBid on all batches so regarding the vault recovery by bidding one index only test, i simulated it previously its very difficult, no matter how, that's still have nano figure to leave vault inLiquidation. (still under liquidation due to the nano range)

indeed this is not easy to catch unless you trick the price. I added a test for this. you can refer it.
Also, I tried mimicing the python test and it failed. While debugging it i noticed the following.
{'vaultId': 'e50ef72256abe8c6eeee48702d3d1762c92e6ba36020e76acf2c562e3b405e61', 'loanSchemeId': 'LOAN200', 'ownerAddress': 'mwsZw8nF7pKxWH8eoKL9tPxTpaFkz7QeLU', 'state': 'active', 'collateralAmounts': ['60.00000000@DFI', '60.00000000@BTC'], 'loanAmounts': ['60.00002283@TSLA'], 'interestAmounts': ['0.00002283@TSLA'], 'collateralValue': Decimal('12000.00000000'), 'loanValue': Decimal('6000.00228300'), 'interestValue': Decimal('0.00228300'), 'informativeRatio': Decimal('199.99992390'), 'collateralRatio': 200}
{'vaultId': 'e50ef72256abe8c6eeee48702d3d1762c92e6ba36020e76acf2c562e3b405e61', 'loanSchemeId': 'LOAN200', 'ownerAddress': 'mwsZw8nF7pKxWH8eoKL9tPxTpaFkz7QeLU', 'state': 'inLiquidation', 'liquidationHeight': 636, 'batchCount': 2, 'liquidationPenalty': Decimal('5.00000000'), 'batches': [{'index': 0, 'collaterals': ['49.99999980@DFI', '49.99999980@BTC'], 'loan': '50.00020907@TSLA'}, {'index': 1, 'collaterals': ['10.00000020@DFI', '10.00000020@BTC'], 'loan': '10.00004206@TSLA'}]}
{'vaultId': 'e50ef72256abe8c6eeee48702d3d1762c92e6ba36020e76acf2c562e3b405e61', 'loanSchemeId': 'LOAN200', 'ownerAddress': 'mwsZw8nF7pKxWH8eoKL9tPxTpaFkz7QeLU', 'state': 'active', 'collateralAmounts': ['16.73490473@DFI', '10.00000020@BTC'], 'loanAmounts': ['10.00004586@TSLA'], 'interestAmounts': ['0.00000380@TSLA'], 'collateralValue': Decimal('2673.49049300'), 'loanValue': Decimal('1010.00463186'), 'interestValue': Decimal('0.00038380'), 'informativeRatio': Decimal('264.70081509'), 'collateralRatio': 265}

notice the last entry for vault details. it has 16.73490473@DFI as collateral. Actually, for that test, this is what increases the col ratio. Hence the vault survives the reliquidation. Not sure from where these extra DFI came in🤔. can not be from auctions. needs further looking.


routing.ai.juniper.net

Can you please add support for routing.ai.juniper.net
Thanks Thomas!
Nick

Support of Routing Assurance has been added to 4.0.0


Consider falling back to a statically generated response when no example key exists from Prefer header

If you pass a Prefer header with an example key, and that key does not exist, then Prism returns an error
Request terminated with error: https://stoplight.io/prism/errors#NOT_FOUND: The server cannot find the requested content
It would be useful for Prism to fallback to static generation (or dynamic if set) if this happens instead of throwing an error.
Context
We are using Prefer headers to control the examples that we deliver, but don't necessarily need examples for every endpoint. It would be nice to still send the Prefer header key, but fallback to static generation if it doesn't exist

thanks for the issue @louzena-inshur. we are reluctant to implement this as it could cause unexpected behavior in the case of typos or other bad configuration. we find it important that the client is aware of this mismatch. we would take a PR to improve the response error message (and status code).

Thanks @daniel-white , that makes sense with improving the response error message and that you'd want to be explicit if a keyed example was not found.
Perhaps one to think about - having an argument on the CLI for fallbacks like this. Could fallback to a singular 'example' if it exists, when an argument is set?

Released in 5.8.2.


Turn tests into Jobs

At least in the 1.4 Fabric version, tests and other only-one-use pods are deployed thought a deployment and not a job. I think it is better to have them as a job to limit resource usage once everything is deployed.
This is more a discussion than an actual issue, but can lead to some changes.

Yes, makes sense. Would you like to submit a PR?

I would like to, but I do not have an AWS account for testing usage and I do not want to spend any money in helping. However, I want to help.
If It is useful, I can try to modify deployment files but they have to be tested by another one. I actually have a lot of things in mind to be changed/improved which I am going to turn into issues/pr as long as I have time for it.

There is already a PR. I have been trying to modify also the /k8s-templates/fabric-deployment-register* YAML files to turn them into jobs, but the script also has to be modified. The problem here is that when the peer/org/orderer has already been registered, the script returns an error, which is interpreted as a fatal error by Kubernetes (setting the job status as Error).
To solve this, I recommend to not return an error but a warning in the script, and end the execution with a 0 status. However, this is very different from this issue, so should be debated in another one.


Publishing api path lookup

There is now an endpoint for looking up content ids by base paths, which we can do in a single request, so we can remove the dependency on content store.
https://trello.com/c/IhmS82zW/562-whitehall-replace-content-store-with-publishing-api-lookup

nice :+1:


Proper use of pagination in AWS queries

To permit more than a single page of results in any resource listing.

Coverage remained the same at 100.0% when pulling 70058a811df7c49d7e0913738d39439e776c7abf on uberblah:pagination into 918540bc85560a9f566f919eca7fa484af53326a on dtan4:master.

Coverage remained the same at 100.0% when pulling 9ca002aead54483d45ba1c0ed3ba8a5595859618 on uberblah:pagination into 918540bc85560a9f566f919eca7fa484af53326a on dtan4:master.

Sorry for late review 🙇
As described at https://aws.amazon.com/jp/blogs/developer/response-paging/ , paging loop can be written more simply using Enumerator. I prefer this style.
iam = Aws::IAM.new
iam.list_users.each do |response|
  puts response.users.map(&:user_name)
end


Enabling Bi-Directional (Full-on) Access Changes to Disabled (by design)

Under "Monitor all files in Real time protection", we are instructed to set "Configure monitoring for incoming and outgoing file and program activity" to "Enabled" with the option "bi-directional (full-on access)" but when we do, GPM Editor shows the policy state as "Disabled".
After researching this further, I found this Q&A which states that this is by design. The setting is just badly worded as pointed out here: https://docs.microsoft.com/en-us/answers/questions/492031/windows-defender-real-time-pretection-configuratio.html.
Should this note be added to the documentation for clarity?

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

ID: 523651c3-a318-2369-6892-d13e04991596
Version Independent ID: 624c5e05-f87d-1bd4-bc87-bd55dcac1d86
Content: Onboard Windows devices to Microsoft Defender for Endpoint via Group Policy
Content Source: microsoft-365/security/defender-endpoint/configure-endpoints-gp.md
Product: m365-security
Technology: mde
GitHub Login: @mjcaparas
Microsoft Alias: macapara

@lccctemp Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/7101
Once the author approves, the changes will be live.
Thanks
Sri

@msbemba Thank you very much for the contribution and updating the documentation with PR. @lccctemp Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Create new ticket type: subtitles

Reported by pegro on 6 Jan 2014 16:50 UTC
May be it's useful to have subtitle tickets for automated processing and releasing of such files.

Modified by texec on 18 Jan 2014 21:31 UTC


Introduce super-linter action for linting JSON, XML, ENV files and bash_exec

Why are the changes needed?

introduce action/super-linter with multiple linters, (https://github.com/marketplace/actions/super-linter)
using the smaller size version of image github/super-linter/slim for faster image pulling
enable linting for bash_exec for checking executable of bash scripts, with fixed tools/spark-block-cleaner/kubernetes/docker/entrypoint.sh
enable linting for JSON files, with removing licence header in kyuubi-server/web-ui/tsconfig.json
enable linting for XML files
enable linting for ENV files

How was this patch tested?

[x] Pass CI jobs

Fix https://github.com/apache/kyuubi/actions/runs/4393204237/jobs/7693453883#step:4:29
2023-03-11 16:40:51 [WARN]   Warnings found in [bash-exec] linter!
2023-03-11 16:40:51 [WARN]   Error: File:[/github/workspace/tools/spark-block-cleaner/kubernetes/docker/entrypoint.sh] is not executable

The follow-up to do after this PR:

apply linting for shell scripts with shellcheck tool.

until super-linter merged this PR to support config severity.  The super-linter is currently showing too many verbose messages of INFO level which causes errors and failures.
this PR (https://github.com/apache/kyuubi/pull/4500) helps fix the auto-fixable violation in shell scripts.

The licence header in JSON files like kyuubi-server/web-ui/tsconfig.json, as comments are not supported originally in JSON. As in Spark, eslint.json is also remained without licence header.

Actually, the extended JSON format supports comments syntax.

Actually, the extended JSON format supports comments syntax.
we use JSON file in original style

Codecov Report

Merging #4295 (43787e2) into master (8267108) will decrease coverage by 0.04%.
The diff coverage is n/a.

:exclamation: Current head 43787e2 differs from pull request most recent head 497bf80. Consider uploading reports for the commit 497bf80 to get more accurate results

@@             Coverage Diff              @@
##             master    #4295      +/-   ##
============================================
- Coverage     53.37%   53.34%   -0.04%
  Complexity       13       13
============================================
  Files           571      571
  Lines         31294    31294
  Branches       4219     4219
============================================
- Hits          16703    16693      -10
- Misses        13012    13020       +8
- Partials       1579     1581       +2

see 6 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

It's ready for review. Have a check when you have time.
cc @pan3793

Thanks, merged to master.


Openssl updates

Opening this up to give some visibility.
@datanoise this is mostly code from you, I'm just turning it into a more up-to-date PR that matches current progress in the stdlib. A :+1: or :-1: would be awesome.
All others, feel free to help or give feedback. Slow in coming as I've hit a few oddities with OpenSSL (which oddly enough also exist in the Ruby OpenSSL stdlib). At least it's consistent :grimacing:

If I recall correctly we weren't sure about adding those classes, because there are lots of digest methods; they may not all be available in the compiled OpenSSL; why have some classes for some digests but not others; ... Having a single interface for all digests sounded better.

@ysbaddaden I can get behind that.

I guess a question here, what min-version of OpenSSL are we looking to support?

This is ready to go with the exception of the build failure due to out of date OpenSSL on the "no arch" build. I'd appreciate feedback and some guidance on the require convention for these kinds of libraries. Lots of things requiring similar things. Not sure how to approach it in the sense of whether to push people to just require "openssl" or be able to piecemeal it.

This was tested locally against OpenSSL 1.0.2f  28 Jan 2016. Not sure what CI is running.

Also, unrelated (but maybe related?) make spec fails for me with:
make spec
./bin/crystal build  -o .build/all_spec spec/all_spec.cr
Using compiled compiler at .build/crystal
Error: execution of command failed with code: 127: `cc -o ".build/all_spec" "${@}"  -rdynamic  -lxml2 -lssl -lz -lcrypto -lreadline -lgmp -lyaml /Users/plukevdh/src/Articulate/tooling/vendor/crystal/src/llvm/ext/llvm_ext.o `(llvm-config-3.6 --libs --system-libs --ldflags 2> /dev/null) || (llvm-config-3.5 --libs --system-libs --ldflags 2> /dev/null) || (llvm-config --libs --system-libs --ldflags 2>/dev/null)` -lstdc++ /Users/plukevdh/src/Articulate/tooling/vendor/crystal/src/ext/libcrystal.a -levent -lpcre -liconv -lgc -lpthread -ldl`
make: *** [.build/all_spec] Error 127

I can successfully run ./bin/crystal spec though.

I believe TravisCI uses Ubuntu Precise. Only the upcoming Xenial supports OpenSSL 1.0.2f. Trusty only has 1.0.1f and I don't know for Precise.

Errata: the build fails on OSX. I believe this is Maverick, I don't know which OpenSSL version is installed.

From my install, it's definitely an old one. Not sure how old off hand though I can check this tomorrow. Are we wanting to support vanilla install or push for adoption of newer OpenSSL?

After unlinking homebrew's verison, the default OSX install is OpenSSL 0.9.8zg 14 July 2015

I was about to send in a PR with less OpenSSL ported from @datanoise and added ssl methods on HTTP::Client. But now that I see this, it looks far more complete.
Should I wait until we fix this or send in my smaller PR? (mine just adds 2 LibSSL functions and 2 SSL methods: TLSv1 and SSLv3, but it does add some stuff to HTTP::Client.)

@jeromegn I would send multiple small PRs (or: I would start with one, wait for it to be merged, send another one, etc.). Huge PRs like this are very hard to review and take a lot of time. If the PR is small and focused it has many more changes to be merged. Thank you! :-)

#triage
This appears to have stalled, CI failed, and is no longer mergable.
The efforts undertaken in previously linked PRs, and @ysbaddaden appears to have become the defacto leader on OpenSSL-in-Crystal.
Should this PR remain open? Is there any value?

This PR still does a lot more than we integrated with @jhass, most notably generate/sign/validate with DSA/RSA keys. Right now we mostly only have what was required for a (hopefully) secure TLS communication (sockets, contexts) and validation (SNI, hostname).
It needs a rebase and clean commits. If someone is courageous enough to work on this.

Headsup.
I merged this to my branch and rebased it against master. See https://github.com/crystal-lang/crystal/compare/master...discord-tech:openssl-updates-from-2180
Needs a bit of work still, all the merged specs don't work anymore. I'll make a PR a bit later if I get things to work at least a bit. I don't have extensive openssl knowledge, so any PR I make needs to be scrutinized rather well.

Will glad to see updated PR from you @vegai

Closing because it's not mergeable. Please send small individual PRs so we can more easily review them.


feat: use apiKey instead of basic auth

fix #511
Sends the push request using the format Authorization: APiKey <token> instead of basic auth headers - https://www.elastic.co/guide/en/kibana/master/api-keys.html

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-05-24T22:41:00.543+0000

Duration: 15 min 50 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
161

Skipped
2

Total
163

:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.


harfbuzz warning: Cannot set "HARFBUZZ_FOUND": current scope has no parent.

Describe the bug
harfbuzz output warnings when I try to use qtbase.
CMake Warning (dev) at C:/vcpkg/installed/x64-windows-static-md/share/harfbuzz/harfbuzzConfig.cmake:68 (set):
  Cannot set "HARFBUZZ_FOUND": current scope has no parent.
Call Stack (most recent call first):
  C:/vcpkg/scripts/buildsystems/vcpkg.cmake:805 (_find_package)
  C:/vcpkg/installed/x64-windows-static-md/share/Qt6/FindWrapSystemHarfbuzz.cmake:9 (find_package)
  C:/vcpkg/scripts/buildsystems/vcpkg.cmake:805 (_find_package)
  C:/vcpkg/installed/x64-windows-static-md/share/Qt6/QtFindWrapHelper.cmake:66 (find_package)
  C:/vcpkg/installed/x64-windows-static-md/share/Qt6/FindWrapHarfbuzz.cmake:3 (qt_find_package_system_or_bundled)
  C:/vcpkg/scripts/buildsystems/vcpkg.cmake:805 (_find_package)
  C:/Program Files/CMake/share/cmake-3.23/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
  C:/vcpkg/installed/x64-windows-static-md/share/Qt6Gui/Qt6GuiDependencies.cmake:45 (find_dependency)
  C:/vcpkg/installed/x64-windows-static-md/share/Qt6Gui/Qt6GuiConfig.cmake:40 (include)
  C:/vcpkg/scripts/buildsystems/vcpkg.cmake:805 (_find_package)
  C:/vcpkg/installed/x64-windows-static-md/share/Qt6/Qt6Config.cmake:177 (find_package)
  C:/vcpkg/scripts/buildsystems/vcpkg.cmake:805 (_find_package)
  CMakeLists.txt:31 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

Environment

OS: Windows
Compiler: VS2022  MSVC 19.32.31326.0

To Reproduce
Steps to reproduce the behavior:

./vcpkg install qtbase:x64-windows-static-md
use find_package(Qt6 COMPONENTS Core Gui Widgets Required)
See warning output when using cmake.exe -DCMAKE_BUILD_TYPE=Debug -DVCPKG_TARGET_TRIPLET=x64-windows-static-md -DCMAKE_TOOLCHAIN_FILE=C:\vcpkg\scripts\buildsystems\vcpkg.cmake -G "CodeBlocks - NMake Makefiles" ..

Expected behavior
No warnings
Additional context
triplet: x64-windows-static-md

Duplicate of #23694.


fish: migrate to Homebrew

Deleting fish from cask as part of deduplication process . See context here.
Please note that this PR is created to continue case-by-case discussions from thread linked above and if decision is made not to remove the cask, PR will be closed.

These are actually different. I removed fish a while ago and renamed fishapp to fish.

Sorry, I see.


🌱 Minor fixes to make Makefile build work

What this PR does / why we need it:
Building docker images fails with a fresh checkout, because the Makefile requires two kustomize patch files that do not exist yet.
Also, the default image name, cluster-api-controller, is misleading. I chaged it to cluster-api-addons-helm-provider which makes the function more obvious.

/check-cla

/check-cla

/check_cla

/ok-to-test

@jabbrwcky Thanks for the contribution, I think I ended up fixing this issue in #41 and #42 where I set it up to publish images.

I believe the build should work now, let me know if it's working for you!

@jabbrwcky I did notice that after my PR merged, the Tilt provider fails to spin up. I'm pretty sure we can fix it by changing tilt-provider.yaml so that the image points to gcr.io/k8s-staging-cluster-api-helm/cluster-api-helm-controller:latest instead. If you'd like to rebase and add that to your PR, I think we'd be good to merge it.

IDK why the PR closed 😕


File.tmpfile requires administrator rights on Windows

verylonglogin.reg reported this on 2012-02-18T00:42:44Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=7537
CC List

bugzilla
bugzilla
dlang-bugzilla
lovelydear

Description
---
import std.stdio;

void main() {
    File.tmpfile();
}
---
dmd 2.058 compiled version running from non-administrator fails with: std.exception.ErrnoException Could not create temporary file with tmpfile() (Permission denied) at std\stdio.d(875)

dlang-bugzilla commented on 2012-04-19T09:10:28Z
The filename is chosen by the C runtime, not the operating system. It is a bug in the DigitalMars C runtime. It probably tries to use the hard-coded %WINDIR%\Temp directory, instead of the user profile directory or %TEMP%.

dlang-bugzilla commented on 2012-04-05T19:23:30Z
File.tmpfile is just a simple wrapper around core.stdc.stdio.tmpfile, so the issue is with the DMC's C standard library.

lovelydear commented on 2012-04-19T09:09:13Z
(In reply to comment #3)
> What?? How is this not a bug?

The OS prevents to create the file, so tmpfile() throws an exception. I don't see how this can be considered a bug.

lovelydear commented on 2012-04-19T09:01:44Z
This is not a bug. It works as intended. Should close.

bugzilla commented on 2012-04-19T11:23:55Z
(In reply to comment #5)
> The filename is chosen by the C runtime, not the operating system. It is a bug
> in the DigitalMars C runtime. It probably tries to use the hard-coded
> %WINDIR%\Temp directory, instead of the user profile directory or %TEMP%.

Actually, it uses stdio.h's _P_tmpdir, which on Windows is "\\". Did I say that implementation is rather old? I also noticed that Windows 7 does not allow writing to the root directory. XP allowed it.

lovelydear commented on 2012-04-19T09:19:52Z
Oh, I just saw the author of the issue. It's not "random Denis".
Anyway, has a bug report been done in DMC C bugzilla ?
Else this one will stay open forever, I'm affraid.

bugzilla commented on 2012-04-19T12:15:09Z
I have it fixed in snn.lib now. You can pick it up here:

ftp://ftp.digitalmars.com/dmc.zip

bugzilla commented on 2019-12-12T16:58:52Z
Is this still not fixed?


Update intro to remove old packaging language.

Summary
This is a small fix to update the changelog intro to remove references to packaging. I'm assuming this page is only for self-hosted Mattermost, so feel free to remove that mention if I'm wrong.
Ticket Link
n/a

@BenLloydPearson @cwarnermm Curious why are we removing the reference? It is referencing the two different binaries (Team Edition, Enterprise Edition) with two different licensing. It's not related to our packaging.


Added optimal settings for travis

Thanks for the contribution! However, we already have an optimal travis config.


[Enhancement] Fast Scanning

💡 Summary
Provide alternate techniques to find CDN behind target domains and/or Simplify the uses of CDN Engine. The latest engine doesn't quite cut it in a matter of speed, the scanning can be ranging from 1-15/s wich is quite slow, the ideal target should be atleast 0,5-1/s. Using threading with max cpu_count also can't help very much.
Motivation and context
This is a problem when scanning list of subdomain , the reason is; some subdomain could have different CDN than the parent domain. Resulting in giant number of subdomain.
For Example:
Parent Domain: line.me
Parent CDN: Amazon CloudFront
Subdomain: blog.clova.line.me
Subdomain CDN: CloudFlare
Why does this work belong in this project?
This would be useful for scanning giant list of subdomain and enhancing the CDN Engine. As for example; I have about 166000 approximate lines of target-list with per domain scanning takes up >1/s, resulting in thousand of minute until finish.
Scan Times
Implementation notes
The alternate way could be using public database such as HackerTarget or DnsDumpster to return CDN Value.
Or providing some parameter to ignore specified steps such as --skip whois, this also could cut times but not recommended
Or Probably enhancing current CDN Engine?
Acceptance criteria

[ ] Target Times 0-1/s

I can confirm that running a single target line.me took a whopping 51s

I spent a good amount of time with this today, and came to the following rough conclusions:

Switching to asyncio inside of the executor doesn't really help much, there's a lot of long blocking IO going on.
Adjusting the threads and timeout helps a lot, in all modes.

I was able to get a roughly 100% speed increase by using 30 threads and timeout of 30s instead of 60s.
I think the timeout is far and away the most important factor. Higher than about 30 threads I Would get WHOIS lookup failures, so I assume I was getting rate limited by that service.

For my use case, anything faster than 30 threads, approximately, causes me to run into a WHOIS throttling issue, so there's no real reason for me to boost performance faster than 100domains/min, unless I can get unrestricted WHOIS queries going.
Similarly, with that as a upper limit for my own performance, even when swapping out the threading or reorganizing the workflow, I don't really beat the original time because I still have to wait for all the WHOIS queries.
If I need to go further, I'd probably break it across several containers/hosts/pods/whatever and add some launcher to split up the input list into multiple chunks and reconstitute the output at the end , as that's almost certainly guaranteed to work and be a cheap/easy solution.

Thoughts
I am looking to add something to the scanning engine in the near future but the concept would be:

Have address pools of top X CDNs (cloudflare, cloudfront, etc)
Resolve given domain to IP or IPs via DNS query
Cross check IP addresses discovered using known IP pools.
If nothing found, fallback to using other methods.

Then we can avoid using the other methods since we already know what the CDN is. Then if we want information from those sources, we can maybe add a force flag to make it still run those checks.
Results
I did some testing with this and got the IP blocks for the following CDNs:

Incapsula
Cloudflare
Akamai
Cloudfront
CacheFly
Airee
Edgecast
MaxCDN
Beluga
Limelight
Fastly
Myracloud
Azure
Clever-cloud
FastCDN

Did some preliminary testing and got the following results (note these do not include the fallback):
FINDCDN: 12.271649267000612
RESULTS:
{'date': '11/23/2022, 16:54:17', 'cdn_count': '4', 'domains': {'line.me': {'IP': "'<IP_ADDRESS>', '<IP_ADDRESS>'", 'cdns': "'.cloudfront.net'", 'cdns_by_names': "'Cloudfront'"}, 'asu.edu': {'IP': "'<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>'", 'cdns': "'.fastly.net', '.nocookie.net'", 'cdns_by_names': "'Fastly', 'Fastly'"}, 'cisa.gov': {'IP': "'<IP_ADDRESS>'", 'cdns': "'.edgekey.net', '.akamaitechnologies.fr'", 'cdns_by_names': "'Akamai', 'Akamai'"}, 'www.dmv.ca.gov': {'IP': "'<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>'", 'cdns': "'.cloudfront.net'", 'cdns_by_names': "'Cloudfront'"}}}
CUSTOM: 0.005282060999888927
RESULTS
[{'line.me': [None]}, {'asu.edu': ['Fastly']}, {'cisa.gov': ['Akamai']}, {'www.dmv.ca.gov': ['Cloudfront']}]

So there is default everything on the Findcdn side. Hereis the test code:
from dns.resolver import NXDOMAIN, NoAnswer, NoNameservers, Resolver, Timeout, resolve
from ipaddress import ip_network, ip_address
from timeit import default_timer as timer
from findcdn import main

CDN_RANGES = {
    "Incapsula": [
        ip_network("<IP_ADDRESS>/21"),
        ip_network("<IP_ADDRESS>/19"),
        ip_network("<IP_ADDRESS>/21"),
        ip_network("<IP_ADDRESS>/22"),
        ip_network("<IP_ADDRESS>/22"),
        ip_network("<IP_ADDRESS>/22"),
        ip_network("<IP_ADDRESS>/18"),
        ip_network("<IP_ADDRESS>/16"),
        ip_network("<IP_ADDRESS>/16"),
        ip_network("<IP_ADDRESS>/16"),
    ],
   # ... (more for each cdn mentioned)
]

def check_cdn(domain):
    # Resolve domain ip address
    resp = resolve(domain)
    ips = []
    for ip in resp:
        if str(ip.address) not in ips:
            ips.append(ip_address(str(ip.address)))
    # For each IP, perform a check on CDN_RANGES
    cdns = []
    for ip in ips:
        FOUND = None
        for cdn, ranges in CDN_RANGES.items():
            for rng in ranges:
                if ip in rng:
                    FOUND = cdn
                    break
            if FOUND:
                break
        cdns.append(FOUND)
    return list(set(cdns))

DOMAINS = [
    "line.me",
    "asu.edu",
    "cisa.gov",
    "www.dmv.ca.gov"
]

# Test using Findcdn
import json

start = timer()

result = main(DOMAINS)

stop = timer()

print(f"FINDCDN: {stop - start}")
print("RESULTS:")
print(json.loads(result))

# Test using custom
start = timer()
res = []
for dom in DOMAINS:
    res.append({dom : check_cdn(dom)})
stop = timer()

print(f"CUSTOM: {stop - start}")
print("RESULTS")
print(res)

To follow up on the above comment:

For Cloudfront blocks I used: https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips
For Fastly blocks I used: https://api.fastly.com/public-ip-list
For Azure I used https://management.azure.com/providers/Microsoft.Cdn/edgenodes?api-version=2021-06-01 (requires auth token though)
Then for everything else I either used the ASN for the specific CDN  via ipinfo.io or publicly available information on their CDN blocks.

CDE v2 Notes
Some status updates. Went through and changed a bunch in how the v1 engine worked. Now:

All analyses are modularized
If one engine finds the CDN first, it skips the rest and moves to the next domain (single threaded)

├── analyzers
│   ├── analyzers.yml
│   ├── base.py
│   ├── __cdn_config__.py
│   ├── cnamelyzer.py
│   ├── httplyzer.py
│   ├── __init__.py
│   ├── iplyzer.py
│   └── whoislyzer.py
└── cdnEngine.py

With the cdnEngine being:
from findcdn.cev2.analyzers import ANALYZERS

def analyze_domain(domain: str):
    for analyzer in ANALYZERS.keys():
        a = ANALYZERS[analyzer]['class']
        results, error_code = a.run(domain)
        # print(f"{analyzer} ==> {results} {error_code}")
        if len(results) > 0:
            break # CDN has been found
    return results

And the init.py for analyzers does some dynamic import magic
# Third-Party Libraries
from yaml import safe_load

# Internal Libraries

# Get path where the modules should be
PWD = path.dirname(path.realpath(__file__))

# Load in analyzers config file
with open(f"{PWD}/analyzers.yml", "r") as fp:
    analyzers = safe_load(fp)

ANALYZERS = {}
for analyzer, attribs in analyzers['analyzers'].items():
    spec = util.spec_from_file_location(attribs['classname'], f"{PWD}/{attribs['filename']}")
    module = util.module_from_spec(spec)
    spec.loader.exec_module(module)
    ANALYZERS[attribs['classname']] = {
        "class": getattr(module, attribs['classname'])(), # instantiate the class here
        "arg": attribs['argument']
    }

Not sure how liked this type of importing is. I would say I like it because then all someone needs to do to extend findcdn with another module is to add another file into the analyzers folder and add to the analyzers.yml file without having to worry about the code imports too much. Im not biased either way between this method or just explicitly defining the imports in init.py.
V1 vs V2 Results
TL;DR
V2: 12.519790108985035 s (single "thread")
V1: 34.34032432202366 s (4 co routine workers)
Detailed
For this I was curious what the runtime of single threaded V2 would be against the co-routine V1 with 4 workers. These are the results of running the two against each other for the following set of domains:

www.asu.edu
www.cisa.gov
www.netflix.com
www.leagueoflegends.com
github.com
www.cdnplanet.com
pascal-0x90.github.io
line.me
blog.clova.line.me
www.achp.gov
twitter.com
platform.twitter.com

Starting CDN Engine v2
================================
www.asu.edu ==> ['Fastly']
www.cisa.gov ==> ['Akamai']
www.netflix.com ==> []
www.leagueoflegends.com ==> ['Akamai']
github.com ==> []
www.cdnplanet.com ==> ['Cloudflare']
pascal-0x90.github.io ==> ['Fastly']
line.me ==> ['Cloudfront']
blog.clova.line.me ==> ['Cloudflare']
www.achp.gov ==> []
twitter.com ==> ['Twitter']
platform.twitter.com ==> ['Edgecast']

v2 Finished in: 12.519790108985035 s

================================
Starting CDN Engine v1
================================
{
    "date": "11/25/2022, 21:19:38",
    "cdn_count": "10",
    "domains": {
        "www.asu.edu": {
            "IP": "'<IP_ADDRESS>'",
            "cdns": "'.fastly.net', '.nocookie.net'",
            "cdns_by_names": "'Fastly', 'Fastly'"
        },
        "www.cisa.gov": {
            "IP": "'<IP_ADDRESS>'",
            "cdns": "'.edgekey.net', '.akamaitechnologies.fr'",
            "cdns_by_names": "'Akamai', 'Akamai'"
        },
        "www.leagueoflegends.com": {
            "IP": "'<IP_ADDRESS>'",
            "cdns": "'.edgekey.net', '.akamaitechnologies.fr'",
            "cdns_by_names": "'Akamai', 'Akamai'"
        },
        "www.cdnplanet.com": {
            "IP": "'<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>'",
            "cdns": "'.cloudflare.com'",
            "cdns_by_names": "'Cloudflare'"
        },
        "pascal-0x90.github.io": {
            "IP": "'<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>'",
            "cdns": "'.nocookie.net'",
            "cdns_by_names": "'Fastly'"
        },
        "line.me": {
            "IP": "'<IP_ADDRESS>', '<IP_ADDRESS>'",
            "cdns": "'.cloudfront.net'",
            "cdns_by_names": "'Cloudfront'"
        },
        "blog.clova.line.me": {
            "IP": "'<IP_ADDRESS>', '<IP_ADDRESS>'",
            "cdns": "'.cloudflare.com'",
            "cdns_by_names": "'Cloudflare'"
        },
        "www.achp.gov": {
            "IP": "'<IP_ADDRESS>', '<IP_ADDRESS>'",
            "cdns": "'.amazonaws.com'",
            "cdns_by_names": "'Amazon AWS'"
        },
        "twitter.com": {
            "IP": "'<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>', '<IP_ADDRESS>'",
            "cdns": "'.twimg.com'",
            "cdns_by_names": "'Twitter'"
        },
        "platform.twitter.com": {
            "IP": "'<IP_ADDRESS>'",
            "cdns": "'.wac.', 'edgecastcdn.net', '.v5cdn.net'",
            "cdns_by_names": "'EdgeCast', 'EdgeCast', 'EdgeCast'"
        }
    }
}

v1 Finished in: 34.34032432202366 s

Why www.netflix.com results in Empty CDN?
> www.netflix.com
> <IP_ADDRESS>
> EC2-18-200-8-190.EU-WEST-1.COMPUTE.AMAZONAWS.COM

This based on https://subdomainfinder.c99.nl/ and https://bgpview.io/ip/<IP_ADDRESS>

At least according to CDN Planet with their CDN Finder, here, Netflix does not use a CDN. Another tool I use to validate, Wappalyzer, does not identify any CDN being used by www.netflix.com.
On that note though, yes the site itself may be hosted in AWS but it is not indicative of a CDN. You would need to use Cloudfront and put that in front of your ec2 by setting up an ALB as described here.
If this logic is flawed and folks think that identifiers of AWS mean CDN then I can fix that identifier otherwise I took out the line that says
".*\.amazonaws\.com": "Amazon AWS"

in cdn_config since that had too many false positives.
I would also like to note, it does not mean they are not using a load balancer, it just is not a CDN. So it is possible to see X-CACHE type tags but it does not mean it is part of a CDN.

Nice! Seems like a very positive change, let me know i I can help somehow!


(3.0.0 hotfix)

Hotfix: replace java with java-platform with an exclude for :serverversion
Issue:

stickyapi-common depended on serverversion, which is not published
stickyapi had no dependencies

Edit: if the root jar is now effectively a meta package (just a pom pointing to other modules) do we still need rootSources? 🤔
Issues

[x] stickyapi X.X.X API title missing from aggregate javadocs

Now shows: StickyAPI X.X.X API (Aggregated)

3.0.1 checklist (as of c232fa28c6b42c4f4f32e16a4381383f21484e20)

[x] Check stickyapi meta-pom (implementation platform("com.dumbdogdiner:stickyapi:3.0.1"))

runtimeClasspath - Runtime classpath of source set 'main'.
\--- com.dumbdogdiner:stickyapi:3.0.1
     +--- com.dumbdogdiner:stickyapi-bukkit:3.0.1
     |    +--- org.jetbrains:annotations:20.1.0
     |    +--- io.github.classgraph:classgraph:4.8.104
     |    +--- com.github.seancfoley:ipaddress:5.3.3
     |    \--- com.dumbdogdiner:stickyapi-common:3.0.1
     |         +--- org.jetbrains:annotations:20.1.0
     |         +--- io.github.classgraph:classgraph:4.8.104
     |         +--- com.github.seancfoley:ipaddress:5.3.3
     |         +--- com.google.code.gson:gson:2.8.6
     |         \--- com.dumbdogdiner:stickyapi-config:3.0.1
     |              +--- org.jetbrains:annotations:20.1.0
     |              +--- io.github.classgraph:classgraph:4.8.104
     |              \--- com.github.seancfoley:ipaddress:5.3.3
     +--- com.dumbdogdiner:stickyapi-bungee:3.0.1
     |    +--- org.jetbrains:annotations:20.1.0
     |    +--- io.github.classgraph:classgraph:4.8.104
     |    +--- com.github.seancfoley:ipaddress:5.3.3
     |    \--- com.dumbdogdiner:stickyapi-common:3.0.1 (*)
     +--- com.dumbdogdiner:stickyapi-common:3.0.1 (*)
     \--- com.dumbdogdiner:stickyapi-config:3.0.1 (*)

[x] Check stickyapi-common (implementation "com.dumbdogdiner:stickyapi-common:3.0.1")

runtimeClasspath - Runtime classpath of source set 'main'.
\--- com.dumbdogdiner:stickyapi-common:3.0.1
     +--- org.jetbrains:annotations:20.1.0
     +--- io.github.classgraph:classgraph:4.8.104
     +--- com.github.seancfoley:ipaddress:5.3.3
     +--- com.google.code.gson:gson:2.8.6
     \--- com.dumbdogdiner:stickyapi-config:3.0.1
          +--- org.jetbrains:annotations:20.1.0
          +--- io.github.classgraph:classgraph:4.8.104
          \--- com.github.seancfoley:ipaddress:5.3.3

[x] Check includes for stickyapi-common
[x] Check includes for stickyapi-bukkit
[x] Check sources for stickyapi (includes serverversion?)
[x] Check sources for stickyapi-common (includes serverversion?)

Oop, spoke too late ><


Upgrade eslint and its plugins to latest versions

Description
Upgrade eslint and its plugins to latest versions
Notes
Need help updating the js/jsx code to pass new lint tests.
Tests

I will be taking over this issue.


Alternative package for ShareDB and Meteor

Hi,
As part of our project to build a Meteor platform for authoring collaborative learning exercises FROG, we had the need to embed collaborative editing deeply, including simple text, rich text, and even collaboratively editable forms - we use react-jsonschema-forms very extensively in our tool, and wanted to see if we could make these collaboratively editable.
We had a student (Dario Anongba) work with us for one semester on this project. Initially we wanted him to look at embedding ShareDB into Meteor, and we were very inspired by this repository. As his work progressed, we realized we could release a pure JS package, instead of a Meteor package, with React components that make it extremely easy to begin using ShareDB, including a simple textarea, the Quill editor, and most interesting, react-jsonschema-form (RJF). RJF is a tool made by Mozilla which can generate very complex forms based on a simple JSON object specification. Our package supports most of the RJF functionality, and let's you easily construct a form with multiple text fields, checkboxes, select menus etc, which are all synced to a ShareDB collection, maintaining cursor position for the text fields, etc.
We published the work in the package collab-react-components. We hope this would be useful to the community, and would love feedback about the API design, the implementation etc. It is trivial to add this to a Meteor app (just add two lines to server.js). He also had some early work on coordinating between ShareDB collections and Mongo collections, which can be found here, but in the end we decided to go towards a pure JS package, because we will not need this kind of one-to-one mapping in our Meteor app anyway.
One final thing that you might find interesting is the way we handle shared data between learning activities. The idea is that learning activities are pluggable NPM packages, which should not know anything about Meteor or database structure etc. Instead, they export React components, which receive as props data, an arbitrarily complex JSON object, and dataFn, a collection of functions to operate on the data structure. In the background, all the synchronization is done with ShareDB at ot-json0, and it works really well. Our platform is in rapid development, but if you're interested, the main files to look at are
managing the ShareDB server, and automatically generating new collections based on templates
https://github.com/chili-epfl/FROG/blob/develop/frog/server/share-db-manager.js
the data functions that manipulate a JSON object, just a wrapping over ot-json0 ops
https://github.com/chili-epfl/FROG/blob/develop/frog/imports/api/generateReactiveFn.js
a React higher-order component which wraps a component and lets it receive live-updating ShareDB data
https://github.com/chili-epfl/FROG/blob/develop/frog/imports/ui/StudentView/ReactiveHOC.jsx
an example activity - a fully fledged chat, which live-updates, in 30 not very dense lines (imagine that the groups are split into groups, which generates different collections, so that you will have multiple chat "rooms" at the same time). The beauty is that there is nothing in all the files above specific to chat, and the same thing works just as well for our other activities.
https://github.com/chili-epfl/FROG/blob/develop/ac/ac-chat/src/Chat.jsx
Would love to keep in touch with anyone using ShareDB for interesting stuff, or using Meteor for synchronous collaboration etc.

Very nice, thanks for sharing it.


Improving the look of the Headings

@RIKI-05 may I look to improve the Headings such as Hygiene, Categories etc by editing the borders of the same?

Please Go Ahead @Swap-nil-2003

@RIKI-05 thanks! Could you please add the hacktoberfest label to it as well.


Active YouTube livestreams result in error (sometimes)

"Video does not have a chat replay."
I noticed that that appears after a livestream is finished but before the live chat is available.
However, for active livestreams that in progress, as I test this more than the first occurrence I experienced, for a 2nd different active livestream, I wasn't able to reproduce it because the script output the same as above, however, trying a few livestreams at https://www.youtube.com/results?search_query=live&sp=EgJAAQ%253D%253D to reproduce the error, I can find other livestreams that result in the same error. Due to the nature of time-sensitivity, I can't provide any specific examples that will work in future, but I'm sure you can find one to reproduce the same error experience where the script fails with:
Traceback (most recent call last):
  File "chat_replay_downloader.py", line 449, in <module>
    chat_messages = chat_downloader.get_chat_replay(
  File "chat_replay_downloader.py", line 404, in get_chat_replay
    return self.get_youtube_messages(match.group(1), start_time, end_time, message_type)
  File "chat_replay_downloader.py", line 332, in get_youtube_messages
    data = self.__parse_item(item)
  File "chat_replay_downloader.py", line 235, in __parse_item
    self.__time_to_seconds(data['time_text']))
KeyError: 'time_text'

Note: The line numbers might be off by 1 because I edited the script per my last issue report
The data['time_text'] doesn't exist, but I see that some of the data is available. For example this was the value of data:
{'message': 'Oh ty', 'author': '• Lacy •', 'timestamp': '1603504526543501'}

Perhaps for active livestreams that are in progress, the python script can, instead of using already post-processed calculated time values, the script can generate these calculations or otherwise remove them?
I can't find a way to get the unix epoch timestamp for when a livestream started, so that it can be used to calculate time elapsed for each message in data that doesn't contain 'time_text'

Thanks for posting! Let me look into it. 😃

I can't find a way to get the unix epoch timestamp for when a livestream started, so that it can be used to calculate time elapsed for each message in data that doesn't contain 'time_text'

This was a big issue I had early into development for the tool. Without calling the API (I want to ensure this requires no authentication and can be used by anyone), there are no proper ways to get the start time. One way I thought of solving this was to work backwards: They give a time stamp, and I calculate the start time using the epoch time the message was sent (e.g. subtracting 0:10 from the epoch time). However, this yielded inaccurate times.

Let me know if that works! 😃 I made it print out the timestamp instead of the time text (which doesn't exist). There were also some other issues to fix with other live streams.
As you mentioned above, it is difficult to give examples (due to time sensitivity), so we sort of need to solve errors on a per-case basis. If you find any errors, I'll do my best to fix it asap. 👍


package request: wezterm

Project description
It's another GPU-accelerated terminal emulator written in Rust. Seems natural to include in nixpkgs.
https://github.com/wez/wezterm
Metadata

homepage URL: https://github.com/wez/wezterm
source URL: https://github.com/wez/wezterm
license: MIT
platforms: unix

I recently tried to build it following the docs.  I tried to figure out how the dependencies are called on nixos.  The get-deps script is only for other distros.
This is my attempt
nix-shell --run "cargo build --release" -p cargo gcc cmake dbus fontconfig pkgconf python3 wayland libxkbcommon xorg.libX11 xorg.xcbutilkeysyms xorg.xcbutilwm dbus_libs

but it fails when trying to compile the x11 crate. Do you know which package I need to use on nixos to compile that?

There is some discussion on wezterm's gitter: https://gitter.im/wezterm/Lobby?at=5fada3f5b4283c208a5f7d5c
Here is a recap':
I tried to build it as well a few days ago:
The standard buildRustPackage helper does something wonky with the packages and I get a version error with some dependencies.
Building the latest stable release manually with cargo doesn't work either for a different reason. The rust version of nixos 20.09 is too old (v1.45 vs v1.47), the build has been fixed in master for rust 1.45.
I tried to update to rust 1.47, but I got the same error. I think I did something wrong (still relatively new to Nix).
I tried to compile the latest master with rust 1.45, it works, but then when I run it I get an error saying it can't find libEGL.so.
And I stopped searching for now. If anyone wants to continue, feel free!

I'm in the process of packaging wezterm and have succeeded to build and run it from a nix-shell environment. However, packaging it is proving difficult due to issues with the dependency vendoring that the rustPlatform.buildRustPackage entails. I reproduced using cargo vendor alone and created a ticket upstream so we can get this resolved: https://github.com/wez/wezterm/issues/337


parseDate(new Date().toISOString()) fails

Provide a general summary of the issue here
Both of these fail (version 3.5.0):
import { parseDate, parseDateTime} from '@internationalized/date';
console.log(parseDate(new Date().toISOString()))
console.log(parseDateTime(new Date().toISOString()));

I'm likely doing something wrong, though.
🤔 Expected Behavior?
The dates to parse
😯 Current Behavior
Invalid ISO 8601 date string: 2023-12-02T16:39:55.850Z
💁 Possible Solution
No response
🔦 Context
No response
🖥 Steps to Reproduce
stackblitz is down for maintenance:
import { parseDate, parseDateTime } from '@internationalized/date';

console.log(parseDate(new Date().toISOString()));
console.log(parseDateTime(new Date().toISOString()));

Version
3.5.0
What browsers are you seeing the problem on?
Chrome
If other, please specify.
No response
What operating system are you using?
mac
🧢 Your Company/Team
No response
🕷 Tracking Issue
No response

Date.toISOString returns an absolute time with date, time, and time zone components. You need parseAbsolute to parse that. parseDate only parses dates, and parseDateTime parses dates and times without a time zone.


Gradle build is failing for lib v5.1.0

Describe the bug
Gradle builds fail on expo clouds
To Reproduce
Steps to reproduce the behavior:

Import the latest version of 5.1.0
Build the application

Expected behavior
The build should successfully complete
Gradle log
FAILURE: Build failed with an exception.

* What went wrong:

Execution failed for task ':app:processDebugMainManifest'.

> Manifest merger failed : uses-sdk:minSdkVersion 21 cannot be smaller than version 33 declared in library [:maniac-tech_react-native-expo-read-sms]<EMAIL_ADDRESS>as the library might be using APIs not available in 21

  	Suggestion: use a compatible library with a minSdk of at most 21,

  		or increase this project's minSdk version to at least 33,

  		or use tools:overrideLibrary="com.reactlibrary" to force usage (may lead to runtime failures)

* Try:

> Run with --stacktrace option to get the stack trace.

> Run with --info or --debug option to get more log output.

> Run with --scan to get full insights.

* Get more help at https://help.gradle.org/

BUILD FAILED in 4m 31s

Error: Gradle build failed with unknown error. See logs for the "Run gradlew" phase for more information.

Fixed with Gradle v8 support PR.

I get this error on expo 51.0.21 with gradle version 8.6
 Could not resolve all task dependencies for configuration ':maniac-tech_react-native-expo-read-sms:classpath'.             > Could not resolve com.android.tools.build:gradle:8.0.0.               Required by:                   project :maniac-tech_react-native-expo-read-sms
             is it a way to fix it without downgrading my gradle ?


masteryOptions can be null, account for this in attack activity

If not weapon mastery options, weapon attacks failed. Null can be returned by masteryOptions get.

This change would mean that dialogConfig.masteryOptions is never undefined, so we unnecessarily show a blank drop-down. I've pushed a fix for rolling attacks that preserves passing undefined to dialogConfig.masterOptions when appropriate.

Thanks, wasn't sure if this was the right approach!


Try to Rewrite Animation

Following Function should be work:

Play and Pause.
Cooldown when m_looping == true & animate end.
Change Animate Speed SetInterval(), you can press k to test.
Looping toggle.
STATE::ENDED When m_looping == false & animate end.

This push may fix #131?
(depend on my reading skill...)
how to test:
(please set DEFAULT_LOG_LEVEL = Util::Logger::Level::TRACE)

pause animate( press A )
Set Animate Visible to false ( press B )
play animate ( press S )
Wait 10s ( as long as you want )
Set Animate Visible to true ( pressV )
see the log trace if right? (the log should be continue number(currentframe) after Set the Visible to true).


swapping out HashMap for OrderMap

Swapping out OrderMap for HashMap resulted in a pretty dramatic speedup for our multithread example. While running with 1B loop iterations, runtime under a profiler (linux perf) dropped from 48 minutes to 14 minutes.

This is addressed better in #10


Make typedefs for all function pointer types

Doxygen and sphinx barf on function pointer types. For each function pointer, make a typedef, then replace its accompanying declarations with the typedef.

This is small enough it should be doable for all projects at once.

Fixed toolbox typedefs in 0e33ec56c3b4bfac9a221547d26dc2d8555f7244

Fixed in master.


feat: add flag for chart based zarf.yaml and update templated fields in chart deployments

Description
Updates npx pepr build to take in an optional argument --zarf chart|manifest so that the generated zarf yaml will use the generated chart vs the manifest. Default behavior is still to use the manifest. pepr 822
Also adds templating to the pod annotations on the deployments and extra volume/volumeMounts
in support of uds-core 417
I tested the generation locally for both the --zarf flag as well as rendering the templates with a values file that added pod annotations and extra volumes. There didn't seems to be any area really covering testing this right now. The existing tests in helm.test.ts do still generically check the templates are valid that were updated here.
Related Issue
Fixes #
822
Relates to #
417
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Other (security config, docs update, etc)

Checklist before merging

[x] Test, docs, adr added or updated as needed
[x] Contributor Guide Steps followed

@zachariahmiller this is really great work. Just went through and ran everything locally and added the new flags to the helm chart and everything is working well. Thanks for the PR.


Bug 1701422: Use port 443 for registry service

Adds port 443 as the primary serving port on the registry service
Maintain port 5000 for backwards-compatibility
Drops port number on internal registry hostname

/assign @dmage
/hold
Likely blocked by openshift/origin#23408

/retest

/retest
Flakes (to be investigated).
Upgrades passing means we are keeping backwards compatibility?

No, it doesn't mean that we haven't broken backward compatibility. #267+#312 is a good example.

/test e2e-aws-builds
/hold
Builds do a lot of pull/push, so this can capture a few things.
What I really would like is a test that does the following:

Starts on a pre-cluster with imagestreams imported and a new-app template deployed.
Upgrades to the new internal registry hostname.
Runs an action that utilizes an "old" pull spec (start-build, maybe?)

I'll run this manually to sketch out a test case.

New PR updating the service account controller so that each port creates an auth token: https://github.com/openshift/openshift-controller-manager/pull/7


go-nats panic

Versions of gnatsd and affected client libraries used:
gnatsd v1.0.4 download from github release binary
client library version 1.3.1

OS/Container environment:
CentOS 6.8 64Bit bare VM
Steps or code to reproduce the issue:
gnatsd is run with single node
The go *nats.Conn is used in multiple goroutines, each of which may publish message and pushsrv subscribe 6 topics with the same connection.
When there are a lot of concurrent users login into the service , the pushsrv panic with the below message :
panic: sync: negative WaitGroup counter
goroutine 9291 [running]:
sync.(*WaitGroup).Add(0xc42121a530, 0xffffffffffffffff)
/usr/local/go/src/sync/waitgroup.go:75 +0x134
sync.(*WaitGroup).Done(0xc42121a530)
/usr/local/go/src/sync/waitgroup.go:100 +0x34
pushsrv/vendor/github.com/nats-io/go-nats.(*Conn).readLoop(0xc4200b6a00, 0xc42121a530)
/data/home/go_workspace/src/pushsrv/vendor/github.com/nats-io/go-nats/nats.go:1554 +0x238
created by pushsrv/vendor/github.com/nats-io/go-nats.(*Conn).spinUpGoRoutines
/data/home/go_workspace/src/pushsrv/vendor/github.com/nats-io/go-nats/nats.go:979 +0xb1

I had fixed  a similar issue in 1.3.0, so I will have another look. In the meantime, could you check for me the go client details? There is no 1.3.1, and I looked at few of the releases and the line numbers don't match any.
Again, I am going to try to write a test that can reproduce, but would love some clarification on the client version you are using. Alternatively, I see that you are vendoring: have you tried to update your vendor go-nats directory with the latest release?

Thanks kozlovic,
There is not a release version named 1.3.1 really in the release category. I clone the client library via go get command in the 2017, I found there is a constant in value Version in the nats.go
package nats

import (
	"bufio"
	"bytes"
	"crypto/tls"
	"crypto/x509"
	"encoding/json"
	"errors"
	"fmt"
	"io/ioutil"
	"math/rand"
	"net"
	"net/url"
	"regexp"
	"runtime"
	"strconv"
	"strings"
	"sync"
	"time"

	"github.com/nats-io/go-nats/util"
	"github.com/nats-io/nuid"
)

// Default Constants
const (
	Version                 = "1.3.1"
	DefaultURL              = "nats://localhost:4222"
	DefaultPort             = 4222
	DefaultMaxReconnect     = 60
	DefaultReconnectWait    = 2 * time.Second
	DefaultTimeout          = 2 * time.Second
	DefaultPingInterval     = 2 * time.Minute
	DefaultMaxPingOut       = 2
	DefaultMaxChanLen       = 8192            // 8k
	DefaultReconnectBufSize = 8 * 1024 * 1024 // 8MB
	RequestChanLen          = 8
	LangString              = "go"
)

// STALE_CONNECTION is for detection and proper handling of stale connections.
const STALE_CONNECTION = "stale connection"
...

Later  last night when we were running stress testing on another imsrv, which is using the same copy of the nats client, there was an other panic stack info
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x8763a1]

goroutine 62661 [running]:
imsrv/vendor/github.com/nats-io/go-nats.(*Conn).parse(0xc4200bea00, 0xc42591e000, 0x8000, 0x8000, 0x8000, 0x0)
 /data/home/user_00/go_workspace/src/imsrv/vendor/github.com/nats-io/go-nats/parser.go:278 +0xe61
imsrv/vendor/github.com/nats-io/go-nats.(*Conn).readLoop(0xc4200bea00, 0xc423975e10)
 /data/home/user_00/go_workspace/src/imsrv/vendor/github.com/nats-io/go-nats/nats.go:1545 +0x1d0
created by imsrv/vendor/github.com/nats-io/go-nats.(*Conn).spinUpGoRoutines
 /data/home/user_00/go_workspace/src/imsrv/vendor/github.com/nats-io/go-nats/nats.go:979 +0xb1

We will look into it for sure, but we do recommend using a formal release. If possible use the latest release found here: https://github.com/nats-io/go-nats/releases/tag/v1.5.0

@shengery These are really strange crashes. Would you mind showing how you create the NATS connection and give us as much information as possible as how you use it? Thanks!

Thanks. Need to dig more into that, but still very confused with the stack. For instance, from your original report, we see that:
goroutine 9291 [running]:
sync.(*WaitGroup).Add(0xc42121a530, 0xffffffffffffffff)
/usr/local/go/src/sync/waitgroup.go:75 +0x134
sync.(*WaitGroup).Done(0xc42121a530)
/usr/local/go/src/sync/waitgroup.go:100 +0x34
pushsrv/vendor/github.com/nats-io/go-nats.(*Conn).readLoop(0xc4200b6a00, 0xc42121a530)
/data/home/go_workspace/src/pushsrv/vendor/github.com/nats-io/go-nats/nats.go:1554 +0x238

Yet, you can see that from the 1.3.0 tag, this line has nothing to do with the report:
nats.go line 1554
The line should point to something like this.

hi @kozlovic , the commit in my vendor repository should be at the commit a2b049bedd9f04e9c033655e7ad7dc8404d44aa2
I put the client library via go get  command , not directly download the release version .

hi @kozlovic , is there any further investigation ?

Sorry for the delay, I was on vacation. I may refactor a bit the code around that for a fix to #368, but not sure what the problem for this issue is since the rare panic due to waitgroup was already fixed (or at least an attempt to) in 1.3.0.
Have you had a chance to try yourself with the latest release?

@kozlovic thanks for your reply
We are currently using the latest release version , the problem has not shown yet.

Closing for now.. we will re-open if you have some updates.


check-ttf: Added "Heavy" font styles

Hey folks,
Black was not enough for some folks over on the GF team. We now have Heavy ;)

I've added the style name and set its weight to 950.
Please do not merge this if it's going to cause problems. @davelab6 & @felipesanches what are your thoughts on this?
Cheers,
Marc

well... even though FontBakery is meant to be useful as a generic tool, in reality it is really crafted to the purposes of onboarding fonts into Google Fonts. So, if the GF team has an updated naming-scheme, it seems reasonable to incorporate that into fontbakery checks.
I think it can't be harmful so I'll merge it. But of course, in case @davelab6 has a different opinion we may as easily revert it later (if needed).

No no no, this can't be allowed, sorry :)
Heavy is a mistake by the upstream, and requires changing the sources to comply with the 9 weights, Thin to Black, 100 to 900.

@davelab6 Thank you so much!
Alright, I'll break the news to Jacques. If he cries, it is your fault.
Cheers,
Marc

That screenshot looks like the new Nunito from @fonthausen - there are 9 weight total, so everything needs to be renamed to run Thin to Black

Or, we can run 200 to 900 and then the Heavy can be a single style family.

If we did that, then Regular would then become the light weight, it would then look a lot lighter than the previous Regular.
I'm not so cool with this approach.

What other name options do we have for heavy type ? Because, like Marc I wouldn't change the name of the lighter weights

We make the Black weight the Heavy, then delete the Heavy, like this:

No, I wouldn't do that because the jump between ExBd and Bk is too big.
Glyphs offers names like UltraBold etc.

Black could become UltraBold, Heavy could become Black

Ok, I'm closing this now.
I'll submit an issue on the Nunito repo.
Cheers,
Marc

I agree, the release team - you me and @graphicore - need to check how much difference we are introducing into each family in all browsers on all platforms and note that in the project's release notes etc

@fonthausen sadly the way CSS works today, there is only Bold (700), ExtraBold (800) and Black (900). In the future, Variable Fonts will provide 1000 possible instances, allowing a Heavy to be available in a weight progression at 1000, and allowing a hairline at 1. But for now, if we want to keep to your designed progression at the very top, we need to split the Heavy out into its own family.

(In the past, Work Sans also offered 10 weights and I proposed having the darkest as a single style display family, but in the end, I decided to get it reinterpolated as a single 9 weight family.)

@davelab6 @Fonthausen I have no problems with making the Heavy font a separate family. This solution has the least work as well.

@m4rc1e see it as an opportunity to create another 7 levels of blackness off the scale!

https://www.youtube.com/watch?v=46kXH6GGtT0 (Spinal Tap)


UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   ext4   defaults,nofail   1   2

below /etc/fstab entry is not working on system reboot.
UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   ext4   defaults,nofail   1   2
Issue fixed by adding below entry (used xfs instead of ext4)
UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   xfs   defaults,nofail   1   2
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6fde1939-787d-2aa5-4b29-d303f8ed49cb
Version Independent ID: c2838cb5-c34c-e0ff-b280-b86f29453cad
Content: Attach a data disk to a Linux VM - Azure Linux Virtual Machines
Content Source: articles/virtual-machines/linux/attach-disk-portal.md
Service: virtual-machines-linux
Sub-service: disks
GitHub Login: @cynthn
Microsoft Alias: cynthn

@pulakiitr Thanks for the Feedback on the document.
As mentioned in the document based on the sudo blkid command output, you have to give the type of the file system.

As you mentioned that the issue is fixed by replacing the ext4 with xfs, so the drive type in your case could be XFS.
As the document has the mention of this XFS type, at this point we are no updating this document. And the example in the document are for illustration purpose only and these could be examples for providing idea on the setup in this case.
Hope that is helpful.

you guy's already updated document from ext4 to xfs and saying no document updated needed.

@pulakiitr The other issue was opened 4 days ago.
However, the issue you opened was few hours back and you mentioned that the doc needs to be updated, which means you were still seeing the old document.
It takes some time usually for the doc changes to reflect. Thanks.


[Test] Add @escaping to async refactoring tests

The async refactorings ignore whether a completion handler had
@escaping or not. In preparation of fixing this, fix up all functions
to have @escaping for their completion handler parameter.
Also some small miscellaneous fixes in order to reduce the number of
warnings output on test failures and also the addition of REQUIRES: concurrency on all tests.

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - fabb02100fd2547f36d497bb350d37ff573cef94

@swift-ci please clean test Linux platform


portaudio: fix cross compilation

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[x] riscv64-linux (cross)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

(Maybe) supersedes https://github.com/NixOS/nixpkgs/pull/175996, as the root cause is the configure script only accepts a custom ar if the absolute path is provided in $AR.

Can you set strictDeps too?


could suport the gpu?

At the moment RTNeural is not intended to be used for running inference on a GPU. For more information please see Section 2.1 of the reference paper.
I believe that some other C++ libraries may be used for running inference on a GPU, such as libtorch.


Unexpected Behavior with Jittable class

Hello,
First off, thanks for your hard work in developing this package. It's great to have a JAX-native implementation of TFP.
In working with the library, I noticed some unexpected behavior using the Jittable class. The underlying problem is that the Jittable class registers all of the instance's data under the aux_data of the Jax PyTree (as opposed to the children) Line 35. My understanding is that the aux_data is meant to store object metadata, while the actual array-like data should be stored in the children of the PyTree node (see JAX docs).
As a result of the current implementation of Jittable, a few undesirable things happen.
1) Jittable Functions Can't Be Re-used Across Objects of the Same Shape
The benefit of jitting is that compiled code can be re-used on similar inputs. However, the current implementation of Jittable does not allow this. Because data (like a model's parameters) are stored in the aux_data (metadata) field of the Jax PyTree, any changes to those parameters will trigger a re-compile since JAX thinks you're passing in a different type of object.
In fact, we don't even get that far using Jittable, since the code fails when attempting to compare the metadata (to determine if it's different --> thus needing a re-compile). Here's a quick example: I create two Bernoulli model objects with the same shaped parameters. I then create a simple jitted function (to sample from the provided model) and run it on bern_1 followed by bern_2.
import distrax  # __version__ = 0.1.2

import jax.numpy as np
import jax.random as jr
from jax import jit

bern_1 = distrax.Bernoulli(logits=np.ones((3,)))
bern_2 = distrax.Bernoulli(logits=np.zeros((3,)))

@jit
def jitted_function(model, seed):
    return model.sample(seed=seed, sample_shape=(5,))

seed = jr.PRNGKey(0)
jitted_function(bern_1, seed)  # jitted_function is compiled here

jitted_function(bern_2, seed)  # throws ValueError

The ValueError thrown by the last line:
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

2) Modifying Object Data Leads to Escaped Tracers
Another issue with registering parameter-like data in the aux_data field of a PyTree is that modifying values inside a jitted function leads to undesirable behavior.
In this minimal example, I make use of the DummyJittable object from the jittable test harness. I define a simple jitted function that adds one to the object's parameters. This function can be seen as a basic analogy for a function that increments a model's parameters in some optimization routine like SGD, e.g.
The code runs, but printing the object's parameters after the function shows that Jax Tracers have escaped the jitted function's context.
from distrax._src.utils.jittable import Jittable

class DummyJittable(Jittable):
  """
  Taken from distrax._src.utils.jittable_test
  """
  def __init__(self, params):
    self.name = 'dummy'  # Non-JAX property, cannot be traced.
    self.data = {'params': params}  # Tree property, must be traced recursively.

dummy = DummyJittable(np.zeros((5,)))

@jit
def add_one_to_params(obj):
    print("jitting...")
    obj.data["params"] = obj.data["params"] + 1
    return obj

dummy_out = add_one(dummy)
print(dummy_out.data)

>>> {'params': Traced<ShapedArray(float32[5])>with<DynamicJaxprTrace(level=0/1)>}

If we wanted to modify these parameters outside a jitted function's context, we would get an error.
dummy_out.data["params"] - 1 # throws UnexpectedTracerError

>>> UnexpectedTracerError: Encountered an unexpected tracer. A function transformed by JAX had a side effect, allowing for a reference to an intermediate value with shape (5,) and dtype float32 to escape.
JAX transformations require that functions explicitly return their outputs, and disallow saving intermediate values to global state.
The function being traced when the value leaked was add_one at /var/folders/kc/slznj52d4p57wn5mdxm530080000gn/T/ipykernel_78765/2780791423.py:1 traced for jit.

How do we fix this behavior?
Non-metadata for a Jittable object should be registered in the children field of its PyTree. This solves the two problems presented above.
Here's a super-simple example of re-writing the DummyJittable to behave as expected.

from jax.tree_util import register_pytree_node_class

@register_pytree_node_class
class AlternativeDummyJittable:
    def __init__(self, params):
        self.data = {'params': params}

    def tree_flatten(self):
        params = self.data["params"]
        return (params,), None  # (children, aux_data) <-- notice params goes in children

    @classmethod
    def tree_unflatten(cls, aux_data, children):
        params, = children
        return cls(params)

With this definition, the jitted function behaves as expected.
@jit
def add_one(obj):
    print("jitting...")
    obj.data["params"] = obj.data["params"] + 1
    return obj

alt = AlternativeDummyJittable(np.zeros((5,)))
alt_out = add_one(alt)  # function compiles here
print(alt_out.data)  # prints JAX array as opposed to tracer values

# we can re-use the compiled function on an object with different parameters / same shape!
alt_different_params = AlternativeDummyJittable(np.ones((5,)))
alt_out = add_one(alt_different_params)  # no need to re-compile
print(alt_out.data)  # prints JAX array as opposed to tracer values

Hopefully the above makes sense. I'm happy to elaborate on any points made above. Currently, the Jittable class is misleading and breaks on standard logic of a "jittable" object. Object data like parameters should be registered in the children field of a PyTree instead of the aux_data field.
Thank you!
-Collin

I got bitten by this today. LeakedTracer errors are the worst, and really hard to pin down and fix.
Actually, I feel that the flax folks got it right with flax.struct.dataclass and flax.struct.field. It is very easy to handle, since whether an attribute is part of the pytree or meta is made explicit.

Your work on this native JAX implementation for TFP is also much appreciated on my end as well! Thanks a lot.
Unfortunately, I hit the same error today, and it does keep me from going full distrax. A solution would be very helpful!

Thank you @schlagercollin for an excellent and thorough report. We believe the issue is now fixed in #168 and have incorporated elements of your report as new test cases.

Thanks @schlagercollin for your very thorough report. We've incorporated your examples as test cases and pushed a change (#177) that we believe addresses the issue.


httpd package error on unpacking

I'm getting problems with httpd in multiple branches (fedora21 as well as the centos-7 shown here), anyone else running into this, looking up into the install log it was here that it failed:
Installing : httpd-2.4.6-31.el7.centos.x86_64                         200/373Error unpacking rpm package httpd-2.4.6-31.el7.centos.x86_64

What OS and docker versions do you use on the host? If you create Dockerfile with just
FROM <the-os>
RUN yum install -y httpd

and run docker build ., does it pass?

Here's the output:
http://sprunge.us/ISNY

Here's the output:
http://sprunge.us/ISNY

So the relevant bits are:
Sending build context to Docker daemon
FATA[0000] Post http:///var/run/docker.sock/v1.18/build?cpusetcpus=&cpushares=0&dockerfile=Dockerfile&memory=0&memswap=0&rm=1&t=: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
thoth@mktulu:/tmp/test$ docker build .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM fedora:21
 ---> e26efd418c48
Step 1 : RUN yum install -y httpd
[...]
  Installing : httpd-2.4.10-15.fc21.x86_64                                  7/7Error unpacking rpm package httpd-2.4.10-15.fc21.x86_64
error: unpacking of archive failed on file /usr/sbin/suexec;55636724: cpio: cap_set_file

You seem to be hitting https://github.com/docker/docker/issues/5928 and https://github.com/docker/docker/pull/5930. Can you please talk to your distribution's docker package maintainer about why docker on that platform does seem to still drop cap_set_file?

actually I'm using the latest docker binary straight from docker.  So no package maintainer, pretty much this:
wget https://get.docker.com/builds/Linux/x86_64/docker-latest
chmod +x docker-latest
sudo mv docker-latest /usr/local/bin/docker

is how I install Docker on Debian Jessie at the moment.

I went ahead and tried this on a ubuntu trusty host (3.16.0-38-generic #52~14.04.1-Ubuntu SMP) as well, Docker was built using the angstwad ansible role, I have a packer builder here:
https://github.com/joshuacox/dacksible
that was used to build the VM
I get the same errors as I did in debian.    Maybe even BTRFS.

Thanks for the investigation. I'm closing this issue now.


Corrected typo in guide article 3 by 3 Determinants

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

@RandellDawson Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


Bug: Created GitOps Repo also containing other Cloud Provider files as well, which are not needed

Which version of kubefirst are you using?
v2.1.4
Which cloud provider?
Civo
Which installation type?
UI (Console app)
Which distributed Git provider?
GitHub
What is the issue?
Running Kubefirst UI on a local kubernetes cluster (created with 'kubefirst launch up') and setting everything up for using civo as the provider and github as the scm.
As the Kubefirst UI creates everything needed to provision the kubernetes cluster on civo, it will - of course - create the gitops repo, which will also contain the files for the gcp provider.
Since this not needed, I assume it might be a bug 😄

Code of Conduct

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

@PatrickLaabs thanks for reporting this - we actually already caught it and it will be patched in the next release.


UX Improvement suggestions for Rewards section.

Hello! i'm using this section while running testnet node, and have some suggestions how to improve it for better user experience.

Make it possible to withdraw multiple/all rewards at once
Add withdraw button next to each reward in Totals section for instant withdrawal
Make Rewards History section a bit more useful

See attached screenshot with my notes, please.
And design drafts: file1, file2
Sketch file available upon request.

Hi! Thanks for posting an issue!

Withdrawing multiple/all rewards at once is not possible currently. The smart contract allows you to withdraw a reward for a given operator in a given group, pls see here.

I think the best person who answers this question is @liz-shinn  😁

Yes, we are going to replace the date with a link to the transaction on etherscan. see #1843

Make it possible to withdraw multiple/all rewards at once

This was also brought up my @shaimo in #1846.
One staker may have multiple group members. When withdrawing a reward from a group, we need to go through all members and see how many group members that staker has so that we can calculate an applicable reward:
https://github.com/keep-network/keep-core/blob/afc5d1f7cd2792effe7f6e7f10a6ec333f52c8d3/solidity/contracts/libraries/operator/Groups.sol#L318-L322
We've been also experimenting with calculating member indices off-chain and passing them as a parameter but the gas savings were not significant, if any, from what I remember.
When doing it for just one group, the gas cost is controlled. If we were to withdraw from multiple groups, if means we need to do this iteration multiple times and in some cases, we may even run into out of gas issues.
Another factor we need to take into consideration is that we'll have more groups on testnet than on mainnet given the gas price difference and I expect rewards withdrawal will not be that problematic on mainnet.
Since this problem was brought up independently by @rakhmanovr and @shaimo and we've seen some other people mentioning it on Discord, I think it's worth experimenting.
I see a couple of options here:

we create a separate contract calling withdrawGroupMemberRewards in a loop - concerned about the cost and not sure what's the group number limit given the block gas limit
we add separate function allowing to pass group indices and member indices for them - concerned about the input format - I guess this would require some ABI-encode magic.

Having this data and comparing it to the option with withdrawing per group, we should decide on offering Withdraw All option as an alternative and what UX pattern we can employ so that the user is aware of the cost difference.

Having this data and comparing it to the option with withdrawing per group, we should decide on offering Withdraw All option as an alternative and what UX pattern we can employ so that the user is aware of the cost difference.

It reminds me of a UX pattern used in the cash app Venmo. There's an option to either withdraw immediately and pay a fee, or to withdraw over 1–2 days and pay no fee. The two options are presented to the user side-by-side, and you can select which you prefer:

To be able to do something like this for withdrawal, we would need a way to be able to estimate gas cost for Withdraw All so you could easily compare the costs.


Some problems

There are many problems during the use process, and I cannot open an interface like yours. I look forward to updating and optimizing it

Hey WinHex89, thanks for using this plugin! Yes, It's not production-ready yet but I will work on it and solve everything. You are the first one to give feedback on GitHub, so I really appreciate it! I'm curious why and how you chose to try this plugin, is there a problem that it can solve for you? I will also try to optimize the plugin to better tailor your needs if you could provide some feedback.


Feat(eos_cli_config_gen): Adding 'ip igmp host-proxy' interface support

Change Summary
Adding 'ip igmp host-proxy' interface support
Related Issue(s)
Fixes #3633  , #3566
Component(s) name
arista.avd.eos_cli_config_gen
Repository Checklist

[x] My code has been rebased from devel before I start
[x] I have read the CONTRIBUTING document.
[x] My change requires a change to the documentation and documentation have been updated accordingly.
[x] I have updated molecule CI testing accordingly. (check the box if not applicable)

@philippebureau @kornoa You have requested this feature, so I hope you can help us test this PR.
You can install with galaxy directly from the PR like this:
ansible-galaxy collection install git+https://github.com/vibhu-gslab/ansible-avd.git#/ansible_collections/arista/avd/,igmp_host_proxy --force

@ClausHolbechArista:
I've checked the adjusted molecule test in the PR. This looks good. I don't need more local testing. Relevant testing should always be included in the code. ;-)
Besides functionality: I would recommend to outsource repetitive Jinja2 code from various interface type templates. Maintenance on duplicated code is annoying.

@kornoa
Besides functionality: I would recommend to outsource repetitive Jinja2 code from various interface type templates. Maintenance on duplicated code is annoying.
Ack, but Jinja is suboptimal for this. We try to balance the ease of contributions by non-programmers vs the efficiency of the code.
We will evaluate your suggestion. Thanks.


Switches that control non-color lights should not show color or temperature wheel

Home Assistant release with the issue:
0.81.04
Last working Home Assistant release (if known):
n/a
Operating environment (Hass.io/Docker/Windows/etc.):
Docker
Component/platform:
deCONZ
Description of problem:
I import Hue lights and switches that are connected to a Conbee stick. If I click the dimming switch details in hass, they show a color wheel and a temperature slider even if the lamps connected to that switch do not support both.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
deconz:

Traceback (if applicable):
n/a
Additional information:

Zigbee groups doesn't detail what they support, this is a known behaviour.

Thanks for nothing that. Are you aware of a way to hide the controls on the UI that are not supported?

Im not sure. Maybe template light


Added ci functional test for basic workflow

[ ] I have added the tests to cover my changes.
[x] I have updated the documentation, VERSION, and CHANGELOG accordingly.
[x] I have read the CONTRIBUTING document.

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop@29ae109). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop      #31   +/-   ##
==========================================
  Coverage           ?   52.17%
==========================================
  Files              ?        2
  Lines              ?      138
  Branches           ?        0
==========================================
  Hits               ?       72
  Misses             ?       66
  Partials           ?        0

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

Codecov Report

Merging #31 (73c8e52) into develop (67c5c92) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop      #31   +/-   ##
========================================
  Coverage    52.17%   52.17%
========================================
  Files            2        2
  Lines          138      138
========================================
  Hits            72       72
  Misses          66       66

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