[help wanted]: add sliding window support for flashinfer

Anything you want to discuss about vllm.
flashinfer already supports sliding window in https://github.com/flashinfer-ai/flashinfer/issues/159 , and we should update our code and pass sliding window to flashinfer , to remove this restriction:
https://github.com/vllm-project/vllm/blob/5f8d8075f957d5376b2f1cc451e35a2a757e95a5/vllm/attention/backends/flashinfer.py#L739-L740
Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

@elfiegg I see your great contribution in https://github.com/vllm-project/vllm/pull/9781 , would you like to take this?
if anyone else is interested, contribution is extremely welcome.

Hey Kaichao - sorry for the delay! I can help take a look later this week if it's not urgent.

@elfiegg thank you!

Does it support interleaved sliding window attention which is used in gemma2


[Breaking Change] In-browser transpilation turning down July 25

TL;DR: The debug loader will stop down-leveling sources on July 25.
6 years ago we added a feature to the Closure Debug Loader that would detect when source files contained newer language syntax than was supported by the browser.  This was extremely useful at the time for transitioning to ES 2015, but was always intended as a last recourse "stop gap" when server-side transpilation was unavailable.  In the meantime, a number of better server-side solutions have cropped up and this feature is finally no longer needed.  We will be removing the in-browser transpiler on July 25.
This should only affect you (1) if you are using the debug loader, (2) are running with newer language features on older browsers that don't support them, and (3) only after you update to a new version of the library (NOTE: if you're pulling base.js directly from a raw.github-style URL, this will happen immediately - we highly discourage this practice).
If you are relying on the debug loader at all, we recommend looking into alternative bundling solutions.  There are a number of very performant bundlers available that should greatly improve your development experience (note also: the debug loader should never be used for production).  For Closure dependency management, consider closure-webpack-plugin if you need downleveling.  Moreover, modern browsers are keeping up with the EcmaScript spec a lot faster than they were in 2015, so in many cases downleveling is not even required anymore (and you can use a compiled binary to test against older browsers when necessary).
If anyone anticipates this change to cause undue hardship, please let me know and we can look into other options and whether it makes sense to extend the timeline.
FAQ
How do I know if this will affect me?
If you write <script src="path/to/base.js">, <script src="path/to/my/deps.js">, and goog.require('my.namespace') in your HTML, then you are using the debug loader.  This will still work, provided your sources do not use features that are newer than the browsers it runs on.  Closure Library itself may use any Stage 4 features, which should generally be supported by all evergreen browsers, but may not be available in all older browsers.  If you need to run uncompiled code on older browsers, consider using a bundler that does minimal downleveling.

This change will be rolling out today.


Mapping adds/omits additional columns on a select

When you query the same table with two different queries the results are different based on whats in the cache
async get(scheduleDate) {
       return this.stopRepository.findAll();
   }

   async mobileGet(scheduleDate) {
       const em = Main.DI.em;
       const qb = em.createQueryBuilder(Entities.Stops, "stops");
       const test = await qb
           .select(mobileStopColumns)
           .where({ start_date: { $lte: scheduleDate } })
           .andWhere({ end_date: { $gte: scheduleDate } })
           .getResultList()//.execute("all", false);
       return test;
   }

If I execute findAll, all columns are returns as expected however if I then call mobileGet with a subset of columns I still get all the columns (seemingly correctly filled in with data) as if I called findAll()
if I only call mobileGet first I only get the columns I expected, however then findAll returns the subset instead of the full column list
return res.map(r => this.em.map(this.entityName, r));
as long as I don't map it works as expected. (call execute)
To Reproduce
See above
Expected behavior
That mapping would only map for the columns selected and both calls would return their respective data.
Versions

Dependency
Version

mikro-orm
4.5.9

That is how identity map works, its not result cache. Each request needs to have its own context.
https://mikro-orm.io/docs/identity-map

I just discovered that now was about to say.


Disable pooling in Northwind fixture

Remove appveyor/travis
Resolves #11309

@dotnet-bot test windows Release x64 Build


Check for private keys disabled before attempting unlock

Before trying to unlock a wallet, first check if it has private keys disabled. If so, there is no need to unlock.
Note that such wallets are not expected to occur in typical usage. However bugs in previous versions allowed such wallets to be created, and so we need to handle them.
Fixes #772
For some additional context, see #631

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews
See the guideline for information on the review process.
A summary of reviews will appear here.

cc @furszy

Doesn't mean that the migration process will also be blocked when this happen? --> look at this line getEncryptionStatus() should be returning Locked, which here would trigger the askpassphrase dialog in the same way described on #772.

That's a good point. Perhaps getEncryptionStatus() should just move to returning NoKeys for all private key disabled wallets.

Also, what is the expectation here, merge and backport this PR without backporting #28724? Because, after #28724, this isn't a problem anymore.

28724 is a much scarier change since it deletes things from the wallet database and I wasn't sure if people were comfortable with that. If we move forward with it, then that can supersede this PR.

Also, what is the expectation here, merge and backport this PR without backporting #28724? Because, after #28724, this isn't a problem anymore.

28724 is a much scarier change since it deletes things from the wallet database and I wasn't sure if people were comfortable with that. If we move forward with it, then that can supersede this PR.

I'm going to merge this to get this bugfix into 27.0 as https://github.com/bitcoin/bitcoin/pull/28724 remains untagged.


draft May cloud release notes

Closes #

Add May Cloud release notes.
Need to roll new Usage Dashboard template into docs.

add maps viz.


Added Some Colors and Structured the Code Base

Added Some Colors as discussed in the README.md file and Structured the Code Base.
Improved the UI and did some tweaks with the Code.
Added requirements.txt file
Added Banner and Colors in the UI.
Restructured the Code.
Update README.md file.

Thank you very much for the contribution!
I'm thinking of maybe moving everything into the one main file? What do you think of that?
Also, push the screenshots to some oneline site. I'll be editing the commits.

Thanks, looks real cool!

Thanks again! Made some changes to https://github.com/Anon-Exploiter/decoder/commit/732064ac5429d050693b85a12dcc270970b47026
Merged all the code into one file.


Development of RADOS binding of Ceph FS

Development of RADOS binding of Ceph File System
Even though Ceph FS is not NoSQL database, RADOS, Ceph utility, supports object-based storage.
For Ceph benchmark for cloud services. I implemented RADOS binding using rados-java library expect the scan() function.

The travis failure is because you need to add the new module to the list of dependencies for the distribution module.

I fixed all code you mentioned, and an additional error.

I changed the version to 0.2.0 and merged from YCSB master for updating to 0.9.0-SNAPSHOT.

does rados provide any kind of testing utility jar that could be used to include a test?

I switched rados and ioctxto non-static, and implemented a test.
The test is success in my cluster, but the Travis CI building was failed because there is no the Ceph cluster.

The test is success in my cluster, but the Travis CI building was failed because there is no the Ceph cluster.

Does Ceph have some kind of artifact for making a local test instance that we could make use of? (see the hbase10 or accumulo bindings for examples) If not,  we should update the test to make use of the JUnit Assume API to skip the test when a Ceph instance is not present (see the mongodb or riak bindings as an example).

If not, we should update the test to make use of the JUnit Assume API to skip the test when a Ceph instance is not present (see the mongodb or riak bindings as an example).

I was not able to find the test instance for Ceph, so I updated to skip the test using JUnit AssumeNoException.


Don't count comments post-approval as requests for changes

This has bitten us a few times in the past that a comment posted to a
thread was counted as a request for change, with the new setting. This
tweaks the behavior so it's not the case anymore: after a reviewer has
approved a PR, they can comment freely, but if they want to ask for
changes, they should be explicit about it and do a "Request changes"
review.

Oh nice!


Panic when only using the finalize hook in decorator

I have a usecase where i want to a hook to be called only when the resource is being deleted, with the assumption that nothing has to be done for create/update operations.
So, if i mention only the finalize hook, I see a runtime panic error in the logs of metacontroller:

Decorator looks something like this:
apiVersion: metacontroller.k8s.io/v1alpha1
kind: DecoratorController
metadata:
  name: call-removal-api
spec:
  hooks:
    finalize:
      version: v1
      webhook:
        url: http://call-removal-api.metacontroller.svc.cluster.local?type=delete
  resources:
  - apiVersion: helm.toolkit.fluxcd.io/v2beta1
    resource: helmreleases

Should this be a supported use case in metacontroller?

@Shashankft9 which version do you use ? I remember it was reported already, and I was under impression it is fixed already

hey @grzesuav, I am using version 4.10.0, let me try the latest version and see if this feature is there - thanks!

@grzesuav I checked with the latest metacontroller, seems like this issue is present there as well, in this line: https://github.com/metacontroller/metacontroller/blob/master/pkg/controller/decorator/hooks.go#L60, here c.syncHook will be nil which will cause a panic.
Couldn't this be fixed by just doing a check like c.syncHook.IsEnabled() ?

This should now be catered for in the latest version.


Recognition of Sticheropsis as a segregate of Sticherus (Gleicheniaceae, Polypodiopsida)

Author(s) of proposal
Lucas V. Lima, Thaís E. Almeida & Alexandre Salino
Name of taxon
Sticheropsis
Rank of taxon
Genus
Approximate number of species affected
2
Description of change
A phylogenetic study based on genomic-scaled dataset, with extensive geographic sampling, recovered Sticherus as paraphyletic (Lima et al. in Molec. Phylogen. Evol. 184: 107782. 2023).  The clade called Sticherus s.s, including S. laevigatus, the type of the genus, and Sticherus milnei (Baker) Ching was recovered as sister to a larger clade comprising Stromatopteris and Gleichenia, which in turn is sister to the remaining species of Sticherus (referred to here as the aff. Sticherus clade; Lima et al., l.c. 2023).  Sticherus s.s. is characterized by having an anisotomic branching pattern, whereas the species in the aff. Sticherus clades are characterized by having an isotomic branching pattern. The aff. Sticherus clade has a pantropical distribution with most of its species occurring in the Neotropics (about 54 species), whereas the Sticherus s.s. clade (S. laevigatus and S. milnei) occurs only in Australasia (Holttum, l.c.; Chinnock & Bell in Fl. Australia 48: 148–162. 1998; Gonzales &Kessler, l.c.). Divergence time estimates suggest that the split between Sticherus s.s. from the Gleichenia+Stromatopteris+aff. Sticherus clade occurred around 114–117 mya, with the latter diverging from Stromatopteris and Gleichenia at approximately 111–113 mya (Lima et al., l.c. 2023).
Reason for change
The paraphyly of Sticherus presents a significant nomenclatural challenge when aiming to recognize monophyletic genera. Under this circumstance, the name Sticherus would be restricted to just the two the species in the aff. Sticherus clade:  S. truncatus (type) and S. milnei. Consequently, all remaining species in the aff. Sticherus clade would require a new  generic name. Aiming to minimize the nomenclatural changes (avoiding 91 new combinations), we proposed the conservation of Sticherus with a new type Sticherus gracilis, a species from the aff. Sticherus clade.  To accommodate S. milnei and S. truncatus, we proposed a new genus, Sticheropsis,  in a paper accepted in the Botanical Journal of The Linnean Society. The conservation proposal was published in Taxon 73(1):305-306 (Lima et al. 2024) (available below).
Accepted version of BJLS manuscript:
Accepted_Lima et al Gleicheniaceae Classification_BJLS_2024.pdf
Taxon proposal:
TAXON-2024-Lima-3006 Proposal.pdf
Gleicheniaceae Phylogenomic:
Lima et al 2023.pdf
Reference(s) for publication of the name
Lucas Vieira Lima, Thaís Elias Almeida, Michael Kessler, Germinal Rouhan, Shuichiro Tagane, Vinícius Antonio de Oliveira Dittrich & Alexandre Salino (2024) The classification of the fern family Gleicheniaceae, with the description of a new genus, segregated from Sticherus. Botanical Journal of The Linnean Society. DOI: 10.1093/botlinnean/boae027
Lucas Vieira Lima, Thaís Elias Almeida, Michael Kessler, Germinal Rouhan & Alexandre Salino. (2024) Proposal to conserve the name Sticherus (Gleicheniaceae) with a conserved type. Taxon 73(1):305-306. DOI: 10.1002/tax.13119
Lucas Vieira Lima, Alexandre Salino, Michael Kessler, Germinal Rouhan, Weston L. Testo, Caio Suzart Argolo, GoFlag Consortium, Thaís Elias Almeida (2023) Phylogenomic evolutionary insights in the fern family Gleicheniaceae. Molecular Phylogenetics and Evolution 184: 107782. DOI: 10.1016/j.ympev.2023.107782.
List the numbers of any related issues
No response
Code of Conduct

[X] I agree to follow the PPG Code of Conduct

There are two different issues here, one of which PPG is qualified to vote on and the other which PPG is not. The PPG community can decide on whether to accept the generic delimitations suggested in this study. However, whether the genus with two species is to be called Sticherus or Sticheropsis is not within the power of the PPG community to decide one way or another. A proposal to conserve Sticherus with a conserved type has been submitted to Taxon. This will be discussed and voted on by the appropriate Nomenclatural Committee, then voted on by the General Committee and eventually their decision will be ratified by the International Botanical Congress. If no decision is reached by the Committees before the upcoming IBC and can be voted on this year, strictly speaking no decision will be reached for another six years (although overturning decisions by these Committees is practically unheard of so names are often adopted once the decisions of the Committees have been published). No matter what PPG votes here on this proposal, the decisions of the Committees and IBC are the only ones that matter and, therefore, the proposal as presented here is rather meaningless. A proposal to recognise the genera as delimited, along with noting that a later decision on the conservation proposal will lead to clarity on the names of the genera, would be appropriate but the simple fact is that until the Committees and IBC rule on the conservation proposal, the correct name for the genus with two species is Sticherus whether we like it or not.
Incidentally, the genus of two species is not only in Australasia as stated in the BJLS draft paper because S. truncatus is found in western Malesia and continental SE Asia. If it is not too late and has not already been corrected, note also that there are inconsistencies in the gender being used for Sticheropsis in the BJLS draft paper.

I have been looking into the ramifications of this proposal some more and another angle has occurred to me. Only when the Sticherus Conservation proposal is approved by both the Vascular Plants and General Committees, and the report of the General Committee is published, can the change be said to take effect under the terms of the International Code of Nomenclature (Art. 14.15). This date is extremely important as if the genus Sticheropsis is published before the report of the General Committee (assuming they approve the conservation proposal), then Sticheropsis will be illegitimate under Art. 6.4 and will not become legitimate even if the proposal is approved. At that point, regardless of how the vote of PPG proceeds and how established use of the name Sticheropsis has become, the genus with two species will have no name under the rules of the ICN. The only way to rectify that would be to wait until after the General Committee has published its report before Sticheropsis is formally described, or to describe a new genus to include the illegitimate name Sticheropsis, or to apply for Conservation of Sticheropsis. This will all be a lengthy process and hence this proposal to PPG is extremely premature.

As noted above, the Code and Committees will ultimately determine the correct names for these two clades. However, there has been some desire/discussion to apply names in PPG in anticipation of their eventual acceptance, realizing of course that such acceptance may not materialize. The aim, I think, is to avoid another Aglaomorpha/Drynaria situation and also, more generally, to do less harm. Since there is no name for the larger clade, the alternatives would presumably be to recognize a non-monophyletic Sticherus or to describe a new genus for the larger clade and implement that (when published) in PPG. Maintaining the larger clade as Sticherus and recognizing the smaller clade as a new genus would seemingly do less harm. The critical issue, as I see it, is the timing issue raised in the second comment...with Sticheropsis being illegitimate as currently typified. Presumably, this issue could be avoided if the new genus was typified on the other species? We would then be left with a situation more analogous to that for Dennstaedtiaceae (https://github.com/pteridogroup/ppg/discussions/45).

I agree with Eric’s comment. It is crucial to realize the distinction between the two issues. PPG aims to clarify the recognition of taxa based on our understanding of their phylogenetic history. The names applied to the taxon accepted have to follow the roles of the Code. In most cases, this is not a challenge but in some cases we may not feel happy with the name selected by applying the standard priority role. It is not the task of PPG to make a decision on this although we can determine the preference of the PPG community. At the end, a proposal has to be submitted to and agreed on by the nomenclature sessions held at the IBC.
Eric mentioned a good example, the Drynaria/Aglaomorpha issue. In PPGI we accepted Aglaomorpha as the name for this clade because it is the oldest available name. The proposal to conserve Drynaria against Aglaomorpha was submitted to and agreed on during the nomenclature session held at the IBC in Shenzhen. Thus, Drynaria status is now clear.
Lepisorus is another interesting case. Several genera now considered to be part of Lepisorus have priority. Some years ago, a proposal was submitted to conserve Lepisorus. The question here would be to clarify the decision of the proposal during the nomenclature session at the IBC in Melbourne.
Of course, we hope to avoid messy situation but we have to accept the procedures in place to handle diversions from the priority roles set in the Code.
Luckily, the next IBC is happening soon and thus decisions will be made on the majority of the issues that challenge us at moment. Thus, I recommend we focus on the question if we accept the separation of the taxa whereas the decision on the name utilized will be only resolved during the IBC. Of course, we can express our preference but it is not the decision by PPG alone but the decision of the nomenclature session.

I do not think we are disagreeing at all over the fundamental issue here, which is on whether we recognise these two groups as different genera or not. What I am pointing out is that PPG has no role to play at all in what these genera are to be called and we should not be asked to vote on this proposal as it is currently worded. Harald highlights the Aglaomorpha/Drynaria issue. When these genera were synonymised, Aglaomorpha became the correct name of the genus. When the conservation proposal was passed, Drynaria became the correct name. A while ago, PPG was asked to vote on this but actually, Drynaria is now the correct name and no amount of input from us would change that. The PPG vote was rather meaningless. I actually have little doubt that the proposal to conserve Sticherus with a conserved type will pass but I want to clarify what will now happen. The proposal has been submitted and will be voted on by the Vascular Plants Committee. They will forward their decision to the General Committee who will also vote on it. The General Committee will publish their decision. On that date, and only from that date, can a new name be proposed for the genus with the old type of Sticherus in it, i.e. the genus with two species in Asia/Australasia. The decision must be ratified at the IBC following the report of the General Committee but really this is only a formality. Do note that this process takes at least months and often years to be completed and although it is not impossible it could be completed by the Madrid IBC, I think this is unlikely. Nevertheless, we only need to wait until the report of the General Committee which will be long before the next IBC in six years (I would presume).
As Sticheropsis is not yet published at all, we are currently effectively being asked to approve what is technically an invalid name. If Sticheropsis is published before the report of the General Committee, then we are being asked to vote for what will be an illegitimate name. And as the paper is said to be already accepted in Bot. J. Linn. Soc., I would imagine that is very likely. Any indication that the genus Sticheropsis includes the type of Sticherus laevigatus, even as a synonym of S. truncatus, will make Sticheropsis illegitimate - choosing a different type will not fix that problem. Only exclusion of Sticherus laevigatus from Sticheropsis will fix the problem and I assume that is not an option.
I would argue that as currently formulated, the only option on this proposal is to vote no or we would be in danger of undermining our credibility which should be to formulate a stable taxonomic framework for pteridophytes. If the PPG proposal were to be reframed to be voting on the principle that Sticherus be split into two genera with the New World taxa in the genus Sticherus, following the conservation proposal in Taxon, and the Old World taxa in the proposed genus Sticheropsis which should remain unpublished (and perhaps even cited as Sticheropsis ined. or "Sticheropsis") until the General Committee has published its report, then that is another matter. The Bot. J. Linn. Soc. paper would then have to be revised to prevent the publication of Sticheropsis as an illegitimate name if the intention is indeed to have it published before the General Committee's report. If the paper is published soon in its current form, then in the future the genus would need a new name and that name could not be Sticheropsis (because a conservation proposal for it would almost certainly fail)! How would we then reconcile a PPG vote in favour of Sticheropsis with the reality that the name would be illegitimate?

Dear PPG Fellows,
Thank you for all this discussion regarding the Sticheropsis proposal.
It is clear that we have to deal with the Sticherus paraphyly issue, and a new genus is needed. We chose the “less harm pathway”, by seeking the conservation of Sticherus with a different type. Avoiding more than 90 new combinations.
In fact, it is beyond PPG scope to decide on those types of proposals, since it is in power of the Nomenclatural Committee in the IBC. However, as pointed by Harald Schneider, one of the mains goals of PPG is to reflect the phylogeny of ferns and lycophytes. That was our goal with the Sticheropsis proposal.
It is policy of the PPG to accept and vote on such cases with pending voting in the IBC. We had similar cases, where new genera were voted and approved by the community. It is not good for us to use different criteria with similar cases. I personally contacted the PPG organization asking instructions about my case and proposition.
I especially would like to thank David for reading our work and providing notes. I made a mistake by choosing the type of Sticheropsis same as Sticherus before the appreciation of my proposal in the IBC. However, selecting another type will, in fact, solve this issue. Regardless of the inclusion of S. truncatus in the new genus. Fortunately, I still have time to change this issue, since we are still revising the manuscript proofread. So, I contacted the Editors in the BJLS, and the actions to solve this situation are in their course. Therefore, we will not have an illegitimate genus. As soon as possible, I will upload the new version of the manuscript here.
I thank the community once again for all this discussion and clarifications regarding my work. I put a lot of effort, alongside my coauthors, to contribute with the taxonomy , biogeography and evolution of Gleicheniaceae. It is not easy to do and keep doing this in Brazil!
Best wishes,
Lucas

Hi Lucas, I think we all understand the clear intention of your proposal and your desire to provide a solid framework for the species concerned. I want to make only one quick comment. Under Articles 52.1 and 52.2, changing the type species of Sticheropsis will not allow for the legitimate publication of Sticheropsis if you continue to delimit the genus in the same way. This is because the type of a name which should have been taken up is still being included in the genus, i.e., the type of S. laevigatus. One option you may consider in your BJLS paper is to make it clear that although you are proposing the genus Sticheropsis you do not consider it to be be validly published in the paper (see Art. 36.1). The benefit of this is that it leaves open the option of validating it as soon as the General Committee has issued its report (assuming it is favourable). If you follow this route, you establish your intention to use the name and because the name has not been validly published, it is consequently not possible for it to be illegitimate. A note to explain this process in the BJLS paper would be useful. You should note too that as the genus would not be validly published, neither would either of the combinations you propose.

I think Lima et al.  can still designate Gleichenia milnei Baker as the type of their new genus Sticheropsis so that Sticheropsis can be validly published, although it will be superfluous upon publication. A later conservation proposal to conserve Sticheropsis might succeed considering the lengthy process of the General Committee's official report and the need of names in the fern community. The last GC report came out six year after the Shenzhen IBC.  The next one might be years too after the Madrid IBC.

Quick reply to Li-Bing. The General Committee publishes its reports much more often than every six years and once they have reported on the proposal to conserve Sticherus with a conserved type, Sticheropsis could be published. If Sticheropsis were to be validly published now, and consequently illegitimate, I think there would be almost no chance that the Nomenclature Committee for Vascular Plants would vote to conserve it if a later application were to be submitted. This is because what they are tasked with doing is promoting stability. They would see that the timescale has been too short for the name to have become established and that the cause of the instability was entirely preventable.

One procedural thing about the IBC--the deadline for submitting mail ballots has now passed. There are always a limited number of nomenclatural proposals submitted too late for the relevant committees to consider them in time for the Congress that are only discussed on the floor.  The conservation proposal for Sticherus did make it into Taxon about a month before the end of March 2024 deadline for proposal publication, but has not to-date made it through both nomenclatural committees. Thus, there is a chance that this proposal will not be resolved at the IBC session this year.  Even if it is discussed at the in-person nomenclatural session, the resultant vote could be to refer it back to committee. There could be considerable delay if that happens, as these committees take a while to re-constitute themselves after an IBC because of changes in membership.  I personally am supportive of the proposal to PPG. However, I would still vote to delay action on this item until the type of Sticherus becomes fixed, either through acceptance or rejection of the conservation proposal, and the pertinent nomenclatural combinations are published. Basically, PPG is stuck--there currently is no validly published name to account for those species that are not in the same part of the overall lineage that includes the type of the name Sticherus if that genus is split into two monophyletic groups. PPG also cannot recognize an unpublished name, as the act of doing so would constitute publication of a nomen nudum and render that invalid name unavailable for any future use.

I got clarification from Karen Wilson, the chair of the IBC general nomenclature committee. Any published nomenclatural proposals that do not make it tgrough review by both nomenclature committees prior to the IBC are deferred until after the Congress. A proposal tgat is supported by both committees can be treated as tentatively accepted (and thus guide the publication of suitable nomenclatural combinations. However, it is not codified until the next IBC.

Quick clarification, a name that has not been validly published, such as a nomen nudum, does not exist for nomenclatural purposes and can be used in the future. As long as the conditions for valid publication are not met, using the name in PPG will not preclude it from being validly published with the same name later. A problem may arise arrive, however, if someone later does validly publish it, thereby making the name illegitimate if done before the Committees have published their recommendations.
But in order for anybody to make an informed decision on this, we shall need to know what amendments the authors of the BJLS paper have made before we vote.

Given the uncertainties regarding this proposal, I am going to leave it open for now, but not put it on the ballot yet.

Dear PPG II fellows,
Thank you once again for bringing Sticheropsis nomenclatural issue to discussion. It is a challenging nomenclatural situation, and it is very helpful to count on the keen eyes of our community.
As David said, some points should be clarified to make it easier to the community to vote on this genus proposal.
Germinal Rouhan (coauthor in the BJLS paper) and I contacted Valéry Malécot, member of the General Committee of Nomenclature to clarify this issue. With their advice, we are moving forward with the following:

The Sticherus conservation proposal published on February 21, 2024, will not go to the Committee for Vascular Plants (NCVP) before the end of 2024 and to the general committee (GC) before 2025, and formal validation will happen at the next IBC.

We must consider that our Sticherus proposal is to be applied, otherwise (if we do not use it ourselves) that becomes an argument for the NCVP or the GC to rebut the proposal directly (because this would suggest that we are not in line with our proposal). I think it is in the best interest of the PPG community to seek stability on a worldwide spread genus like Sticherus and avoid more than 90 new combinations.

Regarding the type of Sticherus: in the coming publication at BotJLinnSoc, We designated the type of Sticherus: "Typus: S. gracilis (Mart.) Copel. (Gen. Fil.: 27. 1947) (Mertensia gracilis Mart.), typ. cons. prop." (as in the Taxon proposal), which informs readers that there is a conservation proposal in progress, and which has no effect on the validity of the genus Sticheropsis.

Regarding the type of Sticheropsis: We choose Sticheropsis milnei -instead of S. laevigatus (currently the type of Sticherus)- as the type of Sticheropsis, avoiding any possible problems, raised by several colleagues, regarding the type of Sticherus and Sticheropsis.

Regarding one of David’s concerns, the inclusion of S. truncatus in Sticheropsis will not be against articles 52.1 and 52.2 of the ICN. Because the proposal of conservation of the type of Sticherus, Sticheropsis will not be illegitimous, since the proposed type of Sticherus (Sticherus gracilis) is not included, and both species can be included in Sticheropsis.

Therefore, the PPG may recognize the Sticheropsis, and we will have a solution for Sticherus paraphyly until the approval of my conservation proposal in the next IBC.

Dear Lucas and PPG,
Thanks for the informative message. I have been a member of the General Committee (I am stepping down next month), which I should have mentioned before you went through the effort to contact Valéry.  However, unless I am missing it, the name Sticheropsis is not yet published. That alone requires that PPG not formally recognize it. As a group, we have not approved recognition of other fern genera that were either unpublished or for which the majority of the new combinations had not been made (as in some of the African Cheilanthes segregates that were proposed to PPG).  It would be inconsistent to approve recognition of this particular genus at the present time.  It can always be done later, once the committees have gone through their deliberations. But this is preferable to the committees ruling against the proposal and PPG having accepted what would then become an illegitimate generic name.
Be well,
GY
George Yatskievych, Ph.D.
Botanist, Curator: Billie L. Turner Plant Resources Center, University of Texas at Austin
Main Bldg Rm 127, 110 Inner Campus Dr, Stop F0404, Austin, TX 78712-1711 U.S.A.
Tel.<PHONE_NUMBER><EMAIL_ADDRESS>From: lucaslima1618 @.>
Sent: Friday, June 7, 2024 2:05 PM
To: pteridogroup/ppg @.>
Cc: Yatskievych, George A @.>; Comment @.>
Subject: Re: [pteridogroup/ppg] Recognition of Sticheropsis as a segregate of Sticherus (Gleicheniaceae, Polypodiopsida) (Issue #78)
Dear PPG II fellows,
Thank you once again for bringing Sticheropsis nomenclatural issue to discussion. It is a challenging nomenclatural situation, and it is very helpful to count on the keen eyes of our community.
As David said, some points should be clarified to make it easier to the community to vote on this genus proposal.
Germinal Rouhan (coauthor in the BJLS paper) and I contacted Valéry Malécot, member of the General Committee of Nomenclature to clarify this issue. With their advice, we are moving forward with the following:

The Sticherus conservation proposal published on February 21, 2024, will not go to the Committee for Vascular Plants (NCVP) before the end of 2024 and to the general committee (GC) before 2025, and formal validation will happen at the next IBC.
We must consider that our Sticherus proposal is to be applied, otherwise (if we do not use it ourselves) that becomes an argument for the NCVP or the GC to rebut the proposal directly (because this would suggest that we are not in line with our proposal). I think it is in the best interest of the PPG community to seek stability on a worldwide spread genus like Sticherus and avoid more than 90 new combinations.
Regarding the type of Sticherus: in the coming publication at BotJLinnSoc, We designated the type of Sticherus: "Typus: S. gracilis (Mart.) Copel. (Gen. Fil.: 27. 1947) (Mertensia gracilis Mart.), typ. cons. prop." (as in the Taxon proposal), which informs readers that there is a conservation proposal in progress, and which has no effect on the validity of the genus Sticheropsis.
Regarding the type of Sticheropsis: We choose Sticheropsis milnei -instead of S. laevigatus (currently the type of Sticherus)- as the type of Sticheropsis, avoiding any possible problems, raised by several colleagues, regarding the type of Sticherus and Sticheropsis.
Regarding one of David's concerns, the inclusion of S. truncatus in Sticheropsis will not be against articles 52.1 and 52.2 of the ICN. Because the proposal of conservation of the type of Sticherus, Sticheropsis will not be illegitimous, since the proposed type of Sticherus (Sticherus gracilis) is not included, and both species can be included in Sticheropsis.

Therefore, the PPG may recognize the Sticheropsis, and we will have a solution for Sticherus paraphyly until the approval of my conservation proposal in the next IBC.

Reply to this email directly, view it on GitHubhttps://github.com/pteridogroup/ppg/issues/78#issuecomment-2155368541, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A62P7PXHYVKUNHRQQJK6ZBLZGH74ZAVCNFSM6AAAAABGCXPXTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJVGM3DQNJUGE.
You are receiving this because you commented.Message ID<EMAIL_ADDRESS>

Dear George Yatskievych,
Thank you for your comment. I saw your reply email and wanted to provide some clarification. The paper describing Sticheropsis has been accepted and will be published in the next few days. When we vote on this proposal, likely next month, the genus will have been published.
Thank you.
Best wishes!

Dear Lucas,
I perhaps misunderstand what you are saying, and it may not be possible to fully comprehend the ramifications until I have seen the text of your paper, but I still have some concerns. I have no problem at all with your points 1 and 3. On your point 2, if the two committees used an argument that PPG not using Sticherus and Sticheropsis was a reason to reject the proposal, the committees would be violating Recommendation 14A.1 in the ICN. They would not. On your point 4, as you are describing a new genus, you can choose as the type any of the included species. However, on points 4 and 5, do note that until (assuming they do) the General Committee has published its recommendation to accept the proposal to conserve Sticherus with a conserved type then the type of Sticherus remains S. laevigatus not S. gracilis and, under Art. 52.1, regardless of which species you make the type of Sticheropsis, if you include the type of S. laevigatus within Sticheropsis, then Sticheropsis will be illegitimate. Please see Art. 6.4, Ex. 4 for a directly analogous example.

Dear PPG II feloows,
The manuscript with Gleicheniaceae classification was published in BJLS.
boae027 (1).pdf
Regarding Sticheropsis, as mentioned in a previous comment, I followed the guidance of Valéry Malecot and Germinal Rouhan.
I believe the proposal is now ready for a vote.
Thank you all for your valuable contributions to this discussion.
Best wishes,
Lucas

Dear Lucas,
As has been discussed earlier, the timing of your paper is unfortunate. It should not have been published until after the proposal to conserve the generic name Sticherus with a new type was voted on by the pertinent nomenclatural committees.  The fact is that Sticherus laevigatus (as your paper noted, a synonym of S. truncates) is still the acknowledged lectotype of the genus until a proposal to alter this has gone through review.  Thus, Sticheropsis as published is illegitimate because it contains the type of an earlier genus.  As was also noted by others in this discussion, once a genus is illegitimate that name is no longer available in the future, regardless of the vote on the proposal.  You will want to republish the nomenclatural portion of your paper with a different generic epithet if your proposal is approved by the two nomenclatural committees in the future.  As such, there is no way for PPG to approve the reclassification.
Sorry,
GY
George Yatskievych, Ph.D.
Botanist, Curator: Billie L. Turner Plant Resources Center, University of Texas at Austin
Main Bldg Rm 127, 110 Inner Campus Dr, Stop F0404, Austin, TX 78712-1711 U.S.A.
Tel.<PHONE_NUMBER><EMAIL_ADDRESS>From: lucaslima1618 @.>
Sent: Thursday, July 25, 2024 8:51 AM
To: pteridogroup/ppg @.>
Cc: Yatskievych, George A @.>; Comment @.>
Subject: Re: [pteridogroup/ppg] Recognition of Sticheropsis as a segregate of Sticherus (Gleicheniaceae, Polypodiopsida) [POSTPONED] (Issue #78)
Dear PPG II feloows,
The manuscript with Gleicheniaceae classification was published in BJLS.
boae027 (1).pdfhttps://github.com/user-attachments/files/16378590/boae027.1.pdf
Regarding Sticheropsis, as mentioned in a previous comment, I followed the guidance of Valéry Malecot and Germinal Rouhan.
I believe the proposal is now ready for a vote.
Thank you all for your valuable contributions to this discussion.
Best wishes,
Lucas

Reply to this email directly, view it on GitHubhttps://github.com/pteridogroup/ppg/issues/78#issuecomment-2250376105, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A62P7PWHZF7U2B3R2RFQQCTZOD7FLAVCNFSM6AAAAABGCXPXTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJQGM3TMMJQGU.
You are receiving this because you commented.Message ID<EMAIL_ADDRESS>

Dear PPG Fellows,
We obviously made a mistake in our interpretation of recommendation 14.1 that cannot truly apply to Sticheropsis. This latter name is indeed illegitimous, and we will have to publish a different generic name, and as a consequence we withdraw this proposal here in PPG.
Best wishes,
Lucas


IE 10 and 11: Unable to get property 'teardown' of undefined or null reference

Getting this problem on 2.1.9 and 3.0.0 in IE 10 and 11. Works fine in IE Edge.
Edit:
My bad, I was trying to call revert() on a seeThru object. It appears that the video doesn't get initialized at all and there's no error.

So is there anything the library can do about that issue or can we close it?

My bad. The video's height was over 1200px which is not supported by IE. I thought the plugin was at fault but I was wrong.
Thanks.

@slavajacobson is there documentation somewhere regarding dimension limits? I can't seem to find anything definitive


nanovdb fails to build if cuda version is 10.1 or earlier

What
nanovdb fails to build if cuda version is 10.1 or less.
Where
Debian Linux 10.5, Cuda 10.1
Why
The cmake test uses an experimental param for nvcc --extended-lambda which gives an error on nvcc 10.1 or earlier
Fix
The parameter exists in nvcc 10 and 10.1 but is prefixed by --expt-. Adding a check to cmake fixes the build.
		set (CUDA_EXTENDED_LAMBDA "--extended-lambda")
		if (CUDA_VERSION_MAJOR EQUAL 10)
			if  (CUDA_VERSION_MINOR LESS_EQUAL 1)
				set ( CUDA_EXTENDED_LAMBDA "--expt-extended-lambda")
			endif()
		endif()
		set ( CMAKE_CUDA_FLAGS "${CUDA_EXTENDED_LAMBDA} -use_fast_math -lineinfo")

Other
I'm not sure about 9 or earlier as I don't have an installation to test.

Thanks Adnan - especially for the detailed document of the issue and proposed solution - I’ll look into this ASAP!
Cheers,
Ken

On Sep 12, 2020, at 3:54 PM, Adnan<EMAIL_ADDRESS>wrote:

What
nanovdb fails to build if cuda version is 10.1 or less.
Where
Debian Linux 10.5, Cuda 10.1
Why
The cmake test uses an experimental param for nvcc --extended-lambda which gives an error on nvcc 10.1 or earlier
Fix
The parameter exists in nvcc 10 and 10.1 but is prefixed by --expt-. Adding a check to cmake fixes the build.
  set (CUDA_EXTENDED_LAMBDA "--extended-lambda")
  if (CUDA_VERSION_MAJOR EQUAL 10)
  	if  (CUDA_VERSION_MINOR LESS_EQUAL 1)
  		set ( CUDA_EXTENDED_LAMBDA "--expt-extended-lambda -use_fast_math -lineinfo")
  	endif()
  endif()
  set ( CMAKE_CUDA_FLAGS "${CUDA_EXTENDED_LAMBDA} -use_fast_math -lineinfo")

Other
I'm not sure about 9 or earlier as I don't have an installation to test.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

My pleasure and thank you for the nanovdb initiative! This would help me eliminate a lot of boilerplate code.

I’ll push a fix up tomorrow, but note that it will also include other changes (and improvements). This includes changes to the memory layout which implies that the major version number is bumped (21->22) and consequently  .nvdb files will have to be generated again.
Cheers,
Ken

On Sep 12, 2020, at 7:51 PM, Adnan<EMAIL_ADDRESS>wrote:

My pleasure and thank you for the nanovdb initiative! This would help me eliminate a lot of boilerplate code.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Awesome. Thanks for the quick fix! Also, I'm not that far into the integration to worry about file compatibility yet.
Best regards,

Hi Adnan,
This is being delayed because I’ve literally had to evacuate my house do to the Bobcat wildfire! Assuming my house doesn’t burn down I expect to be working normally again end of this week

On Sep 12, 2020, at 8:29 PM, Adnan<EMAIL_ADDRESS>wrote:

Awesome. Thanks for the quick fix! Also, I'm not that far into the integration to worry about file compatibility yet.
Best regards,
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Of course. Stay safe. This can wait.


Panel fails to open - Windows and Linux builds

Hi,
I'm encountering an issue with the module, and I don't really know what steps to give in order to reproduce it.
The panel won't open, whether it is configured as an independant menu, or in the "Create actor" section. I tried 1.7.0 and 1.6.3, both on my windows and linux builds.
Here is what I caught in my web browser :

Hope this is of some help!

Hi! Are you using the french translation by any chance? I noticed some issue with that, as the french translation is no up-to-date and I think causes this issue. But I should investigate so it doesn't crash.

Yes, indeed I am using the french translation! What seems odd to me is that I tried to disabled all modules (including the french translations) except this one, and I had the same issue.

@Potjoe-97 I identified the issue as some mismatch between keys, the key HCT.Class.Submit used to be a final key (it mapped to a translated text) but now its a parent key, with another level of keys under it, and that was not updated on the fr.json.
I corrected that so that the module should work now. I noticed some errors to pick up some input names and etc, but it doens't seem to hamper the usage: the hero seems to get created with everything it should have.
Please do notice that the FR localization is currently deprecated, as it was becoming hard to keep it updated, not been myself a native french speaker. The idea was to move it into an independent module someone else could manage, but that hasn't happened just yet, applications still open though! :P


I lost all the items on the dash board again

Dev Home version
<IP_ADDRESS>
Windows build number
10.0.23471.1000
Other software
OS Build Version: 10.0.23471.1000.amd64fre.ni_prerelease.230526-1341
.NET Version: .NET 6.0.16
Steps to reproduce the bug
Set the dash board
Close the application
Restart the PC
Open the dashboard
All of the items on the dashboard are lost.
Expected result
Retain the items I set on the dashboard
Actual result
The dashboard is empty
Included System Information
CPU: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz
Physical Memory: 31.81GB (12.79GB free)
Processor Architecture: x64
Included Extensions Information
Extensions:
Microsoft.Windows.DevHomeGitHubExtension_<IP_ADDRESS>_x64__8wekyb3d8bbwe
Microsoft.Windows.DevHome_<IP_ADDRESS>_x64__8wekyb3d8bbwe

Duplicate of #742


Remove pre-commit rubocop to avoid discouraging commits

Description
After some thought and experience with this blocking my commits, I've been thinking that we should avoid discouraging commits to this project due to rubocop issues. We can always catch these issues in CI.
Our intentions are to increase commits and contributions, not discourage them. This reverts https://github.com/rubyforgood/human-essentials/pull/2026/files
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?
N/A
Screenshots
N/A

@scooter-dangle @albertchae


Enable WebSocket-based subscribe API

Description
Subscribe API is already defined in the Gateway but not enabled.
Enable it and make sure that it works properly.
Motivation

Subscribe API is essential for notifications in Lisk Desktop

Acceptance Criteria

External clients receive subscribe events on those blockchain events.

new round
new block
new transactions

Development will be continued in #125.


Add JSON Formatter to collect logs for different systems e.g. logstash

This was an issue originally opened on the ZF2 repository.
Link to original: https://github.com/zendframework/zf2/issues/7466
Original post from user sandrokeil:
"I want to send logs from my PHP Docker container to stderr and analyze it with the ELK (elasticsearch, logstash, kibana) stack.
Currently there are different formatters e.g. XML, but a JSON formatter is missing. If we have a JSON Log formatter in ZF2, it gives us the possibility to write standardized plugins for different systems (logstash, fluentd).
Any thoughts or pitfalls for this?"

can be closed in favor of https://github.com/zendframework/zend-log/pull/58


useAppMetafields hook not fetching metafields on first load of 3-page checkout within theme customizer

Please list the package(s) involved in the issue, and include the version you are using
"@shopify/ui-extensions-react": "^2023.7.0"

Describe the bug

This is bug is occuring within the theme customizer. As far as I can tell, the extension is functioning fine in live checkouts.
Metafields are not fetching when using the useAppMetafields hook on the first load of 3-page checkout.
  const appMetafields = useAppMetafields({
    type: "shop",
    namespace: namespace,
    key: key,
  });

After navigating to another page of the checkout (ie. 'Shipping, 'Payment', etc) then coming back to the initial page, the metafield loads.
The extension usually makes a request to a graphql endpoint with operation nameExtensionMetafields, which it is NOT calling on the first load of a checkout page.
The metafield is fetching fine on the first load when on 1-page checkout.
I am using these dynamic extension targets:
purchase.checkout.block.render
purchase.thank-you.block.render
Here are the relevant parts of my toml file:
api_version = "2023-07"

[[extensions]]
type = "ui_extension"
name = "App Name"
handle = "app-name"

[[extensions.targeting]]
module =  "./src/targets/checkout-extension-target.jsx"
target = "purchase.checkout.block.render"

[[extensions.targeting]]
module =  "./src/targets/thank-you-extension-target.jsx"
target = "purchase.thank-you.block.render"

[[extensions.metafields]]
namespace = "metafield_namespace"
key = "metafield_key"

The Shopfy app review team notified me about the issue and it has to be resolved soon or they will remove my app from the app store. 😢
Expected behavior

The metafield should fetch on the first page load.

@elskhn  and @sjanczy2
I updated my initial post to mention that this is bug is occuring within the theme customizer.
The only reason the app review team noticed it was because i use a metafield to determine whether my app block will be visible, and because the metafield isn't loading, the block doesn't show when you first open the editor. The block doesn't show until you navigate to another page of checkout, then navigate back to the initial page, where the metafields finally load.

@elskhn It is simply an empty array.

And you are not seeing AppMetafields  or ActivatedExtensionMetafields graphql queries, correct?

Correct, until I navigate to a different page, then back to the page my extension should show on,
ActivatedExtensionMetafields and ExtensionMetafields are not in the network tab.

Just confirming, is your extension rendering when that first page is loaded?

Hey Sean, we've shipped out a fix for this! Please let us know if you still see any unexpected behaviour.

Thanks @elskhn! It works on my end now and metafields are loading on initial page load of the checkout!


Allow plugins to apply yaml

What this PR does / why we need it:

Allows GO plugins to apply yaml string to create/update resources.
Improves consistency with JS plugins interface.

Which issue(s) this PR fixes

Fixes #1136

Special notes for your reviewer:
Please merge after https://github.com/vmware-tanzu/octant/pull/2774 is merged.

Using Update in api service interface to create and update seems a bit odd. This PR uses update to make the api consistent with JS plugins. It can be argued to have create and update but have similar signatures and underlying implementation which can help with clarity around developers intent.

The breaking changes are a bit too aggressive imo.
Create and Update has error handling for specific cases: e.g. create when the object already exists, update on an object which does not exist
Moreover, the preferred method of fetching objects is through store.Get which returns unstructured objects. The proposed changes here mean a conversion to YAML is required for each update operation.
In theory, one can already do the conversion from YAML via something like k8s.io/client-go/kubernetes/scheme. We could provide abstractions to help with this

I can see why typescript plugins have to do it this way because it is difficult to represent unstructure.Unstructured in https://github.com/vmware-tanzu/plugin-library-for-octant/blob/main/plugin/octant.d.ts#L143 , although in theory possible but hard to validate.

Based on Sam's comments, a new method (ApplyYaml) is introduced in the dashboard client api leaving the Create and Update methods intact avoiding breaking api changes and providing better control for specific actions. Since a string yaml can also be applied using an internal action (https://github.com/vmware-tanzu/octant/blob/71e75e12b05764588d3f0aede455d143e35a3355/internal/octant/actions.go#L25), this will be documented for users.

Some notes:
res, err := request.DashboardClient.ApplyYAML(request.Context(), "default", "apiVersion: v1\nkind: Pod\nmetadata:\n  name: static-web\n  labels:\n    role: myrole\nspec:\n  containers:\n    - name: web\n      image: nginx\n      ports:\n        - name: web\n          containerPort: 80\n          protocol: TCP\n")
if err != nil {
	return err
}

This method of triggering an action requires binding to a component and an understanding of what payload metadata is needed since there is no RunAction rpc call
button := component.NewButton("Create pod", action.Payload{"action": action.ActionApplyYaml, "namespace": "default", "update": "apiVersion: v1\nkind: Pod\nmetadata:\n  name: static-web\n  labels:\n    role: myrole\nspec:\n  containers:\n    - name: web\n      image: nginx\n      ports:\n        - name: web\n          containerPort: 80\n          protocol: TCP\n"})

ApplyYAML returns a slice of strings that seems to be a tokenized message of the server response (e.g. [Updated Pod (v1) static-web in default]) although not documented anywhere


Improve README

With the update to julia version 1.0 and the new Pkg system, this package is inactive. You can still download and use this package, but consider instead using the new packages with updated modules

I have no idea of what are these new packages. Could you please share what is the current state of affairs in SeismicJulia? What is the package that new users should try in Julia v1.0 and beyond? Is there a package for segy IO?

Hi juliohm,
SeismicJulia got split into different packages. In this way, the user doesn't need to load the full library and the project is more approachable.
Functions for SEGY IO are in SeisMain. This would be your entry point to the project.
The exported functions when you load SeisMain are SegyToSeis, SeisRead, SeisReadHeaders, SeisWrite, SeisWriteHeaders, SeisCopy, SeisHeaderInfo, SeisToSegy, SeisRemove. These functions allow you to convert to SeismicJulia internal format, read, write, etc.
SeisProcessing has all the modelling (SeisLinearEvents, SeisParabEvents, etc) and processing tools (SeisFXDecon, SeisNMO, SeisRadon, SeisStack, etc).
SeisReconstruction includes reconstruction capabilities as MWNI, POCS and SpitzFX.
SeisImaging has migration functions based on WEM, EWEM, LSWEM, and PostStack WEM.
SeisAcoustics is a library for wave equation propagation modelling and imaging via FD.
Finally, SeisPlot includes plotting capabilities.
We hope you find the new SeismicJulia project enjoyable. Cheers.

I still think the README needs some work. This information you are sharing here is not available there and users may just avoid the package because they don't know what is the state of affairs. Closing the issue after a long period with it open.


modular.datomic/DatomicConnection doesn't return this on component/start

Hi modular folks,
Just asking here if there is any reason (besides apparently ease to get the connection in one step call) to differentiate this datomic component returning something different to this, in relation other components in modular and stuartsierra/component examples that return this
I received an issue related with this code and only I'm curious about
thanks!
Update:
returning something that doesn't implement IObj limits our app to not use metadata with the related component

That's a bug in modular, not only that you get something unexpected back, you also cannot stop that instance.

Hi @ordnungswidrig
I don't think this implementation is a bug because following stuartsierra/component README it seems that "returning something different from this" is allowed . Also, you can have components that don't need to be stopped even to implement component/Lifecycle

Components which do not need lifecycle can be ordinary Clojure maps

In the specific case of DatomicConnection, we don't need to stop this connection instance either
I think that the only weird thing here is the different pattern used in this case in relation with the rest of modular components

To my understanding everybody expects a component to be restartable, i.e. (-> comp start stop start) should work. So while not required by the component library, is seems to be good style.

Hi @tangrammer you're right regarding datomic connection. This questions the necessity of a "DatomicConnection" component, which can be replaced by a call to d/connect with a configured database url.

Yep! Good explanation
El 23/1/2015 12:09, "Philipp Meier"<EMAIL_ADDRESS>escribió:

To my understanding everybody expects a component to be restartable, i.e. (->
comp start stop start) should work. So while not required by the
component library, is seems to be good style.
—
Reply to this email directly or view it on GitHub
https://github.com/juxt/modular/issues/19#issuecomment-71179039.

Fixed on https://github.com/juxt/modular/pull/20


Add text-to-sound script

Add text-to-sound script 👍🏻
Hope you like it

Thanks for making your contributions

you're welcome 😄  have a good day 🌟


fix: Gitea pr preview

fixes #2757
Adds a check for the $git_type of gitea when running generateGitImportCommands so it checks out the PR instead of the 'main' branch.

Removed the redundant if statement that contained an error and added a logical OR to the Github check as it's working the same way on Gitea. (checked with the commands manually as well)

Ran it on the dev docker compose, I can confirm that it works as expected,

@andrasbacsai could this be part of #2789 by any chance?

Thank you for the PR! It looks good!


Error Property not assegnable fieldconfig.d.ts

Description
After update to Formly 6.3.8 with Angular 18.2.8 when i run build, i have this error:
Error: node_modules/.pnpm/@ngx-formly+core@6.3.8_@angular+forms@18.2.8_@angular+common@18.2.8_@angular+core@18.2.8_rxjs_l7h432ghykbabka76egm4kfqla/node_modules/@ngx-formly/core/lib/models/fieldconfig.d.ts:99:9 - error TS2411: Property 'className' of type 'ExpressionType | undefined' is not assignable to 'string' index type 'ExpressionType'.
Your Environment

Angular version: 18.2.2
Formly version: 6.3.8

Additional context
Same error on this interface:
    className?: ExpressionType<string>;
    hide?: ExpressionType<boolean>;
    'props.disabled'?: ExpressionType<boolean>;
    'props.required'?: ExpressionType<boolean>;

Hi,
I've tested with the latest Angular version but I'm unable to reproduce it.
Could you please provide us your tsconfig / Typescript version and the field config that raise the issue ?
Thank you!

Im experiencing the same issue, here is my tsconfig
{
"compileOnSave": false,
"compilerOptions": {
"baseUrl": "src",
"downlevelIteration": true,
"outDir": "./dist/out-tsc",
"forceConsistentCasingInFileNames": true,
"strict": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"sourceMap": true,
"declaration": false,
"module": "ES2022",
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"importHelpers": true,
"target": "ES2022",
"typeRoots": ["node_modules/@types"],
"lib": ["ES2022", "dom"],
"paths": {
"@core": ["app/core"],
"@core/": ["app/core/"],
"@shared": ["app/shared"],
"@shared/": ["app/shared/"],
"@theme": ["app/theme"],
"@theme/": ["app/theme/"],
"@testing": ["testing"],
"@testing/": ["testing/"],
"@env": ["environments"],
"@env/": ["environments/"]
},
"useDefineForClassFields": false,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true
},
"angularCompilerOptions": {
"enableI18nLegacyMessageIdFormat": false,
"strictInjectionParameters": true,
"strictInputAccessModifiers": true,
"strictTemplates": true
}
}
"typescript": "~5.4.2"

I'm able to reproduce it now, we'll provide a fix soon!

This issue has been fixed and released as part of v6.3.9 release.
Please let us know, in case you are still encountering a similar issue/problem.
Thank you!


Fix issue related zero size buffer

This request fix few issues:

make can not find ../config.h
issue with sero size of buffer (memalign return non-null pointer for zero size)
back to use wc instead of wc_exp

@miked-mellanox or @amirsela could you review and accept


Invalid string to bash in env

I'm not really sure what is the reason but here's what's happening:

cloned the repo
make && sudo make install
run sdb

Then I get the following
/usr/bin/env: ‘bash\r’: No such file or directory

I'm using mono on Linux Mint and my suspicion is that this is a problem with line endings, given Windows's \r\n and Unix's \n.

Ok, I found the solution. It's about all git projects really. When core.autocrlf is set to true then git clones all repos with CRLF even on linux, which obviously breaks stuff.
To fix that one has to change it to core.autocrlf = input (may need manuall .gitconfig alteration).


cfu: generate rsp_valid without using cmd_valid

This PR removes combinational path from cmd_valid to rsp_valid which slightly improves fMax (1-2MHz in recent tests) and FWIW doesn't impact model evaluation time.

@piotr-binkowski  what are the implications of this change?   Combinational CFU operations are no longer allowed?   Or were they not allowed previously?


Documentation - App Web Src - Customize Build

Is your feature request related to a problem? Please describe.
If I wanted to customize the build stage / content of the webapp, is that possible? Imagine I wanted to use a LESS / SASS precompiler or TypeScript, how would I do that?
Describe the solution you'd like
Documentation :-)
Describe alternatives you've considered
I've seen that you can reference code from Node Modules and there's definitely some magic going on, but I am not a fan of cargo cult programming so I was hoping to have some documentation to understand what is happening and how as a developer I can extend it.
Additional context

Hi @klcodanr and thanks for reaching out.
This is not possible yet and we'll be very opinionated in the technical support we provide for the development lifecycle of the first applications.
We have in mind that more flexibility will be required especially on the front-end side in order to surface a larger panel of use-cases, to be addressed by our team in the longer run.
As a short-term solution, you could build your own plugin for the CLI. The drawback would be on the implementation effort, and deviation from our reference app plugin.

@meryllblanchet Makes sense, at some point will there be more docs on what you can do with the current setup?

@klcodanr We have a very first documentation within the CLI repository itself. We're working to provide a more detailed documentation soon.

Closing the issue as we are generally writing the developer documentation on https://github.com/AdobeDocs/adobe-custom-applications.


Disable welcome message for new issues

I find this annoying and propose to disable it. I just don't think this adds any value at all.
The bot's auto-response doesn't make up for lacking human resources to respond to and deal with issues. I'd argue that it makes it worse.
Every message lands in repository watcher's inbox, including mine, I'd rather not have it.
Again feel free to close, just voicing my opinion.

I whole heartedly agree!

I don't feel that strongly about it, partly because I disabled most of the notifications, but I agree more than I disagree. Especially since the instruction to use the issue template is often ignored, and I'm not sure if the template is that useful anyway.

partly because I disabled most of the notifications

Can I ask why you do that? I am slightly surprised to be honest. One of the reasons I want this message gone is precisely because it can encourage people who actually follow development to disable notifications. That means even less chance of getting a response if you are looking for help to isolate a bug or progress a pull request to completion.

I disabled the Kivy repository messages even before this message was added, because I was getting more than I wanted to read anyway, and because I've mostly focused my efforts on python-for-android for quite a while. I do keep a closer watch on the p4a-relevant repositories.
I also still keep an eye on the commit summaries from the irc bot, and regularly interact with issue from there (including this one).

This seems like a straightforward merge to me, but it's been sitting here for 3 months.
I don't really see the point in having it sit around, anyone can make the change if the decision is made, so I'm closing it.
For future consideration, my core arguments are:

There is no message content, it's a clapping hand icon congratulating the user on having filled in a form

Thousands of copies of this pointless message are distributed to repository watchers over a year. It screws up at least some e-mail conversation tracking, making it appear like you have a conversation with welcome[bot]

It deteriorates the website UX, since issues get a comment it looks like someone has responded to it, but you won't know it's the bot until you click the issue.


Pass through -Denv on ant data-import

I've run into this a few times and it makes it quite painful to run a single import with a separate *.properties file. This should fix at least the data-import task.

This work should be obsoleted by https://issues.jasig.org/browse/UP-4591

Yeah, that's definitely a better solution. :-)


Added adder mapping files for yosys

to enable $add/$sub operator mapping to different types of adders
to enable mapping $fa to full adder

Pulled and merged.  I also changed the Makefile.in so that all of the openlane install files common to every digital standard cell library are listed in a variable and looped over, instead of having a separate install command for every one.


Got error when trying to hit the http://localhost:8000/mock (tag: 3.0.0-4)

I got the same error as in this comment: 33
Could @cristichiru take a look? Thank you!

Indeed I left a piece of code in the plugin that I have now removed.
From https://docs.konghq.com/gateway/latest/plugin-development/custom-logic/#migrating-from-baseplugin-module:
You don’t need to add a :new() method or call any of the CustomHandler.super.XXX:(self) methods.

Try 3.0.0-5

Many thanks for the prompt reply!!!
I've tried to run on my localhost and also need to update the function set_consumer(consumer, credential) up to date with this from ldap-auth to run successfully as in this snapshot:

if the warning "Error with Permissions-Policy header: Origin trial controlled feature not enabled: 'interest-cohort'." is not related, I think it's fixed now!


Add other Pages - ContactUs , AboutUs etc

On the top right corner there are some dummy link to pages like AboutUs , ContactUs , Our Products ...
*Add Simple Html, Css , Js Page s and link to these buttons.
Page should be in accordance with the site topic- Its a Traditional Fashion Shopping Site.
Feel Free to be Creative and Experimental !

/prbot how?


time features by default

Hi there,
Would be possible to have a choice between time and chrono of sqlx?
I would appreciate for such opportunities.

It conflicts with originally sqlx/chrono in my code.

If you would like to make a PR that enables either choice, I'm happy to review.

@1g0rkR I dont love how I implemented it but my fork here is working with chrono: https://github.com/vinnymeller/tower-sessions-sqlx-store
as stated in the readme I do not recommend at all using it - but you can at a minimum you can see which part(s) of the code need to be updated to support chrono

maybe something like this? https://github.com/maxcountryman/tower-sessions-stores/pull/46
for me it's becoming critical because of sqlx < 0.8.1 security problem

mostly from @vinnymeller

for me it's becoming critical because of sqlx < 0.8.1 security problem

This is why SessionStore is a public trait. You can and should implement stores to suit your specific use cases and needs.

Is there a way to disable time somehow? Because it causes a circular break with sqlx right now

I found the PR #46 that was reverted in this commit https://github.com/maxcountryman/tower-sessions-stores/commit/3a546a97fe88b7c58d07117e786ce0f13aea403a
I don't understand why, because it just re-broke any setup with sqlx > 0.8.x

Yeah, is there a recommended solution?
I'm also stuck because I need to update sqlx, but this crate then causes time feature dependency to be activated in sqlx

I migrated my ${Something}Row structs to the time crate and made two functions that convert back and forth between chrono and time.
This is not great but was the pragmatic path out of the stuck situation

Probably the feature selection can be removed entirely and replaced with something like this: https://github.com/maxcountryman/underway/blob/40f8f899587cb0125e2b8897a4349d2f9c0a391d/src/timestamp.rs which then is used in the crate here as a type override (note that this is particularly ugly in the linked example, but in practice could be cleaned up).  Doing so allows e.g. https://github.com/maxcountryman/underway/blob/40f8f899587cb0125e2b8897a4349d2f9c0a391d/Cargo.toml#L15-L19.


AttributeError when trying to save report

When saving a report using
data_drift_report.save("/dbfs/FileStore/drift/drift_report.html")
I get
AttributeError: 'DataDriftTableWidget' object has no attribute 'wi'
caused by
/databricks/python/lib/python3.8/site-packages/evidently/widgets/data_drift_table_widget.py in get_info(self)
25
26     def get_info(self) -> BaseWidgetInfo:
---> 27         if self.wi:
28             return self.wi
29         raise ValueError("no widget info provided")
I'm using azure databricks, and can save the json profile, and get the same error if I use data_drift_report.show(), though I never installed nbextension.
I can save the iris report, and am using numerical and categorical feature mappings.

I had the same issue when I forgot to include the prediction key in the column_mapping dictionary.

@Chien10 thanks for helping out!

Including prediction didn't help, and I was only running a data drift report.

Hi @lrumanes, could you share 1) a snippet of how your pandas dataframe looks for reference and current datasets (e.g. a header and 1 line of data) 2) a line of code where you run the calculate function?

This appears to have been caused by encoding the categorical data incorrectly.  Is there any way to pass a map of the original values of the data in so column values display in the graphs in admit_data_drift_report.save and admit_data_drift_report.show?

Hi @lrumanes, apologies for taking the time to get back to you here!
We tried a bunch of combinations but where unable to reproduce the error. Our best guess for now is that there is some error on the dataframe side or e.g. in column mapping.
Could you share the snippet of your code where you specify the column mapping and call the "calculate" command? If it is not sensitive, ideally with a preview of your dataframe (just 2-5 lines would do). You can also send it to email<EMAIL_ADDRESS>or privately in our Discord channel https://discord.gg/xZjKRaNp8b

This appears to have been caused by encoding the categorical data incorrectly. Is there any way to pass a map of the original values of the data in so column values display in the graphs in admit_data_drift_report.save and admit_data_drift_report.show?

yes, this is still an open issue. Unfortunately, at the moment there are no ways to pass a map for categorical data encoding.
However, we already working on this issue in PR: https://github.com/evidentlyai/evidently/pull/113
Hopefully, this will be fixed soon enough and all Dashboards will work correctly with categorical data without encoding.


Promise.all indexing issue when combining non-zone.js promises

When you use Promise.all for combining not only zone.js promises (e.g. WinJSPromise) you can fall into issue that Promise.all results into single element result.
Example of issue https://plnkr.co/edit/UO2QhIa5eeLm6tPAyAjt?p=preview.
Important part of the code(skipping WinJSPromise import) is this one:
  let p1 = WinJSPromise.as(3);
  let p2 = Promise.resolve(45);
  Promise.all([p1, p2]).then(res => {
    console.log(`Promise.all: `, res);
  })
  WinJSPromise.join([p1, p2]).then(res => {
    console.log(`WinJSPromise.join: `, res);
  });

The output from Promise.all is [45], where expected is [3, 45]. This works fine with native Promise.all.
Problem is in how index is counted in this implementation:
https://github.com/angular/zone.js/blob/c8c599073b87025d44a4b7d6e2efea9cedfbd3e2/lib/common/promise.ts#L305-L331
Following update implementation fixes the issue (note the index variable missing in original version):
Promise.all = function (values: any): Promise<any> {
    let resolve: (v: any) => void;
    let reject: (v: any) => void;
    let promise = new this((res, rej) => {
      resolve = res;
      reject = rej;
    });
    let count = 0;
    let index = 0;
    const resolvedValues: any[] = [];
    for (let value of values) {
      if (!(value && value.then)) {
        value = this.resolve(value);
      }
      value.then(
          ((index) => (value: any) => {
            resolvedValues[index] = value;
            count--;
            if (!count) {
                resolve(resolvedValues);
            }
          })(index),
          reject);
      count++;
      index++;
    }
    if (!count) resolve(resolvedValues);
    return promise;
}

This issue was found and discussed a bit here

@taras-mytofir , thank you for posting the issue, I will check it.

@taras-mytofir , could you provide a reproduce repo?
I just added a test case like this.
            const otherPromise: any = {
              then: function(thenCallback: (value: string) => any) {
                thenCallback('otherPromise');
              }
            };
            Promise.all([Promise.resolve('resolution'), otherPromise]).then((v: any) => value = v);
            expect(value).toEqual(['resolution', 'otherPromise']);

And the test passes.

@JiaLiPassion example with one promise as WinJSPromise:
https://plnkr.co/edit/biopXhYkyxK9hhmQxlVh?p=preview

@taras-mytofir, the code you provided failed because WinJSPromise not following the Promise Spec which was described  here https://promisesaplus.com/#point-67, promise.then should make sure run in async way, so the callback which was passed into then should not run in the current tick turn.
So I think you should report bug to WinJSPromise. Or you can patch WinJSPromise just like this https://plnkr.co/edit/yUVkEdTecvc0jKO8fqdG?p=preview (BTW, this is just a quick patch, just to describe the idea).

I see, thanks for looking into this!

This problem also occurs on the API of the Universal Windows Platform. Although WinJSPromise and UWP API do not follow Promise spec. But in order to avoid confusion for developers, making the performance of ZoneAwarePromise the same as native Promise, is it a better choice?
For example, the test case(non standard Promise) below:
class MockPromise {
    constructor(value) {
        this.value = value;
    }
    then(resolve, reject) {
        resolve(this.value);
    }
}
var a = new MockPromise('a');
var b = new MockPromise('b');
Promise.all([a,b]).then(values=>console.log(values));

For native Promise, the result is
["a", "b"]

For ZoneAwarePromise, the result is
["b"]


wcoin

Please note: This repository is being rebuilt to accept the new volume of token additions and modifications. PR merges will be delayed.

I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
This repository is managed using an auto merge action. Please ensure your PR has no deleted lines, and it will be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address:
Token Name:
Token Symbol:
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>)
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

Auto merge requirements
Your pull request will be automatically merged if the following conditions are met:

Your pull request only adds new tokens to the list. Any modification to existing
tokens will require manual review to prevent unwanted modifications.

Your pull request does not touch unrelated code. In particular, reformatting changes to unrelated
code will cause the auto merge to reject your PR.

Any asset files added correspond to the token address you are adding. Asset files
must be PNG, JPG or SVG files.

Your change is valid JSON and conforms to the schema. If your change failed validation,
read the error message carefully and update your PR accordingly.

No other tokens shares the same name, symbol or address.

For example, this change would be rejected due to unrelated changes:

The bot runs every 60 minutes and bulk-merges all open pull requests to prevent conflicts.
This means that you need to wait up to 60 minutes for your pull request to be merged or reprocessed.

I can help refer this zakimzf/profile#1
PS: if you don't need my help.. please ignore this!

Please do!

Read the PR that i linked in the above message then if you are still
interested then contact me on telegram @zakimzf
On Wed, 16 Feb 2022, 1:46 pm Theozac, @.***> wrote:

I can help refer this zakimzf/profile#1
https://github.com/zakimzf/profile/pull/1
PS: if you don't need my help.. please ignore this!
Please do!
—
Reply to this email directly, view it on GitHub
https://github.com/solana-labs/token-list/pull/18846#issuecomment-1041226677,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQAH7M7CHJF7Z6GNVHXHTUTU3NMPTANCNFSM5OPX4OUA
.
You are receiving this because you commented.Message ID:
@.***>

May I have some help with this PR please! 🙏

Contact me on telegram @zakimzf
On Fri, 18 Feb 2022, 5:12 pm Theozac, @.***> wrote:

May I have some help with this PR please! 🙏
—
Reply to this email directly, view it on GitHub
https://github.com/solana-labs/token-list/pull/18846#issuecomment-1044386588,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQAH7M7VCHDCRF3W762BU4DU3YWD5ANCNFSM5OPX4OUA
.
You are receiving this because you were mentioned.Message ID:
@.***>


convert_addresses updates

This just upstreams a couple of things that've drifted over the past year or so.
More generally @owen9825 @Gnippots I find that in user submitted data there's... quite a bit of variation in how people will fill in their street names. The AEC form certainly doesn't require that the normalisation be done beforehand but some abbreviations might not get picked up? So consider using this.

After ~100 checks, I agreed with Andrea that we'd contact people anyway, even if their details matched, as a way of confirming their membership. So I no longer have a need to support the NationBuilder columns :/


docs(snap): Move usage instructions to docs

Usage instructions are being moved to docs; see https://github.com/edgexfoundry/edgex-docs/pull/751.
The snap/README has been updated to include development docs only.
Depends on:

https://github.com/edgexfoundry/edgex-docs/pull/751

Signed-off-by: Mengyi<EMAIL_ADDRESS>

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/app-rfid-llrp-inventory/blob/main/.github/Contributing.md
PR Checklist
Please check if your PR fulfills the following requirements:

[x] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
[x] I am not introducing a new dependency (add notes below if you are)
[ ] I have added unit tests for the new feature or bug fix (if not, why?)
[ ] I have fully tested (add details below) this the new feature or bug fix (if not, why?)
[x] I have opened a PR for the related docs change (if not, why?)

Testing Instructions

New Dependency Instructions (If applicable)

@lenny-intel @ajcasagrande could you please review and squash+merge it? thank you!


Tarjan's algorithm

Is your feature request related to a problem? Please describe.
It is used to find strongly connected components of a directed graph.
Describe the solution you'd like
It involves only one DFS traversal, unlike Kosaraju's algorithm. The DFS search produces a dfs tree and the SCCs form the subtrees of the dfs tree. Then we find the lowlinks for every node.
Do you want to work on it
I can code in C++ and Java. Please assign this issue to me. I am a GSSoC participant

present at #1296


[WIP]add contrastive learning baseline SimCLR and its linear prob with FS

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


User view in groups detail is misaligned

Describe the Issue:
The user view for individual user in groups has a misalignment which makes the view crooked.

How To Reproduce:

Add a user to an existing group or a new group
view the users in group detail view

Expected behavior:
Should properly align to edges
Environment information (Please complete the following information; remove  any unnecessary fields) :

Product Version: [e.g., IS 5.10.0, IS 5.9.0]
OS: [e.g., Windows, Linux, Mac]
Database: [e.g., MySQL, H2]
Userstore: [e.g., LDAP, JDBC]

Optional Fields
Related issues:

Suggested labels:

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


(PUP-8850) Remove macauthorization, mcx and computer

These types and providers now live in the macdslocal_core module.

There isn't a corresponding "Add to puppet-agent" PR, as we're not adding the types and providers back.

Forgot to remove types from pops.

jenkins please test this

CLA signed by all contributors.


[Feature request] Browser Extensions

@dni are you considering Nostr Wallet Connect as well? Something that Alby asked for


Allow existingJavaType to take precedence over $ref

In the scenario where both existingJavaType and $ref are set on the same schema node, the creator of the schema intends to rely on an existing Java type for the code generation, but still wants to refer a schema for documentation and interoperability purposes.
Therefore, from code generation standpoint, existingJavaType takes precedence, and $ref is ignored.
Resolution of ref at property level is not needed in that scenario.

It depends on a schema version. Most versions don't accept any overrides along $ref.


Issues in dualgcn_bert.py

Hi bro, when I train the model: dualgcn_bert, there has an error at line "adj_ag /= self.attention_heads"

I got the following RuntimeError:
RuntimeError: Output 0 of SqueezeBackward1 is a view and is being modified inplace. This view is an output of a function that returns multiple views. Inplace operators on such views is forbidden. You should replace the inplace operation by an out-of-place one.
How do I fix it?
Thx！

adj_ag = adj_ag / self.attention_heads


Add automated accessibility tests

The accessibility team recommended setting up automated testing for accessibility. alphagov/govuk-frontend uses axe but there are other options like tenon
This would be useful for developing tech-docs-gem, but also for technical writers in each implementation of tech-docs-template.

We previously trialled tenon, we'd be happy to talk about the pros and cons of both options.


add currency in cospend

Since projects in Cospend have currencies now, would be instrumental to have currency (default one and override) at bill level in PayForMe.
Makes a lot of sense as this app is very useful when travelling abroad with friends.

good point, but as I am not working in app development anymore and not actively using PayForMe/Cospend myself, I personally will only spend time in keeping the current functionality intact as good as I can.


Set a different property name for children

Thanks for this amazing Library!
I do not have control over the JSON data from the server. Is it possible to have an option set a different property name for children objects like below?
const treeData = [   { text: 'Item 1', state: { visible: false } },   { text: 'Item 2', state: { selected:    { text: 'Item 3', children: [     { label: 'Item 3.1', state: { disabled: true } },     { label: 'Item 3.2', state: { selectable: false } }   ]}   // and so on ... ]
Thanks

Yes liqur allow this.  read docs.
https://amsik.github.io/liquor-tree/#Redefine-Structure-Example

Thanks @Diaskhan


Multiple charts freeze Firfox tab with maintainAspectRatio: false

Expected behavior
User can change width of browser window showing multiple charts that were created with maintainAspectRatio: false option.
Current behavior

Open this demo in Firefox: https://codepen.io/evgenyneu/pen/poQXENO
Gradually change the width of the window.
At some point the plot width no longer changes, the plots no longer redraw and become non-interactive (the marker tooltips are not shown on hover) and vertical scoll bar not moving with the window.
If you refresh the page, it shows a spinner instead of the plots.
If you open another tab and then return to the plots tab, it shows a spinner in the middle instead of the plots.

Video:
https://github.com/chartjs/Chart.js/assets/880411/fc7438ca-8e19-421e-9e7e-4698bbd04d55
Reproducible sample
https://codepen.io/evgenyneu/pen/poQXENO
Optional extra steps/info to reproduce
No response
Possible solution
No response
Context
No response
chart.js version
v4.3.3
Browser name and version
Firefox 116.0.2 on m1 mac
Link to your project
No response

Pasting the HTML code that reproduces the problem
<script<EMAIL_ADDRESS>
<script>
  let charts = 10;

  const makeData = (points) => {
    return Array.from({ length: points }, (v, i) => {
      return {
        x: i,
        y: Math.random()
      };
    });
  };

  for (let i = 0; i < charts; i++) {
    var htmlContent = `<div><canvas class="Chart${i}"></canvas></div>`;
    document.body.innerHTML += htmlContent;
  }

  for (let i = 0; i < charts; i++) {
    new Chart(document.querySelector(`.Chart${i}`), {
      type: "line",
      data: {
        datasets: [
          {
            data: makeData(10)
          }
        ]
      },
      options: {
        animation: false,
        maintainAspectRatio: false,
        scales: {
          x: {
            type: "linear"
          },
          y: {
            type: "linear"
          }
        }
      }
    });
  }
</script>

I'm stuck with the same problem. Only on Firefox though (tested on MacOS), in Chrome everything's fine. It seems that the rendering of the browser pane freezes. Links don't work anymore, reloading doesn't help, you really have to close the tab and open a new one.
I've discovered it in a dashboard I made, but also on this sample page:
https://chartjs-plugin-crosshair.netlify.app/samples/
It's not related to that plugin, however.
It seems that the more charts are on the page, the more likely it is to evoke the freeze by resizing the window. If I have only 1-2 charts, I really need to abuse the window and quickly and repeatedly make it narrow and wider.

Same issue here, I can reproduce the issue with my own code since a few days. It seems to be an issue with Firefox 116 on MacOS. I can't reproduce the bug on Firefox 103 for MacOS and even in Firefox 116 for Linux it's working fine.

I was even able to reproduce it on the startpage of ChartJS.
https://github.com/chartjs/Chart.js/assets/15139137/acc992bc-f5fa-445e-912e-22751b7b6383
I also noticed that the pages that freeze are still "alive" in background. If you know where buttons and links are positioned, you are still able to click them and navigate through pages, but you don't see anything. I can even navigate to other pages and then press CTRL+A and then CTRL+C to copy the content of the new page, but still see the content of the frozen page.

I'm new to chart.js but I have seen this on Linux (Fedora 38, using Wayland) so its not macOS specific.

As github already mentioned above, I reported this issue in the web-bugs repository, because it has nothing to do with ChartJS itself, it has to be a bug in Firefox. The web-bugs team were able to reproduce the issue and are currently working on it.


How I can avoid "test connection to the authentication endpoint"

Hi,
I am receiving a following open ssl error. However, the rundeck service is up and running and I am able to access it on port 4443.
Is there a way to dodge/fix this check ?
"================================================================================
Error executing action run on resource 'ruby_block[wait for rundeckd startup]'
================================================================================
  OpenSSL::SSL::SSLError
  ----------------------
  SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol

  Cookbook Trace:
  ---------------
  /home/chef-repo/.chef/local-mode-cache/cache/cookbooks/rundeck/resources/server_install.rb:351:in `block (3 levels) in class_from_file'

  Resource Declaration:
  ---------------------
  # In /home/chef-repo/.chef/local-mode-cache/cache/cookbooks/rundeck/resources/server_install.rb

  343:   ruby_block 'wait for rundeckd startup' do
  344:     action :nothing
  345:     block do
  346:       # test connection to the authentication endpoint
  347:       require 'uri'
  348:       require 'net/http'
  349:       uri = URI("#{new_resource.grails_server_url}:#{new_resource.grails_port}")
  350:       uri.path = ::File.join(new_resource.webcontext, '/j_security_check')
  351:       res = Net::HTTP.get_response(uri)
  352:       unless (200..399).cover?(res.code.to_i)
  353:         Chef::Log.warn { "#{res.uri} not responding healthy. #{res.code}" }
  354:         Chef::Log.debug { res.body }
  355:         raise
  356:       end
  357:       Chef::Log.info { 'wait a little longer for Rundeck startup' }
  358:       sleep new_resource.extra_wait
  359:     end
  360:     retries new_resource.retries

  Compiled Resource:
  ------------------
  # Declared in /home/chef-repo/.chef/local-mode-cache/cache/cookbooks/rundeck/resources/server_install.rb:343:in `block in class_from_file'

  ruby_block("wait for rundeckd startup") do
    action [:nothing]
    default_guard_interpreter :default
    declared_type :ruby_block
    cookbook_name "ganga"
    block #<Proc:0x0000000004dea540@/home/chef-repo/.chef/local-mode-cache/cache/cookbooks/rundeck/resources/server_install.rb:345>
    retries 60
    retry_delay 5
  end

"

I have updated the grails url to "https://localhost" and port to "4443" which is open for the network.
Now I am getting an error related to certificate
  ================================================================================
  _Error executing action `run` on resource 'ruby_block[wait for rundeckd startup]'
  ================================================================================

  OpenSSL::SSL::SSLError
  ----------------------
  SSL_connect returned=1 errno=0 state=error: certificate verify failed (self signed certificate)

  Cookbook Trace:
  ---------------
  /home/chef-repo/.chef/local-mode-cache/cache/cookbooks/rundeck/resources/server_install.rb:351:in `block (3 levels) in class_from_file'_

Issue has been fixed by updating the port to 80 and url to http://localhost.

I am re-opening this ticket because of the following reason.
Rundeck went through start up script when I have provided the grailsURL : http://localhost and port 80 but for production purpose we need to set the grailsURL to "https://rundeck.nrhl.com" and port to "4443".
Unfortunately, providing these values resulting in open ssl error as mentioned above.

Assuming that you aren't using the Apache front end, are you setting use_inbuilt_ssl?

@PowerSchill I haven't defined "use_inbuilt_ssl" in my recipe and not using Apache too.

I think use_inbuilt_ssl is needed to do ssl when not using Apache but not really sure since I do Apache. I will see if I can set up a test for it.

I have set use_inbuilt_ssl  to true and tried, which complained the following error
  OpenSSL::SSL::SSLError
  ----------------------
  SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol

Updated the NGINX confi to support TLS, which fixed the issue.
Thanks for co-ordinating and providing the required information @PowerSchill


[6.0] Runtime checking for associated types conforming to invertible protocols

Emit metadata for runtime checks of conformances of associated types to invertible protocols, e.g., T.Assoc: Copyable. This allows us to correctly handle, e.g., dynamic casting involving conditional conformances that have such constraints.
The model we use here is to emit an invertible-protocol constraint that leaves only the specific bit clear in the invertible protocol set.
https://github.com/apple/swift/pull/72788

@swift-ci please test


Changed the 2 assets urls to vercel instead of Zeit

asset urls work fine as vercel.com aswell.

Thanks for PR and astute observation!
We left this URL as-is because we needed a new image first.
The image has been updated in #4278 so I'll close this PR.