[package:observe] should support Maps with String keys

 Issue by jmesserly
Originally opened as dart-lang/sdk#11980

instead of Symbols, we should use String keys in Map. This makes it easier to work with JSON using "toObservable".
We probably need for ObservableMap to produce a different kind of change record. It might also be a good time to modify the single ".changes" property so ObservableLists can produce a ".listChanges" ... essentially, each type of change record is really its own API. This matches what ES Harmony Object.observe is doing, too--you need to request a particular kind of change records that your observer callback understands.

This comment was originally written by<EMAIL_ADDRESS>
This is necessary, please!!!

 Comment by jmesserly

Issue dart-lang/sdk#11981 has been merged into this issue.

This comment was originally written by<EMAIL_ADDRESS>
Could you add a "gotcha" to the documentation to not use Maps with string keys at this time, if you want to see changes?
Spent a while trying to find out why this wasn't working.

 Comment by sethladd

With PolymerExpressions, this is less of an issue. When inside a PolymerElement, I don't have this issue.

 Comment by sigmundch

Added this to the M8 milestone.

 Comment by sethladd

You can only bind a model to a template.
However, since you are using a custom element (x-foo), that should have its own model automatically bound. The model is an instance of the Dart class that backs the custom element (class XFoo extends PolymerElement)
See this example: https://github.com/sethladd/dart-polymer-dart-examples/tree/master/web/bind_to_a_map

 Comment by sethladd

It works when you're inside a custom element. Can you use a <polymer-element>?

This comment was originally written by<EMAIL_ADDRESS>
I'm trying the following code.
var el = createElement('x-foo');
el.model = toObservable({'_id': '1',
                  'username': 'Bat',
                  'email'<EMAIL_ADDRESS>                  'active': true
                  });
But it's saying it should be a template. How to bind a map object to a custom element? Could you show me an example?

 Comment by jmesserly

was fixed in M8. Was in a CL from the past week, forgot which one :)

Removed this from the Later milestone.
Added this to the M8 milestone.
Added Fixed label.

 Comment by sigmundch

Removed this from the M8 milestone.
Added this to the Later milestone.

 Comment by anders-sandholm

Removed Library-Observe label.
Added Pkg-Observe label.


KAFKA-16386: Convert NETWORK_EXCEPTIONs from KIP-890 transaction verification

KIP-890 Part 1 introduced verification of transactions with the transaction coordinator on the Produce and TxnOffsetCommit paths. This introduced the possibility of new errors when responding to those requests. For backwards compatibility with older clients, a choice was made to convert some of the new retriable errors to existing errors that are expected and retried correctly by older clients.
NETWORK_EXCEPTION was forgotten about and not converted, but can occur if, for example, the transaction coordinator is temporarily refusing connections. Now, we convert it to:

NOT_ENOUGH_REPLICAS on the Produce path, just like the other retriable errors that can arise from transaction verification.
COORDINATOR_LOAD_IN_PROGRESS on the TxnOffsetCommit path. This error does not force coordinator lookup on clients, unlike COORDINATOR_NOT_AVAILABLE. Note that this deviates from KIP-890, which says that retriable errors should be converted to COORDINATOR_NOT_AVAILABLE.

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Getting a fresh build before merging 👍

testAlterSinkConnectorOffsetsOverriddenConsumerGroupId
testSeparateOffsetsTopic
These caught my eye but have been flaky/failing since before this change. Here are JIRAs for them: https://issues.apache.org/jira/browse/KAFKA-15914 and https://issues.apache.org/jira/browse/KAFKA-14089
The other tests look known and/or unrelated. I will go ahead and merge.

I wonder if I should backport this to 3.7 as well.


Revise the Query API

Description
Having used the QueryBus and @QueryHandler annotated methods ourselves and based on the experiences of users of both models, we feel the API needs to be simplified.
At this stage, we believe we could streamline the API by (1) keeping scatter-gather and (2) replacing the rest for a streaming solution.
A streaming solution, like the QueryBus#streamingQuery method, can replace the direct query and subscription query because it can fulfill both purposes depending on how long the response is kept.
Furthermore, we feel the use of the ResponseType has been restricting the use of queries too much too the JVM space, as it relies on the FQCN. As there is clear value in being able to dispatch a query to a non-JVM-based application, it would be beneficial to drop the ResponseType altogether and instead deserialize the response on the receiving end.
With the introduction of the MessageStream in #2967 and the changes in the Unit of Work, we're laying the foundation to investigate the use of a revised Query API.

Isnt't the streaming query just connected to one node? So it might miss events send to other instances, unlike the streaming query which connects to all nodes?

Isnt't the streaming query just connected to one node? So it might miss events send to other instances, unlike the streaming query which connects to all nodes?

Exactly why I left this issue "under discussion," as we have made no real conclusion on what the new API would look like.
If have, for better or worse, taking as much as I still recall from the meetings we have, and drafted this issue.

After some more digging in our planning documents, I also uncovered the idea to have a dedicated annotation or lambda to configure a subscription query handler.
This would (1) align with your point, @gklijs, (2) make a clear difference between a query handler that answer a single time and one that provides updates, and (3) potentially drop the need of the QueryUpdateEmitter (depending on the implementation, of course).


Host PyPi repository with arm64 prebuilts

Then
 [[tool.poetry.source]]
name = '...'
url = 'https://.../pypi/simple/'
default = true

It's okay now; we only build ruamel.yaml.


Update index.md

Simplify generation commands (there was a bug several releases ago that required the longer style, but should not be needed anymore)

Thanks! I have applied your PR to develop as cdde1e57f37868c5ad1506781c96b172a2448bb2. Pushing to master would deploy the website right away, but at the moment the build is a bit broken outside of develop... The changes will go live with the next release!


installation script has no effect?

for me it says /nix/store/1pp7al3i0pxwdf30fhhxb2nr9rws2mr8-install-agenix-shell in the shellHook which is just some directory; I think ideally it should be inlined, i.e. have the store path be directly a the text and not a storepath/bin/exe

alright I looked at the flake template, makes sense! I think I would put the installationScript attribute as
source ${config.agenix-shell/bin/install-agenix-shell}
``` such that you can just concat it with the rest of your `shellHook`

For some reason that breaks my entire devShell 😞

Hey sorry but I missed this issue, have you figured it out in the end?
Yeah probably including the source part is in the installationScript is not a bad idea. Probably I will create another option (internal) which contains just the installationScript as now and a new installationCommand with default value is "source ${installationScript}", so we leave more customizability if someone for some reason doesn't need to source it.
Also notice that my initial idea was providing this raw installationScript for a "vanilla" experience but then add a module that extends devshell's options and use it myself (I tend to use devshell whenever I can).

Running ${lib.getExe config.agenix-shell.installationScript} in devenv enterShell still has no effect, and sourcing it breaks other shell variables

@MrFoxPro How does it break them? If you give me a repro that uses devenv I will try to fix it (and we could also add it to templates/checks).

@MrFoxPro How does it break them? If you give me a repro that uses devenv I will try to fix it (and we could also add it to templates/checks).

Okay I will try. What I mean by breaking is all binaries provided by packages = [] are gone (I guess because PATH overriden)

@MrFoxPro In the past few weeks I tidied up a bit the repository (there were things that didn't make sense) and after I tried to replicate your problem but it doesn't seem to appear.
This is the flake I'm using:
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    devenv.url = "github:cachix/devenv";
    agenix-shell.url = "github:aciceri/agenix-shell";
  };

  outputs = inputs: let
    system = "x86_64-linux";
    pkgs = inputs.nixpkgs.legacyPackages.${system};
    lib = pkgs.lib;
    installationScript = inputs.agenix-shell.packages.${system}.installationScript.override {
      agenixShellConfig.secrets = {
        foo.file = ./secrets/foo.age;
      };
    };

    in {
      devShell.x86_64-linux = inputs.devenv.lib.mkShell {
        inherit inputs pkgs;
        modules = [
          ({ pkgs, config, ... }: {
	    packages = [ pkgs.hello ];

            enterShell = ''
	      source ${lib.getExe installationScript}
	    '';
          })
        ];
      };
    };
}

I also just added this example to templates.


Proposal: consider using 2-way bindable structures.

I know that, this might sound as a paradigm change, however inspired by this library, I've created a poc library for 2-way bindable structures, that might be considered for solid:
This would change api in following way:
const User = () => {
  const user = useState({ firstName: "Adam", lastName: "Smith" });
  return (
    <>
      <input value={user.firstName()} onChange={(e) => user.firstName(e.target.value)} />
      <input value={user.lastName()} onChange={(e) => user.lastName(e.target.value)} />
      <SomeUserPanel user={user()} setUser={value => user(value)} />
    </>
  );
  // or 2 way binding approach
  return (
    <>
      <input $value={user.firstName} />
      <input $value={user.lastName} />
      <SomeUserPanel $user={user} />
    </>
  );
};

You could easily create a directive to have bidirectional data binding, i.e. <input use:bind('value', user.firstName) />. Everything else is just semantic sugar.

I did very intentionally design Solid in a way that would make 2-way binding require specific consideration. As @atk suggested for the input case it would be pretty easy to setup a custom directive for this. Like if it was just for inputs you could probably do this:
function model(el, accessor) {
  const [s, set] = accessor();
  el.addEventListener("input", (e) => set(e.currentTarget.value));
  createRenderEffect(() => el.value = s());
}

const [firstName, setFirstName] = createSignal("");
<input use:model={[firstName, setFirstName]} />

But this could be tailored even more to your case where you have wrappers.
I think that this request is 2 part.

Have a signal that combines getter/setter functions like KnockoutJS.
Have a syntax that automatically does the 2-way binding.

The first is easy to do for anyone, and I don't intend to change the default signature. As I said it is very much intentional. There are consequences to this beyond my desire for unidirectional flow (which I could and have written full articles about). Mostly that our accessors know they are just functions. Any function. I don't want isSignal to be a thing ever. There are all the weird mishaps with people accidentally providing Signals to argumentless functions that end up having or eventually having arguments.
Beyond DX issues there are performance considerations when people start being pushed to provide wrapped values that are special. Ultimately adding another official form is confusing.
From that perspective similarly having sugar for the JSX bindings seems out of place. Of course, a custom directive addresses this reasonably.
I'm pretty happy that if someone like yourself wanted to take things this way they could. But I don't want to muddle the patterns/best practices we're building here. If a good pattern emerges from the community that could be a consideration, but I don't think the framework can support being multi-paradigm itself right now.

thanks for detailed feedback, will certainly look to the use directive approach.

Since this is sort of open ended and proposal of sorts I think we should move it to discussions until there is an actionable item for it.


unit tests produce RuntimeWarning: invalid value encountered in double_scalars

Let's prioritize fixing this, I've seen it occur for our Learn3 users and it's quite unsettling for them.
gpkit/nomials/data.py:186: RuntimeWarning: invalid value encountered in double_scalars
  mmap[i][j] = mag(expmap[exp][j]/c)

Once fixed, @galbramc should enable parsing the logs for RuntimeWarnings

It happens in models as well:
gas_solar_trade/gassolar/environment/solar_irradiance.py:40: RuntimeWarning: overflow encountered in exp
tau = np.exp(-0.175/costhsun)
overflow is also not a good thing. I really don't know why these things are not considered errors by numpy.

This is what numpy does anytime it casts to inf or nan, I think. I can fix the one in data caused by a 0-monomial, but it's generally a useful message.

I just saw this in my email. I'm still confused by how it uses the nan and just continues going. Why isn't fine final answer a nan? Where does the nan disappear so that it is not relevant in the computation?

I think this one in particular is creating an inf, which ends up on the greater-than side of a constraint and so makes the constraint trivially easy.

So is that legitimate behavior? Are you explicitly trying to test for that? I don't think it belongs in the testing if this is a mere accident. If you want to allow inf to be an upper bound, then you should have a test that checks that explicitly.

If it results in a valid constraint, I'm tempted to let users get away with it...but probably raising an error in such instances wouldn't inconvenience them too much.

In the Learn3 case I bet it's because of a 0-substitution, which is a whole 'nother unexpected use case that we should probably make a better interface for.

Yeah, I don't know how reliable things are in regards to relying on NaN or Inf. Neither one is really a number, and something about working with non numbers in a numerical calculations makes me uneasy.

This shouldn't happen anymore with NomialMap


Add suggestions, give more priority to suggestions over the detailed statistics

Fix #20 fix #19 fix #22

Going to merge, no rush on review but feel free to take a look and offer suggestions.


Update out of date link to ESFAs guide to R and git

Describe the bug
Under other resources, there is a link to ESFAs guide to R and Git is out of date and needs replacing. New link is : https://rsconnect/rsc/esfa-r-training/
Expected behaviour
The out of date link should be replaced and to lead to https://rsconnect/rsc/esfa-r-training/
Additional context
Out of date link issue and new link sent to STD mailbox

The link seems to work and is current


Improve JSON serialization for WebAuthn data classes

This PR adds better support for JSON serialization for the WebAuthn data classes, and for using them with the Fido2Server.
See #146 for details.

Hello @dainnilsson,
If you believe that this is ready for testing, can you release it as RC? so we start testing it.
Thanks.

Yes or here on github, as I'll try to make the library conform with fido-alliance tests.

Hi @dainnilsson,
I tested the new implementation, and I've some comments shall i add them here or open an issue per comment?

@mkalioby Here is fine!

Ok, here are the issues, I faced.

How to get the attestation_object while completion registeration using server.register_complete(state,response=json)?
the challenge in the authentication is returned as bytes which fail with the standard JSON encoder, so I had to replace the values with the one in the state, but it is fine in registration.
the allowCredentials is also bytes, so it  fails with the JSON encoder, can it be return as list of dict in the following format [ {"id":websafe_encode(x.credential_id),"type":"public-key"} for x in credentials]. This is conforming to the standard.

Finally, there are some minor tweaks for the FIDO2 Conformance, I can submit them as a PR.

Thank you for testing!

You can use the data objects to parse the response and access the attestation object via it  (data here is the json data from the client):

registration = RegistrationResponse.from_dict(data)
att_obj = registration.response.attestation_object
auth_data = server.register_complete(state, registration)

and 3. I don't follow what you mean here. Are you talking about the value returned from server.authenticate_begin? That should be immediately serializable to json, just like the one from server.register_begin. Do note that you need json to use the Mapping interface of the options object, by explicitly converting it into a dict:

options, state = server.authenticate_begin(credentials)
json_to_client = json.dumps(dict(options))

If you are doing this and its not working, could it be that you're not enabling the feature?
fido2.features.webauthn_json_mapping.enabled = True

Thank you for testing!
1. You can use the data objects to parse the response and access the attestation object via it  (`data` here is the json data from the client):

registration = RegistrationResponse.from_dict(data)
att_obj = registration.response.attestation_object
auth_data = server.register_complete(state, registration)

That what I did yesterday after opening the function code and did it in my view, in fido2==1.0.0 there was att_obj = AttestationObject((data['attestationObject'])) after decoding the cobr, can't you make the function return a tuple of auth_data and attestation_object instead of just auth_data

2. and 3. I don't follow what you mean here. Are you talking about the value returned from `server.authenticate_begin`? That should be immediately serializable to json, just like the one from `server.register_begin`. Do note that you need json to use the Mapping interface of the options object, by explicitly converting it into a dict:

options, state = server.authenticate_begin(credentials)
json_to_client = json.dumps(dict(options))

If you are doing this and its not working, could it be that you're not enabling the feature?
fido2.features.webauthn_json_mapping.enabled = True

Here is the screenshot for the options["publicKey"] in authentication_begin function

You can see the options_dict has bytes for the challenge and the credentials.
I'm enabling the new feature at the start of each function.

Ok, so I take it that 2 and 3 are resolved, thanks for checking!
As for 1. and making the function return a tuple instead of just auth_data: That's certainly possible, but it's also much more backwards incompatible than the rest of this change. I know it's opt-in, so it shouldn't unexpectedly break anything, but it does require an explicit change in handling the return value. On the other side, the "Mapping" functionality changes are much less likely to impact users. I would guess that most user could enable this feature without having anything break in their code.
Given that, I'm hesitant to change this. The "manual" way of instantiating a RegistrationResponse using from_dict also has the benefit of exposing other fields, not just the attestation_object.


Fails to parse hostname correctly on Chrome

URL parsing relies on the native URL implementation, which is buggy.
So new URLPattern({hostname:'example.com'}).test("foo://example.com") returns false in Chrome when using this polyfill. The root cause seems to be a noncompliant URL implementation: https://issues.chromium.org/issues/40063064
Maybe this should use https://www.npmjs.com/package/whatwg-url instead of the native implementation?

I would say, as this is a polyfill this merely intends to add missing API:s, not fixing bugs in existing ones

I would say, as this is a polyfill this merely intends to add missing API:s, not fixing bugs in existing ones

I agree for the most part.
The URLPattern spec refers to the "result of parsing" a string. That refers to the algorithm in the URL spec, not the URL global.
Indeed, this API should work even if you delete globalThis.URL, which is not the case.


Disconnect Reason Messages Doesn't Show Sometimes

Version of Waterdog

git:Waterdog-Bootstrap:1.15-SNAPSHOT:fd407a5:301 by md_5
Expected Behavior

To show the disconnect message (such as "Internal Server Error" or "You've been banned").
Actual Behavior

Sometimes did not show the disconnect message. Sometimes it would show, sometimes it wouldn't. Would only show "Disconnected from the server."
Crashdump, Backtrace or Other Files

Describe the bug

Pretty straight forward. The disconnect message is not always shown, and is sometimes replaced with "Disconnected from the server." giving the player no context in which why he or she was disconnected.
To Reproduce

Get 2 accounts and kick someone from the server with a reason.
If kick message shows, attempt again.
Attempt until shown "Disconnected from the server" without a reason.

Screenshots

Server software used:

Pocketmine
Additional context

Pretty small visual problem, that is all. Without proxy shows fine. This is kind of random and you might have to try multiple times to reproduce this bug.

This is known issue. Thanks for reporting it.

Bump, any news on this?

bump

No news about this, kinda low priority right now

No news about this, kinda low priority right now

I don't think it's a low priority...

I don't think it's a low priority...

Considering there are other issues such as #102, I doubt a visual bug is of high priority (even though it kinda sucks :d)


Fixing incorrect author.

Oops, sorry about that!

Oh I see, phew, I assumed I had made an embarrassing oversight :)
Yes I'm quite happy to be the point of contact there so you're welcome to leave me as the named contact. I still feel like I'm claiming credit for your awesome hard work but that's entirely your preference!


Totally remove onRemoteChange

I don't really understand the reason of removing it TBH, but it's been deprecated for at least three months. Should I remove it and keep patch-applied event only in Palindrome 3.0.0?
cc @tomalec @warpech

We want people to upgrade to Palindrom 3.0.0 without really noticing it, so I would try to keep as much backwards compatibility as possible.
I would prefer us to remove deprecated features when things get stable, maybe few months from now.

Rationale: adapting to it is not easy for our users, because their apps would not fail instantly.

I have looked into it and yes, onRemoteChange is deprecated since 2.0.0 (https://github.com/Palindrom/Palindrom/commit/f36b534fd4c6f5a2aff71bf5a4dc3f8a314b0e13).
@joozek78 do you remember the exact reason?
The spirit of that deprecation was to go towards DOM Events way. But maybe that was wrong? Palindrom is not DOM-aware, therefore it needs to mock EventEmitter. Maybe we should simplify that once again and only have callbacks in Palindrom.
PalindromDom is DOM-aware and it can trigger events.

I think the reason was simply not to duplicate the functionality of events
On Wed, 22 Mar 2017 at 14:30 Marcin Warpechowski<EMAIL_ADDRESS>wrote:

I have looked into it and yes, onRemoteChange is deprecated since 2.0.0 (
f36b534
https://github.com/Palindrom/Palindrom/commit/f36b534fd4c6f5a2aff71bf5a4dc3f8a314b0e13
).
@joozek78 https://github.com/joozek78 do you remember the exact reason?
The spirit of that deprecation was to go towards DOM Events way. But maybe
that was wrong? Palindrom is not DOM-aware, therefore it needs to mock
EventEmitter. Maybe we should simplify that once again and only have
callbacks in Palindrom.
PalindromDom is DOM-aware and it can trigger events.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Palindrom/Palindrom/issues/121#issuecomment-288398194,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFvBIWTTLs5RTLgyLBtXDB_Lv-Vo_dqiks5roSJqgaJpZM4MPzcP
.

I'd really like it if we got rid of the EventEmitter. It's needless except for this patch-applied.

@joozek78 haha, I just come from the principle that the best code is no code. The more you remove code the better the quality. Given no feature is sacrificed.

I agree, if you only removed code and didn't break anything, then your
change is (most probably) pure goodness
On Wed, 22 Mar 2017 at 16:22 Omar Alshaker<EMAIL_ADDRESS>wrote:

@joozek78 https://github.com/joozek78 haha, I just come from the
principle that the best code is no code. The more you remove code the
better the quality. Given no feature is sacrificed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Palindrom/Palindrom/issues/121#issuecomment-288433561,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFvBIX5kHn0EgKWEBbxdCJ32bLFbn4rJks5roTywgaJpZM4MPzcP
.

I think that starcounter-debug-aid might be listening to the events emitted by Palindrom.
We would need to change that somehow (maybe emit the events from PalindromDom)?

There is no big difference, but that would be definetly cleaner.

Actually emitting the events from PalindromDom does not fix the bad design that we have (introduced by me, I admit). Plain JS objects cannot trigger DOM events, which is why the lines https://github.com/Palindrom/Palindrom/blob/37aef7730cc17ce3f630782032381905f467d96f/src/palindrom.js#L23-L85 are used.
I would be very happy to remove that and stick to callbacks.

Closing as settled to removing events and sticking to callbacks.
As for starcounter-debug-aid, it won't be affected at all. Because it uses palindrom-polymer-client events. Not PalindromDOM's.


Merge pull request #1512 from MicrosoftDocs/master

sync to live

Docs Build status updates of commit 3657219:
:warning: Validation status: warnings
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


CloudWatch metrics from the reindexer are hitting rate limits

Spotted in the CloudWatch logs:
com.amazonaws.services.cloudwatch.model.AmazonCloudWatchException: Rate exceeded (Service: AmazonCloudWatch; Status Code: 400; Error Code: Throttling; Request ID: b6914f5d-67b4-11e7-9e42-9f8cd2761134)

which leads to
ERROR uk.ac.wellcome.metrics.MetricsSender - Failed to send incrementCount metric!

Not a massive issue as long as some metrics are sent, but would be good to fix when we’re next in this part of the codebase.

Yeah, we should batch the updates.


cargo-gra: 0.6.0 -> 0.6.2; karlender: 0.10.4 -> 0.10.11

Things done

Built on platform(s)

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

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

Build fails, will look into it soon
karlender> error: couldn't read `src/../target/gra-gen/compiled.gresource`: No such file or directory (os error 2)
karlender>    --> src/main.rs:272:26
karlender>     |
karlender> 272 |     let resource_bytes = include_bytes!("../target/gra-gen/compiled.gresource");
karlender>     |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
karlender>     |
karlender>     = note: this error originates in the macro `include_bytes` (in Nightly builds, run with -Z macro-backtrace for more info)
karlender>
karlender> error: could not compile `karlender` (bin "karlender") due to 1 previous error

cargo-gra gen fails. We need to update it.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 355603

x86_64-linux

:white_check_mark: 2 packages built:

cargo-gra
karlender


Half working memory store replaced by redis

Accidental pr. Feel free to ignore

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

Codecov Report

Merging #65 into master will decrease coverage by 0.56%.
The diff coverage is 7.01%.

@@            Coverage Diff             @@
##           master      #65      +/-   ##
==========================================
- Coverage   35.04%   34.47%   -0.57%
==========================================
  Files          29       30       +1
  Lines         799      815      +16
  Branches       34       36       +2
==========================================
+ Hits          280      281       +1
- Misses        519      534      +15

Impacted Files
Coverage Δ

src/main/scala/com/twitter/diffy/Main.scala
100% <ø> (ø)
:arrow_up:

...om/twitter/diffy/proxy/ThriftDifferenceProxy.scala
0% <ø> (ø)
:arrow_up:

.../com/twitter/diffy/proxy/HttpDifferenceProxy.scala
50% <0%> (ø)
:arrow_up:

...om/twitter/diffy/analysis/DifferenceAnalyzer.scala
0% <0%> (ø)

...m/twitter/diffy/analysis/DifferenceCollector.scala
1.85% <1.85%> (+1.85%)
:arrow_up:

...ain/scala/com/twitter/diffy/util/EmailSender.scala
94.44% <100%> (ø)
:arrow_up:

...n/scala/com/twitter/diffy/DiffyServiceModule.scala
100% <100%> (ø)
:arrow_up:

...in/scala/com/twitter/diffy/lifter/HttpLifter.scala
100% <100%> (ø)
:arrow_up:

...diffy/analysis/RedisStoreDifferenceCollector.scala
21.42% <21.42%> (ø)

...cala/com/twitter/diffy/proxy/DifferenceProxy.scala
25.92% <50%> (ø)
:arrow_up:

... and 2 more

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 f307e3f...ece4949. Read the comment docs.


Fix API version bug

I noticed this library was generating requests to the soon-to-be-retired version 7 API, in spite of what the default api_version would have had me believe. I can open an issue if needed but i hope the description here makes the bug clear:
The login URL should not include the leading v in the api version, just the numeric part.
(See docs at: https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_login.htm)
Including the leading v (as is the default behavior with the value "v29.0" results in salesforce returning a server_url with a version of 7.0, which  is being retired early next year. I've opted to leave the default value as is,  to avoid changing the library's interface, and just to change the implementation to generate the correct URL.

Also wanted to share a workaround, which is to explicitly pass a valid api_version without the leading 'v' to the Connection constructor.


Using custom SerDe methods for deserializing params in Sagemaker

This PR allows to set custom classes as parameters for Estimators. E.g. it allows to set DistributionOutput to something other than StudentT for DeepAR.
{
  "forecaster_name": "gluonts.model.deepar.DeepAREstimator",
  "distr_output": "{\"__kind__\": \"instance\",\"class\": \"gluonts.distribution.NegativeBinomialOutput\",\"args\": [],\"kwargs\": {}}"
}

Job PR-364/1 is complete.
Docs are uploaded to http://gluon-ts-staging.s3-accelerate.dualstack.amazonaws.com/PR-364/1/index.html


Preparing fix for duplicate generated structs.

W.I.P
should fix #806

This has been manually merged at https://github.com/mono/CppSharp/commit/10c86a2a10e0e3337ba5d6075a380ed9e2c8bc4b.


Update to support Pandas 1.2.0

This PR updates reciprocalspaceship to support the latest pandas 1.2.0. Based on testing, this supports versions 1.1.4 to latest, so I have adjusted our install_requires in setup.py to reflect that.

Codecov Report

Merging #42 (313686c) into master (eca32b4) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #42      +/-   ##
==========================================
- Coverage   99.18%   99.15%   -0.03%
==========================================
  Files          34       34
  Lines        1349     1303      -46
==========================================
- Hits         1338     1292      -46
  Misses         11       11

Flag
Coverage Δ

unittests
99.15% <100.00%> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

reciprocalspaceship/dataset.py
98.97% <100.00%> (-0.04%)
:arrow_down:

reciprocalspaceship/dtypes/base.py
96.55% <100.00%> (-0.28%)
:arrow_down:

reciprocalspaceship/dataseries.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/batch.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/phase.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/m_isym.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/mtzint.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/stddev.py
100.00% <0.00%> (ø)

... and 6 more

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 eca32b4...313686c. Read the comment docs.

Codecov Report

Merging #42 (313686c) into master (eca32b4) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #42      +/-   ##
==========================================
- Coverage   99.18%   99.15%   -0.03%
==========================================
  Files          34       34
  Lines        1349     1303      -46
==========================================
- Hits         1338     1292      -46
  Misses         11       11

Flag
Coverage Δ

unittests
99.15% <100.00%> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

reciprocalspaceship/dataset.py
98.97% <100.00%> (-0.04%)
:arrow_down:

reciprocalspaceship/dtypes/base.py
96.55% <100.00%> (-0.28%)
:arrow_down:

reciprocalspaceship/dataseries.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/batch.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/phase.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/m_isym.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/mtzint.py
100.00% <0.00%> (ø)

reciprocalspaceship/dtypes/stddev.py
100.00% <0.00%> (ø)

... and 6 more

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 eca32b4...313686c. Read the comment docs.


Use tiles on the Get Started page

On the API Reference page, I recently added some "tiles" for the cloud providers. This PR applies that same treatment for the Choose Your Provider selection on the Get Started page, mainly for consistency.

@justinvp Oh, awesome -- thanks for this extra context. I'll take a look and see if I can take care of those as well.


photometry card bug fix and debugging works again now

Fixes #  .
Description of the Change
Checklist
Please check all that apply to your proposed changes

[ ] HTML code change
[ ] Added package dependency
[ ] Added data
[ ] Changed django model
[ ] Documentation change
[ ] Added or changed TaskRunner

Additional context

Is this related to any of our open issues?

Is this related to any of our open issues?

ah don't think so, diego pointed out the bug but didn't add to git

actually suggest merging this in, as it'll help with debugging and running some validation jobs


Mustang outputs validation errors whereas KoSIT works

Using Mustang 2.15.0 CLI and PDF examples from current ZUGFeRD 2.3.2, for example XRECHNUNG_Reisekostenabrechnung.pdf I get errors on validation (notice that I mean the XML error, not the already known Java errors):
$ java -Xmx1G -Dfile.encoding=UTF-8 -jar Mustang-CLI-2.15.0.jar --action validate --source XRECHNUNG_Reisekostenabrechnung.pdf
13:46:44.810 [main] INFO  c.h.s.x.SchematronResourceXSLTCache - Compiling XSLT instance [cpPath=/xslt/en16931schematron/EN16931-CII-validation.xslt; urlResolved=true; URL=jar:file:/mnt/wsl/dev/code/netadvisor/zugferd/Mustang-CLI-2.15.0.jar!/xslt/en16931schematron/EN16931-CII-validation.xslt]
13:46:46.412 [main] INFO  c.h.s.x.SchematronResourceXSLTCache - Compiling XSLT instance [cpPath=/xslt/XR_30/XRechnung-CII-validation.xslt; urlResolved=true; URL=jar:file:/mnt/wsl/dev/code/netadvisor/zugferd/Mustang-CLI-2.15.0.jar!/xslt/XR_30/XRechnung-CII-validation.xslt]
13:46:46.574 [main] WARN  c.h.x.t.LoggingTransformErrorListener - [warn] Transformation warning (net.sf.saxon.trans.XPathException: A function that computes atomic values should use xsl:sequence rather than xsl:value-of)
13:46:46.576 [main] WARN  c.h.x.t.LoggingTransformErrorListener - [warn] Transformation warning (net.sf.saxon.trans.XPathException: A function that computes atomic values should use xsl:sequence rather than xsl:value-of)
13:46:46.710 [main] INFO  o.m.validator.XMLValidator - FailedAssert
13:46:46.719 [main] WARN  o.m.validator.ZUGFeRDValidator - Warning 27: Item net price MUST equal (Gross price - Allowance amount) when gross price is provided. [ID PEPPOL-EN16931-R046] from /xslt/XR_30/XRechnung-CII-validation.xslt)
13:46:46.719 [main] INFO  o.m.validator.XMLValidator - FailedAssert
13:46:46.720 [main] WARN  o.m.validator.ZUGFeRDValidator - Warning 27: Item net price MUST equal (Gross price - Allowance amount) when gross price is provided. [ID PEPPOL-EN16931-R046] from /xslt/XR_30/XRechnung-CII-validation.xslt)
13:46:46.720 [main] INFO  o.m.validator.XMLValidator - FailedAssert
13:46:46.720 [main] WARN  o.m.validator.ZUGFeRDValidator - Warning 27: Item net price MUST equal (Gross price - Allowance amount) when gross price is provided. [ID PEPPOL-EN16931-R046] from /xslt/XR_30/XRechnung-CII-validation.xslt)
13:46:46.720 [main] INFO  o.m.validator.XMLValidator - FailedAssert
13:46:46.720 [main] WARN  o.m.validator.ZUGFeRDValidator - Warning 27: Item net price MUST equal (Gross price - Allowance amount) when gross price is provided. [ID PEPPOL-EN16931-R046] from /xslt/XR_30/XRechnung-CII-validation.xslt)
13:46:46.755 [main] INFO  o.m.validator.ZUGFeRDValidator - Parsed PDF:valid XML:valid Signature:null Checksum:D335AC75A79B2AA9511F9D335852B64DCCFAD507 Profile:urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 Version:2 Took:3862ms Errors:[27,27,27,27]
<?xml version="1.0" encoding="UTF-8"?>

<validation filename="XRECHNUNG_Reisekostenabrechnung.pdf" datetime="2024-11-27 13:46:42">
  <pdf>ValidationResult [flavour=3b, totalAssertions=21440, assertions=[], isCompliant=true]
    <info>
      <signature>unknown</signature>
      <duration unit="ms">1706</duration>
    </info>
    <summary status="valid"/>
  </pdf>
  <xml>
    <info>
      <version>2</version>
      <profile>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</profile>
      <validator version="2.15.0"/>
      <rules>
        <fired>30</fired>
        <failed>4</failed>
      </rules>
      <duration unit="ms">2089</duration>
    </info>
    <messages>
      <warning type="27" location="/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction[1]/ram:IncludedSupplyChainTradeLineItem[1]/ram:SpecifiedLineTradeAgreement[1]/ram:GrossPriceProductTradePrice[1]" criterion="not(ram:ChargeAmount) or xs:decimal(../ram:NetPriceProductTradePrice/ram:ChargeAmount) = xs:decimal(ram:ChargeAmount) - xs:decimal(ram:AppliedTradeAllowanceCharge/ram:ActualAmount)">Item net price MUST equal (Gross price - Allowance amount) when gross price is provided. [ID PEPPOL-EN16931-R046] from /xslt/XR_30/XRechnung-CII-validation.xslt)</warning>
      <warning type="27" location="/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction[1]/ram:IncludedSupplyChainTradeLineItem[2]/ram:SpecifiedLineTradeAgreement[1]/ram:GrossPriceProductTradePrice[1]" criterion="not(ram:ChargeAmount) or xs:decimal(../ram:NetPriceProductTradePrice/ram:ChargeAmount) = xs:decimal(ram:ChargeAmount) - xs:decimal(ram:AppliedTradeAllowanceCharge/ram:ActualAmount)">Item net price MUST equal (Gross price - Allowance amount) when gross price is provided. [ID PEPPOL-EN16931-R046] from /xslt/XR_30/XRechnung-CII-validation.xslt)</warning>
      <warning type="27" location="/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction[1]/ram:IncludedSupplyChainTradeLineItem[3]/ram:SpecifiedLineTradeAgreement[1]/ram:GrossPriceProductTradePrice[1]" criterion="not(ram:ChargeAmount) or xs:decimal(../ram:NetPriceProductTradePrice/ram:ChargeAmount) = xs:decimal(ram:ChargeAmount) - xs:decimal(ram:AppliedTradeAllowanceCharge/ram:ActualAmount)">Item net price MUST equal (Gross price - Allowance amount) when gross price is provided. [ID PEPPOL-EN16931-R046] from /xslt/XR_30/XRechnung-CII-validation.xslt)</warning>
      <warning type="27" location="/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction[1]/ram:IncludedSupplyChainTradeLineItem[4]/ram:SpecifiedLineTradeAgreement[1]/ram:GrossPriceProductTradePrice[1]" criterion="not(ram:ChargeAmount) or xs:decimal(../ram:NetPriceProductTradePrice/ram:ChargeAmount) = xs:decimal(ram:ChargeAmount) - xs:decimal(ram:AppliedTradeAllowanceCharge/ram:ActualAmount)">Item net price MUST equal (Gross price - Allowance amount) when gross price is provided. [ID PEPPOL-EN16931-R046] from /xslt/XR_30/XRechnung-CII-validation.xslt)</warning>
    </messages>
    <summary status="valid"/>
  </xml>
  <messages></messages>
  <summary status="valid"/>
</validation>

Instead, when validating the embedded XML with KoSIT Validator 1.5.0 the XRechnung is fully validated without any errors:
Angaben zum geprüften Dokument

Referenz:
2962fa84-dec1-4829-b879-a1254a38c1a5
Zeitpunkt der Prüfung:
27.11.2024, 13:47:42
Erkannter Dokumenttyp:
EN16931 XRechnung (CII)
Erkannter Rechnungssteller:
Lieferant GmbH
Erkannte Rechnungsnummer:
280081
Erkanntes Rechnungsdatum:
15.11.2024
Konformitätsprüfung: Das geprüfte Dokument enthält weder Fehler noch Warnungen. Es ist konform zu den formalen Vorgaben.

Bewertung: Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten.

They are warnings, not errors. In the validation output, they are marked as such, and the overall outcome is status="valid". However, I'm not sure why the KoSIT validator doesn't display any warning.

Sorry, I expressed myself incorrectly. Yes, I have seen that they are “only” warnings. The question is not why they are not found in KoSIT, but why they are found in Mustangproject.
When I look at the corresponding XML file:
<ram:SpecifiedLineTradeAgreement>
  <ram:GrossPriceProductTradePrice>
    <ram:ChargeAmount>11.76</ram:ChargeAmount>
  </ram:GrossPriceProductTradePrice>
  <ram:NetPriceProductTradePrice>
    <ram:ChargeAmount>11.76</ram:ChargeAmount>
  </ram:NetPriceProductTradePrice>
</ram:SpecifiedLineTradeAgreement>

I see a GrossPriceProductTradePrice of 11.76 for the first position, a NetPriceProductTradePrice of 11.76 and no specification for AppliedTradeAllowanceCharge. This means that both amounts are mathematically correct because there is no discount.
I suspect that the Mustangproject validator expects AppliedTradeAllowanceCharge to be specified in this context, but this does not seem to be a problem with KoSIT.
I don't want to discuss what is correct. What is not nice, however, is that the two validators deliver different results here.

By the way: If the XML part contains warnings - and in this case it seems to me to be a serious error (the validator speaks of “MUST”), is the document really compliant (i.e. valid)? Is it really compliant with ZUGFeRD 2.3.2? (In this case I would expect a severity of NOTICE or INFORMATION, but not a WARNING.)

By the way: If the XML part contains warnings - and in this case it seems to me to be a serious error (the validator speaks of “MUST”), is the document really compliant (i.e. valid)? Is it really compliant with ZUGFeRD 2.3.2? (In this case I would expect a severity of NOTICE or INFORMATION, but not a WARNING.)

The text, especially the word "MUST" comes from the validating XSLT, so I guess it would be a bad idea to changes this in mustangproject.
I just compared .../XR_30/XRechnung-CII-validation.xslt (from mustangproject) and .../3.0.2/xsl/XRechnung-CII-validation.xsl (from the KoSIT validator), and for the warnings you got, there's no difference (including the flag, which is "warning" in both files). As noted, I've no idea why the KoSIT validator doesn't display them.
(What's even weirder, in other cases, the KoSIT validator does issue warnings. For example, if you have an empty ram:DefinedTradeContact element, you get a warning from Rule PEPPOL-EN16931-R008: "Document MUST not contain empty elements." The overall outcome of the validation by the KoSIT validator in this case is "Acceptable".)
I really don't want to read the code of the KoSIT validator to find out which criteria are used to decide wether a warning will be issued or not ;-)
For warnings from mustangproject, please note that it currently has a bug that can case errors to be treated as warnings. I've alread submitted a pull request for this one and hope it'll be merged before the next release. (See https://github.com/ZUGFeRD/mustangproject/pull/595).


Not support alias yet

Describe the bug
If I use alias in file, the extenstion fail to reach the file: Eg: @/component/index.tsx
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

We hope to support aliases in the future, so thank you for opening this issue. We will get back to you if we release a new version that should handle your use-case.

Is this something that's actively being planned or anything? Was thinking I might take a look at this and submit a PR if I can spare some time if not.

Just installed Sapling but sadly experienced the same issue as thanhlmm. Are you still working on a new version to come out or has the project stalled?


play back speed of mp3 file

Hi,
if we change the play back speed, the pitch also changes or not?

Yes the pitch changes.


Temperature sensor not updating.

Prerequisite

[X] Yes, I've read the readme completely.

Cache

[X] Yes, I've cleaned accessory cache and the issue still exists.

Version
1.7.0 beta 41
Device Infomation JSON File
No response
Device Control Mode
None
Logs
No response
Other Infomations
The sensor not updating issue has returned in this version. It gets the correct value when HB started and the plugin logs in, but doesn’t change after that.

Yes I’ve dropped back to 1.6 and it’s working again.
On 1 May 2023 at 17:08 +0100, gaosen @.***>, wrote:

#274 I think it's a server side issue, please submit the ticket on https://service.console.tuya.com/ with your device id, problem caused time. If you believe it's a plugin side issue, please install the old version and confirm it's working again.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

is it working in recent 1.7.0 beta versions? and are you using homeassistant tuya plugin or any other services simultaneously? the tuya account can't be used in multiple services.

#280


[build] changes to fix the build on Travis CI

Context: https://travis-ci.org/mono/Embeddinator-4000/jobs/471012684
Context: https://travis-ci.org/mono/Embeddinator-4000/jobs/471026456
Context: https://travis-ci.org/mono/Embeddinator-4000/jobs/471037351
First issue we are hitting is a missing version of Cake on MyGet:
Unable to find version '0.23.0' of package 'Cake'.
  https://www.myget.org/F/cake/api/v3/index.json: Package 'Cake.0.23.0' is not found on source 'https://www.myget.org/F/cake/api/v3/index.json'.

To fix this:

Let's remove MyGet.config and just use NuGet
Update Cake to 0.31, I recently used that version on another project

Next issue is that the build will not work using JDK 10:
Compiling binding code...
    Invoking: /usr/libexec/java_home
        /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
    Invoking: /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/bin/javac
...
Fatal Error: Unable to find package java.lang in classpath or bootclasspath

To fix this we should use the -v 1.8 switch on every call to java_home.
Next issue is that we aren't specifying a version with the #tool
directive:
The 'tool' directive is attempting to install the 'NUnit.ConsoleRunner' package
without specifying a package version number.

The latest failure on travis is related to JDK 1.8 not being installed on the build machine...
        /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
        Unable to find any JVMs matching version "1.8".

I am not sure how to fix yet... Only option might be to download/install JDK 8 our selves.

Actually every CI system broke.
Jenkins/Windows:
17:43:44 Unhandled Exception: System.InvalidOperationException: Could not determine Java SDK location. Please provide `javaSdkPath`.
17:43:44    at Xamarin.Android.Tools.AndroidSdkInfo..ctor(Action`2 logger, String androidSdkPath, String androidNdkPath, String javaSdkPath) in D:\j\workspace\embeddinator-4000-windows-pr\external\Xamarin.Android.Tools\src\Xamarin.Android.Tools.AndroidSdk\AndroidSdkInfo.cs:line 25

Jenkins/Mac:
17:43:22         Setting selected xcode to /Applications/Xcode92.app/Contents/Developer
17:43:22 xcode-select: error: invalid developer directory '/Applications/Xcode92.app/Contents/Developer'


Require CMake >= 3.5

This should address two warnings:
CMake Warning (dev) at CMakeLists.txt:1 (project):
  cmake_minimum_required() should be called prior to this top-level project()
  call.  Please see the cmake-commands(7) manual for usage documentation of
  both commands.

CMake Deprecation Warning at CMakeLists.txt:3 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

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

Comparison is base (b4cf04f) 51.30% compared to head (1090745) 51.23%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #22      +/-   ##
==========================================
- Coverage   51.30%   51.23%   -0.07%
==========================================
  Files          22       22
  Lines        2912     2912
==========================================
- Hits         1494     1492       -2
- Misses       1418     1420       +2

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


Wip rocmtest trial mi200

merge changes in develop branch to wip-rocmtest-trial-mi200

We generally do not need to open a PR to merge into the trial branch :)

The merge direction of this PR is not correct

🥲

@junliume I can update trial branches if you wish (but I need to open PRs because I can't update branches in this repo)

[TIP] 💡
git checkout develop &&\
git pull origin develop &&\
git checkout wip-rocmtest-trial-mi200 &&\
git pull my wip-rocmtest-trial-mi200 &&\
git merge --no-commit develop

Then observe changes, resolve merge conflicts (if any), commit and push. Basically merges should be trivial; beware if this is not the case.
Maybe it is worth opening PRs for this for a while and assign me as a reviewer, for a while at least.

@nyamodil See previous comment.

@atamazov will do so, on any trial branch merges intended. thank you.


Avalonia doesn't properly recreate the state of a control

Discussed in https://github.com/AvaloniaUI/Avalonia/discussions/13444
Describe the bug
If you cut out a control from the hierarchy and return it back later to the same place Avalonia doesn't remember the state it was in before but recreates it from scratch.
WPF does remember.
To Reproduce
Steps to reproduce the behavior:

Open Avalonia issue app and WPF test app.
(Observe that pressing the DataTemplate1 and DataTemplate2 buttons has the same behavior for both apps)
Change the state of the control created by the DataTemplate, so in A: either choose something from the combobox, or in B: write something into the textbox
Observe that pressing the Root Replace and Root Return has different behavior in Avalonia compared to WPF
Avalonia forgets the state but WPF remembers it

Environment

OS: Windows
Avalonia-Version: 11.0.2

Additional context
AVALogicalAndVisualTreeIssue.zip
WPFLogicalVisualTreeTest.zip

If you need special handling, you can always implement IDataTemplate: https://github.com/AvaloniaUI/Avalonia.Samples/tree/main/src/Avalonia.Samples/DataTemplates/IDataTemplateSample
In this, you can do your caching as needed I believe.

NOTE
While Avalonia is somewhat close to WPF, it's not a direct clone, so some things may work different than in WPF. I'll leave it to the team to decide if that is an actual bug or by design.

I am creating a library so I was looking at the current functionality since I wanted to make something that will work without any adjustments so IDataTemplate doesn't really help me here. But thanks for the tip.
I've labeled it a bug because I found the current behavior to be different from what I would have expected. We're recreating something that doesn't have to get recreated. I'm still new to the inner workings of Avalonia so I couldn't pinpoint why it's done in this way maybe it has a good reason to be this way.

If you cannot you DataTemplates, maybe a behavior or attached properties can help you for the time beeing.


Restructure main readme to show big picture and detail

As outlined in the RC5 Retrospective document:
The specification overview / main readme needs to show the high level and low level concepts in a clear and coherant manner.

I like the approach of https://github.com/ReactiveX/RxSwift#i-came-here-because-i-want-to-
I think we should do this to partly resolve this issue.


gs1.1 constants and comments

Add new gossipsub constants as well as comments for existing constants
A future PR will change how the gossipsub multicodecs are handled (eg: filtering peers by the gossipsub v1.1 multicodec instead of the gossipsub v1.0 multicodec)

Codecov Report

Merging #85 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #85   +/-   ##
=======================================
  Coverage   80.00%   80.00%
=======================================
  Files           1        1
  Lines          10       10
=======================================
  Hits            8        8
  Misses          2        2

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 97943fe...0b3e5e4. Read the comment docs.


Unable to pass in an existing source map?

Hi again,
Firstly thanks for fixing the CLI since my initial issue / and the last few updates since.
Secondly, I noticed it is not possible to pass in an existing source map? I have a map from a previous step and would like to ensure this is remapped, just like JSUglify offers.
Would this be possible to add in an update?

I doing it in the webpack plugin, so i can move it from plugin to obfuscator

But i still not shure what i should do this - it is really important to make this functional? Because you can remap exiting source map with source map from obfuscator with help of https://github.com/azu/multi-stage-sourcemap
https://github.com/javascript-obfuscator/webpack-obfuscator/blob/master/index.ts#L72

closed. for this functional use https://github.com/azu/multi-stage-sourcemap


docs: Material Design implementation

Type: docs
Platform: all
Hi there,
There is a ionicmaterial implementation but I'd like to use AngularJS Material implementation. Would it work nicely?

Greetings @Kinnonii!
My sensors indicate that you need to update your issue through our custom issue form. We are now requiring all issues to be submitted this way, to ensure that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
I will have no choice but to close this issue if it is not resubmitted through the form. Please fill out the rest of the form, so that I may use my friendly robot powers to assist you.
Thank you!

Ionic Material is pretty cool. Ionic is moving towards making Material Design naturally part of Ionic, but we've still a ways to go. We actually worked on the Angular Material project, but the codebases are substantially different. I don't think they'd intermingle very well. You'd have to migrate things component by component, at which point, you'd have Ionic Material anyway.
Since it's not really a bug, I'm going to close the issue, but you may want to check out this conversation in the forums:
http://forum.ionicframework.com/t/is-there-a-tutorial-for-using-ionic-and-angular-material/14662


Update the changelogs for 7.46.0

What does this PR do?

Update the changelogs for 7.46.0
Motivation

Final release on the way
Additional Notes

We will wait for 7.46.0 to be out to merge this PR
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached
[ ] If the PR doesn't need to be tested during QA, please add a qa/skip-qa label.

What does this PR do?

Update the changelogs for 7.46.0
Motivation

Final release on the way
Additional Notes

We will wait for 7.46.0 to be out to merge this PR
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached
[ ] If the PR doesn't need to be tested during QA, please add a qa/skip-qa label.

https://github.com/DataDog/integrations-core/pull/15585#pullrequestreview-1581758973


shell: Clarify revert to HTTP

Before this change, it wasn't clear what one would revert from, as there was no context being given.

To be honest, it sounds the same to me and originated from m0n0wall. Such things are better explained in the documentation.

I'm not sure how it can "sound the same" - the old text mentions X and the new one X and Y. They cannot sound the same :)
I'm guessing that as a developer knowing the ins and outs of this software, it can be very hard to see where small changes like this one are coming from and why they're needed. But from regular users' perspectives it's different. We see and interpret things in the user interface quite a bit differently than those having used this software for a long time.
Yesterday I installed a new OPNsense. After the initial install I had to reconfigure the interface addresses to make it reachable over the network (I couldn't access it by <IP_ADDRESS>), so in the console I went to the option to reconfigure the IP addresses.
After configuring the addresses, I started getting questions about the web GUI and other things, which in itself is pretty unexpected. All I had asked to do was change the IP addresses - I had never asked to reconfigure anything related to the web GUI or similar. So that's the first thing to ponder, but whatever.
Then comes the question "Do you want to revert to HTTP as the web GUI protocol?". At this point in time I have never configured the web GUI at all on this firewall, so I have no idea what it is currently set to. Hence I cannot possibly know what I am reverting from, and even though I could go through a thought process an assume that it means "from HTTPS", that's far from certain. There's an unknown chance that "reverting to HTTP" includes other changes as well. I simply do not know the context, because there never was a context given here.
That's why this small change is important. In short, it simply removes ambiguity, and that's a very important thing in a user interface. Please let's just merge this - I wouldn't have taken the time to open a PR if this wasn't correcting a flaw in the text.
FWIW, I'm very much aware of an into not complicating user interfaces or text unnecessarily, I work in other projects where there's a ton of user facing change requests, and I'm one of those that push quite hard on not making things too verbose or having too many options unless they're really needed. But as developers we also have to keep in mind that our users do see things that we don't see, at least they interpret them differently in many cases, and most often the way new users interpret a user interface says more about how good the user interface is, than how we interpret it does.

I agree with Franco here, these things are better explained in the docs (https://github.com/opnsense/docs), in an attempt to provide more context, it will never be complete and for most users this change doesn't really clarify more than the original line. Keep in mind that every change proposed costs time from many others (managing the project, documentation, translations).
It's often good to consider the amount of effort a seemingly simple change costs in reality, for these type of changes we really do seek more justification.
Maybe you do want to write a chapter about the console options for the docs, I don't think that's already there.

It's two additional words. How can this possibly be any harm, or any more maintenance burden? I'm very well aware of maintenance burdens. This is not one of them.
Do you realize that you are effectively suggesting that people go and read the documentation, to understand what this simple text means? I'm at a loss of words.
Again, how can this small change possibly be a problem for anyone, including you as developers.

let's agree to disagree, time spend in elaborate discussions about changing this sentence (which has been in predecessors of the product for over 15 years), would likely be better spend on improving the documentation.
My main concern is that this change doesn't really clarify more than it already does, quoting your own comment:

There's an unknown chance that "reverting to HTTP" includes other changes as well. I simply do not know the context, because there never was a context given here.

If that's the problem, adding a "from https" doesn't really solve these concerns as well.... if context is unclear, it's always a good idea to read the manual.... hence my previous question about extending the docs.
Consider this my last comment on the discussion by the way, I thought I could be of help providing some direction, which doesn't seem to be the case.

There's an unknown chance that "reverting to HTTP" includes other changes as well. I simply do not know the context, because there never was a context given here.

If that's the problem, adding a "from https" doesn't really solve these concerns as well.... if context is unclear, it's always a good idea to read the manual.... hence my previous question about extending the docs.

This is simply not an accurate assessment. The old text doesn't say anything about what is being reverted from, which means that something is being changed to HTTP, but you don't know if it's HTTP and/or something else as well. The new text explains exactly what is being reverted from, which means that you know HTTPS is what is being changed to HTTP.
Can you please not just realize that even if you don't agree that this is needed, it will definitely not cause any more maintenance burden, not tae up any relevant additional screen estate, and will not cause any harm in any way, and accept it?
Just because things has been the way they are for 15 years doesn't have to mean that they were right. If that was the case, we wouldn't see changes being made at all. So it's a moot point.
I completely agree that we shouldn't be spending time on discussing this.

IMHO this question should be removed from the dialog, who wants to run this on http in a LAN. Even offering http access nowadays is really risky :)

I get what @rawtaz is getting at. I think the confusion he's speaking of its the word "revert". Since a fresh install is default HTTPS technically there's nothing to revert.
So instead of proposed change "Do you want to revert from HTTPS to HTTP for the web GUI protocol?" maybe it should read something like "Do you wish to use HTTP instead of HTTPS for the web GUI protocol?" this to me reads more clearly.
revert: To go back to a former condition

Someone with better communication skills put it into words way better than I did. Thank you!
Besides @FingerlessGlov3s suggestion, here's another slightly shorter one in case it's more in line with core developers' intentions: Do you want to change the web GUI protocol from HTTPS to HTTP?
I'd love to find a compromise where the text is improved and keeps core developers happy :+1:

Yes that last suggestion sounds reasonable. If you change the PR I will merge it.
Cheers,
Franco

Awesome, I updated+rebased the PR.

Merged, thanks all!


RuntimeError: Failed to import transformers.models.blip.modeling_blip due to missing split_torch_state_dict_into_shards from huggingface_hub

I encountered an issue when trying to install the dependencies from requirements.txt and subsequently importing pyreft. The following error is raised:
javascript
Copy code
RuntimeError: Failed to import transformers.models.blip.modeling_blip because of the following error (look up to see its traceback):
Failed to import transformers.generation.utils because of the following error (look up to see its traceback):
cannot import name 'split_torch_state_dict_into_shards' from 'huggingface_hub' (/usr/local/lib/python3.10/dist-packages/huggingface_hub/init.py)

I believe updating huggingface-hub to 0.23.0 and restart the kernel should work - let me know if you met any further issues

thanks for your response the requirements.txt that I am using. However the conflict is explained below:
INFO: pip is looking at multiple versions of pyvene to determine which version is compatible with other requirements. This could take a while.
ERROR: Cannot install -r requirements.txt (line 4) and huggingface-hub==0.23.0 because these package versions have conflicting dependencies.
The conflict is caused by:
The user requested huggingface-hub==0.23.0
pyvene 0.1.2 depends on huggingface-hub==0.20.3
can you please help me what should i do?

If you are using colab, maybe you can try %pip install huggingface-hub=0.23.0. I will consider updating huggingface-hub on pyvene too

Thanks a lot for your time and response,
I am looking forward to that.

Hello, I still run into this error on Colab, even when downgrading huggingface-hub. Unfortunately, the main demo (https://colab.research.google.com/github/stanfordnlp/pyreft/blob/main/main_demo.ipynb) doesn't work because of this issue. Have you found a fix?
RuntimeError: Failed to import transformers.models.blip.modeling_blip because of the following error (look up to see its traceback): Failed to import transformers.generation.utils because of the following error (look up to see its traceback): cannot import name 'split_torch_state_dict_into_shards' from 'huggingface_hub' (/usr/local/lib/python3.10/dist-packages/huggingface_hub/__init__.py)


VS Razor Code Actions

Summary of the changes

Razor Code Actions support for Add Using + Fully Qualified Namespace for Tags

Extract to Component & Create Component should just work, however haven't had a chance to test them out yet as the create document commands aren't currently available directly.
Support for both VS + VS Code Code Actions
Added/updated tests
Note seeing this sometimes: https://github.com/dotnet/aspnetcore/issues/25105

Background document is "correct"
Investigating still

Fixes: https://github.com/dotnet/aspnetcore/issues/23985

Love how the preview is available for a lot of the code actions. I'd reach out to the LSP platform team to see why they didn't provide the "preview" support for edits that were already available on the CodeAction

Updated with PR feedback.
@NTaylorMullen suggested removing the existing razor/runCodeAction entirely to simplify the flow and minimize the endpoints we need to maintain. Made the appropriate changes there. 😄

Also, would be good to make sure the changes here didn't accidentally regress VSCode.

Yep, validated all four in VSCode 💯

Ahhh one other note I forgot to mention that can totally be done in a follow up. We'll need to disable the file operation based CodeActions in LiveShare guest/Codespaces scenarios until they make them work. That's because the underlying system will pre-create the file based off the existence of the light bulb. Meaning when a user is typing <abcd> it's super likely LiveShare will create multiple files: a.razor, ab.razor, abc.razor, 'abcd.razor' etc. and destroy users file systems.
This alone may be a difficult problem to handle. Some ideas would be to implement a MiddleLayer (assuming the LSP platform supports them for CodeActions) or somehow utilize the InitializationOptions OR just pass in an extra parameter/service to the Razor language server that's VS aware.


[fcl] Adds optional Authentication Refresh Service to fcl.authenticate

Allows for optional Authentication Refresh Service to update fcl.currentUser session data before sending tx
There was no way to know if a user’s wallet provider session had expired or ended for other reasons.
This led to a situation where a user who is logged in to an app initiates a transaction which fails silently and without any clear error. The user needs to reauthenticate, but the client (and FCL) were unaware.
Wallet Providers can now provide an optional Authentication Refresh Service to FCL upon initial configuration.
If provided, FCL will attempt to refresh the user's session by executing this service before a transaction.
This solution provides a standard way for the app to reauthenticate a user or inform them that their wallet session has expired.
FCL will use the authn-refresh service endpoint and method provided to request updated authentication data from the Wallet Provider.
The service is expected to reauthenticate the user or prompt for approval if required.
If FCL receives back an APPROVED PollingResponse, it rebuilds fcl.currentUser with updated session data and services
and the Authentication Refresh process is complete.
The initial transaction can then be executed with confidence the user session is valid.

Adds new authn-refresh service and normalizer
Updates fcl.authenticate to execute before attempting to authorize tx if a user is logged in, and auth-refresh service is provided
Renames/refactors building of default discoveryService

is this really necessary ? Sorry I am not too familiar with FCL, but isn't it better to handle with http response ( like 403 )  on pre-auth ?
This will add another latency to transaction sending ( which I guess 99% of the time will success )

is this really necessary ? Sorry I am not too familiar with FCL, but isn't it better to handle with http response ( like 403 ) on pre-auth ?
This will add another latency to transaction sending ( which I guess 99% of the time will success )
(I am assuming when authentication failed it will not silently renew the session)

I know @orodio responded to your concern on the issue. Going to merge this but can continue discussion there.


Enumerate all intrinsic instance properties

@heaths,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

:white_check_mark: Build vswhere 1.0.18-beta+gbd92c60d58 completed (commit https://github.com/Microsoft/vswhere/commit/bd92c60d58 by @heaths)


mrb_str_modify segfault

EDIT: Found a minimal reproduction
[jared:~/projects/mruby] git checkout upstream/master
[jared:~/projects/mruby] git pull upstream master
[jared:~/projects/mruby] rake clean default
[jared:~/projects/mruby] mirb
mirb - Embeddable Interactive Ruby Shell

> count = 1
 => 1
> singular = 'thing'
 => "thing"
> "#{count} #{singular}#{'s' unless count == 1}"
Segmentation fault: 11
[jared:~/projects/mruby]

Previous description follows below

Getting a segfault in mrb_str_modify. Not 100% on what's causing the error yet. To capture what I can for now....
git bisect
leads me to this commit:
[jared:~/projects/mruby] git status
HEAD detached at d8fc09c
You are currently bisecting, started from branch 'cf5ca03'.
....
[jared:~/projects/mruby] git show head
commit d8fc09cf927aad33138b54bc79d286ac0636cc06
Author: Yukihiro "Matz" Matsumoto<EMAIL_ADDRESS>Date:   Wed Feb 17 11:02:29 2016 +0900

    push value for NULL AST when value is required; fix #3110

Tests & Output
Previous ruby/spec results were ok (relatively few crashes).
When moving from d8fc09^ to d8fc09 I start seeing this instead.
Most of the tests fail with the same segfault. Seems to be something in the mspec HTML formatter, since they all fail just before printing the summary for the tests to the output file.
Any tips for debugging?
Still trying to come up with a minimal reproduction...
The valgrind output shows me where in the c code the error happens. Is there a quick way to dump the ruby stack trace at that point? (edit: mrb_raise seems to generate a stack trace pretty well :)

Looks like a null pointer is being passed in as s
When I add this:
MRB_API void
mrb_str_modify(mrb_state *mrb, struct RString *s)
{
  fprintf(stderr, "mrb_str_modify\n");
  fflush(stderr);
  fprintf(stderr, "s: %p\n", s);
  fflush(stderr);
  fprintf(stderr, "RSTR_PTR %%p: %p\n", RSTR_PTR(s));
  fflush(stderr);
  fprintf(stderr, "RSTR_PTR %%s: %s\n", RSTR_PTR(s));
  fflush(stderr);

The first 3 test files all fail with the same final output:
mrb_str_modify
s: 0x0
==35178== Invalid read of size 1
==35178==    at 0x10001FE40: mrb_str_modify (string.c:664)
==35178==    by 0x10002020E: mrb_str_concat (string.c:766)
==35178==    by 0x100034039: mrb_vm_exec (vm.c:2217)
==35178==    by 0x100035026: mrb_top_run (vm.c:2448)
==35178==    by 0x100063418: load_exec (parse.y:5637)
==35178==    by 0x10000161B: main (mruby.c:226)
==35178==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==35178==
==35178==
==35178== Process terminating with default action of signal 11 (SIGSEGV)
==35178==  Access not within mapped region at address 0x1
==35178==    at 0x10001FE40: mrb_str_modify (string.c:664)
==35178==    by 0x10002020E: mrb_str_concat (string.c:766)
==35178==    by 0x100034039: mrb_vm_exec (vm.c:2217)
==35178==    by 0x100035026: mrb_top_run (vm.c:2448)
==35178==    by 0x100063418: load_exec (parse.y:5637)
==35178==    by 0x10000161B: main (mruby.c:226)
==35178==  If you believe this happened as a result of a stack
==35178==  overflow in your program's main thread (unlikely but
==35178==  possible), you can try to increase the size of the
==35178==  main thread stack using the --main-stacksize= flag.
==35178==  The main thread stack size used in this run was 8388608.
==35178==
==35178== HEAP SUMMARY:
==35178==     in use at exit: 1,924,475 bytes in 22,230 blocks
==35178==   total heap usage: 147,147 allocs, 124,917 frees, 48,801,309 bytes allocated
==35178==
==35178== LEAK SUMMARY:
==35178==    definitely lost: 4,096 bytes in 1 blocks
==35178==    indirectly lost: 0 bytes in 0 blocks
==35178==      possibly lost: 0 bytes in 0 blocks
==35178==    still reachable: 1,885,686 bytes in 21,808 blocks
==35178==         suppressed: 34,693 bytes in 421 blocks
==35178== Rerun with --leak-check=full to see details of leaked memory
==35178==
==35178== For counts of detected and suppressed errors, rerun with: -v
==35178== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Awesome! Thanks!


addEventlistener to Window

@Jukoo Could you please sign the CLA and I'll merge this :)

Added Myself separately :)

CLA signed


There is no document formatter for 'html'-files installed

Issue Type: Bug
Trying format my html file Crl+Alt+F and receive this message:
"There is no document formatter for 'html'-files installed."
VS Code version: Code 1.23.1 (d0182c3417d225529c6d5ad24b7572815d0de9ac, 2018-05-10T17:11:17.614Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 1992)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwarevideo_decode: enabledvideo_encode: enabledvpx_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.89GB (8.65GB free)

Process Argv
C:\Program Files\Microsoft VS Code\Code.exe

Screen Reader
no

VM
0%

Extensions (4)

Extension
Author (truncated)
Version

ng-template
Ang
0.1.9

angular2-snippets
dan
1.0.19

Angular-BeastCode
Mik
6.0.15

angular2-inline
nat
0.0.17

I can't reproduce as the built-in HTML support has a formatter which is installed by default.
There are two ways of disabling it:

"html.format.enable": false
disable the built-in 'HTML Language Feature` extension.

Can you check in your settings and in the extensions viewlet that this is not the case?
Also, in an editor that shows an HTML file, is the 'Format' action available in the context menu?

@aeschli it's my bad.
Thx for your time!
I didn't see next tab 'WORKSPACE SETTINGS' after 'USER SETTINGS'. In that tab property "html.format.enable" was false.
But, I didn't manualy change the property (I event didnt know that I can).
The same problem at my laptop too and I suggest it can be caused one of extension.


Timestamps for crashdetect_log

Is there an option to set timestamps for crashdetect_log, or could that be something added to the plugin?

Added this in https://github.com/Zeex/samp-plugin-crashdetect/commit/dcac8159f385cc654e89403e070a82649678e0c0. It will be released in 4.17.


figure out how to support monthly devnets

We're planning on moving away from a single long-lived devnet and towards monthly devnets tied to upcoming upgrades. However, the SCR does not handle this nicely today.
Context from George

Context from Mark

if we wanted to use the superchain registry as part of the release candidate devnet flow then it would be a lot more adding chains to the superchain registry, which would make us feel the pain of doing so. If we didn’t use the superchain registry for the transient devnet then the superchain registry flow wouldn’t be tested until testnet.

IMO, we should treat the Superchain registry add chain flow as an upstream dependency for the success of the monthly devnet flow. The other words, the devnet flow can’t be considered easy unless the SCR add chain flow is also easy.

We would probably want to streamline the process of removing a chain, in fact an entire superchain, from the registry. This could be done with new add-chain (now called ops) commands. We haven't done this kind of thing before, but I don't see any fundamental problems.


pixiecore quick xyz is legacy BIOS only by default?

Not a big issue, but I happened to notice that the quick cmd for serving up netboot.xyz is hardcoded to serve the legacy bios kernel image even to uefi clients which fails to boot iPXE with an exec format error (as you'd expect)
Switching the hardcoded location to a uefi image does work fine, so it's an easy workaround, but I thought I'd report it incase there was something neater we could do here:
diff --git a/pixiecore/cli/quickcmd.go b/pixiecore/cli/quickcmd.go
index 883195e..3360d0a 100644
--- a/pixiecore/cli/quickcmd.go
+++ b/pixiecore/cli/quickcmd.go
@@ -302,7 +302,7 @@ func netbootRecipe(parent *cobra.Command) {
                Long: `https://network.xyz allows to boot multiple operating
        systems and useful system utilities.`,
                Run: func(cmd *cobra.Command, args []string) {
-                       kernel := "https://boot.netboot.xyz/ipxe/netboot.xyz.lkrn"
+                       kernel := "https://boot.netboot.xyz/ipxe/netboot.xyz.efi"
                        fmt.Println(staticFromFlags(cmd, kernel, []string{}, "").Serve())
                },
        }

I think having a command-line option/flag here would be okay. AFAIK thee original author doesn't maintain this project anymore, but I've used it in the past to great success. Perhaps one of us can fork it if we have active use for it (I don't at the moment :/)

So the quick cmd already has cmdline options to let you specify a custom iPXE binary for BIOS, 32-bit UEFI and 64-bit UEFI
And the remote clients specify in their request what they would like:
https://github.com/danderson/netboot/blob/66e5fba6f6632bd6dd144100a91a448e8fdb8450/pixiecore/pxe.go#L100-L105

I don't promise to maintain pixiecore, but as it happens I hit the same boot failure with xyz and would love to fix it :P
Sounds like the recipe needs to be updated to send different images based on the client's requested architecture.

Would a PR to fix this get accepted?
Seems like the issue is still present


development: add option to launch story at specific slide

A story should start at the specified slide when it loads. Slides are counted automatically, beginning with 1.

Also add the option to use negative numbers with the following logic:
-1 - last slide
-2 - the slide before the last slide
and so on.

Use case:

when developing a story, it is cumbersome to step again and again to a specific slide.
Solutions:
startslide attribute to the HTMLElement
URL # - change/update - this 2nd solution could be enabled when needed, but best to leave it switch off by default, since the URL fragment can be used by the user for different purposes.


MGMT-18834: validate before each patch if something changed before running patch itself.

MGMT-18834: validate before each patch if something changed before running patch itself.
Add logging for each patch operation

/lgtm


feat: stabilize lockfile v4

What does this PR try to resolve?
Stabilize lockfile v4, which effectively contains only one change: #12280.
How should we test and review this PR?
v4 cannot be constructed at this moment unless people deliberately change their lockfiles to version = 4. No user-perceivable change is involved.
The change of SourceId serialization is postponed to the time v4 becoming the default lockfile version. That seems more reasonable than doing it now.
Additional information
I failed to resolve any other issue listed in https://github.com/rust-lang/cargo/issues/12120. They are either too complicated or not worthy. Therefore I think we can just ship this without waiting.

I failed to resolve any other issue listed in https://github.com/rust-lang/cargo/issues/12120. They are either too complicated or not worthy. Therefore I think we can just ship this without waiting.

Is there a reason we are wanting to go forward with this now rather than wait?

Is there a reason we are wanting to go forward with this now rather than wait?

I cannot predict how long we will wait for other issues getting addressed. It's more meaningful to ship a fix when we already have one.
I've waited for https://github.com/rust-lang/cargo/issues/10801 but that failed. I gave a shot on https://github.com/rust-lang/cargo/issues/12464 but after chatting with Eh2406 today, I quit. Fixing #12464 entails a fundamental overhaul of the current resolver that I am not capable of. pubgrub is going to provide a different (and clearer?) way to address patches.

@rfcbot fcp merge
This will stabilize the V4 lockfile which includes #12280.  The idea being to go ahead and get this into people's hands now rather than waiting for a certain number of fixes to make it in.

:umbrella: The latest upstream changes (presumably #12860) made this pull request unmergeable. Please resolve the merge conflicts.

Thanks, sorry for the delay!
@bors r+

:pushpin: Commit f8a47fa6b34c636ab9d670898e9eff182ef1ab2d has been approved by ehuss
It is now in the queue for this repository.

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing f8c152df3b029fd730b0f9707e1b32b7e9e044f9 to master...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing f8c152df3b029fd730b0f9707e1b32b7e9e044f9 to master...

:eyes: Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request.


How to check/re-establish connection?

Hi,
We are using this cool library in one of our websites. (Currently version 7.1.0).  We are using it with SignalR.  We basically copied the example. But we have started having problems where it stops working. The only way we have of fixing the connection at them moment is restarting the App Pool.
Is there a way to check if the current connection is working and if not Stop/Re-Start the table dependency?

I had a bit more of a search in closed issues and found a number of people have asked similar questions. None of which seemed to have a solution.

Sorry for this late response. I have a lot of to do.
When a connection is lost, there is not way to re-connect your SqlTableDependency instance to its database objects (trigger, queue etc...). When the connection is lost, these object are lost too.
In order to see if the SqlTableDependency  is still working you can:
1-check its status. Example:
if (_tableDependency.Status == TableDependencyStatus.StopDueToError) ...
2-Substribe to OnError event:
this._tableDependency.OnError += this.TableDependency_OnError;
May be you can have a look at test named StatusLostConnectionTest present in GIT HUG


update network policy docs on whitelisting

This is a Bug Report
Problem:
We need to clarify node network policies, because node local traffic is whitelisted https://github.com/kubernetes/api/blob/master/networking/v1/types.go#L64 .
Proposed Solution:
doc node whitelists
Page to Update:

cc @kubernetes/sig-network-misc i can do this if nobody else wants it

/kind bug
/priority backlog

Note: missing docs are for https://kubernetes.io/docs/concepts/services-networking/network-policies/

/language en


Limit connectivity to Redis instances with firewall rules #544

PR Summary

Created Azure.Redis.FirewallRuleCount (AZR-000293) in Azure.Redis.Rule.ps1
Created Azure.Redis.FirewallIPRule (AZR-000294) in Azure.Redis.Rule.ps1
Created Azure.Redis.FirewallRuleCount documentation
Created Azure.Redis.FirewallIpRule documentation.
Created tests for both rules in Azure.Redis.Tests.ps1.
Updated redis-A, B, C, D, and E in Resources.Redis.json

PR Checklist

[X] PR has a meaningful title
[X] Summarized changes
[X] Change is not breaking
[X] This PR is ready to merge and is not Work in Progress
Rule changes

[X] Unit tests created/ updated
[X] Rule documentation created/ updated
[X] Link to a filed issue
[X] Change log has been updated with change under unreleased section

Other code changes

[ ] Unit tests created/ updated
[ ] Link to a filed issue
[ ] Change log has been updated with change under unreleased section

@BernieWhite, PR is ready for code review!

@BernieWhite, I had to update the CHANGELOG. Now we are ready for code review.


Remove extra lines that yield paragraph tags

I noticed inconsistent line spacing across the rendered bulleted list. These empty lines this PR removes were the cause.

Thanks for the patch. This repo doesn't accept pull requests; we'd have to fix this internally. Unfortunately, though, this is probably an artifact of copybara stripping of internal references, so it may not be feasible.

No problem. I just wanted to put the mis-render on your radar.


support dimension (time) for WMTS 1.0.0

Dear All,
Following http://portal.opengeospatial.org/files/?artifact_id=35326 there is the possibility to have the dimension, page 22 Table 9 — Parts of Dimension data structure.
e.g.
<Style isDefault="true">
  <ows:Title xml:lang="en">default</ows:Title>
  <ows:Identifier>default</ows:Identifier>
</Style>
<Format>image/png</Format>
<Dimension>
  <ows:Identifier>time</ows:Identifier>
  <ows:UOM>ISO8601</ows:UOM>
  <Default>2017-05-16</Default>
  <Current>false</Current>
  <Value>2015-07-30/2017-05-16/P1D</Value>
</Dimension>

A getcapabilities example could be:
https://gibs-b.earthdata.nasa.gov/wmts/epsg4326/best/wmts.cgi?Service=WMTS&Request=getcapabilities&Version=1.0.0
If there is no program to support it, I can have a look at it.
@tomkralidis the issue is that the WMS-T has a different structure (page 53, 06-042_OpenGIS_Web_Map_Service_WMS_Implementation_Specification.pdf),  could you give me a bit of help, maybe some points of start?
Thanks,
D

@murdav looking at http://schemas.opengis.net/wmts/1.0/wmtsGetCapabilities_response.xsd, wmts:Dimension occurs 0..n times in a given Layer element.

I would create a dimensions property which is a list of each dimension with the appropriate properties, starting at around https://github.com/geopython/OWSLib/blob/master/owslib/wmts.py#L773.  The wmts:Value property being a list of values.

Thanks for this!
Further question, I didn't find how I can run OWSLib tests before pulling the request from my fork to master. I got some minor errors (like field title has changed the value) that I can easily update.
Is it possible to run the tests locally, if so, how?
D

@murdav you can run the tests with py.test (see how Travis does it in https://github.com/geopython/OWSLib/blob/master/.travis.yml#L17).  Note you can also run tests on single doctest files.

+1 for this feature request!

Feature is implemented in #904 and for now can be used from a fork https://github.com/lubojr/OWSLib/tree/368-wmts-dimensions-support if anyone needs it

Thanks @lubojr.  Merged.


Add SlsProductVersions

This change is

all trees replaced by trues.
On Tue, Jan 24, 2017 at 1:04 PM Andrew Ash<EMAIL_ADDRESS>wrote:

@ash211 commented on this pull request.
In src/main/groovy/com/palantir/gradle/dist/SlsProductVersions.java
https://github.com/palantir/gradle-java-distribution/pull/163#pullrequestreview-18266091
:

+/**

Utility methods for checking whether version strings are valid SLS version strings,

c.f. https://github.com/palantir/sls-spec/

*/
+public class SlsProductVersions {
private static final Pattern NON_ORDERABLE_VERSION = Pattern.compile("^[0-9]+\.[0-9]+\.[0-9]+[a-z0-9-]*$");
private static final List ORDERABLE_VERSION = ImmutableList.of(

       Pattern.compile("^[0-9]+\\.[0-9]+\\.[0-9]+-[0-9]+-g[a-f0-9]+$"),

       Pattern.compile("^[0-9]+\\.[0-9]+\\.[0-9]$"),

       Pattern.compile("^[0-9]+\\.[0-9]+\\.[0-9]+-rc[0-9]+$"),

       Pattern.compile("^[0-9]+\\.[0-9]+\\.[0-9]+-beta[0-9]+$")

);

/**

* Returns tree iff the given string is a valid "orderable" SLS version.

nit: tree -> true
In src/main/groovy/com/palantir/gradle/dist/SlsProductVersions.java
https://github.com/palantir/gradle-java-distribution/pull/163#pullrequestreview-18266091
:

private static final List ORDERABLE_VERSION = ImmutableList.of(

       Pattern.compile("^[0-9]+\\.[0-9]+\\.[0-9]+-[0-9]+-g[a-f0-9]+$"),

       Pattern.compile("^[0-9]+\\.[0-9]+\\.[0-9]$"),

       Pattern.compile("^[0-9]+\\.[0-9]+\\.[0-9]+-rc[0-9]+$"),

       Pattern.compile("^[0-9]+\\.[0-9]+\\.[0-9]+-beta[0-9]+$")

);

/**

* Returns tree iff the given string is a valid "orderable" SLS version.

*/

public static boolean isOrderableVersion(String version) {

   return Iterables.any(ORDERABLE_VERSION, pattern -> pattern.matcher(version).matches());

}

/**

* Returns tree iff the given string is a valid "non-orderable" SLS version.

tree -> true
In src/main/groovy/com/palantir/gradle/dist/SlsProductVersions.java
https://github.com/palantir/gradle-java-distribution/pull/163#pullrequestreview-18266091
:

/**

* Returns tree iff the given string is a valid "orderable" SLS version.

*/

public static boolean isOrderableVersion(String version) {

   return Iterables.any(ORDERABLE_VERSION, pattern -> pattern.matcher(version).matches());

}

/**

* Returns tree iff the given string is a valid "non-orderable" SLS version.

*/

public static boolean isNonOrderableVersion(String version) {

   return NON_ORDERABLE_VERSION.matcher(version).matches();

}

/**

* Returns tree iff the given string is a valid "orderable" or "non-orderable" SLS version.

tree -> true
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/palantir/gradle-java-distribution/pull/163#pullrequestreview-18266091,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGOdwTdudHnWjjHpn5mew-Friaa3hvX8ks5rVmc1gaJpZM4Lsx7k
.

Anything else here?

Merging so I can move on; let me know if you want changes.

Looks fine to me, only thought is we might want to actually publish an sls-spec Java lib with this utility in it. Don't feel strongly, especially since this is really the only place we'd need a Java version.

Two options for such a library: could live in sls-spec repo or here. Either
we, I think we should consider renaminf GJD to sls-packaging at some point.
On Tue, Jan 24, 2017, 22:11 Mark Elliot<EMAIL_ADDRESS>wrote:

Looks fine to me, only thought is we might want to actually publish an
sls-spec Java lib with this utility in it. Don't feel strongly, especially
since this is really the only place we'd need a Java version.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/palantir/gradle-java-distribution/pull/163#issuecomment-275027869,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGOdwQXpMw9NCj6nJujX6SJnh-T7175Pks5rVueNgaJpZM4Lsx7k
.

Yeah, fine leaving it here, also fine with renaming the repo.

Made some issues, punting on both for now.
On Wed, Jan 25, 2017 at 3:56 AM Mark Elliot<EMAIL_ADDRESS>wrote:

Yeah, fine leaving it here, also fine with renaming the repo.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/palantir/gradle-java-distribution/pull/163#issuecomment-275089512,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGOdwdTGTuczWTfeCGx_rcZ_KxVb34ISks5rVzgQgaJpZM4Lsx7k
.


English support

Hi
Your package is AWESOME. The best WYSIWYG for React BUT sadly is not in english.
English is the universal language (I'm a spanish native speaker). So. Can you translate this package in English? I don't understand the instructions for images (for example).
Thank you

Sure, I am just adding this feature, there is a new branch 'multiple-languages' for it and it should be completed in 3 or 5 days. Thank you for your feedback.
Good luck


Core: Implement TagHelper discovery

When restructuring the way Razor's parsing pipeline works we did not port the TagHelper discovery mechanisms in the same way as we did in the past. We need to implement this ontop of our various pass extensibility pieces.

26a1cf3cff57cc57694c70ef01e9dfce036ff23e
6c8ef157b4487cb50f7e3b4021a6b0192d9ed37d


[chore] bump nix dependency and remove deprecated functions.

https://github.com/waycrate/wayshot/commit/fc90d64289eaaeb85820198b402c1ce4d6d3015e