[BUG] Changes to workflow doesn't trigger garbage collection of legacy resources

Describe the bug
Changes applied to application workflow will not generate a new apprev. Now we have to modify components' fields to trigger garbage collection. Since GC depends on resourcetracker related to apprev, the legacy resources will still be there.
To Reproduce

Create 2 components from official demo application:

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: first-vela-app
  namespace: default
spec:
  components:
    - name: express-server1
      type: webservice
      properties:
        image: crccheck/hello-world
        port: 8000
    - name: express-server2
      type: webservice
      properties:
        image: crccheck/hello-world
        port: 8000
  workflow:
    steps:
    - type: apply-remaining
      name: deploy

Now there are 2 deployments.
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
express-server1   1/1     1            1           6m6s
express-server2   1/1     1            1           6m6s

Modify workflow to exclude express-server2 component

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: first-vela-app
  namespace: default
spec:
  components:
    - name: express-server1
      type: webservice
      properties:
        image: crccheck/hello-world
        port: 8000
    - name: express-server2
      type: webservice
      properties:
        image: crccheck/hello-world
        port: 8000
  workflow:
    steps:
    - type: apply-remaining
      name: deploy
      properties:
       // The application output resources will not include express-server2
        exceptions:
          - "express-server2"

Verify bug

kubectl get app -n default first-vela-app -o yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  annotations:
    oam.dev/kubevela-version: latest
  finalizers:
  - app.oam.dev/resource-tracker-finalizer
  generation: 2
  name: first-vela-app
  namespace: default
spec:
  components:
  - name: express-server1
    properties:
      image: crccheck/hello-world
      port: 8000
    type: webservice
  - name: express-server2
    properties:
      image: crccheck/hello-world
      port: 8000
    type: webservice
  workflow:
    steps:
    - name: deploy
      properties:
        exceptions:
        - express-server2
      type: apply-remaining
status:
  appliedResources:
  - apiVersion: apps/v1
    creator: workflow
    kind: Deployment
    name: express-server1
    namespace: default
  conditions:
  - lastTransitionTime: "2021-12-08T10:19:35Z"
    reason: Available
    status: "True"
    type: Parsed
  - lastTransitionTime: "2021-12-08T10:19:35Z"
    reason: Available
    status: "True"
    type: Revision
  - lastTransitionTime: "2021-12-08T10:19:35Z"
    reason: Available
    status: "True"
    type: Policy
  - lastTransitionTime: "2021-12-08T10:24:33Z"
    reason: Available
    status: "True"
    type: Workflow
  - lastTransitionTime: "2021-12-08T10:24:33Z"
    reason: Available
    status: "True"
    type: Render
  - lastTransitionTime: "2021-12-08T10:24:33Z"
    reason: ReconcileSuccess
    status: "True"
    type: Ready
  latestRevision:
    name: first-vela-app-v1
    revision: 1
    revisionHash: f7d150b128ed2e54
  observedGeneration: 2
  resourceTracker:
    name: first-vela-app-v1-default
    uid: 7aabdf08-e238-484c-9c64-d81b574513f3
  services:
  - healthy: true
    message: Ready:1/1
    name: express-server1
    workloadDefinition:
      apiVersion: apps/v1
      kind: Deployment
  status: running
  workflow:
    appRevision: first-vela-app-v1:263a07fd119c514d
    contextBackend:
      apiVersion: v1
      kind: ConfigMap
      name: workflow-first-vela-app-context
      uid: 12838245-017a-4589-8ff6-16bd0ad1c500
    finished: true
    mode: StepByStep
    startTime: "2021-12-08T10:24:32Z"
    steps:
    - firstExecuteTime: "2021-12-08T10:24:32Z"
      id: xb9bgfwo4v
      lastExecuteTime: "2021-12-08T10:24:32Z"
      name: deploy
      phase: succeeded
      type: apply-remaining
    suspend: false
    terminated: false

Noted that express-server2 doesn't exist in status.appliedResources
But deployment express-server2 still exist.
kubectl get deployment -n default
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
express-server1   1/1     1            1           10m
express-server2   1/1     1            1           10m

This may be attributed to resourcetracker:
kubectl get resourcetracker first-vela-app-v1-default -o yaml
apiVersion: core.oam.dev/v1beta1
kind: ResourceTracker
metadata:
  creationTimestamp: "2021-12-08T10:19:35Z"
  generation: 1
  labels:
    app.oam.dev/name: first-vela-app
    app.oam.dev/namespace: default
  name: first-vela-app-v1-default
  resourceVersion: "49132"
  uid: 7aabdf08-e238-484c-9c64-d81b574513f3
status:
  trackedResources:
  - apiVersion: apps/v1
    kind: Deployment
    name: express-server1
    namespace: default
    uid: d95c508d-69d3-43d4-b3b4-25ea3148f73e
  - apiVersion: apps/v1
    kind: Deployment
    name: express-server2
    namespace: default
    uid: a66e31a8-9d55-4887-9105-4cc035818a95

Expected behavior
I think during the GC, controller should diff Application.status.appliedResources and ResourceTracker.status.trackedResources , then clean up the legacy resources.
KubeVela Version
Version: master
GitRevision: git-cdb83c2f
GolangVersion: go1.17.1
Cluster information
Client Version: 4.9.0-0.okd-2021-11-28-035710
Server Version: 4.9.0-0.okd-2021-11-28-035710
Kubernetes Version: v1.22.1-1820+4dd1b5a1afc832-dirty

This problem is expected to be solved after ResourceTracker mechanism is reworked. See #2849 for details.
Briefly, the new mechanism will run GC based on ResourceTracker.Spec.ManagedResource and the ResourceTracker's version will follow the Generation of Application instead of AppRev, which means any changes to the Application Spec will trigger the GC, including changes to Workflow.

KubeVela v1.2.0-beta.3 fixes it.


Download a list of videos stored in a text file

Understood.
Checklist

[X] I'm reporting a feature request
[X] I've verified that I'm running youtube-dl version 2021.05.16
[X] I've searched the bugtracker for similar feature requests including closed ones

Description

WRITE DESCRIPTION HERE
Hi!
Youtube-dl is working well for me on Linux - I have one feature request, I would like to download a number of videos (from say the YouTube website) by placing the URL's of the videos into a .txt file, one URL per line, then run youtube-dl with the name of the text file and let youtube-dl work through the list as its ready.  It would save me a lot of time instead of having to do this for each video.

youtube-dl -a
:)

It's working perfectly! Thanks very much :)


Function name should be lowercase

https://github.com/shobrook/ast-lib/blob/f2f9fcda479773b9cfd0274eb07739e42a6df45b/lib/algorithms.py#L293

Unless Call is a proper noun.
Maybe ignore this? idk, your call

That class inherits from ast.NodeVisitor, and my definition of visit_Call is overriding theirs. So nah, it's not my call, and it's not your call – it's the ast module's call.


Dealing with nested comments

What is your question?
What is the recommended way to deal with (ie ignore) nested C-style comments (/* ... /* ... */ ... */) using Lark's LALR parser?
I tried defining a token for the start-of-comment (/*) and having a lexer_callback function manually scan the following text and replace inner /* and */ with spaces. It then constructed and returned a Token instance covering the whole of the outer comment but I think it was ignored - understandable, I suppose, since I was using a %ignore directive.

I think your best bet is to do it by writing a postlexer.

Thank you! I had missed this when reading the documentation.


migrating import/default rule to parsers.all function

Migration of import/default rule to parsers.all function
Closes #2498.

(I changed the base of this so it's into a "parsers" branch)

Am I going in the right direction ? @ljharb

This is looking great! We're down to 8 failures :-)


Points on the cone surface but isInside function return 0

Hi,
I just want to use isInside to check a point if is on a surface of a cone. I defined a point and visualise it, it is definitely on the surface of the cone. But the isInside function return False (0). Could you please help me with this problem? Thanks!

If it is on the surface then it is not inside.. :) so the output is technically correct!
It's probably better if you also check mag2(p-cone.closestPoint(mypt))

Hi,
Thank you so much for the reply. I just check the result following your suggestion, it returns 4.2500001239715134e-06.  Does it look right?

The code I used: "vedo.mag2(myCone.closestPoint(myPoint))". myCone is just a Cone object from vedo and my point is a position tuple of x,y,z coordinates.

you can maybe share your code to check? otherwise it is difficult for me to help..

H = 0.0050.01/(40.005-20.002)
H1 = (3 * 0.005 * 0.01 - 2 * 0.002 * 0.01) / (4 * 0.005 - 2 * 0.002)
tcone = Cone(alpha=0.5, r= 0.005, pos=(0, 0, H1), res=120, height=2H, axis=(0, 0, -1))
position1 = (-0.002 / 2, 0, 0.01 / 2)
tclo = tcone.closestPoint(position1)
print(tclo, position1)
print('inside: ', tcone.isInside(position1))
Thanks!

the point is almost exactly on one of the triangular surfaces of the cone and is technically outside of the cone. Replacing x=-0.00199 brings it inside:
from vedo import *

H = 0.005*0.01/(4*0.005-2*0.002)
H1 = (3 * 0.005 * 0.01 - 2 * 0.002 * 0.01) / (4 * 0.005 - 2 * 0.002)

tcone = Cone(alpha=0.5, r= 0.005, pos=(0, 0, H1), res=120,
	height=2*H, axis=(0, 0, -1))
position1 = (-0.00199 / 2, 0, 0.01 / 2)

tclo = tcone.closestPoint(position1)

printc(tclo, position1)
printc('inside: ', tcone.isInside(position1))
printc(mag(tclo-position1), c='b')

show(tcone, Point(position1), Point(tclo, c='g'), axes=1)

Thanks! Is there any other way to solve the problem like this? Because I already tried to improve the resolution of the cone. But still got the same problems。

the only way I see is to check the distance, and compare it with the face normal. Use .normals() and the cross product. To find the cell id use .closestPoint(pt, returnCellId=True).
Let me know if you need further help.

Thanks for the update! I will try the suggestion you provided and close the issue at this point.


Add event tracking

What
To measure engagement for users that have accepted cookies we want to
record certain events with either specific labels for targeted elements
or more generic for larger groups .
This script introduces functions to send events for:

targeted elements with data attributes
external links to non *.cloud.service.gov.uk subdomains and email links
404 pages

For targeted elements values for the event are read from the data
attributes.
For external links, values are partially set and partially read from
the target element.
For 404 pages, values are set.
How to review

Test url:  https://paas-product-pages-ga-test.london.cloudapps.digital/ (being verified by PA)
or  locally:
clone branch
run npm install to install latest dependencies
run npm test to verify
review code

@0atman  added a commit just now :)

need to drop the standard fix commit


No longer automatically subtract 1 from user-specified --jobs

This argument comes in two parts, but luckily, the first one is both easier to understand and hopefully to agree with.
Background: Bundler 1.4.0 added support for parallel installation via the --jobs param.  Soon after, this blog post (probably greatly amplified by this Thoughtbot blog post) popularized the recommendation "set --jobs to nproc - 1".
Not long after, probably also inspired by the popularity of this tip, this "n - 1 jobs" advice got codified into Bundler itself: https://github.com/bundler/bundler/commit/66acd02de593a6c7ee271bcbce3917eb3a01825a
However, my assertion here is Bundler should not do that.
The first argument (the easy one) is just that it's not doing what the user asks for.  For all the people following the (seemingly popular) tip to set their jobs to nproc - 1, they're actually ending up with the probably-worse - 2.  Even worse than that, if a user does a conservative --jobs 2, they're getting no benefit — Bundler is quietly taking their parallelization back down to "no parallelization".
Hopefully that's a sufficient argument on its own, but the part II is that this blanket advice is probably out-of-date anyway.
Using this script, I repeatedly installed 29 gems (installing them to a vendor/ dir and deleting it in between runs).  I averaged the time over 10 runs per --jobs value, but the trend holds regardless of how many runs you do.
Note that these numbers are for a machine with 2 physical cores and 4 virtual ones (a Mac, reporting 2 and 4 respectively from sysctl -n hw.physicalcpu and sysctl -n hw.ncpu, the latter corresponding to Linux's nproc).
~/Code/tmp/bundler_jobs_bench ☠  ./bundler_jobs_bench.sh

Installing 29 gems repeatedly...

===============================================
Using Bundler version 1.15.1 (current release version)
===============================================

--jobs 1  5.58435780 seconds on average (across 10 runs)
--jobs 2  5.35010690 seconds on average (across 10 runs)
--jobs 3  3.93493610 seconds on average (across 10 runs)
--jobs 4  3.86082760 seconds on average (across 10 runs)
--jobs 5  3.24673650 seconds on average (across 10 runs)
--jobs 6  3.49340190 seconds on average (across 10 runs)
--jobs 7  3.26473430 seconds on average (across 10 runs)
--jobs 8  3.34560500 seconds on average (across 10 runs)

===============================================
Using development version (no more n - 1 jobs)
===============================================

--jobs 1  4.32629540 seconds on average (across 10 runs)
--jobs 2  3.48100690 seconds on average (across 10 runs)
--jobs 3  3.30937880 seconds on average (across 10 runs)
--jobs 4  3.30868200 seconds on average (across 10 runs)
--jobs 5  3.54932920 seconds on average (across 10 runs)
--jobs 6  3.36123440 seconds on average (across 10 runs)
--jobs 7  3.96490630 seconds on average (across 10 runs)
--jobs 8  3.39955640 seconds on average (across 10 runs)

From the above, you can see:

In the first block, no notable change between --jobs 1 and --jobs 2 — that's because they're currently the same.

In both, a best time corresponding to the value that (effectively) matches nproc, not nproc - 1.

Regardless of nproc coming out best in this run, there is close enough performance among the range of nproc - 1 through to nproc * 2 that it doesn't seem like anything in particular (like the - 1 removed in this commit) should be codified — people seeking to particularly optimize their bundler runtimes should do their own tweaking of the value, and it should be respected as given.

@indirect I think this PR is yours to review

I just pushed up 9831fe9e1c24b02de2de742cad76216643215eed to actually red/green test this as well.  I couldn't figure out the tests at first, because it turned out they were subtly broken in a way that made it non-obvious that this n-1ing was happening at all.
The previous version of this test was slightly broken in a few ways:

The worker output (the preceeding "x: " that was being checked by expect(out).to match(/[1-3]: /)) is 0-indexed, so it should have at the very least been [0-3].

However, the tests only checked that any worker had any output value of 1, 2, or 3. They could have all been "1" and the test would still pass.  Specifically, in the old version of this test that checked expect(out).to match(/[1-3]: /), "3" was never output.

The final expect(out).to match(/: "4"/) test is only testing the echoing back of the jobs param, and was not actually testing that any parallelism occurred.

9831fe9e1c24b02de2de742cad76216643215eed lowers the jobs param down to 2 instead of 4 to try to guarantee that the test will always hit "full" parallelism, and then checks that there are actual workers for both 0 and 1, not just "any" workers.

I agree with the argument made here—let's use the value of jobs as given in 2.0, rather than subtracting 1.
Relatedly, I think 2.0 should default jobs to either the number of processors or nproc-1, changing parallel installation from opt in to opt out instead.

@indirect something like this?
diff --git a/lib/bundler/feature_flag.rb b/lib/bundler/feature_flag.rb
index b07ea4967..733dc265d 100644
--- a/lib/bundler/feature_flag.rb
+++ b/lib/bundler/feature_flag.rb
@@ -15,6 +15,7 @@ module Bundler
     (1..10).each {|v| define_method("bundler_#{v}_mode?") { major_version >= v } }

     settings_flag(:allow_offline_install) { bundler_2_mode? }
+    settings_flag(:auto_config_jobs) { bundler_2_mode? }
     settings_flag(:error_on_stderr) { bundler_2_mode? }
     settings_flag(:init_gems_rb) { bundler_2_mode? }
     settings_flag(:only_update_to_newer_versions) { bundler_2_mode? }
diff --git a/lib/bundler/installer.rb b/lib/bundler/installer.rb
index 3212a6821..eafaf64fd 100644
--- a/lib/bundler/installer.rb
+++ b/lib/bundler/installer.rb
@@ -164,11 +164,18 @@ module Bundler
     def install(options)
       load_plugins
       force = options["force"]
-      jobs = 1
-      jobs = [Bundler.settings[:jobs].to_i, 1].max if can_install_in_parallel?
       install_in_parallel jobs, options[:standalone], force
     end

+    def jobs
+      return 1 unless can_install_in_parallel?
+      if set_jobs = Bundler.settings[:jobs]
+        [set_jobs, 1].max
+      elsif Bundler.feature_flag.auto_config_jobs?
+        SharedHelpers.processor_count
+      end
+    end
+
     def load_plugins
       Bundler.rubygems.load_plugins

diff --git a/lib/bundler/settings.rb b/lib/bundler/settings.rb
index e0eb660a8..9efc2de8e 100644
--- a/lib/bundler/settings.rb
+++ b/lib/bundler/settings.rb
@@ -8,6 +8,7 @@ module Bundler

     BOOL_KEYS = %w[
       allow_offline_install
+      auto_config_jobs
       auto_install
       cache_all
       cache_all_platforms
@@ -35,6 +36,7 @@ module Bundler
     ].freeze

     NUMBER_KEYS = %w[
+      jobs
       redirect
       retry
       ssl_verify_mode
diff --git a/lib/bundler/shared_helpers.rb b/lib/bundler/shared_helpers.rb
index 39f0423f7..224a310c4 100644
--- a/lib/bundler/shared_helpers.rb
+++ b/lib/bundler/shared_helpers.rb
@@ -76,7 +76,7 @@ module Bundler

       keys.each {|key| ENV.delete(key) }

-      block.call
+      yield
     ensure
       keys.each {|key| ENV[key] = old_env[key] }
     end
@@ -111,13 +111,13 @@ module Bundler
     def filesystem_access(path, action = :write, &block)
       # Use block.call instead of yield because of a bug in Ruby 2.2.2
       # See https://github.com/bundler/bundler/issues/5341 for details
-      block.call(path.dup.untaint)
+      yield(path.dup.untaint)
     rescue Errno::EACCES
       raise PermissionError.new(path, action)
     rescue Errno::EAGAIN
       raise TemporaryResourceError.new(path, action)
     rescue Errno::EPROTO
-      raise VirtualProtocolError.new
+      raise VirtualProtocolError
     rescue Errno::ENOSPC
       raise NoSpaceOnDeviceError.new(path, action)
     rescue *[const_get_safely(:ENOTSUP, Errno)].compact
@@ -153,7 +153,7 @@ module Bundler

     def trap(signal, override = false, &block)
       prior = Signal.trap(signal) do
-        block.call
+        yield
         prior.call unless override
       end
     end
@@ -176,6 +176,13 @@ module Bundler
         "\nEither installing with `--full-index` or running `bundle update #{spec.name}` should fix the problem."
     end

+    def processor_count
+      require "etc"
+      Etc.nprocessors
+    rescue
+      1
+    end
+
   private

     def find_gemfile(order_matters = false)

@segiddins yeah, that looks about right to me. I was thinking we might need to borrow this CPU counter, but I'm not sure how it compares to the one inside etc: https://github.com/celluloid/celluloid/blob/f8e48978f4a299148df65ec2402aaabcdceb7607/lib/celluloid/internals/cpu_counter.rb

It looks like Etc.nprocessors might only be for *nix-y systems and might not work well with Windows, but I don't have a Windows machine to check.
The linked Celluloid implementation also has a special implementation for JRuby, but it looks like JRuby has natively implemented Etc::nprocessors.

I'm fine with the auto-discovery only working where Etc.nprocessors is implemented, since if it doesn't work the user can always just configure jobs and I'd rather we not introduce platform-specific code that we won't be testing on CI

I feel really bad about the state of our windows support, but I'm willing to admit that is unrelated to this ticket. :P Ising Rtc seems fine. 👍🏻

Sorry, just to clarify, this is a PR, not just an issue :)
Re:

let's use the value of jobs as given in 2.0, rather than subtracting 1.

Is master currently targeting 2.0, or are you saying this shouldn't be pulled into the current working version and should be reserved for just 2.0?
I agree that "default to nproc in 2.0" is a separate issue, and I can fix that separately if you'd like (using roughly what @segiddins shared above, unless he's already on it), but I think the "don't automatically n-1 the user-provided value" should go into whatever the upcoming version is, 2.0 or otherwise.

@tjschuck sorry, I did realize this is a PR! Thank you for sending it. 😁 I'm not comfortable with changing the way we handle JOBS in a minor release, especially given that it has been the way it is now for many years.
However, your argument is convincing, and I think we should change how we treat the JOBS setting in 2.0. The master branch is currently accepting changes for 2.0 via feature-flagging, so this is a reasonable place to send your PR.
I am also suggesting that, along with changing how we handle JOBS, it should default directly to nproc in 2.0. If you want to implement that as well, that would be :100:.

Please see https://github.com/bundler/bundler/pull/5986 for an alternative implementation

I would just like to point out how supremely infuriating it is to learn that bundler takes an argument where I very clearly specify a number, and then says "no, you don't actually want that number, what you really want is that number minus one, because REASONS! oh, but not really because I'm not even telling you that I'm doing this!!!"

@swrobel really? you came here to be mad about something that we already agree is bad, and already fixed six months ago?
Additionally, your tone here is outside what's allowed by our code of conduct. Please stop, so we won't have to take any enforcement action. Thanks.

I just read your entire code of conduct, republished here below:

The use of sexualized language or imagery and unwelcome sexual attention or advances, including when simulated online.
Trolling, insulting/derogatory comments, and personal or political attacks.
Casual mention of slavery or indentured servitude and/or false comparisons of one’s occupation or situation to slavery. Please consider using or asking about alternate terminology when referring to such metaphors in technology.
Making light of/making mocking comments about trigger warnings and content warnings.
Public or private harassment, deliberate intimidation, or threats.
Publishing others’ private information, such as a physical or electronic address, without explicit permission. This includes any sort of “outing” of any aspect of someone’s identity without their consent.
Publishing screenshots or quotes, especially from identity channels, without all quoted users’ explicit consent.
Publishing or telling others that a member belongs to a particular identity channel without asking their consent first.
Publishing of non-harassing private communication.
Any of the above even when presented as “ironic” or “joking”.
Any attempt to present “reverse-ism” versions of the above as violations. Examples of reverse-isms are “reverse racism”, “reverse sexism”, “heterophobia”, and “cisphobia”.
Unsolicited explanations under the assumption that someone doesn’t already know it. Ask before you teach! Don’t assume what people’s knowledge gaps are.
Feigning or exaggerating surprise when someone admits to not knowing something.
“Well-actuallies”
Other conduct which could reasonably be considered inappropriate in a professional or community setting.

Not sure how any of what I said could possibly be considered in violation of that. Did I somehow make a casual mention of slavery or indentured servitude? 😂
Sorry man, I was really annoyed because I was late to this party. I apologize for venting here.

@swrobel I appreciate the apology, and I understand that software can definitely be frustrating when it behaves in unexpected and undesired ways.
Since you seem to have missed it completely, let me reproduce the exact part of the code of conduct that you were violating:

Examples of behavior that contributes to creating a positive environment include:
Using welcoming and inclusive language.
Being respectful of differing viewpoints and experiences.
Gracefully accepting constructive feedback.
Focusing on what is best for the community.
Showing empathy and kindness towards other community members.

Responding to a warning with "did I somehow mention slavery 😂" counts as doubling down, so you're getting a 24 hour block. Any future violations will result in a permanent block.

This is a perfect example of someone letting the tiniest bit of power go to their head.


[New Game] : Catch Craze

PR Description 📜
In Catch Craze, you control a basket at the bottom of the screen, aiming to catch falling objects. The game gets progressively harder as you score more points, with objects falling faster and spawning more frequently. The goal is to score as many points as possible before the time runs out.
Fixes #4698

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots

Thank you soo much for contributing to our repository 💗

@ishita-43 please review my last pull request please

Thank you @aditya-bhaumik ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

@ishita-43 i have resolved the conflicts please review and merge my pull request please

@kunjgit i have resolved the conflicts can you please merge it

Thank you  @aditya-bhaumik , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


Give landing page mobile design a more appealing layout

Currently the landing page mobile design is notably lacking behind the desktop version due to the extra space created by the profile image. Find a way to make the space fit.

Willing to work on this issue


Check and update searchIndex when restarting dataNode if necessary

Description：

The searchIndex for some regions may be smaller than the safelyDeletedSearchIndex when the node is restarted, which means that the data of the current node is not flushed by the wal, but has been synchronized to other nodes. At this point, different replicas have been inconsistent and cannot be automatically recovered.

Solution：

To prevent subsequent logs from marking smaller searchIndex and exacerbating the inconsistency, we manually set the searchIndex to safelyDeletedSearchIndex here to reduce the impact of this problem in the future

Codecov Report

Merging #11510 (152f54b) into master (58d3a12) will increase coverage by 0.00%.
Report is 1 commits behind head on master.
The diff coverage is 55.55%.

@@            Coverage Diff            @@
##             master   #11510   +/-   ##
=========================================
  Coverage     49.00%   49.01%
- Complexity    24700    24708    +8
=========================================
  Files          2777     2777
  Lines        173854   173863    +9
  Branches      20814    20815    +1
=========================================
+ Hits          85192    85212   +20
+ Misses        88662    88651   -11

Files
Coverage Δ

...he/iotdb/consensus/iot/IoTConsensusServerImpl.java
44.93% <55.55%> (+0.20%)
:arrow_up:

... and 9 files with indirect coverage changes
:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!


Update setup.py to accomodate pip 20+

This fixes a problem with the newest version of pip:
Traceback (most recent call last):
  File "scrapy-selenium/setup.py", line 5, in <module>
    from pip.download import PipSession
ModuleNotFoundError: No module named 'pip.download'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "scrapy-selenium/setup.py", line 10, in <module>
    from pip._internal.download import PipSession
ModuleNotFoundError: No module named 'pip._internal.download'

@clemfromspace
This pip issue is causing major install problems on all softwares using scrapy-selenium as a pip requirement.
Can you merge this patch or change setup.py to use static install_requires field (as it should be the case actually...) ?
Merci beaucoup !


[Ruleset] Single rule override in a managed ruleset disables all other rules

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
terraform -v
Terraform v1.1.3
on darwin_amd64

provider registry.terraform.io/cloudflare/cloudflare v3.7.0
provider registry.terraform.io/hashicorp/aws v3.72.0
provider registry.terraform.io/hashicorp/http v2.1.0
provider registry.terraform.io/tchupp/env v0.0.2

Affected resource(s)
cloudflare_ruleset
Terraform configuration files
resource "cloudflare_ruleset" "terraform_managed_resource_8313e85ab7164e90adfaee5254de6322" {
  description = "Cloudflare Managed WAF ruleset"
  kind        = "zone"
  name        = "Managed WAF"
  phase       = "http_request_firewall_managed"
  zone_id     = "94691220711a494300a5b3021d0a8443"
  rules {
    action      = "execute"
    description = "Execute Cloudflare Managed Ruleset on my zone-level phase entry point ruleset"
    enabled     = true
    expression  = "true"
    # id          = "db6a5a81d2a14d92be019b27852c227e"
    # ref         = "db6a5a81d2a14d92be019b27852c227e"
    # version     = "1"
    action_parameters {
      overrides {
        rules {
          action  = "log"
          enabled = true
          id      = "0f2da91cec674eb58006929e824b817c"
        }
        rules {
          action  = "log"
          enabled = true
          id      = "81718f38edde45a58298189e113e4f59"
        }
      }
      id      = "efb7b8c949ac4650a09736fc376e9aee"
      version = "latest"
    }
  }
}

Debug output
PLAN:
-----------------------------------------------------: timestamp=2022-01-18T16:08:37.257Z
2022-01-18T16:08:37.257Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:08:37 [DEBUG] Read CloudflareZone Settings: &cloudflare.ZoneSettingResponse{Response:cloudflare.Response{Success:true, Errors:[]cloudflare.ResponseInfo{}, Messages:[]cloudflare.ResponseInfo{}}, Result:[]cloudflare.ZoneSetting{cloudflare.ZoneSetting{ID:"0rtt", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"advanced_ddos", Editable:false, ModifiedOn:"", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"always_online", Editable:true, ModifiedOn:"2021-07-27T14:37:08.842655Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"always_use_https", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"automatic_https_rewrites", Editable:true, ModifiedOn:"2021-07-27T14:37:09.101991Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"brotli", Editable:true, ModifiedOn:"2021-07-27T14:37:08.403736Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"browser_cache_ttl", Editable:true, ModifiedOn:"2021-07-27T14:37:08.870975Z", Value:14400, TimeRemaining:0}, cloudflare.ZoneSetting{ID:"browser_check", Editable:true, ModifiedOn:"2021-07-27T14:37:09.011391Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"cache_level", Editable:true, ModifiedOn:"2021-07-27T14:37:08.197261Z", Value:"aggressive", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"challenge_ttl", Editable:true, ModifiedOn:"2021-07-27T14:37:08.687736Z", Value:1800, TimeRemaining:0}, cloudflare.ZoneSetting{ID:"ciphers", Editable:true, ModifiedOn:"", Value:[]interface {}{}, TimeRemaining:0}, cloudflare.ZoneSetting{ID:"cname_flattening", Editable:true, ModifiedOn:"", Value:"flatten_at_root", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"development_mode", Editable:true, ModifiedOn:"2021-07-27T14:37:09.038731Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"early_hints", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"edge_cache_ttl", Editable:true, ModifiedOn:"", Value:7200, TimeRemaining:0}, cloudflare.ZoneSetting{ID:"email_obfuscation", Editable:true, ModifiedOn:"2021-07-27T14:37:08.891936Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"filter_logs_to_cloudflare", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"hotlink_protection", Editable:true, ModifiedOn:"2021-07-27T14:37:08.299883Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"http2", Editable:true, ModifiedOn:"", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"http3", Editable:true, ModifiedOn:"2021-07-27T14:37:09.118323Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"ip_geolocation", Editable:true, ModifiedOn:"2021-07-27T14:37:08.511741Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"ipv6", Editable:true, ModifiedOn:"2021-08-09T14:19:57.083527Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"log_to_cloudflare", Editable:true, ModifiedOn:"", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"max_upload", Editable:true, ModifiedOn:"2021-08-18T06:12:13.970271Z", Value:500, TimeRemaining:0}, cloudflare.ZoneSetting{ID:"min_tls_version", Editable:true, ModifiedOn:"", Value:"1.2", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"minify", Editable:true, ModifiedOn:"2021-07-27T14:37:08.338596Z", Value:map[string]interface {}{"css":"off", "html":"off", "js":"off"}, TimeRemaining:0}, cloudflare.ZoneSetting{ID:"mirage", Editable:true, ModifiedOn:"2021-07-27T14:37:08.916457Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"mobile_redirect", Editable:true, ModifiedOn:"", Value:map[string]interface {}{"mobile_subdomain":interface {}(nil), "status":"off", "strip_uri":false}, TimeRemaining:0}, cloudflare.ZoneSetting{ID:"opportunistic_encryption", Editable:true, ModifiedOn:"2021-07-27T14:37:08.737619Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"opportunistic_onion", Editable:true, ModifiedOn:"2021-07-27T14:37:08.219545Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"orange_to_orange", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"origin_error_page_pass_thru", Editable:true, ModifiedOn:"2021-07-27T14:37:08.710318Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"polish", Editable:true, ModifiedOn:"2021-07-27T14:37:08.048877Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"prefetch_preload", Editable:true, ModifiedOn:"2021-07-27T14:37:08.936680Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"privacy_pass", Editable:true, ModifiedOn:"2021-07-27T14:37:08.586361Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"proxy_read_timeout", Editable:true, ModifiedOn:"2021-08-12T13:37:16.350930Z", Value:"900", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"pseudo_ipv4", Editable:true, ModifiedOn:"2021-07-27T14:37:08.809173Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"response_buffering", Editable:true, ModifiedOn:"2021-07-27T14:37:08.358612Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"rocket_loader", Editable:true, ModifiedOn:"2021-07-27T14:37:08.607404Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"security_header", Editable:true, ModifiedOn:"", Value:map[string]interface {}{"strict_transport_security":map[string]interface {}{"enabled":false, "include_subdomains":false, "max_age":0, "nosniff":false, "preload":false}}, TimeRemaining:0}, cloudflare.ZoneSetting{ID:"security_level", Editable:true, ModifiedOn:"2021-07-27T14:37:08.381710Z", Value:"high", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"server_side_exclude", Editable:true, ModifiedOn:"2021-07-27T14:37:08.760998Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"sort_query_string_for_cache", Editable:true, ModifiedOn:"2021-07-27T14:37:08.423667Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"ssl", Editable:true, ModifiedOn:"2021-07-27T14:37:08.783511Z", Value:"strict", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"tls_1_2_only", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"tls_1_3", Editable:true, ModifiedOn:"", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"tls_client_auth", Editable:true, ModifiedOn:"2021-07-27T14:37:08.447219Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"true_client_ip_header", Editable:true, ModifiedOn:"2021-07-27T14:37:08.091382Z", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"visitor_ip", Editable:true, ModifiedOn:"", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"waf", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"webp", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"websockets", Editable:true, ModifiedOn:"2021-07-27T14:37:08.318131Z", Value:"on", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"binary_ast", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"h2_prioritization", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"image_resizing", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"early_hints", Editable:true, ModifiedOn:"", Value:"off", TimeRemaining:0}, cloudflare.ZoneSetting{ID:"universal_ssl", Editable:true, ModifiedOn:"", Value:"on", TimeRemaining:0}}}: timestamp=2022-01-18T16:08:37.257Z
2022-01-18T16:08:37.257Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:08:37 [WARN] Value not in schema returned from API zone settings (is it new?) - "advanced_ddos" : "on": timestamp=2022-01-18T16:08:37.257Z
2022-01-18T16:08:37.257Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:08:37 [WARN] Value not in schema returned from API zone settings (is it new?) - "edge_cache_ttl" : 7200: timestamp=2022-01-18T16:08:37.257Z
2022-01-18T16:08:37.257Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:08:37 [DEBUG] Flattened Cloudflare Zone Settings: map[string]interface {}{"always_online":"on", "always_use_https":"off", "automatic_https_rewrites":"off", "binary_ast":"off", "brotli":"off", "browser_cache_ttl":14400, "browser_check":"on", "cache_level":"aggressive", "challenge_ttl":1800, "ciphers":[]interface {}{}, "cname_flattening":"flatten_at_root", "development_mode":"off", "early_hints":"off", "email_obfuscation":"on", "filter_logs_to_cloudflare":"off", "h2_prioritization":"off", "hotlink_protection":"off", "http2":"on", "http3":"on", "image_resizing":"off", "ip_geolocation":"on", "ipv6":"off", "log_to_cloudflare":"on", "max_upload":500, "min_tls_version":"1.2", "minify":[]interface {}{map[string]interface {}{"css":"off", "html":"off", "js":"off"}}, "mirage":"off", "mobile_redirect":[]interface {}{map[string]interface {}{"mobile_subdomain":interface {}(nil), "status":"off", "strip_uri":false}}, "opportunistic_encryption":"off", "opportunistic_onion":"on", "orange_to_orange":"off", "origin_error_page_pass_thru":"off", "polish":"off", "prefetch_preload":"off", "privacy_pass":"on", "proxy_read_timeout":"900", "pseudo_ipv4":"off", "response_buffering":"off", "rocket_loader":"off", "security_header":[]interface {}{map[string]interface {}{"enabled":false, "include_subdomains":false, "max_age":0, "nosniff":false, "preload":false}}, "security_level":"high", "server_side_exclude":"on", "sort_query_string_for_cache":"off", "ssl":"strict", "tls_1_2_only":"off", "tls_1_3":"on", "tls_client_auth":"on", "true_client_ip_header":"off", "universal_ssl":"on", "visitor_ip":"on", "waf":"off", "webp":"off", "websockets":"on", "zero_rtt":"off"}: timestamp=2022-01-18T16:08:37.257Z
2022-01-18T16:08:37.257Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:08:37 [DEBUG] Flattened Cloudflare Read Only Zone Settings: []string{"advanced_ddos"}: timestamp=2022-01-18T16:08:37.257Z
2022-01-18T16:08:37.269Z [WARN]  Provider "registry.terraform.io/cloudflare/cloudflare" produced an invalid plan for module.zone_example_net.cloudflare_zone_settings_override.default[0], but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .settings[0].mobile_redirect: block count in plan (1) disagrees with count in config (0)
      - .settings[0].security_header: block count in plan (1) disagrees with count in config (0)
2022-01-18T16:08:37.272Z [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-01-18T16:08:37.274Z [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.7.0/linux_amd64/terraform-provider-cloudflare_v3.7.0 pid=391
2022-01-18T16:08:37.274Z [DEBUG] provider: plugin exited
2022-01-18T16:08:37.292Z [INFO]  backend/local: plan operation completed
2022-01-18T16:08:37.293Z [INFO]  backend/local: writing plan output to: .terraform/plan

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

  # cloudflare_ruleset.terraform_managed_resource_8313e85ab7164e90adfaee5254de6322 has changed
  ~ resource "cloudflare_ruleset" "terraform_managed_resource_8313e85ab7164e90adfaee5254de6322" {
        id          = "2237201281764c428f254c4593003f68"
        name        = "Managed WAF"
        # (4 unchanged attributes hidden)

      ~ rules {
            id          = "62cf64b830f74eedbcf0663ec06e8ebc"
            # (4 unchanged attributes hidden)

          ~ action_parameters {
                id        = "efb7b8c949ac4650a09736fc376e9aee"
              + products  = []
              + rules     = {}
              + rulesets  = []
                # (2 unchanged attributes hidden)

                # (1 unchanged block hidden)
            }
        }
    }

Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include actions to undo or respond to these changes.

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # cloudflare_ruleset.terraform_managed_resource_8313e85ab7164e90adfaee5254de6322 will be updated in-place
  ~ resource "cloudflare_ruleset" "terraform_managed_resource_8313e85ab7164e90adfaee5254de6322" {
        id          = "2237201281764c428f254c4593003f68"
        name        = "Managed WAF"
        # (4 unchanged attributes hidden)

      ~ rules {
            id          = "62cf64b830f74eedbcf0663ec06e8ebc"
            # (4 unchanged attributes hidden)

          ~ action_parameters {
                id        = "efb7b8c949ac4650a09736fc376e9aee"
                # (5 unchanged attributes hidden)

              ~ overrides {
                    # (1 unchanged attribute hidden)

                  + rules {
                      + action  = "log"
                      + enabled = true
                      + id      = "ae20608d93b94e97988db1bbc12cf9c8"
                    }
                    # (2 unchanged blocks hidden)
                }
            }
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.
╷
│ Warning: Experimental feature "module_variable_optional_attrs" is active
│
│   on modules/zone/versions.tf line 3, in terraform:
│    3:   experiments = [module_variable_optional_attrs]
│
│ Experimental features are subject to breaking changes in future minor or patch releases, based on feedback.
│
│ If you have feedback on the design of this feature, please open a GitHub issue to discuss it.
│
│ (and 40 more similar warnings elsewhere)

APPLY:
2022-01-18T16:11:37.751Z [WARN]  Provider "registry.terraform.io/cloudflare/cloudflare" produced an invalid plan for cloudflare_ruleset.terraform_managed_resource_8313e85ab7164e90adfaee5254de6322, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .rules[0].action_parameters[0].ruleset: planned value cty.StringVal("") for a non-computed attribute
      - .rules[0].action_parameters[0].rulesets: planned value cty.SetValEmpty(cty.String) for a non-computed attribute
      - .rules[0].action_parameters[0].increment: planned value cty.NumberIntVal(0) for a non-computed attribute
      - .rules[0].action_parameters[0].products: planned value cty.SetValEmpty(cty.String) for a non-computed attribute
      - .rules[0].action_parameters[0].rules: planned value cty.MapValEmpty(cty.String) for a non-computed attribute
      - .rules[0].action_parameters[0].overrides[0].action: planned value cty.StringVal("") for a non-computed attribute
      - .rules[0].action_parameters[0].overrides[0].enabled: planned value cty.False for a non-computed attribute
      - .rules[0].action_parameters[0].overrides[0].rules[0].score_threshold: planned value cty.NumberIntVal(0) for a non-computed attribute
      - .rules[0].action_parameters[0].overrides[0].rules[0].sensitivity_level: planned value cty.StringVal("") for a non-computed attribute
      - .rules[0].action_parameters[0].overrides[0].rules[1].sensitivity_level: planned value cty.StringVal("") for a non-computed attribute
      - .rules[0].action_parameters[0].overrides[0].rules[1].score_threshold: planned value cty.NumberIntVal(0) for a non-computed attribute
cloudflare_ruleset.terraform_managed_resource_8313e85ab7164e90adfaee5254de6322: Modifying... [id=2237201281764c428f254c4593003f68]
2022-01-18T16:11:37.754Z [INFO]  Starting apply for cloudflare_ruleset.terraform_managed_resource_8313e85ab7164e90adfaee5254de6322
2022-01-18T16:11:37.755Z [DEBUG] cloudflare_ruleset.terraform_managed_resource_8313e85ab7164e90adfaee5254de6322: applying the planned Update change
2022-01-18T16:11:37.761Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:11:37 [DEBUG] unknown key encountered in buildRulesetRulesFromResource for action parameters: products: timestamp=2022-01-18T16:11:37.761Z
2022-01-18T16:11:37.762Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:11:37 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
PUT /client/v4/zones/94691220711a494300a5b3021d0a8443/rulesets/2237201281764c428f254c4593003f68 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.1.3 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.7.0
Content-Length: 545
Authorization: Bearer D-s6q-jJjYPzwZYP4iI89W--GR_oOBbACoZBgBPp
Content-Type: application/json
Accept-Encoding: gzip

{
 "description": "Cloudflare Managed WAF ruleset",
 "rules": [
  {
   "action": "execute",
   "action_parameters": {
    "id": "efb7b8c949ac4650a09736fc376e9aee",
    "overrides": {
     "enabled": false,
     "rules": [
      {
       "id": "0f2da91cec674eb58006929e824b817c",
       "action": "log",
       "enabled": true
      },
      {
       "id": "81718f38edde45a58298189e113e4f59",
       "action": "log",
       "enabled": true
      },
      {
       "id": "ae20608d93b94e97988db1bbc12cf9c8",
       "action": "log",
       "enabled": true
      }
     ]
    },
    "version": "latest"
   },
   "expression": "true",
   "description": "Execute Cloudflare Managed Ruleset on my zone-level phase entry point ruleset",
   "enabled": true
  }
 ]
}
-----------------------------------------------------: timestamp=2022-01-18T16:11:37.762Z
2022-01-18T16:11:39.736Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:11:39 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6cf919a929285790-IAD
Content-Type: application/json; charset=UTF-8
Date: Tue, 18 Jan 2022 16:11:39 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU56Rb8iNWZVUvXhqkC64fYN6ZT; SameSite=Lax; path=/; expires=Tue, 18-Jan-22 18:41:40 GMT; HttpOnly
Set-Cookie: __cfruid=10e115dbf56ed28a25293305082941f7a16f1500-1642522299; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 875
X-Version: 4856-0d1141c75d51

{
  "result": {
    "id": "2237201281764c428f254c4593003f68",
    "name": "Managed WAF",
    "description": "Cloudflare Managed WAF ruleset",
    "source": "firewall_managed",
    "kind": "zone",
    "version": "3",
    "rules": [
      {
        "id": "bde910c6136d46a4a69683665a8230a9",
        "version": "1",
        "action": "execute",
        "action_parameters": {
          "id": "efb7b8c949ac4650a09736fc376e9aee",
          "version": "latest",
          "overrides": {
            "enabled": false,
            "rules": [
              {
                "id": "0f2da91cec674eb58006929e824b817c",
                "action": "log",
                "enabled": true
              },
              {
                "id": "81718f38edde45a58298189e113e4f59",
                "action": "log",
                "enabled": true
              },
              {
                "id": "ae20608d93b94e97988db1bbc12cf9c8",
                "action": "log",
                "enabled": true
              }
            ]
          }
        },
        "expression": "true",
        "description": "Execute Cloudflare Managed Ruleset on my zone-level phase entry point ruleset",
        "last_updated": "2022-01-18T16:11:39.155671Z",
        "ref": "bde910c6136d46a4a69683665a8230a9",
        "enabled": true
      }
    ],
    "last_updated": "2022-01-18T16:11:39.155671Z",
    "phase": "http_request_firewall_managed"
  },
  "success": true,
  "errors": [],
  "messages": []
}

-----------------------------------------------------: timestamp=2022-01-18T16:11:39.735Z
2022-01-18T16:11:39.736Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:11:39 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
GET /client/v4/zones/94691220711a494300a5b3021d0a8443/rulesets/2237201281764c428f254c4593003f68 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.1.3 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.7.0
Authorization: Bearer D-s6q-jJjYPzwZYP4iI89W--GR_oOBbACoZBgBPp
Content-Type: application/json
Accept-Encoding: gzip

-----------------------------------------------------: timestamp=2022-01-18T16:11:39.736Z
2022-01-18T16:11:40.949Z [INFO]  provider.terraform-provider-cloudflare_v3.7.0: 2022/01/18 16:11:40 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6cf919b56a9d8232-IAD
Content-Type: application/json; charset=UTF-8
Date: Tue, 18 Jan 2022 16:11:40 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU56Rb8iNWZVUvXhr5bS6HBMK6V; SameSite=Lax; path=/; expires=Tue, 18-Jan-22 18:41:41 GMT; HttpOnly
Set-Cookie: __cfruid=aa86a692c4d28008a4768214b0a4c0483d930cc6-1642522300; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 146
X-Version: 4856-0d1141c75d51

{
  "result": {
    "id": "2237201281764c428f254c4593003f68",
    "name": "Managed WAF",
    "description": "Cloudflare Managed WAF ruleset",
    "source": "firewall_managed",
    "kind": "zone",
    "version": "3",
    "rules": [
      {
        "id": "bde910c6136d46a4a69683665a8230a9",
        "version": "1",
        "action": "execute",
        "action_parameters": {
          "id": "efb7b8c949ac4650a09736fc376e9aee",
          "version": "latest",
          "overrides": {
            "enabled": false,
            "rules": [
              {
                "id": "0f2da91cec674eb58006929e824b817c",
                "action": "log",
                "enabled": true
              },
              {
                "id": "81718f38edde45a58298189e113e4f59",
                "action": "log",
                "enabled": true
              },
              {
                "id": "ae20608d93b94e97988db1bbc12cf9c8",
                "action": "log",
                "enabled": true
              }
            ]
          }
        },
        "expression": "true",
        "description": "Execute Cloudflare Managed Ruleset on my zone-level phase entry point ruleset",
        "last_updated": "2022-01-18T16:11:39.155671Z",
        "ref": "bde910c6136d46a4a69683665a8230a9",
        "enabled": true
      }
    ],
    "last_updated": "2022-01-18T16:11:39.155671Z",
    "phase": "http_request_firewall_managed"
  },
  "success": true,
  "errors": [],
  "messages": []
}

-----------------------------------------------------: timestamp=2022-01-18T16:11:40.948Z
2022-01-18T16:11:40.950Z [WARN]  Provider "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" produced an unexpected new value for cloudflare_ruleset.terraform_managed_resource_8313e85ab7164e90adfaee5254de6322, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .rules[0].id: was cty.StringVal("62cf64b830f74eedbcf0663ec06e8ebc"), but now cty.StringVal("bde910c6136d46a4a69683665a8230a9")
      - .rules[0].action_parameters[0].overrides[0].rules[2].score_threshold: was null, but now cty.NumberIntVal(0)
      - .rules[0].action_parameters[0].overrides[0].rules[2].sensitivity_level: was null, but now cty.StringVal("")
cloudflare_ruleset.terraform_managed_resource_8313e85ab7164e90adfaee5254de6322: Modifications complete after 3s [id=2237201281764c428f254c4593003f68]
2022-01-18T16:11:40.952Z [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-01-18T16:11:40.956Z [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.7.0/linux_amd64/terraform-provider-cloudflare_v3.7.0 pid=213
2022-01-18T16:11:40.956Z [DEBUG] provider: plugin exited
2022-01-18T16:11:40.963Z [DEBUG] Uploading remote state to S3: {
  Body: buffer(0xc002d74fc0),
  Bucket: "xxx",
  ContentLength: 143344,
  ContentType: "application/json",
  Key: "cloudflare-terraform:/test/terraform.tfstate"
}

2022-01-18T16:11:41.729Z [DEBUG] [aws-sdk-go]
╷
│ Warning: Experimental feature "module_variable_optional_attrs" is active
│
│   on modules/zone/versions.tf line 3, in terraform:
│    3:   experiments = [module_variable_optional_attrs]
│
│ Experimental features are subject to breaking changes in future minor or patch releases, based on feedback.
│
│ If you have feedback on the design of this feature, please open a GitHub issue to discuss it.
│
│ (and 40 more similar warnings elsewhere)
╵

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Panic output
No response
Expected output
We expect only the override to be applied
Actual output
All rules that were enabled by default in the ruleset get disabled
Steps to reproduce

Add a new override to an existing cloudflare managed ruleset rule
terraform apply
All rules in the ruleset will get disabled

Additional factoids
No response
References
No response

IIRC, this is an issue with "enabled": false in the overrides disabling all the others because the value was modified at one time or another. From memory, the solution is that you should now explicitly send it set the true since the value has been modified (aka, it doesn’t happen if you haven’t changed it previously).
@vences do you recall?

(if it is, this is a known thing with using booleans as zero, optional and default values in Terraform)

@jacobbednarz this is correct, setting enabled: true under overrides helped.
However, it has now enabled all the rules. How can I use default cloudflare rule settings (the ones managed by CF security team) combined with couple custom overrides?
Basically, now I have two options:

Either use default cloudflare recommended settings with no overrides at all
Apply custom overrides while enabling all the rules (even the rules that are recommended to be disabled by Cloudflare)

Any way out of this misery ? :)

@jacobbednarz yes it has been highlighted here and you even sent an enhancement to the plugin sdk here
As soon as it is explicitly set-up you cannot revert to the default configuration unfortunately. Only way for now is to delete and recreate the rulesets configuration without the enabled.

Its worth noting in this thread, that the implications to the end user can be somewhat catastrophic. As was mentioned here, the first time we applied our template w/o including enable , the ruleset was created and everything worked. But on subsequent deployments of the same template enabled: false was injected. We didnt catch this and our Production WAF was disabled for months. To further complicate matters, the Portal UI clearly shows everything is enabled. It wasnt until I queried the rulesets via the API that I discovered why we hadnt seen a single rule trip. Its no fun having to explain to your CISO that your shiny new WAF has been off for months. Its even less fun to explain that Cloudflare knew this was an issue.


fix shatter panic and spelling mistake

Hi @IvoryDuke
This work of yours is thoroughly impressive and I have learned a lot from studying it.
I will use some of the concepts for my own (non-game) editor.
I noticed that there is a panic every time I do the shatter operation. I am not sure if I am doing something wrong, or if its an issue with the shatter tool itself or just the item selection logic.
This MR does 2 things:

Fixes spelling mistake "whever" -> "whether"
In item_selector.rs:

@@ -255,8 +255,12 @@ where
             }
         };

-        let value = Some(self.items[self.depth]);
-        self.previous = value;
-        value
+        if let Position::None = self.depth {
+            None
+        } else {
+            let value = Some(self.items[self.depth]);
+            self.previous = value;
+            value
+        }

If you want me to split it into two MR's I can do that.

Actually given the conflicts I will redo this and make them separate PRs':
https://github.com/IvoryDuke/HillVacuum/pull/6
https://github.com/IvoryDuke/HillVacuum/pull/7


search field

Implement Search Field
Fix and debug images bugs: undefinded, remove spaces, skip not found images
cleanup the install

Yes I saw the email I on on the design that's why I put it there.
So which icon should we use?


Any way to specify time scale on the chart?

First of all... Thank you for this component... It's a simple component that serves a good purpose.
I am using it in my web page. But I am running into the issue of my candles being one sided on the chart when it loads.
Here is an example:

I know that in the TradingView API reference there is a way to provide the time scale of the chart. Or even to resize the chart with the candle data that it has.
But this is not available on your component. Would that be something that it could be made available?
I would try to take a swing at it, but I'm horrible with JS and the way Blazor interacts with it.
Also, another thing... I've noticed that when the price data is very small (over 3 decimal places) the price doesn't reflect in the price scale. Very small numbers are common in markets like crypto. Is that also something that can be addressed.
Thanks again for the work you've done.

Both issues have been addressed. You can upgrade to v1.0.5 to take advantage of them.
To change the decimal precision in the price chart you can set the new chart option RightPriceScaleDecimalPrecision to the amount of decimals you want.
The empty space will automatically no longer occur, as the chart will auto fit immidiately after creation.
Additionally, you can pass in your own arguments directly into the js library with the following new properties in ChartOptions:
// -- Custom definitions
/// <summary>
/// Options defined here will be added to the chart when calling createChart()
/// Example usage:
/// options.CustomChartDefinitions["height"] = 500;
/// </summary>
public Dictionary<string, dynamic> CustomChartDefinitions { get; set; } = new();

/// <summary>
/// Options defined here will be added to the chart when calling addCandlestickSeries()
/// Example usage:
/// options.CustomCandleSeriesDefinitions["borderVisible"] = false;
/// </summary>
public Dictionary<string, dynamic> CustomCandleSeriesDefinitions { get; set; } = new();

/// <summary>
/// Options defined here will be added to the chart when calling addHistogramSeries()
/// Example usage:
/// options.CustomVolumeSeriesDefinitions["color"] = "#26a69a";
/// </summary>
public Dictionary<string, dynamic> CustomVolumeSeriesDefinitions { get; set; } = new();

Both issues have been addressed. You can upgrade to v1.0.5 to take advantage of them.
To change the decimal precision in the price chart you can set the new chart option RightPriceScaleDecimalPrecision to the amount of decimals you want.
The empty space will automatically no longer occur, as the chart will auto fit immidiately after creation.
Additionally, you can pass in your own arguments directly into the js library with the following new properties in ChartOptions:
// -- Custom definitions
/// <summary>
/// Options defined here will be added to the chart when calling createChart()
/// Example usage:
/// options.CustomChartDefinitions["height"] = 500;
/// </summary>
public Dictionary<string, dynamic> CustomChartDefinitions { get; set; } = new();

/// <summary>
/// Options defined here will be added to the chart when calling addCandlestickSeries()
/// Example usage:
/// options.CustomCandleSeriesDefinitions["borderVisible"] = false;
/// </summary>
public Dictionary<string, dynamic> CustomCandleSeriesDefinitions { get; set; } = new();

/// <summary>
/// Options defined here will be added to the chart when calling addHistogramSeries()
/// Example usage:
/// options.CustomVolumeSeriesDefinitions["color"] = "#26a69a";
/// </summary>
public Dictionary<string, dynamic> CustomVolumeSeriesDefinitions { get; set; } = new();

Wow... Thanks a million... Really appreciate this.

FYI... I just updated the package:
And I soon as I ran it, the chart doesn't show and I got this on the browser:

Here is what the debugger in VSCode tells me:
`Microsoft.AspNetCore.Components.Server.Circuits.CircuitHost: Error: Unhandled exception in circuit 'btGu_4s3wHzMlZ-5Z_r1_wKO2viKgsB6DXFzFNfKGxo'.
Microsoft.JSInterop.JSException: error loading dynamically imported module
at Microsoft.JSInterop.JSRuntime.InvokeAsync[TValue](Int64 targetInstanceId, String identifier, Object[] args)
at TradingView.Blazor.ChartHelperInterop.LoadChart(ElementReference eleRef, ChartData data, ChartOptions options)
at TradingView.Blazor.TradingViewChart.LoadChartAsync(ChartData data, ChartOptions options)
at UI.Pages.Bot.Portfolio.LoadTradeViewChart(List1 orders) in /home/cyberyaga/Projects/ChigueteBotWeb/UI/Pages/Bot/Portfolio.razor:line 416    at UI.Pages.Bot.Portfolio.onRowClick(Account a) in /home/cyberyaga/Projects/ChigueteBotWeb/UI/Pages/Bot/Portfolio.razor:line 378    at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)    at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)


Thanks. Very helpful.

Exactly what i was looking for. Very helpful. Thanks....

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

ID: e84ae485-589a-39ae-215b-2a180e256847
Version Independent ID: 1e333459-27c2-0a15-e6f5-00dbc4e6b88f
Content: Clipping primitive - Mixed Reality Toolkit
Content Source: mrtk-unity/features/rendering/clipping-primitive.md
Product: mixed-reality
GitHub Login: @keveleigh
Microsoft Alias: kurtie

Appreciate the kind words!


Removed Firefox specific mousemove event listener

fixes #30

Whoops, this repo is only here for legacy purposes. I reproduced this PR in the monorepo


[FEATURE] Add VAT Calculator

Is your feature request related to a problem? Please describe.
I want to add a VAT Calculator.
Describe the solution you'd like
Described above.
Describe alternatives you've considered
Described above.
Additional context
Described above.

nice contribution mate 🎉


Move to travis-ci.com

Don't think this has been brought up before. It seems travis-ci.org will no longer be supported past October 1, 2018. https://docs.travis-ci.com/user/legacy-services-to-github-apps-migration-guide/

NVM, travis-ci will do it on their end.


Archive the second Twitter account: @reckful

Could also grab @Everland while at it

Tweets from  vicinitas.io, although the format differs slightly from what I got for the main account, but it might be because this data was free to get, whereas I paid for the @byron account
@playeverland_user_tweets.xlsx
@reckful_user_tweets.xlsx

Done. Tweets + videos + photos - all archived and available via twitter-api.reckful-archive.org


Support the docker builder

Build on docker for local testing

Yet to do:

Replace the two calls to snap with something easier to work with
Remove the MySQL availability checks or skip the package entirely
Skip installing 87956 versions of dotnetcoresdk
Add the docker tagging postprocessor


Add opt-in support to readonly /etc, also doc transient overlayfs for /etc

We want bootc to support both "generic, unlocked" systems that have persistent mutable state in /etc, as well as "sealed" systems that are only configured via bootc, and shouldn't have persistent mutable configuration.
(Similar, for /var, though in the general case for that I think people will instead want to allow-list at least some persistent paths, like the journal)

We have documented transient /etc.


Matrix library

Add a matrix library. We can include conepts learned in MAT223  and MAT224.

Here we would only construct a matrix and operations we could do on them, and not include transformations and other concepts we lernt. All these concepts would have a separate library similar to sorting and searching algorithms.

The matrix library has been started by @ismail-ahmed0149. There are still many features to add, and the current features can also be improved so keep editing it. Happy coding 😀

@ismail-ahmed0149
👋 Hi!
I have made some changes to the library. please refer to pull request #77  for further information. Happy coding 😀

We have prepared a basic library, so I am closing this issue. There are still many functions to be added. All these functions would be linked to their own feature requests and issues.


Logo.png is missing

Not a huge deal but the logo.png  referenced in new.py is missing from this repo, causing the streamlit run new.py command to fail.
It was easy enough to add my own logo.png to get things running but wanted to give you a heads up.

Thanks! I have added the logo tho. Closing this as done.


np.linalg.pinv not supported

Here is a link to what I think is the python sources for np.linalg:
https://github.com/numpy/numpy/blob/master/numpy/linalg/linalg.py
Other implementations:
https://github.com/TheAlgorithms/C-Sharp/blob/master/Algorithms/Numeric/Pseudoinverse/PseudoInverse.cs
https://github.com/accord-net/framework/blob/master/Sources/Accord.Math/Matrix/Matrix.Linear.Generated.cs#L298

It’s very necessary, by the way - I have a lab on it((


fix(config): improve emit skipped error message and ensure outDir always TS_JEST_OUT_DIR

Summary

Stuffs from outDir can cause LanguageService not emit any codes and run into emit skipped mode therefore setting internally outDir to TS_JEST_OUT_DIR always.

Improve emit skipped error message

Closes #2350
Test plan

Green CI
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information
N.A.

Pull Request Test Coverage Report for Build 564663636

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 93.622%

Totals

Change from base Build 564619370:
-0.02%

Covered Lines:
947

Relevant Lines:
977

💛  - Coveralls


Migrating (most) dependencies to vcpkg

This is based off my original work in the now closed PR #644 which contains a bit of discussion on the topic.
This PR represents a first step to making Cesium-Native available in vcpkg as a resource for others to fetch, inline with #248.  It should also reduce the maintenance burden of managing all those additional projects and configs inside the CMake build tree.
Summary of the changes
Migrate most of the /extern dependencies to be vcpkg based

CSPRNG isn't available in vcpkg, but examination of the source code suggests that it's only being used for random token generation where a PRNG should be sufficient.  I've replaced the code in fillWithRandomBytes.cpp with a pure C++ version using the STL.

if there's a strong argument for something stronger, I can look at improving the seed value, thought it should be noted that the previous UWP version seemed perfectly happy depending on a PRNG.
Also the backing API CSPRNG uses on Windows is now deprecated.

s2geometry is available in vcpkg, but only for non-windows platforms for some reason. cesium-native is building some custom subset of the codebase to avoid the OpenSSL dependency.  Given the choice between trying to fix the vcpkg port to work on windows and leaving this dependency in I opted for the latter. For now.

If Cesium decides to accept this PR and go this route, it would be pretty simple to fork the main VCPKG repository and put the customized version of s2geometry into the fork, which would eliminate the last /extern project dependency.

Modify the CI config to cache the vcpkg build artifacts
The vcpkg macro I've introduced builds the dependencies outside of the CMake buildtree (by default in ~/.ezvcpkg/<commit id>) and thus they're easy to cache.  This makes the aggregate cost of building your upstream dependencies on fall to zero both for CI builds and for developers after they've done a local "clean" because the external artifacts aren't built by the resulting Makefile / IDE project.  Because the dependency buildtree is also tied to the commit ID in VCPKG, It also means if developers want to try out new versions of specific dependencies, they can switch between those new dependencies and the current dependencies without having to rebuild them each time.
The current setup uses the project root CMakeCache.txt as a proxy for "dependencies have changed" so some false cache misses may still occur.  This could be fixed by pushing the vcpkg call into a vcpkg.cmake file that gets included, but this would require a little extra work to ensure that the ezvcpkg_fetch exported variables like EZVCPKG_DIR and CMAKE_TOOLCHAIN_FILE were then re-exported to the root scope.
You can see the impact of this change comparing an existing run from your current main branch with this PR branch build where the cache was fully populated.  I'm uncertain why the Visual Studio builds aren't seeing much benefit (not sure why), but the overall CI time has at least gone down by ~8 minutes, mostly due to longest running job MacOS now running substantially faster.
This change also eliminates the need for a target_link_libraries_system macro.  The issue here was that include paths inside the CMake root folder get treated as non-system by default.  By moving to vcpkg, and an out-of-tree build for the external dependencies, this problem goes away for everything except s2geometry, which can be handled explicitly by adding the SYSTEM directive to the target_include_directories declaration for that one project.
Because I'm depending on static libraries, I needed to set the set CMAKE_MSVC_RUNTIME_LIBRARY to MultiThreaded / MultiThreadedDebug to avoid runtime conflicts with the static external libraries we're linking, otherwise the main project uses MultiThreaded DLL by default and causes link time errors.  I'm currently only trying to target a static library version of Cesium-Native, but I suspect that with a bit of work both a shared and static version can be supported.
Changes / fixes required because of version differences
In a few cases, the version of a library in vcpkg was significantly newer than the one being used by Cesium, and rather than try to create a custom vcpkg fork right off the bat, I decided to try to deal with any problems caused by those changes inline.

I encountered an error with the fmt formatting of the rapidjson error enum, and had to add a specialization of the fmt::formatter struct for the rapidjson::ParseErrorCode type to correct it.  I'm uncertain if this is triggered by a version difference in fmt or rapidjson or what, but the addition of a CesiumUtility/Log.h header that includes the template specialization fixed the issue.
Similarly I encoutered an error in validateDracoMetadataAttribute with an implicit signed/unsigned conversion, which is probably traceable to some change in the draco library version.  I fixed it with a simple static cast, since it appears to be something that will be in the range of 1-4.  This could also probably be fixed by changing the signature of the receiving function, but I didn't want to try that initially as I didn't know what else might depend on the existing signature.
Added a cactch.hpp helper header to bridge the API difference between the prior extern version and the current vcpkg version of Catch2.
Added a cesium-sqlite3.h header to replace the one removed from the sqlite3 checkout

An alternative would be to just include the sqlite3.h header on the assumption that the dependency will always be coming from vcpkg, thus eliminating the need for a preprocessor macro. I'm not sure what the current use case is for supporting an alternative sqlite3 version would be unless some customers are already linking it and want to use the same version. For the static build this shouldn't be a problem though.

@kring I managed to get a PR merged to s2geometry that fixes the windows builds and I have another PR that updates the vcpkg version of s2geometry.
Once that's merged I should be able to update this PR to make all dependencies vcpkg based.

Awesome, thanks @jherico! We're slow to review this, but we haven't forgotten about it. Thanks for all your work on it!

@kring this is perplexing.  I managed to get s2geometry updated in vcpkg so that it builds on windows, and integrated that into the PR, moving the last submodule based dependency to vcpkg, BUT for some reason on the vs2019 version of the CI server the package built package isn't found by CMake.  I don't understand though why the CMake binary would behave differently because the target version of Visual Studio is different.
The only other problem I encountered was that one of the unit tests was failing because it seems to depend on the semantic meaning of certain s2 cell IDs, and at least one of them has changed.
I'll see if I can look closer at the VS2019 logs to try to determine why it's failing in the next couple days.

Huh I'm not sure @jherico. Could the GH Actions runner perhaps be caching something vcpkg-related? Total guess.

because it seems to depend on the semantic meaning of certain s2 cell IDs, and at least one of them has changed.

I'm really surprised S2 cell IDs would change. I don't see any mention of that in the changelog, at a glance. We'll have to investigate further.

@kring I think I figured it out.  This is an image from the page on the cell hierarchy:

Cell 5 is the one that's centered on the south pole, and the failing test was the one checking the longitude, which is basically a meaningless question.  I've commented out this test as well as another test for cell "b" which is centered on the north pole, but is also checking the "longitude".  This one wasn't failing, but again, it's a meaningless check and the implementation could change again, so this should avoid regressions (the latitude check for both is still there and the old tests are still present, but commented out with a note as to why).
There's another test that validates a cell centered on the international dateline, which evaluated as -180 degrees, but now is 180.  I've updated that test to use the absolute value of the cell longitude to prevent further content-free regressions.

Man, I really did not want to have to install VS2019 today, but here we are.  The VS2019 failure is because the s2geometry source code uses a "terse" static_assert, which is technically a C++17 feature, but s2geometry is set to C++14.  Every compiler except VS2019 doesn't care and allows terse static_assert anyway, but if VS2019 is a required target for cesium-native then I have to make sure that s2geometry is compliant.  I've got a PR for both s2geometry and vcpkg that should fix this.  I'm attempting a build of cesium-native off my vcpkg fork to see if corrects the problem as expected.  This also gave me some insight into some shortcomings for my ezvcpkg script which I've addressed in the embedded version in this repo and will work towards integrating into my main ezvcpkg repo.

Thank you so much for all your work!


Plugin without namespace not found

It seems that a plugin not in a namespace is not found.

I tested in my local system, it can be found even if without a namespace. you could create a simple github repo for me to reproduce this issue. thanks.

Indeed, i just had a local cache issue.


Run pipeline does not have a --reprocess flag, fix docs issue

Signed-off-by: echohack<EMAIL_ADDRESS>

LGTM


feat: Support SQLite as a source

TODO:

Update docs

Closes #108

I think the workflows don't have access to the repo secrets
packages/postgres test: ✘   (0 / 1)
packages/postgres test:
packages/postgres test:    FAIL  "query runs"
packages/postgres test:     connect ECONNREFUSED <IP_ADDRESS>:5432

Looks like you're right. I think it's because the PR is originating from a fork of the repo and secrets are disabled there by default. I'm going to look into this to see if there's an easy way around it.

I've run the tests locally and they all passed. We'll figure out the secrets access separately.
I've added some error handling so the SQLite errors get displayed fully in the query viewer on the page. Last piece is adding to the docs, then we're good to release it! 🎉

@hughess

I've added some error handling so the SQLite errors get displayed fully in the query viewer on the page. Last piece is adding to the docs, then we're good to release it! 🎉

Awesome. Thanks for the quick turnaround 😄


The readme example is not working with now dev

Describe the bug
I'm trying to implement the default example in the README. but when I access api/user on localhost I get an error msg (see logs section)
To Reproduce
this is a repo of my current state : https://github.com/wcastand/example_rust_now
Expected behavior
A clear and concise description of what you expected to happen.
Logs
~/Documents/rust/api master* 35s ❯ now dev
> Now CLI 16.5.2 dev (beta) — https://zeit.co/feedback/dev
> Ready! Available at http://localhost:3000
> Building now-rust@1.0.0:api/user.rs
downloading the rust toolchain
info: downloading installer
info: profile set to 'default'
info: updating existing rustup installation

Rust is installed now. Great!

To get started you need Cargo's bin directory ($HOME/.cargo/bin) in your PATH
environment variable. Next time you log in this will be done
automatically.

To configure your current shell run source $HOME/.cargo/env
installing openssl-devel...
failed to `yum install -y openssl-devel`
Error: spawn yum ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:264:19)
    at onErrorNT (internal/child_process.js:456:16)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {
  message: 'spawn yum ENOENT',
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn yum',
  path: 'yum',
  spawnargs: [ 'install', '-y', 'openssl-devel' ],
  stdout: null,
  stderr: null,
  failed: true,
  signal: null,
  cmd: 'yum install -y openssl-devel',
  timedOut: false,
  killed: false
}

Environment (please complete the following information):

rust [e.g. stable]
rust edition [e.g. 2018]
now-rust [e.g. 1.0.1]
OSX Mojave (10.14.6)

Hi @wcastand, this is a known issue, and is being tracked in #1 and #3, and #6.

Sorry about this, I didn't realised it was linked. my bad for the useless issue then :)


Edit Project button doesn't work

It looks like a angular issue, the ui-sref is Edit Project

noticed this earlier on it now

no longer an issue!

No longer an issue.


esp32_rtc: use small lock in arch/xtensa/src/esp32s2/esp32s2_rtc.c

Summary
esp32_rtc: use small lock in arch/xtensa/src/esp32s2/esp32s2_rtc.c
reason:
We would like to replace the big lock with a small lock.
Impact
esp32_rtc
Testing
ci

[Experimental Bot, please feedback here]
No, this PR does not fully meet the NuttX requirements as described.  Here's why:

Insufficient Summary:  The summary is too vague. It needs to explain why a smaller lock is desirable.  What problem does it solve? What are the benefits (e.g., performance improvement, reduced deadlock risk)?  How does the change exactly work?  Just saying "replace big lock with small lock" isn't enough detail.
Incomplete Impact Assessment: Simply stating "esp32_rtc" doesn't address the specific impact questions.  Consider each point (user impact, build impact, hardware impact, documentation, security, compatibility).  Even if the answer is "NO", explicitly state it for each item.
Missing Testing Details: "ci" is insufficient.  Specify the actual build host and target details (OS, architecture, board, configuration). Provide meaningful test logs that demonstrate the issue before the change and the improvement after the change.  What were you testing?  What were the results? Show concrete evidence that the change works and has the intended positive effect.  Just saying "ci" doesn't prove anything.

Example of a better Impact and Testing section:
Impact

Is new feature added? NO
Is existing feature changed? YES (The locking mechanism within the esp32_rtc driver is changed.)
Impact on user (will user need to adapt to change)? NO
Impact on build (will build process change)? NO
Impact on hardware (will arch(s) / board(s) / driver(s) change)? YES (This change specifically affects the esp32s2 architecture and the esp32_rtc driver)
Impact on documentation (is update required / provided)? NO
Impact on security (any sort of implications)?  NO (Assuming the smaller lock provides equivalent protection)
Impact on compatibility (backward/forward/interoperability)? NO
Anything else to consider?  Potentially improved performance due to reduced lock contention.

Testing
I confirm that changes are verified on local setup and works as intended:

Build Host(s): Linux (Ubuntu 20.04), x86_64, GCC 9.4.0
Target(s): esp32s2:esp32s2_saola_1

Testing logs before change:
# Demonstrate the problem before the change.  For example:
# Measured RTC access time: 10ms (showing high latency due to lock contention)
# or:
# Observed deadlock scenario when accessing RTC from multiple threads.
<Insert actual logs showing the issue being addressed>

Testing logs after change:
# Demonstrate the improvement after the change.  For example:
# Measured RTC access time: 1ms (showing reduced latency)
# or:
# No deadlocks observed during concurrent RTC access.
<Insert actual logs showing the positive effect of the change>

please merge https://github.com/apache/nuttx/pull/15231 into one commit, these two files are basically similar

please merge #15231 into one commit, these two files are basically similar

ok

Please let me test it on our internal CI before merging it...


Initial parser implementation

The parser and AST was taken from LPython. In subsequent commits we will start modifying it to parse C++.

TODO: get --show-ast working.

@czgdp1807, @Shaikh-Ubaid I don't have time to completely finish it. Go ahead and take it from here. We need to get --show-ast working and then start modifying the parser to parse C++ instead of Python. I would not bother with AST->ASR until we can parse enough of AST. So it's an orthogonal feature for now.


Missing loggregator tags from dea

The CAPI team used to track the following tags through the collector:
cf.collector.uptime_in_seconds
cf.collector.reservable_stagers
cf.collector.dea_registry_running
Since the migration from collector to loggregator we no longer have a way of tracking this info. We would like to be able to continue seeing this information through loggregator.
@youreddy & @jeffpak
CF CAPI Team

This has been delivered.


Fix parallelism of Kafka's consumer groups

Fixes #917
Proposed Changes

Fix parallelism of Kafka's consumer groups
Run e2e tests in parallel

/assign @matzew
/assign @vaikas

/ok-to-test

/hold
Wait wait, Why @pierDipi are you cloning the client? Are you sure it's a good idea? To me it sounds that cloning the client creates a new TCP connection pool to the cluster, eventually creating tons of them because a client is created for every subscription... And since these clients are not closed, they also leak https://godoc.org/github.com/Shopify/sarama#Client

The documentation of https://godoc.org/github.com/Shopify/sarama#NewConsumerGroupFromClient says:

PLEASE NOTE: consumer groups can only re-use but not share clients.

I think we can use https://godoc.org/github.com/Shopify/sarama#NewConsumerGroup directly

We can have only one consumer group for all topics, but we need to re-structure the KafkaDispatcher.
Even with only one consumer group, we need to re-create the consumer group when we have new topics to consume, therefore we should fix the factory implementation.
Given these:

PLEASE NOTE: consumer groups can only re-use but not share clients

cloning the client creates a new TCP connection pool to the kafka cluster

I would opt for fixing the factory implementation using https://godoc.org/github.com/Shopify/sarama#NewConsumerGroup (this PR?) and discussing the issue: https://github.com/knative/eventing-contrib/issues/1166
What do you think?

What do you think?

Let's discuss on the issue and close this PR, better to fix everything in a new one

/assign

/test pull-knative-eventing-contrib-integration-tests

/unhold

probably wishful thinking, but... any chance this might help with: https://github.com/knative/eventing-contrib/issues/1166#issuecomment-620058942  ?

@duglin https://github.com/knative/eventing-contrib/pull/1179 should solve your issue.
If you still get the problem, please, open an issue.

Cool!  Now I'm excited! :-)  Will test it out soon...  thanks a ton!

@pierDipi now I'm not getting any events. I noticed the topics and servers are now arrays of strings, is there anything else in the source CR that changed that I need to be aware of?

My CR:
apiVersion: sources.knative.dev/v1alpha1
kind: KafkaSource
metadata:
  name: ks1
spec:
  consumerGroup: knative-group
  bootstrapServers: [ <IP_ADDRESS>:9092 ]
  topics: [ u1t1,u1t2,u2t1,u2t2,u3t1,u3t2,u4t1,u4t2,u5t1,u5t2,u6t1,u6t2,u7t1,u7t2,u8t1,u8t2,u9t1,u9t2,u10t1,u10t2 ]
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: knkafkaservice

@pierDipi question for ya.....
looking at https://github.com/knative/eventing-contrib/blob/master/kafka/source/pkg/reconciler/source/kafkasource.go#L137
"err" might not actually be an error, it could just be an Event.see: https://github.com/knative/eventing-contrib/blob/master/kafka/source/pkg/reconciler/source/kafkasource.go#L196
so on line 137, shouldn't we only stop if it's a real error and not an Event about the ksvc being created?
/cc @aslom @lionelvillard

I guess I have a broader question... how do we normally distinguish between Events that should end up on the CR vs errors that should stop the reconciliation process?


Add /stinfo and /doorLabels

command: /stinfo about|credits|legal|help|model|stats
about: gives a brief description of the mod
credits: gives the credits for the mod
legal: gives license info for both the mod itself and TF for Java
help: explains the functionality of the mod (more needed)
model: gives a brief description of the model and where its stored
stats: will give a description of the stats and timing once finalized
command: /doorLabels (true|false)
renders door labels denoting the model choice, perfect choice, and reverse entrances (anything that has a color indicator) for people who may have trouble distinguishing colors.

Maybe rebase your branch again to prevent conflicts?


fixed resize event being global: use unique id for each instance of Glide

Hello there,
Found an issue when using multiple instances of Glide; the resize event is global which means if you destroy one of them, the resize event will also be removed for the other one.
A solution is to use a unique ID when adding/removing the event listener. Also it might also be the case for other events, but I didn't had to use them.

Only window resize event is "global", every other is binded directly to elements. It sholud be fine.
Thanks :)

Cool! You're welcome 👍

Math.random() could bring some collisions. For now I leave it as is.
If this will be a problem, we switch to some sort of uuid generator.


Guard Canonicalization is invalid

Consider the following two sets of assignments:
w.in = a.out ? 1'd1;
w.in = b.out ? 1'd1;

and
w.in = a.out;
w.in = b.out;

In the first program, we're saying something like: if a.out or b.out is active, forward 1'd1 to w.in, otherwise forward nothing. In the second program, we're saying unconditionally forward both a.out and b.out to w.in which is an obvious runtime conflict.
The first program can be optimized into:
w.in = a.out | b.out ? 1'd1;

However, the canonicalization pass currently transforms program (1) to (2), altering the semantics. We should disable rewrites of the form a = g ? 1'd1 -> a = g and instead only allow the canonicalizer to perform a = 1'd1 ? b to a = b.

It's a good example, and I think it clearly depends on nailing down semantics for undefinedness as suggested in #922… namely, I don't think it's a foregone conclusion that this is always a conflict:
w.in = a.out;
w.in = b.out;

We don't right now, but we could decide that this is perfectly safe if a.out and b.out are never defined simultaneously.


How to watch all resources based on labelSelector?

I am new to Rust, but trying to learn the language better by writing something that is useful to me.  I'm attempting to write a daemon that will watch all objects based on a labelSelector and if it notices that a matched object has changed, it will notify me.  The idea is that I can theoretically send a webhook when a Pod or a Deployment spec are updated, alerting someone to the fact that they changed.
I was starting with the configmap_watcher example, but then realized that the watcher was (obviously) only scoped to ConfigMaps.  I saw a reference in #194 that mentions that a user could implement a Api::all() connection with the generic Resource, which I think will do exactly what I am looking for.  When I try to do:
let foo: Api<k8s_openapi::Resource> = Api::all(client);

I am warned that the Resource type does not have a size.  The compiler helpfully suggests that I use the dyn keyword but that doesn't seem to be the right choice.
Thanks for any hints you could provide, or alternative approaches you might suggest.  My other thought was I could potentially open multiple Api::all() watchers for the various types I want to look at (Pod, Deployment, ReplicaSet, etc) but I wasn't sure if that was necessarily very efficient either.

Oh, yeah, you are right. We don't support the kubectl get all case at the moment because it's not a single Resource type.
It also does not appear to be found on a single resource url either; if you use kubectl get all -v=9 it literally just does a list on all resources sequentially.

If I were you I would put a watcher on Api<Deployment> (which covers the replicaset and pod in terms of ownership) plus whatever top level objects you need. It's going to be more efficient.
For the get all feature: Don't see a clean way to support a fake all-endpoint without doing a series of calls to the supported endpoints api resources, and then looping over those results dynamically. It is possible we could implement that, but it'd be an annoying request that would have an annoying responce type (e.g.Vec<(Resource, serde_json::Value)>`) which would have to be manually deserialized.

So in a scenario where I am making numerous watchers, i.e. Api, Api, Api etc, would I have to create individual watchers for this?  Would it be possble to pass an array of Api connections to watch them in tandem?  I'm thinking about in the example how we have an event loop here:
   let mut w = watcher(cms, lp).boxed();
    while let Some(event) = w.try_next().await? {
        info!("Got: {:?}", event);
    }

If I were to create n watchers, I'd probably have to coalesce them into an iterable and do a 'is there an event available' foreach rather than the await for the next event, I guess?

Yeah, you would need individual watchers. How you run all of them in the cleanest way I'm not sure what's best. You can:

use tokio::select! to await the first element from a set of streams (pretty deep nested logic)
use Stream::select_all to combine the stream into a bigger stream (then use that in a try_next(), i think)

The second one is probably harder to get to compile, but I expect it will look nicer. We actually do really need a good user example for the latter. If you manage to get that to work.I'd appreciate you posting it here :-)

Try something like this:
#[tokio::main]
async fn main() -> anyhow::Result<()> {
    std::env::set_var("RUST_LOG", "info,node_watcher=debug,kube=debug");
    env_logger::init();
    let client = Client::try_default().await?;

    let deploys: Api<Deployment> = Api::all(client.clone());
    let cms: Api<ConfigMap> = Api::all(client.clone());

    let deploy_stream = try_flatten_applied(watcher(deploys, ListParams::default()))
        .map_ok(|d| Watched::Deploy(d))
        .boxed();
    let configmap_stream = try_flatten_applied(watcher(cms, ListParams::default()))
        .map_ok(|cm| Watched::Config(cm))
        .boxed();

    let mut combo_stream = stream::select_all(vec![deploy_stream, configmap_stream]);
    while let Some(o) = combo_stream.try_next().await? {
        match o {
            Watched::Config(cm) => info!("Got configmap: {}", Meta::name(&cm)),
            Watched::Deploy(d) => info!("Got deployment: {}", Meta::name(&d)),
        }
    }
    Ok(())
}

enum Watched {
    Config(ConfigMap),
    Deploy(Deployment),
}

Thanks @clux, this works quite well!


Update to most recent cookiecutter-django version

Description
Rationale
Use case(s) / visualization(s)

Oops, sorry. I confused head and base


Adding Riot Games Scope

Not all of the scope but what I can do for now instead of Noting.

Thank you for the merging.


Add support for deep-nested govspeak fields

Documents with govspeak parts that are nested mutliple levels deep
in the details hash weren't getting rendered by publishing-api.
This adds recursion to the rendering presentor, so that these schema
types can be accomodated.
Pair-coded with @emmabeynon
Trello: https://trello.com/c/r2gA1lxN/640-migrate-guide-format-to-rendered

Looks good to me 👍 Probably best to get some 👀 from Publishing Platform on this. @kevindew maybe?

FWIW I think this implementation does exactly what is needed, but I wonder if there's an opportunity to leverage the schemas so the system knows exactly which keys in the details hash need govspeak transformation rather than searching for them.  (I don't know if the schemas can be used like this, or if they contain this information).

@h-lame breaking your comment down through the post-structural lens, here. I'm going to postulate that if it quacks like a duck, you can treat is as if it is a duck. Furthermore, the labels that a schema author might use to help outline the structure of a document can not be rigorously construed to have bearing on the purpose or intent of the associated objects.
Also, that sounds like hard work.

@whoojemaflip sure.  I should have said that I didn't really think what I was suggesting is something that should happen as part of this PR even if it is possible.  I agree it would probably be a lot of work.

@h-lame it would probably take some aggressive policing of the schema field definitions to ensure they remained within an established taxonomy of types. Might be worth looking into at some point..

Hey @whoojemaflip - @dougdroper is just in the process of checking this out. Sorry for the delay.

@dougdroper had a spin, do you think that's an improvement?

@dougdroper @kevindew maybe we should seek a 5th opinion...?

@kevindew Nah, don't think it is an improvement :) but we are bikeshedding now.


Is it wrong to create new search methods within the model?

I'm wondering if you have any problem creating search methods within the model.
Ex. findByHash
const { Model } = require('objection');

class Usuario extends Model {

  static get tableName() {
    return 'usuario';
  }

  static async findByHash(hash) {
    return await Usuario.query().findOne({hash});
  }
}
module.exports = Usuario;

None at all! That's a really good way to add more complex/custom queries to your app.