Add hsv_to_rgb and rgb_to_hsv Jinja2 filters

Description:
Add hsv_to_rgb and rgb_to_hsv Jinja2 filters. HSV is much easier to work with when one wants to traverse the color wheel (in a script or automation).
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Checklist:
If user exposed functionality or configuration variables are added/changed:

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

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

Hi @Diaoul,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

You've checked the documentation checkbox in the PR template but did not provide a link to a PR

You've checked the documentation checkbox in the PR template but did not provide a link to a PR
Had to leave before I could finish this. It's updated now.

I've settled on implementing the HSV to RGB conversion reusing the functions from util.color. It is still possible to downgrade 16 to 8 bits value without precision loss.
I've also added rshift and lshift bitwise operations which are very handful to deal with those conversions.
Here is an example of bloated script that will be obsolete once this PR is merged: https://community.home-assistant.io/t/using-hsv-hsb-to-set-colored-lights/15472
Maybe this PR closes #3968 as well. /cc @mweinelt

I've settled on implementing the HSV to RGB conversion reusing the functions from util.color. It is still possible to downgrade 16 to 8 bits value without precision loss.
I've also added rshift and lshift bitwise operations which are very handful to deal with those conversions.
Here is an example of bloated script that will be obsolete once this PR is merged: https://community.home-assistant.io/t/using-hsv-hsb-to-set-colored-lights/15472
Maybe this PR closes #3968 as well. /cc @mweinelt

I've settled on implementing the HSV to RGB conversion reusing the functions from util.color. It is still possible to downgrade 16 to 8 bits value without precision loss.
I've also added rshift and lshift bitwise operations which are very handful to deal with those conversions.
Here is an example of bloated script that will be obsolete once this PR is merged: https://community.home-assistant.io/t/using-hsv-hsb-to-set-colored-lights/15472
Maybe this PR closes #3968 as well. /cc @mweinelt

I've settled on implementing the HSV to RGB conversion reusing the functions from util.color. It is still possible to downgrade 16 to 8 bits value without precision loss.
I've also added rshift and lshift bitwise operations which are very handful to deal with those conversions.
Here is an example of bloated script that will be obsolete once this PR is merged: https://community.home-assistant.io/t/using-hsv-hsb-to-set-colored-lights/15472
Maybe this PR closes #3968 as well. /cc @mweinelt

Are both of those needed or would number one suffice?
Both what ? If functions then yes I need both if I want to increment hue
for example I need to get the current hue before setting it to an
incremented value.
If color representation, I guess at the low level one is enough but high
level multiple formats would suit most use cases.

Does that answer your question ? If not please elaborate.
Le 19 nov. 2017 7:15 PM, "Anders Melchiorsen"<EMAIL_ADDRESS>a
écrit :

@amelchio commented on this pull request.
In homeassistant/helpers/template.py
https://github.com/home-assistant/home-assistant/pull/10462#discussion_r151872606
:

@@ -487,6 +488,22 @@ def forgiving_float(value):
return value

+def hsv_to_rgb(value):
Would you mind answering my question?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/10462#discussion_r151872606,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATe9BKlLkKvJalvJnLRudxL6kVAvwCzks5s4HAygaJpZM4QWWkY
.

Just like to mention this will help out a lot.  FastLED (a library used by tons of people doing LED strip animations) speaks HSV.  As mentioned by @Diaoul, HSV is great for animations that traverse the color wheel.
In fact, the lack of HSV support is what is keeping me from migrating all my stuff to home-assistant.

I'll work on a new PR then with the hsv_color property, defaulting to conversion from RGB, same for the setter.
It'll be 8 bits (0-255), for 16 bits I'll add hsv_color_16. I won't touch existing code using HSV (some lights use 16 bits H with 8 bits SV).

Should hsv be a property or should it be standalone hue and saturation properties?

I think separate properties make sense, often you will only want to alter the H. However, having to use three keywords to specify a full color puts me off a bit.
About the 8/16 bits, I actually would prefer user-friendly ranges. That is, a 0-360 range for hue and the platform can convert to however many bits it needs. I know that this is not how lights work now, but I don't think they work very well currently :-)

OK for separate properties. Solves the issue of V being brightness and much easier to work with than a list anyway.
I agree 0-360 seems more user friendly but it is really unpractical. FastLED uses 8 bits (or 16 in the future), I think Phillips Hue (and some other components) uses 16 bits. What about saturation then, should it be a float 0.0-1.0?
When you say "the platform can convert" you mean on a component basis? If so, what about "generic" lights, can we enforce that hue is 0-360?
Or maybe add hue, hue_8 and hue_16? This can be achieve with a lot a conversions.

Actually, V isn't brightness same as rgb(100, 100, 100) is a darker version of rgb(255, 255, 255).

With platform I mean for example components/light/hue.py. This is the module that knows which bit size to use and I don't think that information should bleed into components/light/__init__.py (like it currently does for some properties). This does mean that each light will have to be updated individually for HSV support.
We added brightness_pct for a more user-friendly setting and I guess we could use saturation_pct as well?
This is quite complex, I hope more people will participate in fleshing it out.

it should be separate hue, saturation and brightness imo.
(To prevent duplication of brightness)
We actually also should make it so that color temperature and hue are always in sync via built in methods. Or one of these should be ‘none’ when the other is set. (because they control the same characteristics)

@Diaoul HSV===HSB. The V is definitely the same as brightness.
How do you make a darker fully saturated red? You reduce brightness ergo you dim the light.

@NovapaX I know it's the same, but I think it should be different than the global brightness nevertheless. The reason is that brightness information is already duplicated when using RGB. There is the implicit brightness, see my previous comment and the brightness property.
For example you can have rgb(100, 100, 100) with brightness 255 it will still be darker than rgb(255, 255, 255) with the same brightness although it's the same "color" (white).

I see... but 'global' means you're actually controlling a group of lights?
I think there's no point in having a two brightness channels on a single entity.
If you're controlling multiple lights (as in a group) I can see how brightness could be used as a 'global brightness adjustment', but there's no point in controlling the same value on a single entity via two different parameters.

I see... but 'global' means you're actually controlling a group of lights?

By global I mean it's applied after the color.

I think there's no point in having a two brightness channels on a single entity.

What I'm saying is that it's already the case. When you set your light at rgb(127, 127, 127) with brightness at 255 it's actually the same as rgb(255, 255, 255) with brightness to 127.

For what it's worth, HomeKit has "Hue", "Saturation" and "Brightness" -- the "brightness" is basically the "dimmer".
My own code uses the "Brightness" param to control FastLED via "setBrightness".  I peg the "V" in their HSV object to 255 always.
Not sure if that is how it is really supposed to be done, but that is how I've done it.


Windows usage instructions

Can we have some instructions about using tslint on Windows? Tried cscript tslint-cli.js -f myfile.ts but no joy

I've got the same error: Cannot find module './tslint-cli'

Have you got Node.js installed? I'm no expert but this is what I do:
Install Node.js
Log out, and back in (just in case, to set up path)
Open cmd.exe and run 'npm install tslint -g'
From a command prompt, check 'tslint --version' to check it's installed
I think palantir should add some installation instructions, I'd never used Node before TsLint.
Incidentally, for noobs here's a quick and dirty Powershell script to TsLint all your project's ts files (with an exclude list for 3rd party d.ts files etc):
https://www.dropbox.com/s/ne9m3hkag5bnd9r/TsLint files.ps1?dl=0

It's working. My path was pointing to a wrong tslint installation.
Thanks for the help.


ui: Add loading indicator for message edits.

Fixes #16143.

The first commit is great, merged, thanks @ryanreh99!  Posting a few comments on the rest.

I mainly split out the network calls to display a loading indicator when the modal is opened, if we are already performing a move on that topic.
This check would require the message id which would be obtained from the first request.
Similar to currently_deleting_messages.
So instead of a spinner and hiding the buttons at the start, this displays an error text on Submit.

This is great, merged, thanks @ryanreh99!


Upgrade github actions to Node 20

Currently, github actions use v3 of actions/checkout, which internally runs on Node 16 (https://github.com/actions/checkout/blob/v3/action.yml#L90).
This PR upgrades github actions to v4, which internally runs Node on 20 (https://github.com/actions/checkout/blob/v4/action.yml#L102)

@ferhoyos , just noticed this has been sitting for a while.  is there a reason we don't move it forward?

@jshaughn Yes, a PR approval of any of the Kiali maintainers :-)


Add other elements to Filter/Control sidebar

Question
Is it possible to add any component to the Filter/Parameter sidebar?
As far as I understood, only elements which are added as children of controls will be added to the sidebar.
But controls only takes either vm.Filter() or vm.Parameter().
I want to add a dropdown in the sidebar, which I want to control using dash callbacks.
I hope the code example helps to make clear what I want.
Code/Examples
import dash_core_components as dcc
import vizro.models as vm
import vizro.plotly.express as px
from vizro import Vizro

iris = px.data.iris()

page = vm.Page(
    title="My first page",
    components=[
        vm.Graph(
            id="scatter_chart",
            figure=px.scatter(iris, title="My scatter chart", x="sepal_length", y="petal_width", color="species"),
        ),
    ],
    controls=[
       #Here I want to add any component, could also be dcc.Dropdown or any other custom element.
        vm.Dropdown(
            id="my-dropdown",
            ...
        ),
        vm.Parameter(
            targets=["scatter_chart.title"],
            selector=vm.Dropdown(
                options=["My scatter chart", "A better title!", "Another title..."],
                multi=False,
            ),
        ),
    ],
)

dashboard = vm.Dashboard(pages=[page])

Vizro().build(dashboard).run()

Which package?
vizro
Code of Conduct

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

Hi @FSaal 👋
Yes, it's possible to extend the set of allowed types that can be added to the component's field. Here's an example below
# Enables vm.Dropdown to be a Page control
vm.Page.add_type("controls", vm.Dropdown)

Thank you so much for the superfast reply @petar-qb!
Apparently I didn't read the https://vizro.readthedocs.io/en/stable/pages/user-guides/custom-components/#extend-an-existing-component page thoroughly

Thank you so much for the superfast reply @petar-qb!
Apparently I didn't read the https://vizro.readthedocs.io/en/stable/pages/user-guides/custom-components/#extend-an-existing-component page thoroughly


Add a more direct NewScannerReader func.

If the user has an io.Reader, they can now use NewScannerReader to more directly create a Scanner.
Previously, they would be forced to either read all bytes from the reader into a byte slice and use that (which then indirectly gets wrapped by a bytes.NewReader), or copy this func in their code.
Resolves #14. /cc @jingweno

:+1:


Refactor api clients setup

Currently the api definitions are hardcoded in src/plugins/maverick/clients.json.  This is not good for several reasons:

Requires users to edit this file on the filesystem to alter api definitions
Doesn't work out-of-the-box
Can't edit api definitions in the browser as it can't write back to the filesystem.

Maybe create a mechanism for connecting to window.location by default, and then use browser storage for additional?

Listen for -api broadcasts #150

Refactored to remove the hardcoded .json files, in favour of a single default client which is created using the defaults of Maverick FC -api instance (port 6800).
However this is just a sample/default client which will not always work - eg. if just a dev instance of Maverick which will run SITL -api on a different port.  So once the default client is created and stored in vuex, there should be a UI interface that can edit the details of all defined clients, so port/hostname can easily be changed.
We could then store this in local storage, but that only persists within a single browser and per domain name accessed.
@SamuelDudley Perhaps we could persist the api definitions back through the -api and store it locally there, and it can be retrieved as soon as the -api is connected to.  That way we can find -api through broadcast and connect to it, and then -api can upload a list of defined/saved api client instances back to -web.  We could also persist this back to all connected -apis, so effectively replicating the client config and creating a mesh of sorts?

Is it necessary to create replication of client config if we have broadcast on all -api instances?

Perhaps im mixing up two things here:

How does -web find -api backends to connect to?
How do we persists -web user options across multiple sessions?

I'm hoping 1. can be solved with zeroconf as that would help with name collision, etc. If zeroconf is not available from the browser we can make an independent service that runs on maverick (once per maverick instance and exposes the details of all -api instances it can find via zeroconf. e.g. a common web location that all -api instances are exposed by. The port of this process would be common to all maverick installs  (by default) making automated discovery out-of-the-box possible. This assumes we cannot simply zeroconf from the browser.
I see 2. as more of a user management issue e.g. for the user logged into -web, what are the preferences? dark mode, light mode, what -api's do they want connected and visible, etc, etc... (possibly we have the equivalent of named user work-spaces to allow multiple configurations per user).
So yes, these details could be stored and replicated across all -api instances that the user has an account on. It would require that some sort of user settings storage is needed in -api and a method to transmit these back to -web (jwt?)

Fortunately zerconf (mdns) can be done in the browser.  There are lots of projects, these are just two of the first i came across:
https://github.com/agnat/node_mdns
https://github.com/tkurki/dnssd.js

Add a new component for api connections.  Try using a vuetify data iterator to display all connections (will be very suitable with multiple connections).  Each unit should show the connection, state of the connection, and either an expansion or dialog to edit the connection details.

Also create a 'core' vuex module.  A lot of the core stuff is currently in store/index.js, should be broken out into a core module to correspond with plugins/core

@fnoop From my comment above:

I see 2. as more of a user management issue e.g. for the user logged into -web, what are the preferences? dark mode, light mode, what -api's do they want connected and visible, etc, etc... (possibly we have the equivalent of named user work-spaces to allow multiple configurations per user).
So yes, these details could be stored and replicated across all -api instances that the user has an account on. It would require that some sort of user settings storage is needed in -api and a method to transmit these back to -web (jwt?).

Can I confirm that you are after a way to store and retrieve preferences from the -api database?
If so are you okay with -api dumping a big json object back to the browser in response to a user query or do we want to define a settings schema and have everything in its own graphql field?

Is it necessary to create replication of client config if we have broadcast on all -api instances?

This is an interesting question.  Broadcasting -api means that the clients can easily pick up nearby vehicles, and can add each one with the click of a button.
It does however mean that they'll have to re-setup the config for each -web instance on each browser, and as we start to add more -web config that will be a bit of a pain.  It's the same for current GCSs - their config is local to that one instance of the GCS.
But then if you replicate the client config across -apis then it will be 'viral', so if you wanted different groups of vehicles with different config that would have to be managed - eg. each vehicle could belong to a different 'swarm' and config would only replicate within that swarm?

Can I confirm that you are after a way to store and retrieve preferences from the -api database?  If so are you okay with -api dumping a big json object back to the browser in response to a user query or do we want to define a settings schema and have everything in its own graphql field?

So to start with I've added persistence to vuex storage.  This saves the state of vuex to the browser localStorage so it's reloaded each time -web is reloaded in that browser.  There's a 'reducer' in the persistence that restricts it to certain vuex modules (core, cockpit, planner) to start with as other vuex modules don't make sense to persist (and vuex plugins like vuex-router-sync don't like it).
Suggest we use it for a bit and then think about persisting the config back to -api.

New api/client model now mostly in place and looks good.  Still need to:

Add ability to delete existing API
Add test/information to config connections interface
Discover/auto-add new connections from broadcast -api


Deprecation of Landsat bucket on AWS

Hi all, this looks like a great project! I wanted to flag the below as I see you're calling s3://landsat-pds in your example.
https://lists.osgeo.org/pipermail/landsat-pds/2020-December/000178.html

Thanks for the heads-up, @jflasher!  I'm still using MapServer daily at work but this repo could use some TLC from me. For one thing, this repo uses a pretty old version of MapServer. The geosptial community has really rallied around some concepts like COGs (see https://www.cogeo.org/) and things like GDAL-3's COG driver simplifies some of the work required to serve WMS tiles with MapServer.  Leaving this open as I'll address this when I have some more free time.


ndt7: AppInfo should be mandatory for counterflow messages during upload tests

This is a proposal to change the ndt7 protocol specification. It has been discussed with @bassosimone (original author of the ndt7 spec) at https://github.com/m-lab/ndt7-client-go/pull/75.
Currently, both TCPInfo and AppInfo are optional fields for a Measurement object. When the client is uploading, the sender-side rate is overestimated due to buffers and data still "in transit" at the end of the measurement period. To get an accurate rate, the client must rely on Measurement messages periodically sent by the server. However, an ndt7 server today can be compliant without implementing TCPInfo nor AppInfo, which would make the clients blind to how much data has been actually received by the server and unable to show a meaningful rate to the user.
ndt-server currently sends TCPInfo only, which provides network-level byte count, and that's what our clients use. However, there is a significant asymmetry in what clients show: when downloading, the rate is computed at the application level -- (size of WS payloads / elapsed time) while when uploading the rate is computed at the network level -- (bytes received by the server / elapsed time). Clients cannot generally access TCPInfo metrics (most of our measurements come from Javascript-based implementations) so using a network-level rate for the download is not an option, but we can be consistent by showing application-level measurements in both tests.
Making AppInfo mandatory in the spec for counterflow messages (and adding it to ndt-server) would solve both these problems, guaranteeing that the clients get at least one source of accurate measurements and that we're not mixing apples and oranges by providing rates computed at different levels of the OSI model.

It should probably specify a frequency (range) as well.

My understanding is that the use case we are seeking to address is archival storage of goodput measurements.
Please be precise about the source of the following information:

Client visible goodput, upload and download
Server visible goodput, upload and download
Client visible network throughput, upload and download
Server visible network throughput, upload and download

This summary may be helpful for updates to the ndt7 spec or to inform the MSAK design.
I know not all are available. So, which will we regard as authoritative, advisory, part of presentation only or part of archival data? Can we meet the use case? If so, what will we change? If not, what do we need to do instead?


setAlwaysOnBottom will support Windows in the future?

https://zhuanlan.zhihu.com/p/37877070  效果像这种的. Linux setAlwaysOnBottom 是这种效果? 还是我理解错了.

Any updates on this?
Found this on https://stackoverflow.com/questions/527950/how-to-make-always-on-bottom-window

Version 0.3.2 supported


Add builder methods for UiTextureAtlasImage

Objective
Implement builder methods for UiTextureAtlasImage.
Solution
Copy the methods from UiImage  except with an index parameter for new instead of an image handle.

I had forgotten about this PR, I thought that it had been merged ages ago.
UiImage and UiTextureAtlasImage should have the same interface as far as possible, so it needs to be merged.

@ickshonpe once this is rebased / main is merged in I'll merge this PR. CI is failing because of a missing required check.

UiTextureAtlasImage was removed in 135c724; this PR can be safely closed.


Development arivera12

PR ready! Take a look of the source code changes and approve it when ever you can.

I added changes.

Once we we are ready with the PR. I will update the nuget package. Please let me know.

Merged!

https://www.nuget.org/packages/LibreTranslate.Net/1.0.1


Custom usage statistics

Hi,
Coud you please suggest me how can I get view usage statistics not only for all the period, but also for last 1/3/12 months?
Thanks in advance,
Pasha

This is something we're also struggling with. The current statistic supported by the API gets less useful the longer you've had the server up and running. We have some workbooks that have been live for years and currently get 1/10th of the daily views that newer workbooks get, but because it's a cumulative number, this is completely hidden. In the browser, we almost always look at the last 1/3 months and it's really painful this is not supported by the API :/
And it feels completely unnecessary to have to snapshot these values daily and run daily diffs to get the actual usage. Obviously doable, but so unnecessary.


argonaut-codecs upgrade v7.0.0

argonaut-codecs made a breaking change for their error type
src/Data/DateTime/ISO.purs:57:18 - 59:42 (line 57, column 18 - line 59, column 42)

    Could not match type

      String

    with type

      JsonDecodeError

already fixed by #8


Fix remote start discovery

Fixes https://github.com/tesla-local-control/tesla_ble_mqtt_core/issues/124

I have included this change into the #iain-dev branch which I am actively working on to add read state capability. It will eventually find its way into #main, so I will close this
See https://github.com/tesla-local-control/tesla_ble_mqtt_core/commit/9e9796b43160cfc7a809b5e3512bb1948fc5f35d
Thanks a lot for your contribution,
Iain


API uploading twice!

Checks

[X] This template is only for bug reports, usage problems go with 'Help Wanted'.
[X] I have thoroughly reviewed the project documentation but couldn't find information to solve my problem.
[X] I have searched for existing issues, including closed ones, and couldn't find a solution.
[X] I confirm that I am using English to submit this report in order to facilitate communication.

Environment Details
(Windows)
Steps to Reproduce
followed instructions, (Windows)
✔ Expected Behavior
it should upload only once
❌ Actual Behavior
it uploads audio twice as per fiddler trace.

seems with gradio, could you help provide more info about which specific point is the audio uploaded (e.g. corresponding to which part in codebase), TIA


Transform refactor

Edit: Updated to reflect changes as of Aug. 12
This represents a significant change to the Transformable interface and expectations for sources that implement it.
The concept of a "transform" has been codified in the Transform class, which represents an array of operations to be applied against a source. Transforms are considered immutable. Once they are applied, their id and operations should not change.
Limiting sources to performing a single operation at a time maximum was previously a severe limitation for sources such as the JSONAPISource. Each source now has the ability to merge and coalesce operations as it sees fit, and then perform as many of them together as possible (e.g. through a single ajax request).
The _transform method should now return either a TransformResult or a promise that resolves to a TransformResult. Previously, sources were expected to call didTransform as they performed transformations, but this has been deprecated. A TransformResult contains an array of completed operations as well as an array of inverseOperations.
The transformed method has been introduced for sources to call when they experience transformations besides those requested via transform. This is useful both for sources that spontaneously receive data and for sources that perform operations additional to the ones requested. The transformed method takes a single argument: a TransformResult. Any calls to didTransform made outside of a request to transform should now be changed to invoke transformed.
The didTransform event is still triggered when a source changes, either from a call to transform or transformed. Event handlers can expect two arguments: a Transform and a TransformResult.
I realize that this includes a number of breaking changes, but I believe the architecture is now much cleaner and more capable.

@dgeb this looks fantastic! Far simpler and the API aligns far better with the scenarios I've explored.
When you mentioned that you were going to use the signature transform(arrayOfOperations) I did wonder why you hadn't just gone with transform(transformation). Looking at https://github.com/orbitjs/orbit.js/blob/transform-refactor/lib/orbit/transformable.js#L87 I'm not sure what the benefit is, perhaps it would be more consistent to use transform(transformation) everywhere as opposed to transform(operations) in some places and applyTransformation(transformation) in others?
I've only had a quick look over, will have to digest fully a little later on.

@opsb thanks for the initial review! I considered changing the signature of transform as you suggested because I like the symmetry. It would be a trivial change but would require clients to do slightly more work. I'm definitely still open to the idea.

Aside from symmetry the other benefit is that more information can be added to the transformation without changing the signature. Admittedly I can't think of any particular  use cases off the top of my head(maybe related to tracking, hinting or optional information).

Come to think of it, the information for vector clocks would need to live somewhere.

@opsb yeah, there are definitely cases that call for applyTransformation. I only meant transform as a convenience method (it does internally call applyTransformation). But I'll seriously consider just changing the signature of transform instead (and eliminating applyTransformation).

In that case perhaps rename applyTransformation(transformation) => transform(transformation) and transform(ops) => transformOps(ops)? Long term I suspect transform(transformation) will be the one that endures/covers more scenarios but transformOps is still available as a convenience for now.

@opsb seems good - let me try this out :+1:

Do you want the changes from firebase associated with the original transformation (triggered by the call to source.transform()? Or do you expect these changes to be received after that transformation is resolved?

Because changes are coming over the websocket (which may be coming from local or remote users) the original call to source.transform() has already returned and the original transformation isn't available (note that it's not possible to use the source in a blocking configuration). I create new Operations as changes are received from firebase (firebase represents the datastore as JSON and you can attach listeners to any point in the tree), I then bundle Operations together by checking for dependencies between them (e.g. a record includes a link id but the related record hasn't been loaded yet). I currently emit these Operation together in a sequence that takes into account their dependencies(using multiple calls to didTransform). I would now construct a Transformation/TransformationResult and emit that.
It might be worth us having a chat about my scenario, the use of websockets make the requirements pretty different. I'm also considering doing a rewrite of orbit-firebase that's based around using record/relationship objects internally for tracking state (it needs to keep track of things like whether listeners have been attached to particular points in the firebase JSON tree and what the requested 'includes' are for a record). I'm aiming to produce a Source that has the record/relationship layer and then an adapter layer to hook up to firebase (or potentially rethinkdb :) ). Given the prospect of a rewrite now's a good time to reconsider my general approach.

It might be worth us having a chat about my scenario, the use of websockets makes the requirements pretty different to the JSON API source.

Sure - would be glad to! Let's coordinate on gitter or irc.
As for refactoring of this PR, I've been thinking it over and am planning the following:

decoupling TransformResult from Transformation (which might work best renamed to just Transform)
allowing transform to accept either a Transform instance or operations (which would be used to construct a Transform)
removing applyTransformation
transformed still accepts a TransformResult
didTransform emits both Transform and TransformResult objects

I'm wondering if transform result should be:
new TransformResult(transform, inverseTransform)

and then
didTransform(transformResult)

another option would be to do away with TransformResult completely and simply emit
didTransform(transform, inverseTransform)

@opsb There are really three different sets of operations associated with a transformation - the operations that were applied, the operations that were completed, and the inverse of the completed operations. Maybe the applied operations aren't actually important in didTransform, but what is important is the ancestry info. I'll try out some options here ...

I've gone ahead with the changes mentioned above and will consider further refactoring.
To summarize:

Transformation has been renamed to Transform.
Transform no longer contains a reference to an associated result.
Transformable#transform accepts a transform OR an array of operations.
Transformable#transformed accepts a TransformResult.
The didTransform event sends a Transform and a TransformResult.

In the case of a call to transformed, an empty Transform is created so that didTransform listeners can spawn related transforms.
At this point, it would be easy to transition to didTransform sending results as transform and inverseTransform (instead of TransformResult) and not send the applied transform at all. Will think on this ...

@opsb There are really three different sets of operations associated with a transformation - the operations that were applied, the operations that were completed, and the inverse of the completed operations.

@dgeb I was thinking the transform in didTransform(transform, inverseTransform) would contain the operations that were applied as opposed to the transform passed to transformable.transform(transform).
In my experience the transform applied and transmitted are always the same but I recall you did mention a scenario a while back where they differ, can you refresh my memory?

@opsb maybe we should reset the terminology at this point:

"requested" transform - the transform requested via a call to transform( requestedTransform )
"applied" transform - the actual transform applied to a source
"inverse" transform - the inverse of the applied transform

It's possible that the applied transform will differ from the requested transform. For instance, a request might be made to update a record's attribute which, upon inspection of the source's cache, doesn't actually need to be updated. In sources which don't have a cache, there won't be any pre-processing, so the applied and requested transforms should probably match.
In source's that spontaneously emit didTransform events without a corresponding call to transform, the requested transforms are effectively null.
Currently, the didTransform method emits the requested transform, as well as a result that contains both the applied and inverse operations. I'm considering a refactor that emits only the applied and inverse transforms, such that the ancestry information is tracked on the applied transform.

@dgeb :+1: for the terminology

For instance, a request might be made to update a record's attribute which, upon inspection of the source's cache, doesn't actually need to be updated.

Given that sources can be connected in a graph it's possible that the next source will need to apply the operation, in this case shouldn't we transmit the original Transform? Only applying some operations seems like an internal optimisation for the source, don't we simplify things if we apply the same transform consistently to each source (where they can each decide whether to skip operations or not)? By keeping the transform intact as it propagates it makes things like vector clocks possible (otherwise you'd have to reset the vector clocks every time a source skipped a couple of operations and generated a new Transform).
Something else occurred to me, couchdb's replication protocol makes use of a global database revision. I'm not sure if that would work with multiple sources (as opposed to trying to synchronise 2 databases in the couchdb case) but it's an example of when we might want to include information that doesn't sit in the transform or inverseTransform so it's an argument for a TransformResult.

I've just pushed significant changes to this branch that treat transforms as immutable. Sources now track whether they've applied an individual transform, and they need to create additional transforms if they perform additional work while processing a transform.
For example, a JSONAPISource may receive additional data (say a server-generated ID) when adding a record. This source must now call transformed to ensure that this change is emitted as a replace operation distinct from the original add operation requested.
I've updated this PR's comment to reflect these changes.

This is all looking pretty awesome!

Generally looks great! The simplified API makes everything far clearer. It's great to see the implementation simplifying down and I suspect there will be more of this to come as things settle into place.

@opsb @gnarf thanks for the review! I've pushed some fixes based on your comments. Glad it's looking generally good to you both.

Let's take this in and do any further improvements in new PRs.
We should coordinate and do a "documentation" pass on everything so that we can make sure we have our interfaces documented.

Sounds good @gnarf :+1:


Force iframe refresh after Eos deployment

If we deploy something then people who don't refresh Phosphor.me will watch as playlist generation silently fails because the older workers are gone from Eos.

This was fixed with #225; we simply force workers to load immediately and cache them for a long time. This way, the worker won't be lost from the page session if the server updates. Webpack filenames are custom per build (include hashes) so the cacheing doesn't break anything.


Downgrade tendermint to v0.34.0

Because of celestia-app dependencies, tendermint has to be downgraded to v0.34.0 to be able to use optimint in cosmos-sdk.

Codecov Report

Merging #119 (ef22978) into main (9807b61) will increase coverage by 0.27%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #119      +/-   ##
==========================================
+ Coverage   57.29%   57.57%   +0.27%
==========================================
  Files          24       24
  Lines        1967     1961       -6
==========================================
+ Hits         1127     1129       +2
+ Misses        726      719       -7
+ Partials      114      113       -1

Impacted Files
Coverage Δ

rpcclient/local.go
25.25% <ø> (+0.41%)
:arrow_up:

mempool/clist_mempool.go
80.00% <100.00%> (-0.05%)
:arrow_down:

node/aggregator.go
67.00% <0.00%> (+3.00%)
:arrow_up:

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 9807b61...ef22978. Read the comment docs.


Drop UWP?

Summary
No idea what the real future for UWP is.  I have never once used UWP in a professional setting, so it costs me time to support something I don't use.  Ultimately, I consider webassembly to be a much more appealing model than anything on windows at this point
Some of the options being considered are:

Consider moving issues & feature requests to a sponsor only model
Continue to offer it, but close down issues & feature requests for it
Drop UWP 100% from source, focus on webassembly, android, & iOS

API Changes
None
Intended Use Case
Focus on other areas... consider WinUI long term if it proves itself.

I use UWP all the time. It is easy to create a proof of concept and zip it up and send it to colleagues.
Also supporting tools  (especially for Bluetooth)  are easy to create and share with UWP.
Instead of going through the whole process of registering an app with Apple or Google and then adding test users so they can get a tool or a prototype that we don't know if it will be a real app it is too much hassle. Especially with Apple that the test user has to be a member of the company even though they don't need access to App store.
My though is as long as Xamarin supports it it is easy to use it and reuse Xamarin libraries to use it.
With MAUI then whatever MAUI will supports for windows, UWP, WinUI, Flutter, ...
For webassembly a lot of companies don't like to use a browser, for security reasons, for apps that are internal or need speed (especially medical and financial).

If Windows is not supported? This is not interesting to me as I use Xamarin Forms just because we can create all apps in one go. The UWP app on the client is easy to distribute and appreciated from the LOB users ..continue their work on a bigger screen.
Working in a browser does not give the user the same experience or options.

I can see where you're coming from. Ever since we started with Xamarin.Forms the UWP-support seems abysmal, even from Microsoft themselves. I'm hoping MAUI will switch the Windows target to WinUI, but infos regarding that are pretty ambiguous.
For the time being we're tied to UWP though and need the platform to be supported, including background tasks in our use case.
So yeah, UWP support would be sorely missed until we can migrate to greener pastures...
To be honest: We thought UWP support was already dropped, since the Shiny.Support.UWP is already unlisted on NuGet and this is a necessary package for UWP support, isn't it?

@DDHSchmidt The way UWP is implemented has changed and is shown in the sample application within this repo.  That nuget package is no longer needed

To anyone posting, I'm not interested in you losing interest in this library because I don't support UWP (unless you are a higher tier sponsor).  I'm more interested in the scenarios of what benefit it would be to all of us.  MKGNZ has given 2 good points that I consider "of value".  Please keep your posts relevant to this.

I won't be dropping UWP, but support/issues for it are going to move to a sponsor only in the future


Clarify use of C# extension without C# Dev Kit

In addition to the clarification of the dependency direction mentioned in https://github.com/dotnet/vscode-csharp/issues/6171 I would really appreciate if the description of the C# extension includes even more instructions.

While it is possible to use the C# extension as a standalone extension, we highly recommend using C# Dev Kit.

Installing C# Dev Kit will automatically install this extension as a required dependency.
...
...

Please add another list of 1./2./3. instructions how to use this extension without C# Dev Kit!
I assume (but I am not sure) it would use OmniSharp instead, just like version 1 of the extension.

It is totally possible to use the C# extension by itself.  There are two possible modes that the C# extension runs in when devkit is not installed.

Roslyn LSP mode - this is the new default in 2.x.
O# mode (via the dotnet.server.useOmnisharp option)

We generally recommend using Roslyn LSP instead of O# mode and should generally work for most modern .net projects.  There are a few known parity gaps between Roslyn LSP and O# (see https://github.com/dotnet/vscode-csharp/issues/5736).  If you're hitting any of those cases you'll have to switch to O# until we resolve those issues.
Assigning to @mikadumont to see if we need any doc updates.

As far as I understand it Roslyn LSP mode is provided by the C# Dev Kit extension. Unfortunately this extension is not open source with a permissive license but brings license terms which I, as an "enterprise" user, currently don't want to accept (because I would have to pay the full price of Visual Studio Professional 2022 to use Visual Studio Code plus C# Dev Kit).
In version 1 of the C# extension OmniSharp was installed by the extension. Is this still the case for version 2 of the C# extension? Or do I have to install OmniSharp myself somehow?

source generator does not work if dotnet.server.useOmnisharp is not used. #6373


Update zh translation.

Update zh translation.

Directly copied translations are removed. Please check again.

Thank you for contribution.


Migrate from jest to vitest

In order to make our tests faster, we should migrate from jest to vitest

I am working on https://github.com/swarmion/template/pull/175.
Migrating this repo will be my next task 🪨

Fixed in #265


Usage with Coffeescript

I had already install coffee-script and coffee-loader,  It doesn't works.
webpack built 3dfcf2ef9a16589d32fa in 4098ms
Hash: 3dfcf2ef9a16589d32fa
Version: webpack 1.12.14
Time: 4098ms
 Asset     Size  Chunks       Chunk Names
app.js  1.04 MB       0       app

ERROR in ./src/components/Hello.vue

  error    Parsing error: Unexpected token :
  /home/xmrg/share/wechat-anonymous-moments/src/components/Hello.vue:9:7
    data:->
         ^

✖ 1 problem (1 error, 0 warnings)

Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  21.1 kB       0
webpack: bundle is now VALID.

Hello.vue:
<template>

{{ msg }}

</template>

You need to disable eslint in webpack's preLoaders.

Thank you !!!!!!!


 It would be better if we separated the folder into another repo. Benchmarks that the tests need can live inside tests/.

New benchmarks can include the followings

Veri-Q
MQT-QMAP
PyZX


Make all offxml files compatible

@ChayaSt attempted to run the example from the README and was running into a weird error, that initially I wasn't able to replicate, but then tried a slightly different version of the same code and we were able to isolate the issue.
We started from a new conda environment with:
conda create -n chaya_test python=3.6
conda activate chaya_test
conda install --yes -c conda-forge -c omnia openforcefield
conda install -c openeye openeye-toolkits
conda install ipython jupyter

Then using the example we made an OEMol from a smiles and loaded the offxml file from the conda installation.
smiles = 'Cc1cccc(c1C)C'
new_mol = oechem.OEMol()
oechem.OESmilesToMol(new_mol, smiles)
oechem.OEAddExplicitHydrogens(new_mol)
FF_filename = get_data_filename('forcefield/Frosst_AlkEthOH_parmAtFrosst.offxml')
ff = forcefield.ForceField(FF_filename)
top, syst, pos  = ff_utils.create_system_from_molecule(ff, new_mol, verbose = False)

This gives this rather confusing error:
Traceback (most recent call last):
  File "test_chaya_error.py", line 15, in <module>
    top, syst, pos  = ff_utils.create_system_from_molecule(ff, new_mol, verbose = False)
  File "/Users/caitlinbannan/miniconda3/envs/chaya_test/lib/python3.6/site-packages/openforcefield/typing/engines/smirnoff/forcefield_utils.py", line 98, in create_system_from_molecule
    system = forcefield.createSystem(topology, [mol], verbose=verbose)
  File "/Users/caitlinbannan/miniconda3/envs/chaya_test/lib/python3.6/site-packages/openforcefield/typing/engines/smirnoff/forcefield.py", line 1022, in createSystem
    force.createForce(system, topology, verbose=verbose, **kwargs)
  File "/Users/caitlinbannan/miniconda3/envs/chaya_test/lib/python3.6/site-packages/openforcefield/typing/engines/smirnoff/forcefield.py", line 1499, in createForce
    _check_for_missing_valence_terms('HarmonicBondForce', topology, bonds.keys(), topology.bonds())
  File "/Users/caitlinbannan/miniconda3/envs/chaya_test/lib/python3.6/site-packages/openforcefield/typing/engines/smirnoff/forcefield.py", line 1207, in _check_for_missing_valence_terms
    raise Exception(msg)
Exception: HarmonicBondForce: Mismatch between valence terms added and topological terms expected.
Topological atom sets not assigned parameters:
                        (1, 2) :     0      C2     0      C3
                        (0, 1) :     0      C1     0      C2
                        (6, 7) :     0      C7     0      C8
                       (3, 13) :     0      C4     0      H5
                        (5, 6) :     0      C6     0      C7
                        (4, 5) :     0      C5     0      C6
                       (4, 14) :     0      C5     0      H6
                        (1, 6) :     0      C2     0      C7
                       (2, 12) :     0      C3     0      H4
                        (2, 3) :     0      C3     0      C4
                        (3, 4) :     0      C4     0      C5
                        (5, 8) :     0      C6     0      C9
topology_set:
{(5, 6), (8, 19), (1, 6), (0, 10), (2, 12), (7, 16), (5, 8), (1, 2), (6, 7), (7, 15), (8, 20), (0, 11), (3, 13), (4, 5), (4, 14), (2, 3), (0, 1), (8, 18), (7, 17), (0, 9), (3, 4)}
assigned_set:
{(7, 15), (8, 20), (0, 11), (8, 19), (7, 16), (0, 10), (8, 18), (7, 17), (0, 9)}

If I use the direct path to the github version of Frosst_AlkEthOH_parmAtFrosst.offxml with the script below there are no problems:
smiles = 'Cc1cccc(c1C)C'
new_mol = oechem.OEMol()
oechem.OESmilesToMol(new_mol, smiles)
oechem.OEAddExplicitHydrogens(new_mol)
# using complete path to my github cloned openforcefield package
FF_filename = "~/github/openforcefield/openforcefield/data/forcefield/Frosst_AlkEthOH_parmAtFrosst.offxml')
ff = forcefield.ForceField(FF_filename)
top, syst, pos  = ff_utils.create_system_from_molecule(ff, new_mol, verbose = False)

Also, if you use FF_filename = get_data_filename('forcefield/SMIRNOFF99Frosst.offxml') there is no problem. We need to make sure that

All offxml files in github and the conda versions are useable and up to date with whatever the current file format is.
Every example in our READMEs can be run as written!

@ChayaSt @j-wags @jchodera @davidlmobley Here's the details of what we were posting about on #smirnoff today.

It's worth mentioning that the topology branch has started modifying the spec a bit, by doing things like adding a ToolkitAM1BCC tag, and changing the NonBondedForce/vdW cutoff attrib from a format like 'cutoff' = '8.0*angstrom' to 'cutoff_unit'='angstrom', 'cutoff' = 8.0
Example of old spec: https://github.com/openforcefield/openforcefield/blob/master/openforcefield/data/forcefield/Frosst_AlkEthOH_parmAtFrosst.offxml#L48
Example of new spec: https://github.com/openforcefield/openforcefield/blob/topology/openforcefield/data/forcefield/smirnoff99Frosst.offxml#L307

@bannanc, which bad offxml file was it finding before you debugged it? Was it bundled in the conda package, or was it picking up a file from a different installation/source?

Is it clear that this is mixing new (SMIRNOFF 1.0) and old (SMIRNOFF 0.1) specs?

At a glance, I don't think this problem is arising from mixing the specs. It just came to mind that offxml files in the master branch are being changed, and at some point we will need to manually merge the topology branch back in, adding those changes. I'll update my previous post to clarify.

@j-wags I didn't double check this, but I have to believe the bad file is in the conda installation because it happened in clean conda environments on mine and Chaya's computers.
I'm pretty sure the file, Frosst_AlkEthOH_parmAtFrosst.offxml, was created so we could reproduce bugs in parm@Frosst with the SMIRNOFF format early on when we were verifying that the format was working the way we wanted. So this file isn't necessarily that important.
The bigger problem here is that we need to make sure examples and code snippets in README's can be ran as written, especially in conda and stable releases. I found an issue in one of the examples as well, I'll post a separate issue for that one, but we really need to be checking examples and snippets.

Overhauling all the examples is a big job, though important!
It would be awesome if there was a way we can automate testing of all the examples we provide.

I know its a big job, but at the least the first example in our home README should work, which is what Chaya was using and it doesn't.

We can fix that specific example by switching it to smirnoff99Frosst instead of Frosst_AlkEthOH_parmAtFrosst.offxml. If we want to call that good enough for now, I can put in a PR switching that.

The bigger problem here is that we need to make sure examples and code snippets in README's can be ran as written, especially in conda and stable releases.

@andrrizzi and I have two weeks planned where we'll primarily be polishing docs and testing examples in preparation for the alpha 1.0.0 release. However I think the 1.0.0 API is sufficiently different that the fixes we make there won't overlap much to the 0.0.X toolkit examples.

It would be awesome if there was a way we can automate testing of all the examples we provide.

"Objection, your honor, the opposing counsel is begging the question"
There's a module that does just that (I think @jchodera actually told me about it): https://docs.python.org/3/library/doctest.html . I'll open an issue to get it integrated with our testing framework.

nbval will also test jupyter notebooks, so if we can get the examples in the examples folder primarily into jupyter notebooks we can use that.
I'm using it to test the jupyter notebooks in chemper and then integrating those directly into my ReadTheDocs as examples so you don't have to write the code out separately.

Additional task for this:  https://github.com/openforcefield/openforcefield/pull/215#pullrequestreview-220698906
Once finalized we are also going to need to change the template files in utilities/convert_frosst to reflect new syntax, versionining, date, etc., then use this to re-generate smirnoff99Frosst in the correct format (basically it's generated from a smirnoffishFrcmod.parm99Frosst.txt file via convert_frcmod.py there which puts it into the appropriate XML format, basically for historical reasons -- in porting it, Chris didn't like working with the XML (understandably) and so dealt with an AMBER-style file resembling a frcmod file but with SMIRKS provided in the first column rather than an atom type; the convert_frcmod.py file puts this into the correct XML format).

To help whoever is working on this here are the sections of convert_frosst.
This is a function for adding the date and authors called add_date_and_author, this could be updated to include versions.
Then the main function convert_frcmod_to_ffxml uses functions Forcefield.addParameter, Forcefield.getParameters, and Forcefield.setParameter`.
The bulk of convert_frcmod.py is just bookkeeping and shouldn't need to change.


guile_3_0: remove inactive maintainers

Description of changes
This PR aims to remove inactive maintainers from guile_3_0. All maintainers are given a week for a reaction.
https://github.com/NixOS/nixpkgs/pull/272047#issuecomment-1840293438
Also, @civodul since I can't seem to add him to the reviewers. Perhaps he could co-maintain guix if he wanted to.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

They can always re-add themselves if they'd like :)


Add mark to tests which require network access

We are in the process of packaging upgraded version of this package into openSUSE/Factory and our build environment is sandboxed and has no network access, to ensure we don't leak any impurities into the build process.
When running the test suite it fails like this (the other failed test is similar):
[   55s] ______ CustomLangDetectParserTest.test_custom_language_detect_fast_text_1 ______
[   55s]
[   55s] self = <urllib.request.HTTPSHandler object at 0x7f7dab3f3250>
[   55s] http_class = <class 'http.client.HTTPSConnection'>
[   55s] req = <urllib.request.Request object at 0x7f7dae34a1f0>
[   55s] http_conn_args = {'check_hostname': None, 'context': None}
[   55s] host = 'dl.fbaipublicfiles.com'
[   55s] h = <http.client.HTTPSConnection object at 0x7f7dae34aa30>
[   55s]
[   55s]     def do_open(self, http_class, req, **http_conn_args):
[   55s]         """Return an HTTPResponse object for the request, using http_class.
[   55s]
[   55s]         http_class must implement the HTTPConnection API from http.client.
[   55s]         """
[   55s]         host = req.host
[   55s]         if not host:
[   55s]             raise URLError('no host given')
[   55s]
[   55s]         # will parse host:port
[   55s]         h = http_class(host, timeout=req.timeout, **http_conn_args)
[   55s]         h.set_debuglevel(self._debuglevel)
[   55s]
[   55s]         headers = dict(req.unredirected_hdrs)
[   55s]         headers.update({k: v for k, v in req.headers.items()
[   55s]                         if k not in headers})
[   55s]
[   55s]         # TODO(jhylton): Should this be redesigned to handle
[   55s]         # persistent connections?
[   55s]
[   55s]         # We want to make an HTTP/1.1 request, but the addinfourl
[   55s]         # class isn't prepared to deal with a persistent connection.
[   55s]         # It will try to read all remaining data from the socket,
[   55s]         # which will block while the server waits for the next request.
[   55s]         # So make sure the connection gets closed after the (only)
[   55s]         # request.
[   55s]         headers["Connection"] = "close"
[   55s]         headers = {name.title(): val for name, val in headers.items()}
[   55s]
[   55s]         if req._tunnel_host:
[   55s]             tunnel_headers = {}
[   55s]             proxy_auth_hdr = "Proxy-Authorization"
[   55s]             if proxy_auth_hdr in headers:
[   55s]                 tunnel_headers[proxy_auth_hdr] = headers[proxy_auth_hdr]
[   55s]                 # Proxy-Authorization should not be sent to origin
[   55s]                 # server.
[   55s]                 del headers[proxy_auth_hdr]
[   55s]             h.set_tunnel(req._tunnel_host, headers=tunnel_headers)
[   55s]
[   55s]         try:
[   55s]             try:
[   55s] >               h.request(req.get_method(), req.selector, req.data, headers,
[   55s]                           encode_chunked=req.has_header('Transfer-encoding'))
[   55s]
[   55s] /usr/lib64/python3.9/urllib/request.py:1346:
[   55s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[   55s]
[   55s] self = <http.client.HTTPSConnection object at 0x7f7dae34aa30>, method = 'GET'
[   55s] url = '/fasttext/supervised-models/lid.176.ftz', body = None
[   55s] headers = {'Connection': 'close', 'Host': 'dl.fbaipublicfiles.com', 'User-Agent': 'Python-urllib/3.9'}
[   55s]
[   55s]     def request(self, method, url, body=None, headers={}, *,
[   55s]                 encode_chunked=False):
[   55s]         """Send a complete request to the server."""
[   55s] >       self._send_request(method, url, body, headers, encode_chunked)
[   55s]
[   55s] /usr/lib64/python3.9/http/client.py:1285:
[   55s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[   55s]
[   55s] self = <http.client.HTTPSConnection object at 0x7f7dae34aa30>, method = 'GET'
[   55s] url = '/fasttext/supervised-models/lid.176.ftz', body = None
[   55s] headers = {'Connection': 'close', 'Host': 'dl.fbaipublicfiles.com', 'User-Agent': 'Python-urllib/3.9'}
[   55s] encode_chunked = False
[   55s]
[   55s]     def _send_request(self, method, url, body, headers, encode_chunked):
[   55s]         # Honor explicitly requested Host: and Accept-Encoding: headers.
[   55s]         header_names = frozenset(k.lower() for k in headers)
[   55s]         skips = {}
[   55s]         if 'host' in header_names:
[   55s]             skips['skip_host'] = 1
[   55s]         if 'accept-encoding' in header_names:
[   55s]             skips['skip_accept_encoding'] = 1
[   55s]
[   55s]         self.putrequest(method, url, **skips)
[   55s]
[   55s]         # chunked encoding will happen if HTTP/1.1 is used and either
[   55s]         # the caller passes encode_chunked=True or the following
[   55s]         # conditions hold:
[   55s]         # 1. content-length has not been explicitly set
[   55s]         # 2. the body is a file or iterable, but not a str or bytes-like
[   55s]         # 3. Transfer-Encoding has NOT been explicitly set by the caller
[   55s]
[   55s]         if 'content-length' not in header_names:
[   55s]             # only chunk body if not explicitly set for backwards
[   55s]             # compatibility, assuming the client code is already handling the
[   55s]             # chunking
[   55s]             if 'transfer-encoding' not in header_names:
[   55s]                 # if content-length cannot be automatically determined, fall
[   55s]                 # back to chunked encoding
[   55s]                 encode_chunked = False
[   55s]                 content_length = self._get_content_length(body, method)
[   55s]                 if content_length is None:
[   55s]                     if body is not None:
[   55s]                         if self.debuglevel > 0:
[   55s]                             print('Unable to determine size of %r' % body)
[   55s]                         encode_chunked = True
[   55s]                         self.putheader('Transfer-Encoding', 'chunked')
[   55s]                 else:
[   55s]                     self.putheader('Content-Length', str(content_length))
[   55s]         else:
[   55s]             encode_chunked = False
[   55s]
[   55s]         for hdr, value in headers.items():
[   55s]             self.putheader(hdr, value)
[   55s]         if isinstance(body, str):
[   55s]             # RFC 2616 Section 3.7.1 says that text default has a
[   55s]             # default charset of iso-8859-1.
[   55s]             body = _encode(body, 'body')
[   55s] >       self.endheaders(body, encode_chunked=encode_chunked)
[   55s]
[   55s] /usr/lib64/python3.9/http/client.py:1331:
[   55s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[   55s]
[   55s] self = <http.client.HTTPSConnection object at 0x7f7dae34aa30>
[   55s] message_body = None
[   55s]
[   55s]     def endheaders(self, message_body=None, *, encode_chunked=False):
[   55s]         """Indicate that the last header line has been sent to the server.
[   55s]
[   55s]         This method sends the request to the server.
  Connect to *address* (a 2-tuple ``(host,
[   55s]         port)``) and return the socket object.  Passing the optional
[   55s]         *timeout* parameter will set the timeout on the socket instance
[   55s]         before attempting to connect.  If no *timeout* is supplied, the
[   55s]         global default timeout setting returned by :func:`getdefaulttimeout`
[   55s]         is used.  If *source_address* is set it must be a tuple of (host, port)
[   55s]         for the socket to bind as a source address before making the connection.
[   55s]         A host of '' or port 0 tells the OS to use the default.
[   55s]         """
[   55s]
[   55s]         host, port = address
[   55s]         err = None
[   55s] >       for res in getaddrinfo(host, port, 0, SOCK_STREAM):
[   55s]
[   55s] /usr/lib64/python3.9/socket.py:823:
[   55s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[   55s]
[   55s] host = 'dl.fbaipublicfiles.com', port = 443, family = 0
[   55s] type = <SocketKind.SOCK_STREAM: 1>, proto = 0, flags = 0
[   55s]
[   55s]     def getaddrinfo(host, port, family=0, type=0, proto=0, flags=0):
[   55s]         """Resolve host and port into list of address info entries.
[   55s]
[   55s]         Translate the host/port argument into a sequence of 5-tuples that contain
[   55s]         all the necessary arguments for creating a socket connected to that service.
[   55s]         host is a domain name, a string representation of an IPv4/v6 address or
[   55s]         None. port is a string service name such as 'http', a numeric port number or
[   55s]         None. By passing None as the value of host and port, you can pass NULL to
[   55s]         the underlying C API.
[   55s]
[   55s]         The family, type and proto arguments can be optionally specified in order to
[   55s]         narrow the list of addresses returned. Passing zero as a value for each of
[   55s]         these arguments selects the full range of results.
[   55s]         """
[   55s]         # We override this function since we want to translate the numeric family
[   55s]         # and socket type values to enum constants.
[   55s]         addrlist = []
[   55s] >       for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
[   55s] E       socket.gaierror: [Errno -3] Temporary failure in name resolution
[   55s]
[   55s] /usr/lib64/python3.9/socket.py:954: gaierror
[   55s]
[   55s] During handling of the above exception, another exception occurred:
[   55s]
[   55s] a = (<tests.test_language_detect.CustomLangDetectParserTest testMethod=test_custom_language_detect_fast_text_1>,)
[   55s]
[   55s]     @wraps(func)
[   55s]     def standalone_func(*a):
[   55s] >       return func(*(a + p.args), **p.kwargs)
[   55s]
[   55s] /usr/lib/python3.9/site-packages/parameterized/parameterized.py:637:
[   55s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[   55s] tests/test_language_detect.py:26: in test_custom_language_detect_fast_text
[   55s]     self.result = fast_text_detect_languages(dt_string, confidence_threshold)
[   55s] dateparser/custom_language_detection/fasttext.py:37: in detect_languages
[   55s]     _language_parser = _load_fasttext_model()
[   55s] dateparser/custom_language_detection/fasttext.py:27: in _load_fasttext_model
[   55s]     fasttext_downloader(_DEFAULT_MODEL)
[   55s] dateparser_cli/fasttext_manager.py:28: in fasttext_downloader
[   55s]     urllib.request.urlretrieve(model_url, models_directory_path)
[   55s] /usr/lib64/python3.9/urllib/request.py:239: in urlretrieve
[   55s]     with contextlib.closing(urlopen(url, data)) as fp:
[   55s] /usr/lib64/python3.9/urllib/request.py:214: in urlopen
[   55s]     return opener.open(url, data, timeout)
[   55s] /usr/lib64/python3.9/urllib/request.py:517: in open
[   55s]     response = self._open(req, data)
[   55s] /usr/lib64/python3.9/urllib/request.py:534: in _open
[   55s]     result = self._call_chain(self.handle_open, protocol, protocol +
[   55s] /usr/lib64/python3.9/urllib/request.py:494: in _call_chain
[   55s]     result = func(*args)
[   55s] /usr/lib64/python3.9/urllib/request.py:1389: in https_open
[   55s]     return self.do_open(http.client.HTTPSConnection, req,
[   55s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[   55s]
[   55s] self = <urllib.request.HTTPSHandler object at 0x7f7dab3f3250>
[   55s] http_class = <class 'http.client.HTTPSConnection'>
[   55s] req = <urllib.request.Request object at 0x7f7dae34a1f0>
[   55s] http_conn_args = {'check_hostname': None, 'context': None}
[   55s] host = 'dl.fbaipublicfiles.com'
[   55s] h = <http.client.HTTPSConnection object at 0x7f7dae34aa30>
[   55s]
[   55s]     def do_open(self, http_class, req, **http_conn_args):
[   55s]         """Return an HTTPResponse object for the request, using http_class.
[   55s]
[   55s]         http_class must implement the HTTPConnection API from http.client.
[   55s]         """
[   55s]         host = req.host
[   55s]         if not host:
[   55s]             raise URLError('no host given')
[   55s]
[   55s]         # will parse host:port
[   55s]         h = http_class(host, timeout=req.timeout, **http_conn_args)
[   55s]         h.set_debuglevel(self._debuglevel)
[   55s]
[   55s]         headers = dict(req.unredirected_hdrs)
[   55s]         headers.update({k: v for k, v in req.headers.items()
[   55s]                         if k not in headers})
[   55s]
[   55s]         # TODO(jhylton): Should this be redesigned to handle
[   55s]         # persistent connections?
[   55s]
[   55s]         # We want to make an HTTP/1.1 request, but the addinfourl
[   55s]         # class isn't prepared to deal with a persistent connection.
[   55s]         # It will try to read all remaining data from the socket,
[   55s]         # which will block while the server waits for the next request.
[   55s]         # So make sure the connection gets closed after the (only)
[   55s]         # request.
[   55s]         headers["Connection"] = "close"
[   55s]         headers = {name.title(): val for name, val in headers.items()}
[   55s]
[   55s]         if req._tunnel_host:
[   55s]             tunnel_headers = {}
[   55s]             proxy_auth_hdr = "Proxy-Authorization"
[   55s]             if proxy_auth_hdr in headers:
[   55s]                 tunnel_headers[proxy_auth_hdr] = headers[proxy_auth_hdr]
[   55s]                 # Proxy-Authorization should not be sent to origin
[   55s]                 # server.
[   55s]                 del headers[proxy_auth_hdr]
[   55s]             h.set_tunnel(req._tunnel_host, headers=tunnel_headers)
[   55s]
[   55s]         try:
[   55s]             try:
[   55s]                 h.request(req.get_method(), req.selector, req.data, headers,
[   55s]                           encode_chunked=req.has_header('Transfer-encoding'))
[   55s]             except OSError as err: # timeout error
[   55s] >               raise URLError(err)
[   55s] E               urllib.error.URLError: <urlopen error [Errno -3] Temporary failure in name resolution>
[   55s]
[   55s] /usr/lib64/python3.9/urllib/request.py:1349: URLError

Complete build log shows all packages used and specific steps taken.
With this patch we are at least able to mark this test as network requiring and skip it en masse:
---
 pytest.ini                    |    3 +++
 tests/test_language_detect.py |    2 ++
 2 files changed, 5 insertions(+)

--- /dev/null
+++ b/pytest.ini
@@ -0,0 +1,3 @@
+[pytest]
+markers =
+    network: tests requiring network connection
--- a/tests/test_language_detect.py
+++ b/tests/test_language_detect.py
@@ -1,6 +1,7 @@
 from datetime import datetime
 from unittest.mock import Mock
 import unittest
+import pytest

 from parameterized import parameterized, param

@@ -18,6 +19,7 @@ class CustomLangDetectParserTest(unittes
     def check_is_returned_list(self):
         self.assertEqual(type(self.result), list)

+    @pytest.mark.network
     @parameterized.expand([
         param(dt_string="14 June 2020", confidence_threshold=0.0),
         param(dt_string="26 July 2021", confidence_threshold=0.0)

Unfortunately, that makes this package hard requiring pytest, but I cannot find purely unittest-based marking (we probably could do unittest.skipIf based on the environmental variable).

Actually, this version of the patch doesn't require pytest:
---
 tests/test_language_detect.py |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/tests/test_language_detect.py
+++ b/tests/test_language_detect.py
@@ -1,6 +1,8 @@
+import os
+import unittest
+
 from datetime import datetime
 from unittest.mock import Mock
-import unittest

 from parameterized import parameterized, param

@@ -13,6 +15,7 @@ from dateparser.search import search_dat
 detect_languages = Mock()
 detect_languages.return_value = ["en"]

+NO_NETWORK = int(os.environ.get('NO_NETWORK', 0)) == 1

 class CustomLangDetectParserTest(unittest.TestCase):
     def check_is_returned_list(self):
@@ -22,6 +25,7 @@ class CustomLangDetectParserTest(unittes
         param(dt_string="14 June 2020", confidence_threshold=0.0),
         param(dt_string="26 July 2021", confidence_threshold=0.0)
     ])
+    @unittest.skipIf(NO_NETWORK, "Test requires network access")
     def test_custom_language_detect_fast_text(self, dt_string, confidence_threshold):
         self.result = fast_text_detect_languages(dt_string, confidence_threshold)
         self.check_is_returned_list()


Duplicate libiomp5.dylib & libmklml.dylib when install TF 1.12 with python 3.6.x using Anaconda3 in Mac OS 10.13

System information

OS Platform and Distribution : MacOS 10.13 High Sierra
TensorFlow installed from (source or binary): binary
TensorFlow version: 1.12
Python version: 3.6.x
Installed using : Anaconda 3, version 5.3.1

Describe the problem
Actually, my program meet a issue as #23999
I try to deep into the reason which cause the issue,
and found that when I create a env (name 'py36' in my case) in Anaconda3 with Python 3.6 and install TensorFlow 1.12 ,
there are duplicate files libiomp5.dylib & libmklml.dylib under path
~/anaconda3/envs/py36/lib/python3.6/site-packages/_solib_darwin/_U@mkl_Udarwin_S_S_Cmkl_Ulibs_Udarwin___Uexternal_Smkl_Udarwin_Slib/
which are same files under path
~/anaconda3/envs/py36/lib
No matter I delete which one, the program cannot run well.
Provide the exact sequence of commands / steps that you executed before running into the problem
Step 1. Install Anaconda 3 (Version 5.3.1)
Step2. Create env using Python 3.6
Step3. Install TensorFlow 1.12 and relative package.
BTW, If I create env (name 'py35' ) using Python 3.5, this issue is gone.
There are no folder _solib_darwin be created under ~/anaconda3/envs/py35/lib/python3.5/site-packages/ and no duplicate files libiomp5.dylib & libmklml.dylib
Any other info / logs

My program as follow:
This program will meet issue #23999
when install TF 1.12 with python 3.6.x using Anaconda3 in Mac OS 10.13
import tensorflow as tf
import numpy as np

# Workaround for libiomp5.dylib already initialized.
# import os
# os.environ['KMP_DUPLICATE_LIB_OK'] = 'True'

x_data = np.random.randn(2000, 3)
w_real = [0.3, 0.5, 0.1]
b_real = -0.2

noise = np.random.randn(1, 2000) * 0.1

y_data = np.matmul(w_real, x_data.T) + b_real + noise

NUM_STEPS = 10

g = tf.Graph()
wb_ = []

with g.as_default():
    x = tf.placeholder(tf.float32, shape=[None, 3])
    y_true = tf.placeholder(tf.float32, shape=None)

    with tf.name_scope('inference') as scope:
        w = tf.Variable([[0, 0, 0]], dtype=tf.float32, name='weights')
        b = tf.Variable(0, dtype=tf.float32, name='bias')
        y_predict = tf.matmul(w, tf.transpose(x)) + b

    with tf.name_scope('loss') as scope:
        loss = tf.reduce_mean(tf.square(y_predict - y_true))

    with tf.name_scope('train') as scope:
        learning_rate = 0.5
        optimizer = tf.train.GradientDescentOptimizer(learning_rate)
        train = optimizer.minimize(loss)

    # Before starting, initialize the variables. We will 'run' this first
    init = tf.global_variables_initializer()
    with tf.Session() as sess:
        sess.run(init)
        for step in range(NUM_STEPS):
            sess.run(train, {x: x_data, y_true: y_data})
            if step % 5 == 0:
                print(step, sess.run([w, b]))
                wb_.append(sess.run([w, b]))

        print(NUM_STEPS, sess.run([w, b]))

I am also having a similar problem!

I have the same problem. It's related to the anaconda python3 installation of tensorflow. For some reason anaconda recommends installing their version of tensorflow because it's faster than the official release since it comes with native mkl integration.
I fixed the issue by running conda uninstall tensorflow keras. This seemed to partially remove the packages.  Then I run pip install tensorflow keras which worked successfully.
Installed them back again with pip install tensorflow keras.
This solved my problem.

Closing this issue since its more a likely an issue with anaconda. You can always set a virtual env and run your code as a workaround. Feel free to reopen if have any further problems. Thanks!


Invoke-DbaAdvancedInstall - Enhance processing of install summary

Type of Change

[ ] Bug fix (non-breaking change, fixes # )
[x] New feature (non-breaking change, adds functionality, fixes #7299 )
[x] Breaking change (effects multiple commands or functionality, fixes #7300 )
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Adding code coverage to existing functionality
[ ] Pester test is included
[ ] If new file reference added for test, has is been added to github.com/sqlcollaborative/appveyor-lab ?
[ ] Nunit test is included
[ ] Documentation
[ ] Build system

Purpose
Getting the exit message as a string into the new property .ExitMessage and the full content of the summary.txt into the new property .LogFileContent.
Removing the old property .Log is a "breaking" change. But I don't think that a lot of users have build a process around that property.
Screenshots

Thanks to you both! Will merge with @nvarscar's approval 🙇🏼

yall are the best 😊  thanks so much!


Edit description in feature specification to also reflect in BigQuery schema description.

Is your feature request related to a problem? Please describe.
When editing of current existing feature-specification description to ingest feature into Bigquery table, the changes only reflected in Feast-Core page.
Describe the solution you'd like
Edit description and trigger CI to sync entity and feature specification should also change the description in Bigquery schema description. This can eliminate manual change in the BQ schema itself if a revision of current existing feature is needed.

This makes sense @arfiadhi. It can possibly be picked up during 0.3.

thanks, looking forward to it! @woop

This feature is stale. Lets reopen if its still necessary given Feast 0.3 capabilities.


Use tf.shape for graph mode support

Why
With custom layers/models in graph mode, it seems to have trouble inferring shapes because .shape is used in call() instead of tf.shape(), and I'm running into issues such as:
[1,0]<stdout>:E                               TypeError: Exception encountered when calling layer "distributed_embedding" "                 f"(type DistributedEmbedding).
[1,0]<stdout>:E
[1,0]<stdout>:E                               in user code:
[1,0]<stdout>:E
[1,0]<stdout>:E                                   File "/usr/local/lib/python3.8/dist-packages/distributed_embeddings/python/layers/dist_model_parallel.py", line 503, in call  *
[1,0]<stdout>:E                                       outputs = self._call_base(inputs)
[1,0]<stdout>:E                                   File "/usr/local/lib/python3.8/dist-packages/distributed_embeddings/python/layers/dist_model_parallel.py", line 279, in _call_base  *
[1,0]<stdout>:E                                       global_splits.append(sum(local_splits[-1]))
[1,0]<stdout>:E
[1,0]<stdout>:E                                   TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'
[1,0]<stdout>:E
[1,0]<stdout>:E
[1,0]<stdout>:E                               Call arguments received by layer "distributed_embedding" "                 f"(type DistributedEmbedding):
[1,0]<stdout>:E                                 • inputs=['tf.Tensor(shape=(None, None), dtype=int64)', 'tf.Tensor(shape=(None, None), dtype=int64)']

We've run into this error while trying to integrate distributed-embeddings into Merlin Models (https://github.com/NVIDIA-Merlin/models/pull/974).
From Tensorflow docs:

tf.shape and Tensor.shape should be identical in eager mode. Within tf.function or within a compat.v1 context, not all dimensions may be known until execution time. Hence, when defining custom layers and models for graph mode, prefer the dynamic tf.shape(x) over the static x.shape.

This PR proposes to replace .shape with tf.shape(). According to the doc quoted above, it seems that tf.shape() has advantages because it should behave the same as .shape in eager mode and will also work correctly in graph mode. With the changes in this PR, I've managed to make the custom model work without errors.
Testing
Manually ran
python distributed_embeddings/python/layers/dist_model_parallel_test.py
python tests/dist_model_parallel_test.py

This PR includes a variable name change that makes the tests in python tests/dist_model_parallel_test.py pass.

@FDecaYed @skyw  Ping. It looks like I don't have access to assign reviewers.

@edknv Thanks for the contribution. We've seen this before and I agree this need to be fixed.
There is one issue:
from our testing, use of tf.shape() is not always strictly better than tensor.shape, at least in current tf version. It could create some blocking copy between host/device.
one way to deal with the change is something like
# to get shape[0]
dim0 = tf.shape(tensor)[0] if tensor.shape[0] is None else tensor.shape[0]
# to get shape
tshape = tf.shape(tensor) if None in tensor.shape else tensor.shape


Code Cleanup: Add Key to HTML components returned in loops

Some of these have been fixed, but the Gatsby SSR engine still generates a warning for a number of places that a list of HTML objects doesn't have a unique key.  It doesn't cause a build or usage problem that I can see, but it would be nice to get Gatsby to stop complaining all the time in development mode.

I'm pretty sure this is done, or at least done enough.  I haven't seen any more SSR errors in quite awhile.  I'm going to close this.


Dart error

Analyzer Feedback from IntelliJ
Version information

IDEA IC-171.4249.39
1.23.0
IC-171.4249.39, JRE 1.8.0_112-release-736-b16x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.12.4 unknown, screens 1280x800  Retina

Exception
Please append the contents of:
file:///private/var/folders/1c/0tsnw91j4kq0k2bgxxfr2nmc0000gn/T/report1.txt
Dart analysis server, SDK version 1.23.0, server version 1.18.0, error: Could not initialize the library map from [/Users/davidebausach/sdk/lib/_internal/sdk_library_metadata/lib/libraries.dart, /Users/davidebausach/sdk/lib/_internal/libraries.dart]

FileSystemException(path=/Users/davidebausach/sdk/lib/_internal/libraries.dart

The libraries.dart file has moved to sdk/lib/_internal/sdk_library_metadata/lib/.
This was probably done to make it work like a dart package so you can import it as package:sdk_library_metadata/libraries.dart.
The analysis server version is 1.18, which suggests that it's fairly old compared to the SDK.
I don't use IDEA myself, so I can't say how it finds the analysis server to use.


Bug in Mutating Typed Dict?

When I try mutating a typed dict via a for loop in @njit I only get one iteration of the loop mutated. If I create a new dict instead it works.
Numpy version: 1.20.2
Numba version: 0.53.1
import numba as nb
from numba.types import Set, Tuple, int32, int64
from numba.typed import Dict

t = Tuple((int64,int64))
d1 = Dict.empty(t,int64)
d2 = Dict.empty(t,int64)

@nb.njit
def augment_wrong(x):
    # This is wrong - only one pass through iteration
    for key in x.keys():
        x[(key[0]+1, key[1])] = 1
    return x

@nb.njit
def augment_works(x):
    new_d = Dict.empty(t,int64)
    for key in x.keys():
        new_d[key] = 1 # Copy original key over
        new_d[(key[0]+1, key[1])] = 1
    return new_d

d1[(0,0)] = 1
d1[(1,1)] = 1
d2[(0,0)] = 1
d2[(1,1)] = 1

print(augment_wrong(d1))
print(augment_works(d2))

Apologies if I'm misunderstanding a guarantee - my understanding is that mutating typed Dicts should be allowed.
Thanks!

Thanks for the report. I think the augment_wrong function is probably suffering from the dictionary changing size whilst being iterated. In the python interpreter if you do:
def foo(x):
    for key in x.keys():
        x[(key[0]+1, key[1])] = 1
    return x

foo({(0, 0):1})

you'll get:
    for key in x.keys():
RuntimeError: dictionary changed size during iteration

I suspect Numba ought to catch the same.

Thanks so much for the quick response and diagnosis @stuartarchibald!
Ah, doh! I see, now that you mention that it seems like ambiguous code even in vanilla Python. I wouldn't have guessed a RuntimeError, but that's as good a behavior as anything else.
Copying the keys out first solves the problem:
@nb.njit
def augment_copy(x):
    for key in list(x.keys()):
        x[(key[0]+1, key[1])] = 1
    return x

Thanks so much for catching that!

@mharradon No problem. I think I'll change the title of this ticket because it's really a behavioural bug in Numba, in that Numba ought to be able to catch this.


Fix various spelling errors across engine solution

Found a couple spelling errors while skimming through code, then decided to utilize Visual Studio's built in spell checker across the solution since this is a semi new feature and I figured someone would eventually do this anyways. Fixed some obvious spelling errors and ignored minor grammatical things to avoid being pedantic.

Thanks!


Is it possible to add the skip and next button in this library?

thanks, I will think about it for the next version.
probably, i will provide interfaces for skipping and moving the next target.

I added this functionality on version 1.3.0.


Bug report: Unable to resolve action Readme-Workflows/recent-activity@v1, unable to find version v1

Please check these things before submitting your issue:

[x] I am using the latest version
[x] I searched for duplicate or closed bug report here

Describe the bug
GitHub actions doesn't find version v1
To Reproduce
Steps to reproduce the behavior:

Go to 'Any of your GitHub repo'
Click on 'Actions tab'
Run the 'recent-activity workflow with v1'
See error

Expected behavior
Expected to work Normally
Screenshots
N/A

Additional context
See https://github.com/PuneetGopinath/PuneetGopinath/runs/2565219045?check_suite_focus=true

Is that a test for issue templates and/or the welcome bot or something?

@PuneetGopinath But latest version is working fine.
Can you explain more about this?

@PuneetGopinath But latest version is working fine.
Can you explain more about this?

Nop, in your workflow you are using branch main, anyway now we released v1.2.1 but still it doesn't work
Or could be a bug with github actions itself?

Is that a test for issue templates and/or the welcome bot or something?

Not any test

Wait a se, line 26 shows Failed to resolve action download info.

Wait a sec, line 26 shows Failed to resolve action download info.

Which file are you talking about?

Which file are you talking about?

No any file, line 26 in workflow run

Which file are you talking about?

Not any file, line 26 in workflow run

You are aware that v1 is NOT an actual release hee right?

Just make changes in your .yml file accordingly. Update it to point to recent version v1.2.1 / main branch.

Which file are you talking about?

Not any file, line 26 in workflow run

You are aware that v1 is NOT an actual release hee right?

Yes, I just forgot it
I got confused
Sorry guys


[T2A2][T3-A1]Wu Zefeng

Hahahahaha

Ready for review.

Hi @DesperadoFlames, your pull request title is invalid. It should be in the format of [Activity ID][Team ID] Your name, where [Activity Id] has no dashes or spaces (e.g. [T2A3] stands for Tutorial 2 Activity 3) and [Team ID] has one dash only and no spaces (e.g. [W14-A2] means Wednesday 2pm (14 hrs), Phase A, Team 2). Please follow the instructions given strictly and edit your title for reprocessing.
Note that this comment is posted by a bot sorting all the pull request submissions.


Test on multiple Python versions with tox

Test on Python 2.6, 2.7, 3.3, 3.4, 3.5
Add test instructions to README, add compatible versions.

Thanks for the PR!

@edburnett What do you think about adding travis.ci builds? I can set it up relatively quickly...
My favorite part about it is being able to validate pull requests much faster.
Thanks!


Agtype hash cmp

Move agtype_hash_cmp tests to separate file
Output of the agtype_hash_cmp function varies depending on the machine
endianness. Move tests to a separate file and supply little-endian and
big-endian output expected files.


Add missing Usage Pages

Usage Pages implemented:

[x] 0x01 - GenericDesktop
[ ] 0x02 - Simulation
[x] 0x03 - Virtual Reality
[ ] 0x04 - Sport
[ ] 0x05 - Game
[x] 0x06 - Generic Device
[ ] 0x07 - Keyboard
[ ] 0x08 - LEDs
[x] 0x09 - Button
[ ] 0x0A - Ordinal
[ ] 0x0B - Telephony
[ ] 0x0C - Consumer
[x] 0x0D - Digitizer
[ ] Physical Interface Device definitions for force feedback and related devices

[ ] 0x0F - Physical Interface Device (PID) page

[ ] 0x10 - Unicode
[ ] 0x14 - Alphanumeric Display
[ ] 0x40 - Medial Instruments
[ ] Monitor Devices

[ ] 0x80-0x83 - Monitor Pages

[X] Power Devices

[X] 0x84 - Power Device Page (Thank you @kabili207 #13)
[X] 0x85 - Battery System Page (Thank you @kabili207 #13)
0x86-0x87 - Reserved

[ ] Point of Sales

[ ] 0x8C - Bar Code Scanner
[ ] 0x8D - Scale
[ ] 0x8E - Magnetic Swipe Reading (MSR)

[ ] Image Class Devices

[ ] 0x90 - Camera Control

[ ] OAAF Definitions for arcade and coinop related devices

[ ] 0x91 - Arcade

The Buttons usage page implements a "hacked" Python enum.Enum class.
When Enums are created, the class is treated as final and does not allow adding more members to Enums, I mean, why not?
In the case of the Button usage page, there are 2^16 buttons (a lot) and I'm not prepared to fill up the memory with Button instances that'll never be used. So they're created when requested and should behave like normal python enums.

The Button usage page implements a "hacked" Python enum.Enum class.
When Enums are created, the class is treated as final and does not allow adding more members to Enums, I mean, why not?

I may create a UsagePage metaclass that will automate creating members for the enums at request if the subclass implements a class method (for example def __createmember__(cls, name):)
in case there are more usage pages like Button

I may create a UsagePage metaclass that will automate creating members for the enums at request if the subclass implements a class method (for example def createmember(cls, name):)
in case there are more usage pages like Button

Also, will be useful when parsing devices and their vendor defined usage page isn't defined

In da0bda0

Approved HID Usage Table Review Request 61 was also added for convenience

According to the latest specification pages x86 and x87 are reserved for Power Devices but there usage has not yet been defined are are essentially reserved for future versions.

According to the latest specification pages, x86 and x87 are reserved for Power Devices but there usage has not yet been defined and are essentially reserved for future versions.

Updated, thank you again!


feat: Normalize strings for entities

Motivation

An api might want to nest ids, rather than forcing them inside objects like: ['1', '3', '5'] vs [{ id: '1'}, { id: '3' }, { id: '5' }]
Solution

Specifically allow string types during normalization for entities. This is handled before Entity.normalize step so we removed the special check.

Codecov Report

Merging #1364 (835073a) into master (c2f042f) will increase coverage by 0.46%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1364      +/-   ##
==========================================
+ Coverage   97.68%   98.15%   +0.46%
==========================================
  Files          92       92
  Lines        1728     1730       +2
  Branches      345      346       +1
==========================================
+ Hits         1688     1698      +10
+ Misses         12        9       -3
+ Partials       28       23       -5

Impacted Files
Coverage Δ

packages/normalizr/src/entities/Entity.ts
98.47% <100.00%> (+6.10%)
:arrow_up:

packages/normalizr/src/normalize.ts
98.87% <100.00%> (+0.02%)
:arrow_up:

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 c2f042f...835073a. Read the comment docs.


Remove redundant specificity from input selectors

There has been an ongoing issue in bourbon/bitters where the default selector for input styling is a compound selector (ex. input[type="email"]). While this is effective for targeting particular elements, it makes them difficult to override. Now every time you want to style an input element you have to use a compound selector. This PR and a corresponding one in bitter (TBD) removes the unnecessary declaration of the input as the element.
If a user wants to add greater specificity later on, that should be an option and not the default output.
an example…
input[type="submit"] {
  color: blue;
}

.button {
  color: black;
}

 <input type="submit" class="button"> will always render as color: blue; even though you would almost always prefer classes to be the dominant selector over inherent element styles.

:+1:
The way this is currently using type + attribute combination selectors does make it overly specific. Class selectors are more specific than attribute selectors, so removing the type of element like you suggest, allows for authors to override via classes alone.
We should also change Bourbon’s #{$all-buttons} variable. Can you add those changes to this PR?
I’ll merge for 5.0.

I’ve merged this in for v5.0.0.


Implement hints documentation

Resolves #327

Hey @Iwueseiter how is it going, let me know if I can help with anything

Hey @Iwueseiter how is it going, let me know if I can help with anything

I pushed some commits to the PR, you can look at it and leave a review.


Headless VPS Feedback on 01-rclone-acd.sh

Hey there again,
Okay this is feedback solely from the point of view of a full on "headless" install.
In order to authenticate rClone and ACD you need access to web browser. On a headless install that is not as convenient as a desktop install.
So I got around this impasse by doing the following:

installing a headless or CLI based browser        sudo apt-get install -y w3m
then I installed 'screen'                                      sudo apt-get install -y screen
then at the authentication prompt i did              w3m http://<IP_ADDRESS>:53682/auth
then followed the prompts

For full credit given, I got the idea from
https://enztv.wordpress.com/2016/10/19/using-amazon-cloud-drive-with-plex-media-server-and-encrypting-it/
At any rate.... I throw the idea at you in case you think it may have some benefit to your scripts.
Thanks
Onyx

That's the method I originally used for headless, but I personally found the wiki method simpler to use (I've never really been a fan of w3m, it's great, but not for me)

Rclone has simplified this step, closing the issue.


Question: how to use multiple error budget windows?

Is it possible to use different error budget windows for SLOs?
For example my first service needs 7 day window and the second one 28 days.
For me it looks like I should have two sets of sloth specs and build them as
    # 7 day budget
    sloth generate --input="services/shop/widget_get.slo.yml" --default-slo-period=7d --slo-period-windows-path=./windows
    sloth generate --input="services/shop/cart_add.slo.yml" --default-slo-period=7d --slo-period-windows-path=./windows
    # 28 days budget
    sloth generate --input="services/parcel/prediction_get.slo.yml" --default-slo-period=28d --slo-period-windows-path=./windows

And we can not have one SLO in two windows as alerts do not differentiated by a window. So sloth It generates an alert spec with the same alert name but with a different formula according to the window. We can't merge them.

I'm as well very interested in solution for this,


Consolidate target configs

Consolidate the target configuration on ARM SoCs on a per-family basis. This also includes a fix for an x86 target, arduino_101, which does not have a device tree with flash partitions and thus can't be asked to fit in the boot partition.

@mbolivar I did, but it does not work:
carles@ubuntu-vm ~/src/mcuboot (pr/114)
$ ./build_boot.sh nrf52_pca10040
Board nrf52_pca10040 not yet supported, please use a supported target.

@mbolivar build_boot.sh must be corrected too. See https://github.com/runtimeco/mcuboot/blob/master/build_boot.sh#L11

@carlescufi @nvlsianpu thank you for pointing out my mistake. I never use build_boot.sh as I prefer to build with make -jN.
I've rebased this and build-tested it with build_boot.sh using every board that defines a boot_partition, as well as arduino_101. nrf52_pca10040 doesn't currently define a boot partition in mainline Zephyr, so I built it using the tree in https://github.com/zephyrproject-rtos/zephyr/pull/1307 instead.

Rebased.

@d3zd3z, any feedback?

"sub-command" switched back to "subcommand" in README-zephyr.rst. Rebased.


WebView2Loader.dll is left out

WebView2Loader.dll is left out when publishing an application that have reference to a class library with package reference to Microsoft.Web.WebView2.
Native dll:
WebView2Loader.dll.deploy
Everything works fine when publishing an application with package reference to Microsoft.Web.WebView2.
Step to reproduce issue:

Start VS 2019 and select create a new project.
Select WPF App (.NET Framework) C#, you get a WpfApp1 project.
To solution add New Project, select Class Library (.NET Framework) C#, you get a ClassLibrary1.
To WpfApp1 add reference to ClassLibrary1.
To ClassLibrary1 install NuGet Microsoft.Web.WebView2 (1.0.705.50).
For WpfApp1 select property and select tab Publish and specify a publishing folder on hard drive.
Press Publish Now button and look in publishing folder. The WebView2 assemblies and WebView2Loader.dll is left out.

Thanks
Perka

Apologies about the long delay replying.
Unfortunately, this repository is about the documentation of the Edge developer features, not about the features themselves.
If you are still facing the above problem, please get in touch with the WebView2 team by filing an issue on the WebView2Feedback repository here: https://github.com/MicrosoftEdge/WebView2Feedback/issues


@ not possible intro from keyboard

Hello
I can't intro @ from keyboard in web search CarStream app.
Please, can you implement it ?
From Spain,
Thank you very much
Very good job !!!
Best regards,
Chema

Duplicate of #22
Will be added but requires a lot of work. Taking up next after bookmark settings
In the meantime, use the phone carstream app to login once.