"S₀ = I : Chebyshev() → Ultraspherical(1)"  :UndefVarError: I not defined

In lecture16, here are several codes:
S₀ = I : Chebyshev() → Ultraspherical(1)
f = Fun(exp, Chebyshev())
g = S₀*f
g(4) - exp(4)
I found the error when I run it:
UndefVarError: I not defined
Stacktrace:
[1] top-level scope at In[84]:1
Then I search for solutions, referred in
"https://github.com/JuliaApproximation/ApproxFun.jl/issues/590#issuecomment-408527643"
it can change to code "Conversion(Chebyshev(), Ultraspherical(1))" instead, and it works.
However,  the final result such like "g(3) - exp(3)" is equal to -20.085536923187668, not approach to zero.

yes, it works, but the example seems not good?

Because you can only evaluate a function inside its domain of definition, in this case the default -1 ..1

I got it!!!


Cannot find module (scss)

Hi,
I am trying to implement this plugin on the lit typescript starter.
The issue I am having is that I am importing my scss styles on my lit element (gwds-button.ts), but getting the following error message:
Cannot find module './gwds-button.scss' or its corresponding type declarations.ts(2307)

Hi, add this to src/styles.d.ts (for other .d.ts file)
declare module '*.scss' {
  import { CSSResultGroup } from 'lit';
  const styles: CSSResultGroup;
  export default styles;
}

And add external: [/\.s?css$/], into rollup.config.js

@kraus-milan I've basically copied your comment into the README with that pull request so that it's easy for people to find; hope that's okay with you :)


ICRC-22 - Payment request formats

ICRC-22 - Payment request formats
Data Details

icrc: 22
title: ICRC-22 - Payment request formats
author: David Dal Busco - david dot dalbusco at gmail dot com - @daviddalbusco on twitter
status: Draft
category: ICRC
requires: Textual encoding of ICRC-1 accounts
created: 2023-06-23
updated: 2023-06-23

Context
A standard way of representing payment requests as URLs, which is particularly useful for generating QR codes.
Abstract
"URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format for payment requests allows for instant invocation of the user's preferred wallet application (even if it is a webapp or a swarm đapp), with the correct parameterization of the payment transaction only to be confirmed by the (authenticated) user." - source EIP-681.
References

Bitcoin:

Bitcoin Design: Unified payment requests
Unified QRs for Bitcoin

Ethereum EIP-681: URL Format for Transaction Requests

Introduction
The following is a simple adaptation of above listed references to establish a standard way of sharing URLs that represent payment requests on the Internet Computer.
Specification
Payment request URLs are constructed by incorporating the ICRC "token" in the schema (protocol) part of the URL. The format for creating such URLs is as follows:
urn           = token ":" address [ "?" params]
token         = string
address       = <principal>-<checksum>.<compressed-subaccount>
params        = param [ "&" params ]
param         = [ amountparam ]
amountparam   = "amount=" *digit [ "." *digit ]

Where token epresents the symbol of an ICRC token in lowercase, such as "icp" for the Internet Computer.
The address refers to a textual encoding representation of ICRC-1 accounts, as defined in the related standard.
The amount should be provided as a number.

Thank you @peterpeterparker.
Did you consider using the canister id instead of the symbol to identify the token/currency?

Did you consider using the canister id instead of the symbol to identify the token/currency?

No, not really @domwoe. I feel like to support ICP and others non ICRC tokens (Bitcoin, ETH) as well, using the token/currency is the best approach in term of interpolarity and simplicity. But of course, only my two cents. The proposal is here to be discussed 😉.

One thought is that unlike Bitcoin's network, as canisters' ids are a form of address themselves, then perhaps the intended recipient address is actually a "subaccount" of the canister's "address":
address: ?(canister(<principal>))~recipient(<principal>-<checksum>.<compressed-subaccount>)

(not particularly partial to ~ as the concatenator, so whichever url allowable char seems best).
Although the question of security arises as whose responsible for validating the canister id that's used (in any case). And in any case, if the canister id is present (however it might be) then it can be used to validate the payment request (as opposed to the reliability of using the token symbol to resolve the canister id).
There's a lot to consider...
For the amount, by number do you mean string representation of a number? That's the BIP convention. They also always use non-base units. I'd prefer base units were used to particularly as the decimal value is variable, but that's just me.
In any case, this article is good and has many good references: https://codecapsule.com/2022/06/01/building-payment-system-ethereum/
Can we get a standardized set of encoded QR codes (or have a generator handy) while this is being decided for the sake of usability?

Answering your question @atengberg but of course to be discussed, just giving context on the draft.

One thought is that unlike Bitcoin's network, as canisters' ids are a form of address themselves, then perhaps the intended recipient address is actually a "subaccount" of the canister's "address":

I described the address in the exact same way as it is defined in the ICRC-1 specification. See textual representation.

Although the question of security arises as whose responsible for validating the canister id that's used (in any case). And in any case, if the canister id is present (however it might be) then it can be used to validate the payment request (as opposed to the reliability of using the token symbol to resolve the canister id).

Indeed, I did not mention it. In other ICRCs, is there specific sections or limitations that address such issue or these also implies that the responsability is deferred?

For the amount, by number do you mean string representation of a number?

I meant number. 123456.789

Note: token canister ~ token ledger canister ~ ledger canister. There's no convention, but to be clear.
My comments as to the address "format" were in the context of how should the token canister itself be resolved because if the payment encoding only includes the token's name or symbol, there's no immediate connection to the actual token canister itself that's responsible for the transaction: by formatting the address with an additional, and optional, domain (that of the canister's id (principal)), then there's at least confirmation as that id can be used to ping that token ('ledger') canister's metadata to see that it matches what's given in the payment encoding.
As to the amount, EVM standards use the string convention as EVM based token contracts can have variable decimal values, as can ICRC1. The real issue is how much should the variable decimals of various token canisters/contracts be handled, if at all in the payment encoding?

I agree with @domwoe: token should be a canister ID. Otherwise, the payment request is not self-contained and requires an external token -> canisterID mapping.
Furthermore, it would be nice to handle more transaction types. For example, we probably want a way to represent icrc2_approve operations as a URI.

Is not the principal of the address the token's canister id?
The one problematic case I've found is if decoding a payment, and the token is different than the expected token (from the canister id's query method of icrc1 metadata--whether it be from the payment encoding or known a priori), should the payment be considered a problem?
Or in code
// tokenSymbol is known beforehand derived from a icrc1_token_canister_metadata call
// useCallback is a React thing, hopefully clear enough this is part of a UI form.

  const onQrCodeScanned = useCallback((result) => {
    try {
      const decoded = decodePayment(result);
      if (decoded?.token) {
        if (tokenSymbol && tokenSymbol !== decoded.token) { // HERE is the problem.
          formik.setErrors({
            ...formik.errors,
            recipientAddressInput: 'Token symbol from QR code does not match token symbol from canister metadata'
          })
        }
      }
      if (decoded?.identifier) {
        formik.setFieldValue('recipientAddressInput', decoded.identifier);
      }
      if (decoded?.amount) {
        // Literalize as decoded payment will return 'number' type (conversion to base units handled on submit).
        formik.setFieldValue('amountInput', `${decoded.amount}`);
      }
      if (!decoded) {
        throw new Error("Nullish decoded, falling back to raw qr input result");
      }
   } catch (e) { }// Note if failed, as long as the result is not trivial it's simply set as the recipientAddress input.

This is probably not that significant of a deal.
The only real other issue is that small numberish amounts can lose precision, which is why the EVM payment standards typically suggest using string to encode all amount values.

Hey, I added ICRC-22 support to IC-POS.
https://github.com/kristoferlund/ic-pos

Regarding the question of using the token symbol or canister id to identify the token, a unique id like the canister id is clearly preferable to disambiguate the situation of multiple tokens of the same name. However, @peterpeterparker mentions, he would like to have the option to also support tokens on other chains.

I feel like to support ICP and others non ICRC tokens (Bitcoin, ETH) as well, using the token/currency is the best approach in term of interpolarity and simplicity.

There is no reason why this should not be possible. Actually, the same problem applies to other chains: The smart contract address is the unique identifier for the token, not the symbol. There can be many ERC-20 tokens with the same name on an EVM chain.
Can't we use the smart contract id of the token on its respective blockchain and an additional chain identifier to solve this generically for multiple blockchains and tokens? The symbol is a convenience field that can be there as well to make it sensible to the user.
Now one question that comes up is how important it is to support other chains? There is a standard for Bitcoin and Ether on Ethereum already, but AFAIK not for ERC-20. Would it be the goal to get adoption in the Ethereum world also by allowing ERC-20 payments to be encoded?

I was certainly over-complicating the addressing format, and support for other chains in the textual representation is easily supported already as you point out.
Practically speaking, imho support for bitcoin and its direct derivatives would likely be enough. Theoretically speaking, support specifically for a plurality of interfaces is more inline with the nature of decentralized networking, and is likely going to remain one of the driving forces of web3 (one area where defi has still taken off). Consider ICP could be one of the few (if not only?) secure blockchain providers for BTC<>EVM tokenization, and more realistically could even be setting that tide to come if the case for ICP<>BTC is proven.

Update as of WG discussions
ICRC-22 - URI Format for Payment Requests
Information

icrc: 22
title: ICRC-22 - Payment request formats
author: David Dal Busco - david dot dalbusco at gmail dot com - @daviddalbusco on twitter
status: Draft
category: ICRC
requires: Textual encoding of ICRC-1 accounts
created: 2023-06-23
updated: 2023-10-30

Context
A standard way of representing payment requests as URLs, which is particularly useful for generating QR codes.
Abstract
"URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format for payment requests allows for instant invocation of the user's preferred wallet application (even if it is a webapp or a swarm đapp), with the correct parameterization of the payment transaction only to be confirmed by the (authenticated) user." - source EIP-681.
References

Bitcoin:

Bitcoin Design: Unified payment requests
Unified QRs for Bitcoin

Ethereum EIP-681: URL Format for Transaction Requests

Introduction
The following is a simple adaptation of above listed references to establish a standard way of sharing URLs that represent payment requests on the Internet Computer.
Specification
Payment request URLs are constructed by incorporating the ICRC "token" in the schema (protocol) part of the URL. The format for creating such URLs is as follows:
request = network_identifier ":" contract_address "/" transaction
network_identifier = icp:mainnet // network id
contract_address = // canister address to which to make the call
transaction = // method on the canister to call
urn           = token ":" address [ "?" params]
token         = string
address       = <principal>-<checksum>.<compressed-subaccount>
params        = param [ "&" params ]
param         = [ amountparam ]
amountparam   = "amount=" *digit [ "." *digit ]

Where token epresents the symbol of an ICRC token in lowercase, such as "icp" for the Internet Computer.
The address refers to a textual encoding representation of ICRC-1 accounts, as defined in the related standard.
The amount should be provided as a number. The amount represents the amount of tokens in the base unit used by the ledger. It is strongly recommended to use scientific notation for the amount. Decimal representation can be combined with scientific representation, e.g., 4.042E8 ICP means a count of 404200000 base units as managed by the ICP ledger.
Example
icp:mainnet:<token_contract_address>/tx=icrc1_transfer&from_subaccount=&to=&amount=4.042E8&fee=&memo=&created_at_time=

We wanted to know the exact maximum length of our ICRC-1 textual encodings and wanted to know whether removing the dashes between the digit groups of the principal part of the representation would be sufficient for getting the textual representation of the account below the 128-byte limit imposed by the CAIP standard.
Let’s have a look at this:
The ICRC-1 textual representation is composed from the following components:
principal “-“ checksum “.” subaccount where juxtaposition means concatenation.
The maximum lengths of the individual components are: 63 1 7 1 64
Thus, the maximum overall length of an ICRC-1 textual encoding is 136, which is 8 characters too long.
The maximum-length principal contains 10 dashes. Removing either all but the one separating the principal from the checksum or all dashes both brings us again below the limit of 128 characters.
Thus, it would work to adopt this tweaked textual representation of the ICRC-1 textual encoding for representing an account as a query parameter and being CAIP compliant. It’s likely the simplest adaptation of the ICRC-1 textual representation we can do to get below the limit.
References:

Textual encoding
IC Interface Spec

Applications can register themselves as handlers for certain protocols. So an application might register itself as handling the icp protocol and then if you click on a icp: link, it will open that application to handle the URI.
So if we expect ICP wallets to handle most/all tokens on the IC, it makes sense to have a single protocol rather than a protocol per token where a wallet would need to register as a handler for every possible token on the IC.
But I've never seen URIs with multiple parts separated by multiple colons. Is this still a valid URI? Might it break protocol handlers as I described above? Why not put network/contract address/etc. in the params?

The current working draft is available here:
https://github.com/dfinity/ICRC/pull/101


Support code focus mode

Today, if someone wants to focus only on the code, the only option is to export the notebook source to elixir. We should provide a code focus mode, that hides all markdown cells, perhaps comments, and other non essential functionality for somebody to work, change, and refactor the code directly.

We could also have a toggle for showing outputs or not (enabled by default).


Export: Sanitize output

Remove tagged content without tags.
Remove inexsisting tagged content.

https://phabricator.endlessm.com/T34519

Yeah, this seems reasonable! :+1:


Redeploy

@hjwp - I'm thinking that Python Anywhere might do the trick :dancers:
Currently there is a Procfile and uwsgi.ini that are required for Heroku deployment - if we choose to move away from Heroku, these should (??) be able to be removed.
I'd also like to formally document the deployment process in a new deployment.rst

Depending on the platform, it would also be nice to write some deployment scripts to automate this process.


Repository transfer and reorganization

This issue is an announcement for some upcoming repository changes. They are intended to pave a way for cleaner structure, but they don't change the essence of Luau - Luau continues to be an open-source project which forms a foundation of programming inside Roblox; a team at Roblox is continuously working on making it awesome; it is distributed under the same (MIT) license, will have the same update cadence as before, etc. In short, nothing aside from the GitHub specific repository structure is changing.
Repository transfer
The repository will move into luau-lang org (https://github.com/luau-lang), the name of the repository will stay (luau). This will be done using GitHub repository transfer function; as a result, all existing forks/checkouts should continue to work. All existing issues/PRs should be in tact.
This move will happen on Monday, October 23.
After transfer, git pull for existing checkouts will display warnings with the note that the remote has changed, and recommend adjusting the remote URL. You will need to run something like this to fix the warning (assuming you used SSH checkout):
git remote set-url origin git@github.com:luau-lang/luau

Splitting docs folder into a separate repository
docs folder currently hosts the web site that deploys to https://luau-lang.org/. This folder will be moved to a separate repository in luau-lang organization, called site. The folder will be deleted from this repository with a regular commit; unless you have a PR for docs folder specifically, you should not be affected.
The documentation-only issues will be moved to the new repository. If any unmerged PRs for the site remain, we will close them and expect the author to reopen them against the new repository.
We expect this move to happen the week of October 23-27 and not require any action unless new PRs to docs get opened this week.
Splitting rfcs folder into a separate repository
rfcs folder currently hosts the language proposals. This folder will be moved to a separate repository in luau-lang organization, called rfcs. The folder will be deleted from this repository with a regular commit; unless you have a PR for rfcs folder specifically, you should not be affected.
PRs can not be transferred from a repository to another repository, so they will need to be closed and manually reopened after a transplant vs the new repository. Since RFCs are single-file, we anticipate that it should be easy to fork the new repository and resubmit the changes, linking to the prior discussion if needed. We will not do this ourselves - we will merely close all pending RFCs. We also do not anticipate or recommend blindly re-opening every RFC PR, as most existing PRs have feedback on them that blocks further discussion or approval. We might close some PRs ahead of the move to make the distinction more clear.
Because this is more disruptive as we have a fair amount of RFC PRs opened, we will do this on October 30th.

papers folder was moved to https://github.com/luau-lang/research and was deleted from this repository
docs folder was moved to https://github.com/luau-lang/site; it will be deleted from this repository tomorrow
The actual repository migration is pending some technical issues with the transfer. This issue will continue to be updated until the migration is fully complete.

The repository migration is complete; the repository is now available via https://github.com/luau-lang/luau. The old URL (https://github.com/Roblox/luau) should still work but updating it is recommended.
The docs folder was deleted from this repository.

The last remaining part of the migration is the RFC move which will happen in the next week or so.

RFCs have been transferred to a new repository, https://github.com/luau-lang/rfcs (which is now also hosted on https://rfcs.luau-lang.org). The rfcs folder will be deleted from this repository later today. All existing RFC PRs opened on this repository will be closed; per explanation above, we can not and will not migrate them ourselves - they will need to be reopened by the RFC author.
Please note that while it should be easy to reopen an RFC by submitting a new PR against the new repository (if you do so, please link to the previous PR here that was closed if it has any relevant discussion), we do not actually recommend doing that blindly; a lot of RFCs opened here require substantial work on the design for them to be able to be considered.
I will try to briefly summarize possible future steps on each PR, although please note that since there are a lot of them, my notes will be brief and off the cuff out of necessity, and may not fully represent the scope of work required (and may not be accurate either!). So treat these as an attempt to help think about improving the RFC before resubmitting it instead of specific instructions.

All open RFCs have been closed with associated notes where applicable; the rfcs folder was deleted. https://github.com/luau-lang/rfcs repository should be used for monitoring or working on RFCs in the future.
This concludes the repository migration and reorganization. Thanks everyone for the patience :)


Production environment

Hello, I´m trying to deploy a rendr.js app on IIS with iisnode. Iisnode is working fine with another, non rendr.js app, but I can´t get the rendr app to work. The error message I get from iisnode is unfortunately very general (Internal Server Error) without details.
Has anyone managed to do this? I would appreciate any input on what steps needs to be done e.g. changes in index.js or similar, when moving the rendr.js app to production environment.
Thanks!!
Andreas

Sorry Andreas, I do know that I tried about a year ago to see if I could deploy onto IIS, but after about an hour or so, I gave up and just pushed to Heroku.

Thank you crwang, I´ll go ahead and try that as well.

Heroku worked as a charm, I´m very impressed. Thanks for the tip @crwang

:+1:


Changed disk size

Planning to use here:
https://cloud.google.com/compute/docs/disks/regional-persistent-disk#resize_repd

@betsy-lichtenberg
Thanks for the PR! 🚀✅ Lint checks have passed.

@betsy-lichtenberg
Thanks for the PR! 🚀✅ Lint checks have passed.


Update readme with Natives in Tech links

Hi @arecvlohe!
Thank you for this awesome contribution! :sparkling_heart: Before merging the pull request, don’t you want to add yourself to the contributor's list? Feel free to add yourself to the contributor's list (in alphabetical order by surname) in a new commit on this PR. Use the following format: Your Name.
Greetings! :hugs:

Thanks! I will do it this evening.

@dreamingechoes Done


'cmd--': As default for 'window:decrease-font-size' on MacOs

Description of the Change
The keybinding 'cmd--' appears  instead of  'cmd-_' on  'View' drop down

Alternate Designs
none.
Why Should This Be In Core?
Fix issue https://github.com/atom/atom/issues/16024
Benefits
'cmd--' is more used and more pratical too.
Possible Drawbacks
none
Applicable Issues
https://github.com/atom/atom/issues/16024

Nice. This technically makes it inconsistent (regarding pressing shift or not) with the displayed =/+ shortcut, but seeing as both _ and - do the same thing it shouldn't be a problem.
More to the point, who designed the keyboard to have -= and _+ be pairs, but not -+? 😄


Support Django 2.2+, drop Python 2.7, support more Python versions

CC @lucaswiman
Upgrade django-predicate to support more modern versions of Python and Django, drop old versions and shims.
Background
Hi, @lucaswiman!  I hope you're well!  Yes, I'm still with Myriad.  We miss you!Mind taking a look at this PR and cutting a new version that supports Django 2.2+?  Thanks.
What Changed

Converted from Nose to Pytest.
Removed Python version if/else blocks referencing old Python or Django versions.
Removed six and all references/uses to this library: since Python 2.7 has been removed (see below), six is by definition no longer required.
Reworked a lot of code around the removal of iteritems to be replaced with regular items iteration.
Reworked the tox.ini environments to support all valid combinations of Python and Django versions according to their respective release status pages.
Rewrote Tox targets clean and report/stats to equal the default recommended versions for Pytest, since we're now using pytest-coverage to calculate coverage.

Outstanding Issues

I see that there's a .travis.yml file in this repo: how do I get those tests to run?
I had to stop at Django 4.1 because of errors in 4.2, which I believe might be due to the DeMorgan's Law work-arounds needed in prior versions.  I believe the rewrites in "negated expressions" might have changed enough of the Q internals to change (or maybe even fix!) how negation works in QuerySets: https://code.djangoproject.com/ticket/16211.  If you'd like to take a crack at fixing that in this PR, I'm willing to wait, but perhaps we should try supporting 4.2+ in another PR?

How tested
The entire test suite passes for me locally (and I've confirmed Tox isn't doing that thing where it silently installs only the versions in requirements.txt instead of the versions requested in tox.ini).  I've written up the steps to run these tests in the README:
[...]
report create: /Users/hunter/git/django-predicate/.tox/report
report installdeps: coverage
report installed: coverage==7.4.1
report run-test-pre: PYTHONHASHSEED='1443967536'
report run-test: commands[0] | coverage report
Name                        Stmts   Miss Branch BrPart  Cover
-------------------------------------------------------------
predicate/__init__.py           4      0      0      0   100%
predicate/debug.py             59      7      2      0    89%
predicate/lookup_utils.py      97      0     38      1    99%
predicate/predicate.py        304     17    135      6    94%
-------------------------------------------------------------
TOTAL                         464     24    175      7    95%
report run-test: commands[1] | coverage html
Wrote HTML report to htmlcov/index.html
______________________________________________________________________________________________________________________ summary ______________________________________________________________________________________________________________________
  lint: commands succeeded
  clean: commands succeeded
  py36-1.11-postgres: commands succeeded
  py36-1.11-sqlite: commands succeeded
  py36-2.2-postgres: commands succeeded
  py36-2.2-sqlite: commands succeeded
  py36-3.2-postgres: commands succeeded
  py36-3.2-sqlite: commands succeeded
  py37-1.11-postgres: commands succeeded
  py37-1.11-sqlite: commands succeeded
  py37-2.2-postgres: commands succeeded
  py37-2.2-sqlite: commands succeeded
  py37-3.2-postgres: commands succeeded
  py37-3.2-sqlite: commands succeeded
  py310-3.2-postgres: commands succeeded
  py310-3.2-sqlite: commands succeeded
  py310-4.1-postgres: commands succeeded
  py310-4.1-sqlite: commands succeeded
  report: commands succeeded
  congratulations :)

Okay, I bumped the package version and added a changelog.  I tried to get GHA test running to work, but failed, mostly on account of lack of Python 3.6 support in GHA.  Thanks for your time, @lucaswiman!

Nice thanks @lucaswiman!


Installation issue.

Getting this error when using install.sh
`Successfully installed absl-py-2.1.0 aiofiles-23.2.1 altair-5.3.0 annotated-types-0.7.0 anyio-4.4.0 astunparse-1.6.3 attrs-23.2.0 click-7.1.2 colorama-0.4.6 contourpy-1.2.1 ctranslate2-3.9.0 cycler-0.12.1 dill-0.3.8 docopt-0.6.2 exceptiongroup-1.2.1 fastapi-0.110.3 ffmpy-0.3.2 flatbuffers-24.3.25 fonttools-4.53.0 future-1.0.0 gast-0.6.0 google-pasta-0.2.0 gradio-4.26.0 gradio-client-0.15.1 grpcio-1.64.1 h11-0.14.0 h5py-3.11.0 httpcore-1.0.5 httpx-0.27.0 huggingface-hub-0.23.4 importlib-resources-6.4.0 joblib-1.4.2 jsonschema-4.22.0 jsonschema-specifications-2023.12.1 keras-3.4.1 kiwisolver-1.4.5 libclang-18.1.1 lxml-5.2.2 markdown-3.6 markdown-it-py-3.0.0 matplotlib-3.9.0 mdurl-0.1.2 ml-dtypes-0.3.2 mock-5.1.0 mosestokenizer-1.2.1 namex-0.0.8 nltk-3.8.1 numpy-1.26.4 openfile-0.0.7 opt-einsum-3.3.0 optree-0.11.0 orjson-3.10.6 pillow-10.4.0 portalocker-2.10.0 promise-2.3 protobuf-3.20.3 pydantic-2.8.2 pydantic-core-2.20.1 pydub-0.25.1 pyparsing-3.1.2 python-multipart-0.0.9 pyyaml-6.0.1 referencing-0.35.1 regex-2024.5.15 rich-13.7.1 rpds-py-0.18.1 ruff-0.5.0 sacrebleu-2.3.1 sacremoses-0.1.1 semantic-version-2.10.0 shellingham-1.5.4 sniffio-1.3.1 starlette-0.37.2 tabulate-0.9.0 tensorboard-2.16.2 tensorboard-data-server-0.7.2 tensorflow-2.16.2 tensorflow-addons-0.23.0 tensorflow-datasets-3.2.1 tensorflow-io-gcs-filesystem-0.37.1 tensorflow-metadata-1.15.0 termcolor-2.4.0 tf2crf-0.1.33 tokenizers-0.13.3 tomlkit-0.12.0 toolwrapper-2.1.0 toolz-0.12.1 tqdm-4.66.4 transformers-4.28.1 typeguard-2.13.3 typer-0.10.0 uctools-1.3.0 urduhack-1.1.1 uvicorn-0.30.1 websockets-11.0.3 werkzeug-3.0.3 wrapt-1.16.0
2024-07-04 06:04:54.259356: I external/local_tsl/tsl/cuda/cudart_stub.cc:32] Could not find cuda drivers on your machine, GPU will not be used.
2024-07-04 06:04:54.261982: I external/local_tsl/tsl/cuda/cudart_stub.cc:32] Could not find cuda drivers on your machine, GPU will not be used.
2024-07-04 06:04:54.272369: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:479] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-07-04 06:04:54.293163: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:10575] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-07-04 06:04:54.293203: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1442] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-07-04 06:04:54.305759: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-07-04 06:04:54.937893: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/tensorflow_addons/utils/tfa_eol_msg.py:23: UserWarning:
TensorFlow Addons (TFA) has ended development and introduction of new features.
TFA has entered a minimal maintenance and release mode until a planned end of life in May 2024.
Please modify downstream libraries to take dependencies from other repositories in our TensorFlow community (e.g. Keras, Keras-CV, and Keras-NLP).
For more information see: https://github.com/tensorflow/addons/issues/2807
warnings.warn(
/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/tensorflow_addons/utils/ensure_tf_install.py:53: UserWarning: Tensorflow Addons supports using Python ops for all Tensorflow versions above or equal to 2.13.0 and strictly below 2.16.0 (nightly versions are not supported).
The versions of TensorFlow you are currently using is 2.16.2 and is not supported.
Some things might work, some things might not.
If you were to encounter a bug, do not file an issue.
If you want to make sure you're using a tested and supported configuration, either change the TensorFlow version or the TensorFlow Addons's version.
You can find the compatibility matrix in TensorFlow Addon's readme:
https://github.com/tensorflow/addons
warnings.warn(
Traceback (most recent call last):
File "", line 1, in
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/urduhack/init.py", line 6, in
from .pipeline import Pipeline
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/urduhack/pipeline/init.py", line 4, in
from .core import Pipeline
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/urduhack/pipeline/core.py", line 7, in
from .parsers.ner import NerParser
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/urduhack/pipeline/parsers/ner.py", line 4, in
from urduhack.models.ner import predict_ner
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/urduhack/models/ner/init.py", line 4, in
from .predict import predict_ner
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/urduhack/models/ner/predict.py", line 11, in
from urduhack.models.ner.model import _bi_lstm_crf_model
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/urduhack/models/ner/model.py", line 5, in
from tf2crf import CRF
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/tf2crf/init.py", line 2, in
from .crf import CRF
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/tf2crf/crf.py", line 2, in
import tensorflow_addons as tfa
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/tensorflow_addons/init.py", line 23, in
from tensorflow_addons import activations
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/tensorflow_addons/activations/init.py", line 17, in
from tensorflow_addons.activations.gelu import gelu
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/tensorflow_addons/activations/gelu.py", line 19, in
from tensorflow_addons.utils.types import TensorLike
File "/home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages/tensorflow_addons/utils/types.py", line 29, in
from keras.src.engine import keras_tensor
ModuleNotFoundError: No module named 'keras.src.engine'
[nltk_data] Downloading package punkt to
[nltk_data]     /home/sandeep.pandey/nltk_data...
[nltk_data]   Package punkt is already up-to-date!
Collecting sentencepiece
Using cached sentencepiece-0.2.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (7.7 kB)
Using cached sentencepiece-0.2.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.3 MB)
Installing collected packages: sentencepiece
Successfully installed sentencepiece-0.2.0
fatal: destination path 'fairseq' already exists and is not an empty directory.
Processing /home/sandeep.pandey/local_setup/new/IndicEmbeddings/llm2vec_modified/translation/new/IndicTrans2/fairseq
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Collecting cffi (from fairseq==0.12.2)
Using cached cffi-1.16.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (1.5 kB)
Collecting cython (from fairseq==0.12.2)
Using cached Cython-3.0.10-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (3.2 kB)
Collecting hydra-core<1.1,>=1.0.7 (from fairseq==0.12.2)
Using cached hydra_core-1.0.7-py3-none-any.whl.metadata (3.7 kB)
Collecting omegaconf<2.1 (from fairseq==0.12.2)
Using cached omegaconf-2.0.6-py3-none-any.whl.metadata (3.0 kB)
WARNING: Ignoring version 2.0.6 of omegaconf since it has invalid metadata:
Requested omegaconf<2.1 from https://files.pythonhosted.org/packages/d0/eb/9d63ce09dd8aa85767c65668d5414958ea29648a0eec80a4a7d311ec2684/omegaconf-2.0.6-py3-none-any.whl (from fairseq==0.12.2) has invalid metadata: .* suffix can only be used with == or != operators
PyYAML (>=5.1.)
~~~~~~^
Please use pip<24.1 if you need to use this version.
Using cached omegaconf-2.0.5-py3-none-any.whl.metadata (3.0 kB)
WARNING: Ignoring version 2.0.5 of omegaconf since it has invalid metadata:
Requested omegaconf<2.1 from https://files.pythonhosted.org/packages/e5/f6/043b6d255dd6fbf2025110cea35b87f4c5100a181681d8eab496269f0d5b/omegaconf-2.0.5-py3-none-any.whl (from fairseq==0.12.2) has invalid metadata: . suffix can only be used with == or != operators
PyYAML (>=5.1.)
~~~~~~^
Please use pip<24.1 if you need to use this version.
Using cached omegaconf-2.0.4-py3-none-any.whl.metadata (3.0 kB)
WARNING: Ignoring version 2.0.4 of omegaconf since it has invalid metadata:
Requested omegaconf<2.1 from https://files.pythonhosted.org/packages/92/b1/4f3023143436f12c98bab53f0b3db617bd18a7d223627d5030e13a7b4fc2/omegaconf-2.0.4-py3-none-any.whl (from fairseq==0.12.2) has invalid metadata: . suffix can only be used with == or != operators
PyYAML (>=5.1.)
~~~~~~^
Please use pip<24.1 if you need to use this version.
Using cached omegaconf-2.0.3-py3-none-any.whl.metadata (3.0 kB)
WARNING: Ignoring version 2.0.3 of omegaconf since it has invalid metadata:
Requested omegaconf<2.1 from https://files.pythonhosted.org/packages/29/08/a88210c2c1aa0a3f65f05d8a6c98939ccb84b6fb982aa6567dec4e6773f9/omegaconf-2.0.3-py3-none-any.whl (from fairseq==0.12.2) has invalid metadata: . suffix can only be used with == or != operators
PyYAML (>=5.1.)
~~~~~~^
Please use pip<24.1 if you need to use this version.
Using cached omegaconf-2.0.2-py3-none-any.whl.metadata (3.0 kB)
WARNING: Ignoring version 2.0.2 of omegaconf since it has invalid metadata:
Requested omegaconf<2.1 from https://files.pythonhosted.org/packages/72/fe/f8d162aa059fb4f327fd75144dd69aa7e8acbb6d8d37013e4638c8490e0b/omegaconf-2.0.2-py3-none-any.whl (from fairseq==0.12.2) has invalid metadata: . suffix can only be used with == or != operators
PyYAML (>=5.1.)
~~~~~~^
Please use pip<24.1 if you need to use this version.
Using cached omegaconf-2.0.1-py3-none-any.whl.metadata (3.0 kB)
WARNING: Ignoring version 2.0.1 of omegaconf since it has invalid metadata:
Requested omegaconf<2.1 from https://files.pythonhosted.org/packages/86/ec/605805e60abdb025b06664d107335031bb8ebdc52e0a90bdbad6a7130279/omegaconf-2.0.1-py3-none-any.whl (from fairseq==0.12.2) has invalid metadata: . suffix can only be used with == or != operators
PyYAML (>=5.1.)
~~~~~~^
Please use pip<24.1 if you need to use this version.
Using cached omegaconf-2.0.0-py3-none-any.whl.metadata (3.5 kB)
Requirement already satisfied: numpy>=1.21.3 in /home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages (from fairseq==0.12.2) (1.26.4)
Requirement already satisfied: regex in /home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages (from fairseq==0.12.2) (2024.5.15)
Requirement already satisfied: sacrebleu>=1.4.12 in /home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages (from fairseq==0.12.2) (2.3.1)
Requirement already satisfied: torch>=1.13 in /home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages (from fairseq==0.12.2) (2.3.1+cu118)
Requirement already satisfied: tqdm in /home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages (from fairseq==0.12.2) (4.66.4)
Collecting bitarray (from fairseq==0.12.2)
Using cached bitarray-2.9.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (34 kB)
Collecting torchaudio>=0.8.0 (from fairseq==0.12.2)
Using cached torchaudio-2.3.1-cp39-cp39-manylinux1_x86_64.whl.metadata (6.4 kB)
Collecting scikit-learn (from fairseq==0.12.2)
Using cached scikit_learn-1.5.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (12 kB)
Requirement already satisfied: packaging in /home/sandeep.pandey/miniconda3/envs/itv2/lib/python3.9/site-packages (from fairseq==0.12.2) (24.1)
Collecting omegaconf<2.1 (from fairseq==0.12.2)
Using cached omegaconf-2.0.6-py3-none-any.whl.metadata (3.0 kB)
WARNING: Ignoring version 2.0.6 of omegaconf since it has invalid metadata:
Requested omegaconf<2.1 from https://files.pythonhosted.org/packages/d0/eb/9d63ce09dd8aa85767c65668d5414958ea29648a0eec80a4a7d311ec2684/omegaconf-2.0.6-py3-none-any.whl (from fairseq==0.12.2) has invalid metadata: . suffix can only be used with == or != operators
PyYAML (>=5.1.)
~~~~~~^
Please use pip<24.1 if you need to use this version.
Using cached omegaconf-2.0.5-py3-none-any.whl.metadata (3.0 kB)
WARNING: Ignoring version 2.0.5 of omegaconf since it has invalid metadata:
Requested omegaconf<2.1 from https://files.pythonhosted.org/packages/e5/f6/043b6d255dd6fbf2025110cea35b87f4c5100a181681d8eab496269f0d5b/omegaconf-2.0.5-py3-none-any.whl (from fairseq==0.12.2) has invalid metadata: . suffix can only be used with == or != operators
PyYAML (>=5.1.*)
~~~~~~^
Please use pip<24.1 if you need to use this version.
INFO: pip is looking at multiple versions of hydra-core to determine which version is compatible with other requirements. This could take a while.
ERROR: Cannot install fairseq and fairseq==0.12.2 because these package versions have conflicting dependencies.
The conflict is caused by:
fairseq 0.12.2 depends on omegaconf<2.1
hydra-core 1.0.7 depends on omegaconf<2.1 and >=2.0.5
To fix this you could try to:

loosen the range of package versions you've specified
remove package versions to allow pip to attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
Setup completed!`

Pin the pip version to 24.0 and try. You can change below line to python3 -m pip install --upgrade pip==24.0 https://github.com/AI4Bharat/IndicTrans2/blob/f897168d81b362c59207dc1fa2cf2c77041230b7/install.sh#L15


[N64 Bug] Laptop Gun continues firing while paused and depletes all its ammo

https://github.com/fgsfdsfgs/perfect_dark/assets/66316465/d2d39e29-a052-4c46-8985-8e472cbad172

thats hilarious tbh

@JacksBestGaming I thought THE SAME DAMN THING LOL!


Fix issue 22234 - __traits(getLinkage) returns wrong value for extern(System) functions

Looking at the test cases that came with the implementation (https://github.com/dlang/dmd/pull/6822), it looks like intentional behavior that __traits(getLinkage) gives the actual linkage of extern(System) instead of "System". It also sounds more useful to me this way and avoids code breakage, hence the spec PR instead of dmd PR.

I don't remember what I was doing when making the bug report, but I know it bit me somewhat hard - hard enough to check the spec and open the bug report anyway.

Was it important for your code that __traits(getLinkage) returned "System" instead of "Windows" or "C"?

Again, I don't remember exactly what I was doing then, but it was broken enough to spend the time debugging it, comparing against the spec, and filing the bug report. So it obviously was important.
One case where this would make a difference is using built-in reflection to generate a binding file ahead of time. Saying "C" when it is actually "System" means you now get crashes on Windows.
And that reminds me, the linkage is also wrong in the dmd json output, which is sometimes used to generate bindings - the old dtoh program worked that way.
[
 {
  "kind" : "module",
  "file" : "system.d",
  "members" : [
   {
    "name" : "foo",
    "kind" : "function",
    "protection" : "public",
    "line" : 1,
    "char" : 21,
    "linkage" : "c",
    "deco" : "UZv",
    "originalType" : "extern (System) void()",

At least the "originalType" can be tested as a string, but the "linkage" field doesn't show it.
The dmd -H also gets it wrong, meaning if you use the header generation feature and commit the file it makes, you get random crashes.
dmd -HC also gets it wrong. Again, keep that file and you're in trouble.
The root problem here is the same for all of them.

The root problem here is the same for all of them.

Yes, extern(System) is resolved in the constructor of LinkDeclaration, so dmd loses the LINK.system information very early on. Do you think we can break the existing behavior of __traits(getLinkage), or would you want to see __traits(getLinkage2) or an extra parameter / return value or something?

On Mon, Jan 24, 2022 at 05:52:09AM -0800, Dennis wrote:

Do you think we can break the existing behavior of __traits(getLinkage)

The existing behavior is already broken, not in line with the spec and
giving incorrect results.
It should obviously just be fixed.

The existing behavior is already broken, not in line with the spec and giving incorrect results. It should obviously just be fixed.

I'm not sure it's obvious, extern(System) is pretty rare. I know it's useful for providing one OpenGL header for both Windows and Linux, but I think headers are usually either consistent or system-specific, not differing in ABI only.
I also don't have a good idea what __traits(getLinkage) is actually used for. If you care about twiddling with parameters in assembly, then it would be useful to get a concrete ABI ('Windows', 'C') instead of a variable one ('System'). In Druntime I see it's used to distinguish extern(C++) classes with regular D ones. Also there's this:
private template hasPlainMangling(FT) if (is(FT == function))
{
    enum lnk = __traits(getLinkage, FT);
    // C || Windows
    enum hasPlainMangling = lnk == "C" || lnk == "Windows";
}

This will break.
I'm not familiar with your use case of  'using built-in reflection to generate a binding file ahead of time', so I'd appreciate an example of that.

On Mon, Jan 24, 2022 at 06:27:23AM -0800, Dennis wrote:

I'm not sure it's obvious, extern(System) is pretty rare. I know it's useful for providing one OpenGL header for both Windows and Linux, but I think headers are usually either consistent or system-specific, not differing in ABI only.

In my arsd repo alone, I have bindings to four fairly major things that
use extern(System): OpenGL, MySQL, Chromium Embedded Framework, and Java Native Interface.
The current behavior crashes if you generate any files with it.
The correct behavior would:

if used on extern(System) in a case where it matters, it fixes a bug
you might not have realized you had.

if used in a case where the specific thing is needed, you get a
compile error and now know where the bug was and can fix it.

Either way, fixing the bug leads to bugs getting fixed, and ignoring the
bug leads to bugs staying in the wild.

I also don't have a good idea what __traits(getLinkage) is actually used for. If you care about twiddling with parameters in assembly, then it would be useful to get a concrete ABI ('Windows', 'C') instead of a variable one ('System').

You can easily do version(Windows) enum systemLinkage = "Windows"; else enum systemLinkage = "C"; and just if(linkage == "System") return
systemLinkage;
It is easy to go from detailed information down to simpler information.
But once you discard it, it cannot be recovered.

In Druntime I see it's used to distinguish extern(C++) classes with regular D ones. Also there's this:
private template hasPlainMangling(FT) if (is(FT == function))
{
    enum lnk = __traits(getLinkage, FT);
    // C || Windows
    enum hasPlainMangling = lnk == "C" || lnk == "Windows";
}

This will break.

That is ALREADY BROKEN per the language spec. The druntime authors
should know better.
But it is also trivially easy to add `|| lnk == "System" there as well.
I'll do a PR to fix their bug.

I'm not familiar with your use case of  'using built-in reflection to generate a binding file ahead of time', so I'd appreciate an example of that.

Same idea as dmd -H and dmd -HC, but not built into the compiler.
I made this ages ago and haven't touched it since but same idea:
https://github.com/adamdruppe/dtoh
the old program uses the json output instead of reflection, but again,
same root source of data.

https://github.com/dlang/druntime/pull/3705

BTW if you are concerned about silent breakage, the solution is to still
fix the bug, but just output a note similar to a deprecation transition
message, to tell people they need to fix their code.
So getLinkage could return "System" and do a warning telling people the
code was recently fixed and they should ensure their code is also
correct.

if you are concerned about silent breakage, the solution is to still
fix the bug,

I'm not concerned for myself since I don't have any skin in this game, I'm just cautious that I'm not just flipping from one broken state to another.

I doubt it would be worth it but if you did want to add another thing,
it could be like
getBinaryLinkage (or keep this called getLinkage)
vs
getSourceLinkage
but still when the spec has said something and it is a simple little
change it doesn't seem worth it to do two traits.

and it is a simple little change it doesn't seem worth it to do two traits.

The difficult part is that it's not clear when exactly System stops being its own thing and starts becoming C/Windows.
extern(System) void fsys();
extern(C) void fc();

static assert( typeof(fsys) == typeof(fc) ); // equal on Linux?
static assert( __traits(getLinkage, fsys) == __traits(getLinkage, fc) ); // but this is not equal on Linux

pragma(msg, fsys.mangleof); // special mangle for System, or do we choose C/Windows now?


Create a tutorial example

On Qiskit docs 2.0 we would like to divide documentation in different types using the divio framework. For that, we are working on a tutorials audit to see what kind of documentation we already have. It's not been easy because no file fits 100% the framework.
Following @HuangJunye suggestion, having an example of every type of documentation could help us with the categorization.
The idea is convert one of the tutorials we already have in one that follows divio framework. It would be nice to have both to compare the old and the new in order to understand what we need for that update. If we already have an example of tutorial, please, you could just add the link :)

Thanks for creating the issue. I will work on that. Please assign me.

@agata-branczyk points me to the second tutorial for the entanglement forging prototype as one example.  (The prototypes team has been writing all its documentation with Divio/Diataxis style in mind.)

@garrison That’s great. Thanks for sharing the tutorials for prototypes. Let me take a look at them.

I created grover with sampler primitives on qiskit-ibm-runtime repo as an example for the tutorial.

PR: https://github.com/Qiskit/qiskit-ibm-runtime/pull/236
Page: https://qiskit.org/documentation/partners/qiskit_ibm_runtime/tutorials/grover_with_sampler.html

@garrison You are very familiar with Diataxis framework. Would you like to have a look at the tutorial and give me some feedback?


Drop unnecessary get- prefix from protocol commands

All the protocol commands fetch protocol-related information, they don't modify the state. So the get- prefix is unnecessary:
  get-block-period              Block period in seconds
  get-committee                 Get current committee
  get-committee-enodes          Enodes in current committee
  get-epoch-from-block          Get the epoch of the given block
  get-epoch-period              Epoch period in blocks
  get-last-epoch-block          Block of last epoch
  get-max-committee-size        Maximum committee size
  get-minimum-base-fee          Minimum base fee
  get-operator                  Contract operator
  get-proposer                  Proposer at the given height and round
  get-reverting-amount          Get the amount of LNTN or NTN bonded when...
  get-treasury-account          Treasury account address
  get-treasury-fee              Treasury fee
  get-unbonding-period          Unbonding period in blocks
  get-validators                Get current validators
  get-version                   Contract version

See https://github.com/autonity/aut/commit/2ae01ec572fa338401095805da6bc4772d68065b


Adjust env config

This plugins configuration system is needlessly complicated, developers are free to configure environmental options before passing them to the plugin. With the current system, you are forced to set environment variables which might not be readily possible (and varies between unix/windows).
Instead by dropping this concept and accepting a single config this will simplify all scenarios

@herecydev Thanks for the suggestion. We started with something similarly simple but quickly needed to support multiple environments. This was done intentionally to try and handle additional logic for users instead of having everyone come up with their own way, while still providing a simple default.
I can see how the "simple default" is not so simple given your callout and because of some of this code - https://github.com/newrelic/gatsby-plugin-newrelic/blob/master/src/gatsby/on-render-body.js#L22-L26
I wonder if we could improve this while keeping backwards compatibility, I'm thinking something like this:

Have a better default that doesn't require you to set that env variable and uses the only (or the first?) config you have setup in configs
Make the env variable approach work better across the spectrum of environments - would love your help with any suggestions here on how to make this work in a Windows environment for example.
Better document both behaviors/approaches

What do you think @herecydev ?

I originally set out with your first point in mind (if you're interested see my first commit), it's possible to support both but introduces, in my opinion, a bespoke way of solving an already solved problem. As a well documented as a language feature, questions can be answered in many forums (stack overflow, gatsby's github, etc) and the solutions are not tailored to a specific plugin.
So I actually deeply disagree with your point here: "This was done intentionally to try and handle additional logic for users instead of having everyone come up with their own way, while still providing a simple default".
It's not a simple default in that you have to repeat for all environments or set a environment key that's not needed. It's not aligned with other gatsby plugins either; it's not an idiomatic way of solving the problem.
I'm not clear what you mean by point 2. It already does work with windows, if you follow my first commit this would improve the situation without compromising on backwards compat.

Apologies, I wasn't saying I succeeded in providing a simple default. It definitely should be augmented for that.
I do think it prudent to provide backwards compat support for what's there now, at least for a time. Is there any kind of Gatsby-ecosystem-specific way to handle deprecations of config settings?
We could support both config and configs for now, with one being marked as deprecated and give preferential treatment to config. That gives a decent path forward for existing and new. How's that feel @herecydev ?
cc: @jpvajda who might have an opinion as well.

@herecydev  This improvement seems to follow patterns we've used on our other New Relic Gatsby sites. Thanks for taking the time to submit this PR! I'll share this with my engineering team as we are the OSS maintainers for this plugin at the moment. But I'm all for this change!

I suggest we create a minor release that deprecates the configs, that would address the compatability @devfreddy. Then follow up with removing it in a major release.
If you're happy with that I can reinstate some of that logic and update the readme to indicate the change

Sounds great to me @herecydev, appreciate you spending time hashing things out and for making a contribution. 🥂

@herecydev I was just following up if you still had interest in contributing this change.

@jpvajda Definitely, sorry it's just been a busy week. I'll find some time on the weekend for the alterations

@herecydev no worries! It's opensource, so we appreciate your contributions. 💯

I think I've achieved a PR where both systems will be supported. The readme will direct the user to the more idiomatic style and the code will raise a deprecation warning if the older style is used.

when we merge we may want do a major/minor version bump.
to incorporate that on our sites will require updating our config and update relevant account in NR1 for change in reporting (create/get new applicationID in whatever account)

I am going to merge this into main, then merge the next branch into main, and kick off release of the plugin to get a new version up to date on NPM.

If you want to ship a pre release I can test that all works correctly

It works perrfectly, the latest npm tag is still set to 2.2.0 if you want to update that

@dan-kirkham I just pushed a latest release.
https://www.npmjs.com/package/gatsby-plugin-newrelic/v/2.2.2


added stable version 2.0.0 of the wiffi-wz adapter

This version of the adapter supports all products from stall.biz that support sending a datagram. This adapter was tested by me and at least one other user with a different setup. I suppose it is stable.

Sorry for doing this wrong again.

Maybe "first_published" would be a better name for the field?

no problem ...

for first_published is too late. Attribute used on many places


Add variant co-occurrence

Discussion of design for variant pairs: https://atgu.slack.com/archives/CNLMF0JLV/p1601052637005400


[vitess] Add vitess cdc connector

This is initial implementation of Vitess CDC connector.
For a fully detailed documentation of Vitess Debezium Connector , please see Documentation.

Thanks @s-gelazevicius for the great contribution, I'm not familiar with Vitess, but I'm willing to learn it.
Could you share more about the background of vitess-cdc connector? e.g. How is it used in your business/company, the data-scale etc.

he background of vitess-cdc connector? e.g. How is it used in your business/company, the data-scale etc.

Vitess is clustering solution on top of Mysql. It automatically handles sharding and has some other nice features. From client perspective same Mysql JDBC driver can be used.
Here in Vinted, databases are quite large and we used Mysql directly, but it was hard to scale, sharding required a lot of manual work. So now we are migrating to Vitess.
This connector will be used for our CDC ingestion pipeline implemented as a flink application.

Thanks for the PR @s-gelazevicius !

Hi, @s-gelazevicius

Here in Vinted, databases are quite large and we used Mysql directly, but it was hard to scale, sharding required a lot of manual work. So now we are migrating to Vitess.
This connector will be used for our CDC ingestion pipeline implemented as a flink application.

Thanks for your detailed explanation, happy to see the developer from Vinted and welcome to community, I'll help review this PR.

Hi, @leonardBang  any updates on this pull request. I have re-based it from the latest master to keep it fresh.  It's been siting here for a long time. It would be really nice to have this in upstream.

@s-gelazevicius Thanks for the great work and BIG sorry for my late response.  I'm busy on supporting the TiDB and OceanBase vendors, I'll review this PR soon after the OceanBase PR review finished.

@fsk119 thank you for review. I already addressed some of your comments, and will fix other issues during next week.

@fsk119 I have addressed all comments, could you please review the changes once more

Hey @s-gelazevicius, thanks a lot for the awesome work on this Vitess connector! As we are approaching the feature freeze of Flink CDC version 2.4.0, we are going to make some patches on your current work and merge your commits to master. We'll preserve all your changes and keep the commit under your name and email address 😄
I squashed all commits into one to keep the history of master branch clean. The CI is running in my own Azure pipeline. I'll merge the commit into master once the CI is green.
The only thing we are still missing for the new Vitess connector is the end-to-end test case. Could you add one under flink-cdc-e2e-tests in another PR when you are available? Thanks!

Hey @s-gelazevicius, thanks a lot for the awesome work on this Vitess connector! As we are approaching the feature freeze of Flink CDC version 2.4.0, we are going to make some patches on your current work and merge your commits to master. We'll preserve all your changes and keep the commit under your name and email address 😄
I squashed all commits into one to keep the history of master branch clean. The CI is running in my own Azure pipeline. I'll merge the commit into master once the CI is green.
The only thing we are still missing for the new Vitess connector is the end-to-end test case. Could you add one under flink-cdc-e2e-tests in another PR when you are available? Thanks!

Thanks @s-gelazevicius and @PatrickRen for the contribution,
Could we keep both gintarasm and s-gelazevicius 's contributions when squash the commits? and I think that we should add an e2e test for new joined connector.

Closed by commit e349cb1a836ec610a8f6beeb580f804eb4ac466c


rx: make assert fail with an informative message

If assert fails, then reason for failure is not shown, eg:
Summarizing 1 Failure:
  [FAIL] Factory Concat when Single observable [It] 🧪 should: create derived single observable
  /Users/plastikfan/dev/github/snivilised/lorax/rx/assert.go:205

Ran 1 of 61 Specs in 0.014 seconds
FAIL! -- 0 Passed | 1 Failed | 5 Pending | 55 Skipped
--- FAIL: TestRx (0.03s)

Needs to display the underlying reason for failure.

actually, this might be better addressed by another issue to be raised concerning the re-design of assert and the assertions


added getMixedDataNodeNames method for models

This adds a new method getMixedDataNodeNames for model objects.  Prior to this, we have no functionality to test for, or to retrieve node names which are partially observed: multivariate nodes, which are partially, but not entirely, data.
The core model function isDataFromGraphID was modified, to add an additional argument includeMixed.  The former behaviour of model$isDataFromGraphID exclusively returned TRUE or FALSE, giving only 2 possible options.  When the new argument includeMixed = TRUE, the return values of model$isDataFromGraphID are now 0 (not data; formerly FALSE), 1 (fully data; formerly TRUE), or 2 (partially data; formerly, this would have been TRUE as well, but that result is somewhat misleading).
This change to isDataFromGraphID is protected behind the new argument includeMixed, so no previous use of this function will be affected.
Then, a new method of the model class is added getMixedDataNodeNames.  @perrydv care was taken to do this with efficiency in mind, and the logic takes place at the level of model declarations, until individual nodes need to be inspected (for mixed data cases) - at which point inspection takes place as efficiently as possible, following the existing logic in isDataFromGraphID.
I took this design approach, rather than trying to add arguments to model$isData, or adding arguments to model$getNodeNames, or rather than adding a function such as model$isMixedData, for a few reasons.  These could be discussed, but I envision the main function of this inside the MCMC, to assess (and handle) if there are any mixedData nodes in a model, so this function was written to return those node names.  Furthermore, adding an argument to model$isData would not actually be useful, because at present any nodes which contain any data are omitted from consideration, so this approach would require applying the modified model$isData in an unnatural manner.  Furthermore, the approach used keeps this functionality fully separated from previous functionality, which felt like a good way to go.

Testing passed; this is not directly user facing, and I'm hoping to merge this in.

@danielturek is your intention that this be addressed for 1.3.0?

@paciorek No, I'm ok with waiting on this.  I'll get back to it in due course.  Thanks for checking in.


feat: EIP1559 checks

Pull Request type
EIP1559 checks in __validate__ function
Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Resolves: #742

This change is

@enitrat  checks should be good
i'm debugging the 3 tests failing with entrypoint errors

@enitrat  ready for review


The i character's kerning is off by 2 pixels

Every character is one character apart from the previous, except for the i which is 3 pixels away from the previous character.
Reproducing: Type any character into the app's text field when in 'create badge' menu then type the i
You can see the 3 pixels already in preview and it transfers like that to the badge.

Thank you for reporting this issue, @LyndisCealin. I’ve reviewed the details, and I am confident I can address and resolve the kerning issue for the i character. Could you please assign this to me? I’ll ensure it is fixed promptly and will provide updates as I work on it.
Looking forward to contributing!


Add #find_or_create_by! to many associations

Pull request for Issue #3931. This adds a find_or_create_by! method to many associations.
person.posts.find_or_create_by!(:title => 'Testing')

looking good so far, wanna also add a Changelog entry on https://github.com/mongoid/mongoid/blob/master/CHANGELOG.md . Under new features.

Coverage increased (+0.74%) to 98.56% when pulling 839ba78e123750bff65c667c36e854d0938c6492 on tombeynon:many-find-or-create-by-bang into 660868d73b3688eada8c7e61b177e58d8fcb89ca on mongoid:master.

Coverage increased (+0.74%) to 98.56% when pulling 839ba78e123750bff65c667c36e854d0938c6492 on tombeynon:many-find-or-create-by-bang into 660868d73b3688eada8c7e61b177e58d8fcb89ca on mongoid:master.

great.. thanks

Awesome, thanks Arthur


Refactor FBO class to have private GPU-side IDs

The FBO class currently has public fields such as fboId, which is an integer storing the opengl name. They should most likely be private, although this could/should be done in the context of a bigger refactoring of the FBO class.

I feel like this is a nobel change, but since you created an issue for it, I assume you don't just want to convert fboId to private and provide an accessor for it?
If you do, I'll take care of this right after my current PR.
However, if you mean making it actually hidden from the world (no accessors), then there might be a slight problem for the BindFbo StateChange, which relies on the fboId to work. (Maybe shader parameters too?)

Yes, private fields with read-only accessors would be enough. Depending on how we want to implement subscription to managers/regeneration (through FBO wrappers or right within the FBO class) you might want to use protected fields instead.

@emanuele3d I believe we can close this now?

Yup, doing it now!


how to use jwt token in swagger

Hello i'm trying out your package its great but i don't find how to put jwt token into swagger or attach to request

tanks for response :+1: but  went with other solution but I will test this on other projects. looks great.

Closing the issue, if you need anything feel free to reopen


Unclear release notes / change log

We're using the codeql-action action and try to keep it up-to-date using Dependabot. Such PRs are not merged unthinkingly, we normally check the changes (new features, bugfixes etc.) first. Unfortunately the changelog for new versions/tags of the codeql-action action is often not very helpful to find out what's actually changed, especially when it comes to the CodeQL bundle. We often see something like "Update default CodeQL bundle version to [x.y.z]", but there's no information about the changes that come with the new bundle version (e.g. if rule implementations have been added, removed or fixed etc). And trying to find this out by checking the tags and history of the github/codeql repo doesn't help much either. Am I just missing places where I should look for such information? Or is there actually improvement potential on release notes and changelogs?
(This somehow seems to be similar to #1728, but I didn't want to continue on an already closed issue.)

Thanks for the question. The changelog for the action bundle is located here: https://github.com/github/codeql-action/releases. I realize that this is not the most discoverable place to put it and we are discussing ways to make this easier to find.

Already found that, but it's still confusing. Looking at the changelogs of the language packs that are inked no that page, there're totally different version numbers and no information or cross references what language pack versions are part of what bundle versions.
Example:
Dependabot recently offered to update the codeql-action from 2.20.2 to 2.20.3. Digging in, I found that the bundle version is updated to 2.13.5 with this. Only when looking at the source changes of linked PR, I found out that it was 2.13.4 before. But also in the changes you see that the version scheme doesn't seem consistent (see priorBundleVersion). Now I can check the codeql-bundle-v2.13.5 release notes and from there to the changelogs of language packs I'm interested in, e.g. codeql/java-queries. Here I find totally different version numbers and no information which one is included in what bundle version.


Intents provided as options not recognized correctly

Removing preferences doesn't change the current IN (sometimes it doesn't work when using the provided options)
Using the provided option I want to restart for a new movie was recognized as intent inquire(actors)

Using a new terminal library might partially help with this issue. Depends on #57

@WerLaj Can you provide some examples here? I couldn't reproduce.


fixed spell errors in code example

Fixed spell errors of contrastive in the code examples

Hi @tomaarsen, did the changes.


[FLINK-30752][python] Support 'EXPLAIN PLAN_ADVICE' statement in PyFlink

What is the purpose of the change
This PR supports the EXPLAIN PLAN_ADVICE statement in PyFlink.
Brief change log
Introduce the ExplainDetail#PLAN_ADVICE conversion between Python and Java.
Verifying this change
This change added tests and can be verified as follows:

test_explain
test_sql
basic_operations
test_table_environment_api

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): No
The public API, i.e., is any changed class annotated with @Public(Evolving): No
The serializers: No
The runtime per-record code paths (performance sensitive): No
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: No
The S3 file system connector: No

Documentation

Does this pull request introduces a new feature? Yes
If yes, how is the feature documented? FLINK-30673

@flinkbot run azure

@flinkbot run azure


Do not show charts at the end, close charts after being used

Fixes https://github.com/ewasm/benchmarking/issues/154
Also, closes all charts after being used in order to not retain in memory, avoiding the warning message RuntimeWarning: More than 20 figures have been opened. Figures created through the pyplot interface (matplotlib.pyplot.figure) are retained until explicitly closed and may consume too much memory. (To control this warning, see the rcParam figure.max_open_warning).

@jwasinger I created a Dockerfile to generate the charts in a docker instance, but it is generating the exact same files (no diff), I'll take a closer look at the CI and maybe try to use the same versions of the tools (OS, python, jupyter,etc).


spring-cloud-starter-alibaba-nacos-discovery 2<IP_ADDRESS> It seems that Ribon has been abandoned. How to achieve load balancing of weights?

Component:  nacos
question:
spring-cloud-starter-alibaba-nacos-discovery 2<IP_ADDRESS> It seems that Ribon has been abandoned. How to achieve load balancing of weights? I have tried to modify the weights on the web side of the nacos or in the service configuration file. It seems that they do not take effect. Polling is used by default. How can I make the load balancing of weights take effect?
问题:
spring-cloud-starter-alibaba-nacos-discovery 2<IP_ADDRESS> 它似乎放弃了ribbon,如何做到权重的负载均衡? 我尝试过修改nacos网页端或者是服务配置文件中的权重,似乎都没有生效,都是默认使用轮询的方式.请问如何让权重的负载均衡生效?

In addition, I see that you can customize a load balancer? So does the load balancing of the weights provided by the previous ribbon need to be implemented in the new version?
另外我看到,可以自定义一种负载均衡?所以所之前的ribbon那种提供的权重的负载均衡在新版本中需要自己去实现吗?

NacosLoadBalancer is an alternative implementation of NacosRule.

Collaborator
不好意思,这么久才回复你.
我是一个初学者,我不是很明白你说的意思. 比较想知道,旧版中是用ribbon做负载均衡的nacos利用下面的配置,以及在nacos的UI中调整对应应用的权重,即可实现权重的负载均衡. 那么我想知道,spring-cloud-starter-alibaba-nacos-discovery 2<IP_ADDRESS>要是用什么方法可以实现同样的效果呢
I'm sorry to reply to you so late
I'm a beginner. I don't quite understand what you mean. I want to know that in the old version, using the following configuration and adjusting the weight of the corresponding application in the UI of NACOS, that can mplement weight load balancing. Then I want to know how spring cloud starter alibaba nacos discovery 2<IP_ADDRESS> can achieve the same effect

`#xxxService:
ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule`
我在新版本中先引入了这个spring-cloud-starter-loadbalancer,然后再nacos的ui中调整权重,比如0.1和1,或者1和10,都无法实现权重,都是默认轮询.
In the new version, I first introduced the loadbalancer, and then adjusted the weights in the ui of nacos, such as 0.1 and 1, or 1 and 10. The weights cannot be achieved, and they are all polling by default
(
而且我在网上查找相关问题,有人给出了自己去实现权重的负载均衡,所以我才有这个问题,是不是新版本nacos权重的负载均衡需要自己去实现
In addition, I searched for related problems on the Internet, and someone gave me the idea of implementing load balancing with weights. That's why I have this problem. Is it true that the load balancing with weights of the new version of nacos needs to be implemented by myself
)

org.springframework.cloud
spring-cloud-starter-loadbalancer

NacosLoadBalancer is an alternative implementation of NacosRule.

我查看了NacosLoadBalancer的源码,里面有一行代码,似乎拿到了权重,但是我不清楚为什么权重负载均衡没有出现,而是一直是默认的轮询. 是我需要在应用的配置文件中加入某些配置之类的吗?
I checked the source code of the NacosLoadBalancer. There is a line of code in it, which seems to have gained weight. But I don't know why my code is not effective. Do I need to add some configurations to the application configuration file?
ServiceInstance instance = NacosBalancer 					.getHostByRandomWeight3(instancesToChoose);

@412111959 你好，这个NacosRule需要ribbon才能使用

@HHoflittlefish777 好的，谢谢，我再研究研究


Access to unformatted strings

So I'm working on a provider that would send our errors/warnings to an external error tracking application. I can't send the entire formatted message there, as it would result in a unique occurrence of that error message every time. (Not to mention some possible privacy concerns.) I would like to send the unformatted message as a way of tracking the message.
For instance, given the line:
_logger.LogInformation("User typed '{input}' on the command line", input);

I would want to send only "User typed '{input}'" to the external system. However, there doesn't appear to be way to do this. I could cast the "state" object in ILogger.Log() to ILogValues or FormattedLogValues, but neither gives me access to the original format string. (And even then, that type of casting from object seems hackish at best.) Any thoughts?

As an addendum to this, there are certain types that our logger will always have to obfuscate for security purposes. While I can enumerate the keys/values from ILogValues, I don't seem to be able to change the values at all. Again, having access to both the format string and the values would allow me to get around this.

@MikeyBurkman Regarding the original format string, there is an item in the log values list with key called {OriginalFormat} representing it

That seems... not very type-safe... That's also is assuming an undocumented implementation detail of a class inside a namespace that contains the word "Internal". I mean, it does work for now, but it's hardly something I would trust to put in production code.

cc @loudej @lodejard

@MikeyBurkman Agreed, you should not use internal implementation details.
Your use case is still not clear to me, but if you want to track the message, can't you just use the state object as an identifier?

Just FYI - Serilog/serilog-framework-logging does currently rely on the internal {@OriginalFormat} key

@muratg Your use case is still not clear to me, but if you want to track the message, can't you just use the state object as an identifier?

This use case is important if you don't use EventIds. In this case the OriginalFormat-string is the only way to do reports on your logs. You would just use SELECT COUNT(*) FROM logs WHERE OriginalFormat = "User typed '{input}'" to filter for certain log messages or SELECT TOP 10 OriginalFormat, COUNT(*) FROM logs GROUP BY OriginalFormat ORDER BY 2 DESC to get the log messages with the most occurences.
I can understand that EventIds are a burden for many people and for many smaller projects. So I agree that this is an important topic. Maybe this key could be exposed as a property to hide the implementation details?

:+1: for exposing OriginalFormat as a property, this would be nicer for the Serilog integration to work with. As @cwe1ss mentions, it's a core part of the story for message template-based structured logging.
@muratg @MikeyBurkman "OriginalFormat" is exposed in a public dictionary - so not strictly an internal implementation detail.
Let me know if you need any more info on the use case; OriginalFormat is critical for us.
Cheers!

We are going to keep OriginalFormat as the way to access unformatted string.

Hi, just thought I'd add 2¢ talking about how the longer was designed and intended to be used.
Yes, {OriginalFormat} is public surface area and you can use it in production code. It is not an implementation detail - the logging fwk itself never uses it - and is provided specifically so log providers can do things like serilog does. A custom formatter that provides colorization of values on command line, for example, or using the original format as a way to categorize messages when an application doesn't provide distinct event IDs.
The punctuation around it is to enable a log provider to differentiate systemic properties from event properties.
Also TState should not be as-cast as a known class. The only two things a logging provider should do with TState is pass it to the formatter to access the stringified log line, and as-cast it as the name-value interface to access the properties of a message which has structure.

One other note about the reasons the system ended up with that design...
TState can be a value-type struct, which means if an event is logged thousands of times a second - and nobody is recording that category+severity combination - then there are no objects or strings allocated on the heap to be gc later. If the API used an abstract class or interface as as the event state parameter then it couldn't be allocation-free. Casting a struct to an interface boxes it, so there would be an allocation to call log.
The reason for the formatter func is more obvious - you don't pay memory and CPU to format string messages that don't get logged. And in cases where the provider is doing it's own formatting you don't pay for the default formatting of a message string that isn't used.


How do I move the pagination to bottom of the table if I am not using storybook?

@Gwachukwu hello! Here is the sandbox example to do it: https://codesandbox.io/s/extend-table-example-myv9b?file=/src/index.js
We don't need Storybook to move the pagination to bottom of the table. What we need is to compose our own table like this:
https://github.com/imballinst/react-bs-datatable/blob/757de71d5168e99b9699255c52722e5c3cebb9cf/src/__stories__/02-advanced/00-Extending.stories.js#L13-L128
What we are doing is that, instead of using Datatable, we are creating our own custom table with the components defined from the Components variable. After that, we can place our components wherever we want to. In this case, I am moving the pagination to the bottom right.

@imballinst Thank you. that was useful


Docs: Fix Concepts Integration Tools Link

Description: This PR fix concepts integrations tools link.

Issue: Fixes issue #24112

@ccurme  thank you for your change, now it's working.


asyncData unexpectedly recovers initial value of data

Version
v2.10.1
Reproduction link
https://codesandbox.io/embed/nuxt-asyncdata-issue-xgqtu
Steps to reproduce

Open the repro CodeSandbox
Click the "Navigate" button (navigate to a random url)
Check if the message below the <hr> is changed to "Updated message"

What is expected ?
The message should be changed to "Updated message".
What is actually happening?
The message doesn't change.
Additional comments?
The whole project is a simple Nuxt app with a nested view (pages/index/_timestamp.vue). The "Navigate" button is only to change the URL and fire the watcher event to update the msg data. Click the button again, the nested view instance stays alive (no destroy-and-create).
In a normal Vue app, these codes work just fine. But when using Nuxt, asyncData gets called every time the URL changed, while the page component itself never being unloaded. More unexpectedly, no asyncData is defined in the page component and the initial value of data is being applied every time. As a result, the update to msg in the watcher handler never works. If watching msg, it is updated and then re-assigned to initial value.
I was expecting that asyncData only gets called once the page component is created, even when the page is reused during navigation. Please correct me if I misunderstand this feature.

This bug report is available on Nuxt community (#c9925)

There is no asyncData in your repro.
What you are experiencing is most likely caused by transitions, what probably happens is something like this:

route change
async leave transition
timestamp watcher triggered
leave transition finished
navigation to new component which only sets initial message because watcher was already triggered

If using v2.10 you can try to set features.transitions = false in your nuxt.config to confirm its the transition. A solution for you could be to use a combination of mounted and updated Vue lifecycle hooks instead of a watcher on the route param.

I might not explain my case clearly. I'm asking two possibly related questions.
Q1: Why asyncData is called when only a route param is changed?
Yes, there is no asyncData in my repro. But if I add it to my page component I can see it gets called once the route param changed, which is not what I expected. The documentation says "asyncData is called every time before loading the page component", so it should be called only once (since the page component is created only once).
Q2: Why my component state is recovered when a route param is changed?
If I serve the same codes (without asyncData) directly by Vue (not Nuxt), everything works as expected. The route param changed, the component local state (data) remained. If using Nuxt, the local state gets recovered. If I add asyncData and return a different value, the local state gets recovered to that value every time. This is why I guess the issue is something about asyncData.
And where should I set the features.transitions? I can't find anything like that from the documentation.

The documentation says "asyncData is called every time before loading the page component", so it should be called only once (since the page component is created only once).

Nope, it isn't reused unless you set the internal key value.
See https://github.com/nuxt/nuxt.js/issues/4663

I see. So destroyed lifecycle hook not being called is also intentional?


export constants like the factory address and the deployer address

I agree, in fact when calculating the contract address, you should be able to pass in a custom factory address.

good idea


Update athom-smart-plug-v2.yaml

Remove 'nan' workaround from "Current" sensor, fixed in Esphome 2024.2.1
Add "min_version" required for fix
Add "Current" limiter to switch off relay when over maximum set current
Fix "Current" sensor throttle to match example in Esphome docs
Update "Total Energy" sensor only when there is new data
Add "Restart" button
Reverted "WiFi Strength" %, Home Assistant only accepts dB or dBm
Change "Switch" name to 'Switch', otherwise it's friendly name is duplicated
Shorten sensor names to fit Home Assistant dashboard
Clean up extra whitespace

@dexn "Reverted "WiFi Strength" %, Home Assistant only accepts dB or dBm" ????
HA has no problem with using that sensor, it just sees it as a number (with the % as the unit measurement / type).
Been running fine in HA for over a year with it.

"current_limit : 16 # Current Limit in Amps. AU Plug = 10. IL, BR, EU, UK, US Plug = 16."
There was a 10A version of the v2 plug, that iirc a year ago got replaced with a 16A version. So how would this work with 10A versions being told to work at 16A ?
In Australia also its a 20A circuit for GPO's, with up to 10 outlets upon that circuit, not 10A max.

Re removing 'Device' from the sensor name, if doing this you start getting these sensors populating all over the ESP web interface, versus having them grouped up.
Same for the Reset / Restart, would suggest at least using 'Reset Factory' that would keep this sensor at the bottom of web interface with 'Restart'

@tarontop Aiden,  IMHO that was a bit rushed, 1 hour and pushed.  Allowing time for peer review and feedback (see above) would be good.
??

@tarontop
Ah OK re Amps, makes sense to use that.
Would still query as above, re changing WiFi to Db that means nothing for most users, versus a % system that everyone can understand. Doing this as one person claims it doesn't work, when it in fact does work fine in HA (in use over a year) as demonstrated above.
Also suggest any changes getting submitted start using versioning, i.e. Project version is just 2.0, but with all these changes it should be being updated for each update. So by now we'd be looking at least 2.1.x with all these updates. Doing this makes it much easier for users to check installed vs published code and decide if they want to update, without having to check the actual yaml code.
https://en.wikipedia.org/wiki/Software_versioning

Would still query as above, re changing WiFi to Db that means nothing for most users, versus a % system that everyone can understand. Doing this as one person claims it doesn't work, when it in fact does work fine in HA (in use over a year) as demonstrated above.

@Roving-Ronin Sorry. It does seem to work now. For some unknown reason last month, my HA was saying it was an incorrect unit of measurement for wifi signal. I've updated since and that issue is resolved, so I don't know where my issue was caused.


Add test generator and test

@LingForCC you may want to take of look at the test, which will be in the same folder as component and be named as *.spec.js.

The code looks great! But I am not able to run the standalone version with index.html to see whether test data is applied.

I merged this now because @u9520107 has a big refactoring!


Add dedicated subpool for tracking all blob transactions

Describe the feature
blob transactions should never have a nonce gap: #4405
and also only be allowed if the sender overdrafts at the time of insert, so they should never initially enter the parked subpool.
A blob tx is pending if it satisfies the base fee and the pending blob fee.
the max_fee_per_blob however does not affect the final tx fee since the blob fee comes from the header (Header::blob_fee).
the max_fee_per_blob is however relevant when evicting transactions, because txs with max_fee_per_blob < pending_blob_fee are not considered pending.
To make it easier to keep track of blob transactions, they should be grouped in a separate subpool, so they can be updated more easily without scanning all transactions
Additional context
No response

Hey @mattsse , just checking in here if you're going to take this or this is open for contributions. I would like to work on this if so.

hey, @chirag-bgh
ty, however, I'm already wrapping up this feature, there will be a few followups, so I'll tag you there


rtio: Transactional request support

Adds the ability to mark submissions as being transactional which has the unique semantics of allowing multiple receive/send type operations to be viewed by the submitted to iodev as a single unit of work to do.
This is needed for SPI where a sequence of reads/writes with chip select are part of a transaction.

Includes a stack of bug fixes now so CI hopefully remains happy


Fix for pause and resume in 0.10.x KafkaConsumer

As of kafka-clients 0.10.0, KafkaConsumer.pause() and .resume() take a Java Collection of partitions, not an array:
http://kafka.apache.org/0100/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html

Thanks @jmglov i'll test and review ASAP and cut a new release.

Thanks @jmglov !


Add vat exonaration code

Description
This PR adds a new council directive line (VATEX-EU-79-C) to VatExonaration
Related issue: #4

Merging this. Thanks for your contribution @win20.


docs: preview version 1.24.0-rc1

Closes #216

wait, isn't the mardown file missing in content/docs?

wait, isn't the markdown file missing in content/docs?

Yep, I was not sure but ... thinking about it, I think it makes sense. Let me add it.


HDDS-1154. Add tracing to the client side of StorageContainerLocationProtocol and OzoneManagerProtocol

The best way to display the network performance in the tracing server is to start a new span (=save tracing information) on both of the client and and server side.
This issue is about improving the client side tracing of OzoneManager and StorageLocationManager.
The easiest way to turn on tracing for a class which implements an interface is to create a java proxy with TracingUtil.createProxy. With this utility we can execute the required tracing methods (create span/close span) around the original methods without adding any boilerplate code.
Thanks to the current design hadoop rpc calls are create by the *ClientSideTranslatorPB classes which implements the original protocol interface (eg. StorageContainerLocationProtocolClientSideTranslatorPB implements StorageContainerLocationProtocol) which means that it can easily instrumented by TracingUtil.createProxy.
The only thing what we need is to use the interface everywhere (StorageContainerLocationProtocol) instead of the implementation (ClientSideTranslator) as a client.
The only required method which is not published in the ClientSideTranslator is the close method. With adding the close method to the interface (extends Closable) we are able to use the interface everywhere which can be instrumented to send the tracing information.
See: https://issues.apache.org/jira/browse/HDDS-1154

How to test it (after a clean build):
cd hadoop-ozone/dist/target/ozone-0.4.0-SNAPSHOT/compose/ozonetrace
docker-compose up -d
docker-compose scale datanode=3
#wait a few seconds
docker-compose exec scm ozone freon rk --numOfKeys=10 --numOfBuckets=10 --numOfVolumes=10 --factor=THREE --replicationType=RATIS

Check the jaeger ui from the browser: http://localhost:16686
Choose 'freon' in the 'service' drop down
Click to the 'find traces' button
Click to a 'creon: createKey' record from the results

After this patch you should see the client/server side of the related calls:
eg.

freon: StorageContainerLocationProtocol.getContainerIdWithPipeline
StorageContainerManager.getContainerWithPipeline


NaN in input tensor

The language model gives NaN or Inf found in input tensor.
train.txt
Can help why it is failing to train on non English character?

Hi,
Thank you for the interest in our work.
Please refer in this issue, to the changes that are required for training on non-English language.
In particular, make sure that you created AmharicText_train.csv and AmharicText_eval.csv with the right character set.
Let me know if it works for you.
Aviad

Thank you for your prompt response. As per your suggestion, I have cleaned my train and valid text datasets and now it is working for me. You can close the issue.


BigInt math not usable in @safe code

braddr (@braddr) reported this on 2014-10-13T02:59:11Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=13607
CC List

bugzilla (@WalterBright)
bugzilla (@WalterBright)
hsteoh
rburners

Description
module bitintsafe;

import std.bigint;

void main() @safe
{
    BigInt i, j, k;
    i = j + k;
}

$ dmd -c bigintsafe.d
bigintsafe.d(8): Error: safe function 'D main' cannot call system function 'std.bigint.BigInt.opBinary!("+", BigInt).opBinary'

I started looking into this but the rabit hole is fairly deep.  Filing a bug in hopes that someone will take up the charge on this one while I work on others.  I don't consider this an enhancement request since @safe and phobos really need to be in the 'just works' state.

rburners commented on 2014-10-14T20:43:31Z
https://github.com/D-Programming-Language/phobos/pull/2612

another try

bugzilla (@WalterBright) commented on 2016-06-12T08:13:17Z
(In reply to Robert Schadek from comment #3)
> https://github.com/D-Programming-Language/phobos/pull/2612
>
> another try

That was merged, but the error remains.

hsteoh commented on 2017-04-26T18:03:22Z
A further step in this direction:

https://github.com/dlang/phobos/pull/5354

It's still not complete; BigInt is a pretty deep rabbit warren that will need some time to completely sort out. One step at a time!

rburners commented on 2014-10-14T12:19:27Z
I had a PR open for this a while back.

https://github.com/D-Programming-Language/phobos/pull/2357

It came down to the same argument you're having on the newsgroup right now.

hsteoh commented on 2017-04-26T18:45:08Z
What should be done about the inline asm heavily used by the BigInt implementation?  We could use the sledgehammer approach and slap @trusted on all the inline asm code, but I'm a bit hesitant to do that.

braddr commented on 2014-10-14T17:05:01Z
It also suffered from being too big.  It would have been nice to get the non-controversial parts of the change in.  There was very little use of the @trusted sledge hammer.

bugzilla (@WalterBright) commented on 2019-12-24T12:48:11Z
This is more an enhancement, than a bug. Isn't it?


Update dependencies

Coverage remained the same at 21.294% when pulling 9c316056011b7f24aefce3eacba48bee8a2ce734 on dependencies into 828d03a6ef065e72a09f0cc4fa5c0dc543eb7f30 on master.