Implementation of Elections spec

As defined in this draft proposal.

Coverage decreased (-1.3%) to 98.286% when pulling c952cde626dc7b1a927ddc4a62e53acdd41ead1a on california-civic-data-coalition:master into 8e3abb00c763b7046a0707a6c43e7978854698a8 on opencivicdata:master.

@jamesturk given the movement toward separate apps, should spike this PR and submit another after PR #85 is merged?
Or I could also make a PR on the split-apps branch, and this could all go up together.

let's keep these in separate PRs, but yeah I think we should wait to merge until we've decided one way or another on #83- I'll ping the relevant parties to see if they're OK with the plan

Coverage decreased (-28.4%) to 70.358% when pulling 8e3fd0efe587072c9d0193fc8efd6dbe4b943312 on california-civic-data-coalition:master into 4d0c1648c2c84b734557e1276c25c34b80a4cb2f on opencivicdata:master.

Coverage decreased (-26.5%) to 72.254% when pulling acf550372fcae5c5aa2266585c412e7949093d2a on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-26.5%) to 72.231% when pulling 3bf12ef85fa3009efceba1a68212f80fe9457a69 on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-26.8%) to 71.938% when pulling 9e95522c847b12a19cff54737a44f569fe2cf6b7 on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-11.9%) to 86.838% when pulling 3e1e045ed0ee4e9ccc07ad3a3e00337c1850326f on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-1.5%) to 97.27% when pulling 4cd41a4ac2666fde0f68192e98174152cffce75e on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-1.5%) to 97.27% when pulling bba89e4c7d9b466ea5bfe087de86afdffc82d6b7 on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-1.5%) to 97.27% when pulling bba89e4c7d9b466ea5bfe087de86afdffc82d6b7 on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-1.5%) to 97.27% when pulling bba89e4c7d9b466ea5bfe087de86afdffc82d6b7 on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-1.5%) to 97.27% when pulling bba89e4c7d9b466ea5bfe087de86afdffc82d6b7 on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-1.5%) to 97.27% when pulling b348cf67d90027a7ffdee4ce14c3cf7e03106063 on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-1.5%) to 97.27% when pulling b348cf67d90027a7ffdee4ce14c3cf7e03106063 on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage decreased (-1.5%) to 97.27% when pulling 8b4bdf37f1238c901ade1c5e802f16423369a1da on california-civic-data-coalition:master into 5f97a77dc53361d69adc7f9901c73bed38a4a9e7 on opencivicdata:master.

Coverage increased (+0.3%) to 98.999% when pulling 2de4af2757123a4113fee4bbd8ffca6444306f5b on california-civic-data-coalition:master into b38b6ddb992f16c5d6aab656206e686ca9b1a48f on opencivicdata:master.

Coverage increased (+0.3%) to 98.999% when pulling 2a133f1e98077fc435e0229154397127041cd5f0 on california-civic-data-coalition:master into b38b6ddb992f16c5d6aab656206e686ca9b1a48f on opencivicdata:master.

@jamesturk This one is ready for review again. Below are some notes on differences since I first put in the PR.
Removed inheritance from non-abstract models

Election no longer subclasses Event. There's been some discussion, though, about adding an abstract EventBase in opencivicdata.core someday.

In the mean time, I'm not clear on the proper format for Election.id. I currently have it as ocd-election/..., but should it be ocd-event/...?

ContestBase is now an abstract model from which all the contest models inherit.
RetentionContest no longer inherits from BallotMeasureContest but remains under the contests.ballot_measure namespace.

Added models

ElectionSource, which mirrors the EventSource model. I don't think any of the other event-related models have any relevance to elections.
RetentionContestOption, which mirrors BallotMeasureContestOption.
Split up ContestIdentifier into four contest-class specific models.
Same as above for ContestSource.

Removed models

Replaced Party model with references to Organization from core (per issue #89 from the specs repo). These foreign key relationships (e.g., Candidacy.party) are limited to only organizations with the classification "party", though I believe that's only forced on Django forms, not by the ORM or db.

Coverage increased (+0.3%) to 98.999% when pulling 4ed4d34d427718a5e879d529cd4da41ae3ed5e24 on california-civic-data-coalition:master into b38b6ddb992f16c5d6aab656206e686ca9b1a48f on opencivicdata:master.

@jamesturk so I think the proposed changes are:

Drop the election date hierarchy filter on CandidacyAdmin so as not to introduce a Django >= 1.11 feature just yet.
Make Candidacy.filed_date a fuzzy date field, rather inheriting from DateField in django.db.models.

Should I go ahead and make either or both of these?

no need to drop the date hierarchy filter, definitely want to support Django >= 1.11
I'll defer to you on the filed_date issue, I don't know the data well enough to know if a fuzzy date is necessary, but if you think it'd be useful I'd switch it to that

I don't think I have any further changes, I think we could go ahead and accept this & consider it provisional (so a bit less strict on backwards incompatible changes until it stabilizes)

Cool! Let's do this.

This is excellent news. Thrilled to see this merged and released.


BUG: MoveFileInternal did not move files across disk drives

My temporary directory is on C:\.
If desired file is on M:\ the function would fail without an explanation.

Related to https://discourse.slicer.org/t/updating-only-header-information-for-metaimage-nrrd/15115/3


[FEAT] Option to delete a project role

@WardM99 can I get an ETA on this one?

@Tiebe-Vercoutter 1h max 2h

@WardM99 can you maybe do #442 while you’re at it? It’s about the same subject.


NetBSD says zsh not installed on SDF

I received the error message:
Zsh is not installed! Please install zsh first!

After installing via wget:
$ sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"

On my SDF.org NetBSD account:
iceland% which zsh
/usr/pkg/bin/zsh

My path:
iceland% echo $PATH
/usr/pkg/bin:/usr/local/bin:/usr/bin:/bin:/usr/pkg/games:/usr/pkg/X11R7/bin

Contents of /etc/shells:
iceland% cat /etc/shells
/bin/sh
/bin/csh
/bin/ksh

The problem is, I am running zsh, it's just that the chsh command seems to route you to a different server where account management (setting password, changing shell, etc., is done). Even when you change your shell through that service, the original three (sh,csh,ksh) remain the only three options in the /etc/shells file.
iceland% which chsh
/usr/local/bin/chsh

I can install oh-my-zsh if I alter the following part of the install.sh:
  CHECK_ZSH_INSTALLED=$(grep /zsh$ /etc/shells | wc -l)
  if [ ! $CHECK_ZSH_INSTALLED -ge 1 ]; then
    printf "${YELLOW}Zsh is not installed!${NORMAL} Please install zsh first!\n"
    exit
  fi
  unset CHECK_ZSH_INSTALLED

My question is, is there a better way to check for zsh, if not optimal, say instead using something like (sorry about pseudo-code, my BASH is shaky:
# run which command first so we can test last exit code rather than save to a env var because
# if not found it saves the string 'zsh not found' into the var CHECK_ZSH_INSTALLED
which zsh
if [ $? -gt 0 ]; then
  printf "${YELLOW}Zsh is not installed!${NORMAL} Please install zsh first\n"
  exit
else
  CHECK_ZSH_INSTALLED=`which zsh`
fi

My solution, did not want to create pull request for this, probably needs some fixing:
The section in question:
which zsh
# Check if zsh in PATH by checking last exit code
if [ $? -gt 0 ]; then
  # Maybe not in PATH, but listed in /etc/shells as available, meaning we need to fix our PATH
  printf "${YELLOW}Error: A zsh install was not found.${NORMAL} Checking \
        with /etc/shells to see if it a possible PATH problem...\n"
  CHECK_ZSH_INSTALLED=$(grep /zsh$ /etc/shells | wc -l)
  if [ ! $CHECK_ZSH_INSTALLED -ge 1 ]; then
    printf "${YELLOW}Zsh is not present in /etc/shells either. Please \
             install zsh and retry this installer.\n"
    unset CHECK_ZSH_INSTALLED
    exit
 else
    printf "${YELLOW}Error: a zsh entry was found in /etc/shells, but we \
             could not find it in your PATH. Please make sure that zsh is \
             installed and rerun this install script.\n"
    unset CHECK_ZSH_INSTALLED
    exit
  fi;
  exit
fi;

Hi @saltycraig, this will be fixed on #5169. The complex error checking isn't needed here, perhaps I'll copy the could not find in PATH error message. It should be merged in the following days!

#6398 should fix this


OSX Segmentation Fault with QT 5

System:

OSX 10.11
ROS Kinetic
QT 5.7.1 (homebrew)
Ogre 1.9.0 (homebrew osrf/simulation tap)
RVIZ 1.12.4

Recently tried to upgrade to QT5 + ROS Kinetic on my Mac. While RVIZ was previously running properly, I am now getting a segfault:
libOgreMain.1.10.0.dylib`Ogre::RenderSystem::attachRenderTarget(this=0x0000000112142128, target=0x0000000000000000) + 23 at OgreRenderSystem.cpp:258, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)

A little digging, and it seems that Ogre is not properly allocating a window (i.e., target is 0x000 above).
A little more digging, and I'm fairly sure this is a result of QT5 no longer setting the QT_MAC_USE_COCOA define (required here)
This is noted as a Qt5 issue but in the meantime, an easy fix would be to #define QT_MAC_USE_COCOA whenever Qt5 is being used in RVIZ...

Can confirm that adding QT_MAC_USE_COCOA define does fix the segfault and RViz is able to run on my system (described above)

Upgrading to Qt 5.9.0 fixes this issue.
Can confirm that kinetic-devel branch (v 1.12.10, b92308eb) works out of the box for me with:

OSX 10.12.2
ROS Kinetic
QT 5.9.0 (homebrew)
Ogre 1.9.0 (homebrew osrv/simulation tap)


[Bug] There are no scenarios; must have at least one.

Im trying to run it and after executing yarn I get the error of the subject.
What am I doing wrong/missing?
Thanks.

I have been doing a bad job maintaining this so the dependencies are out of date.
But you should be able to install them by running yarn or npm install and then either yarn start or npm run start.
When do the error appear? Can you post a screenshot or log of the error?

Hi David,
No issues. Looks like in Debian installing the yarn package does not cut it. Properly intalled it and managed to run it only to have another bug that ill put in another thread.
Thanks!


[SPARK-8930][SQL] Support a star '*' in generator function arguments

The current implementation throws an exception if generators contain a star '' like codes blow;
val df = Seq(("1", "1,2"), ("2", "4"), ("3", "7,8,9")).toDF("prefix", "csv")
checkAnswer(
df.explode($"")
{ case Row(prefix: String, csv: String) => csv.split(",").map(v => Tuple1(prefix + ":" + v)) }
,
Row("1", "1,2", "1:1") :: Row("1", "1,2", "1:2")
:: Row("2", "4", "2:4")
:: Row("3", "7,8,9", "3:7") :: Row("3", "7,8,9", "3:8") :: Row("3", "7,8,9", "3:9")
:: Nil
)
[info] - explode takes UnresolvedStar *** FAILED *** (14 milliseconds)
[info] org.apache.spark.sql.AnalysisException: cannot resolve '_1' given input columns prefix, csv;
[info] at org.apache.spark.sql.catalyst.analysis.package$AnalysisErrorAt.failAnalysis(package.scala:42)
[info] at org.apache.spark.sql.catalyst.analysis.CheckAnalysis$$anonfun$checkAnalysis$1$$anonfun$apply$2.applyOrElse(CheckAnalysis.scala:55)
[info] at org.apache.spark.sql.catalyst.analysis.CheckAnalysis$$anonfun$checkAnalysis$1$$anonfun$apply$2.applyOrElse(CheckAnalysis.scala:52)
[info] at org.apache.spark.sql.catalyst.trees.TreeNode$$anonfun$transformUp$1.apply(TreeNode.scala:291)
[info] at org.apache.spark.sql.catalyst.trees.TreeNode$$anonfun$transformUp$1.apply(TreeNode.scala:291)
[info] at org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:51)
[info] at org.apache.spark.sql.catalyst.trees.TreeNode.transformUp(TreeNode.scala:290)
[info] at org.apache.spark.sql.catalyst.plans.QueryPlan.transformExpressionUp$1(QueryPlan.scala:107)
[info] at org.apache.spark.sql.catalyst.plans.QueryPlan.org$apache$spark$sql$catalyst$plans$QueryPlan$$recursiveTransform$2(QueryPlan.scala:117)
[info] at org.apache.spark.sql.catalyst.plans.QueryPlan$$anonfun$org$apache$spark$sql$catalyst$plans$QueryPlan$$recursiveTransform$2$1.apply(QueryPlan.scala:1
21)
[info] at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244)
[info] at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244)
[info] at scala.collection.immutable.List.foreach(List.scala:318)
[info] at scala.collection.TraversableLike$class.map(TraversableLike.scala:244)
[info] at scala.collection.AbstractTraversable.map(Traversable.scala:105)

Merged build triggered.

Merged build started.

Test build #36866 has started for   PR 7305 at commit 70fdd41.

Test build #36866 has finished for   PR 7305 at commit 70fdd41.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

@maropu Probably this is incorrect.
Explode actually only accept single child expression, which should be either in ArrayType or MapType, pass in a Star probably not correct in semantics, particularly the star can be expanded into couple of expressions.
And in Analyzer, seems you simply transform the generator from Explode into UserDefinedGenerator if it contains star, that's not an explode any more.
From the unit test code, probably the SQL like below can achieve the same purpose.
···
Seq(("1", "1,2"), ("2", "4"), ("3", "7,8,9")).toDF("prefix", "csv").registerTempTable("table")
SELECT prefix, csv, concat(prefix, ':', r) FROM table LATERAL VIEW explode(split(csv,',')) d as r
···

@chenghao-intel So I'll fix this PR to throw an AnalysisException if Generate has '*'.
Is it ok?

@chenghao-intel Ok, thanks.
Is the limitation only applied to Explode and I mean that can other generator functions have multiple expressions?
Anyway, I'll fix this PR to throw an AnalysisException if Explode has '*'.

Merged build triggered.

Merged build started.

Test build #37371 has started for   PR 7305 at commit 92d17a3.

I understood that Hive explode only has a single expression though, should we apply the same limitation into UserDefinedGenerator used in the DataFrame#explode implementation?
https://github.com/apache/spark/pull/7305/files#diff-57b3d87be744b7d79a9beacf8e5e5eb2R286

Test build #37371 has finished for   PR 7305 at commit 92d17a3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Merged build triggered.

Merged build started.

Test build #38012 has started for   PR 7305 at commit 891ec4d.

Test build #38012 has finished for   PR 7305 at commit 891ec4d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Merged build triggered.

Merged build started.

Test build #38160 has started for   PR 7305 at commit de3423f.

Test build #38160 has finished for   PR 7305 at commit de3423f.

This patch fails some tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

retest this please

Merged build triggered.

Merged build started.

Test build #38323 has started for   PR 7305 at commit de3423f.

Merged build triggered.

Merged build started.

Test build #87 has started for   PR 7305 at commit de3423f.

Test build #87 has finished for   PR 7305 at commit de3423f.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #38323 has finished for   PR 7305 at commit de3423f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.


some code quality alerts in bml and publicservice module

1.The number of log print information placeholders and variables is inconsistent
2.Some streams are not closed
3.Singleton classes that may cause problems
4.String should not use in synchronized（）

thanks it is fixed in #404


Recurrence completion bug

Expected Behavior
When creating a task with only a recurrence rule the task should recur when completed.

[ ] #todo test recurrence 🔁 every week on Monday
[x] #todo test recurrence 🔁 every week on Monday ✅ 2022-04-11

Current Behavior
Currently the task cannot be toggled completed because of a bug in the Recurrence.next() function. It can be fixed using the new "when done" modifier.
This works

[ ] #todo test recurrence 🔁 every week on Monday when done
[x] #todo test recurrence 🔁 every week on Monday when done ✅ 2022-04-11

Steps to Reproduce

[ ] #todo test recurrence 🔁 every week on Monday

Context (Environment)

Obsidian version: 0.14.5
Tasks version: 1.5.0

Error Code
Uncaught Error: Invalid date passed in to RRule.after
at RRule2.after (eval at  (app.js:1:1490278), :13628:13)
at Recurrence.next (eval at  (app.js:1:1490278), :14136:25)
at _Task.toggle (eval at  (app.js:1:1490278), :14492:42)
at LivePreviewExtension.handleClickEvent (eval at  (app.js:1:1490278), :16187:26)
Possible Solution
I think this has to do with the fact that the reference date is null.
  next() {
    let next;
    if (this.baseOnToday) {
      const today = window.moment();
      const ruleBasedOnToday = new rrule_default(__spreadProps(__spreadValues({}, this.rrule.origOptions), {
        dtstart: today.startOf("day").utc(true).toDate()
      }));
      next = ruleBasedOnToday.after(today.endOf("day").utc(true).toDate());
    } else {
    //This is the branch the error is referencing.
      const after = window.moment(this.referenceDate).endOf("day").utc(true);
      next = this.rrule.after(after.toDate());
    } //The function def continues

Thank you for the report, @PeterRussC. I am not sure it is a bug, though the behavior could be better. In my opinion, recurrence doesn’t really make sense without a „due“ or „scheduled“ date. How does it „recur“?

The bug is not being able to toggle a task as complete when this.referenceDate is null. As for the behavior, I think the due date is implicit just like when there is a basedOnToday/"when done" and there is no due or scheduled dates. Or another way is a recurring task always recurs when completed. I added this default case to the referenceDate assignment to add this in #597.
If you think that a task should be invalid without a due, scheduled, or start date, maybe that behavior could be added to the modal to diss allow tasks with recurrence but no date.

Thanks, @PeterRussC. That's a good catch, for sure! :pray:


Extra feature: chat box

Chat with one player?
General chat room?
Save chats to database? In memory only?

Can use this bootstrap utility in the chatbox
https://getbootstrap.com/docs/5.0/utilities/overflow/

Example chatbox using socketio:
https://socket.io/demos/chat/
code:
https://github.com/socketio/socket.io/tree/master/examples/chat


Prevent token reuse

Adds logic to prevent a token from being reused if it already exists in the DynamoDB table, or if it's already been marked as used by the WebSocketAuthorizer lambda. The solution implemented here is to pass along the request from the authorizer but with an error code that the next lambda uses to reject the response (as discussed in our recent infra meeting).
Note that we'll need an accompanying change in Javalab to properly handle and translate this message. For now, if this happens, the request will just fail and we'll display our standard error message of "We hit an error connecting to our server. Try again."
Testing: tested using dev lambda by manually using the same token twice, both during the upload sources step, and during the websocket connection step.

Were you able to see whether this is happening at all currently (via cloudwatch logs)? Not sure how searchable the logging message is currently.

Were you able to see whether this is happening at all currently (via cloudwatch logs)? Not sure how searchable the logging message is currently.

Yep! They were showing up in both authorizer lambdas with messages like: TOKEN VALIDATION ERROR: used token_id: 84ec7ca3-7aba-4892-8871-ccdd320ea221

Were you able to see whether this is happening at all currently (via cloudwatch logs)? Not sure how searchable the logging message is currently.

Yep! They were showing up in both authorizer lambdas with messages like: TOKEN VALIDATION ERROR: used token_id: 84ec7ca3-7aba-4892-8871-ccdd320ea221

You mean we are seeing this happen in production, or just you saw them when you were testing? If in production, how frequently?

Were you able to see whether this is happening at all currently (via cloudwatch logs)? Not sure how searchable the logging message is currently.

Yep! They were showing up in both authorizer lambdas with messages like: TOKEN VALIDATION ERROR: used token_id: 84ec7ca3-7aba-4892-8871-ccdd320ea221

You mean we are seeing this happen in production, or just you saw them when you were testing? If in production, how frequently?

Ah sorry - I meant only on my dev instance while testing. In production, only see "not_vetted" appearing in the WebsocketAuthorizerLambda logs and "user_blocked" appearing in the HttpAuthorizerLambda

Ah sorry - I meant only on my dev instance while testing. In production, only see "not_vetted" appearing in the WebsocketAuthorizerLambda logs and "user_blocked" appearing in the HttpAuthorizerLambda

Cool -- tangential to this PR but curious about not vetted, did you see that a lot? We wouldn't expect that, right?

Cool -- tangential to this PR but curious about not vetted, did you see that a lot? We wouldn't expect that, right?

Yep - from just briefly scanning the logs, my guess is that any tokens that are returning "user_blocked" in the http authorizer are also returning "not_vetted" in the websocket authorizer, since I believe don't mark the token as vetted if the user is blocked, but we're still passing on the request.


Custom grades and grade remarks

Fixes #393
Describe the changes you have made in this pr -
Added custom grading scale and remarks in grades.
Screenshots of the changes (If any) -
Grading form visible to the mentor

Remarks are visible to group members once the grades are finalized

Todo -

[x] Make remarks visible to the group members

The grades are getting deleted when I click finalize grades
It gets deleted when I am running sidekiq so I suppose you are not running sidekiq.
Run sidekiq as follows
bundle exec sidekiq -q default -q mailers -d -L tmp/sidekiq.log


[zh] Sync troubleshooting-kubeadm.md

There is only 1 PR after last sync (#33688)
$ ./scripts/lsync.sh content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index ac8d89ee3a..7b195a34fd 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -114,7 +114,7 @@ sudo kubeadm reset

 A possible solution is to restart the container runtime and then re-run `kubeadm reset`.
 You can also use `crictl` to debug the state of the container runtime. See
-[Debugging Kubernetes nodes with crictl](/docs/tasks/debug-application-cluster/crictl/).
+[Debugging Kubernetes nodes with crictl](/docs/tasks/debug/debug-cluster/crictl/).

But there are some missed paragraph and some mis-placed.

Netlify build fails.
After #33861 gets merged, this will be resolved.
So, you may need to rebase after #33861 gets merged.

@Sea-n pls rebase this onto main branch and commit again.

/lgtm


Add option --force

The --force | -f option will look into pdsc files validating it against what's exposed in the vendor's *.pidx files

Implemented in https://github.com/Open-CMSIS-Pack/vidx2pidx/pull/4


not working while using preact

hey @antfu , awesome library for vite, I'm making an interesting project using vite + preact though plugin works fine with react, it's not working with preact. can we expect something in future? Thanks

@WhoAdarshPandya we'll add support for preact when we have time to do if (PR are welcome), in the mean time you can use vanilla javascript virtual module to add preact reactivity system using https://github.com/antfu/vite-plugin-pwa/blob/main/src/client/build/react.ts as a guide.

@WhoAdarshPandya add repo where we can check what's failing using this plugin with preact


Add a Hermes EcmascriptEngine Pimpl

This card covers adding support for the Hermes JS library: https://github.com/facebook/hermes
Initial support for this is just about complete and the performance gains are significant: https://github.com/JoshMarler/blueprint/tree/add_hermes_js_engine

@nick-thompson, I've put this down as beta for the moment as it will likely be ready very shortly but feel free to change this if you wish. The performance gains are really significant so might be nice to get this out for beta for people writing more complex apps or targeting embedded hardware etc.
As part of the PR for this I can separate out the Duktape based EcmascriptEngine into it's own pimpl. I can add a couple of cmake options for enabling Duktape and/or Hermes. We can decide which to set as the default and the perhaps follow suit with this pattern for QuickJS and V8 (if and when that lands).

Yep yep all sounds great

Closing as resolved in https://github.com/nick-thompson/react-juce/commit/ae472e33e842bc6ffcebe3e245269769f4d868c8


Add ethernet datamover (EDM) - a foundational ethernet transfer engine

What's Included

Added "channel" concept to ethernet dataflow_api: @aliuTT
Added two level ack to ethernet channels: @aliuTT

First to indicate message received by receiver
Second to indicate receiver buffer available

Added EDM
Added multichannel ethernet microbenchmark sweep with erisc doing DRAM read/write
Added decoupled worker <-> EDM functional sweep

Currently we are prevented from collecting perf measurements here due to reporting bug

Will address in future changes
Why I kept non-decoupled benchmarks around

Description
The EDM is the foundational building block for communication over ethernet. It is "dumb" data mover that is decoupled from the data I/O access pattern. It is up to worker cores to push data to and pull data from the EDM and is designed to be bidirectional and non-blocking.
Workers can interact with EDM by pushing to or pulling from EDM, for each direction, the interface is the same. ChannelBuffers are channels (and corresponding L1 buffering on erisc) that make independent progress relative to each other. They can be filled and drained at different rates relative to one another. Additionally, ChannelBuffers can be written to or read by multiple workers; in that case it is up to workers to ensure they are accessing data with the correct offsets into the buffers.
For every ChannelBuffer, a pair of semaphores are used to facilitate synchronization. One of the semaphores for the ChannelBuffer lives on the erisc in L1 and the other lives in each worker's L1 (a copy). EDM will notify each worker when update occur.
Arg Setup Schema (EDM)

Handshake L1 Address: will be removed in the future. 16 B

Sender channels start: Which ethernet dataflow channels to start the
sender side channels at. Valid values: (0-7)

Sender num channels: Number of sender channels to instantiate.
Informs how many times to run the following arg fetch loop:
4) sender_buffer_address: EDM L1 start offset of the ChannelBuffer
5) sender_num_messages_to_send: Number of eth sends before completion

in other words, how many worker completion worth of transfers

sender_channel_size (B): Size of the L1 buffer on EDM
sender_semaphores_address: EDM local L1 address of semaphore
worker_semaphore_address: Worker L1 address of semaphore
sender num workers: semaphore threshold, also how many XY pairs to fetch in the next loop.
10) Worker X/Y (16bits each)

receiver channel start: same as sender channel start but for
receiver side

receiver num channels:

Transaction States (Worker -> EDM):
Worker

Worker first waits for a semaphore increment on its local semaphore
copy

The semaphore must be initialized to 0 by dispatcher/runtime 2) Upon receipt of (local) semaphore increment, the worker knows that it
is safe to write into the destination.

Worker clears the (local) semaphore
Worker writes into the EDM sender buffer

How much data to writer and at which offset(s) into the buffer are up to the worker kernel
NOTE: Make sure to flush the writes because the following semaphore inc could race ahead 5) Worker increments the semaphore on the EDM (sender) ChannelBuffer 6) Worker goes back to 1 if not done, else finishes

EDM (sender side)
(NOTE: the below is per ChannelBuffer and direction. It doesn't block)

Initializes(increments) the worker L1 semaphore, for all workers 2) Waits (checks) for worker completion to know when buffer payload is
ready

Indicated by the ChannelBuffer's local semaphore value equaling the number of workers 3) Waits (checks) if receiver is ready
Indicated by receiver channel done message which tells sender the receiver side buffer was consumed 4) Waits (checks) for receiver erisc to ack indicating message received
EDM sender can now clear its buffer and signal to workers that they can send again
Go to step 1 if not complete, else exit

EDM receiver <-> Worker code path is the same except that EDM receiver semaphore increments each reader worker's semaphore when data is available. It waits for a semaphore inc from each worker to indicate that the payload was consumed and the EDM receiver's buffer can be reused again.
Added microbenchmarks. Currently only enabled on old, non-decoupled EDM and I/O logic (due to issue reading back timestamps on host in decoupled mode).
To run non-decoupled microbenchmarks:
pytest tests/tt_metal/microbenchmarks/ethernet/test_ethernet_send_data_microbenchmark.py -k "test_run_ethernet_send_data_microbenchmark_sweep"
With the above command, throughput from low GBps to 12GBps were observed, depending on tensor side.
For functional sweep test for decoupled mode, run the pytest: test_decoupled_worker_and_erisc_data_mover_single_direction from
tests/tt_metal/microbenchmarks/ethernet/test_ethernet_send_data_microbenchmark.py

FYI @davorchap

Unfortunately, multi device regressions are broken, so you can't really test your stuff right now :(
We have 2x2 and 2x4 available: https://github.com/tenstorrent-metal/tt-metal/actions/workflows/multi-device-build-and-unit-tests.yaml
@aliuTT and @abhullar-tt can comment more on the state of tunneling, but I believe there are very active changes going on, so it's difficult to rely on CI failures currently.
Your post commit seems good, so I'll approve, and you guys can discuss and merge based on your discretion.

Final review - fixed the issues after rebase. Reran post commit, applied feedback:

(full post-commit) https://github.com/tenstorrent-metal/tt-metal/actions/runs/8180056516
(multi-device) https://github.com/tenstorrent-metal/tt-metal/actions/runs/8180614673
(ubench) https://github.com/tenstorrent-metal/tt-metal/actions/runs/8193478724

@aliuTT, can you please check my conflict resolution, particularly in tunneling to make sure you're okay with it?


Declare ImgPath property of OpenLayers in OpenLayers.js

The declaration of ImgPath within Util.js does not make sense and is not intuitive. Also since eb4bf5d438d660119328ce53f3e6a2b2faaab8ea ImgPath is an API property, but currently ends up in the documentation of OpenLayers.Util.
This pull requests moves the declaration from Util.js to OpenLayers.js and adds two trivial tests for ImgPath.
All relevant tests of OpenLayers pass in FF 10.0.2 and Chrome 11.0.696.57 so I am positive of not introducing regressions.

Correct me if I am wrong, but it doesn't look like this is going to work with single file builds.

Oh yeah... you are totally right. The exact same declaration of ImgPath would then be duplicated in SingleFile.js. Do we want that? Is there any way we can tell NaturalDocs where to put the documentation for ImgPath?

Whatever we do I think we should document what ImgPath should be set by the app developer when the name of the OpenLayers script isn't OpenLayers.js. Refs #288.

I think duplicating is ok. For ND look at apidoc_confit/Menu.txt. I don't think SingleFile.js is referenced in there. In any way
if ImgPath isn't an APIProperty in SingleFile.js it won't be visible (and duplicated) in the documentation. I think it'd make sense to have SingleFile.js in the API docs to explain what its role is. I know we have the narrative doc, the API docs are easier to maintain, so it makes sense to me that they contain as much information as possible.

I'll update the pull request according to your comments then.

Sorry... I hit the wrong button and accidentally closed the request.

@elemoine & @ahocevar Please have another look at this. Thanks in advance.

Since c9dbebf ImgPath is only a "Property" in SingleFile.js. Please have another look, @elemoine .

Please merge. Thanks.


can't get real clinet ip

I set ServerUrl to the IP address of the application load balancer. However, the IP address obtained on the exceptionless UI is the IP address of the load balancer instead of the actual client IP address. What can I do?

Are you running the latest version of the server and client and ensure the x-forward-for headers are configured properly on your lb?

Are you running the latest version of the server and client and ensure the x-forward-for headers are configured properly on your lb?

I use latest version of the server and client. The x-real-ip header instead of X-Forwarded-For header is added to the backend load balancer.

@NPUlrk I've never heard of the  x-real-ip header. I don't believe it is commonly used and I know that the middleware we are using from ASP.NET Core does not support that header.

@NPUlrk I've never heard of the  x-real-ip header. I don't believe it is commonly used and I know that the middleware we are using from ASP.NET Core does not support that header.

After log the LB request header info, I find that load balancer owner's feedback is incorrect. The request header contains the X-Forwarded-For information, but it is strange that the second IP address rather than the first IP address is obtained.

Refer to other answers, I added a middleware to obtain the real IP address, It works.
using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Http;
using System.Net;
namespace Exceptionless.Web.Utility.Handlers {
    public class RealIpMiddleware {
        private readonly RequestDelegate _next;

        public RealIpMiddleware(RequestDelegate next) {
            _next = next;
        }

        public Task Invoke(HttpContext context) {
            var headers = context.Request.Headers;
            if (headers.ContainsKey("X-Forwarded-For")) {
                context.Connection.RemoteIpAddress = IPAddress.Parse(headers["X-Forwarded-For"].ToString().Split(',', StringSplitOptions.RemoveEmptyEntries)[0]);
            }
            if (headers.ContainsKey("X-Real-IP")) {
                context.Connection.RemoteIpAddress = IPAddress.Parse(headers["X-Real-IP"].ToString());
            }
            return _next(context);
        }
    }
}


Change to use built-in GeoCoordinate class instead of MapLocation

Could be worth changing to use the built-in GeoCoordinate class instead of MapLocation:
https://docs.microsoft.com/en-us/dotnet/api/system.device.location.geocoordinate?view=netframework-4.8

Good call @rshackleton, thanks for the recommendation.
I'll change it locally and give it a test before pushing another version to nuget 👍


Question before exercise

Maybe irrelevant question/ If not, I would allow users to get away with a shorter answer (my answer was also to short to be accepted, which can cause frustration).

first note already here
@aversluis1 we can get rid of the minimal length, but you have to decide on this point.

@wbaccinelli, I  think whether we want to change the minimal length depends on the conversation Nele and Eline are having regarding the question itself. If more information will be giving, than they might be able to answer the question and then the minimal length does not need to be addressed. I will post a message about this in the other ticket.

Ok, so I will close this issue.


Add-UsersToAzureADGroup.ps1 not getting all $members of group

thanks for sharing, was helpful in a pinch.  One issue I found was that Get-AzureADGroupMember only pulls the first 100 if not using the -All $true.
recommended change

$members = Get-AzureADGroupMember -ObjectId $GroupObjectID.ObjectID -All $true

Great point! Thanks for the mention. I updated the script to reflect this change as it only helps. Thank you!


Support partial update in layer attribute updaters

For #1576
Change List

Update all primitive layers' updaters to support partial update

Coverage increased (+0.01%) to 62.081% when pulling 4cdf7b05205a45370dd33d7e7c1d5e0798168147 on x/layer-partial-update into 8e382c65aefaeefec240f30d36b20215cd3af5c9 on master.


Unity 2018 tests?

Just wondering if you've tested with newer Unity 2018's

The only versions I’ve tested with are in the readme
fre. 9. nov. 2018 kl. 02:08 skrev yosun<EMAIL_ADDRESS>
Just wondering if you've tested with newer Unity 2018's
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/agens-no/iMessageStickerUnity/issues/35, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAitDeZCOy3YYD1nIcrrgtpUvFBb0v2Oks5utNWHgaJpZM4YVxzW
.


Not loading NFTs/ collections

What happened?
I was testing Denver waifu minting on beta, and after I minted my waifu it took it maybe 30 minutes to load:

I can see it now, but that loading time is not normal.
Please reproduce in steps

Expected Behavior
load faster
What browsers are you seeing the problem on?
Chrome
At which address did you encounter bug?
beta.kodadot.xyz
Are you logged in?
None
Which wallet you are using?
No response
Screenshots

Relevant log output
No response
Payment link for reward
https://kodadot.xyz/transfer/?target=<My_Kusama_Address_check_https://github.com/kodadot/nft-gallery/blob/main/CONTRIBUTING.md#creating-your-ksm-address>
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Oh, I can also see that this collection is not loading properly; its on Kusama. It was minted more than 40 minutes ago. NFT in it is visible but not the collection picture.

another one minted 16 minutes ago not loading:

I sense it's issue with putting things on NFTStorage instead to directly to R2 ?

Clicked on link in waifu minter to land on collection and it failed @vikiival
https://beta.kodadot.xyz/rmrk/collection/26022023

yup it fails to fetch image
https://beta.kodadot.xyz/bsx/gallery/26022023-4


Check for pull requests in Appveyor deployment script

Right now, we deploy a Windows package even when we shouldn't (when a pull request is created.) This fixes that scenario by aborting deployment when PULL_REQUEST_NUMBER is defined in the build environment. Fixes #45.

Codecov Report

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

@@          Coverage Diff          @@
##           master    #57   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           8      8
  Lines         537    537
=====================================
  Hits          537    537

Continue to review full report at Codecov.

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


I can't see the events for next month.

Check that this is really a bug

[X] I confirm

Reproduction link
https://bitbucket.org/divya_rsvr/easygym-scorpio-reactjs/src/notifyAlert/src/components/Profile/Calendar/index.js
Bug description
I'm not able to display my events of next months.

Expected Behavior
Atleast it should show events of one year.
Actual Behavior
No response
react-big-calendar version
"react-big-calendar": "^0.38.5",
React version
"react": "^17.0.2",
Platform/Target and Browser Versions
Windows
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a react-big-calendar issue and not an implementation issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

Sorry , this is a bug from our backend team.


add logout button && no more matches for pairing popup && upload popup

Description

Add a 'Log Out' button in src/components/NavBar/SideBar.jsx, so that users could be able to log out from the application.
Add a ''NoBuddy' popup component in  src/components/NoBuddy/ , so that if a user has looped through all possible matches, the component will not immediately closing, it will say "no more matches".
Add upload popup component in src/components/UploadPopUp/, so that users can upload their timetable file from local machine. Users can also preview and delete the files in the upload dialog.

resolves #129
resolves #84
resolves #130
(To member who responsible for uploading files: #130 only create upload popup component, not including submit functions. Also when you do the submit function, please consider the file storage format and remember to change acceptedFiles number.)
How has this been tested?
manual testing
Screenshots
Add logout button

Add no more matches for paring dialog

Add upload timetable dialog

Checklist
(Leave blank if not applicable)

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

 Looking great! Just one thing to fix for the snapshot testing for the nav. I think you just have to delete the Nav.test.jsx.snap under snapshots folder and re-run the tests using npm test and it should generate a new snapshot :)

Thank you for your review, I modified it, please try npm test again

Heya, not sure if its just on my end but I think the library you are using is a little bugged. The styles are being removed once a file is uploaded to the dropzone for some reason.  I'm not too sure what you can do about this, maybe just use a standard file upload component.

thank you for you suggestion, I change it from dropzone to input. please take a look

Code changes made to resolve issue #129 collide with code changes made in PR #139 and it will cause merge conflicts. It needs to be resolved.

Code changes made to resolve issue #129 collide with code changes made in PR #139 and it will cause merge conflicts. It needs to be resolved.

thank you for your mention, resolved the conflicts now

Heya, not sure if its just on my end but I think the library you are using is a little bugged. The styles are being removed once a file is uploaded to the dropzone for some reason.  I'm not too sure what you can do about this, maybe just use a standard file upload component.

fixed

Heya, not sure if its just on my end but I think the library you are using is a little bugged. The styles are being removed once a file is uploaded to the dropzone for some reason.  I'm not too sure what you can do about this, maybe just use a standard file upload component.

fixed

LGTM!


Error on demo page

Playing around on the demo page , i get
Cannot read property removeChild
This happens after playing around and creating a really small squere

The demo page isn't using the latest release. This should no longer be an issue in the current release.

Ouch sorry, it's in fact using one of the more recent ones (although not the latest). I'll look into it.

I was unable to reproduce this in the latest build. Closing for now, unless someone else manages to reproduce exact steps that might lead to this.


Add support for IS NULL and NOT IS NULL in transform functions

This PR addresses the issue #8251 . Currently, Pinot supports IS NULL syntax in filter expressions such as WHERE clause. But it doesn't support as part of SELECT expressions such as CASE WHEN col IS NULL THEN a ELSE b
The PR adds support for such expressions by utilising the NullValueVectorReader to get the docIds which are null.
The implementation has two requirements/limitations -

nullHandlingEnabled should be set to true  since native NULL values are not supported in  Pinot and requires a null value bitmap index.

Only column names can be provided as the first argument for expressions. The support for functions is still not there.
e.g. colA IS NULL is supported but LOWER(colA) IS NULL is not supported.

Currently Pending  -

Documentation

Codecov Report

Merging #8264 (a62cd28) into master (e6330bb) will decrease coverage by 49.89%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master    #8264       +/-   ##
=============================================
- Coverage     64.06%   14.17%   -49.90%
+ Complexity     4246       81     -4165
=============================================
  Files          1586     1596       +10
  Lines         83399    84107      +708
  Branches      12641    12730       +89
=============================================
- Hits          53427    11919    -41508
- Misses        26129    71292    +45163
+ Partials       3843      896     -2947

Flag
Coverage Δ

unittests1
?

unittests2
14.17% <0.00%> (+0.07%)
:arrow_up:

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

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

One more side note - If these functions are used with a table where Null handling is disabled, they assume everything is non-null. So IS NULL will always return false and IS NOT NULL will always return true.
Instead, If you want it to throw exception in this case, I can do that as well.

One more side note - If these functions are used with a table where Null handling is disabled, they assume everything is non-null. So IS NULL will always return false and IS NOT NULL will always return true.

This is the correct behavior which aligns with the filter semantic


CLOSED-CAPTIONS is added in Version 6

CLOSED-CAPTIONS is added in Version 6, does it need a method for CLOSED-CAPTIONS to set version to v6? @mbowBC

I'm not convinced whether it's required, section 7 appears to outline the expectations: https://tools.ietf.org/html/rfc8216#section-7
If we increase the version because closed captions were supported, any older players would not be able to play the stream - just because a tag existed that it isn't critical to playback.

Actually, my bad. I think I misunderstood the version 6.  It actually adds the CLOSED-CAPTIONS for #EXT-X-MEDIA, which can be included in video renditions. e.g:
#EXT-X-MEDIA:TYPE=CLOSED-CAPTIONS,GROUP-ID="cc",LANGUAGE="en",NAME="English",DEFAULT=YES,AUTOSELECT=YES,INSTREAM-ID="CC1"
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=2190673,BANDWIDTH=2523597,CODECS="avc1.640020,mp4a.40.2",RESOLUTION=960x540,FRAME-RATE=60.000,CLOSED-CAPTIONS="cc",AUDIO="a1",SUBTITLES="sub1"
v5/prog_index.m3u8


Post API Call Results To Cloud Service

Having retrieved the contents of an API call using Insomnia, we would like to push those results up to a cloud based service such as Google Sheets or other such cloud storage service.

Best case for this would be to build out plugin functionality, more specifically with a response hook.


Unbound should reply to CARP-addresses when "Network Interfaces" are configured

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
Until version 21.7.7, DNS queries sent to the unbound service via either the interface's IPv4-Address or a virtual IPv4 CARP-address on the same interface were answered whenever the corresponding interface was configured as a "Network Interfaces" in unbound.
Since version 21.1, unbound does not answer queries directed to a CARP IP-address when the corresponding interface is configured as "Network Interface".
Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)
To Reproduce
Steps to reproduce the behavior:

Go to the "Interfaces: Virtual IPs: Settings" Page and set up virtual IP with Mode CARP-Mode for your LAN interface.
Go to the "Services: Unbound DNS: General" Page, enable unbound and set "Network Interfaces" to LAN
Open a terminal (e.g. ssh) session to the OPNSense server and run "nslookup github.com <your CARP-Address>"
Observe the error message ";; connection timed out; no servers could be reached"

Expected behavior
In step 4 above, the DNS-query should be answered; i.e. a CARP-Address associated with an interface picked in the "Network Interfaces" should be listened on. This was the behavior until version 21.7.7.
Alternatively, the CARP-Address could appear as a separate entry in the dropdown menu "Network Interfaces".
Describe alternatives you considered
As a workaround for now, I do not configure "Network Interfaces" which makes unbound listen on all interfaces including the CARP-address. That workaround however gives rise to the issue described in #5355.
Screenshots

Relevant log files
The query to the CARP-Address is not logged at all in unbound.
Additional context
The firewall rules must allow incoming Packets on LAN Port 53 (or whatever you configure unbound to listen on) of course.
Environment
OPNsense 22.1.1_3-amd64

First and foremost you should base your report on the contents of /var/unbound/unbound.conf contents. If you test locally make sure no policy based routing interferes with you rest. It’s better to test from a client in this case. Lastly, maybe you set no-bind option in CARP VIP which is available since 22.1.1?

maybe you set no-bind option in CARP VIP which is available since 22.1.1?

Indeed. That solves the issue. The "Allow service binding" checkbox was unchecked and I never touched that setting. Maybe that new checkbox should be ticked by default for VIPs created in earlier versions (without the no-binding option) to prevent a behavioral change? It was definitely not clear to me that I'd have to adapt my configuration from the release notes.

I’m not sure. We should have fixed the default in 22.1.1 along with the CARP support addition. But the question is how you ended up with no-bind in CARP if 22.1 didn’t support setting it? Or did you mean an IP alias with a VHID set? That would at least make sense then. 🤔

You say the feature was added in 22.1.1 which, according to https://forum.opnsense.org/index.php?topic=26992.0, was released on February 16?
However, I could restore a configuration from "SYSTEM: CONFIGURATION: HISTORY" timestamped "2/12/22 01:38:22" with the nobind-tag on my carp configuration. The relevant section of the config is (password and subnet removed):
<virtualip>
    <vip>
      <type>single</type>
      <subnet_bits>32</subnet_bits>
      <mode>carp</mode>
      <interface>lan</interface>
      <subnet>192.168.*.*</subnet>
      <vhid>1</vhid>
      <advskew>110</advskew>
      <advbase>1</advbase>
      <password>..../password>
      <nobind>1</nobind>
    </vip>
  </virtualip>

Does that mean I already had the <nobind>1</nobind> in my configuration before or was supported? Very strange. I'm happy to help you further investigate if desired.

@jPhy due to boolean inversion inside config.xml it did save "nobind" enabled (bind disabled) option for all types not supporting it, which included CARP in 22.1 specifically. The patch takes care of this preventing it for all types not IP alias/CARP as supported by 22.1.1 but it's really only cosmetics at this point since 22.1 can't be fixed retrospectively.
Cheers,
Franco


Calling parent method doesn't work

Trying to call parent method accordingly API docs but it doesn't work:
var Person = function(name) {
  this.name = name;
}

var Employee = function(name, position) {
    Employee.base(this, name);
    this.position = position;
}

ol.inherits(Employee, Person);

emp = new Employee('denis', 'webdev');
VM4311:7 Uncaught TypeError: Employee.base is not a function(…)

I don't think base should be called in the instantiation. I think call should be used like below although I havent tested this:
var Person = function(name) {
  this.name = name;
}

Person.prototype.updateName = function(name) {
  this.name = name;
}

var Employee = function(name, position) {
    Employee.call(this, name);
    this.position = position;
}
 Employee.prototype.updateName = function(name) {
  Person.base(this, 'updateName', 'Employee:' + name);
}

ol.inherits(Employee, Person);

emp = new Employee('denis', 'webdev');

Employee instantiates the new instance with a call (Person.call) to Person then updateName calls, using base, the updateName of the Person class.

@nicholas-l there are some errors in your example:

Person.call should be used instead Employee.call
Employee.prototype.updateName should be placed after ol.inherits because  ol.inherits function overwrites the child's prototype by an instance of the parent
Employee.base should be used instead Person.base (accordingly docs)

But anyway it doesn't work.

OOps yes, you are correct on all three counts :) so more like this:
var Person = function(name) {
  this.name = name;
}

Person.prototype.updateName = function(name) {
  this.name = name;
}

var Employee = function(name, position) {
    Person.call(this, name);
    this.position = position;
}
ol.inherits(Employee, Person);

Employee.prototype.updateName = function(name) {
  Employee.base(this, 'updateName', 'Employee:' + name);
}

emp = new Employee('denis', 'webdev');

Looks like this runs in ol-debug.js but not in ol.js

Could this be something to do with it?

Exactly. Is it expected behaviour that base function mentioned in API docs but doesn't work with ol.js?

Sorry for the confusion. The wiki page linked above is not relevant. This is a documentation problem. The base method is definitely not available. You have to know the superclass yourself.
Personally, I'd recommend to use class/inheritance tools from someone else, not ol.inherits (which is just an alias for goog.inherits, and only works well when you build your application together with OpenLayers using the Google Closure library).
That said, a pull reqeust fixing the documentation would be much appreciated.

PR https://github.com/openlayers/ol3/pull/5063

Documentation fixed with #5063.


dimaround window rule for window with blurred bg reduces blur.

How to reproduce:

Add this to your config

windowrulev2 = float,class:floating
windowrulev2 = dimaround,class:floating

bind = SUPER ALT, RETURN, exec, foot -a floating

Open the terminal with this binding

Result:

Dimaround + floating terminal with transparent bg

Now comment out the dimaround rule

No dimaround

As you can see, blur is vastly different between the two screenshots.
Expected: same level of blur, different brightness of background.
This is on https://github.com/hyprwm/Hyprland/commit/dbfa6eea7bf7a6f153cadf970719081e4ef729ee

Apparently this call to renderRect:
https://github.com/hyprwm/Hyprland/blob/b944386ca54cf650d660caac31f065c0211168b1/src/render/Renderer.cpp#L278
fucks up the blend func (removing the blend func setting from renderRect or that call fixes the issue but introduces other)
No clue why.

Hyprland, built from branch main at commit a0b675ec9e57af8bc631fc8cc54d062b58669a9f dirty (binds: add ignoreMods flag).
Tag: v0.31.0-7-ga0b675ec
Can confirm that this no longer happens.
I've only just decided to check on it, so I didn't pay attention when/what exactly fixed it, but it now works as expected:

Spoiler

yeah the switch to premult alpha did it but I forgot which commit it was. It was a while back.


Add batching and stats to openTSDB input

This change adds batching to the openTSDB input, for all points received over the telnet protocol. It also adds stats support to the openTSDB input.

@corylanou @dgnorton @DanielMorsing

Branch is green, as can be seen on Circle here: https://circleci.com/gh/influxdb/influxdb/5676

+1.  Assuming no new tests needed for the added functionality?

No @corylanou -- batching should be transparent to the tests, and the fact that they still pass is good enough for me. In addition the batcher itself has been unit-tested for a while now.


Add try/catch in PsiReferenceExpressionImpl::advanceResolve

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#63
#62  👈
#61
#60
#59
#58
#57
#56
#55
#54
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ermattt and the rest of your teammates on  Graphite


Documentation Review

The documentation of this package is very comprehensive, and I was quickly able to intuit the code's core functionality. Of particular note was the "backyard telescope" example — it certainly highlighted the educational promise of this tool. I was able to reproduce the plots within the documentation without error. My comments are below; similarly to the paper, they are mostly related to grammar/consistency:
Overall

[x] I'd suggest general consistency in italicizing the package name/using the package name in the code font, and writing "Github" as "GitHub"

Contributing

[x] Link the GitHub repository

Introductory tutorial 1

[x] Here and elsewhere, I'd make sure to add y-axis labels (even if they are arbitrary flux units)
[x] Out pulsar —> our pulsar
[x] Near the line introducing GBT: 9 —> (

Fold Mode: Introductory Tutorial 2

[x] long term —> long-term
[x] And then —> and then
[x] Hyphenate "-style"

Pulse profiles: Introductory tutorials

[x] Hyphenate two-dimensional
[x] Add a ylabel (even if arbitrary!) to plots
[x] I would consider a brief discussion of intensity units in general (or a pointer to a resource), given the potential for confusion.
[x] maintianed —> maintained
[x] lower frequency —> lower-frequency
[x] high frequency —> high-frequency
[x] "is a single Gauassian" —> "is a single Gaussian"
[x] "multiple Gaussian defineing is profile" —> "multiple Gaussians defining its profile"
[x] "resutls" —> "results"
[x] "intial" —> "initial"
[x] "mulit-gaussian" —> "multi-Gaussian"

ISM delays

[x] I would mention that paths relative to root in the GitHub repository
[x] 20 minute long —> 20-minute-long
[x] The line including "(here 2048 samples across the pulse period" needs an end parens
[x] intilialize —> initialize
[x] frequeny —> frequency
[x] "specifically frequency dependent delay" —> "specifically frequency-dependent delays"
[x] "eponential" —> "exponential"
[x] "dierectly shifting" —> "directly shifting"

Telescopes

[x] 20 minute long —> 20-minute-long
[x] "intilialize" —> "initialize"
[x] "Here we will show to use" —> "Here we will show how to use"
[x] "somebodies backyard" —> "somebody's backyard"
[x] Add end parens for the  "(here 2048 samples across the pulse period"  line
[x] A single plot comparing all the telescopes against each other might be nice!
[x] aperature —> aperture

Pulse nulling

[x] Period after "33%"
[x] "exmample" —> "example"
[x] exampe —> example
[x] Period after pulsar
[x] "lets" —> "let's"

This issue is part of my JOSS review.

@arjunsavel At this point I have made all of the suggested changes and corrections above. Changes have been pushed to the joss-review branch and will be in the main branch shortly.

@arjunsavel At this point I have made all of the suggested changes and corrections above. Changes have been pushed to the joss-review branch and will be in the main branch shortly.


[en] fix typo "mananger" in Node Architecture

[en] Fix typo: mananger -> manager

Fixes #34208
I have taken a look at other issues and PRs related to typos and the new contributor related docs, this is my first contribution however so hopefully I didn't miss anything important. Thanks for taking a look!

I'm unclear if I have to to be a corporate contributor or I can be an individual contributor so I am checking internally before I take this PR out of draft.

/retitle Fix typo "mananger" in Node Architecture


refactor: use accumulator to track explicit pending reasons

Awhile back, I thought accumulators might simplify the tracking needed to implement the "pending" and "focus" features. Since then, the code has already improved a lot, due to #1420. This pull request makes a minor change that replaces a complicated XPath expression (definition of the explicit-reason variable) with reading the value of an accumulator that tracks explicit pending reasons.
This pull request also adds some unit tests for the x:reason-for-pending function, and those tests pass locally before and after changing the code in that function.
This change isn't essential for v2.3 if we are close to releasing it, but I'll add the v2.3 milestone in case we're not that close to the release after all.

See also follow-up #1762


Prediction dtype fix

Alternative logic to https://github.com/fchollet/keras/pull/5903. Convert to floatx if dtype is float32 or float64, otherwise keep dtype. Only affects predict loop.
Most people are probably using float outputs and are unaffected. If you have int outputs, they will now be predicted as ints.
Cheers

If which cases would have int outputs?

@fchollet NLP-related tasks are the most likely to have int outputs (at least during test/generation). I have a model with a recurrent unit outputting characters each step and looping that output back into the unit. The choice at each step is discrete so the output is an int, which goes through an embedding at the next step. With most sequence generation models your output will be either an argmax or a sample from a softmax.
I feel like someone could accidentally output the wrong type of float and want it to be automatically converted to the right size, so the existing behavior makes sense. If your output is an int, it is probably intentional, so it shouldn't be converted automatically.
Side note: this behavior isn't ideal. If floatX=float32, and the gpu is returning float64, we are downcasting in numpy. Ideally, we would add a cast in the backend and return only half the data size to the cpu. Maybe a better solution would be to enforce the downcasting at the gpu instead of in numpy, but not really something worth working on right now.
Cheers

Not sure if it is necessary, but a more complicated alternative would be to assume that int size should mirror floatX.

Convert float32 or float64 to floatX.
If floatX=float32, convert ints to int32
If floatX=float64, convert ints to int64
Leave any other data types unchanged

Just updated to include float16. Float16, 32 and 64 are converted to floatX, everything else is left alone.
If the dtype is bool, int, unsignedint, or complex, that was probably intentional and the type is left alone.
Some really cool stuff out there on complex valued networks so we are future-proof :-)

Are there any reasons why your first PR would not be sufficient (using the data type of the first batch output)?

This one is more similar to current functionality. If there is someone who has float64 outputs and is expecting keras to automatically downcast to float32 they get to keep that feature.
I can imagine the average Joe accidentally having float64 outputs but meaning to have float32, or the other way around.
If you aren't worried about someone who depends on the predict function to downcast or upcast values from the GPU, which they really shouldn't be doing anyways, then the first PR is really the way to go.
As ever, the balance between clean and simple code and maintaining legacy functionality is in your hands.

Let's go with the first PR then.


how to append content at the cursor pos

Hello all,
I would like to programmatically add an image at the cursor position, and I can't find a way to get the cursor position...
Being able to get the selection bounds of the quill editor would be really useful, wouldn't it?

@gwenaelp did you find any solution?

This issue is stale because it has been open for 60 days with no activity.

This issue was closed because it has been inactive for 7 days since being marked as stale.


Improve bumpversion configuration

Bumpversion configuration should be adapted to allow using development (-dev) versions.

@csala Can you please update the CONTRIBUTING.rst with the workflow you have created? You can consider creating a makefile target or an expanding an existing target if there are a lot of steps that are done repeatedly.

Closed by #15


Update specs2-core, specs2-scalacheck to 4.12.10

Updates

org.specs2:specs2-core
org.specs2:specs2-scalacheck

from 4.12.3 to 4.12.10.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.specs2" } ]

labels: test-library-update, semver-patch

Superseded by #216.


Improve documentation

I think it could be more common issue. I killed about hour figure out it needs IndexedDB. More above IndexedDB is set to disable in Tor Browser, but it works in it, however doesn't not work with same settings in normal Firefox.
Some commentary on it, welcome. Also, I'm not sure this the best place to add it.

I think this is a very specific case, the chat not opening could be caused by a lot of different things. Also this should be in a troubleshooting section, not in the users guide.

I'll close and send it to troubleshooting.


Cannot edit rolemenu that emoticon already removed from server

Need something to update the current Roles that emoticon already removed from the server.
rolemenu edit [message_id] => This option only can be used if the emoticon still exist
So if the emoticon already removed like the picture above, there is no other way to update the roles.
Suggestion :
Make new rolemenu option, like : rolemenu edit_emoticon [message_id] [role_name_with_space]

It's already possible
There is a -rolemenu edit command

Yeah, I am using that, but it always giving me this respond.
Note that the emoticon that I want to change is not there anymore, since it is already removed from the my discord server. I did search on google and not found the way to edit my role reaction.

You cant use a non existant emoji.
That response is exactly what you are looking for. You will update that non existing emoji to a new one.
This is doable and you'd get better help on yags support server!


Third-party Proxy PDF Link Broken

In section "Extranet requirements", the third-party proxy PDF link is broken (404):
https://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/[MS-ADFSPIP].pdf

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

ID: 19f465e2-bc11-db54-2a2c-432833e6551d
Version Independent ID: 06c21eee-9ed9-8ce5-a6c8-e7c869d889af
Content: Federation Server Farm Using SQL Server
Content Source: WindowsServerDocs/identity/ad-fs/design/AD-FS-Requirements.md
Product: windows-server
Technology: identity-adfs
GitHub Login: @billmath
Microsoft Alias: billmath

Thanks for your dedication to our documentation. If we have been unable to review your issue in a timely manner, we sincerely apologize for the delayed response. We have captured the informtion you have provided for review. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


HDDS-2125. maven-javadoc-plugin.version is missing in pom.ozone.xml.

maven-javadoc-plugin.version is missing from pom.ozone.xml which is causing build failure.

+1. Thanks for fixing this too.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
1111
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
761
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
770
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
31
The patch does not generate ASF License warnings.

2785

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1439/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1439

Optional Tests
dupname asflicense xml

uname
Linux 9d7b48b3a86d 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 39e82ac

Max. process+thread count
412 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1439/1/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.


Fixing for issue 1738 - Error on rendering DynamicForm when having a Date Field with internal name starting with underscore ("_")

Q
A

Bug fix?
[x]

New feature?
[ ]

New sample?
[ ]

Related issues?
fixes #1738

What's in this Pull Request?
Problem statement
When a date column is created with an underscore or '_' at the begining, the form is not rendered correctly. For instance, if a column with name '_AccomplishedDate', '1AccomplishedDate' is created, and the list form is not rendered, instead it errors out.
Solution
On investigating the issue, I have created columns as below

Column Name
Type
Internal Name (Retrieved from Item)

1EFDate
DateTime
OData__x0031_EFDate

2EFDate
DateTime
OData__x0032_EFDate

_EFDate3
DateTime
OData__EFDate3

12312EDate
DateTime
OData__x0031_2312EDate

%Test
Text
OData__x0025_Test

1Test
DateTime
OData__x0031_Test

Since the FieldInternal names are not matching with the Internal names of the columns, this issue is spotted.
By checking the FieldInternal name as below, and validating, the issue is resolved.
        if (fieldName.startsWith('_x') || fieldName.startsWith('_')) {
          fieldName = `OData_${fieldName}`;
        }

Screenshot

Thanks,
Nishkalank

@NishkalankBezawada - sorry for the long delay. Could you please resolve the conflict?

@NishkalankBezawada - sorry for the long delay. Could you please resolve the conflict?

Hello @AJIXuMuK,
I have now resolved the merge conflicts.
Thanks,
Nish


BEAM-5985 Create jenkins jobs to run the load tests for Java SDK

Created builder for preparing Jenkins load tests with DSL for group by key Java load test. It will be extended with other tests, suites and Python SDK in next PRs.

Follow this checklist to help us incorporate your contribution quickly and easily:

[ x ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.
Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---

Run GroupByKey Java Load Test Direct

Run Seed Job

Is this ready for review?

Run Seed Job

@robertwb I just want to run some tests to be sure if it works correctly on Jenkins. May I ask you for review when it's ready?

Run GroupByKey Small Java Load Test Dataflow

Run GroupByKey Small Java Load Test Direct

Run Seed Job

Run GroupByKey Small Java Load Test Dataflow

Run GroupByKey Small Java Load Test Direct

Run Seed Job

Run GroupByKey Small Java Load Test Dataflow

Run GroupByKey Small Java Load Test Direct

Run Seed Job

Run GroupByKey Small Java Load Test Dataflow

Run Seed Job

Run GroupByKey Small Java Load Test Direct

Run GroupByKey Small Java Load Test Dataflow

I think the "Java GroupByKey Small Load Test Dataflow" job didn't set max number of workers option and that caused a situation where a Load test took all available workers and starve other jobs for an hour.
See here (match by Job id): https://console.cloud.google.com/dataflow/jobsDetail/locations/us-central1/jobs/2018-12-10_08_16_32-12840883456333022524?project=apache-beam-testing
Full console logs: https://builds.apache.org/job/beam_Java_LoadTests_GroupByKey_Dataflow_Small/5/consoleText
Judging from the logs and the code we are missing maxNumWorkers option in the job. @kkucharc could you add that option?
@alanmyrvold : Sorry for this. How many workers at most can we use for such big job?

@lgajowy Thank you for letting me know. I got confused after gradle workers parameter. The "Small" test isn't that small after all.
@alanmyrvold I am really sorry for this - I wasn't aware of this consequences. Besides of @lgajowy question about recommended workers amount, is there any way to cancel my own job when I see that something bad is happening?

No problem. Glad you tracked it down. Something like 10 max workers would be reasonable.

Run Seed Job

Run GroupByKey Small Java Load Test Dataflow

Run GroupByKey Small Java Load Test Direct

This is ready for review. I tested it on smaller input data set and it was succeeded. @swegner and @lgajowy would you take a look at it, please? cc: @pabloem

I'm feeling a bit overloaded, and probably won't have time to look at this until next week; would you mind finding another reviewer? You can find additional reviewers in the OWNERS file, and use the code velocity dashboard to see who's overloaded.

Thank you @swegner for letting me know. Especially I didn't see code velocity dashboard yet.

Run Dataflow Runner Nexmark Tests

Run seed job

Run seed job

Run seed job

Run GroupByKey Small Java Load Test Dataflow

Run GroupByKey Small Java Load Test Dataflow

Run Dataflow Runner Nexmark Tests

Run GroupByKey Small Java Load Test DIrect

Run Dataflow Runner Nexmark Tests

@lgajowy This is ready for the second round of review.
All Jenkins jobs are triggered properly.
The Direct runner test is failing due to OutOfMemoryError described in detail here.
Test on Dataflow is actually failing but status is still success what was reported here and the reason why is failing is reported here.

LGTM. The failures have been addressed with appropriate JIRA issues so I think we can merge. Those are not periodic jobs so the failures can be fixed afterward (unrelated issues).

Run Dataflow Runner Nexmark Tests

Run Direct Runner Nexmark Tests

Run GroupByKey Small Java Load Test Dataflow


"Uncaught ReferenceError: require is not defined" when using nuxt-edge

Version
v4.0.0-rc.2
Reproduction link
https://github.com/Vlaoff/apollonuxt
Steps to reproduce
I get the error when I launch nuxt and open it in the browser
What is expected ?
Babel should transpile the require
What is actually happening?
Babel keeps the require
Additional comments?
I think it's a problem with the babel 7/wepack 4 configuration.
It does not occur on nuxt 1.4.2, only on the nuxt-edge 2.0.0-xxx
I don't know if the problem is from @nuxtjs/apollo or nuxt.

This bug report is available on Nuxt community (#c139)

Same error here, but, as explained in referenced issue, npm i graphql to put version 14.0.2 seems to be a working work around.

@Vlaoff That should be fixed, could you try? ( delete lock file and reinstall)

Now its only fixed for vue-cli-plugin-apollo 0.17 while here its set as 0.16
https://github.com/nuxt-community/apollo-module/blob/master/package.json#L31
So a bump of vue-cli-plugin-apollo required
@dohomi

And I think the same with graphql-tag, this uses graphql ^0.13.0, and upgrading to vue-cli-plugin-apollo uses graphql ^14.0.2.
So it looks like we need to wait for this one as well.
https://github.com/apollographql/graphql-tag/issues/208

should be fixed with rc3


NEXT-00000 - Improve storefront render exception

1. Why is this change necessary?

If you are currently working with the storefront there is a custom error (Shopware-StorefrontException) which catches the TwigError and displays information about a view & parameters of the error.
However, the view name does not match the actual file containing the error, but rather the base template name of the page, which does not do much to identify the source of the error.
There is also no linked file & line in the Shopware-Exception. Because of this there is no file-preview and no way to jump to the error source, or even identify which line contains the error.
This PR fixes all these issues by using the correct Twig template name and showing the preview/linked file & line with the error source, which greatly improves the information output of the error message.

Before

After

2. What does this change do, exactly?

Changed the call parameters from StorefrontController to share the TwigError
Changed the StorefrontException to display the correct viewname (filename) and display the preview for file & line
Changed the StorefrontExceptionTest to match the changes of this PR

3. Describe each step to reproduce the issue or behaviour.

Create shopware development store
Insert error into a twig template
Try to access the page with the error in the view

4. Please link to the relevant issues (if any).
/
5. Checklist

[X] I have rebased my changes to remove merge conflicts
[X] I have written tests and verified that they fail without my change
[X] I have created a changelog file with all necessary information about my changes
[X] I have written or adjusted the documentation according to my changes
[X] This change has comments for package types, values, functions, and non-obvious lines of code
[X] I have read the contribution requirements and fulfil them.

🤖 Generated by Copilot at 813815a
This pull request improves the handling and logging of StorefrontExceptions that occur when rendering a storefront view fails due to a TwigError. It refactors the cannotRenderView function to take a TwigError as an argument and adds a unit test for it. It also updates the changelog and the StorefrontController accordingly.

🤖 Generated by Copilot at 813815a

Add a changelog entry for the improvement (link)
Replace the view name and message parameters of the cannotRenderView function with a TwigError parameter, and use its properties to populate the exception message and data (link, link)
Pass the caught TwigError instance to the cannotRenderView function in the renderView function of the StorefrontController class (link)
Create a mock TwigError instance with a given message, line, and source context, and use it to test the cannotRenderView function in the StorefrontExceptionTest class (link, link)
Add a use statement for the Twig\Error\Error class in the StorefrontException class (link) and the StorefrontExceptionTest class (link)

Hi @akf-bw
thank you for your suggested change.
It is great but you need to implement a new method for the cannotRenderView method and deprecate the old one and keep it as it is, because the change of the parameter would be a breaking change.
`
/*

@deprecated tag:v6.7.0 - Use renderViewException instead
*/
public static function cannotRenderView(string $view, string $message, array $parameters): self
{`

 public static function renderViewException(string $view, TwigError $error, array $parameters): self     {
Regards 👍

@ssltg @tobiasberge I added the new function and deprecated the old one. PR should now be complete.

Hi @akf-bw, thank you for your effort. We merged your PR to trunk: https://github.com/shopware/shopware/commit/304ce773684d306173c0d3f62daa684b4644e479 🎉


React19

Woek in React 19?

This PR passes the test so yes: https://github.com/vitejs/vite-plugin-react-swc/pull/251
But be aware of this dev change in React 19: https://github.com/facebook/react/issues/29915


The contrast between several combinations of difference-of-3 shades is slightly below 4.5:1

Hello!
First, great work, I love these colours, I use them on a personal site and it's gorgeous. On one occasion, I had a contrast error on "emerald-6 on sky-3", and wanted to know if there were more. So I did a test on all combinations between shades with a difference of 3, in all colours.
The twig code I used:
{% set colors=["gray", "rose", "raspberry", "red", "orange", "cinnamon", "amber", "yellow", "lime", "chartreuse", "green", "emerald", "aquamarine", "teal", "cyan", "powder", "sky", "cerulean", "azure", "blue", "indigo", "violet", "purple", "magenta", "pink"] %}

  {% for color in colors %}
     {% for i in 1..3 %}
       {% for c in colors if c != color %}

            {{ color ~ "-" ~ (i+3) ~ " on " ~ c ~ "-" ~ i }}

       {% endfor %}
    {% endfor %}
  {% endfor %}

I put that on a page with all the custom properties loaded in CSS, and ran Tanaguru WebExt RGAA 4 (RGAA is the french administration rewriting of WCAG, the rules on colour contrast are the same).
The result:

combination
ratio

gray-4 on azure-1
4.44

gray-6 on sky-3
4.47

gray-6 on cerulean-3
4.48

rose-4 on cyan-1
4.48

rose-4 on powder-1
4.49

rose-4 on sky-1
4.47

rose-4 on cerulean-1
4.48

rose-4 on azure-1
4.37

rose-4 on blue-1
4.49

rose-4 on indigo-1
4.48

rose-4 on violet-1
4.46

rose-6 on sky-3
4.43

rose-6 on cerulean-3
4.44

rose-6 on azure-3
4.47

rose-6 on blue-3
4.49

rose-6 on indigo-3
4.49

raspberry-4 on azure-1
4.40

raspberry-4 on violet-1
4.49

raspberry-6 on yellow-3
4.48

raspberry-6 on lime-3
4.48

raspberry-6 on cyan-3
4.42

raspberry-6 on powder-3
4.45

raspberry-6 on sky-3
4.32

raspberry-6 on cerulean-3
4.34

raspberry-6 on azure-3
4.37

raspberry-6 on blue-3
4.39

raspberry-6 on indigo-3
4.39

red-4 on azure-1
4.42

red-6 on yellow-3
4.46

red-6 on lime-3
4.46

red-6 on chartreuse-3
4.49

red-6 on cyan-3
4.40

red-6 on powder-3
4.43

red-6 on sky-3
4.31

red-6 on cerulean-3
4.32

red-6 on azure-3
4.35

red-6 on blue-3
4.37

red-6 on indigo-3
4.37

orange-4 on sky-1
4.48

orange-4 on cerulean-1
4.49

orange-4 on azure-1
4.38

orange-4 on violet-1
4.47

orange-6 on sky-3
4.42

orange-6 on cerulean-3
4.44

orange-6 on azure-3
4.47

orange-6 on blue-3
4.49

orange-6 on indigo-3
4.49

cinnamon-4 on cyan-1
4.45

cinnamon-4 on powder-1
4.46

cinnamon-4 on sky-1
4.44

cinnamon-4 on cerulean-1
4.45

cinnamon-4 on azure-1
4.34

cinnamon-4 on blue-1
4.45

cinnamon-4 on indigo-1
4.45

cinnamon-4 on violet-1
4.43

cinnamon-6 on sky-3
4.41

cinnamon-6 on cerulean-3
4.42

cinnamon-6 on azure-3
4.45

cinnamon-6 on blue-3
4.47

cinnamon-6 on indigo-3
4.47

amber-4 on azure-1
4.46

amber-6 on cyan-3
4.48

amber-6 on sky-3
4.39

amber-6 on cerulean-3
4.41

amber-6 on azure-3
4.43

amber-6 on blue-3
4.45

amber-6 on indigo-3
4.45

yellow-4 on azure-1
4.48

yellow-6 on sky-3
4.42

yellow-6 on cerulean-3
4.43

yellow-6 on azure-3
4.46

yellow-6 on blue-3
4.48

yellow-6 on indigo-3
4.48

lime-4 on azure-1
4.46

lime-6 on cyan-3
4.48

lime-6 on sky-3
4.38

lime-6 on cerulean-3
4.40

lime-6 on azure-3
4.42

lime-6 on blue-3
4.45

lime-6 on indigo-3
4.45

chartreuse-4 on azure-1
4.46

chartreuse-6 on sky-3
4.48

green-4 on azure-1
4.42

emerald-4 on sky-1
4.49

emerald-4 on azure-1
4.39

emerald-4 on violet-1
4.49

emerald-6 on sky-3
4.49

aquamarine-4 on azure-1
4.42

aquamarine-6 on sky-3
4.47

aquamarine-6 on cerulean-3
4.49

teal-6 on sky-3
4.49

violet-4 on sky-1
4.49

violet-4 on azure-1
4.38

purple-4 on azure-1
4.47

magenta-4 on azure-1
4.44

pink-4 on azure-1
4.49

pink-6 on cyan-3
4.49

pink-6 on sky-3
4.39

pink-6 on cerulean-3
4.41

pink-6 on azure-3
4.44

pink-6 on blue-3
4.46

pink-6 on indigo-3
4.46

It's a lot… the contrast is always really really close to 4.5 so maybe it could be easy to fix (easy but long, I know…).

Thank you so much for your work here. 😬 You are correct, that is a lot and rather embarrassing.
I will take some time to figure out exactly what happened, but my best guess is some combination of:
(1) my own insufficient understanding of relative luminance within the library that I used to generate these colors
(2) insufficient testing (which was really just my own spot testing, yikes)
(3) some kind of regression with the color values as I worked through the different shades
(4) erroneous conversion between color values (moving from LCH to hex, for example)
Point 2 (insufficient testing) is quite obvious, this was a mistake that I made. This project should have had tests built in from the start, I apologize for that and will remedy it with a future update.
Thanks again, will leave this open until fixed as it's obviously a relevant issue.

Oh, no need to be embarrassed! That was not my intention at all. Besides, it's about 100 combinations in about 1900, so approximately 5%, which is not a lot. I'm sorry I said that, because when I posted I didn't calculate the total…
For what it's worth, as I needed the sky-3, I tested two alternatives values for it: #0995ac and #0296b2. For my current needs I will choose between these :)

erroneous conversion between color values (moving from LCH to hex, for example)

Interesting! I used hex because that's what I know, do you want me to test with LCH colors?
Do you want me to test for 7:1 contrast too?

Oh, no worries, not offended! Again, I'm really appreciative that you flagged all of this. I think 100 is still kind of a lot 😊
Re: more testing. I'd say maybe don't spend more of your time on it at the moment, let me get a handle on the causes and see if I can get some automated testing in place so that we no longer have to rely on the generosity of the community 😊
The general difficulty in determining the shades of these colors is that, in order to keep those contrast ratios reliable and get 6 shades per color, there isn't a lot of extra room to lighten/darken individual shades. Or, to put it another way, fixing one contrast ratio problem often causing another, opposite contrast ratio problem.
So, I've got more work to do and will reply here when I have an update. Thanks!

Duly noted 🙂 Take care!


Detect cgroups and namespaces via virt-launcher-socket

Instead of introspecting docker containers, to find out the Pod namespaces and cgroups, let virt-handler detect them via a socket. Every virt-launcher instance creates a socket in a directory which is shared with virt-handler. On the VM start, virt-handler checks which process owns this socket and determines which cgroups and namespaces to use for the qemu process. This PR does not yet treat the socket creation as a trigger for the virt-handler controller. This will come in another PR.
Further, the PR does not use the <resource><partition></partition></resource> field in the Domain XML, to set the cgroups. This turns out to be more complex than expected. If libvirt does not have access to systemd, it will try to create it's own cgroup hierarchy and will therefore add .partition, where it should add .slice. If it has access to systemd, it will try to add .slice as group suffix, where k8s/systemd uses .scope.

@berrange  thx for the review.
So regarding the socket creation flow change:
The final story, which would be completed by the next PR, which will use the sockets also as source for the controller inside virt-handler is this:
virt-launchers will create the sockets in a flat directory structure. virt-handler watches via a ListWatcher, based on listing all sockets in the directory (list) and inotify (watch) in the directory for creations and deletions of sockets. This way, we can follow in the controller the creations and deletions. Like with a file descriptor, which would be kept open the whole time, we can now follow these socket changes. In both ways there would be potentially the risk of a race. Both ways, by themselves alone don't provide enough guarantee. Right now, the guarantee, that the VM never gets started or dies immediately when the pod changes, does the PID namespace change.
Advange of this approach, compared to connecting to one socket maintained by virt-handler:

No need keep the file descriptors open

This means, we can resync and restart virt-handler anytime
virt-launcher is independent of virt-handler. It does not need any reconnect logic, or anything else ...

A ListWatcher source much better suits to the watch and follow approach of the k8s client-go framework
We still have the same race guarantees like with the other approach

You can't rely on inotify to track deletion of UNIX socket files on disk. Deleting the UNIX socket requires explicit action during shutdown, and so that will fail if the process is terminated abnormally. You must have the UNIX sockets open to detect EOF as that's guaranteed to occur if the process has gone. Having multiple different unprivileged process all create sockets in the same directory is also a bad idea - its the classic scenario that's lead to countless /tmp file vulnerabilities.

Both approaches have their trade-offs. One the one hand you have the possibility that a virt-launcher process dies abnormally and leaves a dangling socket file. And on the other you have the possibility that virt-handler dies abnormally and does the same.
@berrange In the handler-opens-socket scenario, how should virt-launcher react if the connection to virt-handler is broken (e.g. during a normal re-start)?

You can't rely on inotify to track deletion of UNIX socket files on disk. Deleting the UNIX socket requires explicit action during shutdown, and so that will fail if the process is terminated abnormally. You must have the UNIX sockets open to detect EOF as that's guaranteed to occur if the process has gone.

That is a good point. I will have think of something else then. If I can't restart virt-handler and need to have the connection open the whole time,  I am not very happy with that solution.

Having multiple different unprivileged process all create sockets in the same directory is also a bad idea - its the classic scenario that's lead to countless /tmp file vulnerabilities.

We have to somehow verify the other end anyway. With a k8s secret or something, which we ask for over the socket ...

A quick and dirty solution, would of course be, to resync every 30 seconds, and also open the sockets from the virt-handler side, to see if there is still someone listening. Even one minute would be fine. It is not critical for us if we miss it, since we can't rely on the socket for VM start/dies anyway. It is just a nice addition to react in time (in that context, I am still not sure what our hard PID namespace guarantee should be replaced with).

This socket creation is the wrong way around. virt-handler should be creating a single listener socket, that is then connected to by virt-launcher, which will trigger startup. With this inverted approach, you're forcing virt-handler to trigger startup via some other means, since I has no idea when the socket has been created.

maybe help clarify my understanding here. I might be missing something.
I had it in my mind that virt-handler was going to create a listener socket like you've described, and that virt-launcher was going to create a unix socket as well like @rmohr's patch does now.  Then when virt-launcher initiates it would connect to virt-handler which would both tell virt-handler about about the unix socket virt-launcher created and trigger VM launch. From there, I thought there was some libvirt feature we were going to leverage where we hand off the file virt-launcher created to libvirt.

Looking through these comments some more, this is shaping up to be something different than I expected.
We need to avoid any persistent connection between virt-launcher and virt-handler/libvirtd that is coupled with the lifecycle of a vm.  Virt-handler and the libvirtd container must be able to fail without impacting active VMs on the host. We also need to maintain the ability to update all of these components independently of one another.
The reason I was okay with the socket approach is because I was led to believe virt-launcher would open a socket that would be associated with the qemu process. So, when the qemu process exits, we'd get an EOF in the corresponding virt-launcher container. If this isn't the case, then the socket approach is arguably worse than what we already have.
@berrange just to clarify, does the feature to associate a socket with the lifecycle of a qemu process exist now, or was this something that we could theoretically do in the future?

In general, we could move forward with this, although it does not solve the pods-vm binding, and not the cgroup joining, it at least makes kubevirt pretty much CRI independent and provides an unambiguous way of detecting the right cgroups and namespaces. virt-handler, can also in a follow on PR check for a k8s secret to be present within the virt-launcher pod, which created the socket.
Thoughts?

In general, we could move forward with this, although it does not solve the pods-vm binding, and not the cgroup joining, it at least makes kubevirt pretty much CRI independent and provides an unambiguous way of detecting the right cgroups and namespaces. virt-handler, can also in a follow on PR check for a k8s secret to be present within the virt-launcher pod, which created the socket.

@rmohr I agree.  This is way cleaner way of doing the cgroup and namespace detection than what we are currently doing.  I'll try and help get this merged by doing a detailed code review soon.

To me the value of this PR is unclear.

Right now it gives us cgroup and  namespace detection in a CRI independent way.

The discussion would really benefit from a design shedding light on the controversial issues and giving reasons why the one or other approach was chosen.
Until then it's difficult to tell if it's the right direction.

If we would want to switch the socket creation later we would have almost exactly the same detection code + much more reconnect logic. So if we need it, we can easily extend this code to do the socket creation the other way.
I think that we really don't have a clear picture yet, how to solve setting the cgroups and how to tie the VM lifetime to the pod lifetime without the PID namespace. For that I agree that we need ideas and proposals. The PR is not addressing these issues, so would defering that fine for you?

To me the value of this PR is unclear. There are still quite a few open questions

What are the implications (pros and cons) of keeping the sockets open or closing them
The scope of this PR has changed through the course of the review.

Initially this was seen as a way to move towards a new method of binding the VM lifecycle to the virt-launcher pod through the use of a socket. however through further review (history is in this pr), It appears using the socket as a means of coordination is not a good option at this point.
The remaining value here is we have a way of detecting cgroups and namespaces that is independent of Docker.  With cgroup/namespace detection as the only goal here, this PR seems fairly sane and useful to me.
The component that lives in the cgroup/namespace we want to detect (virt-launcher) creates the unix socket.  The other side (virt-handler) uses the socket to get pid info and ultimately cgroup/namespace info in a way that is not container runtime dependent.
With that scope in mind, There's no value in keeping the socket open. We just want open the socket in order to determine the virt-launcher pid.

Handler vs launcher opening/providing sockets

If the socket is just for a runtime independent way of pid detection, it appears to make the most sense for virt-launcher to create the socket since that's the component we want to discover the cgroup/namespace
of.

the issue around resource tag

what is the issue around resource tag you're referring to?

An RFE/bug must be filed on libvirt for the Resource field
RFE is now there: https://bugzilla.redhat.com/show_bug.cgi?id=1487336

Additional test and documentation added. Fixing the VM re-apply bug will follow tomorrow.

Ok, only the usual test fails. I implemented a non-final workaround, on how to share host specific data for migrations.
Before we merge this, I want to add one or two documents, to describe how the VM start and migration flow works, next refactor steps and where we want to go (as far as we know). However, please do a code-review again in the meantime.

retest this please