Pause functionality - date object doesn't update / confusion what the intent of pausing does

I think the naming of 'Pause' and 'Resume' are not accurate with the current functionality of the plugin.
In the bootstrap example, when you pause the interface "pauses" but since the date object doesn't get updated on "resume" the countdown isn't technically pausing so to speak.
If that doesn't make sense I'll explain further, maybe it's fulfilling what it is intended but some clarification on what the pause event does and doesn't do would be good. I couldn't find anything.
I'm using this in an Angular app and I'm currently working to update the date depending on time difference since it was paused but it feels too much like a hack of what is a simple and great plugin. :)

Duplicated from #116 and #131. The count won't stop because it is physically impossible to stop time itself!!!
There is a lot of explanation why it was implemented this way at the linked issues that you can read. But here is a little snippet to achieve the desired functionality:
var startDate = new Date(2015, 12, 24),
    pauseDate;

var $clock = $('#clock').countdown(startDate);

$('#btn-pause').click(function() {
    pauseDate = new Date();
});

$('#btn-resume').click(function() {
    var timedelta = new Date().getTime() - pauseDate.getTime(); // Elapsed time since the pause
    startDate = new Date(startDate.getTime() + timedelta);
    $clock.countdown(startDate);
});


Improve package publish logic

include release* branches
read version from branch name if starts with release
change output from artifacts to publish (artifacts will be used by NET 8 for binaries)

As i used release1.5.1 (an imaginary version) as my branch name, you can see that the build on my fork determined this to be publish build and forced all version information from the branch name, output from ubuntu-latest run:
06:13:26 [INF] BUILD SETUP
06:13:26 [INF] 	Solution: /home/runner/work/npoi/npoi/solution/NPOI.Core.Test.sln
06:13:26 [INF] 	Configuration: Release
06:13:26 [INF] 	Version suffix:
06:13:26 [INF] 	Publish version: 1.5.1
06:13:26 [INF] Build environment:
06:13:26 [INF] 	Host: Nuke.Common.CI.GitHubActions.GitHubActions

The summary has the Artifacts at the bottom https://github.com/lahma/npoi/actions/runs/5983250670 which opens a zip file containing a NuGet package versioned as 1.5.1 and passes all NuGet checks:

So with these changes you should be able to get NuGet release branch from any release branch automatically as long as branch name starts with release.

LGTM

The CI works great! It's really a life saver. Thank you!
I'm impressed that it can even automatically update dependency packages for the nuget package.

So nice to hear! When it's scripted and automated, it's usually reproducible and and has expect results (release build, exactly known sources etc).


HTYI: player icon links broken

Have been playing all afternoon then all of a sudden I started a few new games and none of the icons were appearing.

This seems to happen if the game gets refreshed and a new game is started with an old lobby code.

please reproduce and provide steps! order of logging in etc would be extremely useful, also taking note of who is being reloaded first (group vs. player)

"This seems to happen if the game gets refreshed and a new game is started with an old lobby code."
Same on group screen refresh. Will check this a few times once Johnny confirms.


It starts, but while loading data, it stops with: «SyntaxError: Unexpected token n in JSON at position 15689»

s|terminal-slack master % node main.js
Error: SLACK_TOKEN undefined. Please add SLACK_TOKEN to the environment variables.
s|terminal-slack master % vim ~/work/notes/slack-token
s|terminal-slack master % SLACK_TOKEN="$(cat ~/work/notes/slack-token)" node main.js
SyntaxError: Unexpected token n in JSON at position 15689
    at JSON.parse (<anonymous>)
    at Request._callback (/home/s/terminal-slack/slackClient.js:31:29)
    at Request.self.callback (/home/s/terminal-slack/node_modules/request/request.js:186:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:191:7)
    at Request.<anonymous> (/home/s/terminal-slack/node_modules/request/request.js:1081:10)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)
    at IncomingMessage.<anonymous> (/home/s/terminal-slack/node_modules/request/request.js:1001:12)
    at Object.onceWrapper (events.js:290:19)
s|terminal-slack master % g pl
Current branch master is up to date.
s|terminal-slack master % date
Thu Jan 26 18:02:31 EET 2017

Hi @siers, I followed your repro steps here and didn't end up with any errors. If this is still unsolved, is there a way you could log the error, response, and data variables from line 20 of slackClient.js (remove any personal information first if needed)? You should be able to write them to a file as done in line 22. This might help in debugging the issue. Thanks!


Page Header Tags issue when no HTML element is used

Description of Problem
I recently had one page on a site that had a strange extra distance somewhere in the page. (fixed header offset actually). After a long search I found that the admin had added tags to the "Page Header Tags".
But only text noting else, apparently he misunderstood the term "tags".
This meant that plain text was injected in the head, which lead to the rendering issue.
Proposed Solution Option 1
I suggest to add a regex validator to the input filed to make sure anything inserted is valid.?
Proposed Solution Option 2 (If Needed, repeat for more)
Strip out all content that's not inside an html element on render?
Alternatives Researched
Documentation of any other items researched for resolution.
Affected version

[ ] 10.0.0 nightly build
[x] 9.4.1 nightly build
[x] 9.4.0 latest supported release

...

To prevent stalebot to keep closing this since nobody picked up this feature-request yet, I am moving this to the feature-request discussions.
Thanks.


Style graphics with symbols

Resolved the comments you added @kmueller-gis!

@PaulAllanSturm comments resolved !

@PaulAllanSturm please check


Remove or None from documentation

Summary
Remove or None from documentation. Fixes wrong linking in documentation
Checklist

[x] I have run nox and all the pipelines have passed.
[x] I have made unittests according to the code I have added/modified/deleted.

Related issues
None

Codecov Report

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

@@           Coverage Diff           @@
##           master      #21   +/-   ##
=======================================
  Coverage   79.51%   79.51%
=======================================
  Files          78       78
  Lines        9610     9610
  Branches     1231     1231
=======================================
  Hits         7641     7641
  Misses       1914     1914
  Partials       55       55

Impacted Files
Coverage Δ

hikari/api/cache.py
100.00% <ø> (ø)

hikari/api/event_dispatcher.py
100.00% <ø> (ø)

hikari/api/rest.py
100.00% <ø> (ø)

hikari/api/shard.py
100.00% <ø> (ø)

hikari/config.py
100.00% <ø> (ø)

hikari/events/base_events.py
100.00% <ø> (ø)

hikari/events/channel_events.py
100.00% <ø> (ø)

hikari/events/guild_events.py
100.00% <ø> (ø)

hikari/impl/bot.py
33.55% <ø> (ø)

hikari/impl/buckets.py
100.00% <ø> (ø)

... and 15 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 3854b4f...0c253c4. Read the comment docs.


Consistently use bazel test and --test_output=all on CI

What do these changes do?
This PR changes CI to consistently use bazel test --test_output=all. This will hopefully make sure that asserts are enabled during all of our tests.
How Has This Been Tested?
CI

This should have the very nice side benefit of speeding up the end2end test, because previously it was build with opt and so couldn't re-use the compilation of the MLIR filecheck, which was fastbuild.

That makes sense, I was wondering why it now has to rebuilt and is not streamed from the cache :+1:

@AdamHillier do you have an idea why the ARM tests timeout now?

@AdamHillier do you have an idea why the ARM tests timeout now?

Good question, I'm not sure. Previously they took a bit longer than this run did: https://github.com/larq/compute-engine/runs/567324056.

:+1: I'll increase the timeout if it fails after this run as well.

In the int8 PR the ARM tests are 'fixed' because the qemu tests only run a small subset of parameters (this should probably be split into a separate PR from the int8 PR), so i think we can simply increase the timeout for now and fix it later.

I wonder if bazel allows more time for "medium" tests when running -c opt or something like that.

I think it is because we used bazel run before, it probably doesn't check the timeout.


Error in DISM Command

Line 17312 of 6.4.9 is missing quotation marks around the /CaptureDir path:
$DismArgs = "/Capture-Image /ImageFile:"$(Join-Path -Path $WimTempLocation -ChildPath DriverPackage.wim)" /CaptureDir:$WimTempLocation /Name:"$WimDescription" /Description:"$WimDescription" /Compress:max"
Line 17324 indicates that the log is in the extract directory, when it is actually in the temp directory:
global:Write-LogEntry -Value "Error: Failed to locate DriverPackage.wim. Please review the DISM log file located in $DriverExtractDest" -Severity 1

PS. It would be great if the expanded drivers in the WimDriverFiles folder were deleted immediately after the WIM has been created. If there are a lot of updates, the gigs of data can rack up fast.

Issue already resolved within the latest available exe.


improve : can use any directory to import file

usecase: shared git directory

maybe we can do the same thing to #openImportButton

Add method filesDirectory
usecase : override method to change directory  when use #openImportButton


reducing link width in closed ToC so the full border shows

The width of the ToC items was obscuring some of the border when the ToC was in the "closed" position.

to

@cmc333333 not sure how much of a refactoring rabbit hole we want to go down right now but I defined a variable for the width of the parent container and did the minus - 1 thing for the piece inside. Ultimately though there are a lot of absolutely positioned elements with semi-arbitrary widths and positions that make up the nav that could use some cleaning up in the long term.

@donjo gratzie . Every little bit helps!


Can't use editor according to the demo

desc
I saw this editor from antd docs, so I  npm install react-lz-editor --save and tried in my project, but this did not work.
It seemed I haven't pass the props right, but whatever I tried, it always showing the same error.
my project ejected from 'create-react-app'
os: win7
error

code
import React, {Component} from 'react'
import {LzEditor} from 'react-lz-editor'

export default class Article extends Component {
    constructor(props) {
        super(props)
    }
    render() {
        return (
            <LzEditor />
        )
    }
}

dependencies
"react": "^16.0.0",
"react-dom": "^16.0.0",
"react-lz-editor": "^0.11.6",
"antd": "^2.13.10",

Sorry about this bug, I have fixed it and will publish to npm. PropTypes is no longer supported and has been removed, this is why the bug appears. Pls refs: https://reactjs.org/warnings/dont-call-proptypes.html

Hi @MikeMiller3 , I have released a new version 0.11.7 on npm, could you please upgrade and try it again? Thank you!

@leejaen It works , thank you !


Fix for #6805 that got caused by renaming a file in the hawkular gem.

Fix for issue #6805

@miq-bot add_label providers/containers, metrics


test limit count: It is unstable and sometimes fails

fixed by https://github.com/iresty/apisix/pull/154


Latest Configuration Changes - New version release?

The latest tagged version of the cookbook does not contain the performance parameters (for raft multiplier etc) which are needed for production. Any idea when the new version will be committed?

Similarly, there are missing configuration options for things like dogstatsd_* and retry_join_ec2 in ConsulConfig. I realize it's difficult to keep this list updated with the available options upstream so I was wondering if there should be an extra_config parameter. This would just be a free-form hash that gets turned into the configuration JSON without any validation.

We will be releasing 2.3 in the next few days. PR are welcome for config options that are missing!

After reading the Consul documentation some more I found a quick way around this so I'll leave it here in hopes that it helps someone else.
From the Consul docs:

When loading configuration, Consul loads the configuration from files and directories in lexical order. For example, configuration file basic_config.json will be processed before extra_config.json. Configuration specified later will be merged into configuration specified earlier. In most cases, "merge" means that the later version will override the earlier.

So in my wrapper cookbook I just defined some extra attributes:
default['consul']['extra_config']['retry_join_ec2']['region'] = 'us-west-2'
default['consul']['extra_config']['retry_join_ec2']['tag_key'] = 'opsworks:instance'
default['consul']['extra_config']['retry_join_ec2']['tag_value'] = 'consul-*'

And then tossed this into the wrapper cookbook's default recipe:
file "#{node['consul']['service']['config_dir']}/extra_config.json" do
  content JSON.pretty_generate(node['consul']['extra_config'], quirks_mode: true)
  mode '0640'
  owner node['consul']['config']['owner']
  group node['consul']['config']['group']
  notifies :reload, "consul_service[#{node['consul']['service_name']}]", :delayed
end

Works like a charm! Thanks again!


How can i add an addOn to the firstpayment

I tried using a preprocessor but they do not seem to trigger on firstpayment, is there an easy solution without customizing too much of cashier?

Hi,
That's correct, firing the preprocessor on the first payment is still on the roadmap.
You could try using the FirstPaymentBuilder manually. Take a look here for some examples on how this works.
Closing this for now, let me know if it should be reopened.

That's correct, firing the preprocessor on the first payment is still on the roadmap.

@sandervanhooft Will that be possible in v2?


RFC: ensure-style options in NixOS modules

Context & motivation
In NixOS, a desirable property is that the current state of the system configuration is a pure function of the Nix expression evaluated.
For example, NGINX virtual hosts are directly a pure function of the Nix expressions describing them.
Another example would be that, under users.mutableUsers = false;, UNIX users are directly a pure a function of the Nix expressions describing them, including their attributes. (please correct me if this is wrong.)
A non-example of this is services.postgresql.ensureUsers, it is possible to manually remove a PostgreSQL user and perform multiple rebuild switch without reviving the user in question, therefore, creating a drift between NixOS expression and the actual PostgreSQL configuration.
Same thing for hardware.ensurePrinters too (which attempt to reconcile the expression with the reality, without removing any printer though.)
This can be generalized into all kind of options that "prefill" data or state which could also be seen as "static configuration state" (e.g. what are my users, what are their permissions, etc.) but could also have been dynamic.
Recently, there have been some activity to extend ensure-style options to existing NixOS modules for the sake of usability and, that under "nice assumptions" (no manual removal, not too much buggy software, etc.), they would even respect the "purity" predicate given above (i.e. the configuration state is a pure function of NixOS expression), see:

#200724
#203474
#164235
https://github.com/NixOS/nixpkgs/pull/206729

Arguments against the proliferation of these options
In #164235, @aanderse argued against these kinds of options because they break many assumptions people tend to have on a NixOS system and recommended using a tooling which would actually try to reconcile the state, e.g. Terraform (or NixOps I would say).
Open questions
Personally, I would argue that there are some practical advantages to limit the amount of tooling used to deploy a system and Terraform/NixOS integration is not necessarily optimal, therefore, I think this matter should be more discussed.
(1) Who is using NixOS with strong assumptions based on the fact they can derive more or less static configuration state based on NixOS expression? Is there any term to describe this property we can start using in the community and document it?
(2) Should we introduce a tainting mechanism whenever a property-breaking option is being used so that this group of users can isolate these systems? Should we do nothing and just try actively to remove these mechanisms? What is a good story for these competing needs?
(3) What is an acceptable way to perform these "reconciliation" operations à la Kubernetes/Terraform/Ansible in NixOS? Should we start work on a framework to contribute those to nixpkgs?
Another connected problem which is related but not directly is the "automatic migration" mechanism that tend to be present for NixOS module for simplicity, but creates real issues when in combination with rollback feature, e.g. upgrading Gitea, Gitea is broken, then rollbacking and Gitea revision N - 1 is not forward compatible with the new DB schema, therefore, Gitea is broken on previous revision too. I do think answering questions here would provide some insights regarding this problem too.

Maybe this is best submitted to the https://github.com/NixOS/rfcs repository?

Maybe this is best submitted to the https://github.com/NixOS/rfcs repository?

I do not plan to write an RFC right now on the subject, it's an RFC as in "request for comments" from the whole community, if it turns out, we actually want to write a proper RFC, we can do it later. :)

You can write a silly, uninformed, non-community-consensus driven RFC all you want. I have done so three times :)

ensure smacks of convergent configuration management. NixOS is special because it describes what is.

ensure smacks of convergent configuration management. NixOS is special because it describes what is.

I agree that on the user-facing side of NixOS we should try to avoid convergent options where possible.
mutableUsers shows that we can make convergent logic behave declaratively. I don't know how we got there, but I suspect that a lot of trial, error and contributions were involved. It would be great for NixOS to offer both a conceptual and technical framework to support the mixing of declaratively managed data and live data.

I personally find myself wanting that extra small bit from the NixOS modules especially around managing the state (ansible and terraform feel way to heavy of a dependency especially since I already have NixOS). I get that trying to declaratively manage something that stores state is not perfect but as others have mentioned it is already done throughout nix.
As a developer I often need to link authentication store + database + message queue + web server  and NixOS is SO close to being able to manage this fully declaratively. The idea it is not perfect is something that the people using these tools will need can be aware of.

Whether we want it or not, having some sort of state is inevitable. We still want to push as much of the configuration to be congruent in the /nix/store, but it would be nice if we had tighter control over that state.
On my machine, /run/current-system/activate is 479 lines of bash, pushing state around on the machine. Most of the data in /var is loosely managed. It would be nice to have some declarative tool that does something close to terraform, but only for local resources.

Similar to the allowUnfree setting there could be something like allowScriptedState to opt-in or out of this behaviour.
This could be a good central place to make users aware & understand the risks of using ensure-style & similar options, especially if we decide to make this setting opt-in in the future.

A non-example of this is services.postgresql.ensureUsers, it is possible to manually remove a PostgreSQL user and perform multiple rebuild switch without reviving the user in question, therefore, creating a drift between NixOS expression and the actual PostgreSQL configuration.

Wow, that's horribly broken. We cannot base the decision on whether we should (not) have ensure* options in NixOS based on that broken behaviour. I'd expect ensure* to reproducibly configure their little state area upon nixos-rebuild, while merging/allowing other state changes on the side. Like users.mutableUsers = true.
What's the alternative if we don't have ensure* options? Configure that state manually? :scream: (I came here because I was looking for a way to configure minio buckets declaratively -- I won't use it if I have to do manual configuration.)

What's the alternative if we don't have ensure* options? Configure that state manually? :scream:

Putting in the effort and making the module implementations more stateful, just like mutableUsers.
Nix isn't magic. Stateless or declarative doesn't mean no state. What Nix does is it reduces the deployed software variables (from traditional package management entropy) into a single variable: a profile. It does not magically reduce the other variables; that would be called "catastrophic data loss".
 And that's ok. This is OSS, and something is better than nothing, but damn. We take away control over individual services by making the whole system software into a single variable, but then we don't help out with the actual setup and migrations? How's that supposed to be any better?
Now it's not all bad. We do have a good example: mutableUsers, and we could probably come up with some guidelines for how to deal with actually interesting state. And we have this amazing tool called the NixOS test framework.

I totally agree with @roberth and I would go further: in my personal opinion, this is an open area of research to get the things right and Nix is uniquely positioned to experiment something new, in regard to this (like designing ways to compose small primitives to converge such state).
Of course, it's a matter of time and a strike balancing between "this option is hard, requires extra carefulness and scrutiny and tests" and "this option is easy and can be added in a harmless way" and that's why I am a bit picky in which to accept and not because also the data loss is really annoying.

ensure smacks of convergent configuration management. NixOS is special because it describes what is.

It does and it is. 2 points:

I'd still rather have a principled form of convergent configuration, than just a bunch of scripts. But I agree that at NixOS we don't do "good enough", we do "necessarily radical, otherwise pragmatic".
Do you think there is a fighting chance to ever make upgrading state as atomic and robust as nixos-rebuild switch/boot, @grahamc?
The main problem I'm seeing is: The content of my database will never be declarative, unless I allow my users to declare stuff. Even with the best system, I'll have to restore a backup of my actual data, instead of just unfolding the latest descriptor into a new instance. Otherwise, it would mean 1 database transaction == 1 backup snapshot ... I mean that would be like trying to rewrite the RPATHs of every single binary and expecting the result to work :smiling_imp:

Thinking about it, not even switch/boot is fully atomic, thus not fully declarative: What if something goes wrong after setting /nix/var/nix/profiles and before/during writing the bootloader? What about buggy state transitions in switch?
Maybe it's time to include the update process in the "what is", that @grahamc mentioned?
What about if we approach the problem as a generalization of the bootloader problem, and have nixos-rebuild declare a sort of "letter of intent" of pending stateful actions, each one monitored to hell and back as well as preferrably undoable?
One huge benefit would be that this would allow to check for more errors that wouldn't show up during eval, before actually eating them at runtime, see https://matrix.to/#/!aGqRytqbCECitOFhbt:nixos.org/$-Luxmact8b2jLtsAnJxBIZM9FDi2C7Gmx0ypVPLnF2E?via=matrix.org&via=lpc.events

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/breaking-changes-announcement-for-unstable/17574/39

In my experience at work, state management is hard. That Nix has a hard time dealing with it does not mean in the slightest that Nix os not good. With that out of the way, here are a few interesting state migration examples and principles I read about and rediscovered at work:

To automatically migrate (and downgrade) a database, you need an up (and down) script that transitions the database to the new (or to the old) script. Taking Gitea example above, it seems they don’t provide a down script. If they don’t, there’s nothing we at Nix can do there. Also, applying a script can take a while and render your system useless while the migration happens, if not done correctly.
You can backup before each migration. This could help with the down script missing. But it’s sometimes not doable. Restoring the db could be a very costly operation that requires a lot of downtime. It shouldn’t, but if you’re talking about Tbs of data, then everything takes time. Also you lose any changes done by users when you restore backups.
We rarely update software and database state at the same time. Let’s take a concrete example which updates a database column type. We usually do it like so:

Add a new column with the new type with NULL data in it.
Update software to use new column and fallback to previous column if the value is NULL.
Run a background script copying data from the old column to the new one, transforming the data as required.
Make sure everything runs fine with the new column with a canary, smoke tests, etc.
Update code to only use new column.
Drop column from table.
Each step should be tested extensively too. Each step becomes more complicated if you have multiple nodes in your cluster, sharding, AZ replication, a lot of data.

I’m sure I’m forgetting a lot here as I’m writing from memory. But I want to convey that IME database updates are rarely free and snappy and easy. Im not sure how all these steps can happen in one deploy command. Nor how Nix can solve this problem space.
The main issue IMO is Nix automatically produces a diff of old state to new state which works great to deploy new stateless binaries. But to deploy stateful stuff, we should be able to let the user override the internal automatic diffing and describe how the migration should happen, in multiple discrete steps.
Also, it doesn’t help that when you update to a new nixpkgs commit, you update everything at once. It would be nice to be able to update to a new nixpkgs commit but be able to apply changes with other strategies than « all at once », like one binary at a time.

Related: https://github.com/NixOS/rfcs/pull/155

In my experience at work, state management is hard. That Nix has a hard time dealing with it does not mean in the slightest that Nix is not good. With that out of the way, here are a few interesting state migration examples and principles I read about and rediscovered at work:

Thank you for your lengthy feedback, I mostly agree with you (except in some points where I don't see a compelling case where I can agree).

To automatically migrate (and downgrade) a database, you need an up (and down) script that transitions the database to the new (or to the old) script. Taking Gitea example above, it seems they don’t provide a down script. If they don’t, there’s nothing we at Nix can do there. Also, applying a script can take a while and render your system useless while the migration happens, if not done correctly.

Yep, it's a classical problem and why we should probably invest in standardizing automaticMigrations knobs for each NixOS module which enable manual migrations, of course, some of them doesn't, which let us move to the next point you wrote.

You can backup before each migration. This could help with the down script missing. But it’s sometimes not doable. Restoring the db could be a very costly operation that requires a lot of downtime. It shouldn’t, but if you’re talking about Tbs of data, then everything takes time. Also you lose any changes done by users when you restore backups.

That is true, but this is a self-inflicted limitation. You don't need to pay the backup cost (though you should always pay it for disaster recovery recipes anyway, right?), you can simply reuse your filesystem or rely on application-specific backup/snapshots technologies.
It's not always clear to a user, but there's a treasure trove of technologies we are usually sitting and not using, massaging filesystem snapshots to make use of them in this context is a trivial example of that. (and yes you can make the database cooperate with flushing the pages, etc. It requires work, it's not hard.)
The delta lost is unfortunate but also inevitable, what would you even expose your application to your users if you didn't finish validating the deployment? And if you do so because there is a weird bug in the application, we are in the set of cases where it will be almost impossible to automate any meaningful answer to this problem and requires manual work every time, so I would say that losing a delta of your state by roll backing a half-broken application is out of scope.
We can tolerate broken applications, but it is very complicated if not impossible to tolerate half broken applications. Failure mode is part of engineering, and failing hard is important. Failure to do so, well… will create disasters.
Disaster require disaster recovery plans and no automation can save us of that, we can just make it easier at most.

We rarely update software and database state at the same time. Let’s take a concrete example which updates a database column type. We usually do it like so:

Add a new column with the new type with NULL data in it.
Update software to use new column and fallback to previous column if the value is NULL.
Run a background script copying data from the old column to the new one, transforming the data as required.
Make sure everything runs fine with the new column with a canary, smoke tests, etc.
Update code to only use new column.
Drop column from table.
Each step should be tested extensively too. Each step becomes more complicated if you have multiple nodes in your cluster, sharding, AZ replication, a lot of data.

I’m sure I’m forgetting a lot here as I’m writing from memory. But I want to convey that IME database updates are rarely free and snappy and easy. Im not sure how all these steps can happen in one deploy command. Nor how Nix can solve this problem space.

I respectfully disagree on "rarely free, snappy and easy", in my experience, they are almost always free, snappy and easy, they rarely fail!
The problem is that when they fail, it's rarely actionable because people are not used to it failing. People are not aware of everything that can go wrong. That's understandable, it mostly goes right.
Solving a problem space makes little sense to me. The Nix expression language trivially decreases (as demonstrated by now) the difficulty to intertwine complex application dependencies at the meta-level in a reusable fashion, via the NixOS module system (so called an expert system sometimes).
The Nix expression language can also trivially decrease the difficulty to tame the state convergence situation by providing abstractions to describe state convergence at the NixOS module level and let it be an emergent (complex) system.
Of course, this is not for the faint of the hearts and will probably never be useful for A/Z replication sharding blablabla use cases for now, as we don't even have "remote systemd" (which is key to enable Kubernetes-style use cases natively with Nix), but I bet this can tremendously help for the rare cases where it fails, because those cases are usually simple and easy.
Even backupping automatically before performing a state transition would be largely welcome by many of us because we have the backup storage, and we just don't have the opportunity to enable such measures.

The main issue IMO is Nix automatically produces a diff of old state to new state which works great to deploy new stateless binaries. But to deploy stateful stuff, we should be able to let the user override the internal automatic diffing and describe how the migration should happen, in multiple discrete steps.

Nix is able to diff closures (of .drvs or realized store paths). Not state. It is us who decide to give meaning to a diff of closures.
For what is worth, we can totally introduce more steps to the switch-to-configuration.pl logic to let them override the automatic diffing and perform policy based deployments, I will mention this again https://github.com/NixOS/nixops/pull/1245.
There is a tension between NixOS being a normal operating system and NixOS embracing completely operation-style logic and offer them by default with empty policy, which makes it trivial for people like us to use them for implementing our own policies on the top of that.
More advanced convergence engines could be built on the top of the existing things, there's no reason to use the NixOS default provided one, there's no reason to have a unique implementation. What we need to do though is to be able to capture the expressivity we need to understand what does it mean to perform state convergence and express database migrations or anything as simply an act of state convergence.

Also, it doesn’t help that when you update to a new nixpkgs commit, you update everything at once. It would be nice to be able to update to a new nixpkgs commit but be able to apply changes with other strategies than « all at once », like one binary at a time.

I don't think "one binary at a time" will ever make sense for NixOS, partial updates are physically impossible for a good reason. What you are looking for though is a way to keep old systemd units running with their old paths and swap them with their new version, one at a time.
But you need to bring your own rollback policy in case of failures to roll out.

Another tangential comment, which is in no way a criticism, is we should invest more in our observability tooling. Most of the big open source projects I host do not provide a good story there. We should embrace extensive tracing and metrics on top structured logging. This would help tremendously IMO.

I am not sure that I understand how is it related to the matter, though. This is the problem of the software you are running and should be tracked somewhere else (even in the issue tracker of the software you are using!).
OTEL and whatnot are things that are available in nixpkgs in the reasonable limits, we are not really the place to hold upstreams accountable on this. :)

Thanks for answering and opening my eyes, see below. Btw, I didn’t copy here what I agree with.

That is true, but this is a self-inflicted limitation. You don't need to pay the backup cost (though you should always pay it for disaster recovery recipes anyway, right?), you can simply reuse your filesystem or rely on application-specific backup/snapshots technologies.

Not disagreeing but just wanted to clarify the cost I was thinking about at the time of writing was the time it takes to make a backup which can be long. This renders deployment cumbersome to make if they happen before deploying.

It's not always clear to a user, but there's a treasure trove of technologies we are usually sitting and not using, massaging filesystem snapshots to make use of them in this context is a trivial example of that. (and yes you can make the database cooperate with flushing the pages, etc. It requires work, it's not hard.)

I never really considered using the file system for this. You referring to snapshots like can be seen in ZFS or LVM, right? I’ve been reading about that now and I imagine we could just create a snapshot everytime we deploy. Which is a very quick operation. This makes me want to redo my whole backup strategy 😁 I wonder if we even could have a dataset (in ZFS terminology) per application we deploy which could even allow pretty seamless relocation of the app.

The delta lost is unfortunate but also inevitable, what would you even expose your application to your users if you didn't finish validating the deployment? And if you do so because there is a weird bug in the application, we are in the set of cases where it will be almost impossible to automate any meaningful answer to this problem and requires manual work every time, so I would say that losing a delta of your state by roll backing a half-broken application is out of scope.

Makes sense.

I respectfully disagree on "rarely free, snappy and easy", in my experience, they are almost always free, snappy and easy, they rarely fail!
The problem is that when they fail, it's rarely actionable because people are not used to it failing. People are not aware of everything that can go wrong. That's understandable, it mostly goes right.

I’m really curious how you do the kind of deploy I mentioned. Like you said, the issue is when they fail. That’s the reason we split each step in its separate deploy. The biggest reason is if something goes wrong, we know without doubt what step failed. Second, reasoning about failure modes is easier if the deploy step is constrained.

Nix is able to diff closures (of .drvs or realized store paths). Not state. It is us who decide to give meaning to a diff of closures.
For what is worth, we can totally introduce more steps to the switch-to-configuration.pl logic to let them override the automatic diffing and perform policy based deployments, I will mention this again NixOS/nixops#1245.

Ah yes. I meant the same. We can do whatever we want but it’s not there yet. I badly expressed myself, I didn’t mean the current behavior is set in stone.

I don't think "one binary at a time" will ever make sense for NixOS, partial updates are physically impossible for a good reason. What you are looking for though is a way to keep old systemd units running with their old paths and swap them with their new version, one at a time.
But you need to bring your own rollback policy in case of failures to roll out.

I mostly agree. I could imagine deploying updates to Nextcloud and Home Assistant independently because they don’t relate to each other.
At first, I tried to deploy my server using disnix which does what you describe pretty well. It has some shortcomings I couldn’t push through so I switched to a more classic deploy system. But I really liked disnix.

OTEL and whatnot are things that are available in nixpkgs in the reasonable limits, we are not really the place to hold upstreams accountable on this. :)

Yes I’m not sure how my last rant related to the issue at hand. I think I was thinking having proper monitoring helps to know if the new deploy behaves correctly and inform if we need to rollback or not.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/what-about-state-management/37082/1


Remove the HelpInfoUri

It's better not to set it, then to set it to a URI that can't ever work for updates

Thanks @Jaykul!  Yes, and thanks for the pr!


cannot listen on ipv6 address

Hi,
not really expecting much, but since there were no other issues about it I'll open one for others looking at the error.
Trying to listen to an ipv6 address fails with Address family not supported, because down the stack python's wsgi/http.server defaults to AF_INET.
This isn't configurable at tor eporter's level if you with to use prometheus' web server though, but they've had multiple issues for a while ( prometheus/client_python#69 from 2015! closed without fixes, and more recently prometheus/client_python#567 with more details but not much progress, prometheus/client_python#132 with a workaround in the prometheus client code...) - they seem to advise not using their web server for real applications? :|
Their wsgi actually does quite some work so I wouldn't necessarily recommend moving away from it at this point, just raising awareness...

fixed upstream just now.


Add notes about :decimal and calendar types

Since we enforce the type, this fails because the default timestamp is :naive_datetime, so without microseconds.
iex(1)> Friends.Repo.insert(%Friends.Person{inserted_at: NaiveDateTime.utc_now()})
** (Ecto.ChangeError) value `~N[2018-09-18 10:10:51.596624]` for `Friends.Person.inserted_at` in `insert` does not match type :naive_datetime
    (ecto) lib/ecto/repo/schema.ex:831: Ecto.Repo.Schema.dump_field!/6
    (ecto) lib/ecto/repo/schema.ex:840: anonymous fn/6 in Ecto.Repo.Schema.dump_fields!/5
    (stdlib) maps.erl:257: :maps.fold_1/3
    (ecto) lib/ecto/repo/schema.ex:838: Ecto.Repo.Schema.dump_fields!/5
    (ecto) lib/ecto/repo/schema.ex:780: Ecto.Repo.Schema.dump_changes!/6
    (ecto) lib/ecto/repo/schema.ex:219: anonymous fn/15 in Ecto.Repo.Schema.do_insert/3

I think ideally the error would provide more information. Should I investigate?
Mentioned to me by @AndrewDryga. WDYT about these docs update, Andrew?

@wojtekmach i did a pass for formatting and clarity, let me know what you think!

@josevalim :shipit:

@wojtekmach I think we should additionally mention that when you insert a struct or update with changes that are not casted, you need to take care of precision manually.
Your code example is a good one, and here is the one we discussed:
channel
|> Ecto.Changeset.change(%{
  verification_token_hash: nil,
  verification_token: nil,
  verification_token_sent_at: nil,
  verified_at: DateTime.utc_now()
})
|> Repo.update!()

Having better error would ease migration for noobs like me :).

:heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:


Add support for dark/light mode snapshots on catalog page

Desired State of the Meshery.io site

On https://meshery.io/catalog, we'll have dark and light versions of snapshots available and so the snapshots being shown should be compatible with current theme of the site.

Contributor Guides and Handbook
The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

📚 See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
🎨 Wireframes and designs for Meshery UI in Figma (open invite)
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@vishalvivekm Can you explain what do you want here?

Hey I would like to work on this


asynchronous tests

https://github.com/scala/scala-dev/issues/641#issuecomment-510857453

If you want this to help Scala.js, an absolute requirement is support for asynchronous tests, i.e., tests returning a Future that will decide whether or not they succeeded.
Also it will be necessary that test classes extend a given class or trait. Annotations won't cut it.

Minitest supports this already:
import scala.concurrent.ExecutionContext.Implicits.global

object MySimpleSuite extends SimpleTestSuite {
  testAsync("asynchronous execution") {
    val future = Future(100).map(_+1)

    for (result <- future) yield {
      assertEquals(result, 101)
    }
  }
}

and so does uTest https://github.com/lihaoyi/utest#asynchronous-tests
val tests = Tests {
  test("testSuccess"){
    Future {
      assert(true)
    }
  }
  test("testFail"){
    Future {
      assert(false)
    }
  }
  test("normalSuccess"){
    assert(true)
  }
  test("normalFail"){
    assert(false)
  }
}

TestRunner.runAsync(tests).map { results =>
 val leafResults = results.leaves.toSeq
 assert(leafResults(0).value.isSuccess) // root
 assert(leafResults(1).value.isSuccess) // testSuccess
 assert(leafResults(2).value.isFailure) // testFail
 assert(leafResults(3).value.isSuccess) // normalSuccess
}

When running the test suites from SBT, you do not need worry about any of this run vs runAsync stuff: the test runner will handle it for you and provide the correct results.

Resolved by Minitest.


seeed-xiao-rp2040: Add initial board support

Summary
Initial board support for Seeed Studio Xiao RP2040
Impact
User will be able to use Nuttx on Seeed Studio Xiao RP2040
Testing
Currently only nsh defconfig is supported:

make distclean
./tools/configure.sh -l seeed-xiao-rp2040:nsh
make
Boot board in  "BOOT mode"and copy nuttx.uf2 into the device.
Reset the board and connect to UART0
User should be able to see NSH

@xiaoxiang781216 any idea what is the error?

@xiaoxiang781216 it seems like our CI is broken again!

Fixed here: https://github.com/apache/nuttx/pull/11282

please rebase to the last master which fix the recent ci break


Added onViewChanged to React Auth UI so that view can be externally synchronized

What kind of change does this PR introduce?
This introduces a feature where you can pass a callback onViewChanged to the Auth component for React. This callback gets executed, whenever the view of the Auth UI changes so that you can externally synchronize with it.
My specific use-case of it was that I wanted to synchronize the redirectUrl with whatever view a user selected. For example on sign up I want to redirect to [main app URL]/onboarding while on the forgotten password page I want to redirect to [main app URL]/reset-password.
This could also potentially help with #236 and #223
Also remember that the redirectUrl needs to match the redirect URL settings on Supabase.
What is the current behavior?
When a view is selected, that state is isolated to the Auth UI component. You can pass the initial view, but cannot listen to changes.
What is the new behavior?
See feature description above; onViewChanged gets called by Auth UI component whenever the view changes.
Additional context
Example of how I use this new feature:
  const [view, setView] = useState<ViewType>("sign_in");
  const [redirectTo, setRedirectTo] = useState<string | undefined>();

  useEffect(() => {
    const currentUrl = new URL(window.location.href);
    switch (view) {
      case "sign_in":
      case "sign_up":
        setRedirectTo(currentUrl.origin + "/onboarding");
        break;
      case "forgotten_password":
        setRedirectTo(currentUrl.origin + "/reset-password");
        break;
      default:
        setRedirectTo(undefined);
        break;
    }
  }, [view]);

          <Auth
            supabaseClient={supabase}
            view={view}
            onViewChange={(view) => {
              setView(view);
            }}
            redirectTo={redirectTo}
          />

Nice change - how can we get it merged?

when can this be merged?

@dbuhon are you able to merge this or know who can?


generate a Junit xml report and try to upload it during CI runs

@mattip it almost works, but there is this error:
there's some permission problem that I don't understand, here are some hints: https://github.com/marketplace/actions/junit-report-action#pr-run-permissions
in case you have time to look into this a bit. but if not, that's ok too.

If you look at the workflow, you can see the permissions are read-only. Maybe github thinks this repo is a fork of somethinge else? I am not an admin, but maybe there is a setting somewhere to reset this.


feat(instagram): replace JS parsing with hardcoded query hashes

Category
This change is exactly one of the following (please change [ ] to [x]) to indicate which:

[ x] a bug fix (Fix #...)
[ ] a new Ripper
[x ] a refactoring
[ ] a style change/fix
[ ] a new feature

Description
Replaced parsing the JS with hardcoded query hashes. Had a look around and more tools seem to be working like this.
I did notice getting errors when being redirected multiple times, hence the changes to the regexes, but please review this thoroughly. There seem the be a lot of people that want this working properly but I don't really have time to check everything myself.
Testing
Required verification:

[ ] I've verified that there are no regressions in mvn test (there are no new failures or errors).
[ ] I've verified that this change works as intended.

[ ] Downloads all relevant content.
[ ] Downloads content from multiple pages (as necessary or appropriate).
[ ] Saves content at reasonable file names (e.g. page titles or content IDs) to help easily browse downloaded content.

[ ] I've verified that this change did not break existing functionality (especially in the Ripper I modified).

Optional but recommended:

[ ] I've added a unit test to cover my change.

This works however, you need to add rate limiting into it. It is detected by the source because it is running too quickly.

This fails to rip all images from https://www.instagram.com/hilaryduff/

Yea closing this, not going to work.
Cheers for testing!


Move project under sigs.k8s.io namespace

What type of PR is this?
/kind api-change
What this PR does / why we need it:
Projects from Kubernetes SIGs should live under to sigs.k8s.io go module namespace. We now apply that to cri-tools and adapt the import paths.
Which issue(s) this PR fixes:

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

Moved repository source code to `sigs.k8s.io/cri-tools` namespace.

/approve
/lgtm


Uses the CDN to retrieve the images

This PR:

Enables the CDN.
Allows to use the no_cdn param (see specs)
Updates specs.
Adds a couple of new specs to test the no_cdn param.

:es:


chore(docs): add dynamic plugins examples doc

Description
This change adds a document to hold links to examples that have been developed showing either how to use dynamic plugins or show off features that are related to or enabled by dynamic plugins.
Which issue(s) does this PR fix

Fixes RHIDP-4872?

PR acceptance criteria
Please make sure that the following steps are complete:

[ ] GitHub Actions are completed and successful
[ ] Unit Tests are updated and passing
[ ] E2E Tests are updated and passing
[x] Documentation is updated if necessary (requirement for new features)
[ ] Add a screenshot if the change is UX/UI related

How to test changes / Special notes to the reviewer
Please request changes with a link for any other examples we would like included in this document.

/lgtm
/approve

/override "Build Image"


Node security releases

Motivation for this change
See nodejs release announcement https://nodejs.org/en/blog/vulnerability/july-2017-security-releases/#node-js-specific-security-flaws
This fixes one high impact vulnerability and one low impact vulnerability
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[x] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Thanks!


Switch from AbsoluteLayout to Grid

WAITING FOR CONFIRMATION OF FIX
Fixes #20

@PavloLukianets Thanks! Looking forward to reviewing it once it's ready for review
BTW, shoot me an email if you have an interest in becoming a collaborator on this project 👍
It will be very helpful for me as I can't spend as as much time as I did it before.

This change requires polishing (Removing all AbsoluteLayout occurrences in code and docs). I am gonna work on that


Disable user selection for header logo and avatars

The (a) header logo and (b) avatars used for both the user and the bot - are currently able to be selected (e.g. click + drag). This can inadvertently trigger the drop zone interaction. In some cases, it can get locked and prevent the drop zone from resetting. Let's disable user selection on these assets.

That's valid - we'll take a look.


Invalid output with JSX: missing closing bracket

Valid input: let t = <view style={Style.make()}> ...items </view>
Invalid output: let t = <view style={Style.make()> ...items </view>;
Note the missing closing bracket after Style.make().
Tested in v 3.3.7,  @ 43efc14.
Tested as well with reason-language-server v 1.4.1, it produces the same invalid output.

This has been fixed in https://github.com/facebook/reason/pull/2292/.

Thanks @IwanKaramazow !! 🙂


add contributing.md file

I would like to add this file because it is a crucial document in open-source repositories, providing clear guidelines and instructions for anyone interested in contributing to the project. It outlines how contributors can get involved, the contribution process, and the repository's coding standards and rules. Please assign this task to me.

@Amulya-B28 It is already completed in #84


Unable to show experience {experienceId}

My team has made a flow with an anchored tooltip that we manually trigger:
onPress={() => {
   Appcues.show(id);
}}

We sporadically get the "unable to show experience {id}" error. There's no real pattern to this, some users get it when the app has been idle for a while, other users get it when they are active.
In Sentry I can see a 404 returned from your API, url:
https://api.appcues.net/v1/accounts/{accountId}/users/{userId}/experience_content/{experienceId}
Using Expo, SDK51, version 3.1.14 of @appcues/react-native.

Hi @jp1987 - thanks for the details here, it is very helpful for our api team to try and diagnose what may be occurring here. We are looking into this and will let you know what we find shortly. It does not seem like anything is incorrect about your usage.
Not required, but just to suggest alternative approaches - you can also trigger custom events and then set up flows to show when those events occur, if your account is set up for event triggering. This gives an additional layer of flexibility as you do not need to hardcode an experience ID anywhere in your product, and can change which experience is used over time as needed. This concept would give effectively the same result as the show(id) approach, but use track(event) instead with a flow configured to show on that event in Appcues studio.

Thanks, we'll change our implementation to Appcues.track, seems handy!

Appcues.track seems to have fixed this issue for us, haven't seen it since.


onInputKeyDown should use utc offset

Expected behavior
onInputKeyDown should use consider utc offset using newDateWithOffset() code
instead of
moment(point) code
Actual behavior
onInputKeyDown use only moment(point) instead of moment(point)     .utc()     .utcOffset(utcOffset);
that leads to inconsistency onSelect (when you select date in dropdown) consider date and onInputKeyDown does not.
Steps to reproduce
In timezone +1 select date via datepicker dropdown (i.e. 20/3/2018). Change in input to 24/3/2018 and 23/3/2018 23:00 is returned.

PRs to fix this are welcome


Update to more current version of RC3

Change bundles to use the 'objects' property instead of separate properties for each type of object
Remove pattern_lang
Remove location attributes
Fix a few examples/idioms
Add titles to properties so validator can reword error messages more easily

Looks good!


Add a command for loading all plugins at once

Sometimes I need to have all plugins loaded (for instance before doing UpdateRemotePlugins in neovim). Right now, I need to manually load all plugins via PlugStatus. A shortcut for this would be nice.

NVIM v0.2.0
Build type: Release
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -Wconversion -DNVIM_MSGPACK_HAS_FLOAT32 -O2 -DNDEBUG -DDISABLE_L
OG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERAT
ED_DECLARATIONS -D_GNU_SOURCE -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.2.0/src -I/usr/include -I/usr/include -I/usr/include -I/usr/i
nclude -I/usr/include -I/usr/include -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui
For differences from Vim, see :help vim-differences

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Type:

[ ] Bug
[ ] Enhancement
[x] Feature Request
[ ] Question

OS:

[x] All/Other
[ ] Linux
[ ] OS X
[ ] Windows

Vim:

[ ] Terminal Vim
[ ] GVim
[x] Neovim

plug#load function currently takes variable number of arguments, so you can call call('plug#load', keys(g:plugs)), but size of varargs in Vimscript is limited to 20, so it will fail if you have more that 20 plugins installed. You can use a for-loop or map() to call plug#load for every one of them, but then it's not efficient. I'll update the function so that it can alternatively process a single list of names.

call plug#load(keys(g:plugs))

Thanks!


Updated recoveryservices backup tests

Included changes to address issue #1422
Updated e2e test to include resource group and vault creation
Minor refactoring in tests (removed unused imports, PEP8 comment corrections)

Codecov Report

Merging #1551 into master will increase coverage by 0.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1551      +/-   ##
==========================================
+ Coverage   54.04%   54.17%   +0.13%
==========================================
  Files        3590     3590
  Lines       88625    88625
==========================================
+ Hits        47893    48012     +119
+ Misses      40732    40613     -119

Impacted Files
Coverage Δ

.../operations/backup_protectable_items_operations.py
91.66% <0%> (+2.77%)
:arrow_up:

...vices/operations/vault_extended_info_operations.py
20.89% <0%> (+7.46%)
:arrow_up:

...ices/operations/backup_vault_configs_operations.py
27.08% <0%> (+10.41%)
:arrow_up:

...es/operations/backup_storage_configs_operations.py
29.54% <0%> (+11.36%)
:arrow_up:

...ure/mgmt/recoveryservices/operations/operations.py
37.5% <0%> (+15.62%)
:arrow_up:

...rvices/operations/replication_usages_operations.py
37.5% <0%> (+15.62%)
:arrow_up:

...t/recoveryservices/operations/usages_operations.py
37.5% <0%> (+15.62%)
:arrow_up:

...rvices/operations/vault_certificates_operations.py
38.7% <0%> (+16.12%)
:arrow_up:

...services/azure/mgmt/recoveryservices/models/sku.py
100% <0%> (+16.66%)
:arrow_up:

...ces/operations/registered_identities_operations.py
48% <0%> (+20%)
:arrow_up:

... and 7 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 97064ed...2deb5cd. Read the comment docs.

Thanks @DheerendraRathor !!!! That's really helpful (y)


Add ChipWhisperer to trs trace conversion script.

The script is based on Riscures trsfile Python library. Use the script
to convert traces stored in ChipWhisperer's project to Riscure's trs
format.
Signed-off-by: Miguel Osorio<EMAIL_ADDRESS>

Closes lowrisc/ot-sca#12

LGTM, thanks @moidx! Should we name this something like cw_to_trs.py, i.e. with _to_ in the name, to make it clear that this is a conversion script?

Done. Thanks @alphan!


fix(eslint): remove useless old rules [BREAKING]

Deploy preview ready!
Built with commit e5dd3a593f8977fbd294485894ca430256feea8f
https://deploy-preview-307--mcs-lite-introduction.netlify.com

Deploy preview ready!
Built with commit e5dd3a593f8977fbd294485894ca430256feea8f
https://deploy-preview-307--mcs-lite-ui.netlify.com

Deploy preview ready!
Built with commit e5dd3a593f8977fbd294485894ca430256feea8f
https://deploy-preview-307--mcs-lite-mobile-web.netlify.com


maybe add a tokenizer and token enumerator to core lib to make it easy to build recursive descendands parsers

Hmm, some examples would be appreciated!

like an regex based tokenizer:
(def builder (make-tokenizer-builder))
(add-lexeme builder "(" 'OpenParen)
(add-lexeme builder ")" 'CloseParen)
(def tokenizer (make-tokenizer builder))
(def tokens (tokenize tokenizer "()"))

and  an enumerator to get the tokens:
(peek-token tokens) -> gives next token, but dont consume it (lookahead) (consume-token tokens) -> gives next token

a token is a pair (symbol kind, string value)

what do you think?

it would make sense to store it in another package. we need a easier way to create packages on the clr side, maybe through attributes?
[LispPackage("core.vector")]
public static class VectorFunctions {
}
[LispPackage("core.parsing.tokenizer")]
public static class TokenizerFunctions {
}

Yes, I think it makes sense to put the tokenizer in a separate package. Vector can probably stay in core, it's foundational enough!

do you agree with the attribute to add functions to packages?
it would be more readable if we have many more functions and packages. I could implement the architecture and some sample packages like the tokenizer

The attribute sounds great

In this case, can I recommend a two step approach? First adding the attribute and refactoring how primitives get initialized. And then a separate task which is the work on the tokenizer itself.

i will implement an architecture that collect all functions. all other stuff is implemented by the functions and the values are controlled by the runtime.
and for the tokenizer do you mean something like when a token is a boolean it should be automaticly converted to a boolean?
I could add something like initializer callbacks that conberts the string to a primitive and some basic implementations for it

No, I meant generally what you suggested in the title of this issue ("maybe add a tokenizer and token enumerator"), not any specific kind of tokenizer.
Please feel free to add a tokenizer for your purposes, but let's keep that as a separate task, after the primitives refactor, so that primitives can have their own pull request.


webpack-bundle cannot be found after server start

Hi guys, I'm having weird error after server start. Error disappears when I change url in my browser or after few page reloads. Here's what I'm getting:
Sprockets::FileNotFound in Home#index
Showing /home/funky/projects/billbill/app/views/layouts/application.html.erb where line #7 raised:

couldn't find file 'webpack-bundle' with type 'application/javascript'
Checked in these paths:
  /home/funky/projects/billbill/app/assets/config
  /home/funky/projects/billbill/app/assets/images
  /home/funky/projects/billbill/app/assets/javascripts
  /home/funky/projects/billbill/app/assets/stylesheets
  /home/funky/projects/billbill/app/assets/webpack
  /home/funky/projects/billbill/vendor/assets/javascripts
  /home/funky/projects/billbill/vendor/assets/stylesheets
  /home/funky/.gem/ruby/2.3.1/gems/jquery-rails-4.2.1/vendor/assets/javascripts
  /home/funky/.gem/ruby/2.3.1/gems/coffee-rails-4.2.1/lib/assets/javascripts
  /home/funky/.gem/ruby/2.3.1/gems/actioncable-<IP_ADDRESS>/lib/assets/compiled
  /home/funky/.gem/ruby/2.3.1/gems/turbolinks-source-5.0.0/lib/assets/javascripts
  /home/funky/projects/billbill/app/assets/webpack
  /home/funky/.gem/ruby/2.3.1/gems/bootstrap-sass-3.3.7/assets/stylesheets
  /home/funky/.gem/ruby/2.3.1/gems/bootstrap-sass-3.3.7/assets/javascripts
  /home/funky/.gem/ruby/2.3.1/gems/bootstrap-sass-3.3.7/assets/fonts
  /home/funky/.gem/ruby/2.3.1/gems/bootstrap-sass-3.3.7/assets/images

Is it something wrong with my environment? You may check my repo, I'm getting it in blank project, after installing react on rails, so after this commit.
I was following this tutorial using chruby+ruby-install instead of rvm and rails 5 instead of 4. And I'm using Atom, not RubyMine.
Maybe it's OK? Maybe It's just needs some time on my laptop...
P.S. error log is from the latest commit.

You need to make sure that your webpack config files and the your initializers/react_on_rails.rb files point to the same output files. Apparently, you have webpack-bundle in your initializer, but not in your webpack config files.

@justin808 OK, I already have them in webpack config here:
https://github.com/FunkyloverOne/billbill/blob/master/client/webpack.config.js#L16
But I do not see where I should put inside initializer, looks like it's already there too...
https://github.com/FunkyloverOne/billbill/blob/master/config/initializers/react_on_rails.rb#L10
BTW, I haven't changed any configs, so that's what was set by your generator.

I'm pretty sure the default generator works. I just created a few videos on this:

Overview:  https://youtu.be/F4oymbUHvoY
Running the generator:  https://youtu.be/_bjScw60FBk
Generator code walkthrough: https://youtu.be/McQ9UM-_ocQ

@FunkyloverOne Do you think there's an issue with React on Rails, or your own setup?

Yup, it all works, just as I tought - my system is just a bit slow.
Thanks for your videos, they makes me feel not that scared of all that new stuff :D
The webpack-bundle.js file is just being deleted after server starts and in takes some time to regenerate it.

I'll just leave this here for anyone else who ran into this while trying to Dockerize a Rails applications using react_on_rails: https://blog.codeship.com/using-honcho-create-multi-process-docker-container/.
I ran into this issue because the Docker container couldn't run multiple Foreman processes, even when using the "formation" options to run them concurrently.  Installing and using Honcho instead of Foreman solved it for me.

This issue is coming for me too from a fresh install

+1 This issue is coming for me too from a fresh install

@icemelt7 any ideas?

This is happening for me on heroku. My app was working fine, then all of a sudden Heroku starts the asset-pipeline and stops because:

doh ...looks like running assets locally and committing my public/assets/ folder resolved this issue for me.
And, forgive me for not saying so before: thanks for this incredible project!

@JayTeeSF You should not be committing to your /public/assets folder.
PS. Please tweet to hash tag #react_on_rails and/or comment on https://github.com/shakacode/react_on_rails/blob/master/KUDOS.md with gratitude.
I really appreciate it. 🙏😇👍.

In case anyone else runs in to this, I was using puma, not foreman. When using puma you must separately run webpack using a command like:
sh -c 'rm app/assets/webpack/* || true && cd client &&
         bundle exec rake react_on_rails:locale && yarn run build:development'

either in a separate window or in the script that starts puma.

@mustmodify hey dude did you already try your solution in production? How does it work

The above solution is only needed for dev. In production, capistrano runs rake assets:precompile which (I guess) triggers webpack to run the once time. Here's what I did to set up my production machine: https://gist.github.com/mustmodify/e4d29b6dd9992381b66cd4efe0b6d32c

@giovapanasiti yep, it hooks into assets:precompile


Allow code execution in component sandbox from the story sandbox

Clear and concise description of the problem
Use case: control the store used in a component from the story.
Example with the PiniaStore.story.vue from the example/vue3
<script lang="ts" setup>
import PiniaStore from './PiniaStore.vue'
import { useMyStore } from '../lib/myStore'

const myStore = useMyStore()
myStore.myValue = 1993
</script>

<template>
  <Story title="PiniaStory">
    <PiniaStore />
  </Story>
</template>

Suggested solution
Maybe add a hook to execute some logic like this:
<script lang="ts" setup>
import PiniaStore from './PiniaStore.vue'
import { useMyStore } from '../lib/myStore'

function sandboxSetup() {
  const myStore = useMyStore()
  myStore.myValue = 1993
}
</script>

<template>
  <Story
    title="PiniaStory"
    :sandbox-setup="sandboxSetup"
  >
    <PiniaStore />
  </Story>
</template>

Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

Ok, I simply forgot the setupApp props... Here's the solution
<script lang="ts" setup>
import PiniaStore from './PiniaStore.vue'
import { useMyStore } from '../lib/myStore'

function setupApp() {
  const myStore = useMyStore()
  myStore.myValue = 1993
}
</script>

<template>
  <Story
    title="PiniaStory"
    :setup-app="setupApp"
  >
    <PiniaStore />
  </Story>
</template>


not working on local network (same lan), but works from outside (wan)

Hi all,
I can see the snap shots via home app, and all the 3 cameras updates every 10 seconds just fine.
If I select a camera for a live stream, it will attempt to connect but fails after about 60 seconds.
If I drop off my local network, and onto my cellular connection, I can connect and live stream just fine.
Homebridge is at the latest docker release, camera ui plugin to the last version too.
All seems ok except for this behavior.
the same here (that's get closed for inactivities): https://github.com/seydx/homebridge-camera-ui/issues/635

🎉 A new version of camera.ui
A new version of camera.ui is currently under active development. An initial alpha/beta release and previews are coming soon. Stay tuned for exciting updates: https://github.com/seydx/camera.ui/issues/448 .
This version will no longer be developed / fixed. The new version contains many novelties and fixes (most important is for HKSV recording).


Content width not set properly

Even though default styles were defined in PR#102, I'm still experiencing width setting issues:

Both rules added in that PR are set properly in the inline stylesheet but .gsc-comments is still missing 1 or 2 pixels worth of padding-right. Here's a live demo if you need to give it a spin yourself.
Thanks 💪

@barnumbirr Looks just fine on my end. What browser are you using? Have you tried disabling all browser extensions (e.g. try opening in an incognito/private window)?

@barnumbirr The issue seems to come from your end. The left/right margin in this rule is too large:

Disabling them or reducing the value (e.g. to 1.1rem) seems to fix it.

@laymonage thank you for looking into the issue. I'm using Firefox 92.0 but haven't touched left margins. The only CSS I've modified is to reverse the comment box and comments order as follows:
.gsc-comments > .gsc-header {
  order: 1;
}

.gsc-comments > .gsc-comment-box {
  order: 2;
  margin-bottom: 1rem;
}

.gsc-comments > .gsc-timeline {
  order: 3;
}

.gsc-timeline {
  flex-direction: column-reverse;
}

.gsc-header {
  padding-bottom: 1rem;
}

@barnumbirr Yes, but the issue comes from the your MkDocs theme's CSS, specifically the rules I pointed above. You can see that it works just fine on my website and https://giscus.app itself. You need to modify your MkDocs' theme. You can also add something like the following to your custom CSS for giscus, but to be honest this feels like a hack:
.gsc-comments {
  padding-right: 1px;
}

@laymonage although adding one pixel of right padding to the gsc-comments class feels like a hack, I fell more comfortable with that then modifying Material for MkDocs' CSS. Unfortunately, that padding doesn't seem to fix it and I still can't wrap my head around why Material for MkDocs would break it in the first place as adding any value other than 1.2rem to margin-right as you've pointed out above seems to work just fine.

@barnumbirr You're not supposed to put the custom CSS on your website. The widget is loaded in an <iframe> so your styles won't have any effect. You need to use a custom giscus theme via the data-theme attribute.
If that's too much hassle for you, try this instead:
.md-main .md-content > .md-content__inner.md-typeset {
    margin-left: 1.1rem;
    margin-right: 1.1rem;
}

It's probably a bug in either the Material MkDocs or Firefox, maybe you could open an issue there.

If that's too much hassle for you, try this in your extra.css instead:
.md-main .md-content > .md-content__inner.md-typeset {
    margin-left: 1.1rem;
    margin-right: 1.1rem;
}

That fixes it indeed. Issue is also present on Microsoft Edge but not on Chromium nor Firefox Mobile. Don't really have an idea if this is a browser or theme issue so not sure where to report it.
I'll close this issue for now.


[TypeScript Resolvers] feat: Generate Interface types without field resolvers

Is your feature request related to a problem? Please describe.
When attempting to generate types for an existing graphql server, I am having trouble getting the generated types for interfaces to match my implementation.
On my server I only specify a __resolveType resolver for my interface type, and let the implementing types provide the revolvers for the shared fields.  However, when I generate types, the interface type requires that a resolver for all fields be provided.

Example
interface Animal {
  color: String!
}

type Dog implements Animal {
  color: String!
  bark: String!
}

type Cat implements Animal {
  color: String!
  meow: String!
}

const resolvers: Resolvers = {
  Cat: {
    color: e => e.color,
    meow: e => e.noise,
  },
  Dog: {
    color: e => e.color,
    bark: e => e.noise,
  },
  Animal: {
    __resolveType: e => (e.dog ? "Dog" : "Cat")
    // Property 'color' is missing in type '{ __resolveType: () => "Cat"; }' but required in type 'AnimalResolvers<any, Animal>'
  },

Describe the solution you'd like
I would like to specify in my configuration that I would like interface resolver types to only require a __resolveType field.
I would be happy to work on adding the functionality if I could get some confirmation this is a feature worth adding, and not just me doing something wrong 😄 .

I reproduced what you have within a test-case: https://github.com/dotansimha/graphql-code-generator/commit/08ded8010e575890055a08925e5ecff0882a8caa
Could you tell me how your codegen.yml looks like?

As @kamilkisiela said, the generated signature doesn't force you to implement the resolvers for the interface's fields.

Full codegen.yml:
schema: src/graphql/schema.graphql
generates:
  ./src/types/graphql.ts:
    plugins:
      - typescript
      - typescript-resolvers
    config:
      rootValueType: undefined
      contextType: ~/graphql/context#Context
      maybeValue: T | null | undefined
      avoidOptionals: true
      showUnusedMappers: true
      noSchemaStitching: true
      skipTypename: true
      enumsAsTypes: true
      namingConvention:
        enumValues: keep
      mappers:
        // Lots of mappers

I'm guessing it's due to avoidOptionals?
I can take a look tonight and update the test to match what I want.

@rynobax yeah the avoidOptionals is causing it, you can remove it for the typescript-resolver plugin. If you need to for typescript plugin only, you can do:
schema: src/graphql/schema.graphql
generates:
  ./src/types/graphql.ts:
    plugins:
      - typescript:
		avoidOptionals: true
      - typescript-resolvers
    config:
      rootValueType: undefined
      contextType: ~/graphql/context#Context
      maybeValue: T | null | undefined
      showUnusedMappers: true
      noSchemaStitching: true
      skipTypename: true
      enumsAsTypes: true
      namingConvention:
        enumValues: keep
      mappers:
        // Lots of mappers

What I want is to have avoidOptionals on for all my object resolvers, but not my interface or union resolvers.  Alternatively, it would also be fine if the interfaces types worked the same as union types, where only a __resolveType field is generated..
I looked into adding a test for what I want, but I had trouble getting the workspaces to bootstrap.  If it would be useful I can keep working on it.  I would also be happy to work on a PR for this feature if you want, just let me know.

@rynobax Make sure you have the latest Yarn installed, clone this repo and run: yarn and then yarn build. This should get you started.
The exact use-case you mentioned is a bit different, so I'm closing this one, and feel free to open a new issue that described exactly what you need and what options should avoidOptionals should support.

@dotansimha this is an example of what was originally asked for. The interaction between using interface graphql types and the avoidOptionals configuration option is unfortunate and ends up causing a lot of duplicated code since the same resolvers need to be implemented twice instead of defining a __resolveType once then implementing the resolvers for each implementation of the interface.
@rynobax
I managed to patch this using a mapped type, but it'd be nice to get a config option to generate __resolveType as the only resolver for interface types:
export type FixTypeResolvers<Resolvers> = {
  [P in keyof Resolvers]:
    Resolvers[P] extends { __resolveType: (a: any, b: any, c: any) => any }
      ? Pick<Resolvers[P], "__resolveType">
      : Resolvers[P];
};

Or put another way, I'd like a way to make the following SDL:
interface View {
  "The type of view."
  type: ViewKind!
  "A list of sites for this view."
  sites: [Site!]!
}

generate the following typings:
export type ViewResolvers<
  ContextType = Context,
  ParentType = ResolversParentTypes["View"]
> = {
  __resolveType: TypeResolveFn<
    "ClientView" | "SiteView",
    ParentType,
    ContextType
  >;
};

Without turning off avoidOptionals so that all my other resolvers don't allow optional resolvers.

@mscharley I see, this use-case seems fine. If you already managed to change that, maybe you can create a PR for this with a configuration flag? :)

I haven't made any changes to the code generation, I just made a mapped type inside my application which manages to patch in the desired behaviour. If you're happy that this is an actual issue, can you reopen this please?

Keeping open, thanks @mscharley . Can you please provide an example for the type you created? maybe it's something we can use in the generated output.

I'm not sure what you're asking for here, I provided an example SDL for an interface and what I'd want the code generation to output already a few comments back. I also provided the mapped type already too, though that's very much a hack.

I see. I wanted to add it to the codegen core as configuration, in order to help you to avoid the need to wrap the type.

I would love for this to be a configuration option for this, I'm just confused by what you meant by "Can you please provide an example for the type you created?". I'm pretty sure I already provided examples, so I'm not clear on what you're asking for.

Thanks @mscharley , I wrote it because I missed your commend with the example :)


New Website Logo: Oxycoin

Name: Oxycoin
Homepage url: https://oxycoin.io
Brand Guidelines/Licensing: no requirements
Logo<EMAIL_ADDRESS>

Thanks. Added to the site. Should be live next week.


[FEATURE] Automated restart of MWAA environment after recovery workflow

Is there an existing feature request for this?

[X] I have searched the existing feature requests

What MWAA versions will be affected by this feature request?
2.5.1, 2.6.3, 2.7.2, 2.8.1
Is your feature request related to a problem? Please describe.
During the backup restore recovery workflow, when a new MWAA environment gets created, the plugins will load before the workflow had an opportunity to restore the connections and variables tables. If a plugin depend on these tables, they they will fail due to missing variable/connection dependencies.
Describe the solution that you would like.
A solution is to automate restarting the newly created MWAA environment after all the other tasks of the recovery workflow is complete.
Describe alternatives you have considered.
The alternative is to manually restart the MWAA environment after the recovery workflow is complete, which is not ideal in a DR situation.
Anything else?
N/A

This is not a priority at the moment.


IBMProvider initialization fails if h/g/p has no backends

Information

qiskit-ibm-provider version: 0.2.0
Python version:
Operating system:

What is the current behavior?
IBMProvider() fails with
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/qiskit_ibm_provider/ibm_provider.py", line 184, in __init__
    self._initialize_services()
  File "/usr/local/lib/python3.9/site-packages/qiskit_ibm_provider/ibm_provider.py", line 411, in _initialize_services
    self._backend = IBMBackendService(self, hgp)
  File "/usr/local/lib/python3.9/site-packages/qiskit_ibm_provider/ibm_backend_service.py", line 85, in __init__
    self._initialize_backends()
  File "/usr/local/lib/python3.9/site-packages/qiskit_ibm_provider/ibm_backend_service.py", line 94, in _initialize_backends
    for name, backend in hgp.backends.items():
  File "/usr/local/lib/python3.9/site-packages/qiskit_ibm_provider/hub_group_project.py", line 62, in backends
    self._backends = self._discover_remote_backends()
  File "/usr/local/lib/python3.9/site-packages/qiskit_ibm_provider/hub_group_project.py", line 82, in _discover_remote_backends
    for backend in backends:
TypeError: 'NoneType' object is not iterable

if the particular h/g/p has no backends. In this case the particular one is hub='ibm-q-internal', group='dev-cloud', project='reservations'
Steps to reproduce the problem
Initializing an account with a h/g/p that has no backends.
What is the expected behavior?
IBMProvider() doesn't fail
Suggested solutions

This is also blocking me

Will be fixed by https://github.com/Qiskit/qiskit-ibm-provider/pull/502

Can confirm I am running into this.

can the fix be made part of a (sub-) release?

can the fix be made part of a (sub-) release?

Sure, i'll release 0.2.1 today


Pull request test

@JoaoMoraesJr Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.


Incorrect results in doublet-source panel method example case.

When I ran the case codes, I got that:
julia> begin            airfoil = naca4((2,4,1,2));            foil    = Foil(airfoil);            V, α   = 1.0, 3.0;            uniform = Uniform2D(V, α);            cl, cls, cms, cps, panels =                solve_case(foil,                     uniform;                     num_panels = 80);        end;cl -0.06478979281472284
as the result of NACA2412 is around 0.608250
# result from XFoil when alpha = 3.0 deg and re = 1e5 and mach = 0.0 is 0.608250 ? where is the error?

Thanks for finding this! The issue was that the NACA 4-digit airfoil generation generates a blunt trailing edge by default. The currently implemented doublet-source panel method does not predict blunt trailing edge airfoils accurately at all, so the default option has been switched to sharp trailing edges.
The latest push 188034ce43c3278c81fa259b0ba6460cb520a720]should fix this issue. The results will not exactly match XFOIL's as the methods are different, but should be somewhat close.

Thanks for finding this! The issue was that the NACA 4-digit airfoil generation generates a blunt trailing edge by default. The currently implemented doublet-source panel method does not predict blunt trailing edge airfoils accurately at all, so the default option has been switched to sharp trailing edges.
The latest push 188034c should fix this issue, so please update AeroMDAO accordingly. The results will not exactly match XFOIL's as the methods are different, but should be somewhat close.

Thank you very much for replying to the question so quickly, the problem is indeed solved, excellent codes, I am reading it carefully and have learned a lot 😀


Use ENSEMBL ID to access transcripts from ENSEMBL API

This issue was decided not to be continued with after reviewing the APIs for both Ensembl and VariantValidator - VV determined to be simpler for the desired functionality - requesting VV API implemented in merging branch 18-additional_parsing_info branch into dev.


Added a chapter about open source tools

This chapter is based on the previously published blog: https://www.khronos.org/blog/offline-compilation-of-opencl-kernels-into-spir-v-using-open-source-tooling
Can be viewed at: https://github.com/AnastasiaStulova/OpenCL-Guide/blob/os_tooling/chapters/os_tooling.md

Is 'flavors' of SPIR-V accepted terminology? Is it a little more precise/formal to say that using Vulkan and OpenCL use different Environment Specifications?

Is 'flavors' of SPIR-V accepted terminology? Is it a little more precise/formal to say that using Vulkan and OpenCL use different Environment Specifications?

The way I've come across this notion while discussing with Codeplay, MS and inside the WG was that there is "SPIR-V for graphics" and "SPIR-V for compute" which were referred to as two "flavors" of SPIR-V. Should we want to be explicit about this being non-normative wording, we could add "so called" before it, but IMHO I don't think it's necessary.
IIUC "flavors" and "dialects" of SPIR-V are shorthands for

The meaning (for eg. precision) and/or the presence of SPIR-V ops may subtly, but ever so importantly change based on the execution context, which is formally defined by the SPIR-V Environment Specification in use. Commonly used environment specifications may have domain-spoken names. One may encounter terms like "SPIR-V for graphics" referring to SPIR-V using the Vulkan Environment Specification or "SPIR-V for compute" referring to the use of the OpenCL Environment Specification. (Note how Vulkan compute shaders are still "SPIR-V for graphics".) These anecdotal names, more precisely different Environment Specs are often referred to as "flavors" or "dialects" of SPIR-V.

I agree that SPIR-V flavor/dialects are used pretty commonly but if we think it might not be clear enough we could add something like:
OpenCL flavor of SPIR-V (implementing OpenCL Environment Specification)
Actually, I like the term SPIR-V for graphics or SPIR-V for compute although Vulkan has compute too so it might be more confusing.

Te diagram source is available at: https://docs.google.com/presentation/d/1JMlnv-F3Bhv6pNCfeiz1UvvrtpEfw9aVhIonU60GtMc/edit?usp=sharing
Edit rights can be requested there.


[top-level/pwrmgr] Extend chip_sw_pwrmgr_main_power_glitch_reset

Add two groups of assertions to check that:

the clock valids are deasserted if a power glitch is detected.
clocks are stopped if their valid is deasserted.

Signed-off-by: Abdullah Varici<EMAIL_ADDRESS>

This PR is for issue: https://github.com/lowRISC/opentitan/issues/14780. I am not sure entirely if this is a correct solution.

Thanks @matutem for your feedback. Now I've made changes you wanted. Can take a look at it again?

The failing CI checks look spurious to me. They should go away on the next run.

Thanks @andreaskurth for your suggestions. I've added them.

I tried to address your feedback (@matutem and @msfschaffner ) and it would be great you could take a look again. Also, I am happy to implement further feedback.

I made changes according to your feedback. Could review it again? @matutem

This may need a rebase onto master to fix the FPGA CI failures.

Thanks @msfschaffner, I've rebased it.


Filesystem Watchers (VS Code) do not work as expected in Codespaces

@shcheklein can you please set up codespaces for vscode-dvc-demo.
@alex000kim can you give me access to the remote and codespaces for a project that I can test against please? Maybe magnetic-tiles-defect? or the new one you've been working on.

You should already have access to it: https://github.com/iterative/magnetic-tiles-defect

Seems like for some reason the appropriate metrics files are not being watched but the watchers are otherwise working as expected for plots updates. Saving dvc.yaml:
https://user-images.githubusercontent.com/37993418/205004733-5c8d4017-8acd-4c98-8254-17e864a82221.mov
Still investigating.

Second attempt to recreate. Everything working as expected 🤦🏻:
https://user-images.githubusercontent.com/37993418/205022514-22927623-5214-4960-b30d-93d90a42c264.mov
except now custom icons are missing:


pip installed version of order_points give wrong answer

I recently installed via pip and then spent the next 4 days trying to work out why my 4 point perspective transform was failing.
The version of the order_points function was returning the wrong sequence, when I replace the shipped version with the version on this page the transform works as expected.
Example code to show the error can be found here:
http://www.hardill.me.uk/sample.tgz
$ pip show imutils
Name: imutils
Version: 0.3.6
Location: /usr/local/lib/python2.7/dist-packages
Requires:

Looks like there is an outstanding pull request that covers this: https://github.com/jrosebr1/imutils/pull/13

Thank you for bringing this to my attention @hardillb. I'll take another look at the pull request.


feat: plumb from through EVM buildThorTrade

Description

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

Testing

Engineering

Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #4826

PR #4827

PR #4828   👈

This comment was auto-generated by Graphite.

Graphite couldn't merge this pull request because a downstack PR #4827 failed to merge.


Update filtering docs

@eliecharra has pointed out that this sentence from the docs was outdated and should be removed.

@sundowndev I think you can remove it from current next version too and maybe previous ones too ? I didn't remember when we merged this feature ...

Fair enough but @wbeuil merged it too fast haha ; it has been introduced in v0.11


fix(menu): add [matMenuTriggerFor] selector and matMenuTriggerFor input

Need this so that MdMenuTrigger can be used with the NoConflictStyleCompatibilityMode module (which allows and requires the 'mat' prefix for all selectors).

I signed it!
On Tue, Jan 31, 2017 at 3:50 PM googlebot<EMAIL_ADDRESS>wrote:

Thanks for your pull request. It looks like this may be your first
contribution to a Google open source project. Before we can look at your
pull request, you'll need to sign a Contributor License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/
https://cla.developers.google.com/ to sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll
verify. Thanks.

If you've already signed a CLA, it's possible we don't have your
GitHub username or you're using a different email address. Check your
existing CLA data https://cla.developers.google.com/clas and verify
that your email is set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
If you signed the CLA as a corporation, please let us know the
company's name.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/angular/material2/pull/2878#issuecomment-276531335,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFd31sgxiY2m2gFa41K6QOEp1ebUL0rlks5rX8jggaJpZM4LzUyL
.

I signed it! (I needed to update my emails).

Will be part of the PR #2923


OBSOLETE peptidyl-serine phosphorylation involved in acrosome reaction

GO:0060477
peptidyl-serine phosphorylation involved in acrosome reaction

Duplicate https://github.com/geneontology/go-ontology/issues/14281


expose swagger-ui index template variables to app configuration

Fixes #1178  .
Changes proposed in this pull request:

add an app option for variables which will be passed to swagger-ui index.j2 template

Coverage increased (+0.003%) to 96.294% when pulling 2515ad7fc3fc59b7904b199d40e18b192f22981f on msladecek:msladecek/swagger-template-variables into 96bdcb010a4e5180c2bce18295e7b576c9c1ef0f on zalando:master.

Thx for the PR @msladecek. Hopefully you're still interested in getting this merged :)
The changes look good to go. Before merging, would be great to just:

add some info on this to the documentation
rebase and retarget the PR to main, which is the new default branch

Hello, I have question, is it required that only the original contributor can continue the work for this merge request, please ? During 16+ months, maybe the original contributor don't want to continue work on it.  But this feauture is very interesting, it's better if we can integrate it.

Hi @zhang-hongjie the work in this PR was complete, so I rebased and retargeted it myself. I opened #1390 which should expose it in the documentation. Feel free to take up any open issues though.

@RobbeSneyders  Thanks, very cool.


Remove irreader's open source icon

Explain why it should be removed
irreader is not open source
https://github.com/jaywcjlove/awesome-mac/blob/master/README-zh.md#rss
http://irreader.fatecore.com/

@VaneHsiung thx!


Create Asyncthunk to fetch data. necessary changes made in components…

In this Milestone-: Creates Asyncthunk to fetch data. necessary changes made in components files and styling done

STATUS: APPROVED!!! 🎉 🎉 🎉 🍾 🍾 🍾
Hi @Daqar,
Good job !!!
To Highlight! 👏 🟢
✔ Good commit messages
✔ Clean and Organized code
✔ Fetches data from API
There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉 🎉 🎉 🍾 🍾 🍾

Cheers and Happy coding!👏👏👏


Fixtures fail in editor.syncRegions when initialized with dom elements instead of query

Hi,
First of all a big compliment for this great tool!
I have noticed some strange behaviour though when using fixtures.
I have created this small fiddle to demonstrate the issue: https://jsfiddle.net/g6v3rxLd/27/
If i pass a nodeList to the init function of the editor app, it seems to work fine the first time you click the edit button. However, if after that, you close and start the editor again, it fails in the syncRegions function because somehow, the parentNode of the fixture has become null.
It fails on this line:
this.parent().domElement().parentNode.replaceChild(this._domElement, this.parent().domElement());
with the following error:
Cannot read property 'replaceChild' of null
Hope this helps to make this tool even better!

Hi @rutsch,
Thanks for the kind words, so there are a couple of issues here, one is that you need an id against your fixture as it is a fixture/region and we need a way to uniquely identify it from other regions. You can specify which attribute is used to identify a fixture/region as the second argument to init but by default it's the id.
On that basis you should change the HTML code in you example to something like:
<p data-fixture id="my-fixture">
    <b>Q1 2017</b>
</p>

This doesn't break your demo because there's only one fixture but it would do if you had multiple so I'm flagging it now in case it's not clear that this is required in fixtures.
As for what breaks your demo when sending a list of nodes the answer is simply that when you save the page the HTML is re-written and so the nodes that you initially queried and selected are no longer part of the DOM, you will need to check for the stopped event against the editor and resync the regions:
editor.init(domRegions);

editor.addEventListener('stopped', (ev) => {
    editor.syncRegions(document.querySelectorAll('[data-fixture]'))
})

Hope that helps - Ant

I think i should re-write my last question as follows:
In edit mode, is it possible to add a new nested HTML structure containing only Fixtures and init those Fixtures?
I can create HTML on toolbarbutton click, but i cannot attach it to a region because it's not a ContentEdit element.
I can replace the empty _domElement with the new HTML, and do a syncRegions() on the editor, but after pressing the save button, the HTML is gone again.
Any help on this would be highly appreciated!


sbclPackages.jzon: use up to date version from quicklisp

Description of changes
In the meantime jzon had a 1.0.0 release and was added to quicklisp. Let's use it instead of a pinned old version.

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
[ ] 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

[ ] Fits CONTRIBUTING.md.

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

@ofborg build sbcl.pkgs.jzon ecl.pkgs.jzon