Prepare for 0.4.7 release

Current changeset since 0.4.6
It's been a while since we've done a release and there's a few things sitting on master that people want to be able to use.
I've added a note to our current structured logging stuff so it's clear that we're not committing to exactly what's there stability-wise. There are hoops we could make users jump through to access that API besides an unstable feature gate, but that didn't seem really necessary to me.

Asking the obvious: Given the new albeit non-default kv_unstable feature, from standard SemVer perspective, shouldn't this be released as 0.5 instead? Consider that any logging implementations or applications that enable kv_unstable  will need to specify a minimum of 0.4.7 for the log crate (which, as its a patch version, can be easily missed without minimum-version testing).
Looking at the changes since 0.4.6 there are also a bunch of pure-fixes that are justifiably in a 0.4.7 patch release.  Should those be at least released first/separately for the sake of reserving a strict SemVer patch, in any case?
I do realize that releasing as 0.5, could cause other problems with cargo resolution of duplicate versions of log. This the standard justification for core rust crates releasing new features, or potentially breaking changes, in patch releases.

In Rust semver, 0.x.y versions treat y as the major version number, which is only incremented for breaking changes.

As exemplified by the phrase "Rust SemVer", if everyone has there own unique definition, then there is no useful convention. Is your definition, @sfackler,  somehow compatible with the below?
https://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

(From this, kv_unstable should be a MINOR version change)
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements

This compatibility convention is different from SemVer in the way it treats versions before 1.0.0. While SemVer says there is no compatibility before 1.0.0, Cargo considers 0.x.y to be compatible with 0.x.z, where y ≥ z and x > 0.

Rust semver is indeed different from semver.org. Below 1.0 we bump the MINOR for breaking changes and the PATCH for nonbreaking changes.

Over simplifying doesn't help your argument.  It pretty common, for rust crates in general, to put new features such as this kv_unstable, in a new MINOR (aka 0.5.0).
Now maybe the fair answer is that for a core crate such as log; which though generally a private dep, breaks with duplicate versions, and that for such a new non-default feature, its just not worth the effort to bump the release to 0.5.0 and force a large area of the ecosystem to upgrade.
Still begs the question if the fully legitimate PATCH fixes should be released as 0.4.7, first.  It could be a useful release (and reserved releases number) if kv_unstable 0.4.8 or 0.5.0 breaks something.

It pretty common, for rust crates in general, to put new features such as this kv_unstable, in a new MINOR (aka 0.5.0).

That does not match my experience in any crate I'm aware of.

Me either. If a crate hasn't hit 1.0 yet, then I treat MINOR as if it were a MAJOR, and squash MINOR and PATCH into PATCH, effectively. This, of course, being motivated by "Rust SemVer."

Crates clap (including when < 1.0.0), actix(-web), and hashbrown come to mind, having examples of (likely) compatible features queued for release in new MINOR versions.  Its true that pre-1.0, this is sometimes overshadowed by the fact that maintainers also have clearly breaking changes queued to introduce on the next MINOR (which is legal pre-1.0).
I think this is a fair question (should it be released as log 0.5.0) because once some dependency turns on a feature gate like kv_unstable, there is no turning it off.   No one has claimed this couldn't be released as 0.5.0, so please make that case that its not worth the trouble to do so, vs. just releasing all queued changes as 0.4.7.

There is no good reason, as far as I can see, to put out a breaking change release just because an unstable feature has been added.

The usual, general reason as to why SemVer assigns compatible new features to MINOR releases, and more specifically here:

In case enabling the kv_unstable feature (for example, enabled by some log implementation, in its new PATCH release) breaks some projects in an unforeseen way.  Releasing it as MINOR version bump clearly makes less compatibility claims, and gives some opt-in time/flexibility downstream.

Would preserve 0.4.x versions for currently queued (on master) and future clear PATCH fixes

Again, I'm not saying that this justifies the effort or other downsides to releasing as 0.5.0, but only that its possible and could have advantages.

@dekellum I mostly agree with the points you're making, but can we be a bit pragmatic about this? It's a fairly minor, unstable feature that doesn't impact a great deal of code (outside the added module itself). Log is a crate used throughout the Rust ecosystem and updating all those crates is just a pain and not worth the effort my opinion. Crates that depends on this unstable feature can specify log = ^0.4.7 as dependency and all others will continue to work.

Hi @dekellum :wave: that is a valid point, and we are very careful about how we version this library.
For all intents and purposes, consumers of log should pretend the kv_unstable feature and the kv module don’t exist yet. There are a few competing needs that have been balanced into this approach:

We can’t just land an API like structured logging support in a single go. It’s pretty much guaranteed that it’ll need big changes based on user feedback.
We want people to contribute to the design and implementation of the structured logging support, and that’s much easier to do if the code lives on master where other contributions are made.
We want people to try structured logging support. There are users who are happy to jump on the breakage bandwagon from crates.io because they’re looped in to the development process.
We don’t want to block on-going maintenance of log itself on this new work. There’s a steady stream of contributions made that shouldn’t be held up by whatever state the unstable work is in.

We could make the unstable work harder to get at, which would prevent users from stumbling across it, but would also create contribution barriers. I’m open to new perspectives though!

In case its not clear, I agree that you should be able to comfortably/safely make log crate releases for preview and evolution of the structured logging feature. Its only a question of how.

that is a valid point, and we are very careful about how we version this library.

Yes, so careful, that 0.4.0 should have been released, or some 0.4.x should be re-released as 1.0.0 (1).  Beyond being a correct representation of the practical state and expectations on this crate, it would not be a question that releasing new features should be done in a new MINOR, right?
But perhaps structured logging is also viewed, ironicly, as the single missing feature to be stabilized for that precious 1.0.0 release?  So how can we proceed, version wise?

For all intents and purposes, consumers of log should pretend the kv_unstable feature and the kv module don’t exist yet. [...] It’s pretty much guaranteed that it’ll need big changes based on user feedback.

Good intentions. So your current plan is to release a series of 0.4.7+ patch releases interleaved with evolving changed to the non-default feature and normal maintenance and legitimate PATCH changes.
But structured logging is indeed a useful feature. How long before a logging implementation enables kv_unstable by default?   The enabled feature adds public fields to the core log::Record struct and builders, and interestingly, also raises the minimum supported rust version (MSRV) from 1.16.0 to 1.21.0.
Meanwhile there is no direct Cargo support for crate MSRV, much less crate×feature MSRV nor "unstable" features.  This 0.4.z PATCH versioning plan seems to be bending a lot of well established conventions, beyond just SemVer, to avoid bumping the MINOR version.
Proposed alternative
Release this as 0.5.0 or, if you prefer, 0.5.0-alpha.0.
In this plan, I don't suggest hiding it behind a non-default feature gate. Any lib crates with a log dependency (including log output implementions) can, in new MINOR or MAJOR series release, choose to actively use kv by depending on '^0.5' or to passively allow that use (even in a PATCH release) by depending on log version `>=0.4.6, <0.6".
This, folks, is how SemVer is supposed to work.
And I offer my help, here or elsewhere, in addressing whatever rust-specific, weirdly-situational or self-inflicted challenges that make this hard to pull off or overly onerous.
(1) https://semver.org/#how-do-i-know-when-to-release-100

How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

There are hundreds if not thousands of crates that directly depend on log. It is profoundly unreasonable to force every single one of them to go manually push their version constraints forward every time we add a new feature to log.
If you want to change the way that Cargo and the broader Rust ecosystem think about 0.x.y versions, that conversation should probably be held in a broader forum than a PR in a single crate's repo.


Reorder account signup form

People were having trouble with automatically entering password verification in blog title field. This re-orders the form to a more "normal" flow where password field is the last item on the page, so no risk of double-typing it.
Closes https://github.com/TryGhost/Ghost/issues/8622 by inadvertent knock-on effect.

Coverage remained the same at 73.106% when pulling 281fd2f670548716ed8fef339ed88aef88238d73 on JohnONolan:reorder-signup into a0de451961172bc0edc1af8ad8d7acc16d443c09 on TryGhost:master.


Generate a Foyer XML from a parameterized ParmEd Structure

This PR introduces a new method to the ParmEd Structure, write_foyer, that allows a parameterized Structure to be written to a Foyer XML. This addresses #71, and should be useful for archiving/documenting the specific force field parameters used for a particular system (particularly if parameters were obtained from a large Foyer XML such as OPLS). This could also prove useful if Foyer XMLs are used by simulation engines such as HOOMD to read force field parameters (so that these do not need to be manually specified by the user).
I wasn't sure exactly where this function best fit into the code base. I think having this be a method of Structure makes sense, rather than as a method of Forcefield and requiring the user to pass a parameterized Structure as an argument. In this case we could of course file a PR to ParmEd, but I like the idea of keeping this within Foyer so we can more easily make modifications if/when needed. The function does have the option to pass a Foyer Forcefield as an argument, as this provides access to additional information for the AtomTypes section (e.g. atom classes, SMARTS definitions) that are not stored within Structure. Another optional argument, unique, is available that allows the user to specify whether only unique atom, bond, etc. definitions should be written to the XML, or if a definition should be written for each atom, bond, etc. instance within a system (more on this later). If a Forcefield is passed to this function the resulting XML should be able to successfully re-atomtype the system, yielding the exact same parameterization. I will need to set up some unit tests to ensure this is actually the case, but wanted to go ahead and get the PR started.
Back to the unique argument. Another, and perhaps more significant, use-case for the write_foyer function concerns the testing of Foyer XMLs for correct parameterization (this is based on a conversation that @chrisiacovella, @justinGilmer, and myself had last week). Currently we are testing Foyer XMLs on "test" molecules by comparing atomtypes assigned by the force field to those contained within a MOL2 or Gromacs TOP file that has been provided by the user (i.e. these contain the known, correct types). However, we do not have a good way to test if bonds, angles, etc. are being properly assigned. I believe a solution to this problem is to compare Foyer XMLs in an expanded format that contains definitions for each atom, bond, etc. within a system (thus describing the full system topology, as would be found within a Gromacs TOP file). This can be achieved with write_foyer by providing unique=False, which, for example, creates a NonbondedForce definition for each atom (where id is added as an additional attribute representing the atom ID) :
<Atom id="0" type="opls_135" charge="-0.18" sigma="3.5" epsilon="0.276144"/>
and, e.g., creates a HarmonicBondForce definition for each bond that contains the appropriate atom IDs:
<Bond id1="0" id2="3" type1="opls_135" type2="opls_140" length="0.109" k="284512.0"/>.
If we replace the MOL2 and TOP files we are currently using for test molecules with these expanded Foyer XMLs, we can easily parse these with ElementTree and compare not only atomtype information, but all bond, angle, etc. parameterization as well.
Usage of write_foyer is pretty straightforward. Here is an example where a Foyer XML is written for an ethane molecule created with mBuild:
ethane = Alkane(2)
opls = Forcefield(name='oplsaa')
ethane_a = opls.apply(ethane)
ethane_a.write_foyer('from-structure.xml', forcefield=opls)

and here is the resulting XML:
<ForceField>
  <AtomTypes>
    <Type name="opls_135" class="CT" element="C" mass="12.01078" def="[C;X4](C)(H)(H)H" desc="" doi="10.1021/ja9621760"/>
    <Type name="opls_140" class="HC" element="H" mass="1.007947" def="H[C;X4]" desc="" doi="10.1021/ja9621760"/>
  </AtomTypes>
  <NonbondedForce>
    <Atom type="opls_135" charge="-0.18" sigma="3.5" epsilon="0.276144"/>
    <Atom type="opls_140" charge="0.06" sigma="2.5" epsilon="0.12552"/>
  </NonbondedForce>
  <HarmonicBondForce>
    <Bond type1="opls_135" type2="opls_135" length="0.1529" k="224262.4"/>
    <Bond type1="opls_135" type2="opls_140" length="0.109" k="284512.0"/>
  </HarmonicBondForce>
  <HarmonicAngleForce>
    <Angle type1="opls_135" type2="opls_135" type3="opls_140" angle="1.932079482" k="313.8"/>
    <Angle type1="opls_140" type2="opls_135" type3="opls_140" angle="1.8814649337" k="276.144"/>
  </HarmonicAngleForce>
  <RBTorsionForce>
    <Proper type1="opls_140" type2="opls_135" type3="opls_135" type4="opls_140" c0="0.6276" c1="1.8828" c2="0.0" c3="-2.5104" c4="0.0" c5="0.0"/>
  </RBTorsionForce>
</ForceField>

A few other things to note:

As shown in the above XML, I don't think we are parsing the desc argument properly. I am grabbing this directly from Forcefield.atomTypeDesc and this always seems to be an empty string.
An additional argument should be added to apply (and also to mBuild.Compound.save) to allow a Foyer XML to be written at the time the forcefield is applied.
I have a feeling this block of code could be written in a more Pythonic manner, but I've struggled to find a better solution.
We need to properly document the rounding that is used for each parameter. I basically just used rounding based on the parameters we have defined in the OPLS forcefield XML.
I need to add coulomb14scale and lj14scale attributes to NonbondedForce. These are stored somewhere within the parameterized Structure, but their location is not obvious...
write_foyer currently considers bond, angle, etc. definitions to be unique if the tuple of involved atom types is unique. The resulting XMLs could be condensed if we grouped parameters using atom classes. Since we have access to the class for each atomtype if a Forcefield is passed using the forcefield argument, I think that grouping parameters by class is something that should be doable.

Big picture question: If you guys are working with ParmEd structures, is this a potential entrance route for other force fields into foyer? e.g. can a "port" of a force field or subset of a force field be made into Foyer using ParmEd? Or are you doing something different here?
We should probably have another call with you guys soon. We now have a working SMARTS/SMIRKS-based force field that basically covers all drug-like chemical space with very small exceptions (more coverage than GAFF and parm@Frosst) that we've validated fairly extensively; I imagine it would be easy for you to get this into the Foyer format. And work you are doing with Foyer may also connect up with what you are doing.
If you'd like I can provide a link to a preprint very soon (hopefully it will be up today/tomorrow).

@davidlmobley Yes, this function should serve a few purposes, but one of those certainly will be aiding users with porting their force fields into Foyer's format (via ParmEd). From a parameterized ParmEd structure, the user should be able to use write_foyer to produce a complete Foyer XML that is missing only a few attributes in the AtomTypes section (e.g. def, desc, class), which would need to be addressed manually (we've discussed adding a routine into Foyer to "guess" SMARTS strings, so if/when that is implemented it could be merged with this function as well).
Of course the primary hurdle here is obtaining the parameterized ParmEd structure, but that should not be a problem in the case of your force field, so yes with the help of this function we should hopefully be able to pretty easily convert your force field into Foyer's format, and it would be a welcome addition. If you don't mind providing the preprint link once it's available I would definitely be interested in checking it out. A call in the near future to further discuss this certainly seems like a good idea.

Preprint is up! https://doi.org/10.1101/286542 Please feel free to share; happy to discuss when you guys are ready.

And for a one-stop quick peek inside, see https://github.com/openforcefield/smirnoff99Frosst/blob/master/smirnoff99Frosst/smirnoff99Frosst.offxml

Sometimes we use parmed classes that inherit from pmd.Structure. As I understand their use, it is preferred to stay in the other classes and not convert back to pmd.Structure (actually, I'm not even sure you can). To get this function to work with those classes, we would need to add this function to each of them
pmd.Structure.write_foyer = write_foyer
pmd.amber._amberparm.AmberParm = write_foyer
pmd.gromacs.GromacsTopologyFile = write_foyer

and probably more. This seems not-so-preferred. But I'm not sure a better approach.
I encountered this when trying to convert the force field information in a .prmtop file to a foyer XML.

One way to get around this technical limitation is to simply write this function to accept a pmd.Structure instead of implementing it as a method.

Anything blocking this from being merged?
P.S. this is an interesting example of adding a feature to parmed temporarily while we wait for topology.core to be developed enough for big additions

Reviving this because I think it's cool.
Looks like it's not too far away - there are the changes I needed to make to the written file to get it to be read back in (as @summeraz noted in the docstring):
3,4c3,4
<     <Type name="opls_135" class="CT" element="C" mass="12.01078" def="[C;X4](C)(H)(H)H" desc="" doi="{'10.1021/ja9621760'}"/>
<     <Type name="opls_140" class="HC" element="H" mass="1.007947" def="H[C;X4]" desc="" doi="{'10.1021/ja9621760'}"/>
---
>     <Type name="opls_135" class="" element="C" mass="12.01078" def="[C;X4](C)(H)(H)H" desc="" doi=""/>
>     <Type name="opls_140" class="" element="H" mass="1.007947" def="H[C;X4]" desc="" doi=""/>
6c6
<   <NonbondedForce>
---
>   <NonbondedForce coulomb14scale="0.5" lj14scale="0.5">

This is still limited in scope but I have attempted to write the <NonbondedForce coulomb14scale="0.5" lj14scale="0.5"> part, including values generated by parsing the structure.adjusts. The test could be beefed up plenty - maybe @ahy3nz knows how to get these two numbers from the Forcefield object?
If this addition is cleared I consider this good to go.

Oh cool I didn't know about structure.adjusts!
In the par writer PR, we've been looking at the various dihedral.type.scnb like here. The idea is that every structure.dihedral.type or structure.rb_torsion.type has a scee and scnb property (so the pmd.structure could have arbitrary 1-4 QQ and LJ scalings for every 1-4 interaction).
I think the logic would follow similarly to how you iterate through all the adjusts and hope for a single chgscale value; iterate through all the rb_torsions.type or dihedral.type and hope for a single scnb value. I think scee = 1/chgscale so the 14 LJ scaling is 1/scnb?

I would think (?) that these approaches should produce the same value

I don't know if this is concerning but they don't match, at least in the structure used in the unit test. But they are the same before and after the loop of writing a partial XML, reading it back in, and typing with it again
(Pdb) [t.type.scee for t in typed.rb_torsions]
[1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0]
(Pdb) [t.type.scee for t in typed_by_partial.rb_torsions]
[1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0]

(Pdb) [t.type.epsilon/((t.atom1.atom_type.epsilon * t.atom2.atom_type.epsilon) ** 0.5) for t in typed_by_partial.adjusts]
[0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5]
(Pdb) [t.type.epsilon/((t.atom1.atom_type.epsilon * t.atom2.atom_type.epsilon) ** 0.5) for t in typed.adjusts]
[0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5]

Hmm, I think parmed has multiple ways of handling the 14s. In the par_writer PR and examples, we were just using parmed to load in top/gro file. The gromacs/charmm readers in parmed will store these 14 interaction parameters in dihedral.scee or dihedral.scnb.
In the foyer workflow, we're dealing with omm.System and then pmd.Structure. In omm.System the 14 interactions are stored in omm.NonbondedForce as NonbondedExceptions to the 14 interactions. When we convert omm > pmd, the omm.NonbondedExceptions appear to get stored as pmd.structure.adjusts
So it looks like there are multiple ways of handling these 14s, scee/scnb for charmm/gromacs, adjusts for openmm; and it doesn't look like they'll mutually update each other.
That being said, it's probably better to look for structure.adjusts and not expect agreement with structure.dihedral.scee/scnb. So I think your current implementation is more appropriate - the only  way (i think) to get the actual lj14scale or coulomb14scale attribute would involve getting the information from the omm.NonbondedGenerator

Looks like the coverage reports are complaining because a) this project has relatively few lines of code so any change has a large impact on the overall coverage and b) the unit test looks for RB torsions and not proper dihedrals. I can add another molecule if people want but I'm generally fine with this as it is.
https://coveralls.io/builds/23222238/source?filename=foyer%2Fxml_writer.py#L50
I'm also not super inclined to dig through the OpenMM objects because I'm not familiar with them and we're going to be ditching them in short time. If somebody else wants to implement this please do so. Again, open to objections but I'm happy with where this is at the moment.

@justinGilmer I'd like to fix or at least investigate the issues you found in #237 before merging. Should be able to cover a lot with just another test molecule or two.

@ahy3nz @justinGilmer I think this is good to go but please give these changes a once-over and then we can merge.

Added a test for writing PeriodicTorsionForce to make codecov happy and it's good I did, there was a small bug in how a variable was stored. Coverage still drops but only by a small amount.

I say fix the sigma-off-by-10 issue and merge the PR

That sounds like a plan to me; remember that Andrew wrote most of this code so I'd be more comfortable with you leading these changes and me following along. Because yes, that is quite a mess.


[Bug]: want to change the color of signup

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug

want to change the color of signup word before and after hover, it will make it look attractive
@Trisha-tech plz assign me this issue
Expected behavior
before hover it will have a color rather then white, and after visiting the link it will have different color
Add ScreenShots

On which device are you experiencing this bug?
Android, iPhone, Linux, Chrome, Windows
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

/assign

I would like to contribute on this as i am good full stack developer. please assign me that issue.

I would like to fix  this issue , please assign it to me , I am gssoc contributor


Is iOS 14 compatible

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Cant agree more, the system version requirement is too strict. I can't believe one app ended support for iOS 15 so soon

希望未来大佬能加入旧设备支持，目前ipad14.8.1下闪退


Add community call meeting notes

Links to rendered docs, for the lazy like me :
https://github.com/Rust-GCC/Reporting/blob/phil/weekly-16-05-2022/2022-05-13-community-call.md
https://github.com/Rust-GCC/Reporting/blob/phil/weekly-16-05-2022/2022-05-16-report.org


Azure Marketplace Managed Application

Hi,
Do we need to set up a PAL for Managed Applications that are deployed through Azure Marketplace ?, or, is ACR automatically recognized for all the resources in the managed resource group where the application gets deployed?
Thanks.

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

ID: 5f901056-c225-b086-cdaa-c8bd978db64c
Version Independent ID: 9c067eb4-54cb-e141-d82f-e136ff3c671e
Content: Link an Azure account to a partner ID
Content Source: articles/billing/billing-partner-admin-link-started.md
Service: cost-management-billing
GitHub Login: @dhirajgandhi
Microsoft Alias: banders

Hi @devszr Thanks for reaching out. We will review and update as appropriate.


Unable to find service remote.send_command on ESP32 remote with custom services

When acting on a Climate entity made by SmartIR (probably the same happens with Fans and Media Players), calling services (for example, off command) causes no ir code sending and the following error on Home Assistant log:
2023-02-22 18:36:48.913 ERROR (MainThread) [custom_components.smartir.climate] Unable to find service remote.send_command
Traceback (most recent call last):
  File "/config/custom_components/smartir/climate.py", line 366, in send_command
    await self._controller.send(self._commands['off'])
  File "/config/custom_components/smartir/controller.py", line 111, in send
    await self.hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1734, in async_call
    raise ServiceNotFound(domain, service) from None
homeassistant.exceptions.ServiceNotFound: Unable to find service remote.send_command

Home Assistant version
2023.2.1
SmartIR version
1.17.6
SmartIR configuration
smartir:

climate:
  - platform: smartir
    name: Office AC
    unique_id: office_ac
    device_code: 1000
    controller_data: esp360remote_send_ir_raw
    temperature_sensor: sensor.living_room_temperature

More details:
Using this configuration file just for testing.
sensor.living_room_temperature is a working sensor entity
esp360remote is ESPHome node name from device configuration made by @ale1800 and used on my device, which is integrated on Home Assistant
esp360remote_send_ir_raw used on smartir config is expected to be the correct service name (without service. suffix, as ESPHome docs says) as your docs says.

Solved. The problem comes from the format of codes: esphome needs integer arrays, while all the other usual json are expressed in base64.

Solved. The problem comes from the format of codes: esphome needs integer arrays, while all the other usual json are expressed in base64.

Sorry, but what was the solution itself ?


Installation issue with official release of Laravel 5

I got the following issue while installing laracasts/behat-laravel-extension with the newly released Laravel 5.
I was trying to follow this laracast:
https://laracasts.com/lessons/laravel-5-and-behat-bffs
And I got the some prophecy version error.
I was able to install behat/behat, behat/mink, behat/mink-extension first, but when trying laracasts/behat-laravel-extension after that, the same errors showed up again. Error messages are at the bottom of this comment.
I wonder if there's a simple answer to that. If not, I'd love to explore a solution by myself, if someone could kindly give me a pointer to start with.
Thanks!
H. Guo
===========================================
php composer.phar require laracasts/behat-laravel-extension
Using version dev-master for laracasts/behat-laravel-extension./composer.json has been updated
Loading composer repositories with package information Updating dependencies (including require-dev)
[RuntimeException]
Could not load package phpspec/prophecy in http://packagist.org: [UnexpectedValueException] Could not parse version constraint ^1.0.2: Invalid version string "^1.0.2"
[UnexpectedValueException]
Could not parse version constraint ^1.0.2: Invalid version string "^1.0.2"
require [--dev] [--prefer-source] [--prefer-dist] [--no-progress] [--no-update] [--update-no-dev] [--update-with-dependencies] [--ignore-platform-reqs] [packages1] ... [packagesN]

Update your composer's version.

@haoyuguo going to close this feel free to reopen if needed.


Fix unhelpful error check

Getting a message in slack

I'm seeing a lot of Op | WARNING  | Tensor at index 0 is not allocated in SD. Sounds like it is something I should be concerned about, what do you think?

This check is not helpful and has to be changed according to the best practices
https://github.com/tenstorrent/tt-metal/blob/5758ff8479b7efbe0f6282501ee1382ab0fa36de/ttnn/cpp/ttnn/device_operation.hpp#L183

@ayerofieiev-tt are we able to just remove this or downgrade it to log_debug? Seems like there are ops that can run fine or expect inputs to be on host.
This warning gets printed a lot for example in Resnet, which runs without issue.


Make ruby library conform to status code spec

Specifically, if the server is refusing to handle a call because it has too many outstanding requests, it should send RESOURCE_EXHAUSTED, not UNAVAILABLE.
This fixes #5993.

The only failure is what appears to be a C windows flake.

LGTM.


Support more than 2 sessions in parallel

The restriction to two sessions in parallel seems a bit arbitrary. I sometimes have 3 characters running in parallel, especially if one of them got stuck unexpectedly :D
This change makes the number of possible parallel sessions a bit more dynamic, although still with a hard upper limit to avoid endless resource allocation.

Looks like a missed a spot :) Will fix right away.

In Ye Olden Days the decision was not arbitrary.  The primary reason - to prevent abuse of KoL's servers seems to me to remain.  I would prefer that there be some consensus among the devs before this is approved especially @Veracity0 's opinion.

I was under the impression that the issue is actually that we don't perform locking file I/O, e.g. when updating your settings.txt, and as such file corruption (including data loss) can and will happen, given enough time. Having more concurrent sessions only accelerates that issue.

See this thread for some more details: https://kolmafia.us/threads/6044/#post-45232
I don't think anything's changed in the intervening decade.

File I/O noted.  But when I implemented it long ago I was asked not to commit it because of the specter of a KoLmafia driven bot army.  If it was A Good Idea I would have been asked to deal with the file locking first is the way I remember it.  Of course I also remember when Hola would refuse to let anything that could automate Crimbo until after the event ;-)

Thanks for finding the legacy thread! I agree that nothing has been changed in the last decade.
I looked a bit, yesterday, and noticed we had file locking for the session file, but perhaps that was for multiple threads, not processes.
Hola's comment was illuminating.
I don't want to allow some arbitrary number of parallel characters logging in and simultaneously writing to GLOBAL prefs. Not without substantial stress testing across all supported OSs.

Regarding automating Crimbo, eventually I reached out to Jick. He thanked me for asking and said he had no problems with it and he was no longer worried about KoLmafia users overwhelming the KoL servers.
I also expect their server infrastructure has modernized over the years - and perhaps the number of active users has flattened out, although I do not have that data.

Since there are good technical reasons for not commiting this and perhaps some social reasons as well I'm inclined to close it in the next few hours.

This sounds reasonable. Thanks for all the interesting information! Merry Crimbo :)

Do I see this correctly that as a workaround, I can set useCWDasROOT to use different folders for different characters (instead of all of them using ~/.kolmafia)?

Do I see this correctly that as a workaround, I can set useCWDasROOT to use different folders for different characters (instead of all of them using ~/.kolmafia)?

Yes, that's a valid / more robust workaround, and one that doesn't run into the same data race issues.

Do I see this correctly that as a workaround, I can set useCWDasROOT to use different folders for different characters (instead of all of them using ~/.kolmafia)?

Yes, that's a valid / more robust workaround, and one that doesn't run into the same data race issues.

Yep.  You won't be able to use global settings and you'll fetch certain data once for each data root, but as long as that's OK with you, that's viable.  You could script up something that set a per-character folder as the CWD (and therefore root).
I'm not keen on using the application's directory as the writable user directory, but some people have been doing that just fine for years.

I'm going to close this because we are not going to implement the suggest change and the workarounds and alternatives can be discussed elsewhere.


Add HmIP-SMO to Homematic IP

Description:
This PR adds an outdoor motion detector.
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#9161
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

Motion detection usually is binary sensor. Is some specific reason you want both sensor and binary sensor for motion detection?

Yes, the HmIP-SMO is a motion detector and an illuminance sensor.
It's the same like the already included HmIP-SMI (AsyncMotionDetectorIndoor), but for outdoor.

funktioniert leider nicht korrekt .
Außen Küche Battery
binary_sensor.aussen_kuche_battery
Außen Küche Illuminance
sensor.aussen_kuche_illuminance
(Entität nicht verfügbar)
binary_sensor.aussen_kuche
https://www.facebook.com/photo.php?fbid=2421457338088629&set=p.2421457338088629&type=3&theater

https://www.bilder-upload.eu/bild-55b3d8-1556214876.jpg.html

https://www.bilder-upload.eu/bild-c3f1c7-1556215081.jpg.html

Please open an issue and fill out the template.
This PR is closed and is not a bug tracker.


dbt: render actual profile only in profiles.yml

Signed-off-by: Jakub Dardzinski<EMAIL_ADDRESS>Fix mypy issue.
Signed-off-by: Jakub Dardzinski<EMAIL_ADDRESS>Problem
dbt integration attempts to render whole profiles.yml file even if other profiles are not used. It should follow similar practice as in dbt-core - fetch and render only needed profile.
Closes: #1589
Solution
Add include_section argument for jinja render method to include only one profile if needed.
Checklist

[x] You've signed-off your work
[x] Your pull request title follows our guidelines
[x] Your changes are accompanied by tests (if relevant)
[x] Your change contains a small diff and is self-contained
[ ] You've updated any relevant documentation (if relevant)
[ ] You've updated the CHANGELOG.md with details about your change under the "Unreleased" section (if relevant, depending on the change, this may not be necessary)
[ ] You've versioned the core OpenLineage model or facets according to SchemaVer (if relevant)
[ ] You've added a header to source files (if relevant)

SPDX-License-Identifier: Apache-2.0
Copyright 2018-2023 contributors to the OpenLineage project

@denimalpaca could you please show an example of such failing profiles.yml? Do you have separate profiles there (in which one is with missing 'BIGQUERY_DATASET' env var) or one profile with different outputs?

It has a profile for each of BigQuery, Postgres, Snowflake, Redshift, and Databricks, in alphabetical order, and the variables for each are pulled from env vars. Like this but with all of the above connections:
bigquery_profile:
  outputs:
    dev:
      project: "{{ env_var('BIGQUERY_PROJECT') }}",
      dataset: "{{ env_var('BIGQUERY_DATASET') }}",
    ...
  target: dev
snowflake_profile:
  outputs:
    dev:
      account: '{{ env_var(''SNOWFLAKE_ACCOUNT'') }}'
      client_session_keep_alive: false
      database: '{{ env_var(''SNOWFLAKE_DATABASE'') }}'
      password: '{{ env_var(''SNOWFLAKE_PASSWORD'') }}'
      role: '{{ env_var(''SNOWFLAKE_ROLE'') }}'
      schema: '{{ env_var(''SNOWFLAKE_SCHEMA'') }}'
      type: snowflake
      user: '{{ env_var(''SNOWFLAKE_USER'') }}'
      warehouse: '{{ env_var(''SNOWFLAKE_WAREHOUSE'') }}'
  target: dev

@denimalpaca are you sure you don't have any additional openlineage-dbt version installed?
I'm asking since the error message line numbers do not match current code.

I'll try it again with the latest version...

Yeah, using 0.21.0 (just updated my main, so it's got all the latest PRs), still not working.

Nevermind, realized an older version was sneaking through. I'll test again when this is released!


Enable Clair after initial provision

If you try to enable quay after the initial creation of the quayecosystem it does not setup any of the required configuration.

QuayEcosystem has been replaced by QuayRegistry type since versin 3.4. This problem should not happen anymore. I am closing this, feel free to reopen.


UUF port: DI into controllers: More info on Configuration needed

Description
UUF Feedback tool port:
Customer Verbatim Feedback:
"I've been developing code for 40+ years and can't follow this article. Where does "Configuration" come from in this line of code: "services. Configure(Configuration);"? It's a class you created somewhere, but where????"
See all open issues for this doc
Page URL
https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/dependency-injection?view=aspnetcore-8.0
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/mvc/controllers/dependency-injection.md
Document ID
f9a790d8-f25b-0e1d-eb63-c8ed3ac518cf
Article author
@ardalis

Set to P1 (to be resolved within 1-2 monthly sprints per LT.)

Tom, I assigned to you since you are listed as ms.author.

In this code, Configuration is a property of the Startup class that holds the application's configuration settings. It is of type IConfiguration, which is an interface provided by the .NET Core framework for accessing configuration data.
The Configuration property is initialized in the constructor of the Startup class. The constructor takes an IConfiguration object as a parameter, which is passed in by the ASP.NET Core runtime when the application starts. This IConfiguration object is typically built from various configuration sources, such as appsettings.json, environment variables, and command-line arguments.


Spline spin tests

I added a couple of tests, just checking that the spline spin models are normalized in their respective domains. I can add more unit tests if we think of any.

Codecov Report
Patch coverage has no change and project coverage change: +6.79 :tada:

Comparison is base (42b6fa7) 87.40% compared to head (d81377e) 94.18%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #70      +/-   ##
==========================================
+ Coverage   87.40%   94.18%   +6.79%
==========================================
  Files          11       11
  Lines         722      722
==========================================
+ Hits          631      680      +49
+ Misses         91       42      -49

Flag
Coverage Δ

python3.10
94.18% <ø> (+6.79%)
:arrow_up:

python3.8
94.04% <ø> (+6.52%)
:arrow_up:

python3.9
94.04% <ø> (+6.52%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 2 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Hi @jacobgolomb I just merged some changes to the interped module to make it play better with JAX. Do you think you'll have chance to fix up these tests? Otherwise I'm happy to do it.

Yeah, I can look at the changes and update the tests.


HBASE-28401 Introduce a close method for memstore for release active …

…segment

Let's see if this could fix the LEAK problem.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

Sorry for being late here, this looks good overall. Just to confirm, this patch is sufficient for getting rid of memstore leak logs or we still need HBASE-28435?

Sorry for being late here, this looks good overall. Just to confirm, this patch is sufficient for getting rid of memstore leak logs or we still need HBASE-28435?
IIUC, HBASE-28435 is more of good to have right?

This patch is enough to solve one possible memory leak log problem(although actually there is no real memory leak). HBASE-28435 is for refactoring, and yes, it is a good to have.


Add a Rake task for manually unpublishing content

Whitehall deletes some content when it unpublishes it, this makes it
very difficult to change the details of the unpublished
content (e.g. change from gone to redirect, or change the redirect).
This Rake task provides a workaround intended for these cases where
you want to manually send an unpublish request to the Publishing API.

(PS: do we document this rake task anywhere once it's merged?)

(PS: do we document this rake task anywhere once it's merged?)

Hmm, it might be worth trying to start documenting how unpublishing/redirecting different types of Whitehall content is managed, but I think that would be a new bit of documentation. I'm not sure if there's something existing where this would fit in and be a useful addition.

Presumably here would be a good place? https://docs.publishing.service.gov.uk/manual/howto-redirect-html-attachment-urls-from-whitehall.html


Renaming for increased clarity

This is a series of cosmetic changes. @yanokwa merged it into next accidentally and then fixed the build. I think there's one more sentence that needs adjusting to be coherent with the new changes.


Update ADLA catalog

Description
This change updates the ADLA catalog to do the following:

Introduces the new package item type
Allows for listing the following items from their parent's parent item (the database):

Table
view
Table valued function
Table statistics

Switched the FileType enum to a string since this field is read only and will have new types added and changed with some regularity.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] I have read the contribution guidelines.
[ ] The pull request does not introduce breaking changes.

General Guidelines

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

SDK Generation Guidelines

[ ] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[ ] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as a link to the swagger spec, used to generate the code.
[ ] The project.json and AssemblyInfo.cs files have been updated with the new version of the SDK.

@begoldsm You may want to pull the latest from this PR: #3117
Also, please fill out the checklist

@markcowl shame on me, I know better! :).
Here is the PR for the swagger update: https://github.com/Azure/azure-rest-api-specs/pull/1119

@markcowl @shahabhijeet I have synced to the latest and squahsed my commits down and update the title, description and the checklist. Let me know if you have any questions or need anything else from me!


Application steps UI and logic

@tinnamariat @alexiaaxels @Dagurf21
Apply for job with all substeps is now on main


Change platform settings for Jericho devices

Issue Type

[x] EOS Configuration rendering error

Summary
Default platform settings today assign incorrectly J2 devices a tcam_profile and lag_hardware only.
New platform should be defined for J2 devices without these settings, and 7500R2 should be added to current platforms.
Component Name
eos_designs
Steps to reproduce

platform_settings:
  - platforms: [7800R3, 7500R3, 7500R, 7280R3, 7280R2, 7280R]
    tcam_profile: vxlan-routing
    lag_hardware_only: true
    reload_delay:
      mlag: 780
      non_mlag: 1020

Expected results

platform_settings:
  - platforms: [7500R2, 7500R, 7280R2, 7280R]
    tcam_profile: vxlan-routing
    lag_hardware_only: true
    reload_delay:
      mlag: 780
      non_mlag: 1020
  - platforms: [7500R3, 7280R3, 7800R3]
    reload_delay:
      mlag: 780
      non_mlag: 1020

Actual results

Configuration generated for J2 devices:

hardware tcam
   system profile vxlan-routing

@xaviramon Please take the folllowing also in account:
eos_designs: 7280R/R2 platform default mlag reload delay too low #1046


Dan/3d octahedron

Grapher file removed
Octahedron now spins in a random direction for a while, switching axes periodically to keep things interesting.
Octahedron radius  "ballradius" can be changed. Set ballradius to a large number to illluminate the entire tree!
colourA through colourH can be modified to create a personalized holiday spirit!

@oliverdunk Hey Oliver. Take a look at my new PR. I moved my example into the "examples" directory. I've only been able to test it with the simulator, so I'd be very interested to see how this looks in real life. Eager to continue coming up with improvements here! Please keep me updated.
Dan

@oliverdunk Hey Oliver. Take a look at my new PR. I moved my example into the "examples" directory. I've only been able to test it with the simulator, so I'd be very interested to see how this looks in real life. Eager to continue coming up with improvements here! Please keep me updated.
Dan

Hey again @danielkwalsh! This looks great, but I think Matt's original code has been accidentally removed in it? Appreciate your time on this, if you can fix that I think it's good to merge. Let me know if you need any help figuring it out.

Hey again @danielkwalsh! This looks great, but I think Matt's original code has been accidentally removed in it? Appreciate your time on this, if you can fix that I think it's good to merge. Let me know if you need any help figuring it out.

Hey, Oliver. Sorry about that. I must have accidentally deleted the file. I've replaced Matt's file again so now there should be no problems merging this PR.

Hey, Oliver. Sorry about that. I must have accidentally deleted the file. I've replaced Matt's file again so now there should be no problems merging this PR.

Hey @oliverdunk, just checking in again to see what's blocking merging this PR. Is there anything else you need?

Hey @oliverdunk, just checking in again to see what's blocking merging this PR. Is there anything else you need?

Hey @danielkwalsh - nothing blocking this! Let's get it merged, thanks for tweaking it slightly :)

Hey @danielkwalsh - nothing blocking this! Let's get it merged, thanks for tweaking it slightly :)


API: ability parse json with comments

VSCode supports json files with comments, but is there a way we can access to the parser via API without installing external libraries?

Yes, we extracted that to the https://www.npmjs.com/package/jsonc-parser node module.


Document ClojureScript usage.

Regarding #56 - thought I'd take a stab at this part.
I'm not sure that @souenzzo's examples work, because :refer :all isn't a feature of CLJS if I understand correctly. I am pretty new to CLJS myself, so this may not be 100% accurate. For myself, I'm just doing (:require [com.rpl.specter :as S]).


[Feature Request] module Pagination depends

Existing Component
Yes
Component Name
Pagination
Description
module [Pagination] now depends on a module [select]
this should be an options, because select module almost as heavy as Pagination.
what about a module name pagination with select?

Sorry, we have no plan to support this.


Pass test object to camrestest + remove resolution loop test

Test object is now passed to the tests, also I've changed the tests to be more explicit, i.e. no more looping through an array of resolutions. It just runs the explicit resolutions test and verifies that there are non black moving pixels coming from the camera.
@tednakamura @samdutton @juberti Do you have anything against me removing the test that checks that gUM is successful for 14 resolutions? It actually prevents it from being run properly on Chrome on Android, it crashes Chrome on this test every time since the last 3 or 4 of milestones (since Camera API v2 was introduced I believe). In my opinion it's more of a stress test than anything else.

it crashes Chrome on this test every time since the last 3 or 4 of milestones (since Camera API v2 was introduced I believe).

Is there an open chromium or Android bug for those crashes?
Overall, I support the general refactoring, but wonder if instead of removing all those other resolution tests for all platforms, what if you instead run the specific resolution tests (240, 320, 720) when a mobile client is detected, but still test all resolutions on non-mobile clients?

Just to clarify, the Check supported resolution tests only verifies that getUserMedia succeeds (which does not necessarily mean that you get working video) for the given resolution while the Check resolution Y x X actually verifies the video coming from the camera.

I have no strong opinion regarding not checking for that big list of resolutions. Though make sure you have a chrome bug open for that crash.

I have put the resolution check tests back in but cleaned up the logic. We can discuss about remove them/detecting mobile clients etc in a separate PR.

sounds & looks good to me

FTR here is the Chrome issue for the crash, TL;DR unsupported resolution crashes Chrome due to an issue in the Camera2 api. It's recently fixed so should be able to test in canary and dev soonish.


First pass on ai top-level folder and contents

Summary
creating a new folder for AI for .NET developers content
Fixes #Issue_Number (if available)

Internal previews

📄 File
🔗 Preview link

docs/ai/azure-ai-for-dotnet-developers.md
Develop .NET apps that use Azure AI services

docs/ai/get-started-app-chat-template.md
CustomerIntent: As a .NET developer new to Azure OpenAI, I want deploy and use sample code to interact with app infused with my own business data so that learn from the sample code.

docs/ai/quickstarts/get-started-azure-openai.md
Quickstart - Build an Azure AI chat app with .NET

docs/whats-new/dotnet-docs-mod2.md
.NET docs: What's new for November 2023

@IEvangelist @FBoucher and @jmatthiesen for visibility


[csolution] question : can we trust the compiler version in cprj ?

CPRJ says:
  <compilers>
    <compiler name="AC6" version="6.16.0"/>
  </compilers>

and indeed in cmsis-toolbox, I have: AC<IP_ADDRESS>.cmake
with:
set(TOOLCHAIN_ROOT "c:/Keil_v5/ARM/ARMCLANG/bin")

But:
$ ./armclang.exe --version
Product: MDK Professional 5.36
Component: ARM Compiler 6.16
Tool: armclang [5dfeb700]

The version returned by the tool is 6.16, not 6.16.0.
So is the version added in the cprj matching the .cmake file or is it the actual version returned by the tooling ?
I need to capture the real version of the compiler in use, not the cmsis-toolbox settings files.

Yes, the exact compiler version is part of the reproducibility.
So we need pack versions (and ideally their path on the disk to be double-sure) and exact compiler versions.

If I may we have extra issue here according to me see extra compiler support. I've feeling this one is even more pregnant because escalading up to pdsc ...

@VGRSTM and @fred-r can we agree that
a) we are using semantic versioning
b) that we can define mappings from tool versions being provided versus the ones being specified
e.g. Arm Compiler 6 is intentionally skipping the patch version if it does not exist. Therefore AC 6.16 == 6.16.0
c) we currently do not have a scalable tool registry which is responsible for ensuring that an Arm Compiler version 6.16 installation is associated with the meta data being used for selecting this compiler in case of being required by the csolution/cproject.
Please feel free to proposed a specification, develop and contribute such a scalable tools registry.
One existing tool I know of is vcpkg from Microsoft. But also there you are relying on the meta data being correctly mapping between the blob being installed and the version being associated.
Regarding supporting additional Compilers, I don't see where the technical scaling issue is. For me the pre-requisite for adding additional compilers is that we have representatives developing and maintaining the support. We already see that we struggle with the IAR compiler.

@jkrech
I agree on semantic versioning of course https://semver.org/

Regarding supporting additional Compilers, I don't see where the technical scaling issue is

I guess no technical issue. More a pain because adding a compiler is impacting lot of contributions. Not only devtools are impacted but CMSIS-Pack side (pdsc, ...) too.
Right now I'm thinking to LLVM introduction. Of course can be added contributing to current code base but will face issue about existing packs usage at a point thinking condition resolution. Most of GCC compliant components may be LLVM ok too but we may not take benefit of ...

Please feel free to proposed a specification, develop and contribute such a scalable tools registry

Obviously I agree but still have question myself about: is Open-CMSIS (or at least current under discussion formats like *.yml & .cprj) right place to do such?
I'm fine having *.yml / .cprj dealing with packs, components, devices, ... here we are discussing to extend support to tools. I guess ambition is to ensure build reproducibility and I'm granting such. Locking compiler is one step but not sufficient according to me. If we want so we have to add all third parties build is relying on (cmake & ninja at least).
Could we think having tooling concerns to be managed by Open-CMSIS integrator instead ?  I'm convinced this way Open-CMSIS has to support compiler type but more ? This would helps my components conditions solving problematic too.
If we look at GCC, each vendor may promote its own variant ... no chance / no interest if Open-CMSIS to introduce in a hard coded manner reference to.
Thinking loud here ... would be happy to get your comment about.

I am not sure we need a tool registry to have accurate versions.
When installing cmsis-toolbox, the toolchains are prompted and stored in TOOLCHAIN_ROOT.
Then, I guess it is possible use this variable when creating the CPRJ to check the version ?

I think to go forward with this point we need to clarify what we expect:

from the OpenCMSIS-Pack-spec
from the vanilla tooling
the level of freedom given to the tools implementer

As an embedded SW, I need to specify the compiler my code is compatible with (pdsc) and also in a lock file the exact toolchain and settings used for building my project (lock file).
To me, if adding a new compiler requires a change request in the Open-CMSIS-pak-spec, maybe it is acceptable ?
For the versions, I do not know.
We have also to consider the tooling:

does the vanilla build environment need to support all offered compilers and versions ? Probably not ?
can we let the tools implementer decide how to manage the toolchains ? Yes, it is probably the best approach ?
is the current cmsis-toolbox approach fine (user prompted for toolchain paths) ? I guess it is acceptable, now this needs to be used for the lock file to provide accurate information.

To be discussed...

@fred-r to my knowledge all that is needed is a *.cmake file that reflects the compiler / version.
See here: https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/toolbox/docs/installation.md#etcsetupcmake
That is what we ship today: https://github.com/Open-CMSIS-Pack/devtools/tree/main/tools/buildmgr/cbuildgen/config
Adding a new compiler version should be pretty simple.

#493 documents how to add a new compiler toolchain. Hence closing this


Drop etcd metrics

This pull request drops accidentally instrumented etcd metrics (more description in the commit message) and removes the namespaceSelector fields as it defaults to the namespace the ServiceMonitor object is in, therefore what was previously in the ServiceMonitor objects is already the default, so just removing unnecessary mental overhead when reading the object.
@bparees @mfojtik @smarterclayton

/lgtm

/retest


Implement JUnit5 support

The JUnit5 implementation itself is just switching the JacocoRunner according to the setting. (Closes #10)
This PR contains mostly tests, which are meant to be used as the baseline when implementing #4, since we will have a faster flacoco and will also need the tests to assert behavioral neutrality.

Ready for review

Hi @andre15silva
The PR seems perfect for me. The tests are fine.
Merged, thanks!


docs/encryption: Document limitations and workarounds

This adds a section in to the transparent encryption getting started
guide explaining that due to potential delays in IPCache updates, it is
possible for both IPsec and Wireguard to send out packets unencrypted.

I wonder if the limitation should have a subsection title or paragraph name, or whatever could “summarise” the issue briefly at the top. My concern is that users need to read through ~10 lines of text to understand what the limitation is and if they are concerned at all.
Looks good otherwise.

Thanks! I decided to add a subtitle called Egress traffic to not yet discovered remote endpoints may be unencrypted. I hope that is a concise but precise enough summary of the issue, but suggestions on how to summarize this better are welcome as well.


Fix: Passing generator when recreating sequence-like field value

Change Summary
Before this fix, calling obj.dict() where an attribute of obj is namedtuple raise error like this:
ValueError: <generator object BaseModel._get_value.<locals>.<genexpr> at 0x7f54af603a50> is not a valid XXX

Related issue number

Checklist

[x] Unit tests for the changes exist
[ ] Tests pass on CI and coverage remains at 100%
[x] Documentation reflects the changes where applicable
[ ] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)

Could you take a look, @samuelcolvin ?

@hongquan I'll look at it when I get a chance.
As you can see I have many pull requests to review and life has been pretty uncertain recently.

Thank @samuelcolvin , hope you are well.

please create an issue before submitting a PR, this is noted in the docs.
I don't think pydantic supports NampedTuple very well at all right now, so I'm not sure this fix is the main / primary thing to fix. Maybe we don't want to support NamedTuple at all and stick to just dataclasses.


Remove direct React dependency?

Depending directly on React from reusable components can cause problems stemming from competing React instances, and version conflicts. See Two React Tips.
One way around this is to export a function, that takes an options object & allow users to inject the React dependency in the options object. See Baby's First Reaction for an example.

@ericelliott thanks a lot for the notes.
I read the articles, very helpful.
Do you think targeting '*' React version is enough to resolve the issue?

Do you think targeting '*' React version is enough to resolve the issue?

No. However, this may get easier with React 0.14+, which splits some of the React dependencies you may need out of the React module.
You may also be interested in react-stampit, which also demonstrates using dependency injection to let users pass in the React dependency and avoid React instance conflicts.

I cannot add this package when running the latest version of react.
npm ERR! peerinvalid The package<EMAIL_ADDRESS>does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer<EMAIL_ADDRESS>wants react@*

Any chance we can remove the peerDependency?

+1


Loic backgroundsub

First version of the Commissioning Custom stages 1 and 2 for SOSS

@loicalbert you can delete this branch now - it is in soss-dev


Group SKT-T1 Vuln 12

You are missing the README.md specifically required in the Case Study Assignment see https://utexas.instructure.com/courses/1144129/pages/case-study-assignment under "Process for the Case Study"
Additionally, the team and vulnerability this PR should be in the PR message and the README.md.
An example of a correct submission is at https://github.com/mtesauro/gauntlt-demo/tree/master/examples/webgoat/vuln-00

Readme is added and the attack file now has correct attack mentioned.


Fixed a bug where string couldn't be app arguments

lib.load_string failed to properly call Lua's loadstring built-in.

Merged into max-next.


Poor display/interaction performance on 4k linux

Type: Bug
Run VScode on linux through VNC server on a large (4k) monitor and make the VScode window large (or full-screen).

Profile-20230421T170501.zip

BTW, I'm noticing very high Cumulative Layout Shift (for example, CLS score is 1.229 at 12131.2ms)

Can you check if the issue repros with our latest insiders version https://code.visualstudio.com/insiders ?

Can you try with hardware acceleration disabled in the application https://code.visualstudio.com/updates/v1_40#_disable-gpu-acceleration

It is already disabled (you can see in previous logs) because I am running on a server farm which doesn't have any GPUs.  I also explicitly ran with (and am now running with) --disable-gpu and there is no difference.

Hi Deepak - any update on this?

Can you check the following,

Does the issue repro when you use https://vscode.dev in a chromium browser over the same VNC setup ?
Does the issue repro with our exploration build code-exploration-x64

The problem repos on both 1 (native Linux chromium @ https://vscode.dev) & 2 (code-exploration).
In addition, though, code-exploration is linked against a different Linux kernel (we use SuSE version 12), so I get the follow error:
[main 2023-05-02T18:39:31.728Z] Error: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by<EMAIL_ADDRESS>

Thanks for testing, given it still repros with latest chromium can you help file an issue in https://bugs.chromium.org/p/chromium/issues/list using https://vscode.dev/ as repro.

I filed Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1442310

What is the current status of this issue?


[#505] Allow setting of ListenerInvocationErrorHandler through Configuration API

This PR adds the option to configure an ListenerInvocationErrorHandler in the EventHandlingConfiguration.
It allows to either adjust the default ListenerInvocationErrorHandler or adjust an ListenerInvocationErrorHandler per EventProcessor.
This PR resolves #505

Close as @abuijze merged it to master through command line.


Python live lab

WMS ID = 440; LiveLabs #3601
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[x] All filenames are lower case (including folders, images, files, etc.)
[x] Filenames are descriptive
[x] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[x] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[x] Image references in markdown contain an alternate text

@klazarz , @william-masdon-oracle  - I pushed the latest changes, they should be final for LevelUp


fix: interface conversion: interface {} is *unstructured.Unstructured, not *v1alpha1.Workflow

Fixes crash loop caused by the health check in v3.5.1

Motivation

Modifications

I safeguarded the type conversion.

Verification

@terrytangyuan Absolutely, but I'm not sure what I should add more to the PR than fixing the attached error, referenced in the screenshot. I now have noticed that this is a generated file. Do you have any suggestions how to fix this better?

@woehrl01 - do you have an invalid workflow in your cluster. Are your CRD definitions in cluster up to date with the workflow-controller version? I'm not sure that would help if the workflow was uploaded prior to the CRD update though.

[ ] @Joibel no, I already cleared all workflows multiple times, crd are in 3.5.1 same as the controller. All the new workflows are creates by the same workflow templates.

Is this a set of workflows that worked under an earlier version? Any chance of attempting to find the workflow that's causing this?

@Joibel I don't know because, we are starting to use it more intense since 3.5.1. I could definitely give it a try to find the workflow, do you have any ideas how I can find the affected workflow?

I don't know how many workflows were talking about. Can you introduce them to another workflow-controller running in a separate cluster (e.g. k3d/minikube or whatever locally) one at a time until you find the one that crashes it. Or use a bisect on the full list to narrow it down. You don't actually need the workflows to be able to work at all.
Otherwise you could build yourself a controller which can spit out just the metadata.name for each workflow it's about to list, but that's more hassle.

@woehrl01  how will workflow get created? Are you using CLI/API? Will minimal CRD created on cluster?
Looks like one or some workflows are malformed.
you can try with Argo CLI to list the workflows to see if any workflows are missing.

Hey guys, I'm getting this as well, are we planning on introducing this fix?
Regardless of what is the issue, its probably still a good solution to add this validation.

I believe this was fixed by #12353 which changed the source code


Need a dirty flag in texture for auto update texture binding

Is your feature request related to a problem? Please describe.
For example, if I use a canvas as a texture image source or use a video, I have to update the texture manually.
And oasis will have fbo features later that we can render scene into a texture.
These cases, the image source is updating all the time.
Other engines like Three.js, texture has a "needsUpdate" flag or has CanvasTexture or VideoTexture that can auto update the texture.
Describe the solution you'd like
I think the features could be:

If a texture is dirty, oasis-engine can auto update the texture and then set the dirty flag false.
If a texture has an autoUpdate flag, the texture could be updated every frame.

These features could help developers using engine easier.
But  update texture each frame will cost more performance, so in API docs we can let developers know that we don't need to set autoUpdate true only if the image source is changing all the time.

VideoTexture is better than needsUpdate and we can add play() or pause() API .

There is a principle that Oasis' Texture2D will not record any image and canvas memory, because it is a pure gpu video memory texture, and image/canvas is only a kind of data source. needUpdate is only valid when the data source is image/canvas, and does not include pixel buffer. The needupdate design will make the Texture2D design dirty, videoTexture meybe better.


Homework 1

ДЗ 1 от Kitlopir

https://github.com/Kitlopir/python_developer/blob/master/homework1/Sequence.py

https://github.com/Kitlopir/python_developer/blob/master/homework1/Test 1.py


Support for SLEEP_MODE_IDLE on Teensy 3

Hi,
I would like to implement support for low power sleep (similar to SLEEP_MODE_IDLE of the Arduino) on Teensy to make it part of the TaskScheduler library
(https://github.com/arkhipenko/TaskScheduler)
The Teensy "avr/sleep.h" does not seem to have have any code actually, and "avr/power.h" is simply empty.
I have looked at the Snooze library and tried to use the Timer initiated power sleep, but it seems to be working differently then Arduino.
TaskScheduler uses SLEEP_MODE_IDLE to place Arduino into low power mode for approximately 1 ms. It is awaken back by the timer interrupt responsible for updating millis() counter. This way I am achieving 1ms scheduling resolution. Arduino does not power down any peripherals while in SLEEP_MODE_IDLE, so USB and other communications continue to run normal.
Teensy seems to be behaving differently.
class definition:
#ifdef CORE_TEENSY
	SnoozeTimer *timer;
	SnoozeBlock *config;
#endif //CORE_TEENSY

constructor:
#ifdef CORE_TEENSY
	timer = new SnoozeTimer;
	config = new SnoozeBlock(*timer);
	timer->setTimer(1);
#endif //CORE_TEENSY

actual sleep:
#ifdef CORE_TEENSY
	Snooze.sleep(*config);
#endif //CORE_TEENSY

causes my Tennsy 3.5 periodically connect and disconnect, so I can't even monitor what is going on with the device.
Is there a sleep function that is close to AVR's SLEEP_MODE_IDLE mode?
Your help is greatly appreciated.
Thanks.
Anatoli

I created a "teensy_idle" branch for your reference of my changes if you have a minute:
This sums up the TEENSY related updates pretty well:
https://github.com/arkhipenko/TaskScheduler/compare/teensy_idle?diff=split&name=teensy_idle

As I said in the Teensy forum that just calling wifi will only pause the processor until interrupt happens, if you want it to pause for set amount of time you have to disable the systick and usb interrupts at a minimum and use a timer to wake in the amount of time you want to sleep.

Thank you for your help!


[enhancement][ISSUE #878] enhance the ninth point expression in 命名风格.md

To get more details, please see ISSUE #878

 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.


mWeb - Assign Task Description field shows as multiline

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Press FAB and choose Assign Task

Expected Result:
Description field initially shows as a single line like in other platforms
Actual Result:
Description field initially shows as a multi line
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[x] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.31-2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:
Issue reported by: @bernhardoj
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1686997207642659
View all open jobs on GitHub

Asking if this should be fixed separately from https://github.com/Expensify/App/issues/19135

@kavimuru Thanks for creating the issue, but we already have the same report (by applause) here https://github.com/Expensify/App/issues/21280. I have added a comment there to add me as the reporter. Maybe we can either add me to the reporter in that issue or close that in favor of this?

Proposal
Please re-state the problem that we are trying to solve in this issue.
The description field show multiline line in the safari
What is the root cause of that problem?
When we implement auto-grow text input, we use a hidden <Text> component to calculate the component's height to grow <TextInput> because the <TextInput> component doesn't support auto-grow.
We calculate height and width for input when React fired a NativeEvent called onLayout when our hidden  <Text> component rendered

The problem comes with Safari web browser (also in the Desktop application) when initially component is rendered with no value React is not able to fire NativeEvent
And we are not able to calculate the height  of the hidden <Text>  component
Then our <TextInput> component render with max height CSS only

What changes do you think we should make in order to solve the problem?
We just need a value in our hidden <Text> component  to fire onLayout event
It will work when we set a placeholder or if we have any state value, if we do not have a placeholder or state then just an Empty string will work, and later it will change with the state value
File: App/src/components/TextInput/BaseTextInput.js
-      {this.state.value || this.props.placeholder}
+    {this.state.value || this.props.placeholder || ' '}

That issue was created first, so I'll close this as a duplicate.

@bernhardoj i added you as the issue reporter on the other one as you reported it on June 17th

Sweet, thanks!


Optional params in movements(): start, end, limit

Added support for providing optional parameters in movements(): start, end, limit. Same like in other API endpoints.

Can you please increase the version in setup.py.
This modification qualifies for an increment fo the patch increase.
Semantic versioning is described here : https://semver.org/


Merge ?

Hello!
Each time I upload a file and then revise again (and push), I always have a problem with 'merge'. The first time Push is fine (when I upload a new file), and then I revise and push, doesn't work.. I deleted one file and want to revise it with another one, but could not do.. Can you please help me?

Oh I guess, it is somehow resolved if you can see the file 'Step1_table_Oct2020.R' ?

Hmmm, are you sure you're still working on the master branch?
A merge commonly occurs when you want to push a branch to the master.


added binary search tree implementation

hi @A7abhilash please move this file into cpp folder and then send PR


Clean-up Python #4815 - P8.9: ML\NaiveBayes

This is the sub-PR breaking from the large PR 4815: https://github.com/rdkit/rdkit/pull/4815

Hi @IchiruTake : thanks for all the contributions you're making! We do appreciate them, but it's a bit overwhelming at the moment. @gedeck and I are working through the PRs, but it does take time, so could you please wait to submit any more new PRs until the existing ones have all been merged?
Thanks!

Hi @IchiruTake : thanks for all the contributions you're making! We do appreciate them, but it's a bit overwhelming at the moment. @gedeck and I are working through the PRs, but it does take time, so could you please wait to submit any more new PRs until the existing ones have all been merged? Thanks!

Sorry for my late response, I have just noticed it recently. The final PR #4966 would be the last PR I can submit ahead in the PR-series 4815 as the schedule request from my university. Following your request, I decided to drop the cleanup in sping module. You can see my note in the PR 4966 above.
It is very hard for me to do all these clean-up stuffs before the large schedules coming.


s3 multipart upload something has issue

Problem description
i tested with open("s3://","wb")  to upload  many files each one with size above 400mb into s3. Sometime it fail with below error
 botocore.exceptions.ClientError: An error occurred (NoSuchUpload) when calling the CompleteMultipartUpload operation: The specified multipart upload does not exist. The upload ID might be invalid, or the multipart upload might have been aborted or completed
and if i reupload it, it will be successful. Anyone else experience this? It only happen for multipart files, if the file is small size then no issue at all.
i'm using smart_open[all]==4.2.0

Please post a reproducible example. Without it, we can't help you.

We also encounter this error very rarely after 100k+ sequential writes to s3. Fix seems to retry completing the multipart upload when this error occurs: https://github.com/peak/s5cmd/pull/470
botocore.errorfactory.NoSuchUpload: An error occurred (NoSuchUpload) when calling the CompleteMultipartUpload op eration: The specified upload does not exist. The upload ID may be invalid, or the upload may have been aborted  or completed.


Revert "fix: upgrade node default runtime to 14"

Reverts aws-amplify/amplify-cli#7700
Node JS 14.x does not support the ZipFile Attribute yet causing failing e2e tests
Invalid request provided: The ZipFile attribute is not supported for the runtime 'nodejs14.x'

Codecov Report

Merging #7763 (ce42e1a) into master (aadc915) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #7763   +/-   ##
=======================================
  Coverage   52.67%   52.67%
=======================================
  Files         549      549
  Lines       27677    27677
  Branches     5354     5354
=======================================
  Hits        14578    14578
  Misses      12116    12116
  Partials      983      983

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aadc915...ce42e1a. Read the comment docs.

I did not see this issue :( :

https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/80

@jhockett  - looks like you can now safely upgrade to Node 14.


[Feature] Cleanup - pollForProcessingImage, preserveTransformations

Feature Request
Is your feature request related to a problem? Please describe.
Update package to use newly abstracted pollForProcessingImage and preserveTransformations
import { pollForProcessingImage } from '@cloudinary-util/util';

and preserveTransformations no longer needs to be maintained within the framework
https://github.com/cloudinary-community/cloudinary-util/pull/184
https://github.com/cloudinary-community/cloudinary-util/pull/187
Updates done in Next Cloudinary:
https://github.com/cloudinary-community/next-cloudinary/pull/504

oops, dupe of https://github.com/nuxt-modules/cloudinary/issues/229


Fix NaN not to be cast to int64

ref: https://github.com/DirectXMan12/k8s-prometheus-adapter/issues/280
This pull-request prevents the NaN from being cast to int64. This is because the value of histogram_quantile(), which returns a NaN when the request is 0, such as calculating a custom metric for 95%tile, will overflow and returned -9223372036854775808m.

LGTM, this is reasonable, thank you!


Create regex-matches condition method

Closes #2324
I went with the regex-matches name since it seemed everybody was OK with it in the issue discussion.
With .NET regexes, it is possible to specify options inline as explained here so the options parameter shouldn't be necessary. I find it more usable if it exists but it creates some kind of redundancy and adds some code to parse the options string. Should we leave it ? If yes, should we make it optional ?
At the moment, all the options you can use inline are supported by the options parameter.

With .NET regexes, it is possible to specify options inline as explained here so the options parameter shouldn't be necessary.

was thinking about this. Maybe the options parameter sense in the following cases:

we could use longer names (the full names)
we configure from the API

AFAIK it already works if you create an property RegexOptions Options on the class - not sure, it works for targets and layout renderers

OK so if I get this correctly, we could have an optional options parameter using the full names of the RegexOptions enumeration values separated by spaces and thus support all the possibilities. For example
regex-matches('foo', '^foo$', 'ignorecase') or
regex-matches('foo', '^foo$', 'ignorecase multiline')
This also allows to support compiled regexes without imposing it :
regex-matches('foo', '^foo$', 'ignorecase compiled')
I'm sorry but I didn't understand what you meant by

we configure from the API
Aren't the expressions always specified as strings and then parsed as ConditionExpression ?

OK so if I get this correctly, we could have an optional options parameter using the full names of the RegexOptions enumeration values separated by spaces and thus support all the possibilities. For example
regex-matches('foo', '^foo$', 'ignorecase') or
regex-matches('foo', '^foo$', 'ignorecase multiline')
This also allows to support compiled regexes without imposing it :
regex-matches('foo', '^foo$', 'ignorecase compiled')
I'm sorry but I didn't understand what you meant by

yes that's correct. (except is should be a comma instead of space) - see https://github.com/NLog/NLog/blob/74e6e26fb50bc1a1396ed8dbeb8e1ec9b31d88e3/tests/NLog.UnitTests/Config/TargetConfigurationTests.cs#L522
But i'm not sure a flag enum property works ConditionMethod, it works for Layout and LayoutRenderers

I modified the initial version and tried to take into account all the remarks.

\0/
Could you please add some docs? I think here is the best place, please add "introduced in NLog 4.5"
https://github.com/NLog/NLog/wiki/When-filter#condition-functions
Thanks for the great work!

@304NotModified Thank you for your help !
To documentation is updated.

Thanks! Nice feature!

NLog became much stronger.
THANK YOU VERY MUCH!!! Good work @MikeFH, thanks to @304NotModified.

:)
this feature is online: https://www.nuget.org/packages/NLog/4.5.0-rc02


Use Salt gitfs to keep master synced with repo

Docs: https://docs.saltstack.com/en/2015.5/topics/tutorials/gitfs.html
Salt has a built-in backend that uses a git repo (such as this one) to provide the files in the /srv/salt tree (the fileserver).
We should use it instead of manually git pulling on the master.

+1
Is this feature new? I don't remember seeing this back when we set this up.

This has been around for a long time, although I'm not sure exactly when it was added (at least as old as 2014.7, possibly as old as 0.16.3 based on a quick skim of the docs).
I'm not yet sure about how this would interact with the workflow of iterating on changes directly on the master.

If we don't have a local filesystem we can edit, what's the procedure for doing test highstate against the live system? There are a few pieces (e.g., the web hooks, buildbot, etc.) that we have no testing for and, in practice, I've needed to do and roll out 3 or 4 fixup tries before I actually get the original patch that was r+'d live.
cc @edunham

We can pass a command line flag to the salt command to point to a different configuration directory, which lets us set up test configurations that point at local files to use interactively. This way, regular salt commands continue to use the gitfs fileserver backend, and we can set up separate temporary directories for testing. I'd recommend putting such directories in /tmp so they don't stick around too long.
That being said, testing in production makes me uneasy and I'd prefer to build a better testing story for our configurations, both making testing inside Vagrant easier and adding more automated functional tests. It's just too easy to forget to pass a command line flag to Salt (I've done this more times on my own setup than I'd like to admit).

Hit the wrong button, whoops.

FYI, I've been looking into this for #350. The solution I mentioned above (custom config directories) won't work, but I've found an alternative solution. See #350 for the details.


Issue #2252, added usePointStyle option to allow label boxes to match…

Solution to this issue: https://github.com/chartjs/Chart.js/issues/2252
New option added: options.legend.labels.usePointStyle (Boolean)
When true, legend "boxes" will be drawn in the same shape as the pointStyle specified for the data.
Simple screenshot for clarity.

+1 to merge.
@slinhart nothing jumped out at me while looking at this.
CC: @tannerlinsley @derekperkins @zachpanz88 @simonbrunel

This looks awesome (assuming it works as defined), but could you please fix that merge conflict @slinhart?

@zachpanz88 merged :grin:

Looks good to me!  Very cool!

Do these merged commits on pull requests ever require the version number be bumped? I was previously using the npm version of chart.js and it is also version 2.1.6, but doesn't include the changes in this issue.

@neilmonroe this will be included in the next release


Hydration mismatch when using v-show and custom style attribute

Vue version
3.4.5
Link to minimal reproduction
https://stackblitz.com/edit/github-dyqiua
Steps to reproduce
Use
test
 in your component and SSR it.
Check the console for hydration errors
What is expected?
No hydration errors
What is actually happening?
[Vue warn]: Hydration style mismatch on

  - rendered on server: style="display:none;width:auto;"
  - expected on client: style="width:auto;"

The server-output it actually correct though.
System Info
No response
Any additional comments?
Possibly related: https://github.com/vuejs/core/issues/10000, https://github.com/vuejs/core/pull/10004

I encounter the same thing.


Retry downloading the benchmarks datasets

Downloading the benchmarks datasets is failing more and more often; thus, instead of fixing the issue, I thought we could retry multiple times.

Soooo... Should we merge, or should I sleep?
I would say we can merge it like that, and if it doesn't solve anything, then we add a sleep in it 👀


Parameterised terms: fixed term compatibility + spurious pyright errors

Phew, this ended up being a complicated one!
Let's start with the easy stuff:

Disabled spurious pyright errors due to incompatible between pyright and eqx.AbstractVar.
Now using ruff.lint and pinned exact typeguard version.

Now on to the hard stuff:

Fixed term compatibibility missing some edge cases.

Edge cases? What edge cases? Well, what we had before was basically predicated around doing
vf, contr = get_args(term_cls)

recalling that we may have e.g. term_cls = AbstractTerm[SomeVectorField, SomeControl]. So far so simple: get the arguments of a subscripted generic, no big deal.
What this failed to account for is that we may also have subclasses of this generic, e.g. term_cls = ODETerm[SomeVectorField], such that some of the type variables have already been filled in when defining it:
class ODETerm(AbstractTerm[_VF, RealScaleLike]): ...

so in this case, get_args(term_cls) simply returns a 1-tuple of (SomeVectorField,). Oh no! Somehow we have to traverse both the filled-in type variables (to find that one of our type variables is SomeVectorField due to subscripting) and the type hierarchy (to figure out that the other type variable was filled in during the definition).
Once again, for clarity: given a subscriptable base class AbstractTerm[_VF, _Control] and some arbitrary possible-subscripted subclass, we need to find the values of _VF and _Control, regardless of whehther they have been passed in via subscripting the final class (and are get_args-able) or have been filled in during subclassing (and require traversing pseudo-type-hierarchies of __orig_bases__).
Any sane implementation would simply... not bother. There is no way that the hassle of figuring this out was going to be worth the small amount of type safety this brings...
So anyway, after a few hours working on this far past the point I should be going to sleep, this problem this is now solved. This PR introduces a new get_args_of function, called as get_args_of(superclass, subclass, error_msg_if_necessary). This acts analogous to get_args, but instead of looking up both parameters (the type variables we want filled in) and the arguments (the values those type variables have been filled in with) on the same class, it looks up the parameters on the superclass, and their filled-in-values on the subclass. Pure madness.
(I'm also tagging @leycec here because this is exactly the kind of insane typing hackery that he seems to really enjoy.)
Does anyone else remember the days when this was a package primarily concerned about solving differential equations?

This is the greatest Man vs. Code debacle triumph GitHub has witnessed. @patrick-kidger exhibits the heart of a beast with one-liners like:

Edge cases? What edge cases?

Any sane implementation would simply... not bother. There is no way that the hassle of figuring this out was going to be worth the small amount of type safety this brings... So anyway, after a few hours working on this

Pure madness.

Does anyone else remember the days when this was a package primarily concerned about solving differential equations?

Seriously, though. I'm extremely impressed by the get_args_of() iterator on display here. @beartype should (probably) begin behaving similarly. Currently, I am lazy and given to frivolity. :smile:
Oh – and thanks so much for supporting @beartype's ad-hoc __instancecheck_str__() non-standard. I'm (probably) going to call a distinguished gathering of the runtime typing community together next month. We have much to discuss! Time grows nigh. Ominous clouds gather, little kittens mewl, and other harbingers of sorrow. Python 3.13 approaches and with it, significant changes for runtime typing. I'll also introduce __instancecheck_str__() there and see if we can't gently convince typeguard and Pydantic to assimilate. :monocle_face:


Render tourism=camp_pitch

It would be great if tourism=camp_pitch is rendered, maybe even with its refnumber if mapped.
A (faint) border could be something appropriate.
Somehow related to me wanting to render a detailed map of campsites...

Good suggestion, thank you!

Hi, @habi! I've fixed a bug with the ref tag and supported tourism=camp_pitch with simple outline if this is an area.
Now it should look like this:
map-machine render -s 600,400 -c 46.80506/6.71758 -z 19

map-machine render -s 600,400 -c 46.80506/6.71758

Using an icon
If we want to use an icon, we should specify its minimal zoom level.  I think, 19 is most appropriate.

However, due to some limitations of currently used scheme format, for zoom levels 18 and smaller, icons will disapear along with refs.

I think it's very nice that camp pitches are now rendered as faintly visible ways, thanks for implementing this so quickly!


Re-add simpler public-registry e2e test

Description
Adds a e2e test for public-registry images, just to verify that the operator configures them correctly, so they start up.

Uses the ECR public-registry
Always uses the latest versions available on said registry

Has also a bit of a refactor for semver conversion.
How can this be tested?
run make test/e2e/publicregistry
Checklist

[x] Unit tests have been updated/added
[x] PR is labeled accordingly with a single label
[x] I have read and understood the contribution guidelines

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.00%. Comparing base (5a17ed2) to head (89a70a0).
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2822      +/-   ##
==========================================
+ Coverage   66.98%   67.00%   +0.02%
==========================================
  Files         249      250       +1
  Lines       13646    13649       +3
==========================================
+ Hits         9141     9146       +5
+ Misses       3698     3697       -1
+ Partials      807      806       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix circular dependency on velox_dwio_common

This fixes a circular dependency. The newer velox_dwio_common_compression doesn't need to link to velox_dwio_commonof which it is also a part.

Closing as fixed by another PR.


Does Deployment Slot Have Private Endpoint Feature?

Does Deployment Slot Have Private Endpoint Feature?
[Enter feedback here]

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

ID: 2174e399-063b-129a-eef6-2c49a67fd4e2
Version Independent ID: 6cb95aa6-fb50-b966-4c9a-01e0718d0bcb
Content: Connect privately to an Azure Web App using  Private Endpoint
Content Source: articles/app-service/networking/private-endpoint.md
Service: app-service
GitHub Login: @Ericgre
Microsoft Alias: ericg

Hello,
yes, but not available yet in the portal, we will update it soon

Thank you!
So I guess I could use powershell or CLI or rest api for deployment slot private endpoint creation.
Can you please point the document link?
Thank you!

@Ericgre  Any update on the question? Can you please share the document link for creating private endpoint for deployment slot?

Sorry, please give me some time, I need to doublecheck, where we are in the release of the API

@Ericgre  Thank you so much for the prompt reply, we have critical production release depends on the private endpoint feature, and especially deployment slot support, we would like to make decision based on whether deployment slot private endpoint feature is available, so this is really important question.
Appreciate you help and looking forward to your feedback!

Hello, we are really sorry but we found a bug that's why is not available in production now, we are trying to fix it, not ETA yet, I'll update the doc, but for sure it's in our plan to provide the private endpoint in front of slots. if needed we can exchange with your customer by mail/teams to provide clarity about the roadmap.

@Ericgre  Thanks you for the confirmation.
Please keep us posted on the date once you have ETA.
Yes, please update the document.
I'm good for now, we have plan B in case can not utilize private endpoint. But we prefer to go with private endpoint if functionality is available.
Thanks!

Thanks for the update @Ericgre .
@RonnieQuan we will proceed to close this thread for now but will continue to update this document when we have new information to provide. If you have are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Autoload Hardcoded subtitle didnt load

This setting just works when the container is a MKV, when you set MP4, the sub didnt load in <IP_ADDRESS> version.

you should give my new post a try...might help.